Roaming Voice Mail Deposit, Indicator and
Access
CDG Document 135
Version 1.0
4 December 2006
CDMA Development Group
575 Anton Boulevard, Suite 560
Costa Mesa, California 92626
PHONE +1 888 800-CDMA
+1 714 545-5211
FAX +1 714 545-4601
http://www.cdg.org
cdg@cdg.org
Notice
Each CDG member acknowledges that CDG does not review the
disclosures or contributions of any CDG member nor does CDG verify
the status of the ownership of any of the intellectual property rights
associated with any such disclosures or contributions. Accordingly, each
CDG member should consider all disclosures and contributions as being
made solely on an as-is basis. If any CDG member makes any use of
any disclosure or contribution, then such use is at such CDG member's
sole risk. Each CDG member agrees that CDG shall not be liable to any
person or entity (including any CDG member) arising out of any use of
any disclosure or contribution, including any liability arising out of
infringement of intellectual property rights.
Roaming Voice Mail Deposit, Indicator and Access
Contents
<page left intentionally blank>
Ref Doc. 135, Ver. 1.0
4 December 2006
ii
Contents
1. Introduction ................................................................................................................................ 1
1.1 Scope ................................................................................................................................. 1
2. Voicemail Deposit ...................................................................................................................... 2
2.1 No Roaming Involvement ................................................................................................... 2
2.2 Serving System Signaling .................................................................................................. 3
2.2.1 Serving System Trunking .................................................................................... 4
3. Voicemail Indicator .................................................................................................................... 7
3.1 Definition ............................................................................................................................ 7
3.2 Types of Indication ............................................................................................................. 7
3.3 Delivery Mechanisms ......................................................................................................... 7
3.3.1 Regular SMS ....................................................................................................... 8
3.3.2 SMS Voice Mail Notification ................................................................................ 8
3.3.3 Message Waiting Notification .............................................................................. 9
3.4 Discussion ........................................................................................................................ 10
3.5 Recommendations ........................................................................................................... 11
4. Voicemail Access ..................................................................................................................... 12
4.1 Definitions ......................................................................................................................... 12
4.2 Current Implementation .................................................................................................... 12
4.2.1 Home Network Access ...................................................................................... 12
4.2.2 Roaming Access................................................................................................ 13
4.3 Main Problem Elements ................................................................................................... 13
4.4 Possible Solutions ............................................................................................................ 14
4.4.1 Access Code Translation .................................................................................. 14
4.4.2 CLI Management ............................................................................................... 16
4.4.3 ANSI-41 Voice Message Retrieval .................................................................... 17
4.4.4 VMS Outcall ....................................................................................................... 18
4.4.5 Triggered Outcall ............................................................................................... 19
4.4.6 SMS-Provided Voicemail Access Number ........................................................ 20
4.4.7 Third Party Solutions ......................................................................................... 20
Ref Doc 135 Ver. 1.0
4 December 2006
iii
Roaming Voice Mail Deposit, Indicator and Access
Contents
4.5 Discussion and Recommendations .................................................................................. 21
5. Glossary .................................................................................................................................... 23
Figures
Figure 1. Call Forwarding from HLR ............................................................................................. 2
Figure 2. Call Forwarding with routreq indication ......................................................................... 3
Figure 3. Call Forwarding with serving system TransferToNumberRequest ................................ 4
Figure 4. Call Forwarding with RedirectionRequest ..................................................................... 5
Figure 5. SMS-Based Notification Delivery .................................................................................. 8
Figure 6. Message Waiting Notification ........................................................................................ 9
Figure 7. Feature Request for Voicemail Access ....................................................................... 15
Figure 8. ANSI-41 Voice Message Retrieval .............................................................................. 17
Figure 9. Service Node Based Voicemail Access ...................................................................... 20
Revision History
Date
Version
Description
13 February 2006
0.1
Initial release
19 February 2006
0.2
Minor updates following internal review
13 March 2006
0.3
Added voicemail deposit / call forwarding section
10 May 2006
0.4
Update to CDG format
11 July 2006
0.5
Update post-IRT – change emphasis for indicator
and access options
4 December 2006
1.0
Release version. No change from previous
Ref Doc. 135, Ver. 1.0
4 December 2006
iv
1. Introduction
This document describes various methods for delivering an indicator of new voice mail
messages to a roaming subscriber, and for the subscriber to subsequently access
his/her mailbox while roaming to listen to the messages. The document provides
recommendations for indicator and access methods to try to achieve maximum
availability of these services across roaming partners.
The twin services of voicemail indicator and access have been designated as high
priority by the Voice and SMS Working Group of the CDMA Development Group’s
International Roaming Team. This implies that these services are highly desirable for
roamers, but do not currently work as well as operators would like.
1.1 Scope
The document focuses on international roaming. Issues related to domestic roaming
may be similar, but are not specifically addressed in this document. In this document the
term “roaming” can generally be taken to mean international roaming.
Ref Doc 135 Ver. 1.0
4 December 2006
1
2. Voicemail Deposit
Voicemail deposit is the process by which a new message is left in a subscriber’s
mailbox. This deposit can occur through various mechanisms, e.g.:


Direct insertion of message, e.g., operator mass marketing communication.

Call Forwarding, i.e., redirection of an attempted mobile-terminated call to voicemail
with the caller leaving a message.
Mailbox-to-mailbox messaging, e.g., forwarding of a message from one user’s
mailbox to another’s.
This section discusses voicemail deposit only as it could be affected by a subscriber’s
roaming status. As such, the only deposit mechanism that will be considered is Call
Forwarding.
2.1 No Roaming Involvement
Some call forwarding scenarios that can result in a voicemail deposit are not affected by
the subscriber’s roaming status. They are included for completeness:

Call Forward Unconditional (CFU): CFU is invoked at the HLR on receipt of a
LocationRequest. The subscriber’s location is not relevant to the behavior of the
service.

