20061218 VSWG Conference Call Minutes

From CDGWiki

Call Date/Time: Tuesday 19 December 0100 UTC (18 December 1700 UTC)

Contents 1 Agenda 2 Participants 3 Discussion 3.1 Survey Review 3.2 Implementation Actions and Timeline 3.3 Business Case Thoughts 4 Next Steps

[edit] Agenda

1. Survey Review
2. Implementation Actions and Timeline
3. Business Case Thoughts

[edit] Participants

Representatives of the following companies attended the call:

• QUALCOMM
• Sprint
• Verizon

[edit] Discussion

[edit] Survey Review

• General Survey
  • 5 carriers have responded to this survey. While the responses varied for how the indicator is delivered (SMS versus IS41) they are consistent in that most subs dial their own number back with the press of a key and then need to reenter their MDN and VM pin.
• Trigger Survey
  • Four carriers have responded to this survey. Please respond to this.

[edit] Implementation Actions and Timeline

• Of the actions presented at the San Francisco meeting, this call focused on "Serving Operators add Roaming Partners' VM Access Codes"
• There are two broad ways in which this could be done:
  • Explicit entry of RP VM access codes into the MSCs' dialplans, with the associated translation to a full international number
  • Triggering/modification methods, where the RSP performs the translation from the home access code to the full international number.
• Explicit entry:
  • "Low-tech" (no special capabilities required by the MSC), but potentially a lot of work if you have many MSCs
  • Some carriers expressed concerns with this approach in the San Francisco meeting - much will depend on an individual operator's particular situation.
  • Some carriers have varying dialplans nationwide within their own network - particularly for "*-numbers" or "short numbers" of the sort often used for VM access. This can be hard enough to keep track of domestically without worrying about the ongoing maintenance of inbound roamer codes as well, especially if clashes are encountered.
  • Use of a "roamer dialplan" is recommended, for this and other reasons. Having all your international inbound roamers in a separate dialplan can minimize the chances of a clash with home codes, as well as allow other flexibility (e.g. disallowing 900/premium-rate calls from roamers). Please contact Daniel if you would like more information on roamer dialplans.
  • Individual codes would need to be entered for each roaming partner as there is little or no commonality among operators as to the access codes used.
• Triggering & Modification:
  • We discussed three possible methods:
    • FEATREQ translation: When a partner uses a * code for VM access, a FEATREQ can be launched to the RSP. The RSP could translate this code to the required full international number, and return the digit string in the featreq.
    • ORREQ translation: When a short code (e.g. 1234) is used to access voicemail, the appropriate k-digit trigger could be added to the subscriber profile at registration time by the RSP, then an ORREQ is launched to the RSP from the serving MSC when the subscriber dials the code. If a match is found to the VM retrieval code, the RSP performs the translation and returns the digits in the orreq. A similar approach could also be used when the subscriber calls their own (national format) MDN as their VM access method.
    • Callback Translation: If the roaming partner uses the SMS VMN method to set the VM indicator, the callback number embedded in the SMS message could be modified en route by the RSP to the full international string. When the subscriber selects "Listen" on their phone, this international number would be dialed.
  • The ORREQ and FEATREQ methods require more complicated ANSI-41 message handling capabilities at the serving MSC, however these signaling flows are common for non-roaming scenarios.
  • These methods would potentially allow a serving carrier to add new roaming partner retrieval codes with little or no incremental work, although specific clashes may still need to be addressed.
  • The CIBER record would need to be rated on the resulting international call, not the subscriber dialed digits. (The Printed Call field may possibly be used to carry the dialed digits for bill presentation)
  • The callback modification is only of use for a carrier that uses SMS notification, however it requires no special support from the serving network (other than MT SMS roaming for the notification itself)
  • All 3 options require work from the RSP. Daniel to approach the RSPs to understand their capabilities here.

[edit] Business Case Thoughts

• How can we help operators estimate the additional revenue to be gained from enabling "one-touch" voicemail access?
• Not especially easy: how to estimate the number of retrieval calls that aren't happening because the dialing requirements are more confusing than at home?
• One approach is to compare the number of retrieval calls (any method) made by subscribers at home to that made by roamers (using the "dial your own full international number" and "explicit international retrieval code" methods). Even allowing for a scale factor for "roaming dialing reluctance" we may be able to identify a gap here that is a potential for additional calls.
• The business case may also incorporate an estimate for subsequent calls that result from the retrieval call, i.e. subscriber listens to message then calls back the person who left the message.
• Assumption is that operators would try to work out the behavior of their own subscribers - they could then share some info with their outbound partners as part of the effort to encourage them to implement "one-touch" retrieval.

[edit] Next Steps

• Operators please fill out the surveys if you haven't already.
• A business case section will be added to the wiki Voicemail page - please add your thoughts/comments.
• Daniel will report back on RSP modification support. In the meantime operators should consider their ability to support any/all of the methods discussed.

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