Media Gateway Control (Megaco) Madhubabu Brahmanapally Internet Engineering Task Force Prerepa Viswanadham Internet Draft krishna Gundamaraju Document: draft-madhu-megaco-callflows-00.txt Kenetec Inc Category: Informational July 2001 Expires:January 2002 Megaco/H.248 Call flow examples Status of this Memo This draft is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working drafts of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working drafts as Internet- Drafts. Internet-Drafts are draft drafts valid for a maximum of six months and may be updated, replaced, or obsoleted by other drafts 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. 1. Abstract This draft illustrates the usage of Megaco (version 1) protocol defined between the Media Gateway Controller and Media Gateway. In light of the vast features presently incorporated and continuously evolving features of the protocol, it serves the purpose of representing typical use case scenarios. There are a lot of possible scenarios for usage of MEGACO protocol. It is not the intent of the draft to represent the inter-working functionality among various protocols, however, an attempt is made to depict its usage in such a case for the purpose of completeness in the larger perspective. An attempt has been made to show the supplementary call services using MEGACO. The call flows can be categorized in to two sub sections, - MEGACO only call scenario - MEGACO and other protocols The draft begins with showing MEGACO only call scenarios, where the called and calling party lie on MEGACO domain. Various Madhubabu, et al. [Page 1] Internet-Draft Megaco/H.248 Call flow examples July 2001 permutations are possible even in this setup, viz RGW to RGW RGW to TGW TGW to TGW RGW/TGW to IVR In the other case, typical cases of MEGACO interaction with other protocols have been depicted. Here it is assumed that the MG, which participates in the interaction, is RGW. This can be extended to any type of Media GW. The scenarios include MEGACO user with SIP MEGACO user with H.323 MEGACO user with SS7 MEGACO user with ISDN MEGACO user with R1 MEGACO user with R2 The packages used in each of the calls flows are mentioned before each of the call flows. The packages that are addressed in this draft along with the packages defined in the base protocol also include packages like R2, R1, etc to illustrate the protocol usage. In case of Trunking gateways even though its not shown explicitly it is assumed that the messages from the CCS (Common Channel Signaling) switches are received by MGC through the Signaling Gateway. The emphasis of the draft is on the Megaco commands hence the messages between Signaling Gateway and MGC are not shown explicitly. Wherever applicable it should be assumed that the CCS switches/exchanges are communicating the messages to MGC through the Signaling Gateway. One of the sections illustrates the usage of SDP for ATM. For simplicity residential gateway with ATM connectivity is assumed. However the same holds true for trunking gateways also. Two methods of call establishment with SDP for ATM are discussed, namely the "Backward Bearer Connection Set-up Model" and "Forward Bearer Connection Set-up Model". This draft should be treated as only a means to illustrate the usage of Megaco but not as a guide for implementing Media Gateway or Media Gateway Controller. These calls flows are only informative. All the messages are encoded in the ABNF syntax for simplicity. The same calls flows are valid with binary messages also. Care has been taken to see that the messages are according to the protocol grammar, in case of discrepancies the protocol draft has to be considered. The Call flow diagrams are only a means to abstract the protocol messages exchanged between the MG and the MGC. These call flow diagrams are not according to any time scale. The IP addresses and port numbers used in the examples are fictitious. The statistic parameter values are also fictituous. Madhubabu, et al. [Page 2] Internet-Draft Megaco/H.248 Call flow examples July 2001 1.2 References:.....................................................4 2. Internet Telephony Call Flows....................................4 2.1 Call between two residential gateways...........................4 Case (a).......................................................7 Case (b)......................................................18 Case (c)......................................................18 2.2 Call between Residential Gateway and Trunking Gateway..........24 2.3 Call between Trunking gateway and Residential Gateway..........34 2.4 Call between two Trunking gateways.............................42 2.5 Call between Residential gateway and SS7 trunk in TGW..........49 2.6 Call between SS7 trunk in TGW and residential gateway..........58 2.7 Call between SS7 trunk in TGW and R2 trunk in TGW..............67 2.8 Call between R2 trunk in TGW and SS7 trunk in TGW..............76 2.9 Call between R1 trunk in TGW and SS7 trunk in TGW..............85 2.10 Call between SS7 trunk in TGW and R1 trunk in TGW.............94 2.11 Call between ISDN trunk in TGW and SS7 trunk in TGW..........103 2.12 Continuity test from TGW.....................................109 Case (a)....................................................109 Case (b)....................................................111 2.13 Call from residential gateway to H.323 Terminal..............112 2.14 Call from residential gateway to SIP user....................120 3 Service Change Command Usage....................................127 3.1 ROOT Termination..............................................127 3.1.1 Registration................................................127 3.1.2 Cold Start..................................................129 3.1.3 Handoff.....................................................131 3.1.4 Disconnection...............................................133 3.2 Service Change for Termination................................136 3.2.1 MG generated Service Change.................................136 3.2.2 MGC generated Service Change................................143 4.0 Audit Command Usage...........................................146 4.1 Audit Value...................................................146 4.1.1 Audit value command on ROOT Termination.....................146 4.1.2 Audit value on non-ROOT terminations........................148 4.2 Audit Capability..............................................150 4.2.1 Audit Capability on ROOT termination........................150 4.2.2 Audit Capability on non-Root Terminations...................150 5. IVR using MEGACO...............................................151 5.1 Connecting Residential gateway to IVR.........................151 5.2 Disconnecting Residential User from IVR.......................158 5.3 Connecting Trunking Gateway to IVR............................160 5.4 Disconnecting Trunking gateway from IVR.......................164 6. Wildcard ContextID usage.......................................166 7. Wildcard TerminationId Usage...................................167 8. Supplementary services support.................................168 8.1 Call Transfer.................................................168 8.2 Call waiting..................................................189 9. Conferencing...................................................211 10.0 SDP for ATM..................................................243 10.1.1 Forward Bearer Connection Set-up Method....................244 10.1.2 Backward Bearer Connection Set-up Method...................257 Madhubabu, et al. [Page 3] Internet-Draft Megaco/H.248 Call flow examples July 2001 1.1. 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 [1]. 1.2 References: 1) Cuervo, et al. "Megaco Protocol Version 1.0", RFC 3015, November2000. 2) Christian Huitema, et. Al. "Media Gateway Control Protocol (MGCP) Call Flows". < 3) Implementers' Guide for ITU Recommendation H.248. Nov 2000. 4) Megaco mail archive http://standards.nortelnetworks.com/archives/megaco.html 5) R2 Package for Megaco Protocol, Kushanava Laha et al,"work in progress" 6) V.Bajaj et al, Megaco/H.248 Basic CAS Packages,"Work in Progress" 7) Wendy et. al, draft-bothwell-megaco-mftonepkgs-01.txt, "Work in Progress", "MF Tone Generation and Detection Packages" 8) Rajesh Kumar et. al, Conventions for the use of the Session Description Protocol (SDP)for ATM Bearer Connections. "draft-ietf-mmusic-sdp-atm-05.txt", "Work in Progress". 2. Internet Telephony Call Flows This section illustrates sample Internet telephone calls. Calls between Trunking gateway, Residential gateway, H.323 Endpoint, etc are illustrated. In all these call scenarios emphasis is given on the Megaco protocol messages rather than the remaining entities.2.1 Call between two residential gateways 2.1 Call between two Residential Gateways The call establishment between two residential users is considered in this example. User A and User B are connected to two residential gateways RGW1 and RGW2. For simplicity we consider the case where the two MG's are controlled by the same MGC. The call scenario assumes the implementation of analog line supervision package, RTP package, generic package, DTMF detection package, Call progress generator package, and the Network Package. Along with the successful call between the two users (case a), we also consider the case where the called party is busy (case c), and the call termination by both the users (case a for UserA terminated call flow and case b for UserB terminated call flow) is also discussed. In this example the registration of the MG (RGW) with the MGC is assumed to have happened as explained in section 3.1.1 Registration. Madhubabu, et al. [Page 4] Internet-Draft Megaco/H.248 Call flow examples July 2001 _____________________________________________________________________ | | | | USERA | RGW1 | MGC | RGW2 | USERB _____________|___________|___________|______________|_________________ | | | | | | | | | | | | |---------->| | | | |Modify to | | | | |Check Offhook | | |<----------| | | | |Modify to | | | | |check offhook | | | |---------->|<----------| | | |Modify Resp| Modify Resp | |----------->| | | | |UserA offhook | | | | |---------->| | | | |Notify offhook | | | |<----------| | | | |Notify Resp| | | | |<----------| | | | |Modify SG:dialtone | | | |ED:al/on,dd/ce{Dmap1} | | | |DM:Dmap1 = 2XXX | | |<-----------| | | | |Dial Tone |---------->| | | | |Modify Resp| | | | | | | | |----------->| | | | |User Dials Digits | | | | |---------->| | | | |Notify digits | | | |<----------| | | | |Notify Response | | | |<----------| | | | | Add TermA SD:ringbacktone | | | Add $, Local SDP Info -underspecified | |<-----------| | | | |RingBack Tone | | | | |---------->| | | | |Modify Resp TermA | | | |Add Resp Local SDP (Specified) | | | |---------->| | | | |Add TermB SD:Ring ED:offhook | | | |Add $ Local(Underspecified) | | | | Remote SDP (Specified) | | | | | | | | | |------------------>| | | | | UserB Phone Ringing | | |<----------| | | | |Add Resp TermB | Madhubabu, et al. [Page 5] Internet-Draft Megaco/H.248 Call flow examples July 2001 | | |Add Resp EphB Local Specified | | | | |<------------------| | | | |UserB goes Offhook | | | |<----------| | | | |Notify Offhook | | | |---------->| | | | | Notify Resp | | |<----------| | | | |Modify TermA SendRecv | | | |Modify EphA Remote(Specified) SendRecv | | |---------->| | | | |Modify Resp| | | | | |---------->| | | | |Modify TermB SendRecv | | | |Modify EphB SendRecv | | | |<----------| | | | |Modify Resp| | |/------------------------------------------------------\| | RTP MEDIA | |\------------------------------------------------------/| |----------->| | | | |UserA goes OnHook | | | | |---------->| | | | |Notify OnHook | | | |<----------| | | | |Notify Resp| | | | | |---------->| | | | |Modify TermA SD:BusyTone | | | | |------------------>| | | | | Busy tone to UserB| | | |<----------| | | | |Modify Resp| | | |<----------| | | | |Subtract TermA | | | |Subtract EphA | | | |---------->| | | | |Subtract Resp TermA | | | |Subtract Resp EphA Statistics | | | | |<------------------| | | | | UserB goes Onhook | | | |<----------| | | | |Notify Onhook | | | |---------->| | | | |Notify Resp| | | | |---------->| | | | |Subtract TermB | | | |Subtract EphB | | | |<----------| | | | |Subtract Resp TermB | | | |Subtract Resp EphB Statistics | |____________|___________|___________|___________________| Madhubabu, et al. [Page 6] Internet-Draft Megaco/H.248 Call flow examples July 2001 Case (a) In all the telephone scenarios explained in this draft, once the call is terminated by either the Calling party or the called party, the other user listens a busy tone. A dial tone can be applied for the user to initiated another call. But for simplicity busy tone is applied so that the user goes onhook before initiating another call. It is assumed in the call scenarios that the registration of the MG with the MGC is done already. In Step 1 the MGC generates the Modify message towards both the Residential gateways to check for off hook on the terminations. (A wildcard command may also be used in this scenario but simplicity we consider only command to specific terminations). Modify message generated only for Residential gateway 1 is shown, similar message is sent to the other Residential gateway also. We are not considering the embedded signal and event descriptors here. Another call scenario will illustrate the use of embedded event and signal descriptors. The MGC in NULL context generates the command to the specific termination TermA. The off hook event of the analog supervision package is used here. The request identifier specified here in the example is 1111. The mode of the termination is set to receive only. The stream parameter is used with only the Local control descriptor. Step 1 MGC to RGW1: MEGACO/1 [216.33.33.61]: 27000 Transaction = 1234 { Context = - { Modify = TermA { Media { LocalControl { Mode = Receiveonly} }, Events = 1111 {al/of} } } } MG after receiving the command from MGC accepts it and responds with the transaction reply. Step 2 MG1 to MGC: MEGACO/1 [209.110.59.34]: 25000 Reply = 1234 { Context = - {Modify = TermA} } In this example User A goes off hook. This event is detected by the RGW1 and constructs and sends the Notify message towards the MGC. The MG uses the same request id (1111) sent by the MGC in its initial Madhubabu, et al. [Page 7] Internet-Draft Megaco/H.248 Call flow examples July 2001 command. The timestamp of the detected event is also passed as parameter to the observed event. Step 3 MG1 to MGC: MEGACO/1 [209.110.59.34]: 25000 Transaction = 2000 { Context = - { Notify = TermA {ObservedEvents =1111 { 20010202T10000000:al/of}} } MGC generates the Notify response and responds with more messages towards the MG that generated the Notify command. Step 4 MGC to MG1: MEGACO/1 [216.33.33.61]: 27000 Reply = 2000 { Context = - {Notify = TermA} } The MGC in the present example issues a MODIFY command. The Modify command contains a signal descriptor for the application of dial tone to the user. The digit map descriptor here is used to configure a digit map on the termination. The digit map name used in the example is Dmap1 and the dial pattern is 2XXX. The event descriptor lists digit map completion event of the DTMF detection package and onhook of the analog line supervision package. The request id specified in the event descriptor is 1112. Step 5 MGC to MG1: MEGACO/1 [216.33.33.61]: 27000 Transaction = 1235 { Context = - { Modify = TermA { Signals {cg/dt}, DigitMap= Dmap1 {(2XXX)} Events = 1112 { al/on, dd/ce {DigitMap=Dmap1} }, } } } MG after receiving the Modify command after validation responds to the MGC and starts processing the descriptors listed. Step 6 MG1 to MGC: Madhubabu, et al. [Page 8] Internet-Draft Megaco/H.248 Call flow examples July 2001 MEGACO/1 [209.110.59.34]: 25000 Reply = 1235 { Context = - {Modify = TermA} } The descriptors are processed in the order that is specified by the MGC. In this example the order of descriptor is signal descriptor, digit map descriptor followed by Events descriptor. The MG first processes the signal descriptor. The dial tone is applied to the Termination specified. The Digit map is updated in the Database of the termination. The Digit map said to be ACTIVE on the termination as the digit map completion event is listed in the events descriptor with the digit map name. A digit map is activated whenever a new event descriptor is applied to the termination or embedded event descriptor is activated, and that event descriptor contains a digit map completion event which itself contains a digit map parameter. UserA after receiving the dial tone starts dialing digits. In this example we will not dwell into the different possible cases of digit dialing by the user. It's assumed that the user dials digits that match the pattern specified in the digit map. Lets assume that the user has dialed 2992. MG detects the digits dialed and reports the same as parameter to the digit map completion event. A notify command is generated from MG1 to MGC. The MG again used the same request identifier as specified by the MGC. Step 7 MG1 to MGC: MEGACO/1 [209.110.59.34]: 25000 Transaction = 2001 { Context = - { Notify = TermA {ObservedEvents =1112 { 20010202T10010000:dd/ce {ds="2992", Meth=FM}}} } } MGC after receiving the Notify command responds back with the Notify response. Step 8 MGC to MG1: MEGACO/1 [216.33.33.61]: 27000 Reply = 2001 { Context = - {Notify = TermA} } MGC after receiving the Notify command starts analyzing the dialed digits. In this example it is assumed that the called subscriber is connected to the RGW2, which is again controlled by the same MGC. The MGC generates a transaction with two commands clubbed into the same Action. The first command is to create a new context and add the physical termination TermA into it. As the MGC is aware that the Madhubabu, et al. [Page 9] Internet-Draft Megaco/H.248 Call flow examples July 2001 destination user UserB is free it indicates MG1 to apply ringback tone to the termination of UserA. The second command is generated to create an ephemeral termination and add the created termination in the same context that was created because of the earlier command. Here we assumed a single set of SDP information indicating that Reserve group is not used. The Reserve Value feature is also not used. Step 9 MGC to MG1: MEGACO/1 [216.33.33.61]: 27000 Transaction = 1236 { Context = $ { Add = TermA { Signals {cg/rt} } Add = $ { Media { { LocalControl { Mode = Receiveonly, }, Local { v=0 c=IN IP4 $ m=audio $ RTP/AVP 4 } } } } } In this example the connection fields IP address, the media field port number are unspecified. The MG in its response indicates the IPAddress and port number used. The contextID is also not specified indicating the creation of a new context. In this example the MG creates a context with contextID 1. The physical termination TermA is added to context 1. The mode of the physical termination was earlier set to Receiveonly and in this message the ephemeral termination is requested to create with Receiveonly mode. The ephemeral termination created in this example is EphA. MG responds with the allocated IP address 209.110.59.33 and port number 30000. Step 10 MG1 to MGC: MEGACO/1 [209.110.59.34]: 25000 Reply = 1236 { Context = 1 { Add = TermA, Add=EphA{ Media { Madhubabu, et al. [Page 10] Internet-Draft Megaco/H.248 Call flow examples July 2001 Local { v=0 c=IN IP4 209.110.59.33 m=audio 30000 RTP/AVP 4 a=recvonly } ; RTP profile for G.723 is 4 } } } } } MGC generates a similar transaction towards the RGW2. The ContextID specified in the action is $. The first command adds the physical termination TermB to the newly created context. The Signal descriptor for this termination lists the ring signal of the analog line supervision package. This alerting signal is applied to the termination of the TermB. The Event descriptor specifies offhook event of the analog line supervision package. The second Add is meant to create an ephemeral termination. MGC has the local information for the ephemeral termination EphA in the RGW1. This information is passed as remote information to the RGW2. The new ephemeral termination that will be created will take these parameters as the remote SDP information. Step 11 MGC to MG2: MEGACO/1 [216.33.33.61]:27000 Transaction = 1237 { Context = $ { Add = TermB { Media { LocalControl {Mode = Receiveonly} }, Signals {al/ri} Events =1234{al/of {events = 1235 {al/on}}}, }, Add = $ {Media { LocalControl { Mode = Receiveonly, }, Local { v=0 c=IN IP4 $ m=audio $ RTP/AVP 4 }, Remote { v=0 c=IN IP4 209.110.59.33 m=audio 30000 RTP/AVP 4 } ; RTP profile for G.723 is 4 } Madhubabu, et al. [Page 11] Internet-Draft Megaco/H.248 Call flow examples July 2001 } } } } MG2 after receiving the new transaction from MGC starts processing it. It creates a new context with contextID 2. It adds the physical termination TermB to that context and start processing the descriptor specified in the command. The signal descriptor lists "ring" signal to be applied on the termination. The event descriptor lists the off hook event. The RGW2 creates an ephemeral termination with TerminationId EphB. The local information is under-specified from the MGC. The MG allocates the necessary resources for processing the media descriptor for the ephemeral termination. The MG responds to the MGC by specifying the IP address reserved for the local connection. In this example MG2 reserves IP address 207.176.47.90 and port number 40000. The MG2 responds to MGC with the following transaction reply. Step 12 MG2 to MGC: MEGACO/1 [207.176.47.89]: 26000 Reply = 1237 { Context = 2 { Add = TermB, Add = EphB{ Media { Local { v=0 c=IN IP4 207.176.47.90 m=audio 40000 RTP/AVP 4 } } ; RTP profile for G723 is 4 } } } The MGC waits for the UserB to go offhook. Once the UserB goes offhook, MG2 reports the notification of the offhook event to the MGC. Step 13 MG2 to MGC: MEGACO/1 [207.176.47.89]: 26000 Transaction = 3000 { Context = 2 { Notify = TermB {ObservedEvents =1234 { 20000202T10020000:al/of}} } } The MGC responds to the MG2 with the Notify response. Madhubabu, et al. [Page 12] Internet-Draft Megaco/H.248 Call flow examples July 2001 Step 14 MGC to MG2: MEGACO/1 [216.33.33.61]: 27000 Reply = 3000 { Context = 2 {Notify = TermB} } The MGC generates a transaction towards MG2 with two commands in one action. It changes the mode of both the terminations to sendrecv. The Signal descriptor of the Modify command for the first termination, stops the ring signal already applied on the termination and the event descriptor lists the onhook event. Step 15: MGC to MG2: MEGACO/1 [216.33.33.61]: 27000 Transaction = 1238 { Context = 2 { Modify = TermB { Signals { } ; to turn off ringing Events = 1235 {al/on}, Media { LocalControl { Mode = SendRecv, } } } Modify = EphB{ Media { LocalControl { Mode = SendRecv, } } } } The MG2 responds to the request from MGC. Step 16 MG2 to MGC: MEGACO/1 [207.176.47.89]: 26000 Reply = 1238 { Context = 2 {Modify = TermB , Modify = EphB} } The MGC generates message to the MG1 to stop the ringback tone and to report the remote SDP information for the ephemeral termination EphA. The mode of the two terminations TermA and EphA is set to send receive. Step 17 MGC to MG1: MEGACO/1 [216.33.33.61]: 27000 Madhubabu, et al. [Page 13] Internet-Draft Megaco/H.248 Call flow examples July 2001 Transaction = 1239 { Context = 1 { Modify = TermA { Media { LocalControl { Mode = sendrecv} } } Signals { } }, Modify = EphA { Media { LocalControl { Mode = sendrecv} Remote { v=0 c=IN IP4 207.176.47.90 m=audio 40000 RTP/AVP 4 } } ; RTP profile for G723 is 4 } } } } The empty signal descriptor in the Modify command for termination TermA, specifies to stop the ringback tone at the calling end. The remote SDP information is updated for the ephemeral termination EphA. The mode is changed to send receive. MG1 responds to the MGC with the response for the Modify commands. Step 18 MG1 to MGC: MEGACO/1 [209.110.59.34]: 25000 Reply = 1239 { Context = 1 {Modify = TermA, Modify = EphA} } The two users can exchange the voice. The call can be termination either by the calling user or the called user. In this example it is assumed that the calling party has gone on-hook The UserA after the conversation goes onhook indicating the tearing down of the call. The same is reported in the Notify command from MG1 to MGC. Step 19 RGW1 to MGC: MEGACO/1 [209.110.59.34]:25000 Transaction = 2002 { Context = 1 { Notify = TermA {ObservedEvents =1112 { 20010202T10030000:al/on} } } Madhubabu, et al. [Page 14] Internet-Draft Megaco/H.248 Call flow examples July 2001 The MGC responds to the MG1s Notify message. Step 20 MGC to RGW1: MEGACO/1 [216.33.33.61]:27000 Reply = 2002 { Context = 1 { Notify = TermA } } The MGC generates a Modify command towards the RGW2 for applying busy tone to the called subscriber. The mode of both terminations is set to receive only. Step 21 MGC to RGW2: MEGACO/1 [216.33.33.61]: 27000 Transaction = 1240 { Context = 2 { Modify = TermB { Signals {cg/bt} Media { LocalControl { Mode = recvonly} } }, Modify = EphB { Media { LocalControl { Mode = recvonly} } } } } } The MG2 responds to this modify request. Step 22 MG2 to MGC: MEGACO/1 [207.176.47.89]: 26000 Reply = 1240 { Context = 2 { Modify= TermB, Modify = EphB} } The MGC generates transactions with two subtracts commands one for physical and other for ephemeral terminations. The MGC does the same for both the Contexts one at RGW1 and the other at RGW2. Madhubabu, et al. [Page 15] Internet-Draft Megaco/H.248 Call flow examples July 2001 Step 23: MGC to MG1 MEGACO/1 [216.33.33.61]: 27000 Transaction = 1241 { Context = 1 { Subtract = TermA {Audit{ }}, Subtract = EphA {Audit{Statistics}} } } The MG subtracts the two terminations from the context. The context itself is deleted with the subtract of the last termination from it. The MG1 responds to this transaction from MGC with statistics on ephemeral termination. Step 24 MG1 to MGC: MEGACO/1 [209.110.59.34]:25000 Reply = 1241 { Context = 1 { Subtract = TermA Subtract = EphA { Statistics { rtp/ps=1234, ; packets sent nt/os=56789, ; octets sent rtp/pr=987, ; packets received nt/or=65432, ; octets received rtp/pl=10, ; % packets lost rtp/jit=30, rtp/delay=30 ; average latency } } } } The User B after going onhook, the RGW2 generates Notify command towards the MGC. Step 25 MG2 to MGC: MEGACO/1 [207.176.47.89]: 26000 Transaction = 3001 { Context = 2 { Notify = TermB {ObservedEvents =1235 { 20000202T10070000:al/on}} } } The MGC responds to the MG2 with the Notify response. Step 26 MGC to MG2: MEGACO/1 [216.33.33.61]: 27000 Madhubabu, et al. [Page 16] Internet-Draft Megaco/H.248 Call flow examples July 2001 Reply = 3001 { Context = 2 {Notify = TermB} } The MGC generates subtract command towards RGW2 for removing TermB from valid context. Step 26 MGC to MG2: MEGACO/1 [216.33.33.61]: 27000 Transaction = 1242 { Context = 2 { Subtract = TermB {Audit{ }}, Subtract = EphB {Audit{Statistics}} } } The MG2 responds to the subtract commands generated by MGC. Step 27 MG2 to MGC: MEGACO/1 [207.176.47.89]:26000 Reply = 1242 { Context = 2 { Subtract = TermB Subtract = EphB { Statistics { rtp/ps=987, ; packets sent nt/os=65432, ; octets sent rtp/pr=1234, ; packets received nt/or=56789, ; octets received rtp/pl=10, ; % packets lost rtp/jit=30, rtp/delay=30 ; average latency } } } } The MGC generates the message as shown in step 1 to both the RGW1 and RGW2, to enable the users to participate/initiate in further calls. Madhubabu, et al. [Page 17] Internet-Draft Megaco/H.248 Call flow examples July 2001 Case (b) _____________________________________________________________________ | | | | USERA | RGW1 | MGC | RGW2 | USERB _____________|___________|___________|______________|_________________ | | | | | | | | | | |/------------------------------------------------------\| | RTP MEDIA | |\------------------------------------------------------/| | | | | | | | | |<------------------| | | | |UserB goes Onhook | | | |<----------| | | | |Notify Onhook | | | |---------->| | | | |Notify Resp| | | | |---------->| | | |<----------| | | | |Modify TermA SD:BusyTone | |<-----------| | | | |Busy tone | | | | | |---------->| | | | |Modify Resp| | | | | |Subtract TermB | | | |Subtract EphB | | | |<----------| | | | |Subtract Resp TermB | | | |Subtract Resp EphB Statistics | |----------->| | | | |UserA goes Onhook | | | | |---------->| | | | |Notify OnHook | | | |<----------| | | | |Notify Resp| | | | |<----------| | | | |Subtract TermA | | | |Subtract EphA | | | |---------->| | | | |Subtract Resp TermA | | | |Subtract Resp EphA Statistics | |____________|___________|___________|___________________| The case (a) above illustrated the call flow between two Residential Madhubabu, et al. [Page 18] Internet-Draft Megaco/H.248 Call flow examples July 2001 Gateways controlled by a single MGC. In this section we will discuss the call scenario where the called party terminates the call. The assumptions for case (a) holds good for this call flow also. The call flow is same till step 18. The voice path is through and both the users are in conversation. We will consider the call flow when UserB goes on hook. As soon as the UserB goes onhook the RGW2 generates notify message to the MGC. Step 19 MG2 to MGC: MEGACO/1 [207.176.47.89]:26000 Transaction = 3001 { Context = 2 { Notify = TermB {ObservedEvents =1235 { 20010202T10030000:al/on} } } } The MGC responds to the MG's notify message. Step 20 MGC to MG2: MEGACO/1 [216.33.33.61]:27000 Reply = 3001 { Context = 2 { Notify = TermB } } The MGC generates a Modify command towards the RGW1 for applying busy tone to the called subscriber. The mode of both terminations is set to receive only. Step 21 MGC to MG1: MEGACO/1 [216.33.33.61]: 27000 Transaction = 1240 { Context = 1 { Modify = TermA { Signals {cg/bt} Media { LocalControl { Mode = recvonly} } }, Modify = EphA { Media { LocalControl { Mode = recvonly} } Madhubabu, et al. [Page 19] Internet-Draft Megaco/H.248 Call flow examples July 2001 } } } } The MG1 responds to this modify request. Step 22 MG1 to MGC: MEGACO/1 [209.110.59.34]: 25000 Reply = 1240 { Context = 1 { Modify= TermA, Modify = EphA} } The MGC generates transactions with two subtracts commands one for physical and other for ephemeral terminations. This command is generated towards the RGW2, since UserB has initiated the call tear down. Step 23 MGC to MG2: MEGACO/1 [216.33.33.61]: 27000 Transaction = 1242 { Context = 2 { Subtract = TermB {Audit {}}, Subtract = EphB {Audit {Statistics}} } } The MG2 responds to the subtract commands generated by MGC. Step 24 MG2 to MGC: MEGACO/1 [209.110.59.34]:25000 Reply = 1242 { Context = 2 { Subtract = TermB Subtract = EphB { Statistics { rtp/ps=987, ; packets sent nt/os=65432, ; octets sent rtp/pr=1234, ; packets received nt/or=56789, ; octets received rtp/pl=10, ; % packets lost rtp/jit=30, rtp/delay=30 ; average latency } } } } Madhubabu, et al. [Page 20] Internet-Draft Megaco/H.248 Call flow examples July 2001 The User A after hearing the busy tone goes onhook. The same activity is recognized as onhook event by the RGW1. The Notify command is generated towards the MGC. Step 25 RGW1 to MGC: MEGACO/1 [209.110.59.34]:25000 Transaction = 2002 { Context = 1 { Notify = TermA {ObservedEvents =1112 { 20010202T10030000:al/on} } } The MGC responds to the MG1s Notify message. Step 26 MGC to RGW1: MEGACO/1 [216.33.33.61]: 27000 Reply = 2002 { Context = 1 { Notify = TermA } } The MGC after receiving the Notify command with onhook event, generates subtract commands to remove the termination from context Identifier 1. Step 27: MGC to MG1 MEGACO/1 [216.33.33.61]: 27000 Transaction = 1241 { Context = 1 { Subtract = TermA {Audit{ }}, Subtract = EphA {Audit{Statistics}} } } The MG subtracts the two terminations from the context. The context itself is deleted with the subtract of the last termination from it. The MG1 responds to this transaction from MGC with statistics on ephemeral termination. Step 28 MG1 to MGC: MEGACO/1 [209.110.59.34]:25000 Reply = 1241 { Context = 1 { Subtract = TermA Subtract = EphA { Statistics { Madhubabu, et al. [Page 21] Internet-Draft Megaco/H.248 Call flow examples July 2001 rtp/ps=1234, ; packets sent nt/os=56789, ; octets sent rtp/pr=987, ; packets received nt/or=65432, ; octets received rtp/pl=10, ; % packets lost rtp/jit=30, rtp/delay=30 ; average latency } } } } The MGC generates the message as shown in step 1 to both the RGW1 and RGW2, to enable the users to participate/initiate in further calls. Case (c) _____________________________________________________________________ | | | | USERA | RGW1 | MGC | RGW2 | USERB _____________|___________|___________|______________|_________________ | | | | | | | | | | | | |---------->| | | | |Modify to | | | | |Check Offhook | | |<----------| | | | |Modify to | | | | |check offhook | | | |---------->|<----------| | | |Modify Resp| Modify Resp | |----------->| | | | |UserA offhook | | | | |---------->| | | | |Notify offhook | | | | |<----------| | | | |Notify Resp| | | | |<----------| | | | |Modify SG:dialtone | | | |ED:al/on,dd/ce{Dmap1} | | | |DM:Dmap1 = 2XXX | |<-----------| | | | |Dial Tone |---------->| | | | |Modify Resp| | | | | | | | |----------->| | | | |User Dials Digits | | | | |---------->| | | | |Notify digits | | | |<----------| | | Madhubabu, et al. [Page 22] Internet-Draft Megaco/H.248 Call flow examples July 2001 | |Notify Response | | | |<----------| | | | |Modify TermA SD:BusyTone | |<-----------| | | | |Busy tone | | | | | |---------->| | | | |Modify Resp| | | |----------->| | | | |UserA goes Onhook | | | | |---------->| | | | |Notify OnHook | | | |<----------| | | | |Notify Resp| | | |____________|___________|___________|___________________| The two call flows explained in case (a) and (b) illustrate a successful call scenario. In this subsection we will look into the flow where UserA calls UserB and as the UserB is already in a call, UserA receives busy tone, thus illustrating an unsuccessful call scenario. The steps 1 through 8 remain that same. When the MGC receives the digits dialed by UserA, it analyses the digits and find that the digits 2992 pertain to UserB, which is again controlled by the same MGC. In this example UserB is already in some call. Hence the call initiation from UserA becomes unsuccessful. MGC in this case issues a message, which instruct the MG, for busy tone application on the Termination TermA. Step 9 MGC to MG1: MEGACO/1 [216.33.33.61]: 27000 Transaction = 1236 { Context = - { Modify = TermA { Signals {cg/bt} } } } MG responds to the Modify message from MGC. It applies busy tone on the termination TermA. MG also responds to the message generated from MGC. Step 10: MG1 to MGC: MEGACO/1 [209.110.59.34]: 25000 Reply = 1236 { Context = - { Modify = TermA } Madhubabu, et al. [Page 23] Internet-Draft Megaco/H.248 Call flow examples July 2001 } As soon as the UserA goes onhook MG detects the same and reports that event as parameter in the Notify command it generates towards the MGC. Step 12: MG1 to MGC: MEGACO/1 [209.110.59.34]: 25000 Transaction = 2002 { Context = - { Notify = TermA {ObservedEvents =1112 { 20010202T10010000:al/on} } } The MGC responds to the Notify generated by MG. Step 11: MGC to MG1: MEGACO/1 [216.33.33.61]: 27000 Reply = 2002 { Context = - { Notify = TermA } } The MGC sends a Modify command towards that RGW1 for the Termination TermA as shown in step 1 that takes the termination TermA to idle state. In this state the RGW1 is again ready to detect events on the termination TermA. 2.2 Call between Residential Gateway and Trunking Gateway In the earlier section we illustrated the call between two users UserA and UserB connected to residential gateways RGW1 and RGW2. In this section we illustrate the call flow between a Residential gateway user and a Trunking gateway. In this flow, the packages that are supported by the RGW are analog line supervision package, RTP package, generic package, DTMF detection package, and Call progress generator package, Network Package. The Trunking gateway is supports RTP package, generic package, and network package. We are not assuming any specific signaling to the other side of the Trunking gateway. This makes call flow simple and independent of the type of signaling towards the other side of the Trunking gateway. Madhubabu, et al. [Page 24] Internet-Draft Megaco/H.248 Call flow examples July 2001 _________________________________________________ | | | USERA | RGW1 | MGC | TGW _____________|___________|___________|___________ | | | | | | | | | |<----------| | | |Modify to | | | |check offhook | | |---------->| | | |Modify Resp| | |----------->| | | |UserA offhook | | | |---------->| | | |Notify offhook | | |<----------| | | |Notify Resp| | | |<----------| | | |Modify SG:dialtone | | |ED:al/on,dd/ce{Dmap1} | | |DM:Dmap1 = 2XXX | |<-----------| | | |Dial Tone |---------->| | | |Modify Resp| | | | | | |----------->| | | |User Dials Digits | | | |---------->| | | |Notify digits | | |<----------| | | |Notify Response | | |<----------| | | | Add TermA SD:ringbacktone | | Add $, Local SDP Info -underspecified |<-----------| | | |RingBack Tone | | | |---------->| | | |Modify Resp TermA | | |Add Resp Local SDP (Specified) | | |---------->| | | |Add Phy | | | |Add $ Local(Underspecified) | | | Remote SDP (Specified) | | |<----------| | | |Add Resp Phy Madhubabu, et al. [Page 25] Internet-Draft Megaco/H.248 Call flow examples July 2001 | | |Add Resp EphB Local Specified | |<----------| | | |Modify TermA SendRecv | | |Modify EphA Remote(Specified) SendRecv | |---------->| | | |Modify Resp| | |/----------------------------------\| | RTP MEDIA | |\----------------------------------/| |----------->| | | |UserA goes OnHook | | | |---------->| | | |Notify OnHook | | |<----------| | | |Notify Resp| | | |<----------| | | |Subtract TermA | | |Subtract EphA | | |---------->| | | |Subtract Resp TermA | | |Subtract Resp EphA Statistics | | |Subtract Phy | | |Subtract EphB | | |<----------| | | |Subtract Resp Phy | | |Subtract Resp EphB Statis |____________|___________|___________| The MGC generates modify command for to the residential gateway to check for offhook for Termination TermA. In this message the event offhook has an embedded signal descriptor and embedded event descriptor. The embedded signal descriptor is sent for application of dial tone immediately after the detection of the offhook event and the event descriptor then will be updated with the onhook and the digit map completion event. The Digit map is also defined in the digit map descriptor. Step 1 MGC to RGW: MEGACO/1 [216.33.33.61]:27000 Transaction = 1234 { Context = - { Modify = TermA { Media { LocalControl { Mode = Receiveonly} }, DigitMap= Dmap1 {(2XXX)} Events = 1111 {al/of Embed {signals {cg/dt}, Events=1112 {al/on}, Madhubabu, et al. [Page 26] Internet-Draft Megaco/H.248 Call flow examples July 2001 {dd/ce {Dmap1}}} } } } The MG after receiving the MGC's message responds to it. Step 2 RGW to MGC: MEGACO/1 [209.110.59.34]: 25000 Reply = 1234 { Context = - {Modify = TermA} } When the user A goes offhook RGW detects the offhook event and as it is listed in the event descriptor report the event detection using Notify command. Step 3 RGW to MGC: MEGACO/1 [209.110.59.34]:25000 Transaction = 2000 { Context = - { Notify = TermA {ObservedEvents =1111 { 20010202T10000000:al/of}} } } the MGC responds with the Notify response. Step 4 MGC to RGW: MEGACO/1 [216.33.33.61]: 27000 Reply = 2000 { Context = - {Notify = TermA} } The user gets Dial tone as part of Embedded descriptor processing. The digit map is active on the termination TermA. When the user dials the digits they are reported to MGC through Notify command. Step 5 RGW to MGC: MEGACO/1 [209.110.59.34]: 25000 Transaction = 2001 { Context = - { Notify = TermA {ObservedEvents =1112 { 20010202T10010000:dd/ce {ds="2992", Meth=FM}}} } } Madhubabu, et al. [Page 27] Internet-Draft Megaco/H.248 Call flow examples July 2001 MGC after receiving the Notify command responds back with the Notify response. Step 6 MGC to RGW: MEGACO/1 [216.33.33.61]: 27000 Reply = 2001 { Context = - {Notify = TermA} } The MGC generates the Add command for adding the physical termination TermA and to create an ephemeral termination EphA. The local SDP information for the ephemeral termination EphA is under specified to enable the RGW to allocate the necessary values by itself. The mode of the two terminations is set to receive only. Step 7 MGC to RGW: MEGACO/1 [216.33.33.61]: 27000 Transaction = 1235 { Context = $ { Add = TermA { Signals {cg/rt} Media { { LocalControl { Mode = ReceiveOnly, }, } Add = $ { Media { { LocalControl { Mode = ReceiveOnly, }, Local { v=0 c=IN IP4 $ m=audio $ RTP/AVP 4 } } } } } MG after creating the context adds the physical termination TermA. In this case MG creates a context with ContextId 1. The ephemeral termination EphA is created and added to the context 1. The MG reserves resources for the local SDP information. In this case the IP address allocated is 209.110.59.33 and the port number used is 30000. The MG responds to the Add command with this information in Madhubabu, et al. [Page 28] Internet-Draft Megaco/H.248 Call flow examples July 2001 the response to MGC. Step 8 RGW to MGC: MEGACO/1 [209.110.59.34]: 25000 Reply = 1235 { Context = 1 { Add = TermA, Add=EphA { Media { Local { v=0 c=IN IP4 209.110.59.33 m=audio 30000 RTP/AVP 4 a=recvonly }; RTP profile for G.723 is 4 } } } } } In this example as mentioned earlier we doesn't assume any specific signaling in the other side of the Trunking gateway. This eliminates the complexity of reporting the address information and alerting the end user. The MGC then "Adds" a physical termination. The wildcard $ is used here to enable the Trunking gateway to choose one of its trunks on the other side of the Trunking gateway. The ephemeral termination is requested to create with the under specified SDP local information and the remote SDP information. Step 9 MGC to TGW MEGACO/1 [216.33.33.61]: 27000 Transaction = 1236 { Context = $ { Add = Trunk1/$ {Media { LocalControl {Mode = SendRecv}}, }, Add = $ {Media { LocalControl { Mode = Receiveonly, }, Local { v=0 c=IN IP4 $ m=audio $ RTP/AVP 4 }, Remote { v=0 Madhubabu, et al. [Page 29] Internet-Draft Megaco/H.248 Call flow examples July 2001 c=IN IP4 209.110.59.33 m=audio 30000 RTP/AVP 4 } ; RTP profile for G.723 is 4 } } } } } The Trunking gateway then processes the command and does the necessary signaling towards the other side of the Trunking gateway. The seized trunk identifier is returned in the Add response for physical termination. In the response for the ephemeral termination, the TGW returns the local information of the ephemeral termination created. In this example the TGW creates a context with ContextID 2. Step 10 TGW to MGC: MEGACO/1 [207.176.47.89]: 26000 Reply = 1236 { Context = 2 { Add = Trunk1/line1, Add = EphB{ Media { Local { v=0 c=IN IP4 207.176.47.90 m=audio 40000 RTP/AVP 4 } } ; RTP profile for G723 is 4 } } } As mention earlier, How the MGC receives the indication about the status of the end user is out of scope of this call flow. But once the MGC receives the users status it forwards the remote SDP information for the RGW and change the mode for the termination both at RGW and TGW to SendRecv. Step 11 MGC to RGW: MEGACO/1 [216.33.33.61]: 27000 Transaction = 1237 { Context = 1 { Modify = TermA { Media { LocalControl { Mode = sendrecv} } } Madhubabu, et al. [Page 30] Internet-Draft Megaco/H.248 Call flow examples July 2001 Signals { } }, Modify = EphA { Media { LocalControl { Mode = sendrecv} Remote { v=0 c=IN IP4 207.176.47.90 m=audio 40000 RTP/AVP 4 } } ; RTP profile for G723 is 4 } } } } The RGW after receiving the Modify command from MGC responds back with the response. Step 12 RGW to MGC: MEGACO/1 [209.110.59.34]: 25000 Reply = 1237 { Context = 1 {Modify = TermA, Modify = EphA} } The MGC also generates commands to the TGW to change the mode of the Ephemeral termination to send receive. Thus enabling the virtual voice path between the two ephemeral terminations. Step 13 MGC to TGW: MEGACO/1 [216.33.33.61]: 27000 Transaction = 1238 { Context = 2 { Modify = Trunk1/line1 { Media { LocalControl { Mode = sendrecv} } } }, Modify = EphB { Media { LocalControl { Mode = sendrecv} } } } } Madhubabu, et al. [Page 31] Internet-Draft Megaco/H.248 Call flow examples July 2001 The TGW after receiving the mode change information in Modify command responds to it. Step 14 TGW to MGC: MEGACO/1 [207.176.47.89]: 26000 Reply = 1238 { Context = 2 {Modify = Trunk1/line1, Modify = EphB} } Now RTP media flow takes place. In the example the UserA goes onhook to terminate the call. The RGW after detecting the event reports the same to MGC in the Notify command. Step 15: RGW to MGC: MEGACO/1 [209.110.59.34]: 25000 Transaction = 2002 { Context = 1 { Notify = TermA {ObservedEvents =1112 { 20010202T10030000:al/on} } } } The MGC responds to the MG1s Notify message. Step 16 MGC to MG1: MEGACO/1 [216.33.33.61]: 27000 Reply = 2002 { Context = 1 { Notify = TermA } } The MGC now generates subtract commands both to the RGW and the TGW. The mechanism of generating call progress tone towards the called user is not shown for simplicity. The two Subtract commands are clubbed in a single action. Step 17 MGC to RGW MEGACO/1 [216.33.33.61]: 27000 Transaction = 1239 { Context = 1 { Subtract = TermA {Audit{ }}, Subtract = EphA {Audit{Statistics}} } } The MG subtracts the two terminations from the context. The context itself is deleted with the subtract of the last termination from it. The MG1 responds to this transaction from MGC with statistics on ephemeral termination. Madhubabu, et al. [Page 32] Internet-Draft Megaco/H.248 Call flow examples July 2001 Step 18 RGW to MGC: MEGACO/1 [209.110.59.34]:25000 Reply = 1239 { Context = 1 { Subtract = TermA Subtract = EphA { Statistics { rtp/ps=1234, ; packets sent nt/os=56789, ; octets sent rtp/pr=987, ; packets received nt/or=65432, ; octets received rtp/pl=10, ; % packets lost rtp/jit=30, rtp/delay=30 ; average latency } } } } The MGC generates similar command towards the TGW Step 19 MGC to TGW: MEGACO/1 [216.33.33.61]: 27000 Transaction = 1240 { Context = 2 { Subtract = Trunk1/line1{Audit{ }}, Subtract = EphB {Audit{Statistics}} } } The TGW responds to the subtract commands generated by MGC. Step 26 TGW to MGC: MEGACO/1 [209.110.59.34]:25000 Reply = 1240 { Context = 2 { Subtract = Trunk1/line1 Subtract = EphB { Statistics { rtp/ps=987, ; packets sent nt/os=65432, ; octets sent rtp/pr=1234, ; packets received nt/or=56789, ; octets received rtp/pl=10, ; % packets lost rtp/jit=30, rtp/delay=30 ; average latency } } Madhubabu, et al. [Page 33] Internet-Draft Megaco/H.248 Call flow examples July 2001 } } 2.3 Call between Trunking gateway and Residential Gateway The earlier section illustrated the call between a residential user and a Trunking gateway. The call was initiated by the Residential gateway. In this call scenario we will illustrate the case where the call terminates on the Residential gateway when originated by the Trunking gateway. Even in this call flow we will assume that signaling beyond the Trunking gateway is taken care by an external entity, to avoid CAS/CCS specific details. ___________________________________________________________ | | | TGW | MGC | RGW1 | USERB _________ ___|___________|______________|_________________ | | | | | | | | |<----------| | | | Add Phy SD:ringbacktone | | Add $, Local SDP Info -underspecified | |---------->| | | |Add Resp Phy | | |Add Resp Local SDP (Specified) | | |---------->| | | |Add TermB SD:Ring ED:offhook | | |Add $ Local(Underspecified) | | | Remote SDP (Specified) | | | | | | | |------------------>| | | | UserB Phone Ringing | |<----------| | | |Add Resp TermB | | |Add Resp EphB Local Specified | | | |<------------------| | | |UserB goes Offhook | | |<----------| | | |Notify Offhook | | |---------->| | | | Notify Resp | |<----------| | | |Modify Phy SendRecv | | |Modify EphA Remote(Specified) SendRecv | |---------->| | | |Modify Resp| | | | |---------->| | | |Modify Phy SendRecv | | |Modify EphB SendRecv | Madhubabu, et al. [Page 34] Internet-Draft Megaco/H.248 Call flow examples July 2001 | |<----------| | | |Modify Resp| | |/-----------------------------------------\| | RTP MEDIA | |\-----------------------------------------/| | |---------->| | | |Modify TermB SD:BusyTone | | | |------------------>| | | | Busy tone to UserB| | |<----------| | | |Modify Resp| | |<----------| | | |Subtract Phy | | |Subtract EphA | | |---------->| | | |Subtract Resp Phy | | |Subtract Resp EphA Statistics | | | |<------------------| | | | UserB goes Onhook | | |<----------| | | |Notify Onhook | | |---------->| | | |Notify Resp| | | |---------->| | | |Subtract TermB | | |Subtract EphB | | |<----------| | | |Subtract Resp TermB | | |Subtract Resp EphB Statistics | |___________|___________|___________________| The Media Gateway controller is intimated about the call initiation from the other side of the Trunking gateway. The MGC then indicates the TGW to seize a trunk using the Add command with $ (choose) wildcard. The MGC also requests for creation of an ephemeral termination using another Add command in the same action request. The Context Id specified by MGC is $ indicating that the TGW needs to create a context and "Add" these terminations in the new context. Step 1 MGC to TGW: MEGACO/1 [216.33.33.61]: 27000 Transaction = 1234 { Context = $ { Add = Trunk1/$ {Media { LocalControl {Mode = recvonly}}, }, Add = $ {Media { LocalControl { Mode = Receiveonly, }, Madhubabu, et al. [Page 35] Internet-Draft Megaco/H.248 Call flow examples July 2001 Local { v=0 c=IN IP4 $ m=audio $ RTP/AVP 4 } } } } } } The TGW after receiving the Add request from MGC creates a context. In this example the ContextID allocated for the new context is 2. The physical termination chosen by the TGW is Trunk1/line1. The mode of the termination is set to Receiveonly. The TGW creates an ephemeral termination with the SDP information specified by MGC. The response contains all the specified values for the SDP information. To avoid complexity in this call flow no reserve group and reserve value properties are used. It should be assumed that they are all "OFF". In this example the TGW reserved 207.176.47.90 as the IP address for the RTP media stream and port number as 40000. Step 2: TGW to MGC: MEGACO/1 [207.176.47.89]: 26000 Reply = 1234 { Context = 2 { Add = Trunk1/line1, Add = EphA{ Media { Local { v=0 c=IN IP4 207.176.47.90 m=audio 40000 RTP/AVP 4 } } ; RTP profile for G723 is 4 } } } The MGC after receiving the response from TGW initiates the UserB alerting towards the RGW. This is done by MGC in the ADD command for the physical termination TermB. The MGC uses $ contextID. Indicating the creation of Context at MG. The Ephemeral termination is requested to create. The Remote SDP information is also passed as the parameters in the media descriptor. The signal descriptor in the Add command for physical termination enables RGW to apply the ring signal on the termination TermB. Madhubabu, et al. [Page 36] Internet-Draft Megaco/H.248 Call flow examples July 2001 Step 3 MGC to RGW: MEGACO/1 [216.33.33.61]: 27000 Transaction = 1235 { Context = $ { Add = TermB { Signals { al/ri } Events= 1111 { al/of Events = 1112 { al/on } } Media { { LocalControl { Mode = ReceiveOnly, }, } Add = $ { Media { { LocalControl { Mode = ReceiveOnly, }, Local { v=0 c=IN IP4 $ m=audio $ RTP/AVP 4 } remote { v=0 c=IN IP4 207.176.47.90 m=audio 40000 RTP/AVP 4 } } ; RTP profile for G723 is 4 } } } The RGW after receiving the transaction request from MGC first creates a context. In this example the contextID allocated is 1. The RGW "adds" the termination TermB to context 1 and as part of the signal descriptor processing applies the "ring" signal on the termination. The Events descriptor lists the offhook event of analog line supervision package. The requestId specified in this example is 1111. The RGW also creates the ephemeral termination EphB. Whose remote SDP information is specified by MGC and the local SDP information is allocated and reserved by RGW. In this example the RGW allocates an IP address of 209.110.59.33 and port number 30000. The mode of the ephemeral termination is set to receive only. Step 4 RGW to MGC: Madhubabu, et al. [Page 37] Internet-Draft Megaco/H.248 Call flow examples July 2001 MEGACO/1 [209.110.59.34]: 25000 Reply = 1235 { Context = 1 { Add = TermB, Add=EphB { Media { Local { v=0 c=IN IP4 209.110.59.33 m=audio 30000 RTP/AVP 4 a=recvonly } ; RTP profile for G.723 is 4 } } } } } The UserB goes Offhook after hearing the "ring" signal. The offhook event is reported to the MGC as observed event descriptor in Notify command. Step 5 RGW to MGC: MEGACO/1 [209.110.59.34]: 25000 Transaction = 2000 { Context = 1 { Notify = TermB {ObservedEvents =1111 { 20010202T10001000:al/of}} } } The MGC responds with the Notify response. Step 6 MGC to RGW: MEGACO/1 [216.33.33.61]: 27000 Reply = 2000 { Context = - {Notify = TermB} } The MGC now generates commands to both RGW and TGW. These commands are generated to modify the mode of the physical and ephemeral terminations towards both RGW and TGW. Step 7: MGC to RGW MEGACO/1 [216.33.33.61]: 27000 Transaction = 1236 { Context = 1 { Modify = TermB { Media { Madhubabu, et al. [Page 38] Internet-Draft Megaco/H.248 Call flow examples July 2001 LocalControl { Mode = sendrecv} } } Modify = EphB { Media { LocalControl { Mode = sendrecv} } } } } The RGW responds with the Transaction response for the commands sent for both physical and ephemeral termination. Step 8 RGW to MGC: MEGACO/1 [209.110.59.34]: 25000 Reply= 1236 { Context = 1 { Modify = TermB {} Modify = EphB { } } } The MGC also generates similar command towards the Trunking gateway. The MGC in the Modify for the ephemeral termination also specifies the remote SDP information, and this enables the TGW to change the mode of the terminations to send and receive. Step 9 MGC to TGW: MEGACO/1 [216.33.33.61]: 27000 Transaction = 1237 { Context = 2 { Modify = Trunk1/line1 { Media { LocalControl { Mode = SendRecv} } } Modify = EphA { Media { LocalControl { Mode = SendRecv} Remote { v=0 c=IN IP4 207.176.47.90 m=audio 40000 RTP/AVP 4 } Madhubabu, et al. [Page 39] Internet-Draft Megaco/H.248 Call flow examples July 2001 } ; RTP profile for G723 is 4 } } } } The Trunking gateway responds to the MGC message and changes the mode for both the terminations to Send and receive. Step 10 TGW to MGC: MEGACO/1 [207.176.47.89]: 26000 Reply = 1237 { Context = 2 { Modify = Trunk1/line1, Modify = EphA { } } } Once both the terminations mode is change to send receive the two users can start the conversation. The media stream is established. The user to the other side of the Trunking gateway terminates the Call. The MGC is updated with this information by the external entity. The MGC generates a busy signal towards UserB connected to the RGW. Step 11 MGC to RGW: MEGACO/1 [216.33.33.61]:27000 Transaction = 1238 { Context = 1 { Modify = TermB { Signals { cg/bt } } } } } The RGW as part of signal descriptor processing plays the busy tone towards the UserB termination TermB. The response is generated after processing the command from MGC. Step 12 RGW to MGC: MEGACO/1 [209.110.59.34]: 25000 Reply = 1238 { Context = 1 { Modify = TermB { } } } Madhubabu, et al. [Page 40] Internet-Draft Megaco/H.248 Call flow examples July 2001 The MGC terminates the call by generating Subtract command for both the terminations in TGW and RGW. Step 13 MGC to TGW: MEGACO/1 [216.33.33.61]: 27000 Transaction = 1239 { Context = 2 { Subtract = Trunk1/line1{Audit{ }}, Subtract = EphA {Audit{Statistics}} } } The TGW responds with the Statistics in the Subtract response for the ephemeral termination. The context is created as an side effect of deleting both the terminations in the context. Step 14: TGW to MGC: MEGACO/1 [207.176.47.89]:26000 Reply = 1239 { Context = 2 { Subtract = Trunk1/line1 Subtract = EphA { Statistics { rtp/ps=987, ; packets sent nt/os=65432, ; octets sent rtp/pr=1234, ; packets received nt/or=56789, ; octets received rtp/pl=10, ; % packets lost rtp/jit=30, rtp/delay=30 ; average latency } } } } The MGC generates similar command towards the RGW to delete the physical and ephemeral terminations. Step 15 MGC to RGW: MEGACO/1 [216.33.33.61]: 27000 Transaction = 1240 { Context = 1 { Subtract = TermB {Audit{ }}, Subtract = EphB {Audit{Statistics}} } } The RGW responds with the statistics for the ephemeral termination in the Subtract response. Madhubabu, et al. [Page 41] Internet-Draft Megaco/H.248 Call flow examples July 2001 Step 16 RGW to MGC: MEGACO/1 [209.110.59.34]:25000 Reply = 1240 { Context = 1 { Subtract = TermB Subtract = EphB { Statistics { rtp/ps=1234, ; packets sent nt/os=56789, ; octets sent rtp/pr=987, ; packets received nt/or=65432, ; octets received rtp/pl=10, ; % packets lost rtp/jit=30, rtp/delay=30 ; average latency } } } } The Call is terminated with the response received from RGW. The MGC generates the initial Modify command to check for offhook on the termination TermB. This takes the termination TermB to idle state and the UserB is ready to ready to generate and receive further calls. 2.4 Call between two Trunking gateways The earlier three sections illustrated the calls between two residential gateways, and between residential gateway and Trunking gateway. This two Trunking gateway call flow scenario illustrates call between two users connected to the other side of the Trunking gateway. Even in this scenario to avoid unnecessary complexity we still assume that some external entity conveys the necessary signaling information to the MGC to enable it to control the two Trunking gateways. The CAS/CCS signaling details towards the other side of the each Trunking gateway is avoided for simplicity. This boils down to the message generation from MGC for enabling media flow. No signaling is done on either the physical or ephemeral termination. __________________________________________________________ | | | TGW1 | MGC | RGW1 | TGW2 _________ ___|___________|______________|_________________ | | | | | | | | |<----------| | | | Add Phy SD:ringbacktone | | Add $, Local SDP Info -underspecified | |---------->| | | Madhubabu, et al. [Page 42] Internet-Draft Megaco/H.248 Call flow examples July 2001 |Add Resp Phy | | |Add Resp Local SDP (Specified) | | |---------->| | | |Add Phy SD:Ring ED:offhook | | |Add $ Local(Underspecified) | | | Remote SDP (Specified) | | | | | | |<----------| | | |Add Resp Phy | | |Add Resp EphB Local Specified | |<----------| | | |Modify Phy SendRecv | | |Modify EphA Remote(Specified) SendRecv | |---------->| | | |Modify Resp| | | | |---------->| | | |Modify Phy SendRecv | | |Modify EphB SendRecv | | |<----------| | | |Modify Resp| | |/-----------------------------------------\| | RTP MEDIA | |\-----------------------------------------/| |<----------| | | |Subtract Phy | | |Subtract EphA | | |---------->| | | |Subtract Resp Phy | | |Subtract Resp EphA Statistics | | |---------->| | | |Subtract Phy | | |Subtract EphB | | |<----------| | | |Subtract Resp Phy | | |Subtract Resp EphB Statistics | |___________|___________|___________________| When the MGC receives the call establishment from one side of the Trunking gateway it generates two ADD commands in a single action. The action request includes creation of Context, choosing of physical termination and adding the same to the context created and creating of ephemeral termination and adding this to the newly created context. The local SDP parameters are under specified. The TGW1 in its response need to specify these under specified parameters. Step 1 MGC to TGW1: MEGACO/1 [216.33.33.61]: 27000 Transaction = 1234 { Context = $ { Add = Trunk1/$ {Media { Madhubabu, et al. [Page 43] Internet-Draft Megaco/H.248 Call flow examples July 2001 LocalControl {Mode = recvonly}}, }, Add = $ {Media { LocalControl { Mode = Receiveonly, }, Local { v=0 c=IN IP4 $ m=audio $ RTP/AVP 4 } } } } } } The TGW after receiving the Add request from MGC creates a context. In this example the ContextID allocated for the new context is 1. The physical termination chosen by the TGW is Trunk1/line1. The mode of the termination is set to Receiveonly. The TGW creates an ephemeral termination with the SDP information specified by MGC. The response contains all the specified values for the SDP information. To avoid complexity in this call flow no reserve group and reserve value properties are used. It should be assumed that they are all "OFF". In this example the TGW reserved 209.110.59.33 as the IP address for the RTP media stream and port number as 40000. Step 2: TGW1 to MGC: MEGACO/1 [209.110.59.34]: 25000 Reply = 1234 { Context = 1 { Add = Trunk1/line1, Add = EphA{ Media { Local { v=0 c=IN IP4 209.110.59.33 m=audio 40000 RTP/AVP 4 } } ; RTP profile for G723 is 4 } } } In this example as mentioned earlier it doesn't assume any specific signaling in the other side of the Trunking gateway. Thus this eliminates the complexion of reporting the address information and alerting the end user. The MGC hence "Adds" a physical termination. The wildcard $ is used here to enable the Trunking gateway to choose Madhubabu, et al. [Page 44] Internet-Draft Megaco/H.248 Call flow examples July 2001 one of its trunks on the other side of the Trunking gateway. The ephemeral termination is requested to create with the under specified SDP local information and the remote SDP information. Step 3 MGC to TGW2: MEGACO/1 [216.33.33.61]: 27000 Transaction = 1235 { Context = $ { Add = Trunk2/$ {Media { LocalControl {Mode = SendRecv}}, }, Add = $ {Media { LocalControl { Mode = Receiveonly, }, Local { v=0 c=IN IP4 $ m=audio $ RTP/AVP 4 }, Remote { v=0 c=IN IP4 209.110.59.33 m=audio 40000 RTP/AVP 4 } ; RTP profile for G.723 is 4 } } } } } The Trunking gateway2 then process the command and does the necessary signaling towards the other side of the Trunking gateway. The seized trunk identifier is returned in the Add response for physical termination. In the response for the ephemeral termination, the TGW returns the local information of the ephemeral termination created. In this example the TGW creates a context with ContextID 2. Step 4 TGW2 to MGC: MEGACO/1 [207.176.47.89]: 26000 Reply = 1235 { Context = 2 { Add = Trunk2/line1, Add = EphB{ Media { Local { v=0 c=IN IP4 207.176.47.90 m=audio 40000 RTP/AVP 4 Madhubabu, et al. [Page 45] Internet-Draft Megaco/H.248 Call flow examples July 2001 } } ; RTP profile for G723 is 4 } } } Once these MGC receives the answer of the call by the end user (through an entity outside the scope of the flow), changes the mode of the termination towards the both Trunking gateways. The MGC also indicates the remote SDP information for the TGW1.Thus enabling the exchange of media parameter information to both the Trunking gateways. Step 5 MGC to TGW1: MEGACO/1 [216.33.33.61]: 27000 Transaction = 1236 { Context = 1 { Modify = Trunk1/line1 { Media { LocalControl { Mode = SendRecv} } } Modify = EphA { Media { LocalControl { Mode = SendRecv} Remote { v=0 c=IN IP4 207.176.47.90 m=audio 40000 RTP/AVP 4 } } ; RTP profile for G723 is 4 } } } } The TGW1 after receiving the command from MGC does the necessary processing to update and processing the remote SDP information. The mode of the terminations is modified to send receive. The response of the transaction is sent back to MGC. Step 6 TGW1 to MGC: MEGACO/1 [209.110.59.34]: 25000 Reply = 1236 { Context = 1 { Modify = Trunk1/line1, Modify = EphA { } } Madhubabu, et al. [Page 46] Internet-Draft Megaco/H.248 Call flow examples July 2001 } Similar command is generated from the MGC towards the second Trunking gateway. Step 7 MGC to TGW1: MEGACO/1 [216.33.33.61]: 27000 Transaction = 1237 { Context = 2 { Modify = Trunk2/line1 { Media { LocalControl { Mode = sendrecv} } } }, Modify = EphB { Media { LocalControl { Mode = sendrecv} } } } } The TGW2 after receiving the mode change information in Modify command responds to it. Step 8 TGW1 to MGC: MEGACO/1 [209.110.59.34]: 25000 Reply = 1237 { Context = 2 {Modify = Trunk1/line1, Modify = EphB} } The RTP media flow takes place once the modes of the terminations are changed to send receive. The MGC is intimated about the call clearing from an external entity. The MGC then generates subtract commands to both the TGWs. Step 9 MGC to TGW2: MEGACO/1 [216.33.33.61]: 27000 Transaction = 1238 { Context = 1 { Subtract = Trunk1/line1{Audit{ }}, Subtract = EphA {Audit{Statistics}} } } The TGW responds with the Statistics in the Subtract response for the ephemeral termination. The context is created as an side effect of deleting both the terminations in the context. Madhubabu, et al. [Page 47] Internet-Draft Megaco/H.248 Call flow examples July 2001 Step 10: TGW2 to MGC: MEGACO/1 [207.176.47.89]:26000 Reply = 1238 { Context = 1 { Subtract = Trunk1/line1 Subtract = EphA { Statistics { rtp/ps=987, ; packets sent nt/os=65432, ; octets sent rtp/pr=1234, ; packets received nt/or=56789, ; octets received rtp/pl=10, ; % packets lost rtp/jit=30, rtp/delay=30 ; average latency } } } } A similar command is generated from the MGC towards the second TGW. Step 11 MGC to TGW: MEGACO/1 [216.33.33.61]: 27000 Transaction = 1239 { Context = 2 { Subtract = Trunk2/line1{Audit{ }}, Subtract = EphB {Audit{Statistics}} } } The TGW responds to the subtract commands generated by MGC. Step 12 TGW to MGC: MEGACO/1 [209.110.59.34]:25000 Reply = 1239 { Context = 2 { Subtract = Trunk2/line1 Subtract = EphB { Statistics { rtp/ps=1234, ; packets sent nt/os=56789, ; octets sent rtp/pr=987, ; packets received nt/or=65432, ; octets received rtp/pl=10, ; % packets lost rtp/jit=30, rtp/delay=30 ; average latency } } } } The two Trunking gateways are now ready to receive further commands Madhubabu, et al. [Page 48] Internet-Draft Megaco/H.248 Call flow examples July 2001 from MGC. The terminations are present in the idle state. 2.5 Call between Residential gateway and SS7 trunk in TGW The calls flow scenarios from 2.2 to 2.4 illustrated the Trunking gateway without considering the signaling performed at the other side of the Trunking gateway. In this section we will illustrate the call flow scenario similar to the one in section 2.2. The emphasis here will be both on the Megaco messages exchanged between MG and MGC and also the signaling that towards the other side of the Trunking gateway. Here in this example the CCS SS7 is assumed. The packages that supported are Call progress tone generation package, analog line supervision package, generic package, RTP package and Network package for the RGW and Network and RTP package for the TGW. _____________________________________________________________________ | | | | USERA | RGW1 | MGC | TGW | SS7 Switch _____________|___________|___________|______________|________________ | | | | | | | | | | | |<----------| | | | |Modify to | | | | |check offhook | | | |---------->| | | | |Modify Resp| | | |----------->| | | | |UserA offhook | | | | |---------->| | | | |Notify offhook | | | |<----------| | | | |Notify Resp| | | | |<----------| | | | |Modify SG:dialtone | | | |ED:al/on,dd/ce{Dmap1} | | | |DM:Dmap1 = 2XXX | | |<-----------| | | | |Dial Tone |---------->| | | | |Modify Resp| | | | | | | | |----------->| | | | |User Dials Digits | | | | |---------->| | | | |Notify digits | | | |<----------| --------------------------->| | |Notify Response IAM | Madhubabu, et al. [Page 49] Internet-Draft Megaco/H.248 Call flow examples July 2001 | |<----------| | | | | Add TermA SD:ringbacktone | | | Add $, Local SDP Info -underspecified | |<-----------| | | | |RingBack Tone |<----------------------------| | |---------->| ACM | | |Add Resp TermA | | | |Add Resp Local SDP (Specified) | | | |---------->| | | | |Add Phy | | | | |Add $ Local(Underspecified) | | | | Remote SDP (Specified) | | | |<----------------------------| | | | ANM | | | |<----------| | | | |Add Resp Phy | | | |Add Resp EphB Local Specified| | |<----------| | | | |Modify TermA SendRecv | | | |Modify EphA Remote(Specified) SendRecv | | |---------->| | | | |Modify Resp| | | |/----------------------------------\| | | RTP MEDIA | | |\----------------------------------/| | |----------->| | | | |UserA goes OnHook | | | | |---------->| | | | |Notify OnHook | | | |<----------| | | | |Notify Resp| | | | |<----------| | | | |Subtract TermA | | | |Subtract EphA | | | | |---------------------------->| | | | REL | | |---------->| | | | |Subtract Resp TermA | | | |Subtract Resp EphA Statistics | | | |---------->| | | | |Subtract Phy | | | |Subtract EphB | | | |<----------------------------| | | | RLC | | | |<----------| | | | |Subtract Resp Phy | | | |Subtract Resp EphB Statis | |____________|___________|___________|_________________| Madhubabu, et al. [Page 50] Internet-Draft Megaco/H.248 Call flow examples July 2001 The MGC generates modify command for to the residential gateway to check for offhook for Termination TermA. In this message the event offhook has an embedded signal descriptor and embedded event descriptor. The embedded signal descriptor is sent for application of dial tone immediately after the detection of the offhook event and the event descriptor then will be updated with the onhook and the digit map completion event. The Digit map is also defined in the digit map descriptor. Step 1 MGC to RGW: MEGACO/1 [216.33.33.61]:27000 Transaction = 1234 { Context = - { Modify = TermA { Media { LocalControl { Mode = ReceiveOnly} }, DigitMap= Dmap1{(2XXX)} Events = 1111 {al/of Embed { signals {cg/dt}, Events=1112 { al/on}, {dd/ce {Dmap1}}} } } } The MG after receiving the MGC's message responds to it. Step 2 RGW to MGC: MEGACO/1 [209.110.59.34]: 25000 Reply = 1234 { Context = - {Modify = TermA} } When the user A goes offhook RGW detects the offhook event and as it is listed in the event descriptor reports the event detection using Notify command. Step 3 RGW to MGC: MEGACO/1 [209.110.59.34]:25000 Transaction = 2000 { Context = - { Notify = TermA {Observed Events =1111 { 20010202T10000000:al/of}} } } the MGC responds with the Notify response. Step 4 Madhubabu, et al. [Page 51] Internet-Draft Megaco/H.248 Call flow examples July 2001 MGC to RGW: MEGACO/1 [216.33.33.61]: 27000 Reply = 2000 { Context = - {Notify = TermA} } The digit map is active on the termination TermA. When the user dials the digits the they are reported to MGC through Notify command. Step 5 RGW to MGC: MEGACO/1 [209.110.59.34]: 25000 Transaction = 2001 { Context = - { Notify = TermA {ObservedEvents =1112 { 20010202T10010000:dd/ce{ds="2992",Meth=FM}}} } } MGC after receiving the Notify command responds back with the Notify response. Step 6 MGC to RGW: MEGACO/1 [216.33.33.61]: 27000 Reply = 2001 { Context = - {Notify = TermA} } The MGC generates the Add command for adding the physical termination TermA and to create an ephemeral termination EphA. The local SDP information for the ephemeral termination EphA is under specified to enable the RGW to allocate the necessary values by itself. The mode of the two terminations is set to receive only. Step 7 MGC to RGW: MEGACO/1 [216.33.33.61]: 27000 Transaction = 1235 { Context = $ { Add = TermA { Signals {cg/rt} Media { { LocalControl { Mode = ReceiveOnly, }, } Add = $ { Media { Madhubabu, et al. [Page 52] Internet-Draft Megaco/H.248 Call flow examples July 2001 { LocalControl { Mode = ReceiveOnly, }, Local { v=0 c=IN IP4 $ m=audio $ RTP/AVP 4 } } } } } MG after creating the context adds the physical termination TermA. In this case MG creates a context with ContextId 1. The ephemeral termination EphA is created and added to the context 1. The MG reserves resources for the local SDP information. In this case the IP address allocated is 209.110.59.33 and the port number used is 30000. The MG responds to the Add command with this information in the response to MGC. Step 8 RGW to MGC: MEGACO/1 [209.110.59.34]: 25000 Reply = 1235 { Context = 1 { Add = TermA, Add=EphA{ Media { Local { v=0 c=IN IP4 209.110.59.33 m=audio 30000 RTP/AVP 4 a=recvonly } ; RTP profile for G.723 is 4 } } } } } In this example as mentioned earlier the CCS SS7 signaling is assumed towards the other side of the Trunking gateway. The IAM message is generated towards the SS7 switch, with the necessary information about the called party and calling party. The SS7 switch responds with ACM indicating that address complete message towards the Trunking gateway. When the ANM "answer" message is received the MGC Adds a physical termination. The wildcard $ is used here to enable the Trunking gateway to choose one of its trunks on the other side of the Trunking gateway. The ephemeral termination is requested to create with the under Madhubabu, et al. [Page 53] Internet-Draft Megaco/H.248 Call flow examples July 2001 specified SDP local information and the remote SDP information. Step 9 MGC to TGW MEGACO/1 [216.33.33.61]: 27000 Transaction = 1236 { Context = $ { Add = Trunk1/$ {Media { LocalControl {Mode = SendRecv}}, }, Add = $ {Media { LocalControl { Mode = Receiveonly, }, Local { v=0 c=IN IP4 $ m=audio $ RTP/AVP 4 }, Remote { v=0 c=IN IP4 209.110.59.33 m=audio 30000 RTP/AVP 4 } ; RTP profile for G.723 is 4 } } } } } The Trunking gateway then processes the command and does the necessary signaling towards the other side of the Trunking gateway. The seized trunk identifier is returned in the Add response for physical termination. In the response for the ephemeral termination, the TGW returns the local information of the ephemeral termination created. In this example the TGW creates a context with ContextID 2. Step 10 TGW to MGC: MEGACO/1 [207.176.47.89]: 26000 Reply = 1236 { Context = 2 { Add = Trunk1/line1, Add = EphB{ Media { Local { v=0 c=IN IP4 207.176.47.90 m=audio 40000 RTP/AVP 4 } Madhubabu, et al. [Page 54] Internet-Draft Megaco/H.248 Call flow examples July 2001 } ; RTP profile for G723 is 4 } } } As mention earlier MGC after receiving the ANM message to indicate the status of the end user it forwards the remote SDP information for the RGW and changes the mode for the termination both at RGW and TGW to SendRecv. Step 11 MGC to RGW: MEGACO/1 [216.33.33.61]: 27000 Transaction = 1237 { Context = 1 { Modify = TermA { Media { LocalControl { Mode = sendrecv} } } Signals { } }, Modify = EphA { Media { LocalControl { Mode = sendrecv} Remote { v=0 c=IN IP4 207.176.47.90 m=audio 40000 RTP/AVP 4 } } ; RTP profile for G723 is 4 } } } } The RGW after receiving the Modify command from MGC responds back with the response. Step 12 RGW to MGC: MEGACO/1 [209.110.59.34]: 25000 Reply = 1237 { Context = 1 {Modify = TermA, Modify = EphA} } The MGC also generates commands to the TGW to change the mode of the Ephemeral termination to send receive. Thus enabling the virtual voice path between the two ephemeral terminations. Madhubabu, et al. [Page 55] Internet-Draft Megaco/H.248 Call flow examples July 2001 Step 13 MGC to TGW: MEGACO/1 [216.33.33.61]: 27000 Transaction = 1238 { Context = 2 { Modify = Trunk1/line1 { Media { LocalControl { Mode = sendrecv} } } }, Modify = EphB { Media { LocalControl { Mode = sendrecv} } } } } The TGW after receiving the mode change information in Modify command responds to it. Step 14 TGW to MGC: MEGACO/1 [207.176.47.89]: 26000 Reply = 1238 { Context = 2 {Modify = Trunk1/line1, Modify = EphB} } Now RTP media flow takes place. In the example the UserA goes onhook to terminate the call. The RGW after detecting the event reports the same to MGC in the Notify command. Step 15: RGW to MGC: MEGACO/1 [209.110.59.34]: 25000 Transaction = 2002 { Context = 1 { Notify = TermA {ObservedEvents =1112 { 20010202T10030000:al/on} } } } The MGC responds to the RGWs Notify message. Step 16 MGC to RGW: MEGACO/1 [216.33.33.61]: 27000 Reply = 2002 { Context = 1 { Notify = TermA Madhubabu, et al. [Page 56] Internet-Draft Megaco/H.248 Call flow examples July 2001 } } The MGC now generates subtract commands both to the RGW and the TGW. The mechanism of generating call progress tone towards the called user is not shown for simplicity. The two Subtract commands are clubbed in a single action. Step 17 MGC to RGW MEGACO/1 [216.33.33.61]: 27000 Transaction = 1239 { Context = 1 { Subtract = TermA {Audit {}}, Subtract = EphA {Audit {Statistics}} } } The MG subtracts the two terminations from the context. The context itself is deleted with the subtract of the last termination from it. The MG1 responds to this transaction from MGC with statistics on ephemeral termination. Step 18 RGW to MGC: MEGACO/1 [209.110.59.34]:25000 Reply = 1239 { Context = 1 { Subtract = TermA Subtract = EphA { Statistics { rtp/ps=1234, ; packets sent nt/os=56789, ; octets sent rtp/pr=987, ; packets received nt/or=65432, ; octets received rtp/pl=10, ; % packets lost rtp/jit=30, rtp/delay=30 ; average latency } } } } The MGC generates a REL "release" message towards the SS7 switch. After receiving the RLC "release complete" message command is generated towards the TGW to subtract the two terminations from context. Step 19 MGC to TGW: MEGACO/1 [216.33.33.61]: 27000 Transaction = 1240 { Context = 2 { Subtract = Trunk1/line1{Audit{ }}, Madhubabu, et al. [Page 57] Internet-Draft Megaco/H.248 Call flow examples July 2001 Subtract = EphB {Audit{Statistics}} } } The TGW responds to the subtract commands generated by MGC. Step 26 TGW to MGC: MEGACO/1 [209.110.59.34]:25000 Reply = 1240 { Context = 2 { Subtract = Trunk1/line1 Subtract = EphB { Statistics { rtp/ps=987, ; packets sent nt/os=65432, ; octets sent rtp/pr=1234, ; packets received nt/or=56789, ; octets received rtp/pl=10, ; % packets lost rtp/jit=30, rtp/delay=30 ; average latency } } } } 2.6 Call between SS7 trunk in TGW and residential gateway In the earlier call scenario 2.5, we illustrated the call flow between MGC and MG considering the CCS SS7 signaling towards one side of the Trunking gateway. The residential Gateway user in that scenario initiated the call. In this scenario we illustrate similar situation with call initiated by a user connected to the PSTN network that originates SS7 signaling. The packages that are supported include Call progress tone generation package, analog line supervision package, generic package, RTP package and Network package for the RGW and Network and RTP package for the TGW. ______________________________________________________________________ | | | | SS7 Switch | TGW | MGC | RGW1 | USERB ____________|________ ___|___________|______________|_________________ | | | | | | | | | | |----------------------->| | | | IAM | | | |<-----------------------| | | | ACM | | | | | | | | | |<----------| | | Madhubabu, et al. [Page 58] Internet-Draft Megaco/H.248 Call flow examples July 2001 | | Add Phy | | | | | Add $, Local SDP Info -underspecified | | |---------->| | | | |Add Resp Phy | | | |Add Resp Local SDP (Specified) | | | |---------->| | | | |Add TermB SD:Ring ED:offhook | | | |Add $ Local(Underspecified) | | | | Remote SDP (Specified) | | | | | | | | | |------------------>| | | | | UserB Phone Ringing | | |<----------| | | | |Add Resp TermB | | | |Add Resp EphB Local Specified | | | | |<------------------| | | | |UserB goes Offhook | |<-----------------------| | | | ANM | | | | | |<----------| | | | |Notify Offhook | | | |---------->| | | | | Notify Resp | | |<----------| | | | |Modify Phy SendRecv | | | |Modify EphA Remote(Specified) SendRecv | | |---------->| | | | |Modify Resp| | | | | |---------->| | | | |Modify Phy SendRecv | | | |Modify EphB SendRecv | | | |<----------| | | | |Modify Resp| | | |/-----------------------------------------\| | | RTP MEDIA | | |\-----------------------------------------/| |----------------------->| | | | REL | | | | | |---------->| | | | |Modify TermB SD:BusyTone | | | | |------------------>| | | | | Busy tone to UserB| | | |<----------| | | | |Modify Resp| | | |<----------| | | | |Subtract Phy | | | |Subtract EphA | | | |---------->| | | | |Subtract Resp Phy | | | |Subtract Resp EphA Statistics | | | | |<------------------| Madhubabu, et al. [Page 59] Internet-Draft Megaco/H.248 Call flow examples July 2001 | | | | UserB goes Onhook | |<-----------------------| | | | RLC | | | | | |<----------| | | | |Notify Onhook | | | |---------->| | | | |Notify Resp| | | | |---------->| | | | |Subtract TermB | | | |Subtract EphB | | | |<----------| | | | |Subtract Resp TermB | | | |Subtract Resp EphB Statistics | |____________|___________|___________|___________________| We assume that the TGW and SG are in a single box, such that both signaling and Media adaptation is done by the same entity The Media Gateway controller is intimated about the call initiation from the other side of the Trunking gateway, when the SS7 message IAM is received. The MGC after receiving the IAM messages responds with the ACM message indicating that the called party address is sufficient to identify the end user. The ACM message is sent to the SS7 switch through the signaling gateway. The circuit to be used for media information is indicated by the SS7 message received by the MGC. The MGC generates the Modify command to the Residential gateway for application of "ring" signal to the user. The event descriptor in the Modify command lists the offhook event. Step 1 MGC to RGW: MEGACO/1 [216.33.33.61]: 27000 Transaction = 1234 { Context = - { Modify = TermA { Media { LocalControl { Mode = ReceiveOnly} }, Events = 1111 {al/of} Signals = {al/ri} ; For application of ring signal } } } The Residential gateway after receiving the Modify command responds with the Modify response. Step 2 RGW to MGC: Madhubabu, et al. [Page 60] Internet-Draft Megaco/H.248 Call flow examples July 2001 MEGACO/1 [209.110.59.34]: 25000 Reply = 1234 { Context = - {Modify = TermA} } The users after receiving the "ring" signal assume to go offhook. The same event is reported to the MGC in the notify command. Step 3 RGW to MGC: MEGACO/1 [209.110.59.34]:25000 Transaction = 2000 { Context = - { Notify = TermA {Observed Events =1111 { 20010202T10000000:al/of}} } } the MGC responds the Notify command with the Notify response. Step 4 MGC to RGW: MEGACO/1 [216.33.33.61]: 27000 Reply = 2000 { Context = - {Notify = TermA} } The MGC after receiving the offhook event responds with the SS7 message to be generated towards the SS7 switch. The ANM message generated from MGC indicates the answering state of the user. The MGC meanwhile generate ADD commands to both the Trunking gateway and Residential gateway. The message towards the Trunking gateway includes the addition of physical circuit that was seized for media transfer. The request for creating ephemeral termination is also sent in the same request. The Local SDP information is under specified allowing the Trunking gateway to choose the necessary SDP parameters. Step 5 MGC to TGW MEGACO/1 [216.33.33.61]: 27000 Transaction = 1235 { Context = $ { Add = Trunk1/line1 {Media { LocalControl {Mode = SendRecv}}, }, Add = $ {Media { LocalControl { Mode = Receiveonly, }, Local { v=0 Madhubabu, et al. [Page 61] Internet-Draft Megaco/H.248 Call flow examples July 2001 c=IN IP4 $ m=audio $ RTP/AVP 4 } } } } } } The Trunking gateway after responds with a contextID in this example 1. The ephemeral termination is created and added to the same context as the physical termination. The ephemeral termination added in this example is EPHA. The local parameters are specified in the response. The IP address chosen for the media transport in this example is 209.110.59.33, and the port number specified 30000. Step 6 TGW to MGC: MEGACO/1 [207.176.47.89]: 26000 Reply = 1235 { Context = 1 { Add = Trunk1/line1, Add = EphB { Media { Local { v=0 c=IN IP4 209.110.59.33 m=audio 30000 RTP/AVP 4 } } ; RTP profile for G723 is 4 } } } The MGC after receiving the response from the Trunking gateway uses the SDP information in the response sent from TG to the Residential gateway. The commands for adding the physical termination TermA and ephemeral termination to be created are sent in the same transaction. The MGC requests creation of context and to add the two terminations in the same. Step 7 MGC to RGW MEGACO/1 [216.33.33.61]: 27000 Transaction = 1237 { Context = $ { Add = TermA {Media { LocalControl {Mode = SendRecv}}, }, Add = $ {Media { Madhubabu, et al. [Page 62] Internet-Draft Megaco/H.248 Call flow examples July 2001 LocalControl { Mode = Receiveonly, }, Local { v=0 c=IN IP4 $ m=audio $ RTP/AVP 4 } Remote{ v=0 c=IN IP4 209.110.59.33 m=audio 30000 RTP/AVP 4 } } ; RTP profile for G723 is 4 } } } The Residential gateway creates a context with ContextId 2. It adds the physical termination TermA in that context. The ephemeral termination EPHB is created with the specified SDP information. The response from the MG specifies the local SDP information. Step 8 RGW to MGC: MEGACO/1 [209.110.59.34]: 25000 Reply = 1237 { Context = 2 { Add = TermA, Add = EphA{ Media { Local { v=0 c=IN IP4 209.110.59.34 m=audio 30000 RTP/AVP 4 } } ; RTP profile for G723 is 4 } } } The MGC after receiving the response with the local SDP information conveys the same to the Trunking gateway as remote SDP information in the Modify command. Step 9 MGC to TGW MEGACO/1 [216.33.33.61]: 27000 Transaction = 1238 { Context = 1 { Modify = EphA Madhubabu, et al. [Page 63] Internet-Draft Megaco/H.248 Call flow examples July 2001 {Media { LocalControl { Mode = SendRecv, }, Remote{ v=0 c=IN IP4 209.110.59.34 m=audio 30000 RTP/AVP 4 } } } } } } The Trunking gateway responds to the Modify command. Step 10 TGW to MGC: MEGACO/1 [207.176.47.89]: 26000 Reply = 1238 { Context = 1 { Modify = EphA } } The media properties are exchanged between the two media gateways and the RTP media can be transferred between these two. The call be will be disconnected with one of the two users going onhook. In this example we consider the user connected to the SS7 domain initiates the termination of the Call. The SS7 switch generates the REL "release" message towards the MGC. The MGC after receiving the REL message initiates the call teardown. The MGC generates a busy tones towards the user connected to the Residential gateway to indicate the disconnection of the call. The modify command is sent with event descriptor that lists the onhook event. Step 11 MGC to RGW MEGACO/1 [216.33.33.61]: 27000 Transaction = 1239 { Context = 2 { Modify = TermA { Signals { cg/bt }, Events = 1236 { al/on }, Media { LocalControl { recvonly } } } } } The Residential gateway responds with the Modify command response. Madhubabu, et al. [Page 64] Internet-Draft Megaco/H.248 Call flow examples July 2001 Step 12 RGW to MGC: MEGACO/1 [209.110.59.34]: 25000 Reply = 1239 { Context = 2 { Modify = TermA, } } The media connection tears down will be complete by responding the REL message by the RLC. The MGC subtracts the terminations added in the two Media gateways for this call. The Subtract command is sent to the Trunking gateway. The audit descriptor lists the statistics to enable statistics reporting to MGC from the Trunking gateway. Step 13 MGC to TGW: MEGACO/1 [216.33.33.61]: 27000 Transaction = 1240 { Context = 1 { Subtract = Trunk1/line1{Audit{ }}, Subtract = EphB {Audit{Statistics}} } } The TGW responds to the subtract commands generated by MGC. Step 14 TGW to MGC: MEGACO/1 [209.110.59.34]:25000 Reply = 1240 { Context = 1 { Subtract = Trunk1/line1 Subtract = EphB { Statistics { rtp/ps=987, ; packets sent nt/os=65432, ; octets sent rtp/pr=1234, ; packets received nt/or=56789, ; octets received rtp/pl=10, ; % packets lost rtp/jit=30, rtp/delay=30 ; average latency } } } } Step 15 RGW to MGC: MEGACO/1 [209.110.59.34]:25000 Transaction = 2001 { Context = 2 { Notify = TermA {Observed Events =1236 { Madhubabu, et al. [Page 65] Internet-Draft Megaco/H.248 Call flow examples July 2001 20010202T20000000:al/on}} } } The MGC responds the Notify command with the Notify response. Step 16 MGC to RGW: MEGACO/1 [216.33.33.61]: 27000 Reply = 2001 { Context = 2 {Notify = TermA} } The MGC after receiving the Notify for onhook from UserA generates transaction with two Subtract command for subtracting both the physical and ephemeral terminations from the Residential gateway. Step 15 MGC to RGW: MEGACO/1 [216.33.33.61]: 27000 Transaction = 1241 { Context = 2 { Subtract = TermA{Audit{ }}, Subtract = EphA {Audit{Statistics}} } } The RGW responds to the subtract commands generated by MGC. Step 16 TGW to MGC: MEGACO/1 [209.110.59.34]: 26000 Reply = 1241 { Context = 2 { Subtract = TermA Subtract = EphA { Statistics { rtp/ps=987, ; packets sent nt/os=65432, ; octets sent rtp/pr=1234, ; packets received nt/or=56789, ; octets received rtp/pl=10, ; % packets lost rtp/jit=30, rtp/delay=30 ; average latency } } } } Madhubabu, et al. [Page 66] Internet-Draft Megaco/H.248 Call flow examples July 2001 2.7 Call between SS7 trunk in TGW and R2 trunk in TGW This section of the call flow illustrates the call between two Trunking gateways, one that does R2 signaling towards the PSTN and the second TGW CCS SS7 towards the PSTN. In this example the user in the CCS SS7 signaling network originates the call. The destination user is connected to the PSTN network with R2 signaling. The R2 package draft is taken as the input for illustrating the events and signals used for communication between MG and MGC. The assumption of the R2 package, that the compelled signaling is part of the MG to generate signals or detect events holds true for this call scenario also. ______________________________________________________________________ | | | | SS7 Switch | TGW1 | MGC | TGW2 | R2Exch ____________|____________|___________|______________|_________________ | | | | | |----------->| | | | | IAM | | | | | |---------->| | | | | IAM | | | | | |----------->| | | | |Modify Phy Seize | | | | |--------------->| | | | | Seize | | | |<-----------| | |