Call Forward No Answer (CFNA) – Inactive at HLR: When the subscriber is known
by the HLR to be inactive, CFNA functions similar to CFU. The HLR returns forwardto destination digits in the LocationRequest Return Result, and there is no
involvement with a serving system.
Figure 1 below shows the call flow:
Orig
MSC
HLR
Serving
MSC
LOCREQ
locreq
a
b
c
d
Figure 1. Call Forwarding from HLR
Ref Doc 135 Ver. 1.0
4 December 2006
2
Roaming Voice Mail Deposit, Indicator and Access
Voicemail Deposit
a) A call for a mobile is received at the originating MSC (this MSC may also be
known as the “in-call MSC” or “home MSC”).
b) The MC sends a LocationRequest message to the HLR to determine the current
location of the mobile.
c) The HLR determines that the mobile is either unavailable (with CFNA active) or
has CFU active. It returns the forward-to destination digits in the
LocationRequest Return Result.
d) The originating MSC forwards the call.
2.2 Serving System Signaling
The following scenarios touch the serving system with ANSI-41 signaling. The required
behavior from the serving system is well standardized, and is expected to be supported
by all current MSCs. These forwarding scenarios should work well even when the
subscriber is roaming internationally:

Call Forward Busy (CFB): The serving MSC detects that the mobile is busy and
returns an indication in the RoutingRequest Return Result. This scenario assumes
Call Waiting is not active for the called subscriber.

Call Forward No Answer – Inactive at VLR: Although the HLR shows the
subscriber as active, the VLR knows the subscriber is inactive. An inactive indication
is returned in the RoutingRequest Return Result.
Figure 2 below shows the call flow:
Orig
MSC
Serving
MSC
HLR
a
LOCREQ
ROUTREQ
routreq
locreq
b
c
d
e
f
Figure 2. Call Forwarding with routreq indication
a) A call for a mobile is received at the originating MSC.
b) The MC sends a LocationRequest message to the HLR to determine the current
location of the mobile.
c) The HLR (recording the mobile as active) sends a RoutingRequest Invoke to the
serving MSC.
Ref Doc. 135, Ver. 1.0
4 December 2006
3
Roaming Voice Mail Deposit, Indicator and Access
Voicemail Deposit
d) The MSC (including VLR) determines that the mobile is busy or inactive and
returns an appropriate indication in the AccessDeniedReason parameter of the
RoutingRequest Return Result.
e) The HLR receives the indication, and returns the appropriate forward-to digits to
the originating MSC, based on the subscriber’s active Call Forwarding features.
f)
The originating MSC forwards the call.
2.2.1 Serving System Trunking
In the following scenarios, the call is actually routed to the serving system before the
need to forward is detected:

Call Forward No Answer – Ring No Reply: The call is delivered to the serving
system and the called subscriber is alerted, but does not answer. Depending on
network configuration, this scenario may also occur if the mobile does not respond to
the page.

Call Forward Busy with call collision: The subscriber is available at the time the
ROUTREQ is received, but becomes busy before the incoming call delivery leg
arrives at the serving MSC.
ANSI-41 allows two different methods of handling the call forwarding in the case where
the serving MSC has already received the call: the serving MSC can forward the call
itself; or can return the call to the originating MSC for it to forward (using the
RedirectionRequest operation). When the called subscriber is roaming internationally,
the second method is strongly recommended. Figure 3 and Figure 4 below show the
two call flows, and the subsequent discussion explains the reasons for preferring the
second method.
Orig
MSC
Serving
MSC
HLR
a
LOCREQ
ROUTREQ
routreq
b
c
d
locreq
e
TRANUMREQ
tranumreq
f
g
h
i
Figure 3. Call Forwarding with serving system TransferToNumberRequest
Ref Doc. 135, Ver. 1.0
4 December 2006
4
Roaming Voice Mail Deposit, Indicator and Access
Voicemail Deposit
a) A call for a mobile is received at the originating MSC.
b) The MC sends a LocationRequest message to the HLR to determine the current
location of the mobile.
c) The HLR sends a RoutingRequest Invoke to the serving MSC.
d) The serving MSC (recording the mobile as active and available) returns a
Temporary Local Directory Number (TLDN).
e) The HLR returns the TLDN to the originating MSC.
f)
The originating MSC delivers the call to the serving MSC using the TLDN.
g) The serving MSC determines that the call cannot be completed (e.g., ring no
reply, or subscriber now busy) and that the subscriber has Call Forwarding
active. It sends a TransferToNumberRequest Invoke (TRANUMREQ) to the HLR
to request the forward-to destination number. The TRANUMREQ includes the
reason the call is to be forwarded.
h) The HLR returns the forward-to digits.
i)
The serving MSC forwards the call.
Orig
MSC
Serving
MSC
HLR
a
LOCREQ
ROUTREQ
routreq
b
c
d
locreq
e
f
REDREQ
g
TRANUMREQ
h
tranumreq
redreq
i
j
k
l
Figure 4. Call Forwarding with RedirectionRequest
a-f)
g)
As for previous scenario.
The serving MSC determines that the call cannot be completed (e.g., ring no
reply, or subscriber now busy) and that the subscriber has Call Forwarding
active. It sends a RedirectionRequest Invoke (REDREQ) to the originating MSC
Ref Doc. 135, Ver. 1.0
4 December 2006
5
Roaming Voice Mail Deposit, Indicator and Access
Voicemail Deposit
to request that the originating MSC forward the call. The REDREQ includes the
reason the call is to be forwarded.
h)
The originating MSC sends a TRANUMREQ to the HLR to request the forward-to
destination digits for the appropriate Call Forwarding service.
i)
The HLR returns the digits to the originating MSC.
j)
The originating MSC releases the call delivery leg.
k)
The originating MSC forwards the call.
In the call flow shown in Figure 3 (“Serving System TRANUMREQ” method), the serving
system receives the forward-to destination digits as stored in the HLR. Especially in the
case of voicemail deposit (but also to a lesser extent for other forward-to destinations)
the digit string is likely to be home-network specific, with no meaning in the serving
system. Even if the digits are “internationalized” by the HLR (a function not specified in
any standard) or RSP by the addition of the home network country code, the resulting
digit string may still not result in a successful voicemail deposit (e.g., if a “special” short
number is used for forwarding to the Voice Mail System). Call forwarding using this
method is unlikely to work successfully without considerable preplanning by the home
operator.
The Serving System TRANUMREQ method is also inefficient from a routing perspective.
When the subscriber is roaming internationally, it requires the maintenance of two
international circuits between the home and serving networks for as long as the caller is
leaving a voicemail message. The roaming subscriber is thus charged for two
international legs for a call over whose length they have no control.
The Serving System TRANUMREQ method is likely to be unsuccessful and (if it does
work) expensive. No successful implementations were known at the time of writing and
its use is strongly discouraged.
Ref Doc. 135, Ver. 1.0
4 December 2006
6
3. Voicemail Indicator
The ability to receive notification of new voicemail messages is a key requirement for
international roaming. The cost and complexity of roaming call delivery may mean that
comparatively more terminating call attempts result in a voice message deposit.
3.1 Definition
Voicemail indicator is used in this document as a generic term to refer to any of the
various ways in which a mobile can indicate to the user that there are voicemail
messages waiting to be heard. This term is not intended to imply anything about the
method in which the indicator is provided to the mobile.
3.2 Types of Indication
Various types of indication are possible at the mobile:

