20061116 VSWG Conference Call Minutes

From CDGWiki

Call Date/Time: Thursday 16 October, 1600 UTC (0800 PST)

Contents 1 Agenda 2 Participants 3 Discussion 4 Next Steps

[edit] Agenda

1. Introduction of Plus Code Dialing Requirements document and highlight key topics
2. Discussion on issues arising

[edit] Participants

Representatives of the following companies attended the call:

• Aicent
• Alltel
• CDG
• KDDI
• Lucent NZ
• QUALCOMM
• Syniverse
• Tata
• Telus
• Verizon Wireless
• Vivo

[edit] Discussion

• This document is intended to be a catch-all, providing a superset of all carrier requirements. in general, where there are multiple implementation options, the relevant entity is required to support both methods, even if the use of one is preferred.
• Some specific requirements were highlighted, and provoked further discussion:
  • 2.2.1-050: Mobile ignores ASCII "+" on an international CLI. Some handsets have been observed populating an ASCII "+" symbol in the dialed digit string, a practice that is discouraged. This requirement is to allow the MS to handle the reverse situation, where the MSC sends the "+" - we don't want the mobile to display two leading + symbols.
    • Tata notes that their mobiles (which do otherwise support PCD) won't handle this.
    • QC: This is not a likely case, so it's not a big deal if the mobile doesn't support it, but it is included in the document to provide for the best possible interoperability.
  • 3.1.1-090: MSC includes Intl Prefix or Intl indicator for onward signaling. Since operators may have different needs, ask the MSC to support both approaches.
    • Lucent NZ: This gets complicated. What appears like the easiest choice here might have knock-on effects in other scenarios. Suggest expressing a preference for maintaining the international indicator, rather than add the International Access Code (IAC) / International Prefix.
    • QC: Different operators may have different levels of support for the international indicator deeper into their network. Retaining the indicator would be a "purer" solution but may not suit everyone. Hence the "must support both" approach.
  • 3.1.1-100: Use of Preferred Carrier: This makes everything more complicated. If a subscriber has a preferred carrier, they should get that if they don't specify a preference when dialing. Although a carrier subscription doesn't mean much when the subscriber is outside their home country, if we want people to program their phone book in plus code format then they will dial like this when at home too. This issue is believed to have led to PCD being described as "illegal" in some countries.
    • VzW: in some cases it is the serving switch which needs to decide whether it will honor the preferred carrier.
    • QC: OK, it is easy to choose to ignore the preference, the tricky part comes in trying to honor it. ANSI-41 includes the CarrierDigits parameter to provide this information to the serving switch.
  • 3.1.1-130: Option for CDR to show that PCD occurred or be the same as today. This is similar to the onward signaling issue - while the identification of PCD use may be handy for reporting, it may also cause additional cost/work for operators to modify their billing systems.
  • MSC Origination and Triggers
    • Lucent NZ: We need to consider the MSC handling of internationally-formatted digits in trigger response messages. Also with the option to add the prefix digits vs retain the international indication, do we need to specify different preferences for different stages in the call model? E.g. a message launched from the Origination Attempt Authorized trigger, versus the Analyzed Information trigger?
    • QC: Hmmm. Good point. Will investigate.
  • 3.2.1-010: CLI sent in international format
    • Tata: What if the serving MSC already modifies an internationally-formatted CLI digit string to include the serving country IAC (and changes the number type so it is no longer International). This works great for MSs that don't support PCD. But PCD-capable handsets will not see the benefit of PCD!
    • QC: This is a valid concern. There is no way for a MS to advertise to the network that it supports PCD (other than by originating a PCD call), and this information is not passed from the home network in ANSI-41. Most networks today are not clever enough to perform the IAC prefixing, so for these networks the PCD recommendation will improve the situation for PCD-capable MSs. This needs some more thought.
    • Tata: What about calls from the serving country? Should these be presented in "+" format?
    • QC: When a subscriber is in their home country, and the caller is from the home country, then the calling number should be presented in national format. When the subscriber is roaming internationally, a call from the serving country needs to be trunked back to the home network to perform the HLR interrogation (LOCREQ). At this point, the calling party should be in international format. Although it is theoretically possible that the HLR/serving MSC could reformat the digits back to national, the recommendation is not to bother: the document (following IS-875) already requires that the serving network accept an internationally-formatted origination to the same country as the MSC (ref 3.1.1-040) so the subscriber can easily return the call. So all calls received by an international roamer will be in international format (unless this is changed by a recommendation regarding the existing modification above)

[edit] Next Steps

• We will continue the discussion at the face-to-face meeting later this month. A listen-only bridge will be available for the entire VSWG session so those who can't attend in person will have a chance to participate in some way.
• In the meantime, team members are encouraged to continue to review the document. Comments are welcome via the wiki or email to Daniel or the team list.

Main | About | Work Items | Whiteboard | Meetings | Documents