TR-30/02-01-010
UIT - Secteur de la normalisation des télécommunications
ITU - Telecommunication Standardization Sector
UIT - Sector de Normalización de las Telecomunicaciones
Study Period 2001-2004
Commission d' études 

Study Group
 16
Comisión de Estudio 

Contributi on tardive 

Delayed Contributi on  D.___ (WP 1/16)
Contribuci ón tardía 

Geneva, 5 – 15 February, 2002
Texte disponible seulement en 

Text available only in
 E
Texto disponible solamente en 

Question(s): Q11, Q.2, Q.3, Q.4
SOURCE:
Cisco Systems Inc.
TITLE:
In-band State Event Signaling for MoIP
___________________
Abstract
This contribution describes a proposed set of in-band RTP messages that are proposed to convey
state events for V.MoIP.
* Contact:
Herb Wildfeuer
Cisco Systems
Tel:
+1 805 961 3620
FAX:
+1 804 961 3600
E-mail:
hwildfeu@cisco.com
Attention: This is not an ITU publication made available to the public, but an internal ITU Document intended only for use by the
Member States of the ITU and by its Sector Members and their respective staff and collaborators in their ITU related work. It shall
not be made available to, and used by, any other persons or entities without the prior written consent of the ITU.
TR-30/02-01-010
Table of Contents
1
Introduction ..........................................................................................................................................................3
GOALS OF THIS CONTRIBUTION ........................................................................................ 3
1.1
2
Message Formats..................................................................................................................................................3
2.1
STATE SIGNALING EVENT (SSE) NUMBER ASSIGNMENTS ............................................... 4
2.2
VOLUME AND DURATION FIELDS IN SSES ....................................................................... 4
3
SSE Operations ....................................................................................................................................................4
3.1
SSE/TELEPHONE-EVENT REDUNDANCY............................................................................ 5
3.2
RTP SSRC FOR SSES ...................................................................................................... 5
3.3
IN-BAND TONE TRANSMISSION ......................................................................................... 5
4
Supported Events .................................................................................................................................................6
DECLARATION OF SUPPORTED SSES AT CONNECTION ESTABLISHMENT ......................... 6
EXAMPLE SSE DECLARATION IN SDP ............................................................................. 6
4.1
4.2
5
Event Sequence for a Modem Relay Call ............................................................................................................7
6
References ............................................................................................................................................................8
2
-3-
1 Introduction
This contribution presents a set of RTP encoded state change messages (called SSEs, state
signaling events) that are proposed to be used to co-ordinate mode shifts and convey mode
setting. The functionality of some of these messages is similar to that of type 3 messages in the
AAL2 context (Ref. 2). The format is identical to that of telephone events described in rfc2833
(Ref. 1). When used with rfc2833 telephone events, these state change messages use a different
payload type (PT). Hence, there is no conflict between the event number space for SSEs and the
event number space for telephone-events.
This contribution deals specifically with a minimal subset of SSE messages proposed for
V.MoIP operation.
RFC2833 (Ref. 1) provides a means of representing temporary events such as tones. The events
included in rfc2833 are not suitable for signaling state changes such as from the voice mode to
voiceband data mode or to the modem relay mode. This is because these changes do not map to
tone events one-to-one.
The messages described in this document are distinct from the rfc2833 events. Wherever rfc2833
events do the job, our proposal is to use these. It is possible to use both rfc2833 and SSE’s for a
connection since they have distinct name spaces and are associated with different media formats
(audio/telephone-event vs. SSEs). Areas in which we are proposing the use of SSEs are:
 Requests to shift to one of the following modes: voice mode, voiceband data mode,
modem relay mode, etc
 Positive and negative acknowledgements of such mode shift requests.
1.1 Goals of this contribution
It is the intent of this paper to standardize the use of these proposed SSE messages for V.MoIP as
well as in other forums. This standardization is being coordinated with the activity involving the
proposed Annex P of H.323, where a more expansive set of SSE messages will be proposed.
We propose that the V.MoIP related SSE messages discussed in this contribution be included as
an Annex in V.MoIP.
2 Message Formats
The message format of the SSEs is identical to that of standard telephone-events. See rfc2833
(Ref. 1) for a discussion.