SMS Message: An SMS message, when read, indicates to the subscriber that s/he
has a new message or messages. This is a normal SMS message that resides in the
mobile’s SMS inbox together with other SMSs.

Message Waiting Indicator (MWI): An icon or message on the mobile’s display,
possibly including the number of messages. This option is the most commonly used.

Pip Tone: A “pip tone” is inserted into the voice channel when the subscriber
originates a call or answers an incoming call. This type of indication does not require
any specific mobile functionality.

Alert Pip Tone: This tone is applied when the mobile powers up and a message is
waiting, or when the first message is left at the Voicemail System (VMS), and the
mobile is idle. As most mobiles today can play an audible tone when Message
Waiting Indicator is applied, Alert Pip Tone is rarely used.
3.3 Delivery Mechanisms
This section describes the means by which the notification is transferred from the VMS
to the mobile.
Note that in each case, the VMS uses another node in the home network (e.g., MC or
HLR) as part of the transfer mechanism. As this communication takes place wholly
Ref Doc 135 Ver. 1.0
4 December 2006
7
Roaming Voice Mail Deposit, Indicator and Access
Voicemail Indicator
within the home network and without regard to the subscriber’s location, it is
independent of roaming and is not discussed in detail in this document.
3.3.1 Regular SMS
This method is used with the “SMS message” notification type described above. It
follows the normal method of Mobile-Terminated SMS roaming. Figure 5 below shows a
typical message flow:
VMS
MC
HLR
Serving
MSC
a
SMSREQ
b
smsreq
SMDPP
c
d
e
smdpp
f
Figure 5. SMS-Based Notification Delivery
a) On deposit of a new message, the VMS notifies the Message Center (MC). The
communication protocol used is beyond the scope of this document, although a
likely candidate is SMPP. In this case the notification would take the form of a
message submission, containing the text to be provided to the mobile.
b) The MC sends an SMSRequest message to the HLR to determine the current
location of the mobile.
c) The HLR responds with the address of the serving MSC.
d) The MC sends the “you have new voicemail” message to the serving MSC,
inside a standard SMSDeliveryPointToPoint (SMDPP) message.
e) The SMS is sent over the air to the mobile, and acknowledged.
f)
The serving MSC reports successful delivery of the SMDPP.
3.3.2 SMS Voice Mail Notification
SMS Voice Mail Notification (VMN) uses a special form of SMS to carry message waiting
information to the mobile. This SMS is defined in TIA/EIA-637. The same ANSI-41
message flow is used to deliver the message to the serving MSC. Inside the SMDPP,
the message has the following characteristics:

Special Teleservice: The SMS_TeleserviceIdentifier is set to 4099 (CDMA Voice
Mail Notification), rather than the usual value of 4098 (CDMA Cellular Messaging
Teleservice)

Number of Messages subparameter: Inside the Teleservice message, the Number
of Messages subparameter indicates the number of messages stored at the VMS.
Ref Doc. 135, Ver. 1.0
4 December 2006
8
Roaming Voice Mail Deposit, Indicator and Access
Voicemail Indicator
This special SMS is sent to the mobile, where it can be used to set the Message Waiting
Indicator.
C.S0015-B defines Enhanced VMN, which provides more information about the waiting
messages. There are currently no known implementations of this feature.
3.3.3 Message Waiting Notification
Message Waiting Notification (MWN) is defined in TIA/EIA-664 and ANSI-41. It uses
standard ANSI-41 messaging to transfer voicemail indication information from the HLR
to the serving MSC, and out to the mobile. This method of notification is in wide use
among CDMA operators.
The information is carried in two parameters that are transmitted as part of the
subscriber profile:

MessageWaitingNotificationCount (MWNCOUNT): Gives the number of
messages waiting

