Download Mechanism for transitioning into and out of VBD mode

ITU - Telecommunications Standardization Sector
Q1109-nnn
Study Group 16 – Question
11
Location: Arlington VA, USA. 30th September – 2nd October 2003
Source:
Nortel Networks
Title:
Mechanism for transitioning into and out of VBD mode
Contact:
Dominic Walker
Nortel Networks
United Kingdom
Tel: +44 (0)1279 403379
Fax: +44 (0)1279 402555
Email:
[email protected]
ABSTRACT
This contribution proposes a mechanism for implementations that comply with v.VBD and that
have indicated support of VBD to autonomously transition into and out of VBD operation. This
contribution does not preclude the gateways from using other mechanisms such as RFC2833,
T.38, V.150.1 and/or Text Relay, for transporting non-voice signals. This contribution assumes
that RTP shall be used for the transport of VBD. It is based on the outcome of the last meeting in
Dallas (July 2003).
Attention: This is not a publication made available to the public, but an internal ITU-T Document intended only for use by the
Member States of the ITU, by ITU-T Sector Members and Associates, 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-T.
Introduction
Negotiation of support of VBD data mode as defined in V.VBD is carried out at call
establishment, during the initial exchange of the call capabilities of the endpoints establishing the
call. Indication of such support entails assigning RTP payload types to VBD as well as the
codecs. The mechanisms for negotiation vary depending on the call capabilities exchange
protocols used, which can be Session Description Protocol (defined in RFC 2327) or H.245 and
the call control protocol such as, but not limited to H.248, H.323 or SIP. This contribution will
assume that SDP was used to negotiate support of VBD .
1 Gateways that only support Voice and Voice Band Data mode as
per v.VBD
This section describes the transitioning mechanism for an implementation that only supports
VBD as per v.VBD and Voice, but does not support any relay mechanisms such as RFC2833,
T.38 or V.150.1, nor VBD as per V.150.1.
This mechanism shall be the default mechanism used by v.VBD gateways if no other
mechanisms have been successfully negotiated between the gateways, otherwise the mutually
negotiated mechanism shall be used in preference to VBD (such as those described in section 2
and 3 below).
The transition from voice state to VBD state is performed when the VBD detectors classify an
input signal as VBD.
Detection shall be carried out at least in the direction from the PSTN to the IP network.
Once VBD has been mutually negotiated by the two gateways using the procedures described in
contribution number Q1109-031, a gateway that complies with this contribution shall be able to
receive and appropriately decode, from the IP network, RTP packets with any of the supported
negotiated payload types for a particular call. And, hence a v.VBD implementation shall
transition from Voice to VBD on receipt of a RTP packet that has the negotiated VBD payload
type.
Thus on detection, in the direction from the PSTN to IP network of the appropriate VBD signals,
will cause a v.VBD implementation to transition to VBD and transmit RTP packets with the
corresponding negotiated VBD payload type. Reception of an RTP packet with the VBD payload
type at the remote end shall be sufficient criteria to transition to VBD mode, but only if prior to
receiving the VBD RTP packet it received Voice RTP packets. The reason for the latter rule is
the explained in the following example:
Lets consider two V.VBD implementations termed A and B connected via an IP network and
each have a PSTN network on their other sides. There will be a case during a call when both
V.VBD implementations are in VBD mode. Implementation A transitions into Voice state due to
detection of VBD signals in the direction from the PSTN to the IP network, which will cause it
to transition into Voice and transmit Voice RTP packets. However, while the first transmitted
Voice RTP packet is traversing the IP network, the remote end (implementation B) is still
transmitting VBD RTP packets, because hasn’t detected anything on its PSTN side, nor has it yet
received the Voice RTP packets. To avoid implementation A from transitioning erroneously
2
back into VBD state, it must not transition back to VBD until it has first received (the prenegotiated) Voice RTP packets, which it should expect to receive due to it (i.e. implementation
A) transitioning into voice. N.B.: An implementation should be able to handle out of order RTP
packets (e.g. a Voice packet followed by a VBD packet that was actually sent before the Voice
packet).
Transition from VBD to Voice shall be carried out by the following mechanisms:

In the direction from the PSTN to IP network:
o Detection of end of modem or facsimile signals or
o detection of voice signals or
o detection of silence period greater than n ms (note for the editor: this timer would
need to be determined if required).

In the direction from IP to PSTN network:
o Receipt of RTP packets that have non-VBD payload types only after the first
VBD RTP packet has been received. This will avoid the case where an
implementation from erroneously transitioning back into Voice state when it has
transitioned to VBD state on detection VBD signals on its TDM side and is still
receiving Voice RTP packets (because the remote end has not yet transitioned
based on reception of the VBD RTP packets).
o detection of silence period greater than n ms (note for the editor: this timer would
need to be determined if required).
The above described transition criteria are also summarized in Figure 1.
Detection VBD signals
VBD RTP packet &
previous RTP packets were
Voice RTP packets
VOICE
State
Bidirectional silence
VBD
State
TDM Voice TDM endof-modem signal
Voice RTP packets & previous
RTP packets were VBD RTP
packets
Figure 1: Voice-VBD Transitioning state diagram
3
2 Gateways that support SSEs as per V.150.1
The requirements in this Section apply to the case where the capabilities that are associated with
a session as a result of negotiation include VBD and support of SSEs as defined in V.150.1 but
do not include modem relay nor T.38. In this case, a media gateway SHALL respond to a Voice
Band Data stimulus (such as an answer tone), detected in the direction form the PSTN to IP
Network, by immediately transitioning the connection to the VBD mode and issuing an SSE
indicating this state (Clause C.5.2 of Recommendation V.150.1). A gateway that receives and
SSE indicating VBD shall operate as described in V.150.1.
When transitioning out of VBD state, it is recommended to use the Th timer, described in section
1, as the hold time before re-activating the detection criteria for transitioning back into VBD.
Note that when using SSEs in conjunction with H.248, if support of VBD was mutually
negotiated at the beginning of the call, receipt of an SSE to transition into VBD cannot be
NACKed by an MG, because this will go against H.248 where resources are reserved and
committed at the beginning of the call.
3 Gateways that support Telephone Events as per RFC2833.
Gateways that support have previously negotiated support of RFC 2833 telephone events, may
use receipt of the appropriate RTP RFC2833 event packets as the criteria for transitioning from
Voice to VBD.
Transition from VBD to Voice shall be performed using the mechanism described in section 1.
4