IETF MEGACO Working Group Albrecht Schwarz Internet Draft draft-schwarz-megaco-relay-services-01.txt Alcatel Expires: November 2003 May 2003 Voiceband Data Transport Services in MEGACO/H.248 Networks Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC 2026 [1]. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet- Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Abstract This document describes the terminology and gives a network model for different strategies concerning Voiceband Data (VBD) transport services. The purpose of this effort is to set the reference space for describing and evaluating Megaco/H.248 signaling procedures. Primary scope are voiceband data services, typically inherent part in voice-over-packet networks (e.g., like Internet Telephony). Motivation: VBD calls typically start out as a voice call. The modems on the VBD devices at the Termination detect the switch to VBD (like facsimile) and fax modem or data modem transmission begins. With the development of Voice over IP, many CODECs have been developed which are optimized for the transmission and reception of voice. In creating these CODECs, VBD transport may not reliably be used over the same transmission channel. In an effort to optimize the transmission of VBD, specialized protocols (e.g., T.38, or V.150) have been developed to provide a more reliable transport, minimize bandwidth usage, etc. Schwarz Work-in-Progress - May 2003 [Page 1] Voiceband Data in Megaco/H.248 Networks May 2003 Conventions used in this document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [2]. Table of Contents 1. Definitions 2 1.1 Gateway & Terminal Types 2 1.2 Packet Network Transport Services 3 1.3 States of MCUs and GWs 4 1.4 Abbreviations 4 2. Motivation and Problem Definition 5 3. Architecture Overview 9 3.1 Network Reference Model 9 3.2 Major States of a Media Gateway 11 4. Gateway Capability Sets 15 4.1 Introduction 15 4.2 Voice-oriented Media Gateways 15 4.3 VBD-only Media Gateways 16 4.4 Voice & Data Media Gateways 16 5. Scope of this Document 16 6. Service Control - Network Strategies 17 6.1 Overall Service Control Aspects 17 6.2 Principle Decision Levels for Service Changes 17 6.3 STRICT Control (by CA & MGC) 19 6.4 AUTONOMOUS Control (by MG) 19 6.5 AUTOMATIC Control (by MCU) 19 7. Interworking Considerations 19 8. Operational & Functional Goals 20 9. Security Considerations 20 10. References 20 Acknowledgments 21 Author's Addresses 21 1. Definitions For the purpose of this document, the following definitions shall apply. 1.1 Gateway & Terminal Types Access Gateway: A type of gateway that provides a User to Network Interface (UNI) such as ISDN BRI/PRI. Schwarz Work-in-Progress - May 2003 [Page 2] Voiceband Data in Megaco/H.248 Networks May 2003 Gateway: A gateway converts media provided in one type of network to the format required in another type of network. For example, a gateway could terminate bearer channels from a Switched Circuit Network (e.g., DS0s) and media streams from a packet network (e.g., RTP streams in an IP network). On-Ramp Gateway: The access point that is called by an originating DCE that interfaces to the IP network. (Abbreviated to MG1) Off-Ramp Gateway: The IP network access point that calls an Answering DCE. (Abbreviated to MG2) Emitting Gateway: The access point that is called by a sending fax equipment (e.g., G3FE) that interfaces to the IP network. (Abbreviated to MG1) Receiving Gateway: The access point that is called by a receiving fax equipment that interfaces to the IP network. (Abbreviated to MG2) Network Access Server (NAS): A gateway that provides access to an IP- based data network. In some cases also known as a RAS, Remote Access Server. Universal Gateway: MG supporting VoIP as well as DoIP (= NAS) functions. Teletype (TTY): A term used by the deaf and hard of hearing for a device which incorporates a FSK (Frequency Shift Keying) modem. This term originates with the electromagnetic Teletypewriters originally used for this communications. 1.2 Packet Network Transport Services The prime `transport services' for Voiceband Data (considered in this document) are derived from TERMINAL types used in traditional SCNs, e.g., - FAX MODEM (e.g., Group 3 Fax Equipment), - DATA MODEM (e.g., Computer with V-series Digital Circuit Equipment), - TEXT MODEM, - others Note:see also [3] respectively the phrase "traditional facsimile". 1.2.1 PASS-THROUGH Service See section 2. Schwarz Work-in-Progress - May 2003 [Page 3] Voiceband Data in Megaco/H.248 Networks May 2003 1.2.2 RELAY Services CAS Relay: The transportation of Channel Associated Signalling Bits across a packet network using specific packet formats in the packet-switched network transport domain. Dialled Digits Relay: The transportation of multifrequency audio tones (e.g., DTMF) across a packet network using specific packet formats (e.g., RFC 2833 encoded [4] for IP networks) in the packet-switched network transport domain. Fax Relay: The transportation of fax modem traffic across a packet network using fax demodulation/remodulation techniques at the network access points (e.g., T.38 [7] for IP networks). Modem Relay: The transportation of data modem traffic across a packet network using modem termination at the network access points (e.g., V.150 [8] for IP networks). Text Relay: The transportation of text modem traffic across a packet network using modem termination at the network access points. Tone Relay: The transportation of general audio tones (e.g., telephony tones and telephony signals) across a packet network using specific packet formats (e.g., RFC 2833 for IP networks) in the packet- switched network transport domain. 1.3 States of MCUs and GWs See subsection 3.2. 1.4 Abbreviations ASIC Application Specific Integrated Circuit ATM Asynchronous Transfer Mode BRI Basic Rate Interface (ISDN) C2P Circuit-to-Packet (direction) CA Call Agent CAS Channel Associated Signalling CS Capability Set CMD Circuit Mode Data DCE Data Circuit-terminating Equipment (Modem) Data Communication Equipment DoVoIP Data over VoIP DSP Digital Signal Processor Digital Speech Processor (North America) DTE Data Terminal Equipment Schwarz Work-in-Progress - May 2003 [Page 4] Voiceband Data in Megaco/H.248 Networks May 2003 DTMF Dual Tone Multi-Frequency E-MG Emitting Media Gateway EC Echo Canceller FAS Facility Associated Signalling ffs for further study FMD Frame Mode Data FR Fax Relay G3FE Group 3 Fax Equipment GCP Gateway Control Protocol (e.g., H.248 [5]) GW GateWay IP Internet Protocol ISUP ISDN User Part IVR Interactive Voice Response MCU Media Conversion Unit (e.g., DSP channel, Encoder) MG Media Gateway (= via Megaco/H.248 controlled GW) MGC Media Gateway Controller MMF Media Mapping Function MMSF Media Mapping and Switching Function MR Modem Relay NAS Network Access Server NFAS Non-Facility Associated Signalling P2C Packet-to-Circuit (direction) PLMN Public Land Mobile Network PMD Packet Mode Data PRI Primary Rate Interface (ISDN) PSTN Public Switched Telephone Network QoS Quality of Service R-MG Receiving Media Gateway RTP Real-time Transport Protocol SCN Switched Circuit Network SPRT Simple Packet Relay Transport SSE State Signalling Event TR Text Relay UDI Unrestricted Digital Information UDP User Datagram Protocol UDPTL Facsimile UDP Transport Layer protocol (T.38 [7]) VBD Voiceband Data VBDoIP Voiceband Data over IP Vc Voice 'compressed' VoIP Voice over Internet Protocol Vu Voice 'uncompressed' 2. Motivation and Problem Definition Voice-over-Internet Protocol (VoIP) networks must support interworking with SCNs (e.g., PSTN, N-ISDN, 2G-PLMN) and traditional terminal types. Initial and prime scope are voice oriented terminals and services (e.g., speech telephony), but also data terminals using voice based transport. Schwarz Work-in-Progress - May 2003 [Page 5] Voiceband Data in Megaco/H.248 Networks May 2003 This is leading to Data-over-Voice (DoV) transport in the SCN, as well as a consequence then in the IP domain (= DoVoIP), too. A dedicated subset of data services, - and primary scope of this document -, shall be summarized under the umbrella of "Voiceband Data" (VBD). This subset of data services is reusing the voice frequency band (= telephony band or voiceband). This is leading to the requirement that a VoIP network and a VoIP gateway MUST support at least: - VoIP, and - VBDoIP. The term 'DoIP' shall further denote the gateway capability of a Network Access Server (NAS). Generally there are two basic models suitable for VBD transport in an IP network: (1) VBD over VoIP ("the VoIP bearer connection with a suitable 'voice configuration'"; abbreviated as VBDoVoIP), or (2) VBD over a data-capable IP transport (shall abbreviated as VBDoDoIP) The first class of operation shall be called "Pass-Through" service (also called "Pseudo Transparent" service) and the second one "Relay" service. Such a transport service differentiation does make sense for inband signaling traffic, too, e.g., like DTMF, CAS bits, general tones or telephony signals. The rationale behind is primarily related to the IP network characteristics, architecture, and intended usage: (1) "PASS-THROUGH transport services" are used for applications - upon networks with a high and guaranteed Quality of Service, - there is no constraint on the available IP bandwidth, - where performance of modulation is robust enough (in case of modem traffic), - well managed and controllable IP networks (Intranets, private IP based networks), - or other reasons. (2) "RELAY transport services" are designed for, respectively providing, - public IP networks (Internet), - IP networks in general that have such impairments as packet loss and jitter, - reduced IP network bandwidth (hence reduced cost to service providers), - enhanced transport (e.g., support of bandwidth control [8]), - increased reliability of VBD connections, compared to pass-through services, Schwarz Work-in-Progress - May 2003 [Page 6] Voiceband Data in Megaco/H.248 Networks May 2003 - increased interworking between some modems, - increased link speed in some modem connections, - others. Table 1 provides a summary from gateway perspective. Considered are the major traffic classes and corresponding transport options. Table 1 is showing only a small set of exemplary services, by far no exhaustive list. The functional block 'Media Conversion Unit' (MCU) within a gateway, as well as the numerous MCU operation modes, will be introduced in the next section. Schwarz Work-in-Progress - May 2003 [Page 7] Voiceband Data in Megaco/H.248 Networks May 2003 +----------------------------------------------------------------------+ | SCN | IP TRANSPORT Domain |Gateway:| | TRAFFIC |-------------------------------------------| MCU | | Type (Examples) | Mode |Protocol Layering (e.g.)| Abbrev.|Y/N|Mode| +=================+=========+========================+========+===+====+ |VOICE (V) | | | | | | | Speech Telephony|uncompre.| G.711oRTP/UDP/IP | VoIP | Y |Vu | | |compress.| G.723.1oRTP/UDP/IP | VoIP | Y |Vc | | Audio (ffs) | | | | | | +-----------------+---------+------------------------+--------+---+----+ |VOICEBAND DATA (VBD) | | | | | | Fax Modem |pass-thr.| FoG.711oRTP/UDP/IP | VBDoIP | Y |VBD | | |relay | FoT.38oUDPTL/UDP/IP | FoIP | Y |FR | | Data Modem |pass-thr.| DoG.711oRTP/UDP/IP | VBDoIP | Y |VBD | | |relay | MoV.150oSPRT/UDP/IP | MoIP | Y |MR | | Text Modem |pass-thr.| ToG.711oRTP/UDP/IP | VBDoIP | Y |VBD | | |relay | ToV.150oSPRT/UDP/IP | ToIP | Y |TR | | Others (ffs) | | | | | | +-----------------+---------+------------------------+--------+---+----+ |Inband SIGNALING | | | | | | |& Telephony Sign.| | | | | | | CAS (Bits) |pass-thr.| CASoG.711oRTP/UDP/IP | VoIP | Y |V | | |relay | CASoRFC2833/RTP/UDP/IP | CASoIP | Y |CAS | | DTMF, MF |pass-thr.| DTMFoG.711oRTP/UDP/IP | VoIP | Y |V | | |relay |DTMFoRFC2833/RTP/UDP/IP |DTMFoIP | Y |DTMF| | Tones (general) |pass-thr.| TONEoG.711oRTP/UDP/IP | VoIP | Y |V | | |relay |TONEoRFC2833/RTP/UDP/IP |TONEoIP | Y |TONE| | Others (ffs) | | | | | | +-----------------+---------+------------------------+--------+---+----+ |CIRCUIT Mode DATA (CMD) | | | | | | I.231.1 (UDI) |pass-thr.| H.221oG.711oRTP/UDP/IP | VoIP | Y |V | | |clear ch.| {1x64-kbps}oRTP/UDP/IP | CMDoIP | Y |CMD | | Others (ffs) | | | | | | +-----------------+---------+------------------------+--------+---+----+ |PACKET Mode DATA (PMD) | | | | | | IPoPPP/HDLC |native | IP | DoIP | Y |PMD | | Others (ffs) | | | | | | +-----------------+---------+------------------------+--------+---+----+ |FRAME Mode DATA (FMD) | | | | | | Q.921 (LAPD) | | | | N |-- | | MTP2 | | | | N |-- | | V5.2 | | | | N |-- | | Others (ffs) | | | | | | +-----------------+---------+------------------------+--------+---+----+ Table 1: Universal Gateway - Principle Operation Modes (Overview) Schwarz Work-in-Progress - May 2003 [Page 8] Voiceband Data in Megaco/H.248 Networks May 2003 3. Architecture Overview 3.1 Network Reference Model Figure 1 below is showing the assumed network reference model, using Megaco/H.248 [15, 5] as Gateway Control Protocol (GCP). CA1 CA2 e.g. +----------+ CA-to-CA Signaling +----------+ e.g. ----SS7--->| |<----------------------->| |<----SS7-- | +------+ | | +------+ | | | MGC1 | | | | MGC2 | | | +------+ | | +------+ | | ^ | | ^ | +-----|----+ +-----|----+ | | | | | CONTROL Domain | - - | - - - - - - - - - - - - - - - - - | - - | TRANSPORT Domain | H.248 | | | MG1 v MG2 v +------------------+ +------------------+ | B-IWF | | B-IWF | | +--------------+ | | +--------------+ | | | MCU | | | | MCU | | | | +--------+ | | | | +--------+ | | ----->-+-+-*| C2P -> |*-+-+-->------------->-+-+-*| C2P -> |*-+-+-->-- DS0 | | |--------| | | IP flow | | |--------| | | DS0 -----<-+-+-*| P2C <- |*-+-+--<-------------<-+-+-*| P2C <- |*-+-+--<-- | | +--------+ | | e.g.: | | +--------+ | | | +--------------+ | RTP audio stream,| +--------------+ | +------------------+ T38 UDPTL stream +------------------+ - - SCN - - - ->|<- - - - - - IP Network - - - - - ->|<- - - SCN - - Figure 1: Reference Network Architecture +----------------+ +----------------+ | Context `MG1' | | Context `MG2' | | +--+ +--+ | | +--+ +--+ | --------+->|T1| |T2|<-+--------------------+->|T3| |T4|<-+------ DS0 | +--+ +--+ | IP | +--+ +--+ | DS0 +----------------+ +----------------+ Figure 2: Corresponding Megaco/H.248 Context Model Schwarz Work-in-Progress - May 2003 [Page 9] Voiceband Data in Megaco/H.248 Networks May 2003 The packet-oriented IP network shall be vertically separated in - a CONTROL Domain (hosting the MGC function), and - a TRANSPORT Domain with the MGs. Note: A potential SERVICE or APPLICATION Domain, on top of the Control Domain, is beyond the scope of this document. The Media Gateway Controller (MGC) is characteristically a subfunction within a Call Agent (CA). The CA is synonymously often denoted as Call Connection Agent (CCA), Call Server (CLS), Call Serving Node (CSN), Softswitch (SX), or others. Note: The MGC may also be located in an H.323 [6] Gatekeeper (GK), or integrated in a narrowband switching system. Figure 1 is showing the general case with multiple Call Agents in a single Control Domain. The CA-to-CA signaling protocol is beyond the scope of this document. The originating MG and terminating MG shall be denoted as MG1 respectively MG2. For instance, MG1 is providing the Emitting GW function (E-MG) in case of T.38 [7], or the On-Ramp GW in case of V.150 [8]. MG2 is corresponding to the Receiving GW function (R-MG), or the Off-Ramp GW in case of V.150 ditto. The scope of this document are Megaco/H.248 procedures at the MGC-MG interface. But due to the different handling possibilities of VBD services by the Transport Domain, the MG system architecture shall be briefly considered. The primary functional block of a MG shall be denoted as Bearer Interworking Function (B-IWF). The B-IWF is housing so- called Media Conversion Units (MCU), the responsible (physical) entity for Voice, Voiceband Data, etc. processing. Note: The MCU function might be physically realized by an Encoder/Decoder chip, DSP, Protocol Processor, ASIC, etc. Additionally the two communication directions shall be differentiated: - Circuit-to-Packet (C2P) direction, and - Packet-to-Circuit (P2C) direction The underlying motivation is that both directions, - MCU_C2P and MCU_P2C -, may be generally working in different operation modes or states (see following subsection). Figure 2 is illustrating the corresponding Megaco/H.248 Context model. Schwarz Work-in-Progress - May 2003 [Page 10] Voiceband Data in Megaco/H.248 Networks May 2003 3.1.1 Relay of Inband Signalling and Telephony Signals It has to be noted that there are two principal relay directions (from MG point of view), dependent where this type of traffic (e.g., CAS, DTMF) is finally originating/terminating: - PACKET RELAY to peer MG (horizontal interface), and - H.248 RELAY to associated MGC (vertical interface) 3.2 Major States of a Media Gateway 3.2.1 State Machines An MCU generally supports a couple of different media conversion functions. A specific set of such functions shall be denoted as operation mode, or briefly as mode. The Megaco/H.248 Context is specifying and describing properties and media attributes, required for a dedicated call, respectively network service. There are principally different transport options for a bearer connection in the IP Transport Domain (see subsection 1.2). Such a specific transport option is corresponding to a specific MCU operation mode. A set of operation modes shall be abstracted by a state model, reflecting meaningful combinations for dedicated call services. The state of a bearer connection may be changed several times during the lifetime of a call. (Example, a PSTN speech telephony terminal with integrated fax equipment, allowing generally a call scenario, e.g., with speech-fax-speech phasing.) For two party call configurations, there are generally following four STATE MACHINES associated with a specific (IP) bearer connection: - MG1_MCU_C2P, - MG1_MCU_P2C, - MG2_MCU_C2P, - MG2_MCU_P2C There are many services where both directions are always in the same state, i.e., in which cases both state machines, associated with the same MG (MG1 or MG2), may be considered as synchronized within a MG. In these cases may a single state machine (per MG_MCU) be considered. [Note: briefly noted as "MG is in state `xyz'".] Schwarz Work-in-Progress - May 2003 [Page 11] Voiceband Data in Megaco/H.248 Networks May 2003 3.2.2 State Diagram Figure 3 is showing the overall MCU state diagram. +------+ | Idle | Note 1: Decision by CA on +------+ Basis of Call/Session | Control Information | (1) ----------------------------------------------- | | | | | | | | v v v v +-------------------------------------+ +--------+ +-------+ +- - - + | Voice & Voiceband Data | | Circuit| | Packet| | Frame| | | | Mode | | Mode | | Mode| | ##################### | | Data | | Data | | Data| | # V (Voice) # | | | | | | | | # # | | | | | | | | # ****** ****** # | | | | | | | | # * Vu * * Vc * # | | | | | | | | # ****** ****** # | | *******| | ******| | *****| | # # | | * CMD *| | * PMD*| | *FMD*| | ##################### | | *******| | ******| | *****| | / \ | | | | | | | | / \ | | | | | | | | ############### ################## | | | | | | | | # VBD "Pass- # # VBD "Relay" # | | | | | | | | # Through" # # # | | | | | | | | # # # ****** # | | | | | | | | # # # * FR * # | | | | | | | | # ******* # # ****** # | | | | | | | | # * VBD * #--# / \ # | | | | | | | | # ******* # # ****** ****** # | | | | | | | | # # # * MR *--* TR * # | | | | | | | | # # # ****** ****** # | | | | | | | | # # # # | | | | | | | | ############### ################## | | | | | | | | | | | | | | | +-------------------------------------+ +--------+ +-------+ +- - - + | | | | | | | | ----------------------------------------------- | v +------+ | Idle | +------+ Figure 3: Media Gateway - Principle MCU Operation Modes (States) Schwarz Work-in-Progress - May 2003 [Page 12] Voiceband Data in Megaco/H.248 Networks May 2003 State diagram conventions used in Figure 3: Line Type | Level | Meaning -----------+-------+------------------------------------------------- --- | 1 | operation mode is already distinguishable and | | controllable on basis of call/session control | | information -----------+-------+------------------------------------------------- ### | 2 | principle operation modes for voiceband voice | | and voiceband data (V & VBD) -----------+-------+------------------------------------------------- *** | 3 | major MCU operation modes (= MAJOR STATES) | | -----------+-------+------------------------------------------------- Note 1: There is a next meaningful level 4 ("sub-states"), see for instance [8]. Note 2: Handling of inband signaling and telephony signals by MCUs is in general a parallel function and associated to the outlined operation modes. They are therefore omitted in Figure 3. 3.2.3 State Description At any given time, each direction of the MG MCU and the packet bearer connection is in exactly one state. The several MCU modes are briefly elaborated (based on [8, 9]): * VOICE (states Vu and Vc): - audio received by the MG1_MCU is encoded for transmission and transmitted through the packet network to the decoder (MG2_MCU) using CODECs appropriate for speech but not necessarily appropriate for data modem or facsimile modulations; - additional codings such as RFC 2833 for comfort noise, DTMF digits, telephony signals, etc. may also optionally be used; - packets containing coded audio received by the MG2_MCU are decoded to audio and played out; and - processing of the audio appropriate to speech, such as echo cancellation, DC removal, dynamic range reduction, latency adjustment, etc. may be performed by either the MG1_MCU or the MG2_MCU or both. * VOICEBAND DATA (VBD "Pass-Through"): - audio received by the MG1_MCU is encoded for transmission and transmitted through the packet network to the MG2_MCU using CODECs appropriate for data modem and facsimile modulations (e.g., G.711 or high bitrate G.726); - additional codings such as RFC 2833 for comfort noise, DTMF digits, Schwarz Work-in-Progress - May 2003 [Page 13] Voiceband Data in Megaco/H.248 Networks May 2003 telephony signals, etc. may also optionally be used; - packets containing coded audio received by the MG2_MCU are decoded to audio and played out; and - processing of the audio inappropriate to data modem and facsimile modulations, such as echo cancellation, DC removal, dynamic range reduction, latency adjustment, etc. must not be performed by either the MG1_MCU or the MG2_MCU or both. Note: VBD mode is also often called "PSEUDO TRANSPARENT MODE" * FACSIMILE RELAY: - audio received by the MG1_MCU is demodulated using facsimile modulation and protocol specifications, and facsimile images extracted from the audio are transmitted to the MG2_MCU using the T.38 protocol; and - packets containing facsimile images received by the MG2_MCU are remodulated onto audio using facsimile modulation and protocol specifications and played out. * MODEM RELAY: - audio received by the MG1_MCU is demodulated using data modem modulation and protocol specifications, and data extracted from the audio are transmitted to the MG2_MCU using the V.150 protocol [8]; and - packets containing data received by the MG2_MCU are remodulated onto audio using data modem modulation and protocol specifications and played out. * TEXT RELAY: - text conversation over IP networks, see 10 * CIRCUIT MODE DATA: - samples received by the MG1_MCU are packetized and passed to the IP network with no modification (= "TRANSPARENT MODE" or "CLEAR CHANNEL MODE" or briefly "CLEAR MODE" 11) - no signal processing is performed in the MCUs, - packets received by the MG2_MCU are de-packetized, and samples are passed to the circuit interface without modification - Examples for use of Clearmode are the transfer of "ISDN 7 kHz voice" (e.g., G.722 encoded), "ISDN data" (e.g., X.25), "ISDN video tele- phony" (e.g., H.320), "ISDN fax", or generally "ISDN B channels". * PACKET MODE DATA: [ffs] * FRAME MODE DATA: [ffs] Schwarz Work-in-Progress - May 2003 [Page 14] Voiceband Data in Megaco/H.248 Networks May 2003 4. Gateway Capability Sets The terms "Capability Set" and "Profile" are used interchangeably in this document. 4.1 Introduction Functionality and capabilities of a gateway are differing due to the variety of network architecture approaches, network convergence and evolution scenarios, or set of supported services and their temporay distribution. Purpose of this chapter is a rough description of some meaningful gateway profiles. Solely considered gateway types are Megaco/H.248 controlled Media Gateways in IP networks. Note: Frame Mode Data (FMD) traffic is typically related to the SCN signaling plane, and shall be not further considered anymore in the following. 4.2 Voice-oriented Media Gateways Table 2 provides an overview of service sets concerning voice-oriented MGs. Every profile MUST support VoIP as a minimum. +-------------------------------+ | Supported MCU Modes | MG |-------------------------------| Scope of TRANSPORT DOMAIN Type|Vu |Vc |VBD|FR |MR |TR |CMD|PMD| IP Network (Examples) ----+---+---+---+---+---+---+---+---+----------------------------------- A | X | | | | | | | | simple VoIP MG, only POTS services ----+---+---+---+---+---+---+---+---+----------------------------------- B | X | X | | | | | | | as (A), plus compressing codecs ----+---+---+---+---+---+---+---+---+----------------------------------- C1 | X | | X | | | | | | as (A), plus VBD pass-through ser. ----+---+---+---+---+---+---+---+---+----------------------------------- C2 | X | X | X | | | | | | as (B), plus VBD pass-through ser. ----+---+---+---+---+---+---+---+---+----------------------------------- D | X | X | X | | | | X | | as (C2), e.g., support of ISDN ----+---+---+---+---+---+---+---+---+----------------------------------- E1 | X | | X | X | | | | | as (C1), plus fax relay service ----+---+---+---+---+---+---+---+---+----------------------------------- E2 | X | X | X | X | | | | | as (E1), plus compressing codecs ----+---+---+---+---+---+---+---+---+----------------------------------- E3 | X | X | X | X | | | X | | as (E2), plus CMD services ----+---+---+---+---+---+---+---+---+----------------------------------- F | X | X | X | X | X | | X | | as (E), plus modem relay service ----+---+---+---+---+---+---+---+---+----------------------------------- F | X | X | X | X | X | X | X | | as (F), plus text relay service ----+---+---+---+---+---+---+---+---+----------------------------------- ...| . | . | . | . | . | . | . | | others ----+---+---+---+---+---+---+---+---+----------------------------------- Table 2: Voice-oriented MGs - Exemplary Profiles and typical application Schwarz Work-in-Progress - May 2003 [Page 15] Voiceband Data in Megaco/H.248 Networks May 2003 Note: A typical example for profile 'D' may be the support of specific N-ISDN bearer services, like I.231.1 (sometimes called "ISDN- over-IP"; approximation or emulation of ISDN services through IP networks). 4.3 VBD-only Media Gateways The question whether a gateway should support packet relay services on top of pass-through modes is influenced primarily of the underlying IP network conditions with respect to performance metrics (packet loss, jitter, and delay). "Good" IP networks allow to limit the gateway capabilities on pass-through modes only. Such VBD-only MGs are corresponding to profiles `C' and `D'. The VBD-only operation mode is currently under standardization 12. 4.4 Voice & Data Media Gateways Detailed gateway profiles are ffs. Table 3 is only indicating the minimum capability set of a so-called universal gateway. Every MG in this category MUST support VoIP and DoIP as a minimum. +-------------------------------+ | Supported MCU Modes | MG |-------------------------------| Scope of TRANSPORT DOMAIN Type|Vu |Vc |VBD|FR |MR |TR |CMD|PMD| IP Network (Examples) ----+---+---+---+---+---+---+---+---+----------------------------------- U | X | . | . | . | . | . | . | X | Universal MG ----+---+---+---+---+---+---+---+---+----------------------------------- Table 3: Voice & Data MGs - Minimum Profile Note: DoIP respectively the PMD functionality MAY require a Megaco/H.248 NAS package [Ref. to be inserted]. 5. Scope of this Document Focus of this document are voiceband related services. That's why the MG and MCU modes CMD, PMD and FMD will not be further considered. The scope of this document shall be limited on voice-oriented MGs with voiceband data support. Note: draft document [13] is proposing detailed Megaco/H.248 procedures for FR Media Gateways capable of autonomous transition between VoIP And FoIP. Therefore, [13] is spanning 'E' type gateways. Schwarz Work-in-Progress - May 2003 [Page 16] Voiceband Data in Megaco/H.248 Networks May 2003 Several tradeoffs have to be considered for a specific VBD transport service, controlled by Megaco/H.248. This document shall merely illustrate the diverse points of discussion. An important goal is to offer a framework that allows further development and expansion of capabilities in voice oriented IP networks. 6. Service Control - Network Strategies 6.1 Overall Service Control Aspects Figure 3 did summarize the prime operation modes, i.e., the MCU states, but following topics were not yet elaborated: (1) potential and meaningful STATE TRANSITIONS, (2) TYPES of EVENTS, triggering such state changes, and (3) principle SOURCES of such EVENTS (called decision instances in this document). The first aspect is related to specific services and superordinated call scenarios. Such transition scenarios are beyond the scope of this document, and shall be addressed in companion proposals (like [13]). The outcome are principle Megaco/H.248 signaling procedures. The second and third aspects are the topics of this section, because the set of potential events may reflect general network approaches and service strategies. 6.2 Principle Decision Levels for Service Changes The term SERVICE shall denote a specific transport service by the IP Transport Domain. This is again related to a specific MCU operation mode respectively state from gateway perspective. State transitions may principally initiated by decision instances listed in Table 4. Schwarz Work-in-Progress - May 2003 [Page 17] Voiceband Data in Megaco/H.248 Networks May 2003 | Level | Decision Instance +-------+----------------------------------------------------------- | I | Call Agent (CA) and Media Gateway Controller (MGC) | | [-> decision by Control Domain] +-------+----------------------------------------------------------- | IIa | Media Gateways (MG1 & MG2); local and remote side | | [-> decision in Transport Domain, without Control Domain | | involvement] +-------+----------------------------------------------------------- | IIb | Media Gateway (MG); only local side | | [-> decision in Transport Domain, MG locally, without | | Control Domain involvement] +-------+----------------------------------------------------------- | III | Media Conversion Unit (MCU) | | [-> decision MG locally, but MCU internally] +-------+----------------------------------------------------------- Table 4: Decision Instances behind MCU State Transitions The reason behind case (IIa) may be, for instance, a kind of notification, CAPABILITIES EXCHANGE between both MGs, or others (e.g., like H.245 in H.323 domains, or State Signalling Event (SSE) protocol according V.150 between MoIP capable MGs). Capability support has following principal elements [14]: - Expression of the capabilities of the sender/recipient (= MG1 & MG2), and - Protocol by which capabilities are exchanged (negotiation). Capability description (e.g., SDP based) and capability exchange protocols and procedures are beyond the scope of this document. Table 4 is outlining three principal decision levels which are based on different wide control horizons. Following terms shall be used to denote the various levels: - Level I = STRICT CONTROL Call Agent is involved in (prime) operation mode changes, MGC is controlling the MG(s), MG is triggering the state transition by re-configuring the MCU. - Level II = AUTONOMOUS Let the MG(s) control and decide how to handle the VBD call without Call Agent involvement. The MGs are loosely controlled by their Call Agent(s). - Level III = AUTOMATIC Let the MCU(s) control and decide how to handle the VBD Schwarz Work-in-Progress - May 2003 [Page 18] Voiceband Data in Megaco/H.248 Networks May 2003 call without involvement of other local MG functions (e.g., resource management). The different levels shall be elaborated in more detail in subsequent sections. 6.3 STRICT Control (by CA & MGC) For further study. 6.4 AUTONOMOUS Control (by MG) For further study. 6.5 AUTOMATIC Control (by MCU) For further study. 7. Interworking Considerations Realizations of (circuit-switched based) voiceband data services in packet networks is inherently implying interworking aspects. The framework of this interworking scenario, - SCN interworking with Megaco/H.248 controlled IP packet domains -, is already covered in the previous sections. Scope of this section are interworking cases between different style of packet network architectures, whereby one domain shall be Megaco/H.248 based. Interworking is generally addressing: - Network Interworking, and - Service Interworking. Due to the limited perspective of MGC and MG entities, interworking shall be separated in: (1) Interworking in Transport Domain (e.g., T.38 related), and (2) Control Domain (e.g., prime impacts on Megaco/H.248). Typical interworking requirements may be derived, e.g., for following VBD service and following types of packet networks: - T.38 in H.323 Domains - T.38 in SIP Domains [...] Schwarz Work-in-Progress - May 2003 [Page 19] Voiceband Data in Megaco/H.248 Networks May 2003 For further study. [Note: Section 7 will be covered by separated document in the next document revision.] 8. Operational & Functional Goals To accommodate current use as well as future growth, Megaco/H.248 signaling procedures for VBD transport services should have a simple minimum set of required features that will guarantee interoperability, as well as mechanisms by which higher capability gateways can be deployed into a packet network of lower capability gateways while ensuring interoperability. [to be completed; simplicity, reliability, robustness, capability exchange aspects, etc.] 9. Security Considerations Security considerations are addressed as per Section 10 of RFC 3015 [15]. Megaco/H.248 procedures for VBD transport service control inheriting the security requirements of Megaco/H.248. 10. References 1 Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996. 2 Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997 3 Masinter, L., "Terminology and Goals for Internet Fax", RFC 2542, March 1999. 4 Schulzrinne, H., Petrack, S., "RTP Payload for DTMF Digits, Telephony Tones and Telephony Signals", RFC 2883, May 2000. 5 ITU-T Recommendation H.248, "Gateway Control Protocol", June 2000. 6 ITU-T Recommendation H.323, "Packet-Based Multimedia Communication Systems", 1998. 7 ITU-T Recommendation T.38, "Procedures for real-time Group 3 facsimile communication over IP networks", June 1998. Schwarz Work-in-Progress - May 2003 [Page 20] Voiceband Data in Megaco/H.248 Networks May 2003 8 ITU-T Recommendations: V.150.0, "Modem-over-IP Networks: Foundation", January 2003. V.150.1, "Modem-over-IP Networks: Procedures for the End-to-End Connection of V-series DCEs ", January 2003. 9 TIA TR-30 Contribution, "Call Discrimination in MoIP Gateways", TR- 30.1/02-02-015, 2002. 10 ITU-T DRAFT Recommendation V.ToIP, "Text-over-IP", targeted for February 2004 (work in progress). 11 RTP Payload Format for a 64 kbit/s Transparent Call. IETF Draft draft- ietf-avt-rtp-clearmode-00.txt, April 2003. 12 ITU-T DRAFT Recommendation V.VBDoIP (planned V.150.2), "VBD-only Gateways", May 2003 (work in progress). 13 Leurs, A., "Megaco/H.248 Procedures for Voice Media Gateways Capable for Fax Relay Services", , August 2002, work in progress 14 Masinter, L., "Terminology and Goals for Internet Fax", RFC 2542, March 1999. 15 Cuervo, et al., "Megaco Protocol Version 1.0", RFC 3015, November 2000 Acknowledgments This document is reflecting many ideas and thoughts of approved, draft, evolving, and work-in-progress standards. The author wishes to thank to all contributors, especially the Megaco/H.248, FoIP (T.38 [7]) and MoIP (V.150 [8]) community. Author's Addresses Albrecht Schwarz Alcatel Lorenzstrasse 10 D-70435 Stuttgart GERMANY Email: Albrecht.Schwarz@alcatel.de Schwarz Work-in-Progress - May 2003 [Page 21]