Survey
* Your assessment is very important for improving the workof artificial intelligence, which forms the content of this project
* Your assessment is very important for improving the workof artificial intelligence, which forms the content of this project
Multiprotocol Label Switching wikipedia , lookup
Airborne Networking wikipedia , lookup
Network tap wikipedia , lookup
Distributed firewall wikipedia , lookup
Serial digital interface wikipedia , lookup
Asynchronous Transfer Mode wikipedia , lookup
Deep packet inspection wikipedia , lookup
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