MessageWaitingNotificationType (MWNTYPE): Indicates the subscribed options –
any or all of: MWI; Pip Tone; and Alert Pip Tone.
The call flow in Figure 6 below shows a typical scenario:
VMS
Serving
MSC
HLR
MSGDIR
a
msgdir
QUALDIR
qualdir
b
c
d
e
Figure 6. Message Waiting Notification
a) On deposit of a new message, the VMS informs the HLR. In the diagram, the
MessageDirective operation (introduced in IS-841, and included in ANSI-41-E) is
shown, however, as this communication is internal to the home network, any
method may be used.
b) The HLR acknowledges the message from the VMS.
c) The HLR determines that the subscriber profile has changed, and sends a
QualificationDirective Invoke (QUALDIR) to the serving MSC1. The QUALDIR
contains the MWNCOUNT and MWNTYPE (assumed here to include MWI)
parameters.
d) The MSC acknowledges the message from the HLR.
1
MSC and VLR assumed co-located
Ref Doc. 135, Ver. 1.0
4 December 2006
9
Roaming Voice Mail Deposit, Indicator and Access
Voicemail Indicator
e) The MSC sends the MWI information to the mobile.
In the example above, QUALDIR was used to transfer the MWN information. It can also
be sent in any other message that carries the subscriber profile, i.e.,
RegistrationNotification Return Result, or QualificationRequest Return Result.
From the serving MSC to the mobile, MWI information is transferred using an IS-2000
Feature Notification Message, or Flash With Information Message (depending on
whether the mobile is currently on a traffic channel). Alert Pip Tone information can be
sent using an Alert With Information Message. Most CDMA mobiles available today
support at least MWI, if not APT as well.
Pip Tones can be applied to the traffic channel directly by the MSC without any more
specific information being sent to the mobile.
X.S0030 defines Enhanced MWN, in which the message waiting count can be
acknowledged back to the HLR. When a mobile roams into a new serving area, this can
prevent the same count being sent to the mobile when it registers in the new system. At
the time of writing, there were no known implementations of Enhanced MWN.
3.4 Discussion
The array of available voice mail indicator options has led to a lack of uniformity among
operators as to the implemented method. When subscribers roam into different
operators’ networks, the differences are experienced by subscribers as lack of
functionality. No one method is supported by all operators.
The voicemail system itself is not aware of a subscriber’s location. It is assumed that
operators will use the same method for both on-network and roaming notification (with
the possible exception of conversion as discussed below).
Individual operator preference may vary, but the “regular SMS” notification method
would appear to provide the least functionality to subscribers – the fact that the
notification is not distinguished from other SMSs could lead to subscriber confusion. This
method depends on the availability of Mobile terminated SMS (MT-SMS) roaming. It will
work in any serving network where the home operator can deliver SMS to its roamers.
SMS is currently an active work item for the CDG IRT, but at present the MT-SMS
footprint for many operators is much less than their voice roaming footprint.
The SMS VMN method provides a better subscriber experience than regular SMS, as a
dedicated voicemail icon can be set. SMS VMN may also provide a better experience
than ANSI-41 MWN as it can include information about the original caller. SMS VMN is
subject to the same limitations as regular SMS in terms of availability in roaming
markets. In addition, some MSCs may not support the SMS VMN Teleservice (no
special processing is required at the MSC for this Teleservice, so in theory this limitation
should not affect many if any MSCs).
ANSI-41 MWN uses standard ANSI-41 messages. All networks that support IS41C/ANSI-41D will support the operations used to carry the MWN information. The
Ref Doc. 135, Ver. 1.0
4 December 2006
10
Roaming Voice Mail Deposit, Indicator and Access
Voicemail Indicator
MWNCOUNT and MWNTYPE parameters require IS-41-C/ANSI-41-D – this should be
supported by the majority of MSCs today.
Not all operators’ MSCs currently support MWN. Although the ANSI-41 messages are
supported, the information is not provided to the subscriber over the air interface. It is
unclear whether this is a capability gap for the particular MSC vendor, or if MWN support
is simply an option that has not been purchased.
Where networks are not compatible, a possible resolution approach involves using an
intermediate node (either a Roaming Service Provider (RSP) capable of MAP-layer
manipulation, or a node with similar capabilities in one of the roaming partners’
networks) to convert from one voicemail indication type to another. For example, the
node may detect the MWNTYPE and MWNCOUNT parameters in a QUALDIR, remove
them, and create and send an SMDPP using SMS VMN. Similarly, the VMN SMDPP
could be changed to a QUALDIR containing the above MWN parameters. This approach
is most applicable to MWI, as the indication type that can be supported by multiple
delivery mechanisms. At the June 2006 IRT meeting, both Syniverse and Verisign
indicated that such a conversion function could be developed.
Regular SMS presents more of a challenge for conversion, as it must be distinguished
from other messages by parsing the actual message text – this represents more work for
a conversion node.
3.5 Recommendations

No single voicemail indication type and delivery mechanism can today give home
operators complete coverage across all roaming partners. However, ANSI-41 MWN
with the MWI notification type is recommended as the method most likely to work.
This preference is based solely on the lack of SMS-MT roaming footprint. Operators
who are confident in their SMS-MT reach may prefer SMS VMN.

The ultimate goal is ubiquitous support for either primary notification method.
Operators are not recommended to change away from an already-deployed solution.

Operators who do not support MWN as a serving network are encouraged to
investigate means to remedy this situation.

Operators using SMS VMN, and whose SMS-MT roaming footprint does not match
that of voice roaming, are encouraged to investigate conversion mechanisms
(including any service that may be provided by an RSP) to change the SMS to an
MWN message for non-SMS destinations. In addition, ongoing efforts to improve the
implementation of MT-SMS roaming may yield benefits for VMN as well.

Operators using regular SMS are encouraged to investigate other alternatives for
delivering a voicemail indicator, as well as continuing to work on expanding MT-SMS
deployment.
Ref Doc. 135, Ver. 1.0
4 December 2006
11
4. Voicemail Access
As with subscribers at home, roaming subscribers require the ability to access their
voice mailbox to listen to messages. For reasons that will be discussed below, this
presents a challenge in the roaming environment.
Unlike voicemail indicator, operator survey responses have indicted a high degree of
similarity among operator implementations of voicemail access. Unfortunately, this does
not lead to a simple solution!
4.1 Definitions
In this document, voicemail access is used to refer to a subscriber establishing a voice
path to the VMS (and inside the VMS to their own mailbox) for the purposes of new
message retrieval, sending a message, changing personal options etc. The term Voice
Mail Retrieval (VMR), is used to refer to a specific means of achieving voicemail access
that is defined in ANSI-41.
The connection of a caller to the called party’s mailbox for message deposit (e.g., after
call forwarding) is discussed in §2.
4.2 Current Implementation
This section describes the way in which most operators are believed to implement
voicemail access today.
4.2.1 Home Network Access