Named Telephone Events (NTE) per RFC 2833
0
1
2
3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
event
|E|R| volume
|
duration
|
|
| | |
|
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Payload Format for Named Telephone Events
Mode Setting Messages for MoIP
3
-4However, not all fields (e.g. volume and duration) are useful for the purpose of the SSEs
described in this contribution..
2.1 State Signaling Event (SSE) Number Assignments
Theoretically, events associated with the SSEs can be assigned event numbers in the range 0255. For maximal distinction from RFC 2833 events, the SSEs are proposed to use different
event numbers as much as possible, i.e. in the range 192-255. It is preferable not to use the range
0-191.
Table 1 is the list of relevant SSEs we are proposing for the V.MoIP application:
Event # of Custom
SSE (decimal)
Definition
AAL2 Type
3
Message
Equivalent
CONSEQUENT
ACTIONS ON
MESSAGE
RECEIPT
192
"vbd mode"
User state = VBD
Up-speed by receiving node
and CAC check initiation.
194
"Voice mode"
Service State
change to
voiceband data.
Service State change
to voice.
User state = voice
203
"Modem Relay Switch"
Request a switch to
modem relay
Not applicable
Down-speed or
Cancellation of pending upspeed by receiving node.
Switch to modem relay
Table 1: V.MoIP SSEs
Note that the “Voice mode” SSE (event code 194) may be used to NAK the “vbd mode” SSE
(event code 192).
Additional SSE’s will be defined and standardized elsewhere (e.g. in IETF). These will address
other state change events.
2.2 Volume and Duration Fields in SSEs
The state change signaling SSE’s listed in Table 1 have no need of volume/duration fields, which
will be set to 0 by sender and ignored by receiver. This is because these refer to state change
messages rather than to tones that have a specified duration.
3 SSE Operations
In this proposal, Modem Relay applications that have negotiated support of VBD during call setup capability exchange will up-speed to VBD as soon as possible (within 50 msec) on detecting a
2100 Hz tone. An ups-peed SSE (event code192) will be sent to the other end immediately. The
VBD mode will be exited if:
1. the other end NACKs using the “voice mode” SSE (event code 194)
2. a mode shift to modem relay occurs
Mode Setting Messages for MoIP
4
-5As a result, an "up-speeded channel" is available that allows the detection of 2100 Hz phase
reversals on the packet side. Depending on the level of integration provided, this takes ~450 ms
(one phase reversal) or ~900 ms (two phase reversals).
Please reference an associated contribution by Cisco Systems to this TR30.1 meeting outlining
call flows, which gives examples of the use of the SSEs proposed in this contribution.
3.1 SSE/telephone-event redundancy
Redundant transmission of SSEs is supported. The number of transmissions proposed for the
V.MoIP SSE’s proposed here is provisionable per Table 2 below. There is no need to
synchronize the parameter of redundant transmission between originating and terminating
gateways since this is not receiver-dependent.
When simple packet retransmission is used, the retransmitted events have the same time-stamp.
When an event message with the same timestamp is transmitted multiple times, a receiver can act
on the first correct message it receives; it does not need to wait for the rest.
SSEs, in general, indicate state changes. These are sent, by default, as triply redundant copies
with the same time stamp. These copies are sent at 20 ms intervals. No refresh is necessary. The
rather large upper bound on the provisionable number of transmissions (50) is for lossy packet
networks.
V.MoIP SSEs
State change (192, 194, 203)
Time (ms)
between repeats
(if any)
Default: 20 ms
Number of
transmissions (1- 50) of
same timestamp
Default: 3
Range: 1-50
Table 2: Default values of provisionable parameters for V.MoIP SSE redundancy
3.2 RTP SSRC for SSEs
V.MoIP SSEs should have the same SSRC as the audio stream. This is recommended, and not
mandatory.
3.3 In-band tone transmission
There is no squelching of the audio channel in relation to the V.MoIP state change control SSEs
in Table 1, i.e.: 192 (vbd mode), 194 (voice mode), and 203 (Switch to modem relay). These are
not tone representations so squelching does not apply.
Mode Setting Messages for MoIP
5
-6-
4 Supported Events
SSEs and telephone-events have the same RTP packet format. Also, they use non-overlapping
event numbers. Further, they are assigned different codec names ("SSE" or "X-SSE") and
"telephone-event" in order to minimize the possibility of future overlap of event numbers.
It is proposed that implementations use a dynamic payload type for SSEs. Further, this payload
type is included in the final set of payload types that are bound to a VoIP connection.
The list of supported SSE events shall be explicitly declared by all parties in a VoIP connection
at the time of connection establishment. For V.MoIP, this contribution identifies the minimal set
of those SSE’s per Table 1.
Note that using different codec names (and dynamic payload types) for standard events (rfc2833
telephone-event) and SSEs makes the event definitions immune to extensions to the list of
standard events, as might ensue in successors to rfc2823. Thus, it does not matter if, in the future,
the IETF defines events 192, 194 and 203 in a manner different from this document.
4.1 Declaration of Supported SSEs at Connection Establishment
The support of SSE event codecs and the enumeration of individual events are to be negotiated at
the time of connection establishment. To achieve this, SSE event codecs and the enumerated list
of supported SSEs need to be declared in the various device control and session control
protocols.
4.2 Example SSE Declaration in SDP
This section gives an example of SSE related declarations in SDP.
With MGCP, SSE’s would be declared in the L:a (codec list) local connection option. With
H.323, the declaration of rfc2833 telephone-events is an integral part of the H.245 specification,
and the declaration of SSEs would be done in a similar manner.
As pointed to out earlier in this contribution, although SSEs and rfc2833 telephone-events have
the same RTP packet format, they shall be assigned different payload types so that their event
number spaces do not overlap.
In SDP (RFC 2327; Ref 6), event codecs are assigned dynamic payload types through the
‘rtpmap’ attribute. Further, the fmtp attribute is used to list the events supported for each event
codec.
The following SDP lines illustrate the binding of the rfc 2833 telephone-events, and SSEs to
dynamic payload types, and the exact delineation of events associated with each event codec.
m=audio 3456 RTP/AVP 0 2 96 98
a=rtpmap:96 telephone-event/8000
a=fmtp:96 0-15,66, 70
a=rtpmap:98 X-SSE/8000
a=fmtp:98 192,194,203
Mode Setting Messages for MoIP
6
-7In this example, the support of PCM u-law and G.726-32 is declared using fixed RTP payload
types of 0 and 2 per RFC 1890. In addition, the possible event codecs proposed for the
connection are rfc2833 telephone-events and X-SSE. The events proposed for each of these
codecs are:


telephone-event: DTMF (0-15), dial tone (66), ringing (i.e. ringback) tone (70)
X-SSE:
(203)
voiceband data mode (192), voice mode (194), and modem relay mode
If rfc2198-based redundancy is to be used, the pseudo-codec "red" (which denotes rfc2198
redundancy) shall be declared in the manner described in rfc2198, Ref 7 (Section 5).
5 Event Sequence for a Modem Relay Call
The main point of this contribution is that switchover to modem relay is signaled using in-band
RTP SSE packets, and not via the out-of band signaling protocol that is used to setup and
teardown the call.
Please reference an associated contribution by Cisco Systems to this TR30.1 meeting outlining
call flows, which gives examples of the use of the SSEs proposed in this contribution.
The state transition diagram illustrated below depicts the use of SSEs to coordinate mode shifts
and convey mode setting for V.MoIP. The pre-assumption is that the call is setup as a normal
voice call, using a supported signaling protocol - H.323, SIP, etc. The state transition are labeled
with example reasons as to why a certain transition may occur. An exhaustive list of the causes
of state transition are beyond the scope of this document.
Mode Setting Messages for MoIP
7
-8-
Reason: e.g. ANS detection, etc….
Action: send SSE 192
VoIP
VBD
Reason: e.g. end of fax/modem, etc…
Action: send SSE 194
Reason: e.g. agreed to
MR but can’t do it..
Action: send SSE 192
Reason: e.g. terminate
MR, return to VoIP
Action: send SSE 194
Terminate
Call
Reason: e.g. starting MR
Action: send SSE 203
Reason: e.g. CM detection
Action: send SSE 203
MR
Figure 1: V.MoIP State Transition Diagram coordinated using in-band SSEs
6 References
1. IETF RFC 2833, RTP Payload for DTMF Digits, Telephony Tones and Telephony
Signals
2. ITU-T I.366.2, AAL Type 2 Reassembly Service Specific Convergence Sublayer for
Trunking, Feb. 99.
3. IETF RFC 2198, RTP Payload for Redundant Audio Data.
4. IETF RFC 1889, ‘RTP: A Transport Protocol for Real-Time Applications’, Jan. 1996.
5. IETF RFC 1890, ‘RTP Profile for Audio and Video Conferences with Minimal Control’,
Jan. 1996.
6. IETF RFC 2327, SDP: Session Description Protocol
7. IETF RFC 2198, RTP Payload for Redundant Audio Data, C. Perkins et al.
8. IANA registration, http://www.isi.edu/in-notes/iana/assignments/mediatypes/audio/vnd.cisco.nse
Mode Setting Messages for MoIP
8