Subscribers in their home network dial a convenient voicemail access code. This
code may be either a feature code (*89), or a “short code” (e.g., 1417). This access
code may be pre-assigned to a short-cut dialing procedure on the mobile. Some
operators’ subscribers dial their own (nationally-formatted) Mobile Directory Number
(MDN), which may also be pre-loaded into a “one-touch” feature on the handset.

The network routes this call to the VMS. The dialed digits may require translation to a
“full” destination number before routing. If the dialed digits are a feature code, this
may either be directly translated at the MSC, or converted by the HLR into the true
destination number (i.e., normal FeatureRequest with TerminationList processing).
The destination number is generic, i.e., all subscribers are routed to the same
Ref Doc 135 Ver. 1.0
4 December 2006
12
Roaming Voice Mail Deposit, Indicator and Access
Voicemail Access
number. Dialing the subscriber’s own number may invoke Call Forward Busy, or may
be recognized at the HLR (CLI = dialed digits) and routed directly to the VMS.

The VMS recognizes the ISUP Calling Party Number / Calling Line Identity (CLI), and
accesses the correct mailbox.

The subscriber may be prompted to enter his/her PIN. Many operators offer the
option to bypass the PIN when the subscriber accesses their own mailbox.
4.2.2 Roaming Access
When roaming the access method is different. Subscribers typically are required to:



Dial a full international number to reach the VMS.
Enter their own number to identify the mailbox.
Enter their PIN.
An alternative access method is as follows:

Subscriber dials his/her own number in full international format (i.e., International
Access Code (IAC) + country code +MDN).


Subscriber escapes from their greeting to “owner mode” (e.g., by pressing # or *).
Subscriber enters his/her PIN.
In some cases, subscribers who regularly use the “PIN bypass” feature while at home
may not be able to remember their PIN while they are roaming.
4.3 Main Problem Elements
Operators would in general like for their subscribers to be able to access their mailbox in
the same manner while roaming as they do when at home.
There are two key elements which force the differences listed above:

Dialed digit analysis in the serving network: The short access code is typically not
recognized by the serving network. The home network access codes typically do not
conform to any standard, and may even clash with other codes in use in the serving
network. This leads to the use of different (longer) access numbers while roaming.
The “dial own MDN” method, especially when preloaded in the handset, results in a
digit string which does not represent an international call while in the serving network,
and which may clash with the serving country’s national numbering plan.

Unreliable CLI: Most operators’ VMSs use the incoming CLI information to
determine the correct mailbox. Unfortunately, when the subscriber is calling from
another country, the CLI is often unreliable. Depending on the way that international
calls are routed, CLI may be available on only a percentage of calls, and the status
may change from day to day. Even without the international call leg, roamers may
use a dummy or incorrect number as their CLI due to modifications in the serving
network to avoid clashes with domestic numbers. These factors lead to the need for
the subscriber to enter his/her mailbox number, as well as the unavailability of PIN
bypass.
Ref Doc. 135, Ver. 1.0
4 December 2006
13
Roaming Voice Mail Deposit, Indicator and Access
Voicemail Access
Any solution for roaming voicemail access will ideally address both of these limitations.
4.4 Possible Solutions
This section lists various approaches that aim to improve the subscriber experience for
roaming voicemail access. Some of these solutions may be available today, while others
are merely future possibilities. Not all solutions fully address both issues described
above. The set of options available to individual operators will most likely depend on the
capabilities of their particular network nodes and VMS.
4.4.1 Access Code Translation
Various mechanisms exist by which a short code, feature code or national MDN dialed
by a roamer in the serving network may be translated to a full international number to
allow the call to reach the VMS in the home network.
In each case, the solution does not address the “Unreliable CLI” issue – the subscriber
will probably have to enter their mailbox and PIN via DTMF once they have been
connected to the VMS.
As the MDN is unique to each subscriber, detection of this call scenario requires
different capabilities in the MSC than those required for a uniform (per roaming partner)
access string. The “dial own MDN” method is discussed in §4.4.1.4
4.4.1.1 MSC Translation
In this option, the serving operator configures their MSC translation tables to map the
home network voicemail access code to the full international number required to reach
the home VMS from the serving network.
This option requires no particular feature support, but may represent a large
implementation effort for the serving operator. With multiple roaming partners, the
chance of the voicemail access code clashing with that of another roaming partner, or
some other number in the serving network are increased.
4.4.1.2 Feature Request
Rather than perform the translation directly, the MSC can issue a request for information
to be provided by another entity (typically the HLR). The call flow for this option is shown
in Figure 7 below:
Ref Doc. 135, Ver. 1.0
4 December 2006
14
Roaming Voice Mail Deposit, Indicator and Access
VMS
Voicemail Access
Serving
MSC
HLR
a
FEATREQ
featreq
b
c
d
e
Figure 7. Feature Request for Voicemail Access
a) The mobile originates a call to the voicemail access feature code.
b) The MSC recognizes the feature code pattern (without being required to know
that it is for voicemail access), and sends an ANSI-41 FeatureRequest
(FEATREQ) to the subscriber’s HLR.
c) The HLR recognizes that the received dialed digits are for voicemail access, and
returns the correct access number. See the discussion below for ways in which
the correct format of this number can be ensured.
d) The MSC uses the digits string received in the previous step to extend the call to
the VMS in the home network.
e) The subscriber is connected to his/her mailbox (mailbox number and PIN entry
may be required).
In order for the call to complete correctly, the digit string received by the MSC must be
formatted correctly for use in the serving network. There are various ways to achieve
this:

E.164 Format: If the serving MSC can accept it, the HLR can return the digits in full
E.164 format, i.e., including Country Code (CC) and National Significant Number, and
with the Nature of Number bit set to “International”. The MSC will then add the
appropriate International Access Code (IAC) before making the outcall.

IAC Included: If the HLR can determine in which serving market the subscriber is
roaming, it can use internal data to add the correct IAC for the serving country (as
well as the CC for the home network) to the digit string before returning the featreq.

External Modification: If neither of the above methods are possible, an intermediate
entity (e.g., RSP, not shown in the diagram) could modify the digits, inserting the IAC
and CC before the featreq reaches the serving MSC.
The ability to continue a feature call based on received digits is believed to be a common
capability among currently deployed MSCs. Similarly, the ability for and HLR to return a
digit string in response to a FEATREQ is believed to be widespread.
Ref Doc. 135, Ver. 1.0
4 December 2006
15
Roaming Voice Mail Deposit, Indicator and Access
Voicemail Access
4.4.1.3 Origination Request
If the home network voicemail access code does not conform to the *XX feature code
format, it will not be recognized by the serving MSC. To allow a short code (e.g., 1417)
to be used, the subscriber could be provisioned with the appropriate “k-digit” trigger. On
detection of the trigger, the MSC will launch an OriginationRequest (ORREQ) to the
HLR, instead of the FEATREQ. The HLR can return the VMS access number in the
corresponding return result (subject to the same number formatting options as above).
Use of ORREQ in international roaming scenarios is believed to be comparatively rare
today; however the necessary capabilities are in common use by many operators for
“on-network” services.
4.4.1.4 MDN Translation
Handsets configured for “one-touch” retrieval that dial their own nationally-formatted
MDN present a particular challenge for international roaming: the dialed digit string is not
appropriately formatted for the serving network/country, and is also unique persubscriber.
One possible approach is to use the ANSI-41 Revertive Call trigger. This could be
inserted into the subscriber profile by the RSP. The trigger is detected when the dialed
digits are equal to the subscriber’s MDN. The resulting OriginationRequest could be
processed by the RSP to add the necessary International Access Code and Country
Code. The status of MSC support for the Revertive Call trigger is unknown at the time of
writing.
Alternatively, the MSC may allow for handling of a revertive call as a local procedure
without requiring a trigger or the intervention of the RSP. Addition of the necessary prefix
digits may be possible through standard dial plan digit string modification.
A potential complication arises if an internationally-formatted (E.164) MDN is used when
the subscriber is roaming. Use of the E.164 MDN is recommended in order to enable
correct CLI for roamer-originated calls. If the MDN is internationalized especially for
roaming, the dialed digits will no longer match the MDN stored in the VLR, and the
revertive call treatment may not be applied.
In this case, several workarounds are possible: the MSC may declare a revertive call
match on an “x least significant digits” basis; E.164 MDN could be used both at home
and while roaming (which would not assist currently deployed handsets); or the
appropriate “k-digit” trigger could be inserted by the RSP to match any call with the same
number of digits as the national MDN.
4.4.2 CLI Management
As stated above, CLI is currently often unreliable when a call is received in the home
network from an international roamer. However, implementation of the full E.164 MDN,
and careful selection of long distance/international providers may enable the correct
transport of the CLI.
For detailed discussion of roamer-originated CLI, see (draft) CDG Reference Doc #139.
Ref Doc. 135, Ver. 1.0
4 December 2006
16
Roaming Voice Mail Deposit, Indicator and Access
Voicemail Access
4.4.3 ANSI-41 Voice Message Retrieval
ANSI-41 defines a specific method of voice mail access. This method is referred to as
Voice Message Retrieval (VMR). The term Voice Mail Retrieval is also sometimes used
to refer to the same service.
VMR specifically addresses the need to connect to a VMS via an access number that
may not be recognized in the serving network. It uses a TLDN similar to call delivery, but
in the reverse direction (i.e., from serving to home network).
Figure 8 below shows a typical call flow.
VMS Host
VMS
Home
Nwk
MSC
HLR
Serving
MSC
a
FEATREQ
b
ROUTREQ
c
routreq
featreq
d
e
f
g
h
Figure 8. ANSI-41 Voice Message Retrieval
a) The mobile originates a call to the VMR feature code.
b) The MSC recognizes the feature code format (i.e., *XX), and sends a
FeatureRequest Invoke (FEATREQ) to the HLR. The MSC does not need to
know that the call is for VMR.
To use a non feature code access number (e.g., 1417) instead, the subscriber
profile could include a 4-digit trigger, which would result in an OriginationRequest
being sent to the HLR instead of the FEATREQ.
c) The HLR recognizes the VMR code, and looks up the pre-defined VMS Host
MSC for this subscriber. It sends a RoutingRequest Invoke (ROUTREQ) to this
MSC. Parameters in the ROUTREQ identify it as relating to VMR, and include a
VMS access code and the mailbox number.
d) The VMS Host MSC returns a TLDN that will be used to deliver the voice call
back to this MSC.
e) The HLR returns the TLDN to the serving MSC in the FeatureRequest Return
Result.
f)
The serving MSC initiates a call to the VMS Host MSC, using the TLDN as the
Called Party Number.
Ref Doc. 135, Ver. 1.0
4 December 2006
17
Roaming Voice Mail Deposit, Indicator and Access
Voicemail Access
g) When the VMS Host MSC receives the call, it dials out to the VMS using the
access code and mailbox number previously received in the ROUTREQ.
h) The subscriber is now connected to his/her voicemail.
The example shown above uses a feature call to trigger VMR. ANSI-41 also allows for
VMR to be triggered by a revertive call (i.e., subscriber dials his/her own number). The
revertive call may be identified at the HLR on receipt of a LocationRequest, or at the
serving MSC, resulting in an OriginationRequest (ORREQ) instead of the FEATREQ. In
either case, identifying a revertive call may be difficult in an international roaming
scenario: at the serving MSC, a match between MDN and dialed digits may be missed
due to the presence of International Access Code and Country Code digits; at the HLR,
the Calling Party number may be unavailable due to the international call leg. This
document focuses on the feature call method. ANSI-41 does not explicitly define support
for the ORREQ usage shown as an alternative in step b above.
The use of a feature code resulting in an international call means that no special
treatment is required in the serving network to route the call. As with any number
translation service in an international roaming scenario, care may be required to ensure
that the TLDN is received in the correct format (e.g., Nature of Number = International,
or IAC included. See also §4.4.1.2 ). Home network feature codes are not universally
available while roaming today, but in general are believed to represent a minor
implementation effort in the serving network.
The standards description of VMR provides a means for the VMS to be selected, as well
as the individual mailbox. The PIN may also be included. However, the exact method for
this selection is not defined in ANSI-41, and there does not appear to be a means to set
the Calling Party Number on the outcall from the VMS Host MSC to the VMS. The
VMBOX parameter would appear to be the best choice to use as the Calling Party
Number. Alternatively, the MSC may be able to construct a Called Party Number that
includes (e.g., concatenates) the VMS Access Code, the mailbox number, and the PIN.
If this format is understood by the VMS, a similar result to that of setting the CLI can be
achieved.
(Note: concatenation of all required numbers for access might also appear to be a useful
tool for the “Access Code Translation” methods described above. However, it is
assumed that the requirements for a full international number may push the called Party
Number string length beyond the maximum that can reliably be sent from one network to
another.)
Most operators who responded to the survey indicated that their networks do not
currently support ANSI-41 VMR. It is unclear at this point whether in these cases VMR is
an optional feature that has not been purchased, or is not a current vendor capability.
4.4.4 VMS Outcall
This option avoids the dependence on the serving network, and Calling Party Number,
by having the VMS initiate the call to the mobile, instead of the other way around.
Ref Doc. 135, Ver. 1.0
4 December 2006
18
Roaming Voice Mail Deposit, Indicator and Access
Voicemail Access
The sections below discuss ways in which this outcall may be triggered. Otherwise, a
callback that is not “on demand” (e.g., instead attempted immediately after message
deposit, periodically thereafter until success) may be inconvenient for subscribers.
Special treatment (e.g., check of Calling Party Number for VMS pilot number) may be
required to ensure that if the outcall goes to voicemail when the subscriber does not
answer, a new message is not deposited.
This option depends solely on VMS capability, and is not impacted by standards. The
capability of existing deployed VMSs with regards to outcall is currently unknown.
This option (especially if suitably triggered) may address the key limitations of current
international roaming voicemail access methods, but may be perceived by subscribers
as a significantly different procedure to be used while roaming. Of course, there is
nothing to prevent this method being used while the subscriber is at home as well.
4.4.5 Triggered Outcall
The VMS outcall described above may be more convenient for subscribers if they can
trigger the outcall at a time of their choosing. Similar to a “normal” subscriber-initiated
access, the trigger must be successfully processed by the serving network, and the
home network must be able to identify which mobile originated it. Two triggering
methods are discussed here: Mobile Originated SMS (MO-SMS), and
FEATREQ/ORREQ:
4.4.5.1 MO-SMS
In this method, the subscriber sends a MO-SMS to a specific voicemail access
destination. Inside the home network, this destination number results in communication
between the Message Center (MC) and the VMS, and the VMS makes the outcall to the
mobile.
The communication between the MC and VMS need not use ANSI-41 (and in fact there
is no standard ANSI-41 message that would natively perform this function): SMPP is a
likely alternative. In this case, there is no standards dependence. The capability of
existing deployed VMSs with regards to an SMPP triggered outcall is currently unknown.
The primary limitation with this option is the current lack of support for MO-SMS
roaming. In the short term, other access methods are likely to yield more widespread
success.
4.4.5.2 FEATREQ/ORREQ
In this method, the subscriber initiates a voice call to a short/feature code. Depending on
the dialed code, and subscriber trigger provisioning, the serving MSC initiates either a
FEATREQ or ORREQ to the HLR. The HLR communicates with the VMS, and the VMS
initiates an outcall to the mobile.
The communication between the HLR and VMS need not use ANSI-41 (and in fact there
is no standard ANSI-41 message that would natively perform this function). Such
communication is expected to be beyond the capabilities of currently deployed HLRs.
Ref Doc. 135, Ver. 1.0
4 December 2006
19
Roaming Voice Mail Deposit, Indicator and Access
Voicemail Access
The capability of existing deployed VMSs with regards to an outcall triggered in this
fashion is currently unknown.
4.4.6 SMS-Provided Voicemail Access Number
Any of the SMS notification methods described in §3.3 (i.e., regular SMS, VMN,
Enhanced VMN) allow for the inclusion of a callback number, which could be set to the
VMS access number. Format modification of this number en route (e.g., at an RSP) may
be necessary, as the originating entity (most likely the VMS) may be unaware of the
subscriber’s location.
This solution does not address the “unreliable CLI” issue for roamers – subscribers
would most likely have to enter their mailbox number and PIN to gain access after being
connected to the VMS
As described in §3.4, use of any SMS-based notification method is limited to those
destinations where MT-SMS roaming is implemented.
The Enhanced VMN feature also allows for the inclusion of a dedicated voicemail
Access Number in the SMS message. A subscriber receiving such an SMS on a
supporting mobile would be able to initiate the call to the VMS with a “single keypress”,
provided the Access Number was correctly formatted for use in the serving network.
Although the Enhanced VMN SMS parameter can include a mailbox ID, it is not clear
how or if this is used when accessing the mailbox.
There are currently no known implementations of Enhanced VMN support either at the
MC or mobile.
4.4.7 Third Party Solutions
Some companies (e.g., Starhome) offer a solution that delivers true CLI into the home
network, using a “reverse call delivery” process similar to VMR. Figure 9 below shows a
possible call flow:
VMS
HLR
Home
Nwk SN
Serving
Nwk SN
Serving
MSC
a
FEATREQ/ORREQ
featreq/orreq
b
c
d
e
f
g
h
i
Figure 9. Service Node Based Voicemail Access
a)
The mobile originates a call to the voicemail access short/feature code.
Ref Doc. 135, Ver. 1.0
4 December 2006
20
Roaming Voice Mail Deposit, Indicator and Access
b-c)
Voicemail Access
Optionally, the MSC may use FEATREQ or ORREQ to obtain routing information
from the HLR. Otherwise, the feature code is translated/routed directly by the
serving MSC.
d)
The MSC routes the call to the Service Node (SN) in the serving network.
e)
The SN communicates with its partner SN in the home network. The
communication is via an Internet Protocol (IP) connection. The serving network
SN provides information about the calling party to the home network SN.
Note: if CLI is not preserved in the ISUP leg in step d, a connection could
potentially be made using WIN messaging, e.g., AnalyzedInformation,
SeizeResource, ConnectResource to ensure that the MDN is reliably transferred
to the SN.
f)
The home network SN returns a TLDN.
g)
The call is extended to the home network SN using the TLDN as the called
number.
h)
The SN calls out to the VMS, using the MDN received in step e as the calling
party number.
i)
The subscriber is now connected to his/her voicemail.
Depending on the level on WIN support in both networks, slight modifications to the call
flow may be possible, e.g., delivering the TLDN to the serving MSC rather than involving
the serving network SN in the voice call path.
This service requires both home and serving networks to install compatible Service
Nodes, and to arrange IP connectivity between them. The equivalent service is available
from Starhome for GSM, but there are no current CDMA deployments of the Starhome
SN. Other companies may well offer similar solutions.
4.5 Discussion and Recommendations
As a general principle, roaming services that require a minimum of capability,
configuration and billing support in the serving network are the most likely candidates for
successful deployment. Home operators to whom these services are important have the
desire and influence to carry out the necessary work in their own network.
On the other hand, serving operators are more likely to carry out work in their network if
a good case can be made for a resulting increase in call revenue. Provision of simple (to
the subscriber) voicemail access is a service that will clearly result in more roameroriginated international calls.
Ref Doc. 135, Ver. 1.0
4 December 2006
21
Roaming Voice Mail Deposit, Indicator and Access
Voicemail Access
The ability to accept a short dialed digit string, and convert this to a full international
number as described in §4.4.1 is a requirement for many of the solutions discussed
above. Therefore, the following initial step is suggested:

Recommendation 1: Operators work to enable the access code translation methods
defined above, particularly the FEATREQ and ORREQ ones.
These two methods allow the greatest control by the home network over routing.
Subscribers will hopefully feel that being able to use their familiar access code is a
worthwhile improvement over the status quo, even if they are still required to enter their
mailbox number and PIN.
Use of the “dial own MDN” approach presents additional challenges for the serving
network when the dialed digits are in the national format for the home country.

Recommendation 2: “dial own MDN” is not recommended as a retrieval method,
particularly when preloaded into the handset in a national format. Operators who
already use this approach may seek to implement one of the methods described in
§4.4.1.4
One possible area of subscriber confusion may be the fact that the same digit string that
they dial at home to reach voicemail as a free or cheap call is charged at full
international rates when roaming. This may be mitigated by education/communication.
Once a common access number can be used, the next step is to focus on the subscriber
experience. Some steps may be taken by the home operator in isolation (e.g., triggered
outcall, VMR); others may require negotiation with the serving operator (e.g., service
node installation, or agreeing to use a LD/International carrier that preserves CLI).

Recommendation 3: Operators work to support E.164 MDN, and serving operators
move to ensure reliable CLI delivery for calls from their network to roaming partners
who send an E.164 MDN.
As a long-term solution less vulnerable to changes in international routing, ANSI-41
VMR is recommended:

Recommendation 4: Operators press their MSC/HLR vendors to develop support
for ANSI-41 VMR, triggered either by ORREQ or FEATREQ, including the capability
to set the calling party on the VMS Host MSC → VMS outcall leg (or other means to
directly access the required mailbox).
This feature builds on the earlier access code translation capability, is mostly
standardized, and should closely match the existing subscriber experience while at
home.
Ref Doc. 135, Ver. 1.0
4 December 2006
22
5. Glossary
Acronym
Meaning
CFB
Call Forward Busy
CFNA
Call Forward No Answer
CFU
Call Forward Unconditional
CLI
Calling Line Identity. In this document, used interchangeably with Calling
Party Number
DTMF
Dual Tone Multi Frequency. “In-band” digit signaling
E.164
ITU-T standard “The international public telecommunication numbering
plan”.
FEATREQ
ANSI-41 FeatureRequest operation
HLR
Home Location Register
MC
Message Center. Also known as Short Message Service Center, SMSC
MDN
Mobile Directory Number
MSC
Mobile Service Center
MWN
Message Waiting Notification
ORREQ
ANSI-41 OriginationRequest operation
QUALDIR
ANSI-41 QualificationDirective operation
RSP
Roaming Service Provider
SMDPP
ANSI-41 SMSDeliveryPointToPoint operation
SMPP
Short Message Peer-to-Peer. Common IP-based protocol used to carry
SMS messages.
SN
Service Node
TLDN
Temporary Local Directory Number
VMN
Voice Mail Notification
VMR
Voice Message (or Mail) Retrieval
VMS
Voice Mail System
Ref Doc 135 Ver. 1.0
4 December 2006
23
Roaming Voice Mail Deposit, Indicator and Access
Acronym
Meaning
WIN
Wireless Intelligent Network
Ref Doc 124, Ver. 1.2
1 April 2006
Discussion and Recommendations
24