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 | | | |<-----------| | | | |Modify Resp | | | | | |<---------------| | | | | Seize Ack | | | |<-----------| | | | |Notify OE:sa|--------------->| | | |----------->| Digits | | | |Notify Resp | | | |<----------| | | | | ACM | | | |<-----------| | | | | ACM | | | | | | | |<---------------| | | | | Answer | | | |<-----------| | | | | Notify OE:ans | | | |----------->| | | | |Notify Resp | | | |<----------| | | | | ANM | | | |<-----------| | | | | ANM | | | | Madhubabu, et al. [Page 67] Internet-Draft Megaco/H.248 Call flow examples July 2001 | |<----------| | | | |Add Phy | | | | |Add $ Local (Unspecified) | | |---------->| | | | |Add Phy Resp | | | |Add Eph Resp | | | | |----------->| | | | |Add Phy | | | | |Add $ Local (Unspecified) | | | | Remote (Specified) | | | |<-----------| | | | |Add Phy Resp| | | | |Add Eph Resp| | | |<----------| | | | |Modify Eph | | | | |---------->| | | | |Modify Resp| | | | |/----------------------\| | | | RTP MEDIA | | | |\----------------------/| | |----------->| | | | | REL | | | | | |---------->| | | | | REL | | | | | |----------->| | | | |Modify Phy ED:R2/clear | | | | |--------------->| | | | | Clear Forward | | | |<-----------| | | | |Modify Resp | | | | | |<---------------| | | | | Clear Back | | | |<-----------| | | | | Notify OE:clear | | | |----------->| | | | | Notify Resp| | | |<----------| | | | | RLC | | | |<-----------| | | | | RLC | | | | | |<----------| | | | |Sub Phy | | | | |Sub Eph | | | | |---------->| | | | |Sub Phy Resp | | | |Sub Eph Resp Statistics | | | | |----------->| | | | |Sub Phy | | | | |Sub Eph | | | | |<-----------| | | | |Sub Phy Resp| | Madhubabu, et al. [Page 68] Internet-Draft Megaco/H.248 Call flow examples July 2001 | | |Sub Eph Resp Statistics | |____________|___________|____________|________________| When the MGC through the signaling gateway receives the IAM it generates a Modify message towards the Trunking gateway that supports R2 package. The signal descriptor has the seize signal and the events descriptor has the event seizeack. The seizeack event has an embedded signal "address". The Trunking gateway is intended to seize a circuit and apply the address signals after the seize acknowledgement is received from the other R2 exchange. The calling party information can also be provided in the address signal. The embedded event of the seize acknowledgement event is the answer. This event has to be reported when the digits reach the other R2 exchange and there is answer from the terminating R2 exchange. The message from MGC to R2TGW is as follows. Step 1 MGC to R2TGW MEGACO/1 [216.33.33.61]: 27000 Transaction = 1234 { Context = - { Modify = Trunk1/line1 { Signals = {R2/sz} Events = 1111 {R2/sa Embed {signals {R2/address {si = 2992, di = 2989}}, Events=1112 {R2/clear, R2/answer} } } } The R2TGW after receiving the Modify command does the command processing and responds with Modify command response. Step 2 R2TGW to MGC MEGACO/1 [209.110.59.34]: 25000 Reply = 1234 { Context = - { Modify = Trunk1/line1 } } The R2 TGW applies seize signal on the specified circuit group and after receiving the acknowledgement from the other R2 exchange updates the embedded events descriptor as the events descriptor. The R2TGW also generates a Notify command towards the MGC to indicate that the seize acknowledgement has been received. Step 3 R2GW to MGC: Madhubabu, et al. [Page 69] Internet-Draft Megaco/H.248 Call flow examples July 2001 MEGACO/1 [209.110.59.34]: 25000 Transaction = 2000 { Context = - { Notify = Trunk1/line1 {Observed Events =1111 { 20010202T10000000:R2/sa}} } } the MGC responds the Notify command with the Notify response. Step 4 MGC to R2GW: MEGACO/1 [216.33.33.61]: 27000 Reply = 2000 { Context = - {Notify = Trunk1/line1} } The MGC now generates the address complete message to the SS7 switch that has generated the IAM message. The R2TGW after receiving the answer event from the other R2 exchange generates message to notify this event. Step 5 R2GW to MGC: MEGACO/1 [209.110.59.34]: 25000 Transaction = 2001 { Context = - { Notify = Trunk1/line1 {Observed Events =1112 { 20010202T10000000:R2/ans}} } } The MGC responds the Notify command with the Notify response. Step 6 MGC to R2GW: MEGACO/1 [216.33.33.61]: 27000 Reply = 2001 { Context = - {Notify = Trunk1/line1} } MGC generates the ANM message towards the SS7 switch through the signaling gateway. It also generates commands to add terminations into specific contexts. It generates a single transaction with two Add commands towards the TGW that supports R2 terminations. One command is to add the physical circuit group Trunk1/line and the other for the ephemeral termination. The SDP information is unspecified that enables the TGW to choose the under specified parameters. Step 7 MGC to R2TGW Madhubabu, et al. [Page 70] Internet-Draft Megaco/H.248 Call flow examples July 2001 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 c=IN IP4 $ m=audio $ RTP/AVP 4 } } } } } } The R2 Trunking gateway after receiving the Add command 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 8 R2TGW to MGC: MEGACO/1 [209.110.59.34]: 25000 Reply = 1235{ Context = 1 { Add = Trunk1/line1, Add = EphA { 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 generates similar transaction with two ADD commands to the other TGW. The local SDP information specified in by the R2TGW is used to as remote SDP information for the other TGW. The MGC conveys this information in the Add command. Madhubabu, et al. [Page 71] Internet-Draft Megaco/H.248 Call flow examples July 2001 Step 9 MGC to TGW MEGACO/1 [216.33.33.61]: 27000 Transaction = 1236{ 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 30000 RTP/AVP 4 } } ; RTP profile for G723 is 4 } } } The Trunking gateway creates a context with ContextId 2. It adds the physical termination Trunk2/line1 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 10 RGW to MGC: MEGACO/1 [207.176.47.89]: 26000 Reply = 1236{ Context = 2 { Add = Trunk2/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 } } } Madhubabu, et al. [Page 72] Internet-Draft Megaco/H.248 Call flow examples July 2001 The MGC after receiving the response generates a modify command to the R2TGW to inform the local SDP information of TGW as the remote SDP for the R2TGW. Step 11 MGC to TGW MEGACO/1 [216.33.33.61]: 27000 Transaction = 1237{ Context = 1 { Modify = EphA {Media { LocalControl { Mode = SendRecv, }, Remote{ v=0 c=IN IP4 209.110.59.33 m=audio 30000 RTP/AVP 4 } } } } } } The R2 Trunking gateway responds to the Modify command. Step 12 TGW to MGC: MEGACO/1 [207.176.47.89]: 26000 Reply = 1237{ Context = 1 { Modify = EphA } } The RTP media flow is established and the two users connected to the SS7 trunk and R2 trunk starts the conversation. After conversation any of the user can disconnect the call, in this example the user connected to the SS7 domain releases the call. The SS7 switch generates a REL message towards the MGC. The Signaling gateway forwards the same request towards the MGC. The MGC initiates the tearing down of the call. This is done initially by generating a Modify command towards the R2 TGW to generate clear forward signal towards the R2 exchange. In the message the MGC sends a signal descriptor with clear signals and events descriptor with the clear in the event. The event in the events descriptor is for detecting the clear back signal generated from the R2 exchange. Step 13 MGC to TGW: MEGACO/1 [216.33.33.61]: 27000 Madhubabu, et al. [Page 73] Internet-Draft Megaco/H.248 Call flow examples July 2001 Transaction = 1238{ Context = 1 { Context = Trunk1/line1{ signal { R2/clear}, Events = 1113{ R2/clear} } } The R2 TGW after receiving the commands does the signals and events descriptor processing and responds to the MGC with the Modify command response. Step 14 R2TGW to MGC MEGACO/1 [209.110.59.34]: 25000 Reply = 1238 { Context = 1 { Modify = Trunk1/line1 } } Mean while the MGC generates the subtract message towards the originating TGW to remove the terminations from the newly created context. Step 15 MGC to TGW: MEGACO/1 [216.33.33.61]: 27000 Transaction = 1239 Context = 2 { Subtract = Trunk2/line1{Audit{ }}, Subtract = EphB {Audit{Statistics}} } } The RGW responds to the subtract commands generated by MGC. Step 16 TGW to MGC: MEGACO/1 [207.176.47.89]:26000 Reply = 1239 Context = 2 { Subtract = Trunk2/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 74] Internet-Draft Megaco/H.248 Call flow examples July 2001 } } } } The MGC after receiving the response from the TGW generates the Release complete message RLC towards the SS7 switch through the Signaling Gateway. The R2 TGW after receiving the clear back signal from the other R2 exchange detects it and generates a Notify command towards the MGC. Step 17 R2GW to MGC: MEGACO/1 [209.110.59.34]:25000 Transaction = 2002 { Context = - { Notify = TermA {Observed Events =1113 { 20030202T10000000:R2/clear}} } } the MGC responds the Notify command with the Notify response. Step 18 MGC to R2GW: MEGACO/1 [216.33.33.61]: 27000 Reply = 2002 { Context = - {Notify = TermA} } MGC after receiving the notify command generates subtract command to remove both the physical termination and ephemeral termination. Step 19 MGC to R2TGW: MEGACO/1 [216.33.33.61]: 27000 Transaction = 1240{ Context = 1 { Subtract = Trunk1/line1{Audit{ }}, Subtract = EphA {Audit{Statistics}} } } The R2TGW responds to the subtract commands generated by MGC. Step 20 R2TGW to MGC: MEGACO/1 [209.110.59.34]:25000 Reply = 1240{ Context = 1 { Subtract = Trunk1/line1 Subtract = EphA { Statistics { Madhubabu, et al. [Page 75] Internet-Draft Megaco/H.248 Call flow examples July 2001 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 } } } } Now the termination is free to take part in other calls. 2.8 Call between R2 trunk in TGW and SS7 trunk in TGW This section of the call flow illustrates the call between two Trunking gateways, one that does R2 signaling towards one end and the second TGW CCS SS7. In this example the user in the R2 signaling network originates the call. The destination user is connected to the PSTN network with CCS SS7 signaling. The R2 package draft is considered 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. ______________________________________________________________________ | | | | R2Exchange | TGW1 | MGC | TGW2 | SS7 Switch ____________|____________|___________|______________|_________________ | | | | | | |<-----------| | | | |Modify ED:sz{SD:sa ED:addr, cl} | | |----------->| | | | |Modify Resp | | | |----------->| | | | | Seize | | | | |<-----------| | | | |SeizeAck |----------->| | | | |Notify OE:sa| | | |----------->| | | | | Digit 1 | | | | |<-----------| | | | |Send Next Digit | | | | : | | | | | : | | | | |<-----------| | | | | End of Singaling | | | | |----------->| | | Madhubabu, et al. [Page 76] Internet-Draft Megaco/H.248 Call flow examples July 2001 | |Notify OE:addr | | | | |----------->| | | | | IAM |--------------->| | |<-----------| | IAM | | |Notify Resp | |<---------------| | | |<-----------| ACM | | | | ACM | | | |<-----------| | | | |Modify Phy | | | |<-----------| | | | | Answer | | | | | |----------->| | | | |Modify Resp | | | | |<-----------| | | | | Add Phy | | | | | Add Eph Local Unspecified | | |----------->| | | | |Add Phy Resp| | | | |Add Eph Resp Local Specified | | | |----------->| | | | | Add Phy | | | | | Add EPh Local Unspecified | | | | Remote Specified | | | |<-----------| | | | |Add Phy Resp| | | |<-----------| | | | |Modify Eph | | | | |----------->| | | | |Modify Resp | | | | |/-----------------------\| | | | RTP MEDIA | | | |\-----------------------/| | |----------->| | | | |Clear Forward | | | | |----------->| | | |<-----------|Notify OE:R2/clear | | |Clear Back | | | | | |<-----------| | | | |Notify Resp | | | | | |----------->| | | | | REL |--------------->| | | | | REL | | | | |<---------------| | | |<-----------| RLC | | | | RLC | | | |<-----------| | | | |Sub Phy | | | | |Sub Eph | | | | |----------->| | | | |Sub Phy Resp| | | | |Sub Eph Resp Statistics | | Madhubabu, et al. [Page 77] Internet-Draft Megaco/H.248 Call flow examples July 2001 | | |----------->| | | | |Sub Phy | | | | |Sub Eph | | | | |<-----------| | | | |Sub Phy Resp| | | | |Sub Eph Resp Statistics | |____________|____________|____________|________________| The MGC generates a Modify command towards the R2 Trunking gateway with the seize event and an embedded seize acknowledgement signal. The digit map in this scenario is assumed to be provisioned in the MG (shown to be 2XXX which may not be true for practical R2 exchanges). The seize event has a embedded signal seizeack to be applied after detection of seize event. The embedded signal is accompanied by another embedded events namely the clear event to detect the clear forwards signal if generated from the R2 domain. Step 1 MGC to R2TGW MEGACO/1 [216.33.33.61]: 27000 Transaction = 1234 { Context = - { Modify = Trunk1/line1 { Events = 1111 {R2/sz Embed { signals {R2/sa}, Events=1112 { R2/clear signals { R2/clear }, R2/address}} } } } The R2TGW after receiving the Modify command does the command processing and responds with Modify command response. Step 2 R2TGW to MGC MEGACO/1 [209.110.59.34]: 25000 Reply = 1234 { Context = - { Modify = Trunk1/line1 } } In this example as mentioned earlier, the call is originated from a user connected to the R2 domain of PSTN. The R2 exchange that is connected to the R2 Trunking gateway generates the seize signal. The seize signal is identified by the R2TGW and seize event is detected. The seize event is notified to the MGC. The R2TGW meanwhile does the embedded descriptor processing for the seize event. The application of the seizeack and detection of clear event is activated on the specific circuit group. Madhubabu, et al. [Page 78] Internet-Draft Megaco/H.248 Call flow examples July 2001 The Notify command is generated towards the MGC. Step 3 R2GW to MGC: MEGACO/1 [209.110.59.34]:25000 Transaction = 2000 { Context = - { Notify = TermA {Observed Events =1111 { 20010202T10000000:R2/sz}} } } the MGC responds the Notify command with the Notify response. Step 4 MGC to R2GW: MEGACO/1 [216.33.33.61]: 27000 Reply = 2000 { Context = - {Notify = TermA} } The R2TGW collects the digits and reports the same to the MGC as parameters of the address event. The other observed event parameters like the source number, subscribe category, etc are also indicated to the MGC. Step 5 R2GW to MGC: MEGACO/1 [209.110.59.34]:25000 Transaction = 2001 { Context = - { Notify = TermA {Observed Events =1112 { 20010302T10000000:R2/address { di=2992, si=2804 , sc=1 } }} } } the MGC responds the Notify command with the Notify response. Step 6 MGC to R2GW: MEGACO/1 [216.33.33.61]: 27000 Reply = 2001 { Context = - {Notify = TermA} } The MGC then initiates the necessary signaling towards the exchange to which the destination user is connected. In this example the MGC has to generates SS7 messages to the SS7 switch. The IAM message is sent with all the necessary address signaling information. The SS7 switch responds with the ACM message. The MGC after receiving the ANM message generates command to apply answer signal. The MGC sends a Modify command towards the R2 TGW to Madhubabu, et al. [Page 79] Internet-Draft Megaco/H.248 Call flow examples July 2001 indicate that the answer needs to be applied Step 7 MGC to R2TGW MEGACO/1 [216.33.33.61]: 27000 Transaction = 1235 { Context = - { Modify = Trunk1/line1 {signals{ R2/ans } } } } The R2trunking gateway responds to the Modify command. Step 8 R2TGW to MGC: MEGACO/1 [207.176.47.89]: 26000 Reply = 1235 { Context = - { Modify = Trunk1/line1 } } The MGC after receiving the ANM message generates commands to both the Trunking gateways to add physical circuits and create ephemeral terminations. The MGC in its message to the R2TGW in its signal descriptor lists the answer signal to indicate that the call establishment is successful and the end user is free to receive the call. Step 9 MGC to R2TGW MEGACO/1 [216.33.33.61]: 27000 Transaction = 1236{ Context = $ { Add = Trunk1/line1 {Media { LocalControl {Mode = SendRecv}}, }, Add = $ {Media { LocalControl { Mode = Receiveonly, }, Local { v=0 c=IN IP4 $ m=audio $ RTP/AVP 4 } } } } Madhubabu, et al. [Page 80] Internet-Draft Megaco/H.248 Call flow examples July 2001 } } The R2 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 10 R2TGW to MGC: MEGACO/1 [209.110.59.34]: 25000 Reply = 1236{ Context = 1 { Add = Trunk1/line1, Add = EphA{ 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 generates similar transaction with two ADD commands to the other TGW. The local SDP information specified in by the R2TGW is used to as remote SDP information for the other TGW. The MGC conveys this information in the Add command. Step 11 MGC to TGW MEGACO/1 [216.33.33.61]: 27000 Transaction = 1237{ Context = $ { Add = Trunk2/$ {Media { LocalControl {Mode = SendRecv}}, }, Add = $ {Media { LocalControl { Mode = Receiveonly, }, Local { v=0 c=IN IP4 $ m=audio $ RTP/AVP 4 } Remote{ Madhubabu, et al. [Page 81] Internet-Draft Megaco/H.248 Call flow examples July 2001 v=0 c=IN IP4 209.110.59.33 m=audio 30000 RTP/AVP 4 } } ; RTP profile for G723 is 4 } } } The Trunking gateway creates a context with ContextId 2. It adds the physical termination Trunk2/line1 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 12 TGW to MGC: MEGACO/1 [207.176.47.89]: 26000 Reply = 1237{ Context = 2 { Add = Trunk2/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 } } } The MGC after receiving the response generates a modify command to the R2TGW to inform the local SDP information of TGW as the remote SDP for the R2TGW. Step 13 MGC to R2TGW MEGACO/1 [216.33.33.61]: 27000 Transaction = 1238{ Context = 1 { 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 82] Internet-Draft Megaco/H.248 Call flow examples July 2001 } } } } The R2 Trunking gateway responds to the Modify command. Step 14 R2TGW to MGC: MEGACO/1 [207.176.47.89]: 26000 Reply = 1238{ Context = 1 { Modify = EphA } } The RTP media transfer takes place. The user connected to the R2 exchange domain terminates the call. The clear forwards signal generated by the R2 exchange connected to the R2 TGW is detected and reported to the MGC as the clear event in the R2 package. The clear back signal, which is part of the clear event, enables the R2TGW to generate the clear back signal. The clear event detection is reported to MGC as part of the Notify command. Step 15 R2TGW to MGC: MEGACO/1 [209.110.59.34]:25000 Transaction = 2003 { Context = 1 { Notify = TermA {ObservedEvents =1112 { 20010402T10030000:R2/clear} } } } The MGC responds to the RGWs Notify message. Step 16 MGC to R2TGW: MEGACO/1 [216.33.33.61]:27000 Reply = 2003 { Context = 1 { Notify = TermA } } The MGC generates necessary command to the SS7 switch like the REL message. The SS7 switch responds with the RLC message. The MGC now generates commands to both the TGWs for subtracting the terminations from the contexts created. Step 17 MGC to R2TGW: MEGACO/1 [216.33.33.61]: 27000 Madhubabu, et al. [Page 83] Internet-Draft Megaco/H.248 Call flow examples July 2001 Transaction = 1239{ Context = 1 { Subtract = Trunk1/line1{Audit{ }}, Subtract = EphA {Audit{Statistics}} } } The R2TGW responds to the subtract commands generated by MGC. Step 18 TGW to MGC: MEGACO/1 [209.110.59.34]:25000 Reply = 1239{ 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 } } } } The MGC generates similar transaction with two Subtract command for subtracting both the physical and ephemeral terminations from the second Trunking gateway. Step 19 MGC to TGW: MEGACO/1 [216.33.33.61]: 27000 Transaction = 1240 Context = 2 { Subtract = Trunk2/line1{Audit{ }}, Subtract = EphB {Audit{Statistics}} } } The RGW responds to the subtract commands generated by MGC. Step 20 TGW to MGC: MEGACO/1 [207.176.47.89]:26000 Reply = 1240 Context = 2 { Subtract = Trunk2/line1 Subtract = EphB { Statistics { rtp/ps=987, ; packets sent Madhubabu, et al. [Page 84] Internet-Draft Megaco/H.248 Call flow examples July 2001 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.9 Call between R1 trunk in TGW and SS7 trunk in TGW In the earlier section we illustrated the Megaco messages between MGC and two Trunking gateway one that perform CCS SS7 and the other CAS R2 signaling. This section illustrates another similar scenario, but now the call is initiated by the user that originates R1 signaling to the user connected to CCS SS7 signaling. Both the Trunking gateways are assumed to be controlled by the same Media Gateway Controller. The packages that are considered are R1 package, network package, MF tone detection package and RTP package. ______________________________________________________________________ | | | | R1Exchange | TGW1 | MGC | TGW2 | SS7 Switch ____________|____________|___________|______________|_________________ | | | | | | |<-----------| | | | |Modify ED:sz{SD:sa ED:addr, cl} | | |----------->| | | | |Modify Resp | | | |----------->| | | | | Seize | | | | |<-----------| | | | |SeizeAck |----------->| | | | |Notify OE:sa| | | |----------->| | | | | KP | | | | |----------->| | | | | Digit1 | | | | | : | | | | | : | | | | |----------->| | | | | ST | | | | | |----------->| | | | |Notify OE:addr | | | | |----------->| | | | | IAM |--------------->| Madhubabu, et al. [Page 85] Internet-Draft Megaco/H.248 Call flow examples July 2001 | |<-----------| | IAM | | |Notify Resp | |<---------------| | | |<-----------| ACM | | | | ACM | | | |<-----------| | | | |Modify Phy | | | |<-----------| | | | | Answer | | | | | |----------->| | | | |Modify Resp | | | | |<-----------| | | | | Add Phy | | | | | Add Eph Local Unspecified | | |----------->| | | | |Add Phy Resp| | | | |Add Eph Resp Local Specified | | | |----------->| | | | | Add Phy | | | | | Add EPh Local Unspecified | | | | Remote Specified | | | |<-----------| | | | |Add Phy Resp| | | |<-----------| | | | |Modify Eph | | | | |----------->| | | | |Modify Resp | | | | |/-----------------------\| | | | RTP MEDIA | | | |\-----------------------/| | |----------->| | | | |Clear Forward | | | | |----------->| | | |<-----------|Notify OE:R1/clear | | |Clear Back | | | | | |<-----------| | | | |Notify Resp | | | | | |----------->| | | | | REL |--------------->| | | | | REL | | | | |<---------------| | | |<-----------| RLC | | | | RLC | | | |<-----------| | | | |Sub Phy | | | | |Sub Eph | | | | |----------->| | | | |Sub Phy Resp| | | | |Sub Eph Resp Statistics | | | | |----------->| | | | |Sub Phy | | | | |Sub Eph | | Madhubabu, et al. [Page 86] Internet-Draft Megaco/H.248 Call flow examples July 2001 | | |<-----------| | | | |Sub Phy Resp| | | | |Sub Eph Resp Statistics | |____________|____________|____________|________________| The MGC generates a Modify command towards the R1 Trunking gateway with the seize event and an embedded seize acknowledgement signal. The digit map in this scenario is assumed to be provisioned in the MG (shown to be 2XXX which may not be true for practical R1 exchanges). The seize event has a embedded signal seizeack to be applied after detection of seize event. The embedded signal is accompanied by another embedded events namely the clear event to detect the clear forwards signal if generated from the R1 domain. Step 1 MGC to R1TGW MEGACO/1 [216.33.33.61]: 27000 Transaction = 1234 { Context = - { Modify = Trunk1/line1 { Events=1111{R1/sz Embed{ signals {R1/sd}, Events=1112 { mfd/ce{dmap}, R1/clearforward signals { R1/clearback }, R1/address}} } } } The R1TGW after receiving the Modify command does the command processing and responds with Modify command response. Step 2 R1TGW to MGC MEGACO/1 [209.110.59.34]: 25000 Reply = 1234 { Context = - { Modify = Trunk1/line1 } } In this example as mentioned earlier, the call is originated from a user connected to the R1 domain of PSTN. The R1 exchange that is connected to the R1 Trunking gateway generates the seize signal. The seize signal is identified by the R1TGW and seize event is detected. The seize event is notified to the MGC. The R1TGW meanwhile does the embedded descriptor processing for the seize event. The application of the seizeack and detection of clear event is activated on the specific circuit group. The Notify command is generated towards the MGC. Step 3 Madhubabu, et al. [Page 87] Internet-Draft Megaco/H.248 Call flow examples July 2001 R1GW to MGC: MEGACO/1 [209.110.59.34]:25000 Transaction = 2000 { Context = - { Notify = Trunk1/line1 {Observed Events =1111 { 20010202T10000000:R1/sz}} } } the MGC responds the Notify command with the Notify response. Step 4 MGC to R1GW: MEGACO/1 [216.33.33.61]: 27000 Reply = 2000 { Context = - {Notify = Trunk1/line1} } The R1TGW collects the digits and reports the same to the MGC as parameters of the address event The digit completion event of the MF detection package is used here. This is extracted from the MF tone detection package. Step 5 R1GW to MGC: MEGACO/1 [209.110.59.34]:25000 Transaction = 2001 { Context = - { Notify = Trunk1/line1 {Observed Events =1112 { 20010302T10000000:mfd/ce{ds=2992}} } } the MGC responds the Notify command with the Notify response. Step 6 MGC to R1GW: MEGACO/1 [216.33.33.61]: 27000 Reply = 2001 { Context = - {Notify = Trunk1/line1} } The MGC then initiates the necessary signaling towards the exchange to which the destination user is connected. In this example the MGC has to generates SS7 messages to the SS7 switch. The IAM message is sent with all the necessary address signaling information. The SS7 switch responds with the ACM message. The MGC sends a Modify command towards the R1 TGW to indicate that has gone offhook. The answer signal is sent in the Signals descriptor. Step 7 MGC to R1TGW Madhubabu, et al. [Page 88] Internet-Draft Megaco/H.248 Call flow examples July 2001 MEGACO/1 [216.33.33.61]: 27000 Transaction = 1235 { Context = - { Modify = Trunk1/line1 {signals{ R1/ans } } } } The R1 Trunking gateway responds to the Modify command. Step 8 TGW to MGC: MEGACO/1 [207.176.47.89]: 26000 Reply = 1235 { Context = - { Modify = Trunk1/line1 } } The MGC after receiving the ANM message generates commands to both the Trunking gateways to add physical circuits and create ephemeral terminations. The MGC in its message to the R1TGW in its signal descriptor lists the answer signal to indicate that the call establishment is successful and the end user is free to receive the call. Step 9 MGC to R1GW MEGACO/1 [216.33.33.61]: 27000 Transaction = 1236 { Context = $ { Add = Trunk1/line1 {Media { LocalControl {Mode = SendRecv}}, }, Add = $ {Media { LocalControl { Mode = Receiveonly, }, Local { v=0 c=IN IP4 $ m=audio $ RTP/AVP 4 } } } } } } The R1 Trunking gateway after responds with a contextID in this Madhubabu, et al. [Page 89] Internet-Draft Megaco/H.248 Call flow examples July 2001 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 10 R1TGW to MGC: MEGACO/1 [209.110.59.34]: 25000 Reply = 1236 { Context = 1 { Add = Trunk1/line1, Add = EphA{ 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 generates similar transaction with two ADD commands to the other TGW. The local SDP information specified in by the R1TGW is used to as remote SDP information for the other TGW. The MGC conveys this information in the Add command. Step 11 MGC to TGW MEGACO/1 [216.33.33.61]: 27000 Transaction = 1237 { 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 30000 RTP/AVP 4 } Madhubabu, et al. [Page 90] Internet-Draft Megaco/H.248 Call flow examples July 2001 } ; RTP profile for G723 is 4 } } } The Trunking gateway creates a context with ContextId 2. It adds the physical termination Trunk2/line1 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 12 R1GW to MGC: MEGACO/1 [207.176.47.89]: 26000 Reply = 1237 { Context = 2 { Add = Trunk2/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 } } } The MGC after receiving the response generates a modify command to the R1TGW to inform the local SDP information of TGW as the remote SDP for the R1TGW. Step 13 MGC to R1TGW MEGACO/1 [216.33.33.61]: 27000 Transaction = 1238 { Context = 1 { 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 91] Internet-Draft Megaco/H.248 Call flow examples July 2001 The R1 Trunking gateway responds to the Modify command. Step 14 R1TGW to MGC: MEGACO/1 [207.176.47.89]: 26000 Reply = 1238 { Context = 1 { Modify = EphA } } The RTP media transfer takes place. The user connected to the R1 exchange domain terminates the call. The clear forwards signal generated by the R1 exchange connected to the R1 TGW is detected and reported to the MGC as the clear event in the R1 package. The clear back signal, which is part of the clear event, enables the R1TGW to generate the clear back signal. The clear event detection is reported to MGC as part of the Notify command. Step 15: R1TGW to MGC: MEGACO/1 [209.110.59.34]:25000 Transaction = 2003 { Context = 1 { Notify = TermA {ObservedEvents =1112 { 20010402T10030000:R1/clear} } } } The MGC responds to the R1GWs Notify message. Step 16 MGC to R1TGW: MEGACO/1 [216.33.33.61]:27000 Reply= 2003 { Context = 1 { Notify = TermA } } The MGC generates necessary command to the SS7 switch like the REL message. The SS7 switch responds with the RLC message. The MGC now generates commands to both the TGWs for subtracting the terminations from the contexts created. Step 17 MGC to R1TGW: MEGACO/1 [216.33.33.61]: 27000 Transaction = 1239 { Context = 1 { Subtract = Trunk1/line1{Audit{ }}, Subtract = EphA {Audit{Statistics}} Madhubabu, et al. [Page 92] Internet-Draft Megaco/H.248 Call flow examples July 2001 } } The R2TGW responds to the subtract commands generated by MGC. Step 18 R1TGW to MGC: MEGACO/1 [209.110.59.34]:25000 Reply = 1239 { 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 } } } } The MGC generates similar transaction with two Subtract command for subtracting both the physical and ephemeral terminations from the second Trunking gateway. Step 19 MGC to TGW: MEGACO/1 [216.33.33.61]: 27000 Transaction = 1240 { Context = 2 { Subtract = Trunk2/line1{Audit{ }}, Subtract = EphB {Audit{Statistics}} } } The R1GW responds to the subtract commands generated by MGC. Step 20 TGW to MGC: MEGACO/1 [207.176.47.89]:26000 Reply = 1240 Context = 2 { Subtract = Trunk2/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 Madhubabu, et al. [Page 93] Internet-Draft Megaco/H.248 Call flow examples July 2001 rtp/jit=30, rtp/delay=30 ; average latency } } } } 2.10 Call between SS7 trunk in TGW and R1 trunk in TGW This section of the call flow illustrates the call between two Trunking gateways, one that does R1 signaling towards one end and the second TGW CCS SS7. In this example the user in the CCS SS7 signaling network originates the call. The destination user is connected to the PSTN network with R1 signaling. ______________________________________________________________________ | | | | SS7 Switch | TGW1 | MGC | TGW2 | R1Exch ____________|____________|___________|______________|_________________ | | | | | |----------->| | | | | IAM | | | | | |---------->| | | | | IAM | | | | | |----------->| | | | |Modify Phy Seize | | | | |--------------->| | | | | Seize | | | |<-----------| | | | |Modify Resp | | | | | |<---------------| | | | | Wink | | | |<-----------| | | | |Notify OE:sa|--------------->| | | |----------->| KP,Digits,ST | | | |Notify Resp | | | |<----------| | | | | ACM | | | |<-----------| | | | | ACM | | | | | | | |<---------------| | | | | Answer | | | |<-----------| | | | | Notify OE:ans | | | |----------->| | | | |Notify Resp | | | |<----------| | | | | ANM | | | |<-----------| | | | | ANM | | | | Madhubabu, et al. [Page 94] Internet-Draft Megaco/H.248 Call flow examples July 2001 | |<----------| | | | |Add Phy | | | | |Add $ Local (Unspecified) | | |---------->| | | | |Add Phy Resp | | | |Add Eph Resp | | | | |----------->| | | | |Add Phy | | | | |Add $ Local (Unspecified) | | | | Remote (Specified) | | | |<-----------| | | | |Add Phy Resp| | | | |Add Eph Resp| | | |<----------| | | | |Modify Eph | | | | |---------->| | | | |Modify Resp| | | | |/----------------------\| | | | RTP MEDIA | | | |\----------------------/| | |----------->| | | | | REL | | | | | |---------->| | | | | REL | | | | | |----------->| | | | |Modify Phy ED:R1/clear | | | | |--------------->| | | | | Clear Forward | | | |<-----------| | | | |Modify Resp | | | | | |<---------------| | | | | Clear Back | | | |<-----------| | | | | Notify OE:clear | | | |----------->| | | | | Notify Resp| | | |<----------| | | | | RLC | | | |<-----------| | | | | RLC | | | | | |<----------| | | | |Sub Phy | | | | |Sub Eph | | | | |---------->| | | | |Sub Phy Resp | | | |Sub Eph Resp Statistics | | | | |----------->| | | | |Sub Phy | | | | |Sub Eph | | | | |<-----------| | | | |Sub Phy Resp| | Madhubabu, et al. [Page 95] Internet-Draft Megaco/H.248 Call flow examples July 2001 | | |Sub Eph Resp Statistics | |____________|___________|____________|________________| When the MGC through the signaling gateway receives the IAM it generates a Modify message towards the Trunking gateway that supports R1 package. The signal descriptor has the seize signal and the events descriptor has the event seizeack. The seizeack event has an embedded signal "address". The Trunking gateway is intended to seize a circuit and apply the address signals after the seize acknowledgement is received from the other R1 exchange. The calling party information can also be provided in the address signal. For simplicity it is omitted here. The embedded event of the seize acknowledgement event is the answer. This event has to be reported when the digits reach the other R1 exchange and there is answer from the terminating R1 exchange. The message from MGC to R1TGW is as follows. Step 1 MGC to R1TGW MEGACO/1 [216.33.33.61]: 27000 Transaction = 1234 { Context = - { Modify = Trunk1/line1 { Signals = { R1/sz} Events = 1111 {R1/sd Embed { signals {R1/address { ds = 2989} }, Events=1112 { R1/clear, R1/ans} } } } The R1TGW after receiving the Modify command does the command processing and responds with Modify command response. Step 2 R1TGW to MGC MEGACO/1 [209.110.59.34]: 25000 Reply = 1234 { Context = - { Modify = Trunk1/line1 } } The R1 TGW applies seize signal on the specified circuit group and after receiving the acknowledgement from the other R1 exchange updates the embedded events descriptor as the events descriptor. The R1TGW also generates a Notify command towards the MGC to indicate that the seize acknowledgement has been received. Step 3 R1GW to MGC: MEGACO/1 [209.110.59.34]:25000 Madhubabu, et al. [Page 96] Internet-Draft Megaco/H.248 Call flow examples July 2001 Transaction = 2000 { Context = - { Notify = Trunk1/line1{Observed Events =1111 { 20010202T10000000:R1/sd}} } } the MGC responds the Notify command with the Notify response. Step 4 MGC to R1GW: MEGACO/1 [216.33.33.61]: 27000 Reply = 2000 { Context = - {Notify = Trunk1/line1} } The MGC now generates the address complete message to the SS7 switch that has generated the IAM message. The R1TGW after receiving the answer event from the other R1 exchange generates message to notify this event. Step 5 R1GW to MGC: MEGACO/1 [209.110.59.34]:25000 Transaction = 2001 { Context = - { Notify = Trunk1/line1{Observed Events =1112 { 20010202T10000000:R1/ans}} } } the MGC responds the Notify command with the Notify response. Step 6 MGC to R1GW: MEGACO/1 [216.33.33.61]: 27000 Reply = 2001 { Context = - {Notify = Trunk1/line1} } MGC generates the ANM message towards the SS7 switch through the signaling gateway. It also generates commands to add terminations into specific contexts. It generates a single transaction with two Add commands towards the TGW that supports R1 terminations. One command is to add the physical circuit group Trunk1/line and the other for the ephemeral termination. The SDP information is unspecified that enables the TGW to choose the underspecified parameters. Step 7 MGC to R1TGW MEGACO/1 [216.33.33.61]: 27000 Madhubabu, et al. [Page 97] Internet-Draft Megaco/H.248 Call flow examples July 2001 Transaction = 1235{ Context = $ { Add = Trunk1/line1 {Media { LocalControl {Mode = SendRecv}}, }, Add = $ {Media { LocalControl { Mode = Receiveonly, }, Local { v=0 c=IN IP4 $ m=audio $ RTP/AVP 4 } } } } } } The R1 Trunking gateway after receiving the Add command 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 8 R1TGW to MGC: MEGACO/1 [209.110.59.34]: 25000 Reply = 1235{ Context = 1 { Add = Trunk1/line1, Add = EphA{ 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 generates similar transaction with two ADD commands to the other TGW. The local SDP information specified in by the R1TGW is used to as remote SDP information for the other TGW. The MGC conveys this information in the Add command. Madhubabu, et al. [Page 98] Internet-Draft Megaco/H.248 Call flow examples July 2001 Step 9 MGC to TGW MEGACO/1 [216.33.33.61]: 27000 Transaction = 1236{ 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 30000 RTP/AVP 4 } } ; RTP profile for G723 is 4 } } } The Trunking gateway creates a context with ContextId 2. It adds the physical termination Trunk2/line1 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 10 RGW to MGC: MEGACO/1 [207.176.47.89]: 26000 Reply = 1236{ Context = 2 { Add = Trunk2/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 generates a modify command to Madhubabu, et al. [Page 99] Internet-Draft Megaco/H.248 Call flow examples July 2001 the R1TGW to inform the local SDP information of TGW as the remote SDP for the R1TGW. Step 11 MGC to TGW MEGACO/1 [216.33.33.61]: 27000 Transaction = 1237{ Context = 1 { Modify = EphA {Media { LocalControl { Mode = SendRecv, }, Remote{ v=0 c=IN IP4 209.110.59.33 m=audio 30000 RTP/AVP 4 } } } } } } The R1 Trunking gateway responds to the Modify command. Step 12 TGW to MGC: MEGACO/1 [207.176.47.89]: 26000 Reply = 1237{ Context = 1 { Modify = EphA } } The RTP media flow is established and the two users connected to the SS7 trunk and R1 trunk starts the conversation. After conversation any of the user can disconnect the call in this example the user connected to the SS7 domain releases the call. The SS7 switch generates a REL message towards the MGC. The Signaling gateway forwards the same request towards the MGC. The MGC initiates the tearing down of the call. This is done initially by generating a Modify command towards the R1 TGW to generate clear forward signal towards the R1 exchange. In the message the MGC sends a signal descriptor with clear signals and events descriptor with the clear in the event. The event in the events descriptor is for detecting the clear back signal generated from the R1 exchange. Step 13 MGC to TGW: MEGACO/1 [216.33.33.61]: 27000 Transaction = 1238{ Madhubabu, et al. [Page 100] Internet-Draft Megaco/H.248 Call flow examples July 2001 Context = 1 { Context = Trunk1/line1{ signal { R1/clear}, Events = 1113{ R1/clear} } } The R1 TGW after receiving the commands does the signals and events descriptor processing and responds to the MGC with the Modify command response. Step 14 R1TGW to MGC MEGACO/1 [209.110.59.34]: 25000 Reply = 1238 { Context = 1 { Modify = Trunk1/line1 } } Mean while the MGC generates the subtract message towards the originating TGW to remove the terminations from the newly created context. Step 15 MGC to TGW: MEGACO/1 [216.33.33.61]: 27000 Transaction = 1239 Context = 2 { Subtract = Trunk2/line1{Audit{ }}, Subtract = EphB {Audit{Statistics}} } } The RGW responds to the subtract commands generated by MGC. Step 16 TGW to MGC: MEGACO/1 [207.176.47.89]:26000 Reply = 1239 Context = 2 { Subtract = Trunk2/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 101] Internet-Draft Megaco/H.248 Call flow examples July 2001 } } } The MGC after receiving the response from the TGW generates the Release complete message RLC towards the SS7 switch through the Signaling Gateway. The R1 TGW after receiving the clear back signal from the other R1 exchange detects it and generates a Notify command towards the MGC. Step 17 R1GW to MGC: MEGACO/1 [209.110.59.34]:25000 Transaction = 2002 { Context = - { Notify = TermA {Observed Events =1113 { 20030202T10000000:R1/clear}} } } the MGC responds the Notify command with the Notify response. Step 18 MGC to R1GW: MEGACO/1 [216.33.33.61]: 27000 Reply = 2002 { Context = - {Notify = TermA} } MGC after receiving the notify command generates subtract command to remove both the physical termination and ephemeral termination. Step 19 MGC to R1TGW: MEGACO/1 [216.33.33.61]: 27000 Transaction = 1240{ Context = 1 { Subtract = Trunk1/line1{Audit{ }}, Subtract = EphA {Audit{Statistics}} } } The R1TGW responds to the subtract commands generated by MGC. Step 20 R1TGW to MGC: MEGACO/1 [209.110.59.34]:25000 Reply = 1240{ Context = 1 { Subtract = Trunk1/line1 Subtract = EphA { Statistics { rtp/ps=987, ; packets sent Madhubabu, et al. [Page 102] Internet-Draft Megaco/H.248 Call flow examples July 2001 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 } } } } Now the termination is free to take part in other calls. 2.11 Call between ISDN trunk in TGW and SS7 trunk in TGW This section illustrates the Megaco message flow between MGC and two Trunking media gateways one that perform ISDN signaling towards the user and the other TGW performs SS7 signaling. In this example we assume that an ISDN user initiates that call. ______________________________________________________________________ | | | | ISDNSwitch | TGW1/SG | MGC | TGW2/SG | SS7Switch ____________|____________|___________|______________|_________________ | | | | | |----------->| | | | | Setup |---------->| | | | | Setup | | | | | |----------->| | | | | IAM |--------------->| | | | | IAM | | | | |<---------------| | | |<-----------| ACM | | | | ACM | | | |<----------| | | |<-----------| Alerting| | | | Alerting | | |<---------------| | | |<-----------| ANM | | |<----------| ANM | | |<-----------| Connect | | | | Connect |<----------| | | | |Add Phy | | | | |Add Eph Local unspecfied | | |---------->| | | | |Add Phy Resp | | | |Add Eph Resp Local Specified | | | |----------->| | | | |Add Phy | | | | |Add Eph Local Unspecified | | | | Remote Specified | Madhubabu, et al. [Page 103] Internet-Draft Megaco/H.248 Call flow examples July 2001 | | |<-----------| | | | |Add Phy Resp| | | | |Add Eph Resp Remote Specified| | |<----------| | | | |Modify EPh Remote Specified | | |---------->| | | | |Modify Eph Resp | | | |/----------------------\| | | | RTP MEDIA | | | |\----------------------/| | |----------->| | | | | Disconnect |---------->| | | | | Disconnect|----------->| | | | | REL |--------------->| | | | | REL | | | | |<---------------| | | |<-----------| RLC | | |<----------| RLC | | |<-----------| Release | | | | Release | | | | |----------->| | | | | Release Complete | | | | |---------->| | | | |Release Complete | | | |<----------| | | | |Sub Phy | | | | |Sub Eph | | | | |---------->| | | | |Sub Phy Resp | | | |Sub Eph Resp Statistics | | | | |----------->| | | | |Sub Phy | | | | |Sub Eph | | | | |<-----------| | | | |Sub Phy Resp| | | | |Sub Eph Resp Statistics | |____________|___________|____________|________________| The initial message sent by the ISDN switch is the Setup message. The setup message has all the address information. The MGC after receiving the Setup message from the Signaling gateway generates the IAM message towards the SS7 switch through the Signaling gateway. After receiving the ACM address complete message from the SS7 switch the MGC generates Alerting message towards the ISDN switch. The MGC after receiving the ANM message generates Connect message towards the ISDN switch. The MGC now adds terminations in both the Trunking gateways. Step 1 MGC to ISDNTGW Madhubabu, et al. [Page 104] Internet-Draft Megaco/H.248 Call flow examples July 2001 MEGACO/1 [216.33.33.61]: 27000 Transaction = 1234{ Context = $ { Add = Trunk1/line1 {Media { LocalControl {Mode = SendRecv}}, }, Add = $ {Media { LocalControl { Mode = Receiveonly, }, Local { v=0 c=IN IP4 $ m=audio $ RTP/AVP 4 } } } } } } The ISDN Trunking gateway after receiving the Add command 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 2 ISDNTGW to MGC: MEGACO/1 [207.176.47.89]: 25000 Reply = 1234{ Context = 1 { Add = Trunk1/line1, Add = EphA{ 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 generates similar transaction with two ADD commands to the other SS7TGW. The local SDP information specified in by the ISDNTGW is used to as remote SDP information for the other TGW. The MGC conveys this information in the Add command. Madhubabu, et al. [Page 105] Internet-Draft Megaco/H.248 Call flow examples July 2001 Step 3 MGC to SS7TGW 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 30000 RTP/AVP 4 } } ; RTP profile for G723 is 4 } } } The Trunking gateway creates a context with ContextId 2. It adds the physical termination Trunk2/line1 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 4 RGW 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 209.110.59.33 m=audio 30000 RTP/AVP 4 } } ; RTP profile for G723 is 4 } } } Madhubabu, et al. [Page 106] Internet-Draft Megaco/H.248 Call flow examples July 2001 The MGC after receiving the response generates a modify command to the ISDNTGW to inform the local SDP information of TGW as the remote SDP for the ISDNTGW. Step 5 MGC to TGW MEGACO/1 [216.33.33.61]: 27000 Transaction = 1236{ Context = 1 { Modify = EphA {Media { LocalControl { Mode = SendRecv, }, Remote{ v=0 c=IN IP4 209.110.59.33 m=audio 30000 RTP/AVP 4 } } } } } } The ISDN Trunking gateway responds to the Modify command. Step 6 ISDNTGW to MGC: MEGACO/1 [207.176.47.89]: 26000 Reply = 1236{ Context = 1 { Modify = EphA } } The RTP flow is established. The call can be terminated either from the ISDN user or from the user connected to SS7 domain. In this example we assume that the ISDN user terminates the call. The ISDN switch generates Disconnect message towards the MGC through Signaling gateway. The MGC generates Release message towards the SS7 switch. The MGC also generates messages to subtract termination from contexts in both the Trunking gateways. Step 7 MGC to ISDNTGW: MEGACO/1 [216.33.33.61]: 27000 Transaction = 1237{ Context = 1 { Subtract = Trunk1/line1{Audit{ }}, Subtract = EphA {Audit{Statistics}} } Madhubabu, et al. [Page 107] Internet-Draft Megaco/H.248 Call flow examples July 2001 } The ISDNTGW responds to the subtract commands generated by MGC. Step 8 ISDNTGW to MGC: MEGACO/1 [209.110.59.34]:25000 Reply = 1237{ 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 } } } } The MGC generates similar transaction with two commands towards the TGW that terminates SS7 media trunks. Step 9 MGC to TGW: MEGACO/1 [216.33.33.61]: 27000 Transaction = 1238 Context = 2 { Subtract = Trunk2/line1{Audit{ }}, Subtract = EphB {Audit{Statistics}} } } The SS7TGW responds to the subtract commands generated by MGC. Step 10 TGW to MGC: MEGACO/1 [209.110.59.34]:26000 Reply = 1238 Context = 2 { Subtract = Trunk2/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, Madhubabu, et al. [Page 108] Internet-Draft Megaco/H.248 Call flow examples July 2001 rtp/delay=30 ; average latency } } } } 2.12 Continuity test from TGW In this section we will illustrate the usage of Megaco command for performing continuity tests. The basic continuity package as defined in the protocol is considered. The procedures specified in the package are illustrated. There are two cases in the continuity test. One in which the MGC generates Megaco commands towards MG to initiate an continuity test and the second one in which the command from MGC enables the gateway to return any continuity test originated from switched circuit network. Case (a) __________________________________________________________________ | MG | MGC _______________________________|___________________________________ | | |<----------------------------------| | Modify TermA SD:ct/ct ED:ct/cmp state=test |---------------------------------->| | Modify TermA Resp | <------------| | Continuity Signal | | | ------------>| | Continuity Signal Resp | |---------------------------------->| | Notify TermA OE:ct/cmp {resp=success} |<----------------------------------| | Notify TermA Resp | _____________|___________________________________|__________________ The case of originating Continuity test by the Trunking gateway is considered in this section. The MGC intends to check the continuity of a specified circuit group line1 of the trunk Trunk1 in the Trunking gateway. The MGC generates a modify command with the termination state set to "test". The event descriptor specifies the "cmp" completion event of the continuity package. The Signal descriptor lists the "ct" continuity test signal. Step 1 MGC to TGW: MEGACO/1 [216.33.33.61]: 27000 Madhubabu, et al. [Page 109] Internet-Draft Megaco/H.248 Call flow examples July 2001 Transaction = 1234 { Context = '-' { Modify = Trunk1/line1 {Media { TerminationState {ServiceState = test}} Signals = { ct/ct } Events = 1111 { ct/cmp } } } } The TGW after receiving the Modify command for termination Trunk1/line1 in Null context, updates the termination state. The event descriptor is updated in the Trunking gateway. The signal "ct" is applied on the specified termination. The Trunking gateway now states for detecting any tones/signals on the line on which the continuity test signal was applied. The response for the message generated by MGC is sent back. Step 2 TGW to MGC: MEGACO/1 [207.176.47.89]: 26000 Reply = 1234 { Context = '-' { Modify = Trunk1/line1 } } The Trunking gateway detects for any return tone/signal. The frequency of the tone is assumed to be provisioned at the TGW. As soon as the response is received from the other side of the trunk the Trunking gateway reports the same to the MGC in the form of event detection. The event "cmp" in the event descriptor is used to notify the observed activity on the termination. The parameter value for the response parameter indicates the result of the continuity test performed. Step 3 TGW to MGC: MEGACO/1 [207.176.47.89]: 26000 Transaction = 2000 { Context = '-' { Notify = Trunk1/line1 {ObservedEvents =1111 { 20010202T10000000: ct/cmp { res=success}} } } The MGC after receiving the Notify message responds to the MGC with the response. Step 4 MGC to TGW: MEGACO/1 [216.33.33.61]: 27000 Reply = 2000 { Context = - {Notify = Trunk1/line1} Madhubabu, et al. [Page 110] Internet-Draft Megaco/H.248 Call flow examples July 2001 } Case (b) In the earlier continuity test scenario we saw the Megaco messages exchanged between MG and MGC when the MGC initiated the continuity test. In some scenarios the MG should respond to the continuity test originated from the PSTN switches. In this section we will consider such a scenario. __________________________________________________________________ | MG | MGC _______________________________|___________________________________ | | |<----------------------------------| | Modify TermA SD:ct/rsp | |---------------------------------->| | Modify TermA Resp | ------------>| | Continuity Signal | | | <------------| | Continuity Signal Resp | _____________|___________________________________|__________________ The continuity package signal "rsp" is used for this purpose. This signal duration and frequency are provisioned at the TGW. When the MGC is intimated form the PSTN switch for responding the continuity test, the MGC generates a Modify command with the "rsp" signal in the signal descriptor. The termination state is set to "test". Step 1 MGC to TGW: MEGACO/1 [216.33.33.61]: 27000 Transaction = 1234 { Context = '-' { Modify = Trunk1/line1 {Media { TerminationState {ServiceState = test} LocalControl { mode = loopback} } Signals = { ct/rsp } } } } There can be two possible cases for responding the continuity test originated from the PSTN network. One in which the Trunking gateway generates a signal of different frequency when it receives a continuity check specific signal. The second possibility is to respond with the same signal looped back to the same switch that originated it. In Madhubabu, et al. [Page 111] Internet-Draft Megaco/H.248 Call flow examples July 2001 this example we assume the case of Loopback. The mode of the termination is also set to loopback to facilitate this. The Trunking gateway after receiving the signal loops back the same signal. The Trunking gateway also responds with the transaction response message towards the MGC. Step 2 TGW to MGC: MEGACO/1 [207.176.47.89]: 26000 Reply = 1234 { Context = '-' { Modify = Trunk1/line1 } } Once the test is complete the MGC is intimated about the success of failure of the continuity test through the switch that originated the continuity test. 2.13 Call from residential gateway to H.323 Terminal. In This section we illustrate a call between a Residential gateway user and to an endpoint in the H.323 domain. We assume that the call is initiated from the user of the Residential gateway and after dialing the digits the MGC does necessary mapping of the number to identify that the called number belongs to the H.323 network. _________________________________________________________________________ | | | | RGW | MGC | GK | H.323EP | _______________|_________________|__________________|__________________|_ | | | | |<--------------| | | | Modify | | | ------>| | | | OffHook|-------------->| | | <------| Modify Resp | | | DialTone | | | |-------------->| | | | Notify OffHook | | |<--------------| | | | Notify Resp | | | ------>| | | | Digits |-------------->| | | | Notify Digits| | | |<--------------| | | | Notify Resp | | | Madhubabu, et al. [Page 112] Internet-Draft Megaco/H.248 Call flow examples July 2001 | |------------------>| | | | ARQ | | | |<------------------| | | |------------------------------------>| | | Setup | | | |<----------------| | | | ARQ | | | |---------------->| | | | ACF | | |<------------------------------------| | | Alerting | <------| | | | RingBack tone | | | |<--------------| | | |Add Phy | | | |Add Eph Local Unspecified | | |-------------->| | | |Add Phy Resp | | | |Add Eph Resp Local Specified | | | |<------------------------------------| | | Connect | | |<----------------------------------->| | | TCS | | |<----------------------------------->| | | MSD | | |<----------------------------------->| | | OLC (forward Logcial ch)RGW rtp/rtcp| | |<----------------------------------->| | | OLC (Rev Logical Ch) H.323 rtp/rtcp | |<--------------| | | | Modify Eph Remote Specified | | |-------------->| | | |Modify Resp | | | |/---------------------------------------------------\| | RTP Media | |\---------------------------------------------------/| | |<----------------------------------->| | | CLC SessionId = 1 | | |<----------------------------------->| |<--------------| | | <------| Modify SD:cg/bt | | Ringbacktone |<----------------------------------->| | | CLC SessionId = 2 | |-------------->| | | | Modify Resp | | | | |<------------------------------------| | | Release Complete | | |------------------>| | | | DRQ |<----------------| |<--------------| | DRQ | |Sub Phy |<------------------|---------------->| Madhubabu, et al. [Page 113] Internet-Draft Megaco/H.248 Call flow examples July 2001 |Sub Eph Stats | DCF | DCF | _______|_______________|___________________|_________________|_______ 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 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}} } Madhubabu, et al. [Page 114] Internet-Draft Megaco/H.248 Call flow examples July 2001 } 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 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 {Observed Events =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 analyses the digits sent by the Residential Gateway. The routing functionality in MGC enabled and it indicates that the dialed digits belong to the user in H.323 network. The MGC acts as a H.323 Terminal towards H.323 network and generates the signaling towards the destined Called party. The MGC initially generates an admission request towards the Gatekeeper. The Gatekeeper acknowledges the admission request message by generating the Admission confirmation message ACF. Assuming that the GK used directed-routed call model, the Gatekeeper provides the transport address information of the destination user. The MGC then initiates the H.225 signaling by generating the SETUP message towards the H.323 endpoint. The H.323 Endpoint after receiving the Setup message from the MGC initiates the Admission request towards the Gatekeeper. The H.323 Endpoint after receiving the Admission confirmation message from the Gatekeeper generates the Alerting message towards the MGC. The MGC after receiving the ALERT message from the H.323 Endpoint generates a Add command to the Residential gateway to apply ring back tone to the given termination. In the Add command the MGC requests the creation Madhubabu, et al. [Page 115] Internet-Draft Megaco/H.248 Call flow examples July 2001 of ephemeral termination and under specifies the Local SDP information. The mode of the termination 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 = sendrecv, }, } Add = $ { Media { { LocalControl { Mode = sendrecv, }, 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 Madhubabu, et al. [Page 116] Internet-Draft Megaco/H.248 Call flow examples July 2001 m=audio 30000 RTP/AVP 4 a=recvonly } ; RTP profile for G.723 is 4 } } } } } The H.323 Endpoint generates the CONNECT message after the called party goes offhook. We assume that the H.245 information is passed in Connect message. The Terminal Capability set and the Master slave determination occurs between the MGC and the H.323 Endpoint. The Open Logical channel messages (OLCs) indicate the session and media related parameters. This enables the MGC to inform and receive the SDP information of both the users. By the end of this OLCs the MGC is aware of the SDP information of the H.323 Endpoint. The MGC now generates Modify message towards the MG, with the Remote SDP information for the ephemeral termination EphA. Step 9: MGC to RGW: MEGACO/1 [216.33.33.61]: 27000 Transaction = 1236 { Context = 1 { Modify = TermA { Signals { } ; to turn off ringback tone Events = 1235 {al/on}, 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 G.723 is 4 } } } The RGW responds to the request from MGC. Step 10 RGW to MGC: Madhubabu, et al. [Page 117] Internet-Draft Megaco/H.248 Call flow examples July 2001 MEGACO/1 [207.176.47.89]: 26000 Reply = 1236 { Context = 1 {Modify = TermA , Modify = EphA} } Now RTP media flow takes place. In the example we assume that the H.323 goes onhook to terminate the call. The MGC initiates the tearing down of the Call by closing the logical channels that were earlier created for exchanging the H.245 information. The MGC after receiving the DISCONNECT message generates a Modify message towards the Residential gateway user for applying the busy tone and for making the mode of the two terminations to receive only. Step 11 MGC to RGW: 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} } } } } } The RGW responds to this modify request. Step 12 MG2 to MGC: MEGACO/1 [207.176.47.89]: 26000 Reply = 1240 { Context = 1 { Modify= TermA, Modify = EphA} } Step 13: RGW1 to MGC: MEGACO/1 [209.110.59.34]:25000 Transaction = 2002 { Context = 1 { Notify = TermA {ObservedEvents =1235{ Madhubabu, et al. [Page 118] Internet-Draft Megaco/H.248 Call flow examples July 2001 20010202T10030000:al/on} } } The MGC responds to the MG1s Notify message. Step 14 MGC to RGW1: MEGACO/1 [216.33.33.61]:27000 Reply = 2002 { Context = 1 { Notify = TermA } } The MGC after the Release Complete message waits for the Notify command with onhook event from UserA and after receiving subtracts the physical and ephemeral termination at the Residential gateway. Thus enabling the user to participate in further calls. Step 15 MGC to RGW MEGACO/1 [216.33.33.61]: 27000 Transaction = 1238 { Context = 1 { Subtract = TermA {Audit{ }}, Subtract = EphA {Audit{Statistics}} } } The MG subtracts the two terminations from the context. The context itself is deleted with subtract of the last termination from it. The RGW responds to this transaction from MGC with statistics on ephemeral termination. Step 16 RGW to MGC: MEGACO/1 [209.110.59.34]:25000 Reply = 1238 { 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 } } } Madhubabu, et al. [Page 119] Internet-Draft Megaco/H.248 Call flow examples July 2001 } 2.14 Call from residential gateway to SIP user. This section illustrates a call between a user connected to Residential gateway and another SIP user. It is assumed that the MGC acts as a SIP server agent. The MGC generates SIP messages towards the SIP user agent/called party. When the MGC receives the digits dialed by the user even though not explicitly shown in the figure, it communicates with a routing database and finds the SIP user agent's URL. ___________________________________________________________________ | | RGW | MGC | SIP User __________________|_________________________|______________________ | | | |<--------------------| | |Modify TermA {ED=al/of{SD:cg/dt,ED:al/on,dd/ce{dmap}}} |-------------------->| | ----->| | | OffHook | | |-------------------->| | | Notify OffHook | | |<--------------------| | | Notify Resp | | ------>| | | Digits| | | |-------------------->| | | Notify Digits | | |<--------------------| | | Notify Resp | | | |------------------------>| | | INVITE | | |<------------------------| | | 180 (RING) | |<--------------------| | |Add TermA SD:cg/rt | | |Add Eph Local Unspecified | | Remote SPecified | |-------------------->| | | Add Phy Resp | | | Add Eph Local Specified | <------| | | RingBack Tone | | | |------------------------>| | | ACK (SDP Specified) | |/---------------------------------------------\| | RTP Media | |\---------------------------------------------/| ------>| | | Madhubabu, et al. [Page 120] Internet-Draft Megaco/H.248 Call flow examples July 2001 OnHook |-------------------->| | | Notify OnHook | | |<--------------------|------------------------>| | Notify Resp | BYE | |<--------------------| | | Sub TermA | | | Sub EphA |<------------------------| |-------------------->| 200 OK | | Sub Phy Resp | | | Sub Eph Resp Statistics | ______|_____________________|_________________________|________ 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 report the event detection using Madhubabu, et al. [Page 121] Internet-Draft Megaco/H.248 Call flow examples July 2001 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 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 analyses the digits sent by the Residential Gateway. The routing functionality in MGC enabled and it indicates that the dialed digits belong to the SIP user. The MGC acts as a SIP User agent, and generates a INVITE message towards the SIP user. INVITE sip:UserB@there.com SIP/2.0 Via: SIP/2.0/UDP here.com:5060 Madhubabu, et al. [Page 122] Internet-Draft Megaco/H.248 Call flow examples July 2001 From: Bob To: Julien Call-ID: 12345601@here.com CSeq: 1 INVITE Contact: Bob Content-Type: application/sdp Content-Length: 0 The SDP information is not provided in this INVITE message. The MGC receives the 180- OK message from the SIP user to indicate that ringing is done towards that end. SIP/2.0 180 Ringing Via: SIP/2.0/UDP here.com:5060 From: Julien To: Bob;tag=8321234356 Call-ID: 12345601@here.com CSeq: 1 INVITE Content-Length: 0 The MGC generates a Modify message to the Residential gateway to apply ringback tone to the given termination. Step 7 MGC to RGW: MEGACO/1 [216.33.33.61]: 27000 Transaction = 1235 { Context = $ { Modify = TermA { Signals { cg/rt } } } } The MG after receiving the Modify message applies ringback tone to the user and generates Modify response. Step 8 RGW to MGC: MEGACO/1 [209.110.59.34]: 25000 Reply = 1235 { Context = - {Modify = TermA} } The MGC meanwhile receives the 200 OK message from the SIP user to indicate its SDP information. SIP/2.0 200 OK Via: SIP/2.0/UDP here.com:5060 From: Julien To: Bob;tag=8321234356 Call-ID: 12345601@here.com Madhubabu, et al. [Page 123] Internet-Draft Megaco/H.248 Call flow examples July 2001 CSeq: 1 INVITE Contact: Julien Content-Type: application/sdp Content-Length: 147 v=0 o=UserB 2890844527 2890844527 IN IP4 there.com s=Session SDP c=IN IP4 207.176.47.90 t=0 0 m=audio 35000 RTP/AVP 4 a=rtpmap:0 PCMU/8000 The MGC now 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 Remote SDP information is also sent. The mode of the two terminations is set to send receive. Step 9 MGC to RGW: MEGACO/1 [216.33.33.61]: 27000 Transaction = 1236 { Context = $ { Add = TermA { Media { { LocalControl { Mode = sendrecv, }, } Add = $ { Media { { LocalControl { Mode = sendrecv, }, Local { v=0 c=IN IP4 $ m=audio $ RTP/AVP 4 } Remote{ v=0 c=IN IP4 207.176.47.90 m=audio 35000 RTP/AVP 4 } } } } Madhubabu, et al. [Page 124] Internet-Draft Megaco/H.248 Call flow examples July 2001 } 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 10 RGW to MGC: MEGACO/1 [209.110.59.34]: 25000 Reply = 1236 { Context = 1 { Add = TermA, Add=EphA{ Media { Local { v=0 c=IN IP4 209.110.59.33 m=audio 30000 RTP/AVP 4 a=sendrecv } ; RTP profile for G.723 is 4 } } } } } In the ACK message of SIP, the local SDP information is indicated towards the remote SIP user. ACK sip:UserB@there.com SIP/2.0 Via: SIP/2.0/UDP here.com:5060 From: Bob To: Julien;tag=8321234356 Call-ID: 12345601@here.com CSeq: 1 ACK Content-Length: 147 v=0 o=UserA 2890844526 2890844526 IN IP4 here.com s=Session SDP c=IN IP4 209.110.59.33 m=audio 30000 RTP/AVP 4 a=rtpmap:0 PCMU/8000 Now RTP media flow takes place. In the example we assume that the UserA goes onhook to terminate the call. The RGW after detecting the Madhubabu, et al. [Page 125] Internet-Draft Megaco/H.248 Call flow examples July 2001 event reports the same to MGC in the Notify command. Step 11: 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 12 MGC to MG1: MEGACO/1 [216.33.33.61]:27000 Reply = 2002 { Context = 1 { Notify = TermA } } The MGC now generates subtract commands to the RGW. The BYE message is generated by the MGC towards the other SIP user. BYE sip:UserB@here.com SIP/2.0 Via: SIP/2.0/UDP there.com:5060 From: Bob;tag=8321234356 To: Julien Call-ID: 12345601@here.com CSeq: 1 BYE Content-Length: 0 The MGC after sending the BYE message recives the 200 OK message from the remote SIP user. SIP/2.0 200 OK Via: SIP/2.0/UDP there.com:5060 From: Julien;tag=8321234356 To: Bob Call-ID: 12345601@here.com CSeq: 1 BYE Content-Length: 0 The two Subtract commands are clubbed in a single action. Step 13 MGC to RGW MEGACO/1 [216.33.33.61]: 27000 Transaction = 1238 { Context = 1 { Madhubabu, et al. [Page 126] Internet-Draft Megaco/H.248 Call flow examples July 2001 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 14 RGW to MGC: MEGACO/1 [209.110.59.34]:25000 Reply = 1238 { 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 } } } } 3 Service Change Command Usage This section lists the few methods that illustrate the usage of MEGACO protocol defined service change methods. The scenarios takes into consideration both ROOT termination and specific terminations. The intention of the section is to provide the usage of different methods and the situations when each of the methods needs to be used. 3.1 ROOT Termination. 3.1.1 Registration. The MEGACO protocol defined a special termination called the ROOT termination to address the gateway as a whole. This enables easy addressing from both MG and MGC to address the gateway as a single entity. The virtual MG situations are not discussed in this version of the call flow draft. The Media Gateway once ready to receive messages from MGC registers itself using the Service change command. The termination Identifier ROOT is used for this purpose. This can be treated as the first Madhubabu, et al. [Page 127] Internet-Draft Megaco/H.248 Call flow examples July 2001 messages sent from MG to MGC. The call flow assumes that the MGC is ready to receive the messages from the MG. _______________________________________________________________________ | Media Gateway | Media Gateway Controller ___________________________________|___________________________________ | | Port Num 2944 PortNum |------------------------------------>| 20000 |ServiceChange ROOT Method=Restart Sca=15000 | | PortNum 20000|<------------------------------------| Port Num 2944 |ServiceChange Resp ROOT sca=25000 | | | PortNum 15000|<------------------------------------| PortNum 25000 | Modify *Event al/of | | | Port Num 15000|------------------------------------>| PortNum 25000 | Modify Response | _____________|_____________________________________|____________________ In the following example MG generates the registration message to the default port of MGC, it also specifies the service change address to which the MGC has to send further messages. MGC also specifies the new transport address so that when MG generates any messages it generates to this address instead of the default transport address for the MGC. In the example it is to be noted that the MGC is generating the MODIFY command to the new transport address specified by MG in its registration command. The first command sent from MG (once it is ready to receive message) is the Service Change command, with ROOT termination identifier. In the example MG is generating the registration message to the default port of MGC (defined by protocol 2944 for Text message) Step 1: MG to MGC: MEGACO/1 [209.110.59.34]: 20000 Transaction = 1234 { Context = - { ServiceChange = ROOT {Services { Method=Restart, ServiceChangeAddress=15000, Profile=ResGW/1, 12345677T87654320} } } Madhubabu, et al. [Page 128] Internet-Draft Megaco/H.248 Call flow examples July 2001 } The MGC responds the registration request to the same transport address used by MG to send the request. In the response MGC specifies its new transport address, that needs to be used by MG for further messages generated towards MGC.(In example 25000). Step 2: MGC to MG: MEGACO/1 [216.33.33.61]:2944 Reply = 1234 { Context = - {ServiceChange = ROOT { Services {ServiceChangeAddress=25000, Profile=ResGW/1 , 12345678T87654321} } } } In the example it is also shown that the MGC uses the transport address specified by MG for receiving messages. The initial MODIFY command sent to check for offhook event on all termination is sent to the new transport address specified by MG. Step 3: MGC to MG: MEGACO/1 [216.33.33.61]:25000 Transaction = 9999 { Context = - { Modify = * { Events = 1234 {al/of} } } } The MG generates response to the new transport address specified by MGC in its registration response. Step 4: MG to MGC: MEGACO/1 [209.110.59.34]:15000 Reply = 9999 { Context = - {Modify = A1} Context = - {Modify = A2} Context = - {Modify = A3} } 3.1.2 Cold Start A MG is pre-provisioned by a management mechanism with a Primary and (optionally) an ordered list of Secondary MGC's. Upon a cold start of the MG, it will issue a ServiceChange command with a "Restart" method, on the Root Termination to its primary MGC. If the MGC accepts the MG, it will send a Transaction Accept, with the ServiceChangeMgcId set to it. If the MG receives an ServiceChangeMgcId not equal to the MGC Madhubabu, et al. [Page 129] Internet-Draft Megaco/H.248 Call flow examples July 2001 it contacted, it sends a ServiceChange to the MGC specified in the ServiceChangeMgcId. In this example the MG generate a registration command towards the secondary MGC. The secondary MGC responds with the service change address to enable MG to send further messages to that specified port. ____________________________________________________________________ | | Media Gateway | Primary MGC | Secondary MGC ______________________|_________________________|___________________ | | | |----------------------->| | | ServiceChange ROOT | | | Method = Restart | | |<-----------------------| | | ServiceChange Resp ROOT| | | ServiceChangeMGCId=209.110.59.33:25000 | |---------------------------------------------->| | ServiceChange ROOT Method=Restart | |<----------------------------------------------| | ServiceChange ROOT Resp | __________|________________________|______________________|_________ The first command sent from MG (once it is ready to receive message) is the Service Change command, with ROOT termination identifier. In the example MG is generating the registration message to the Primary MGC. Step 1: MG to MGC: MEGACO/1 [209.110.59.34]: 20000 Transaction = 1234 { Context = - { ServiceChange = ROOT {Services { Method=Restart, } } } } The MGC responds the registration request by specifying a new transport address of the secondary MGC that needs to be used by MG for generating another registration command towards secondary MGC. Step 2: MGC to MG: MEGACO/1 [216.33.33.61]:25000 Reply = 1234 { Madhubabu, et al. [Page 130] Internet-Draft Megaco/H.248 Call flow examples July 2001 Context = - {ServiceChange = ROOT { Services {mgcid=209.110.59.33:25000, Profile=ResGW/1 , 12345678T87654321} } } } MG generates the Service Change command to the MGC specified by the primary MG. Step 3: MG to MGC: MEGACO/1 [209.110.59.34]: 25000 Transaction = 4321 { Context = - { ServiceChange = ROOT {Services { Method=Restart, Reason="Cold Boot", Profile=ResGW/1, 12345677T87654320} } } } The MGC after receiving the registration request from the MG responds with the Service Change reply. Step 4: MGC to MG: MEGACO/1 [216.33.33.62]: 27000 Transaction = 4321 { Context = - { ServiceChange = ROOT {Services { Profile=ResGW/1, 12345677T87654320} } } } 3.1.3 Handoff The Handoff method can be used both by MG and MGC. In the scenario below MGC uses this method to indicate that it is going out of service and the MGC specified in the service change need to be contacted. The MG subsequently generates the handoff message to the MGC specified in the Service change mgId in the message generated by the controlling MGC. Madhubabu, et al. [Page 131] Internet-Draft Megaco/H.248 Call flow examples July 2001 ____________________________________________________________________ | | Media Gateway | MGC1 | MGC2 ______________________|_________________________|___________________ | | | |<-----------------------| | | ServiceChange ROOT | | | Method = Handoff | | | mgcidtotry=199.164.0.197:45678 | |<-----------------------| | | ServiceChange Resp ROOT| | | | | |---------------------------------------------->| | ServiceChange ROOT Method=Handoff | | Reason="MGC directed Change" | |<----------------------------------------------| | ServiceChange ROOT Resp | __________|________________________|______________________|_________ The MGC generates the ServiceChange command with Handoff as the method. It also specifies the MGC that needs to be tried by the MG. Step 1: MGC to MG: MEGACO/1 [209.110.59.34]: 20000 Transaction = 1234 { Context = - { ServiceChange = ROOT {Services { Method=Handoff, MgcIdToTry=199.164.0.197:45678, Profile=ResGW/1, 12345677T87654320} } } } After receiving the command from MGC, the MG tries for the MG that is specified in the message. It first responds to the service Change command generated by the controlling MGC. Step 2: MG to MGC: MEGACO/1 [216.33.33.61]: 25000 Reply = 1234 { Context = - { ServiceChange = ROOT } } Madhubabu, et al. [Page 132] Internet-Draft Megaco/H.248 Call flow examples July 2001 MG generates the Service Change command to the MGC specified by the primary MG. Step 3: MG to MGC: MEGACO/1 [209.11.59.34]: 25000 Transaction = 4321 { Context = - { ServiceChange = ROOT {Services { Method=Handoff, Reason="MGC Directed Change", Profile=ResGW/1, 12345677T87654320} } } } The MGC after receiving the Handoff request from the MG responds with the Service Change reply. Step 4: MGC to MG: MEGACO/1 [216.33.33.62]: 27000 Reply = 4321 { Context = - { ServiceChange = ROOT {Services { Profile=ResGW/1, 12345677T87654320} } } } 3.1.4 Disconnection The MG issues the disconnection method of Service Change when it lost the communication with MGC and later regains it. The MGC normally generates an Audit message to assess the state of the terminations before and after the disconnection. The Audit command enables MGC to synchronize its state with the MG's state. _______________________________________________________________________ | Media Gateway | Media Gateway Controller ___________________________________|___________________________________ | : | | : | | : | | MG lost communication with MGC | | | Madhubabu, et al. [Page 133] Internet-Draft Megaco/H.248 Call flow examples July 2001 |------------------------------------>| |ServiceChange ROOT Method=Disconnection | Reason="loss of lower layer Connectivity" | | |<------------------------------------| | ServiceChange Resp ROOT | | | |<------------------------------------| | Audit * ED,SD,MD | | | |------------------------------------>| | Audit EphA Response ED,SD,MD | _____________|_____________________________________|____________________ The MG generates ServiceChange command towards the MGC with method = disconnection on the ROOT termination and with reason = "Loss of lower layer connectivity". Step 1: MG to MGC: MEGACO/1 [209.110.59.34]: 20000 Transaction = 1234 { Context = - { ServiceChange = ROOT {Services { Method=Disconnection, Reason=" Loss of lower layer connectivity" } } } } The MGC responds the disconnection message by responding with Service Change response. Step 2: MGC to MG: MEGACO/1 [216.33.33.61]:25000 Reply = 1234 { Context = - {ServiceChange = ROOT { } } } The MGC after receiving the disconnection message audits the terminations that are present in the Media Gateway. The Audit response enables MGC to assess the state of the termination before and after disconnection. Step 3 MGC to MG: Madhubabu, et al. [Page 134] Internet-Draft Megaco/H.248 Call flow examples July 2001 MEGACO/1 [216.33.33.61]:27000 Transaction = 1235 { Context = 2 {AuditValue = *{ Audit{Media, DigitMap, Events, Signals, Packages, Statistics }} } } The MG responds with the media descriptor, packages and statistics. The Digit map, signal and events are not defined on this termination hence only tokens are sent back in the response. Step 4 MG to MGC: MEGACO/1 [209.110.59.34]:25000 Reply = 1235 { Context = 2 { AuditValue = EphA { Media { TerminationState { ServiceState = InService, Buffer = OFF }, Stream = 1 { LocalControl { Mode = SendReceive, nt/jit=40 }, Local { v=0 c=IN IP4 209.110.59.33 m=audio 30000 RTP/AVP 0 a=ptime:30 }, Remote { v=0 c=IN IP4 207.176.47.90 m=audio 40000 RTP/AVP 0 a=ptime:30 } } }, audit { Events, Signals, DigitMap}, Packages {nt-1, rtp-1}, Statistics { rtp/ps=1200, ; packets sent nt/os=62300, ; octets sent rtp/pr=700, ; packets received nt/or=45100, ; octets received rtp/pl=0.2, ; % packet loss rtp/jit=20, rtp/delay=40 } ; avg latency } } } Madhubabu, et al. [Page 135] Internet-Draft Megaco/H.248 Call flow examples July 2001 3.2 Service Change for Termination The service change command can be used on terminations to take terminations from in-service to out-of-service and vice versa. This section illustrates the use of service change on termination generated both from MG and MGC. The wildcard termination identifiers scenarios are discussed in a separate section. 3.2.1 MG generated Service Change 3.2.1.1 Graceful OOS from MG The graceful method of service change when generated from MG is used to intimate MGC the removal of terminations from in-service. The Service Change delay is used to specify the period after which the termination will be removed from service. The service change delay can be NULL or any other 32bit-value. We will consider both the cases here. Case a deals the simple case where the delay is 350 seconds and in case b we will consider NULL value for the delay. case (a) _______________________________________________________________________ | Media Gateway | Media Gateway Controller ___________________________________|___________________________________ | | | | |------------------------------------>| |ServiceChange CtxId=2 TermA | | Method=Graceful, Delay = 350 | | | |<------------------------------------| | ServiceChange Resp | | | | : | | : | | : | After 350 Seconds TermA is taken out of service | | |<------------------------------------| | Subtract Ctxid=2 TermA | | | |------------------------------------>| | Subtract Resp Ctxid=2 TermA | _____________|_____________________________________|____________________ Madhubabu, et al. [Page 136] Internet-Draft Megaco/H.248 Call flow examples July 2001 Step 1 MG to MGC: MEGACO/1 [216.33.33.61]: 25000 Transaction = 4321 { Context = 123 { ServiceChange = TermA {Services { Method=Graceful, Reason="Termination taken out of Service",Delay = 350 } } } In the first step MG generates the service change command with Graceful method. The termination "TermA" is in context 123. The delay 350 indicates MGC that the termination will be moved to out-of-service after 350 seconds. Step 2 MGC to MG: MEGACO/1 [207.176.47.89]: 27000 Reply = 4321 { Context = 123 { ServiceChange = TermA { } } } After 350 seconds the MG removes the termination "TermA" out of service. As the responsibility of clearing the context lies with the MGC, it generates the Subtract command to remove the termination out of context. The audit descriptor in this example is shown to be present and shown empty. This indicates that the MGC is not interested in any statistics to be returned in the response from MG. Step 3 MGC to MG: MEGACO/1 [207.176.47.89]: 27000 Transaction = 1234 { Context = 123 { Subtract = TermA { Audit = {} } } } The MG responds with the Subtract response. By the time the subtract is received by MG, the termination is out-of-service. The Subtract command can be received even for terminations that are out-of-service. After subtracting the termination from the context, the dynamic information for the context pertained to that termination is cleared. Madhubabu, et al. [Page 137] Internet-Draft Megaco/H.248 Call flow examples July 2001 Step 4 MG to MGC: MEGACO/1 [987.654,321.1]: 25000 Reply = 1234 { Context = 123 { Subtract = TermA { } } } case (b) In this subsection we consider the case where the delay specified by MG is NULL. This indicates that the termination will be taken out-of-service after the termination is subtracted from valid context. _______________________________________________________________________ | Media Gateway | Media Gateway Controller ___________________________________|___________________________________ | | | | |------------------------------------>| |ServiceChange CtxId=2 TermA | | Method=Graceful, Delay = NULL | | | |<------------------------------------| | ServiceChange Resp | | | | : | | : | | : | | | |<------------------------------------| | Subtract Ctxid=2 TermA | | | |------------------------------------>| | Subtract Resp Ctxid=2 TermA | | TermA Taken Out-of-service | _____________|_____________________________________|____________________ Step 1 MG to MGC: MEGACO/1 [216.33.33.61]: 25000 Transaction = 4321 { Context = 123 { Madhubabu, et al. [Page 138] Internet-Draft Megaco/H.248 Call flow examples July 2001 ServiceChange = TermA {Services { Method=Graceful, Reason="Termination taken out of Service",Delay =0 } } } MGC after receiving gets that information that the termination will not be available after the call. MGC should inhibit using this termination further in it calls. MGC responds to the MG for the command it received. Step 2 MGC to MG: MEGACO/1 [207.176.47.89]: 27000 Reply = 4321 { Context = 123 { ServiceChange = TermA { } } } The MGC after the call is complete subtracts the termination from the context and avoids using this termination in further calls. Even in this example the audit descriptor is empty. Step 3 MGC to MG: MEGACO/1 [207.176.47.89]: 27000 Transaction = 1234 { Context = 123 { Subtract = TermA { Audit = {} } } } MG after receiving the message from MGC, responds to the message and immediately removes the termination to out-of-service. Step 4 MG to MGC: MEGACO/1 [987.654,321.1]: 25000 Reply = 1234 { Context = 123 { Subtract = TermA { } } } 3.2.1.2 Forced OOS from MG Madhubabu, et al. [Page 139] Internet-Draft Megaco/H.248 Call flow examples July 2001 The Forced method of service change when generated from MG is used to intimate MGC the removal of terminations from in-service. The termination may be in a valid Context or NULL context when MG has generated this message. We will consider both the cases here. Case (b) deals the simple case where the termination is in NULL context and in case (a) the termination is in Valid Context . case (a) _______________________________________________________________________ | Media Gateway | Media Gateway Controller ___________________________________|___________________________________ | | | | |------------------------------------>| |ServiceChange CtxId=123 TermA | | Method = Forced | | | |<------------------------------------| | ServiceChange Resp | | | Immediately TermA is taken out of service | | |<------------------------------------| | Subtract Ctxid=123 TermA | | | |------------------------------------>| | Subtract Resp Ctxid=123 TermA | _____________|_____________________________________|_________________ Step 1 MG to MGC: MEGACO/1 [216.33.33.61]: 25000 Transaction = 4321 { Context = 123 { ServiceChange = TermA {Services { Method=Forced } } } } In the first step MG generates the service change command with "Forced" Service Change method. The termination "TermA" is in context 123. Step 2 MGC to MG: Madhubabu, et al. [Page 140] Internet-Draft Megaco/H.248 Call flow examples July 2001 MEGACO/1 [207.176.47.89]: 27000 Reply = 4321 { Context = 123 { ServiceChange = TermA { } } } After generating the message MG immediately removes the termination "TermA" out of service. As the responsibility of clearing the context lies with the MGC, it generates the Subtract command to remove the termination out of context. The audit descriptor in this example is shown to be present and shown empty. This indicates that the MGC is not interested in any statistics to be returned in the response from MG. Step 3 MGC to MG: MEGACO/1 [207.176.47.89]: 27000 Transaction = 1234 { Context = 123 { Subtract = TermA { Audit = {} } } } The MG responds with the Subtract response. When the subtract message is received by MG, the termination is out-of-service. The Subtract command can be received even for terminations that are out-of-service. After subtracting the termination from the context, the Call specific information for the context pertained to that termination is cleared. Step 4 MG to MGC: MEGACO/1 [987.654,321.1]: 25000 Reply = 1234 { Context = 123 { Subtract = TermA { } } } case (b) In this subsection we consider the case where the termination is in NULL context. This indicates that the termination will be immediately taken out-of-service. Madhubabu, et al. [Page 141] Internet-Draft Megaco/H.248 Call flow examples July 2001 _______________________________________________________________________ | Media Gateway | Media Gateway Controller ___________________________________|___________________________________ | | | | |------------------------------------>| |ServiceChange CtxId=NULL TermA | | Method = Forced | | | |<------------------------------------| | ServiceChange Resp | | | Immediately TermA is taken out of service | | _____________|_____________________________________|_________________ Step 1 MG to MGC: MEGACO/1 [216.33.33.61]: 25000 Transaction = 4321 { Context = - { ServiceChange = TermA {Services { Method=Forced } } } } MGC after receiving gets that information should inhibit using this termination further in its calls. MGC responds to the MG for the command it received. Step 2 MGC to MG: MEGACO/1 [207.176.47.89]: 27000 Reply = 4321 { Context = - { ServiceChange = TermA { } } } 3.2.1.3 Restart INS from MG In this we will consider the message generation from MG when terminations are brought back to in-service state after they have been removed from out-of-service. Initially when the MG comes up, it doesn't generate any in-service message for specific terminations, as the service change generated on ROOT terminations serves the same purpose. Madhubabu, et al. [Page 142] Internet-Draft Megaco/H.248 Call flow examples July 2001 MG can generate restart for multiple terminations using the wildcard mechanism. But for simplicity we are considering the case where the termination "TermA" is brought back to service. _______________________________________________________________________ | Media Gateway | Media Gateway Controller ___________________________________|___________________________________ | | | | |------------------------------------>| |ServiceChange CtxId=NULL TermA | | Method = Restart | | | |<------------------------------------| | ServiceChange Resp | | | Immediately TermA is brought back to service | | _____________|_____________________________________|_________________ Step 1 MG to MGC: MEGACO/1 [216.33.33.61]: 25000 Transaction = 4321 { Context = - { ServiceChange = TermA {Services { Method=Restart} } } } MGC after receiving the message updates its Database for using this Termination for future use . MGC responds to the MG for the command it received. Step 2 MGC to MG: MEGACO/1 [207.176.47.89]: 27000 Reply = 4321 { Context = - { ServiceChange = TermA { } } } 3.2.2 MGC generated Service Change In the earlier section we saw few scenarios where the MG generated Madhubabu, et al. [Page 143] Internet-Draft Megaco/H.248 Call flow examples July 2001 messages to MG indicating the change of state in the termination. In this section we will look into the cases where MGC generates the service change message on terminations to remove the terminations from in-service to out-of-service and vice-versa. 3.2.2.1 Forced OOS from MGC When the MGC intends to remove the termination from in-service to out-of-service, it generates a forced service change message towards MG. MG immediately removes the termination from in-service to out-of-service. If the termination is in valid context, MGC can generate subtract command and following that another message with service change command to remove it from service. _______________________________________________________________________ | Media Gateway | Media Gateway Controller ___________________________________|___________________________________ | | | | |<------------------------------------| |ServiceChange CtxId=NULL TermA | | Method = Forced | | | |------------------------------------>| | ServiceChange Resp | Immediately TermA is taken out of service | | _____________|_____________________________________|_________________ Step 1 MGC to MG: MEGACO/1 [207.176.47.89]: 27000 Transaction = 4321 { Context = - { ServiceChange = TermA { Method=Forced } } } MG after receiving the message from MG removes the termination immediately from service. The response is generated towards for the message received from MGC. Step 2 MG to MGC: MEGACO/1 [209.11.33.62]: 25000 Reply = 4321 { Context = - { Madhubabu, et al. [Page 144] Internet-Draft Megaco/H.248 Call flow examples July 2001 ServiceChange = TermA { } } } 3.2.2.2 Restart from MGC When the MGC intends to bring the termination from out-of-service to in-service, it generates a restart method of service change message towards MG. MG immediately brings the termination from out-of-service to in-service. _______________________________________________________________________ | Media Gateway | Media Gateway Controller ___________________________________|___________________________________ | | | | |<------------------------------------| |ServiceChange CtxId=NULL TermA | | Method = Restart | | | |------------------------------------>| | ServiceChange Resp | Immediately TermA is brought back to service | | _____________|_____________________________________|_________________ Step 1 MGC to MG: MEGACO/1 [207.176.47.89]: 27000 Transaction = 4321 { Context = - { ServiceChange = TermA { Method=Restart } } } MG after receiving the message from MG brings the termination immediately to service. The response is generated towards for the message received from MGC. Step 2 MG to MGC: MEGACO/1 [209.11.33.62]: 25000 Reply = 4321 { Context = - { ServiceChange = TermA { Madhubabu, et al. [Page 145] Internet-Draft Megaco/H.248 Call flow examples July 2001 } } } 4.0 Audit Command Usage The Audit command is defined in the protocol to enable MGC to get information from MG to MGC. The information received may contain the values present at the MG on a given termination or possible values that can be supported on the given termination depending upon whether the command is Audit Value or Audit Capability. The Audit command can be used on Root Termination also. The Audit command is used by MGC when it needs the state of the termination and the parameter values for that given termination. Wildcard termination identifier and wildcard contextID can be used by MGC in these Audit command. 4.1 Audit Value The Audit value command can be sent from MGC to know the present values of the descriptors requested. The Audit Value command can be sent on either ROOT termination or any other termination in the MG. The section 2.1.1 illustrates the usage of Audit Value command on ROOT termination and section 2.1.2 illustrates the usage of Audit value command on a given termination. 4.1.1 Audit value command on ROOT Termination The ROOT termination denotes the entire gateway as a single entity. There are two possible cases of Audit Value command on ROOT termination. The one in which the ContextId is NULL and the other in which the contextID is ALL. The case (a) below illustrate when the Audit Value command when the ContextId is * and in case (b) other in which the ContextId is NULL. The base ROOT package is assumed to be implemented on the ROOT termination. Case (a) In this section we will illustrate how MGC retrieves the lists of all contexts in MG. The Audit Value command with ContextId '*' and termination identifier ROOT enables MGC to get all the valid contextID values. Step 1 MGC to MG: MEGACO/1 [207.176.47.89]: 27000 Transaction = 1234 { Context = * { AuditValue= ROOT {Audit { } } } } The MG after receiving the command from MGC constructs the response with all the contextID that is active in that MG. Step 2 Madhubabu, et al. [Page 146] Internet-Draft Megaco/H.248 Call flow examples July 2001 MG to MGC: MEGACO/1 [216.33.33.61]: 25000 Reply = 1234 { Context = 100 { AuditValue= TermA, TermB } Context = 200 { AuditValue= TermC, TermD } Context = 300 { AuditValue= TermE, TermF } } Case (b) This section illustrates the usage of ROOT termination identifier with NULL ContextID. This command is supposed to return the values of properties and statistics implemented on ROOT. The MGC generates the AuditValue message to MGC. Step 1 MGC to MG: MEGACO/1 [207.176.47.89]: 27000 Transaction = 1234 { Context = - { AuditValue= ROOT {Audit {Media, Statistics} } } } The MG responds with the values of properties that are defined on the ROOT termination. These properties include the Maximum number of contexts, Maximum number of terminations per context, normal MG execution time, normal MGC execution time and Provisional response timer value. There are no statistics that are defined on the ROOT termination. Hence the MG responds with the statistics token only. Step 2 MG to MGC: MEGACO/1 [216.33.33.61]: 25000 Reply = 1234 { Context = - { AuditValue= ROOT Media { TerminationState{ MaxNumberOfContexts = 100, MaxTerminationsPerContext = 2, NormalMGExecutionTime = 1000, NormalMGCExecutionTime = 1000, ProvisionalResponseTimerValue=1000, } Madhubabu, et al. [Page 147] Internet-Draft Megaco/H.248 Call flow examples July 2001 Audit {statistics} } } 4.1.2 Audit value on non-ROOT terminations This section illustrates the usage of AuditValue command on terminations other than ROOT. The Audit value command response constitutes all the active value of the descriptors that are requested by MGC. In this example we assume that the descriptors are already updated with commands from MGC. The MGC audit is done when the termination is in valid context. This is to include the statistics descriptor in the response from MG. The termination is assumed to be Ephemeral to use all the statistics defined in network package and RTP package. The second message illustrates the use of AuditValue to get the active descriptor values defined on physical terminations. Step 1 MGC to MG: MEGACO/1 [216.33.33.61]:27000 Transaction = 1234 { Context = 2 {AuditValue = EphA{ Audit{Media, DigitMap, Events, Signals, Packages, Statistics }} } } The MG responds with the media descriptor, packages and statistics. The Digit map, signal and events are not defined on this ephemeral termination hence only tokens are sent back in the response. Step 2 MG to MGC: MEGACO/1 [209.110.59.34]:25000 Reply = 1234 { Context = 2 { AuditValue = EphA { Media { TerminationState { ServiceState = InService, Buffer = OFF }, Stream = 1 { LocalControl { Mode = SendReceive, nt/jit=40 }, Local { v=0 c=IN IP4 209.110.59.33 m=audio 30000 RTP/AVP 0 a=ptime:30 }, Remote { Madhubabu, et al. [Page 148] Internet-Draft Megaco/H.248 Call flow examples July 2001 v=0 c=IN IP4 207.176.47.90 m=audio 40000 RTP/AVP 0 a=ptime:30 } } }, audit { Events, Signals, DigitMap}, Packages {nt-1, rtp-1}, Statistics { rtp/ps=1200, ; packets sent nt/os=62300, ; octets sent rtp/pr=700, ; packets received nt/or=45100, ; octets received rtp/pl=0.2, ; % packet loss rtp/jit=20, rtp/delay=40 } ; avg latency } } } The MGC in the following command generates audit value command for physical termination that is in a context. Here only DigitMap, event and signal descriptor are audited. Step 3 MGC to MG: MEGACO/1 [216.33.33.61]:27000 Transaction = 1235 { Context = 2 {AuditValue = TermA{ Audit{ DigitMap, Events, Signals }} } } The MG after receiving the command responds with the event, signal and digit map descriptors that are active on the termination. Step 4 MG to MGC: MEGACO/1 [209.110.59.34]:25000 Reply = 1235 { Context = 2 { Modify = TermA{ Events = 2223 { al/on, dd/ce {DigitMap=Dialplan0} }, Signals {cg/dt}, DigitMap= Dialplan0{ (0| 00|[1-7]xxx|8xxxxxxx|Fxxxxxxx|Exx|91xxxxxxxxxx|9011x.)} } } } Madhubabu, et al. [Page 149] Internet-Draft Megaco/H.248 Call flow examples July 2001 4.2 Audit Capability The Audit capability command from MGC retrieves the possible values of the descriptors requested. The first section 5.2.1 illustrates the Audit capability command on ROOT termination and 5.2.2 on terminations other than ROOT termination. 4.2.1 Audit Capability on ROOT termination The Audit Capability command on ROOT termination is used to determine the properties that are implemented on the ROOT termination. The response from MG includes the possible values of the properties. Step 1: MGC to MG: MEGACO/1 [216.33.33.61]:27000 Transaction = 1235 { Context = - {Audit Capability = ROOT{ Audit{ Media }} } } The properties that are defined on the ROOT in this example are the Max number of Contexts, maximum terminations per context, normal MG execution time, normal MGC execution time and provisional response timer value. Step 2 MG to MGC: MEGACO/1 [209.110.59.34]:25000 Reply = 1235 { Context = - { Modify = ROOT{ Media { TerminationState { MaxNumberOfContexts =10, MaxTerminationsPerContext =2, NormalMGExecutionTime =250, NormalMGCExecutionTime =250, ProvisionalResponseTimerValue = 200 }} } } } 4.2.2 Audit Capability on non-Root Terminations. This section illustrates the usage of Audit Capability command on a non-ROOT termination. The MGC in this example is generating Audit Capability for Events descriptor and signal descriptor. The MG should respond with the possible values of these descriptors. Step 1: Madhubabu, et al. [Page 150] Internet-Draft Megaco/H.248 Call flow examples July 2001 MGC to MG: MEGACO/1 [216.33.33.61]:27000 Transaction = 1234 { Context = - {AuditCapability = TermA{ Audit{ Events, Signals }} } } The response has all the possible values. In this example for simplicity event parameters are not included. The packages that are realized on TermA are analog line supervision package, DTMF detection package call progress tone generation package, tone generation package, and generic package. Step 2 MG to MGC: MEGACO/1 [209.110.59.34]:25000 Reply = 1234 { Context = - { Modify = TermA{ Events = 0 {g/cause, g/signalcompletion, tonedet/std, tonedet/etd, tonedet/ltd, dd/ce, al/on, al/of, al/fl}, Signals {cg/dt, cg/rt, cg/bt, cg/ct, cg/sit, cg/wt, cg/pt, cg/cw, cg/cr}, } } } 5. IVR using MEGACO The Interactive Voice Response (IVR) is assumed to be a gateway with only ephemeral terminations. The IVR is capable of playing announcements, detecting digits and reporting the same to the MGC. In this example we assume a IVR, which is controlled by a MGC. The IVR is assumed to play some announcement and detects the DTMF digits and reports the same to MGC. This section presents few call scenarios where a residential user is connected to IVR, Trunking gateway connected to IVR, call disconnection from residential and Trunking gateway to the IVR. 5.1 Connecting Residential gateway to IVR. _______________________________________________________ | | | USERA | RGW1 | MGC | IVR _____________|___________|___________|__________________ | | | | Madhubabu, et al. [Page 151] Internet-Draft Megaco/H.248 Call flow examples July 2001 | | | | | |<----------| | | |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 $ Local(Underspecified) | | | Remote SDP (Specified) | | | | | | |<----------| | | |Add Resp EphB Local Specified | |<----------| | | |Modify TermA SendRecv | | |Modify EphA Remote(Specified) SendRecv | |---------->| | | |Modify Resp| | |/----------------------------------\| | RTP MEDIA | |\----------------------------------/| |____________|___________|___________| Madhubabu, et al. [Page 152] Internet-Draft Megaco/H.248 Call flow examples July 2001 The MGC initially generates a Modify command to the Residential gateway to which UserA is connected. The Modify command lists a offhook event in the Events descriptor. The embedded signal descriptor lists the dial tone and the embedded event descriptor lists the Digit completion event of the DTMF package. 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 {cg/dt},Embed = 1112 {al/on, dd/ce {DigitMap=Dmap1}} } DigitMap= Dmap1{(2XXX)} } } } The residential gateway responds the Modify command. 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 RGW and constructs the Notify message to the MGC. The MG uses the same request id (1111) sent by the MGC in its initial command. The timestamp of the event detected 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 { Madhubabu, et al. [Page 153] Internet-Draft Megaco/H.248 Call flow examples July 2001 20010202T10000000:al/of}} } } MGC generates the Notify response and responds with further 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 users dials digits and that takes the call to be terminated on the IVR. The digits dialed by the user are reported to the MGC in the Notify command. Step 6 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 7 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 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 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 8 Madhubabu, et al. [Page 154] Internet-Draft Megaco/H.248 Call flow examples July 2001 MGC to MG1: MEGACO/1 [216.33.33.61]: 27000 Transaction = 1235 { 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 9 MG1 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 } } Madhubabu, et al. [Page 155] Internet-Draft Megaco/H.248 Call flow examples July 2001 } } } MGC generates a similar transaction towards the IVR media gateway. The ContextID specified in the action is $. The Add command is meant for 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 IVR. The new ephemeral termination that will be created will take these parameters as the remote SDP information. Step 10 MGC to IVR: MEGACO/1 [216.33.33.61]:27000 Transaction = 1236 { Context = $ { 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 } } } Events = 1113{ streamid = 1 dd/ce { dmap2 }} Digits = Dmap2 {2XXX} } } IVR after receiving the new transaction from MGC starts processing it. It creates a new context with contextID 2. The IVR creates a 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 IVR reserves IP address 207.176.47.90 and port number 40000. The IVR responds to MGC with the following transaction reply. Step 11 MG2 to MGC: Madhubabu, et al. [Page 156] Internet-Draft Megaco/H.248 Call flow examples July 2001 MEGACO/1 [207.176.47.89]: 26000 Reply = 1236 { Context = 2 { 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 after receiving the response forwards the remote SDP information in Modify command to the Residential gateway. The MGC generates message to the RGW to stop the ringback tone and changes the mode of the two terminations TermA and EphA to send receive. Step 12 MGC to MG1: 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 empty signal descriptor in the Modify command for termination TermA, 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. Madhubabu, et al. [Page 157] Internet-Draft Megaco/H.248 Call flow examples July 2001 Step 13 MG1 to MGC: MEGACO/1 [209.110.59.34]: 25000 Reply = 1237 { Context = 1 {Modify = TermA, Modify = EphA} } Now the RTP flow is established. The IVR plays an announcement. The User dials digits depending upon the announcement. The digits are detected on the RTP stream. 5.2 Disconnecting Residential User from IVR. This section illustrates the case of disconnecting a residential user from IVR. The assumption is that the RTP media is already established and now the MGC has to act upon the user actions. The MGC waits for the user to go onhook. Once the UserB goes onhook, MG2 reports the notification of the onhook event to the MGC. _______________________________________________________ | | | USERA | RGW1 | MGC | IVR _____________|___________|___________|__________________ | | | | |/----------------------------------\| | RTP MEDIA | |\----------------------------------/| |----------->| | | |UserA goes OnHook | | | |---------->| | | |Notify OnHook | | |<----------| | | |Notify Resp| | | |<----------| | | |Subtract TermA | | |Subtract EphA | | |---------->| | | |Subtract Resp TermA | | |Subtract Resp EphA Statistics | | |---------->| | | |Subtract EphB | | |<----------| | | |Subtract Resp EphB Statistics |____________|___________|___________| Step 1 MG2 to MGC: MEGACO/1 [207.176.47.89]: 26000 Madhubabu, et al. [Page 158] Internet-Draft Megaco/H.248 Call flow examples July 2001 Transaction = 3000 { Context = 1 { Notify = TermA {ObservedEvents =1234 { 20000202T10020000:al/on}} } } The MGC responds to the MG2 with the Notify response. Step 2 MGC to MG2: MEGACO/1 [216.33.33.61]: 27000 Reply = 3000 { Context = 1 {Notify = TermA} } The MGC generates transactions with two subtracts commands one for physical and other for ephemeral terminations. Step 3 MGC to MG1 MEGACO/1 [216.33.33.61]: 27000 Transaction = 1234 { 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 4 MG1 to MGC: MEGACO/1 [209.110.59.34]:25000 Reply = 1234 { 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 } } } } Madhubabu, et al. [Page 159] Internet-Draft Megaco/H.248 Call flow examples July 2001 The MGC generates similar command towards the IVR to subtract the ephemeral termination. Step 5 MGC to MG2: MEGACO/1 [216.33.33.61]: 27000 Transaction = 1235 { Context = 2 { Subtract = EphB {Audit{Statistics}} } } The IVR responds to the subtract commands generated by MGC. Step 6 MG2 to MGC: MEGACO/1 [209.110.59.34]:25000 Reply = 1235 { Context = 2 { 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 } } } } 5.3 Connecting Trunking Gateway to IVR. This section illustrates a call initiated from Trunking gateway towards IVR. It is assumption that the same MGC controls both the IVR and the Trunking gateway. ____________________________________________________ | | | SS7 Switch | TGW | MGC | IVR ____________|________ ___|___________|______________ | | | | | | | | |----------------------->| | | IAM | | Madhubabu, et al. [Page 160] Internet-Draft Megaco/H.248 Call flow examples July 2001 |<-----------------------| | | ACM | | | | | | | |<----------| | | | Add Phy | | | | Add $, Local SDP Info -underspecified | |---------->| | | |Add Resp Phy | | |Add Resp Local SDP (Specified) | | |---------->| | | |Add $ Local(Underspecified) | | | Remote SDP (Specified) | | | | | | |<----------| | | |Add Resp EphB Local Specified |<-----------------------| | | ANM | | | |<----------| | | |Modify Phy SendRecv | | |Modify EphA Remote(Specified) SendRecv | |---------->| | | |Modify Resp| | | |/---------------------\| | | RTP MEDIA | | |\---------------------/| The MGC receives IAM message from the SS7 switch. In this example we assume that the Signaling gateway and the Media Gateway are together in one physical box. The MGC responds with the ACM message. The MGC also generates add command to the Trunking gateway for addition of a circuit group of specific trunk and also another Add for ephemeral termination. For the ephemeral termination the MGC specifies few SDP parameters in the Local descriptor and many of the parameters are underspecified. This facilitates the MG to assign values by its own. Step 1 MGC to TGW MEGACO/1 [216.33.33.61]: 27000 Transaction = 1234 { Context = $ { Add = Trunk1/line1 {Media { LocalControl {Mode = SendRecv}}, }, Add = $ {Media { LocalControl { Mode = Receiveonly, }, Local { v=0 c=IN IP4 $ m=audio $ RTP/AVP 4 Madhubabu, et al. [Page 161] Internet-Draft Megaco/H.248 Call flow examples July 2001 } } } } } } 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 2 TGW to MGC: MEGACO/1 [207.176.47.89]: 26000 Reply = 1234 { 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 IVR. The command is for adding the ephemeral termination. The MGC requests creation of context and to the termination in the same. Step 3 MGC to IVR MEGACO/1 [216.33.33.61]: 27000 Transaction = 1235 { Context = $ { Add = $ {Media { LocalControl { Mode = Receiveonly, }, Local { v=0 c=IN IP4 $ m=audio $ RTP/AVP 4 Madhubabu, et al. [Page 162] Internet-Draft Megaco/H.248 Call flow examples July 2001 } Remote{ v=0 c=IN IP4 209.110.59.33 m=audio 30000 RTP/AVP 4 } } ; RTP profile for G723 is 4 } } } The IVR creates a context with ContextId 2. The ephemeral termination EPHB is created with the specified SDP information. The response from the IVR specifies the local SDP information. Step 4 RGW to MGC: MEGACO/1 [207.176.47.89]: 26000 Reply = 1235 { Context = 2 { 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 with the local SDP information conveys the same to the Trunking gateway as remote SDP information in the Modify command. Step 5 MGC to TGW MEGACO/1 [216.33.33.61]: 27000 Transaction = 1236 { Context = 1 { Modify = EphA {Media { LocalControl { Mode = SendRecv, }, Remote{ v=0 c=IN IP4 209.110.59.33 m=audio 30000 RTP/AVP 4 } Madhubabu, et al. [Page 163] Internet-Draft Megaco/H.248 Call flow examples July 2001 } } } } } The Trunking gateway responds to the Modify command. Step 6 TGW to MGC: MEGACO/1 [207.176.47.89]: 26000 Reply = 1236 { Context = 1 { Modify = EphB } } 5.4 Disconnecting Trunking gateway from IVR This section illustrates the disconnection of an IVR call from Trunking gateway. The Trunking gateway and the Signaling gateway are assumed to be present in the same physical box. The SS7 messages are received by the Signaling gateway and are forwarded to the MGC through the signaling gateway. _____________________________________________________ | | | SS7 Switch | TGW | MGC | IVR ____________|________ ___|___________|______________ | | | | | |/---------------------\| | | RTP MEDIA | | |\---------------------/| |----------------------->| | | REL | | | |<----------| | | |Subtract Phy | | |Subtract EphA | | |---------->| | | |Subtract Resp Phy | | |Subtract Resp EphA Statistics |<-----------------------| | | RLC | | | | |---------->| | | |Subtract EphB | | |<----------| | | |Subtract Resp EphB Statistics |____________|___________|___________| Madhubabu, et al. [Page 164] Internet-Draft Megaco/H.248 Call flow examples July 2001 It is assumed that the RTP stream is already established. The REL message is received by the MGC through the Signaling gateway. The MGC initiates the terminating of the IVR call. The MGC initially generates a transaction with two subtracts towards the Trunking gateway. One subtract for removing the physical termination and other to remove the ephemeral termination. Step 1 MGC to TGW: MEGACO/1 [216.33.33.61]: 27000 Transaction = 1234 Context = 2 { Subtract = Trunk2/line1{Audit{ }}, Subtract = EphB {Audit{Statistics}} } } The TGW responds to the subtract commands generated by MGC. Step 2 TGW to MGC: MEGACO/1 [209.110.59.34]:26000 Reply = 1234 Context = 2 { Subtract = Trunk2/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 } } } } The MGC generates similar command towards the IVR. Step 3 MGC to IVR: MEGACO/1 [216.33.33.61]: 27000 Transaction = 1235{ Context = 1 { Subtract = EphA {Audit{Statistics}} } } The IVR responds to the subtract commands generated by MGC. Step 4 Madhubabu, et al. [Page 165] Internet-Draft Megaco/H.248 Call flow examples July 2001 IVR to MGC: MEGACO/1 [209.110.59.34]:25000 Reply = 1235{ Context = 1 { 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 } } } } 6. Wildcard ContextID usage The protocol defines two types of wildcards. The CHOOSE wildcard and the ALL wildcard. The CHOOSE wildcard when used from MGC for the ContextId enables MG to create a new context The ALL wildcard ContextID enables MGC to multiple contexts using a single Action. If the MGC needs to perform an operation common to all Contexts it can use the Wildcard ContextID for this purpose. For example if MGC needs to subtract all terminations irrespective of context they are in, it can use ContextId '*' and termination ID '*'. This enables MG to perform the operation on all contexts that are active in the MG. The CHOOSE wildcard had already been in used in earlier call flows. This section shows a scenario where MGC uses * wildcard in ContextID. Step 1: MGC to MG: MEGACO/1 [216.33.33.61]: 27000 Transaction = 1234{ Context = * { Subtract = *{Audit{Statistics}} } } The MG now subtracts all terminations in any of the contexts. There will be as many actions as the number of Contexts that are active in the MG. In this example we assume two contexts Context1 and Context2 with one two terminations in each of the context. Step 2: MG to MGC: MEGACO/1 [209.110.59.34]:25000 Reply = 1234{ Context = 1{ Subtract = TermA {audit = { Statistics}} Madhubabu, et al. [Page 166] Internet-Draft Megaco/H.248 Call flow examples July 2001 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 } } } Context = 2 { Subtract = TermB { audit = {statistics }} 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 } } } } 7. Wildcard TerminationId Usage The wildcards when used for TerminationId can represent CHOOSE, ALL or partial choose. The partial choose enables MGC to specify part of TerminationId and leaving the remaining part of the TerminationId either * or $. The CHOOSE wildcard usage is illustrated in earlier examples. The Partial wildcard usage is illustrated in the Trunking gateway examples. The * wildcard example is treated in this section. In this example the MGC generates a command with wildcard ALL "*" TerminationId, to enable MG to processes the command for all the terminations in the Gateway. The Media gateway is assumed to be a residential gateway. The events descriptor requests MG to check for offhook and apply dial tone when the offhook event occurs. Step 1: MGC to RGW: MEGACO/1 [216.33.33.61]:27000 Transaction = 1234 { Context = - { Modify = *{ Media { LocalControl { Madhubabu, et al. [Page 167] Internet-Draft Megaco/H.248 Call flow examples July 2001 Mode = ReceiveOnly} } , Events = 1111 {al/of { signals { cg / dt } , embed event { al/on , dd/ce { dmap1} } } } DigitMap = dmap1 { 2XXX } } } } The MG responds with specifying each of the TerminationId for which the command has been processed. Step 2: MG1 to MGC: MEGACO/1 [209.110.59.34]:25000 Reply = 1234 { Context = - {Modify = TermA} {Modify = TermB} {Modify = TermC} {Modify = TermD} {Modify = TermE} {Modify = TermF} {Modify = TermG} {Modify = TermH} {Modify = TermI} {Modify = TermJ} } 8. Supplementary services support 8.1 Call Transfer _____________________________________________________________________ | | | MG1 | MGC | MG2 | MG3 ________________|_______________|________________|____________________ | | | | |<----------------|-------------->| | |Initial Modify | Initial Modify| | | |-------------------------------->| | | Initial Modify | |---------------->|<--------------| | |Modify Response | Modify Resp | | | |<--------------------------------| | | Modify Response | |---------------->| | | | Notify OffHook | | | Madhubabu, et al. [Page 168] Internet-Draft Megaco/H.248 Call flow examples July 2001 |<----------------| | | |Notify Response | | | |<----------------| | | |Modify ED:dd/ce{DigitMap=dmap1},al/on SD:cg/dt | <-----|---------------->| | | Dial | Modify Resp | | | Tone | | | | ------>| | | | Digits |---------------->| | | |Notify Digits | | | |<----------------| | | |Notify Response | | | |<----------------|-------------->| | |Modify ringback | Modify Ring | | <------|---------------->|<--------------| | ring | Modify Resp | Modify Resp | | back | |<--------------| | | |Notify OffHook | | |<----------------|-------------->| | | Add Phy |Notify Resp | | |Add Eph Local Unspecified | | |---------------->| | | |Add Phy Resp | | | |Add Eph Resp Local specified | | | |-------------->| | | |Add Phy | | | |Add Eph Local unspecified | | | Remote Specified | | |<--------------| | | | Add Phy Resp | | | | Add Eph Resp Local specified | |<----------------| | | | Modify Eph Remote Specified | | |---------------->| | | | Modify Resp | | | |/-------------------------------\| | | RTP MEDIA | | |\-------------------------------/| | | |<--------------| | | | Notify Flash | | | |-------------->| | |<----------------| Notify Resp | | | Modify RecvOnly | --->| | |---------------->| DialTone| | | Modify Resp |<--------------| | | | Notify Digits | | | |-------------->| | | | Notify Resp | | | |-------------------------------->| | | Modify Ring | | |<--------------------------------| Madhubabu, et al. [Page 169] Internet-Draft Megaco/H.248 Call flow examples July 2001 | | Modify Response | | |-------------->| | | | Modify Ringback tone | | |<--------------| | | | Modify Resp | | | |<--------------------------------| | | Notify OffHook | | |-------------------------------->| | | Notify Resp | | |-------------------------------->| | | Add Phy | | | Add Eph Local Unspecified | | | Remote Specified | | |<---------------------------------| | | Add Phy Resp | | | Add Eph Resp Local Specified | |-------------->| | | | Modify Eph Remote | | |<--------------| | | | Modify Resp | | | | |/---------------\| | | | RTP Media | | | |\---------------/| | |<--------------| | | | Notify OnHook | | | |-------------->| | | | Notify Resp | | | |-------------->| | | | Sub Phy | | | | Sub Eph | | | |<--------------| | | | Sub Phy Resp | | | | Sub Eph Resp Statistics | | |-------------------------------->| | | Modify Eph Remote | | |<--------------------------------| | | Modify Eph Resp | |<----------------| | | | Modify Eph Remote | | |---------------->| | | | Modify Resp | | | |/-------------------------------------------------\| | RTP MEDIA | |\-------------------------------------------------/| |---------------->| | | | Notify OnHook | | | |---------------->| | | | Notify Resp | | | | |-------------------------------->| | | Modify Phy busyTone | | |<--------------------------------| | | Modify Resp | Madhubabu, et al. [Page 170] Internet-Draft Megaco/H.248 Call flow examples July 2001 |<----------------| | | | Sub Phy Sub Eph | | | |---------------->| | | | Sub Phy Resp | | | | Sub Eph Resp Statistics | | | |<--------------------------------| | | Notify OnHook | | |-------------------------------->| | | Notify Resp | | |-------------------------------->| | | Sub Phy | | | Sub Eph | | |<--------------------------------| | | Sub Phy Resp | | | Sub Eph Resp Statistics | _______|_________________|_______________|_________________|____________ The call Transfer feature in PSTN allows a user to tranfer a call that he Has received to another phone. This feature should be supported by MGC so that it is capable of generating required messages towards MG. In this example we assume that the MGC is capable of supporting Call Transfer. UserB, the Called party press flash hook and initiates call towards UserC. After UserC responds to the call, UserB goes onhook to connect UserA with UserC. The MGC generates the Modify message towards all the three Residential gateways to check for off hook on the terminations. (A wildcard command may also be used in this scenario but for simplicity we consider only command to specific terminations). We are not considering the embedded signal and event descriptors here. 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 in this 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} } } } Madhubabu, et al. [Page 171] Internet-Draft Megaco/H.248 Call flow examples July 2001 MG, after receiving the command from MGC, accepts it and responds with the transaction reply. Here for only MG1 is shown to generate the response. In fact all the RGW generate the responses. 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 it constructs the Notify message to the MGC. The MG uses the same request id (1111) sent by the MGC in its initial command. The timestamp of the event detected is also passed as a 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 further 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 following command 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 patter 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: Madhubabu, et al. [Page 172] Internet-Draft Megaco/H.248 Call flow examples July 2001 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 validates the Modify command and responds to the MGC and then starts processing the descriptors listed. Step 6 MG1 to MGC: 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 will 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. Its assumed that the digits dialed by the user, match with the digit map pattern. 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 uses 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}}} } } Madhubabu, et al. [Page 173] Internet-Draft Megaco/H.248 Call flow examples July 2001 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 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 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 Madhubabu, et al. [Page 174] Internet-Draft Megaco/H.248 Call flow examples July 2001 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 { 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}, Madhubabu, et al. [Page 175] Internet-Draft Megaco/H.248 Call flow examples July 2001 }, 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 } } } } } 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 a 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 } } Madhubabu, et al. [Page 176] Internet-Draft Megaco/H.248 Call flow examples July 2001 } 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. 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 and flashhook events 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, al/fl { signals cg/dt, events dd/ce{dmap1}, al/on }}, Media { LocalControl { Mode = SendRecv, } } } Modify = EphB{ Media { LocalControl { Mode = SendRecv, } } } } Madhubabu, et al. [Page 177] Internet-Draft Megaco/H.248 Call flow examples July 2001 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 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, stops 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 Madhubabu, et al. [Page 178] Internet-Draft Megaco/H.248 Call flow examples July 2001 Reply = 1239 { Context = 1 {Modify = TermA, Modify = EphA} } The two users can exchange media, as the RTP streams are made bi-directional. The UserB now press flash to dial the UserC number. The UserB flash event is reported to MGC using the Notify message. Step 19 MG2 to MGC: MEGACO/1 [209.110.59.34]:29000 Transaction = 3001 { Context = 2 { Notify = TermB {ObservedEvents =1235 { 20040202T10000000:al/fl}} } } MGC generates the Notify response. Step 20 MGC to MG2: MEGACO/1 [216.33.33.61]: 27000 Reply = 3001 { Context = 2 {Notify = TermB} } The UserB gets the dial tone and starts dialing the digits. In this example the UserB dials the number 2804 of UserC. The dialed digits are reported to MGC using digit map completion event. The digits are reported using the Notify command. Step 21 MG2 to MGC: MEGACO/1 [209.110.59.34]: 27000 Transaction = 3002 { Context = 2 { Notify = TermB {Observed Events =1235 { 20040202T10010000:dd/ce{ds="2804",Meth=FM}}} } } MGC after receiving the Notify command responds back with the Notify response. Step 22 MGC to MG2: MEGACO/1 [216.33.33.61]: 27000 Reply = 3002 { Context = 2 {Notify = TermB} } The UserC is alerted with ring signal to indicate that a call is to be Madhubabu, et al. [Page 179] Internet-Draft Megaco/H.248 Call flow examples July 2001 received. The Add command for the physical termination TermC with signal descriptor allows the ring signal to be applied on the termination. The ephemeral termination is also requested to be created with under specified Local SDP information and fully specified Remote SDP information. Step 23: MGC to MG3: MEGACO/1 [216.33.33.61]: 27000 Transaction = 1240 { Context = $ { Add = TermC { Signals { al/ri } Events = 1111{ al/of embedded { al/on } } } 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 } } } } In this example the SDP local information connection fields IP address, the media field port numbers are unspecified. The MG3 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 MG3 creates a context with contextID 3. 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 EphC. MG3 responds with the allocated IP address 192.168.0.160 and port number 50000. Step 24 MG3 to MGC: MEGACO/1 [209.110.59.35]: 25000 Madhubabu, et al. [Page 180] Internet-Draft Megaco/H.248 Call flow examples July 2001 Reply = 1240 { Context = 3 { Add = TermC, Add=EphC{ Media { Local { v=0 c=IN IP4 192.168.0.160 m=audio 50000 RTP/AVP 4 a=recvonly } ; RTP profile for G.723 is 4 } } } } } The MGC generates ring back tone towards the UserB to indicate that altering signal has been sent to the called party UserC. Step 25 MGC to MG2: MEGACO/1 [216.33.33.61]: 27000 Transaction = 1241 { Context = 2 { Modify = TermB { Signals { cg/rt } } } } } The MG2 after receiving the Modify command applies the ring back tone specified in the signals descriptor. The Modify response is sent back to MGC. Step 26 MG2 to MGC: MEGACO/1 [209.110.59.34]: 25000 Reply = 1241 { Context = 2 { Modify= TermB, } } The UserC after receiving the ring signal goes offhook. The offhook event is reported to MGC in the Notify command. Step 27 MG3 to MGC: MEGACO/1 [209.110.59.35]:25000 Transaction = 4001 { Context = 3 { Notify = TermC {ObservedEvents =1111 { Madhubabu, et al. [Page 181] Internet-Draft Megaco/H.248 Call flow examples July 2001 20050202T10000000:al/of}} } } MGC generates the Notify response and responds with further messages towards the MG that generated the Notify command. Step 28 MGC to MG3: MEGACO/1 [216.33.33.61]: 27000 Reply = 4001 { Context = 3 {Notify = TermC} } The MGC now updates the UserC connected to the Residential gateway 3 with modify command to change the mode of the terminations set to sendrecv. Step 29: MGC to MG3: MEGACO/1 [216.33.33.61]: 27000 Transaction = 1242 { Context = 3 { Modify = TermC { Signals { } ; to turn off ringing Events = 1235 {al/on}, Media { LocalControl { Mode = SendRecv, } } } Modify = EphC{ Media { LocalControl { Mode = SendRecv, } } } } The Residential gateway responds with the Modify response command. Step 30 MG3 to MGC: MEGACO/1 [209.110.59.35]: 25000 Reply = 1242 { Context = 3 {Modify = TermC , Modify = EphC} } The MGC now updates the UserB connected to the Residential gateway 2 with the local SDP information of UserC as remote SDP information. The Modify command with the remote SDP information is sent to RGW2, for the ephemeral termination. Madhubabu, et al. [Page 182] Internet-Draft Megaco/H.248 Call flow examples July 2001 Step 31 MGC to MG2: MEGACO/1 [216.33.33.61]: 27000 Transaction = 1243 { Context = 2 { Modify = TermB { Media{ LocalControl{ mode = sendrecv }, Remote { v=0 c=IN IP4 192.168.0.160 m=audio 50000 RTP/AVP 4 } ; RTP profile for G.723 is 4 } } } } The RGW2 responds with the Modify response. Step 32 MG2 to MGC: MEGACO/1 [207.176.47.89]: 26000 Reply = 1243 { Context = 2 {Modify = TermB } } The RGW2 updates the remote SDP information and generates the Modify response towards MGC. The Media path is established between UserB and UserC. The two users can be in conversation. The intention of this call scenario is to illustrate the call that is initiated from UserA to UserC. Now the UserB is in connection with UserC and after UserB goes onhook the MGC modifies the remote SDP information of both UserA and UserB. This makes the remote SDP of UserA point to UserC and remote SDP information of UserA point to UserC. When the UserB goes onhook the event is reported to MGC in the Notify command. Step 33 MG2 to MGC: MEGACO/1 [207.176.47.89]:26000 Transaction = 3003 { Context = 2 { Notify = TermB {ObservedEvents =1235 { 20060202T10000000:al/on}} } } MGC generates the Notify response and responds with further messages towards the MG that generated the Notify command. Step 34 Madhubabu, et al. [Page 183] Internet-Draft Megaco/H.248 Call flow examples July 2001 MGC to MG2: MEGACO/1 [216.33.33.61]: 27000 Reply = 3003 { Context = 2 {Notify = TermB} } The MGC also subtracts the terminations TermB and EphB from context2. The context also gets destroyed after deletion of the last termination. The Subtract commands are generated in a single transaction. Step 35 MGC to MG2: MEGACO/1 [216.33.33.61]: 27000 Transaction = 1244 { Context = 2 { Subtract = TermB {Audit{ }}, Subtract = EphB {Audit{Statistics}} } } The MG2 responds to the subtract commands generated by MGC. Step 36 MG2 to MGC: MEGACO/1 [209.176.47.89]:26000 Reply = 1244 { 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 } } } } UserB is not in connection with UserA and UserC. The MGC now initiates the Modify command towards UserA and UserC. Step 37 MGC to MG1: MEGACO/1 [216.33.33.61]: 27000 Transaction = 1245 { Context = 1 { Modify = TermA { Media { LocalControl { Mode = sendrecv} Madhubabu, et al. [Page 184] Internet-Draft Megaco/H.248 Call flow examples July 2001 } } }, Modify = EphA { Media { LocalControl { Mode = sendrecv} Remote { v=0 c=IN IP4 192.168.0.160 m=audio 50000 RTP/AVP 4 } } ; RTP profile for G723 is 4 } } } } 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 38 MG1 to MGC: MEGACO/1 [209.110.59.34]: 25000 Reply = 1245 { Context = 1 {Modify = TermA, Modify = EphA} } Similar command is generated towards UserC connected to RGW3. Step 39 MGC to MG3: MEGACO/1 [216.33.33.61]: 27000 Transaction = 1246 { Context = 3 { Modify = TermC { Media { LocalControl { Mode = sendrecv} } } }, Modify = EphC { Media { LocalControl { Mode = sendrecv} Remote { v=0 c=IN IP4 209.110.59.33 m=audio 30000 RTP/AVP 4 } } ; RTP profile for G723 is 4 Madhubabu, et al. [Page 185] Internet-Draft Megaco/H.248 Call flow examples July 2001 } } } } The remote SDP information is updated for the ephemeral termination EphC. The mode is changed to send receive. MG3 responds to the MGC with the response for the Modify commands. Step 40 MG3 to MGC: MEGACO/1 [209.110.59.35]: 25000 Reply = 1246 { Context = 3 {Modify = TermC, Modify = EphC} } The users UserA and UserC can be in conversation as the modes are changed to sendrecv. The call is transferred completely from UserB to UserC. The call can be terminated by any of the users. 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 41 MG1 to MGC: MEGACO/1 [209.110.59.34]:25000 Transaction = 2003 { Context = 1 { Notify = TermA {ObservedEvents =1112 { 20010202T10030000:al/on} } } } The MGC responds to the MG1s Notify message. Step 42 MGC to RGW1: MEGACO/1 [216.33.33.61]:27000 Reply = 2003 { Context = 1 { Notify = TermA } } The MGC generates a Modify command towards the RGW3 for applying busy tone to the called subscriber. The mode of both terminations is set to receive only. Step 43 MGC to RGW3: MEGACO/1 [216.33.33.61]: 27000 Transaction = 1247 { Context = 3 { Modify = TermC { Madhubabu, et al. [Page 186] Internet-Draft Megaco/H.248 Call flow examples July 2001 Signals {cg/bt} Media { LocalControl { Mode = recvonly} } }, Modify = EphC { Media { LocalControl { Mode = recvonly} } } } } } The MG3 responds to this modify request. Step 44 MG3 to MGC: MEGACO/1 [209.110.59.35]: 25000 Reply = 1247 { Context = 3 { Modify= TermC, Modify = EphC} } The MGC generates a transaction with two subtracts commands one for physical and other for ephemeral terminations Step 45: MGC to MG1 MEGACO/1 [216.33.33.61]: 27000 Transaction = 1248 { 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 46 MG1 to MGC: MEGACO/1 [209.110.59.34]:25000 Reply = 1248 { Context = 1 { Subtract = TermA Subtract = EphA { Madhubabu, et al. [Page 187] Internet-Draft Megaco/H.248 Call flow examples July 2001 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 } } } } Step 47 MG3 to MGC: MEGACO/1 [209.110.59.35]:25000 Transaction = 4002 { Context = 3 { Notify = TermC {ObservedEvents =1235 { 20050202T10000000:al/on}} } } MGC generates the Notify response and responds with further messages towards the MG that generated the Notify command. Step 48 MGC to MG3: MEGACO/1 [216.33.33.61]: 27000 Reply = 4002 { Context = 3 {Notify = TermC} } The MGC generates Subtract command towards MG3. Step 49 MGC to MG3: MEGACO/1 [216.33.33.61]: 27000 Transaction = 1249 { Context = 3 { Subtract = TermC {Audit{ }}, Subtract = EphC {Audit{Statistics}} } } The MG3 responds to the subtract commands generated by MGC. Step 50 MG3 to MGC: MEGACO/1 [209.110.59.34]:28000 Reply = 1249 { Context = 3 { Madhubabu, et al. [Page 188] Internet-Draft Megaco/H.248 Call flow examples July 2001 Subtract = TermC Subtract = EphC { 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 all the three gateways, to enable the users to participate/initiate in further calls. 8.2 Call waiting The call waiting feature in Telephone networks enables a user to receive two calls simultaneously. The user can switch between the calls. In this example UserA calls UserB and when the conversation is taking place UserC calls UserB. The UserB hears a call waiting tone and switches to this new call using flash hook. UserC disconnects the call and the UserB continues his conversation with UserA. The MGC should support such features and UserB should subscribe for this feature. The figure above suggests that all the three MG's are controlled by the same MGC. Even though this many not true in real world this assumption holds good for illustration purposes. _____________________________________________________________________ | | | MG1 | MGC | MG2 | MG3 ________________|_______________|________________|____________________ | | | | |<----------------|-------------->| | |Initial Modify | Initial Modify| | | |-------------------------------->| | | Initial Modify | |---------------->|<--------------| | |Modify Response | Modify Resp | | | |<--------------------------------| | | Modify Response | |---------------->| | | | Notify OffHook | | | |<----------------| | | |Notify Response | | | |<----------------| | | |Modify ED:dd/ce{DmapName=dmap1},al/on SD:cg/dt | Madhubabu, et al. [Page 189] Internet-Draft Megaco/H.248 Call flow examples July 2001 <-----|---------------->| | | Dial | Modify Resp | | | Tone | | | | ------>| | | | Digits |---------------->| | | |Notify Digits | | | |<----------------| | | |Notify Response | | | |<----------------|-------------->| | |Modify ringback | Modify Ring | | <------|---------------->|<--------------| | ring | Modify Resp | Modify Resp | | back | |<--------------| | | |Notify OffHook | | |<----------------|-------------->| | | Add Phy |Notify Resp | | |Add Eph Local Unspecified | | |---------------->| | | |Add Phy Resp | | | |Add Eph Resp Local specified | | | |-------------->| | | |Add Phy | | | |Add Eph Local unspecified | | | Remote Specified | | |<--------------| | | | Add Phy Resp | | | | Add Eph Resp Local specified | |<----------------| | | | Modify Eph Remote Specified | | |---------------->| | | | Modify Resp | | | |/-------------------------------\| | | RTP MEDIA | | |\-------------------------------/| | | |<--------------------------------| | | Notify OffHook | | |<--------------------------------| | | Notify Resp | | |<--------------------------------| | | Notify Digits | | |-------------------------------->| | | Notify Response | | |-------------------------------->| | | Add Phy SD:cg/rt | | | Add Eph Local Unspecified| | | Remote Specified | | |<--------------------------------| | | Add Phy Resp | | | Add Eph Resp Local SPecified | |-------------->| | | |Modify SD:callwaiting tone | | |<--------------| | Madhubabu, et al. [Page 190] Internet-Draft Megaco/H.248 Call flow examples July 2001 | |Modify Resp | | | |<--------------| | | | Notify Flash | | |<----------------| | | |Modify Eph recvonly | | | |-------------->| | | | Notify Resp | | |---------------->| | | | Modify Resp |-------------->| | | | Modify Eph | | | |<--------------| | | | |/---------------\| | | | RTP MEDIA | | | |\---------------/| | |<--------------------------------| | | Notify OnHook | | |-------------------------------->| | | Notify Resp | | |-------------->| | | | Modify SD:cg/bt | | |<--------------| | | | Modify Resp | | | |<--------------| | | | Notify Flash | | | |-------------->| | | | Notify Resp | | |<----------------| | | | Modify Eph SendRecv | | |---------------->| | | | Modify Resp |-------------->| | | | Modify Eph | | | |<--------------| | | | Modify Resp | | |/-------------------------------\| | | RTP Media | | |\-------------------------------/| | |---------------->| | | | Notify OnHook | | | |<----------------| | | | Notify Resp | | | | |-------------->| | | | Modify Phy SD:cg/bt | | |<--------------| | | | Modify Resp | | |<----------------| | | | Sub TermA | | | | Sub EphA | | | |---------------->| | | | Sub TermA Resp | | | | Sub EphA Resp Statistics | | | |<--------------| | | | Notify OnHook | | Madhubabu, et al. [Page 191] Internet-Draft Megaco/H.248 Call flow examples July 2001 | |-------------->| | | | Notify Resp | | | |-------------->| | | | Sub TermB | | | | Sub EphB | | | |<--------------| | | | Sub TermB Resp| | | | Sub EphB Resp Statistics | _______|_________________|_______________|_________________| The MGC generates the Modify message towards all the three Residential gateways to check for off hook on the terminations. (A wildcard command may also be used in this scenario but for simplicity we consider only command to specific terminations). The MGC in NULL context generated 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. Here for only MG1 is shown to generate the response. In fact all the three RGW generates the response. Step 2 MG1 to MGC: MEGACO/1 [209.110.59.34]:25000 Reply = 1234 { Context = - {Modify = TermA} } Madhubabu, et al. [Page 192] Internet-Draft Megaco/H.248 Call flow examples July 2001 In this example User A goes off hook. This event is detected by the RGW1 and constructs the Notify message to the MGC. The MG uses the same request id (1111) sent by the MGC in its initial command. The timestamp of the event detected is also passed as a 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 further 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 following command 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 patter 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 validation responds the Modify command responds the Madhubabu, et al. [Page 193] Internet-Draft Megaco/H.248 Call flow examples July 2001 MGC and starts processing the descriptors listed. Step 6 MG1 to MGC: 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 is 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. The digits dialed by user match with the digitmap pattern. 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 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 Madhubabu, et al. [Page 194] Internet-Draft Megaco/H.248 Call flow examples July 2001 command is to create a new context and add the physical termination TermA into it. As the MGC is aware that the 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 as a result 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, Madhubabu, et al. [Page 195] Internet-Draft Megaco/H.248 Call flow examples July 2001 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 } } } } } 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}, }, 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 Madhubabu, et al. [Page 196] Internet-Draft Megaco/H.248 Call flow examples July 2001 } ; RTP profile for G.723 is 4 } } } } } 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 197] 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 a 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: Madhubabu, et al. [Page 198] Internet-Draft Megaco/H.248 Call flow examples July 2001 MEGACO/1 [216.33.33.61]: 27000 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, stops 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 media as the RTP streams are made bi-directional. Now UserC goes offhook to initiate a call towards UserB. The Residential gateway reports the Offhook event to MGC through the Notify message. Step 19 MG3 to MGC: MEGACO/1 [209.110.60.35]:25000 Transaction = 4000 { Context = - { Notify = TermC {ObservedEvents =1111 { 20040202T10000000:al/of}} } } Madhubabu, et al. [Page 199] Internet-Draft Megaco/H.248 Call flow examples July 2001 MGC generates the Notify response. Step 20 MGC to MG3: MEGACO/1 [216.33.33.61]: 27000 Reply = 4000 { Context = - {Notify = TermC} } The MGC in the following command 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 patter 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 21 MGC to MG3: MEGACO/1 [216.33.33.61]: 27000 Transaction = 1240 { Context = - { Modify = TermC { 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 22 MG3 to MGC: MEGACO/1 [209.110.60.35]: 25000 Reply = 1240 { Context = - {Modify = TermC} } The Media gateway applies dial tone and waits for the user to enter the digits. The UserC dials digits 2992. The same is reported to MGC through the Notify command. Step 23 MG3 to MGC: MEGACO/1 [209.110.60.35]: 25000 Madhubabu, et al. [Page 200] Internet-Draft Megaco/H.248 Call flow examples July 2001 Transaction = 4001 { Context = - { Notify = TermC {ObservedEvents =1112 { 20010202T10010000:dd/ce{ds="2992",Meth=FM}}} } } MGC after receiving the Notify command responds back with the Notify response. Step 24 MGC to MG3: MEGACO/1 [216.33.33.61]: 27000 Reply = 4001 { Context = - {Notify = TermC} } The MGC after analyzing the finds that another call is waiting for UserB. Before generating any further commands to UserB, MGC generates ADD command for physical and to create ephemeral termination towards UserC in RGW3. In the Remote SDP information MGC provides the Local SDP information of UserB. The Local SDP information of UserC is left underspecified to enable the RGW3 choose those values. Step 25 MGC to MG3: MEGACO/1 [216.33.33.61]:27000 Transaction = 1241 { Context = $ { Add = TermC { Media { LocalControl {Mode = Receiveonly} }, Signals {al/rt} Events=1234{al/of}, }, 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 G.723 is 4 } Madhubabu, et al. [Page 201] Internet-Draft Megaco/H.248 Call flow examples July 2001 } } } } MG3 after receiving the new transaction from MGC starts processing it. It creates a new context with contextID 3. It adds the physical termination TermB to that context and start processing the descriptor specified in the command. The signal descriptor lists "ringback" signal to be applied on the termination. The event descriptor lists the off hook event. The RGW3 creates a ephemeral termination with TerminationId EphC. 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 192.168.0.160 and port number 50000. The MG3 responds to MGC with the following transaction reply. Step 26 MG3 to MGC: MEGACO/1 [209.110.60.35]: 25000 Reply = 1241 { Context = 3 { Add = TermC, Add = EphC{ Media { Local { v=0 c=IN IP4 192.168.0.160 m=audio 50000 RTP/AVP 4 } } ; RTP profile for G723 is 4 } } } If generates a Modify command to the UserB with call waiting tone in the Signal Descriptor. Step 27 MGC to MG2: MEGACO/1 [216.33.33.61]:26000 Transaction = 1242 { Context = 2 { Modify = TermB { Media { LocalControl {Mode = SendRecv} }, Signals {cg/cw} Events=1234{al/fl, al/on}, } Madhubabu, et al. [Page 202] Internet-Draft Megaco/H.248 Call flow examples July 2001 } MG2 generates the response for the Modify command generated by MGC. Step 28 MG2 to MGC: MEGACO/1 [207.176.47.89]:26000 Reply = 1242 { Context = 2 { Modify= TermB } } } The UserB press flash button on the phone and the Residential gateway generates Notify command towards the MGC. Step 29 MG2 to MGC: MEGACO/1 [207.176.47.89]:26000 Transaction = 3001 { Context = 2 { Notify = TermB {ObservedEvents =1234 { 20040202T10000000:al/fl}} } } MGC generates the Notify response and responds with further messages towards the MG that generated the Notify command. Step 30 MGC to MG2: MEGACO/1 [216.33.33.61]: 27000 Reply = 3001 { Context = 2 {Notify = TermB} } The MGC now is aware that the UserB should be in voice conversation with UserC instead of UserA. The MGC now has to update the remote SDP information of UserC. Such that any the same local SDP information is used by UserB to continue calling UserC. The Local SDP information of UserC is provided as the remote SDP information to UserB. Since the Ephemeral termination is already in context, the Modify command is used by MGC to update the remote SDP information. Step 31 MGC to MG2: MEGACO/1 [216.33.33.61]: 27000 Transaction = 1243 { Context = 2 { Modify = TermB { Media { LocalControl { Mode = sendrecv} } Madhubabu, et al. [Page 203] Internet-Draft Megaco/H.248 Call flow examples July 2001 } Signals { } }, Modify = EphB { Media { LocalControl { Mode = sendrecv} Remote { v=0 c=IN IP4 192.168.0.160 m=audio 50000 RTP/AVP 4 } } ; RTP profile for G723 is 4 } } } } The empty signal descriptor in the Modify command for termination TermB, stop the Call waiting tone at the calling end. The remote SDP information is updated for the ephemeral termination EphB. The mode is changed to send receive. MG2 responds to the MGC with the response for the Modify commands. Step 32 MG2 to MGC: MEGACO/1 [207.176.47.89]: 26000 Reply = 1243 { Context = 2 {Modify = TermB, Modify = EphB} } The MGC now generates a Modify command to change the mode of the termination from receive only to send receive. At the same time MGC also sends an empty signal descriptor to stop the ring back tone that was earlier applied on termination TermC of UserC. Step 33 MGC to MG3: MEGACO/1 [216.33.33.61]: 27000 Transaction = 1244 { Context = 3 { Modify = TermC { Media { LocalControl { Mode = sendrecv} } } Signals { } }, Modify = EphC { Media { LocalControl { Mode = sendrecv} Madhubabu, et al. [Page 204] Internet-Draft Megaco/H.248 Call flow examples July 2001 } } } } The empty signal descriptor in the Modify command for termination TermC, stop the ringback tone at the calling end. The mode is changed to send receive. MG3 responds to the MGC with the response for the Modify commands. Step 34 MG3 to MGC: MEGACO/1 [209.110.60.34]: 25000 Reply = 1244 { Context = 3 {Modify = TermC, Modify = EphC} } Now the UserB and UserC are connected (through RTP Media). After the conversation in the example UserC goes onhook to termination its call with UserB. The Onhook event is reported to MGC though the Notify command. Step 35 MG3 to MGC: MEGACO/1 [209.110.60.34]:25000 Transaction = 4002 { Context = 3 { Notify = TermC {ObservedEvents =1234 { 20050202T10030000:al/on} } } } The MGC responds to the MG3s Notify message. Step 36 MGC to RGW3: MEGACO/1 [216.33.33.61]:27000 Reply = 4002 { Context = 3 { Notify = TermC } } The MGC generates Subtract command towards RGW3. Step 37 MGC to MG3: MEGACO/1 [216.33.33.61]: 27000 Transaction = 1245 { Context = 3 { Subtract = TermC {Audit{ }}, Subtract = EphC {Audit{Statistics}} } Madhubabu, et al. [Page 205] Internet-Draft Megaco/H.248 Call flow examples July 2001 } The MG3 responds to the subtract commands generated by MGC. Step 38 MG3 to MGC: MEGACO/1 [209.110.59.35]:25000 Reply = 1245 { Context = 3 { Subtract = TermC Subtract = EphC { 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 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 39 MGC to RGW2: MEGACO/1 [216.33.33.61]: 27000 Transaction = 1246 { Context = 2 { Modify = TermB { Signals {cg/bt} Events = 1235 { al/fl, al/on } Media { LocalControl { Mode = recvonly} } }, Modify = EphB { Media { LocalControl { Mode = recvonly} } } } } } The MG2 responds to this modify request. Madhubabu, et al. [Page 206] Internet-Draft Megaco/H.248 Call flow examples July 2001 Step 40 MG2 to MGC: MEGACO/1 [207.176.47.89]: 26000 Reply = 1246 { Context = 2 { Modify= TermB, Modify = EphB} } The User B press flash to continue its call with UserA. The flash event is reported to MGC in the Notify command. Step 41 MG2 to MGC: MEGACO/1 [207.176.47.89]:26000 Transaction = 3002 { Context = 2 { Notify = TermB {ObservedEvents =1234 { 20060202T10000000:al/fl}} } } MGC generates the Notify response and responds with further messages towards the MG that generated the Notify command. Step 42 MGC to MG2: MEGACO/1 [216.33.33.61]: 27000 Reply = 3002 { Context = 2 {Notify = TermB} } The MGC now generates a Modify command towards the UserB with the Local SDP information of UserA as Remote SDP information for the ephemeral termination EphB. This enables UserB to continue the call with UserA. Step 43 MGC to MG2: MEGACO/1 [216.33.33.61]: 27000 Transaction = 1247 { Context = 2 { Modify = TermB { Media { LocalControl { Mode = sendrecv} } } Signals { } }, Modify = EphB { Media { LocalControl { Madhubabu, et al. [Page 207] Internet-Draft Megaco/H.248 Call flow examples July 2001 Mode = sendrecv} Remote { v=0 c=IN IP4 209.110.59.33 m=audio 30000 RTP/AVP 4 } } ; RTP profile for G723 is 4 } } } } The empty signal descriptor in the Modify command for termination TermB, stop the busy tone at the calling end. The remote SDP information is updated for the ephemeral termination EphB. The mode is changed to send receive. MG2 responds to the MGC with the response for the Modify commands. Step 44 MG2 to MGC: MEGACO/1 [207.176.47.89]: 26000 Reply = 1247 { Context = 2 {Modify = TermB, Modify = EphB} } The UserB and UserA can continue their conversation. The call can be tear down either by UserA or UserB. In this example we assume that UserA terminates the Call. The UserA goes onhook and the users action is reported to MGC using the Notify command. Step 45 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 46 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 Madhubabu, et al. [Page 208] Internet-Draft Megaco/H.248 Call flow examples July 2001 receive only. Step 47 MGC to RGW2: MEGACO/1 [216.33.33.61]: 27000 Transaction = 1248 { 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 48 MG2 to MGC: MEGACO/1 [207.176.47.89]: 26000 Reply = 1248 { 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. Step 49: MGC to MG1 MEGACO/1 [216.33.33.61]: 27000 Transaction = 1249 { 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 209] Internet-Draft Megaco/H.248 Call flow examples July 2001 Step 50 MG1 to MGC: MEGACO/1 [209.110.59.34]:25000 Reply = 1249 { 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 UserB after hearing the busy tone goes onhook, the same is recognized by the Media gateway and generates Notify command towards the MGC. Step 51 MG2 to MGC: MEGACO/1 [207.176.47.89]:26000 Transaction = 3003 { Context = 2 { Notify = TermB {ObservedEvents =1234 { 20060202T10000000:al/on}} } } MGC generates the Notify response and responds with further messages towards the MG that generated the Notify command. Step 52 MGC to MG2: MEGACO/1 [216.33.33.61]: 27000 Reply = 3002 { Context = 2 {Notify = TermB} } The MGC then generates subtract commands towards RGW2. Step 53 MGC to MG2: MEGACO/1 [216.33.33.61]: 27000 Transaction = 1250 { Madhubabu, et al. [Page 210] Internet-Draft Megaco/H.248 Call flow examples July 2001 Context = 2 { Subtract = TermB {Audit{ }}, Subtract = EphB {Audit{Statistics}} } } The MG2 responds to the subtract commands generated by MGC. Step 54 MG2 to MGC: MEGACO/1 [207.176.47.89]: 26000 Reply = 1250 { 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 all the Media Gateways, to enable the users to participate/initiate in further calls. 9. Conferencing A Media Gateway optionally performs media conferencing. Media Gateways that support multipoint conferences might allow three or more terminations in a context. In this section we will illustrate conferencing between three users. These call flows makes use of the Topology descriptor. A topology descriptor is used to specify flow directions between terminations in a Context. _____________________________________________________________________ | | | MG1 | MGC | MG2 | MG3 ________________|_______________|________________|____________________ | | | | |<----------------|-------------->| | |Initial Modify | Initial Modify| | | |-------------------------------->| | | Initial Modify | |---------------->|<--------------| | Madhubabu, et al. [Page 211] Internet-Draft Megaco/H.248 Call flow examples July 2001 |Modify Response | Modify Resp | | | |<--------------------------------| | | Modify Response | |---------------->| | | | Notify OffHook | | | |<----------------| | | |Notify Response | | | |<----------------| | | |Modify ED:dd/cd,al/on SD:cg/dt | | <-----|---------------->| | | Dial | Modify Resp | | | Tone | | | | ------>| | | | Digits |---------------->| | | |Notify Digits | | | |<----------------| | | |Notify Response | | | |<----------------|-------------->| | |Modify ringback | Modify Ring | | <------|---------------->|<--------------| | ring | Modify Resp | Modify Resp | | back |<----------------|<--------------| | | Add Phy |Notify OffHook | | |Add $ Local Unspecified | | | |-------------->| | | |Notify Resp | | |---------------->| | | |Add Phy Resp | | | |Add EphAResp Local specified | | | |-------------->| | | |Add Phy | | | |Add $ Local unspecified Remote Specified | |-------------->| | | | Add Phy Resp Add EphB Resp Local Specified |<----------------| | | | Modify EphA Remote Specified | | |---------------->| | | | Modify Resp | | | |/-------------------------------\| | | RTP MEDIA | | |\-------------------------------/| | | |<--------------| | | | Notify Flash | | | |-------------->| | |<----------------| Notify Resp | | | Modify RecvOnly | ---------->| | |---------------->| DialTone | | | Modify Resp |<--------------| | | | Notify Digits | | | |-------------->| | | | Notify Resp | | | |-------------------------------->| Madhubabu, et al. [Page 212] Internet-Draft Megaco/H.248 Call flow examples July 2001 | | Modify Ring | | |<--------------------------------| | | Modify Response | | |-------------->| | | | Modify Ringback tone | | |<--------------| | | | Modify Resp | | | |<--------------------------------| | | Notify OffHook | | |-------------------------------->| | | Notify Resp | | |-------------------------------->| | | Add Phy | | | Add Eph Local Unspecified Remote Specified | |<--------------------------------| | | Add Phy Resp Add EphC Resp Local Specified | |-------------->| | | | Modify EphBRemote | | |<--------------| | | | Modify EphB Resp | | |/-------------------------------\| | | RTP Media | | |\-------------------------------/| | |<--------------| | | | Notify Flash | | | |-------------->| | | | Notify Resp | | |<----------------| | | | Add $ | | | |---------------->| | | | Add EphD Resp | | | | |-------------------------------->| | | Add $ | | |<--------------------------------| | | Add EphF Resp | |<----------------| | | | Mod EphD | | | |---------------->| | | | Mod EphD Resp | | | | |-------------->| | | | Add $ | | | |<--------------| | | | Add EphE Resp | | |<----------------| | | | Mod EphA | | | |---------------->| | | | Mod EphA Resp | | | | | / \ | | | | | | |/------------------------------- ---------------\| | RTP MEDIA | |\-------------------------------------------------/| Madhubabu, et al. [Page 213] Internet-Draft Megaco/H.248 Call flow examples July 2001 | |<--------------| | | | Notify OnHook | | | |-------------->| | | | Notify Resp | | |<----------------| | | | Sub EphA |-------------->| | |---------------->| Sub EphB,EphE | | | Sub EphA Resp |<--------------| | | statsitics | Sub EphB Resp Statistics | | | Sub EphE Resp Statistics | | |-------------------------------->| | | Sub EphC | | |<--------------------------------| | | Sub EphC Resp statistics | |/-------------------------------------------------\| | RTP MEDIA | |\-------------------------------------------------/| | |<--------------------------------| | | Notify OnHook | | |-------------------------------->| | | Notify Resp | |<----------------| | | | Modify Phy busyTone | | |---------------->| | | | Modify Resp | | | | |-------------------------------->| | | Sub Phy, Sub EphF | | |<--------------------------------| | | Sub Phy Resp | | | Sub EphF Resp Statistics| |---------------->| | | | Notify OnHook | | | |<----------------| | | | Notify Resp | | | |<----------------| | | | Sub Phy | | | | Sub EphD | | | |---------------->| | | | Sub Phy Resp | | | | Sub EphD Resp Statistics | | _______|_________________|_______________|_________________|____________ The conferencing feature in PSTN allows a user speak with multiple users at the same time. This feature Madhubabu, et al. [Page 214] Internet-Draft Megaco/H.248 Call flow examples July 2001 should be supported by MGC so that it is capable of generating required messages towards MG. In this example we assume that the MGC is capable of supporting Conferencing. UserB, the called party, initially receives a call from UserA. For adding UserC, UserB press flash hook and dials UserC number and after UserC answers the call goes flash hook again to connect UserA and UserC. Now UserA, User B and UserC are in the call. The MGC generates the Modify message towards all the three Residential gateways to check for off hook on the terminations. (A wildcard command may also be used in this scenario but for simplicity we consider only command to specific terminations). We are not considering the embedded signal and event descriptors here. 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. Here only MG1 is shown to generate the response. In fact all the RGW generates the response. 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 the Notify message to the MGC. The MG uses the same request id (1111) sent by the MGC in its initial command. The timestamp of the event detected is also passed as a parameter to the observed event. Madhubabu, et al. [Page 215] Internet-Draft Megaco/H.248 Call flow examples July 2001 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 further 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 following command 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 patter 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 validating the Modify command responds to the MGC and starts processing the descriptors listed. Step 6 MG1 to MGC: MEGACO/1 [209.110.59.34]: 25000 Reply = 1235 { Madhubabu, et al. [Page 216] Internet-Draft Megaco/H.248 Call flow examples July 2001 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 will be made 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 may contain 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.The digits dialed by the user match with the digit map pattern. 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 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 destination user UserB is free it instructs 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 Madhubabu, et al. [Page 217] Internet-Draft Megaco/H.248 Call flow examples July 2001 context that was created as a result 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 { Local { v=0 c=IN IP4 209.110.59.33 Madhubabu, et al. [Page 218] Internet-Draft Megaco/H.248 Call flow examples July 2001 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}, }, 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 219] 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 a 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. Step 14 MGC to MG2: MEGACO/1 [216.33.33.61]: 27000 Reply = 3000 { Madhubabu, et al. [Page 220] Internet-Draft Megaco/H.248 Call flow examples July 2001 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, flash hook and the dd/ce 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, al/fl { signals cg/dt, events dd/ce{dmap1}, 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 Transaction = 1239 { Context = 1 { Madhubabu, et al. [Page 221] Internet-Draft Megaco/H.248 Call flow examples July 2001 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, 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 media, as the RTP streams are made bi-directional. The figure below shows the terminations at both in both the Contexts. +------------------------------------------------------+ | RGW1 | | Context1 | | +---------------+ +---------------+ | | | | | | | | | | | | | | | Phy A | +-+ | Eph A | | <---->| |<--->|*|<---->| LocalA |<------> | | | +-+ | RemoteB | | | | | | | | | +---------------+ +---------------+ | | | Madhubabu, et al. [Page 222] Internet-Draft Megaco/H.248 Call flow examples July 2001 +------------------------------------------------------+ +------------------------------------------------------+ | RGW2 | | Context2 | | +---------------+ +---------------+ | | | | | | | | | | | | | | | Phy B | +-+ | Eph B | | <---->| |<--->|*|<---->| LocalB |<------> | | | +-+ | RemoteA | | | | | | | | | +---------------+ +---------------+ | | | +------------------------------------------------------+ The UserB now presses flash to dial the UserC number. The UserB flash event is reported to MGC using the Notify message. Step 19 MG2 to MGC: MEGACO/1 [209.110.59.34]:25000 Transaction = 3001 { Context = 2 { Notify = TermB {ObservedEvents =1235 { 20040202T10000000:al/fl}} } } MGC generates the Notify response. Step 20 MGC to MG2: MEGACO/1 [216.33.33.61]: 27000 Reply = 3001 { Context = 2 {Notify = TermB} } The UserB gets the dial tone and starts dialing the digits. In this example the UserB dials the number 2804 of UserC. The dialed digits are reported to MGC using digit map completion event. The digits are reported using the Notify command. Step 21 MG2 to MGC: MEGACO/1 [209.110.59.34]: 27000 Transaction = 3002 { Context = 2 { Notify = TermB {Observed Events =1235 { Madhubabu, et al. [Page 223] Internet-Draft Megaco/H.248 Call flow examples July 2001 20040202T10010000:dd/ce{ds="2804",Meth=FM}}} } } MGC after receiving the Notify command responds back with the Notify response. Step 22 MGC to MG2: MEGACO/1 [216.33.33.61]: 27000 Reply = 3002 { Context = 2 {Notify = TermB} } The UserC is alerted with ring signal to indicate that a call is to be received. The Add command for the physical termination TermC with signal descriptor allows the ring signal to be applied on the termination. The ephemeral termination is also requested to be created with under specified Local SDP information and fully specified Remote SDP information. Step 23: MGC to MG3: MEGACO/1 [216.33.33.61]: 27000 Transaction = 1240 { Context = $ { Add = TermC { Signals { al/ri } Events = 1111{ al/of embedded { al/on } } } 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 } } } } Madhubabu, et al. [Page 224] Internet-Draft Megaco/H.248 Call flow examples July 2001 In this example the SDP local information connection fields IP address, the media field port numbers 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 3. The physical termination TermC is added to context 3. 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 EphC. MG responds with the allocated IP address 192.168.0.160 and port number 50000. Step 24 MG1 to MGC: MEGACO/1 [209.110.59.34]: 25000 Reply = 1240 { Context = 3 { Add = TermC, Add=EphC{ Media { Local { v=0 c=IN IP4 192.168.0.160 m=audio 50000 RTP/AVP 4 a=recvonly } ; RTP profile for G.723 is 4 } } } } } The MGC generates ring back tone towards the UserB to indicate that altering signal has been sent to the called party UserC. Step 25 MGC to MG2: MEGACO/1 [216.33.33.61]: 27000 Transaction = 1241 { Context = 2 { Modify = TermB { Signals { cg/rt } } } } } The MG2 after receiving the Modify command applies the ring back tone specified in the signals descriptor. The Modify response is sent back to MGC. Step 26 MG2 to MGC: MEGACO/1 [207.176.47.89]: 26000 Madhubabu, et al. [Page 225] Internet-Draft Megaco/H.248 Call flow examples July 2001 Reply = 1241 { Context = 2 { Modify= TermB, } } The UserC after receiving the ring signal goes offhook. The offhook event is reported to MGC in the Notify command. Step 27 MG3 to MGC: MEGACO/1 [209.110.59.34]:28000 Transaction = 4001 { Context = 3 { Notify = TermC {ObservedEvents =1111 { 20050202T10000000:al/of}} } } MGC generates the Notify response and responds with further messages towards the MG that generated the Notify command. Step 28 MGC to MG3: MEGACO/1 [216.33.33.61]: 27000 Reply = 4001 { Context = 3 {Notify = TermC} } The MGC now updates the UserC connected to the Residential gateway 3 with modify command to change the mode of the terminations set to sendrecv. Step 29: MGC to MG3: MEGACO/1 [216.33.33.61]: 27000 Transaction = 1242 { Context = 3 { Modify = TermC { Signals { } ; to turn off ringing Events = 1235 {al/on}, Media { LocalControl { Mode = SendRecv, } } } Modify = EphC{ Media { LocalControl { Mode = SendRecv, } } Madhubabu, et al. [Page 226] Internet-Draft Megaco/H.248 Call flow examples July 2001 } } The Residential gateway responds with the Modify response command. Step 30 MG3 to MGC: MEGACO/1 [207.176.47.89]: 26000 Reply = 1242 { Context = 3 {Modify = TermC , Modify = EphC} } The MGC now updates the UserB connected to the Residential gateway 2 with the local SDP information of UserC as remote SDP information. The Modify command with the remote SDP information is sent to RGW2, for the ephemeral termination. Step 31 MGC to MG2: MEGACO/1 [216.33.33.61]: 27000 Transaction = 1243 { Context = 2 { Modify = TermB { Event = 1234 { al/fl, al/on }} Modify = EphB { Media{ LocalControl{ mode = sendrecv }, Remote { v=0 c=IN IP4 192.168.0.160 m=audio 50000 RTP/AVP 4 } ; RTP profile for G.723 is 4 } } } } The RGW2 responds with the Modify response. Step 32 MG2 to MGC: MEGACO/1 [207.176.47.89]: 28000 Reply = 1243 { Context = 2 {Modify = TermB, Modify = EphB } } The RGW2 updates the remote SDP information and generates the Modify response towards MGC. The Media path is established between UserB and UserC. The two users can be in conversation. The following figure shows the different context created and the terminations in these Contexts. The MGC then generates a Modify command towards MG1. The UserA mode is set to Receive only so that UserA generate RTP is not directed towards UserB. Madhubabu, et al. [Page 227] Internet-Draft Megaco/H.248 Call flow examples July 2001 Step 33 MGC to MG1: MEGACO/1 [216.33.33.61]: 27000 Transaction = 1244 { Context = 1 { Modify = TermA { Media { LocalControl { Mode = recvonly} } } Signals { } }, Modify = EphA { Media { LocalControl { Mode = recvonly} } } } Step 34 MG1 to MGC: MEGACO/1 [209.110.59.34]: 25000 Reply = 1244 { Context = 1 {Modify = TermA, Modify = EphA} } The Ephemeral termination EphB now has the Remote SDP information of UserC. This enables the media flow between UserB and UserC. UserA, even though is in valid context, doesn't generate any RTP media. The UserB after the establishment of RTP media with UserC goes flash hook to indicate the conference creation with UserA. The Notify event from RGW2 is reported to MGC using the Notify message. The UserB press flash button on the phone and the Residential gateway generates Notify command towards the MGC. Step 35 MG2 to MGC: MEGACO/1 [207.176.47.89]: 26000 Transaction = 3003 { Context = 2 { Notify = TermB {ObservedEvents =1234 { 20050202T10000000:al/fl}} } Madhubabu, et al. [Page 228] Internet-Draft Megaco/H.248 Call flow examples July 2001 } MGC generates the Notify. Step 36 MGC to MG2: MEGACO/1 [216.33.33.61]: 27000 Reply = 3003 { Context = 2 {Notify = TermB} } +------------------------------------------------------+ | RGW1 | | Context1 | | +---------------+ +---------------+ | | | | | | | | | | | | | | | Phy A | +-+ | Eph A | | <---->| |<--->|*|<---->| LocalA |<------ | | | +-+ | RemoteB | | | | | | | | | +---------------+ +---------------+ | | | +------------------------------------------------------+ +------------------------------------------------------+ | RGW2 | | Context2 | | +---------------+ +---------------+ | | | | | | | | | | | | | | | Phy B | +-+ | Eph B | | <---->| |<--->|*|<---->| LocalB |<------> | | | +-+ | RemoteC | | | | | | | | | +---------------+ +---------------+ | | | +------------------------------------------------------+ +------------------------------------------------------+ | RGW3 | | Context3 | | +---------------+ +---------------+ | | | | | | | | | | | | | | | Phy C | +-+ | Eph C | | <---->| |<--->|*|<---->| LocalC |<------> | | | +-+ | RemoteB | | Madhubabu, et al. [Page 229] Internet-Draft Megaco/H.248 Call flow examples July 2001 | | | | | | | +---------------+ +---------------+ | | | +------------------------------------------------------+ This call flow section illustrates the call between three users. Already UserB and UserC are connected. The UserA remote SDP information points to the UserB. Now the MGC has to add one more ephemeral termination in each of the contexts created at the three different user Gateways. In this scenario we show that EphA, EphB and EphC are initially created. EphA of UserA points to EphB of UserB, but since the mode of the termination is "recvonly", this can be modified as required. The EphB or UserB is virtually connected to EphC of UserC. The MGC for connecting UserA and UserC generates Add command towards RGW1 for creating an Ephemeral termination. After receiving the response of the Add command indicating the creation of EphD, the MGC passes the local SDP information of EphD in the Add command towards UserC for creation of another Ephemeral termination. RGW3 creates Ephemeral Termination EphF with remote information pointing towards EphD of UserA. The MGC now after receiving response from UserC for EphF creation "Modifies" the EphD with the remote SDP information of EphF. Thus connecting the UserA and UserC. The topology descriptor is used to illustrate the control of media flows between the terminations in the context. The MGC generates Add command towards UserB for creating an Ephemeral termination. The Local SDP information of EphA is passed as remote SDP information for this newly created termination. After receiving the response from UserB indicating the successful creation of EphE, the local SDP information of EphE is passed to UserA as remote SDP information for EphA in the "Modify" command. UserA's EphA is modified to point towards the EphE of UserB. Now all the Users have 3 termination in their contexts. Thus enabling them to participate in conference. The following paragraphs illustrates the different messages exchanged in detail, to illustrate the addition of new user in conference. The same can be extended to any number of users but for simplicity, only 3 users are considered. The MGC generates an add command towards MG1 for creation of another ephemeral termination so that the media information is directed towards UserC. The ephemeral termination is requested to be added in context 1. The topology descriptor that shows the directions of media flow inside the context is initially set to ISOLOATE so that there is no media immediately transferred between these termination within the context. Step 37 MGC to MG1: MEGACO/1 [216.33.33.61]: 27000 Transaction = 1244 { Context = 1 Topology TermA,EphA,isolate, TermA, $, isolate, EphA,$, isolate{ Madhubabu, et al. [Page 230] Internet-Draft Megaco/H.248 Call flow examples July 2001 Add = $ { Media { { LocalControl { Mode = ReceiveOnly, }, Local { v=0 c=IN IP4 $ m=audio $ RTP/AVP 4 } } } } } The Residential gateway now generates an ephemeral termination, with newly allocated resources for it. The IP address that is allocated is 192.168.0.155 and the port number is 35000. The response is sent back to MGC. Step 38 MG1 to MGC: MEGACO/1 [209.110.59.34]: 25000 Reply = 1244 { Context = 1 { Add=EphD{ Media { Local { v=0 c=IN IP4 192.168.0.155 m=audio 35000 RTP/AVP 4 a=recvonly } ; RTP profile for G.723 is 4 } } } } } The MGC after receiving this information generates another ADD command towards the Residential gateway 3, such that the UserA SDP information is indicated to UserC. Step 39 MGC to MG3: MEGACO/1 [216.33.33.61]: 27000 Transaction = 1245 { Context = 3 Topology TermC,EphC,bothway, TermC, $, bothway, EphC,$, bothway { Add = $ { Media { Madhubabu, et al. [Page 231] Internet-Draft Megaco/H.248 Call flow examples July 2001 { LocalControl { Mode = sendrecv, }, Local { v=0 c=IN IP4 $ m=audio $ RTP/AVP 4 } Remote { v=0 c=IN IP4 192.168.0.155 m=audio 35000 RTP/AVP 4 a=sendrecv } ; RTP profile for G.723 is 4 } } } } The Residential gateway now generates an ephemeral termination, with newly allocated resources for it. The IP address that is allocated is 192.168.0.100 and the port number is 55000. The response is sent back to MGC. Step 40 MG3 to MGC: MEGACO/1 [209.110.59.34]: 25000 Reply = 1245 { Context = 3 { Add=EphF{ Media { Local { v=0 c=IN IP4 192.168.0.100 m=audio 55000 RTP/AVP 4 a=recvonly } ; RTP profile for G.723 is 4 } } } } } The MGC after receiving the response from the UserC now indicates the same information towards the Residential gateway 1. Thus enabling media flow between the UserA and UserC. Step 41 MGC to MG1: MEGACO/1 [216.33.33.61]: 27000 Transaction = 1246 { Madhubabu, et al. [Page 232] Internet-Draft Megaco/H.248 Call flow examples July 2001 Context = 1 Topology TermA,EphA,isolate, TermA, EphD, bothway, EphA,EphD, isolate{ Modify = EphD { Media { { LocalControl { Mode = ReceiveOnly, }, Remote { v=0 c=IN IP4 192.168.0.100 m=audio 55000 RTP/AVP 4 } } } } } The Residential gateway now generates the Modify response to the MGC. Step 42 MG1 to MGC: MEGACO/1 [209.110.59.34]: 25000 Reply = 1246 { Context = 1 { Modify=EphD } +------------------------------------------------------+ | RGW1 +---------------+ | | Context1 | EPHA | | | +---------------+ | Local A | | | | |-------~------| Remote B |<-------- | | | +------| | | | | Phy A | | +---------------+ | <---->| | | +---------------+ | | | | | | EphD | | | | | +------| Local A |<------> | | |<------------>| Remote C | | | +---------------+ +---------------+ | | | +------------------------------------------------------+ +------------------------------------------------------+ | RGW2 | | Context2 | | +---------------+ +---------------+ | | | | | | | Madhubabu, et al. [Page 233] Internet-Draft Megaco/H.248 Call flow examples July 2001 | | | | | | | | Phy B | +-+ | Eph B | | <---->| |<--->|*|<---->| LocalB |<------> | | | +-+ | RemoteC | | | | | | | | | +---------------+ +---------------+ | | | +------------------------------------------------------+ +------------------------------------------------------+ | RGW3 +---------------+ | | Context2 | EPHC | | | +---------------+ | Local C | | | | |<------------>| Remote B |<-------> | | | +------>| | | | | Phy C | | +---------------+ | <---->| | | +---------------+ | | | | | | EphF | | | | | +------>| Local C |<------> | | |<------------>| Remote A | | | +---------------+ +---------------+ | | | +------------------------------------------------------+ The UserA and UserC are in conversation now. The UserB and UserC were already in conversation. Now the UserA and UserB need to be connected through RTP media. The MGC now generates ADD command towards the UserB of the Residential gateway 2. The Local information of UserA is indicated as the remote information of the newly created ephemeral termination. This ephemeral termination is requested to be added to the earlier context 2 itself. Step 43 MGC to MG2: MEGACO/1 [216.33.33.61]: 27000 Transaction = 1247 { Context = 2 Topology TermB,EphB,bothway, TermB, $, bothway, EphB,$, bothway { Add = $ { Media { { LocalControl { Mode = sendrecv, }, Local { v=0 c=IN IP4 $ m=audio $ RTP/AVP 4 } Remote { Madhubabu, et al. [Page 234] Internet-Draft Megaco/H.248 Call flow examples July 2001 v=0 c=IN IP4 209.110.59.33 m=audio 30000 RTP/AVP 4 a=sendrecv } ; RTP profile for G.723 is 4 } } } } The Residential gateway 2 now creates an ephemeral termination, with newly allocated resources for it. The IP address that is allocated is 192.168.0.110 and the port number is 45000. The response is sent back to MGC. Step 44 MG2 to MGC: MEGACO/1 [209.110.59.34]: 26000 Reply = 1247 { Context = 2 { Add=EphE{ Media { Local { v=0 c=IN IP4 192.168.0.110 m=audio 45000 RTP/AVP 4 a=recvonly } ; RTP profile for G.723 is 4 } } } } } The MGC after receiving the local SDP information update the Ephemeral termination EphA of the Residential Gateway 1. The Modify command is generated towards RGW1. Step 45 MGC to MG1: MEGACO/1 [216.33.33.61]: 27000 Transaction = 1248 { Context = 1 Topology TermA, EphA,bothway, TermA, EphD, bothway, EphA,EphD, bothway{ Modify = EphA { Media { { LocalControl { Mode = sendrecv, }, Remote { v=0 Madhubabu, et al. [Page 235] Internet-Draft Megaco/H.248 Call flow examples July 2001 c=IN IP4 192.168.0.110 m=audio 45000 RTP/AVP 4 } } } } } The Residential gateway now generates the Modify response to the MGC. Step 46 MG1 to MGC: MEGACO/1 [209.110.59.34]: 25000 Reply = 1248 { Context = 1 { Modify=EphA } All the terminations in all the contexts are made to sendrecv, thus all the three users are effectively in conference. The following figure shows the direction of media transfer between terminations inside each of the contexts. +------------------------------------------------------+ | RGW1 +---------------+ | | Context1 | EPHA | | | +---------------+ | Local A | | | | |<------------>| Remote B |<-------> | | | +------>| | | | | Phy A | | +---------------+ | <---->| | | +---------------+ | | | | | | EphD | | | | | +------>| Local A |<------> | | |<------------>| Remote C | | | +---------------+ +---------------+ | | | +------------------------------------------------------+ +------------------------------------------------------+ | RGW2 +---------------+ | | Context2 | EPHB | | | +---------------+ | Local B | | | | |<------------>| Remote C |<-------> | | | +----->| | | | | Phy B | | +---------------+ | <---->| | | +---------------+ | | | | | | EphD | | Madhubabu, et al. [Page 236] Internet-Draft Megaco/H.248 Call flow examples July 2001 | | | +------>| Local B |<------> | | |<------------>| Remote A | | | +---------------+ +---------------+ | | | +------------------------------------------------------+ +------------------------------------------------------+ | RGW3 +---------------+ | | Context3 | EPHC | | | +---------------+ | Local C | | | | |<------------>| Remote B |<-------> | | | +----->| | | | | Phy C | | +---------------+ | <---->| | | +---------------+ | | | | | | EphF | | | | | +----->| Local C |<------> | | |<------------>| Remote A | | | +---------------+ +---------------+ | | | +------------------------------------------------------+ In this example UserB goes onhook. The onhook event is reported to MGC using the Notify message. Step 47 MG2 to MGC: MEGACO/1 [207.176.47.89]:26000 Transaction = 3006 { Context = 2 { Notify = TermB {ObservedEvents =1234 { 20010202T10030000:al/on} } } } The MGC responds to the MG's notify message. Step 48 MGC to MG2: MEGACO/1 [216.33.33.61]:27000 Reply = 3006 { Context = 2 { Notify = TermB } } The MGC generates Subtract command towards the Residential Gateway 2 to delete all the terminations in the context 2. The statistics are requested only for the ephemeral terminations. Step 49 Madhubabu, et al. [Page 237] Internet-Draft Megaco/H.248 Call flow examples July 2001 MGC to MG2: MEGACO/1 [216.33.33.61]: 27000 Transaction = 1249 { Context = 2 { Subtract = TermB {Audit{ }}, Subtract = EphB {Audit{Statistics}} Subtract = EphE {Audit{Statistics}} } } The MG2 responds to the subtract commands generated by MGC. Step 50 MG2 to MGC: MEGACO/1 [209.110.59.34]:25000 Reply = 1249 { 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 } Subtract = EphE { Statistics { rtp/ps=1987, ; 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 Subtract command for the ephemeral termination EphA towards the RGW1. Step 51 MGC to MG2: MEGACO/1 [216.33.33.61]: 27000 Transaction = 1250 { Context = 1 { Subtract = EphA {Audit{Statistics}} } Madhubabu, et al. [Page 238] Internet-Draft Megaco/H.248 Call flow examples July 2001 } The MG1 responds to the subtract commands generated by MGC. Step 52 MG1 to MGC: MEGACO/1 [209.110.59.34]:25000 Reply = 1250 { Context = 2 { 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 UserC at RGW2, for subtracting the ephemeral termination EphC. Step 53 MGC to MG3: MEGACO/1 [216.33.33.61]: 27000 Transaction = 1251 { Context = 3 { Subtract = EphC {Audit{Statistics}} } } The MG3 responds to the subtract commands generated by MGC. Step 54 MG3 to MGC: MEGACO/1 [209.110.59.34]:25000 Reply = 1251 { Context = 3 { Subtract = EphC { 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 239] Internet-Draft Megaco/H.248 Call flow examples July 2001 } Media connection is present only between UserA and UserC as shown in figure below. +------------------------------------------------------+ | RGW1 | | Context1 | | +---------------+ +---------------+ | | | | | | | | | | | | | | | Phy A | | Eph D | | <---->| |<------------>| LocalA |<------> | | | | RemoteC | | | | | | | | | +---------------+ +---------------+ | | | +------------------------------------------------------+ +------------------------------------------------------+ | RGW3 | | Context3 | | +---------------+ +---------------+ | | | | | | | | | | | | | | | Phy C | | Eph F | | <---->| |<------------>| LocalC |<------> | | | | RemoteA | | | | | | | | | +---------------+ +---------------+ | | | +------------------------------------------------------+ After completing the conversation with UserA, UserC goes onhook. The same is indicated towards MGC in the Notify command. Step 55 MG3 to MGC: MEGACO/1 [209.110.59.34]:25000 Transaction = 4004 { Context = 3 { Notify = TermC {ObservedEvents =1111 { 20060202T10030000:al/on} } } } The MGC responds to the MG's notify message. Madhubabu, et al. [Page 240] Internet-Draft Megaco/H.248 Call flow examples July 2001 Step 56 MGC to MG3: MEGACO/1 [216.33.33.61]: 27000 Reply = 4004 { Context = 3 { Notify = TermC } } 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 57 MGC to MG1: MEGACO/1 [216.33.33.61]: 27000 Transaction = 1252 { Context = 1 { Modify = TermA { Signals {cg/bt} Media { LocalControl { Mode = recvonly} } }, Modify = EphD { Media { LocalControl { Mode = recvonly} } } } } } The MG1 responds to this modify request. Step 58 MG1 to MGC: MEGACO/1 [209.110.59.34]: 25000 Reply = 1252 { Context = 1 { Modify= TermA, Modify = EphD} } The MGC generates Subtract command RGW3. Step 59 MGC to MG3: Madhubabu, et al. [Page 241] Internet-Draft Megaco/H.248 Call flow examples July 2001 MEGACO/1 [216.33.33.61]: 27000 Transaction = 1254 { Context = 3 { Subtract = TermC {Audit{ }}, Subtract = EphF {Audit{Statistics}} } } The MG3 responds to the subtract commands generated by MGC. Step 60 MG3 to MGC: MEGACO/1 [209.110.59.34]:25000 Reply = 1254 { Context = 3 { Subtract = TermC Subtract = EphF { 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 UserA goes onhook after hearing the busy tone. The same is indicated to MGC using the Notify command. Step 61 MG1 to MGC: MEGACO/1 [209.110.59.34]: 25000 Transaction = 2002 { Context = 1 { Notify = TermA {ObservedEvents =1112 { 20010202T10010000:al/on} } } MGC after receiving the Notify command responds back with the Notify response. Step 62 MGC to MG1: MEGACO/1 [216.33.33.61]: 27000 Reply = 2002 { Context = 1 {Notify = TermA} Madhubabu, et al. [Page 242] Internet-Draft Megaco/H.248 Call flow examples July 2001 } Step 63: MGC to MG1 MEGACO/1 [216.33.33.61]: 27000 Transaction = 1253 { Context = 1 { Subtract = TermA {Audit{ }}, Subtract = EphD {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 64 MG1 to MGC: MEGACO/1 [209.110.59.34]:25000 Reply = 1253 { Context = 1 { Subtract = TermA Subtract = EphD { 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 } } } } 10.0 SDP for ATM 10.1 This section illustrates the usage of SDP for ATM. The draft "ATM SDP" [ref] is taken as reference. The two call establishment methods namely "Forward Bearer Connection Set-up model" and the "Backward Connection Set-up model" are considered. In the first method, the ATM connection establishment is initiated by the Originating Media Gateway whereas in the second method the Terminating Media Gateway initiates the ATM connection establishment. The SDP atrribute "eecid" is used in both the methods. The "eecid" is a means of correlating service-level connections with underlying ATM bearer connections. In this example we assume that the Originating Media Gateway is Madhubabu, et al. [Page 243] Internet-Draft Megaco/H.248 Call flow examples July 2001 controlled by MGC1 and terminating Gateway controlled by MGC2. The communication protocol between the two MGC's is out-of-scope of this draft. 10.1.1 Forward Bearer Connection Set-up Method In this call scenario we assume that the RGW1 and RGW2 are having ATM connectivity towards the PDN network. RGW1 is controlled by MGC1 and RGW2 is controlled by MGC2. The call is initiated by user connected to the RGW1. ______________________________________________________________________ | | | RGW1 | MGC1 | MGC2 | RGW2 __________________|_________________|_______________|________________ | | | | |<----------------| |-------------->| | Initial Modify | | Initial Modify| |---------------->| |<--------------| | Modify Resp | | Modify Resp | ------>| | | | OffHook|---------------->| | | | Notify OffHook | | | |<----------------| | | | Notify Resp | | | <-------| | | | Dial Tone| | | | ------->| | | | Digits |---------------->| | | | Notify Digits | | | |<----------------| | | | Notify Resp |--------------->| | | |MGC-MGC protocol| | | | Address info | | | | |-------------->| | | | Modify PhyB |-------> | | |<--------------|Ring | | | Modify Resp | | |<---------------| | | | MGC-MGC Ring indication | |<----------------| | | | Add PhyA SD:cg/rt | | <--------| Add $ Local Unspecified | | Ringback |---------------->| | | | Add PhyA Resp | | | | Add EphA Resp | | |<-------- | | |<--------------|OffHook | | | Notify OffHook| | |--------------->| | | | MGC-MGC SDPexchange | | | |-------------->| Madhubabu, et al. [Page 244] Internet-Draft Megaco/H.248 Call flow examples July 2001 | | | Add PhyB | | | | Add $ Local Unspecified | | | Remote Specified | | |<--------------| | | | Add PhyB Resp | | | | Add EphB Local Specified | |<---------------| | | | MGC-MGC SDPexchange | |<----------------| | | | Modify EphA Remote Specified | | |---------------->| | | | Modify EphA Resp| | | |/------------------------------------------------\| | MEDIA | |\------------------------------------------------/| ------->| | | | OnHook |---------------->| | | | Notify OnHook | | | |<----------------|--------------->| | | Notify Resp | MGC-MGC teardowninfo | | | |-------------->| | | | Modify PhyB cg/bt | | |<--------------| |<----------------| | | | Sub PhyA | | |<------- | Sub EphA | |<--------------| OnHook |---------------->| | Notify OnHook | | Sub PhyA Resp | |-------------->| | Sub EphA Reps Statistics |-------------->| | | | Sub PhyB | | | | Sub EphB | | | |<--------------| | | | Sub PhyB Resp | | | | Sub EphB Resp Statistics _________|_________________|________________|_______________|________ In Step 1 the MGC1 generates the Modify message towards the RGW1 and similarly MGC2 generates Modify message towards the RGW2 to check for off hook on the terminations. (A wildcard command may also be used in this scenario but for 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. 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. Madhubabu, et al. [Page 245] Internet-Draft Megaco/H.248 Call flow examples July 2001 Step 1 MGC1 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 MGC1 accepts it and responds with the transaction reply. Step 2 MG1 to MGC2: 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 MGC1. The MG uses the same request id (1111) sent by the MGC1 in its initial command. The timestamp of the detected event is also passed as parameter to the observed event. Step 3 MG1 to MGC1: MEGACO/1 [209.110.59.34]: 25000 Transaction = 2000 { Context = - { Notify = TermA {ObservedEvents =1111 { 20010202T10000000:al/of}} } MGC1 generates the Notify response and responds with more messages towards the MG that generated the Notify command. Step 4 MGC1 to MG1: MEGACO/1 [216.33.33.61]: 27000 Reply = 2000 { Context = - {Notify = TermA} } Madhubabu, et al. [Page 246] Internet-Draft Megaco/H.248 Call flow examples July 2001 The MGC1 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 MGC1 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 MGC1 and starts processing the descriptors listed. Step 6 MG1 to MGC1: MEGACO/1 [209.110.59.34]: 25000 Reply = 1235 { Context = - {Modify = TermA} } The descriptors are processed in the order that is specified by the MGC1. 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 Madhubabu, et al. [Page 247] Internet-Draft Megaco/H.248 Call flow examples July 2001 generated from MG1 to MGC1. The MG again used the same request identifier as specified by the MGC1. Step 7 MG1 to MGC1: MEGACO/1 [209.110.59.34]: 25000 Transaction = 2001 { Context = - { Notify = TermA {ObservedEvents =1112 { 20010202T10010000:dd/ce {ds="2992", Meth=FM}}} } } MGC1 after receiving the Notify command responds back with the Notify response. Step 8 MGC1 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 controlled by MGC2. The MGC1 communicates to MGC2 that there is a call initiation for UserB. The MGC1 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. 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. The MGC1 thus initiates service-level call establishment by sending the following control message to the RGW1. Step 9 MGC to MG1: MEGACO/1 [216.33.33.61]: 27000 Transaction = 1236 { Context = $ { Add = TermA { Signals {cg/rt} } Add = $ { Media { { LocalControl { Madhubabu, et al. [Page 248] Internet-Draft Megaco/H.248 Call flow examples July 2001 Mode = Receiveonly, }, Local { v=0 o=- 2873397497 0 ATM - - s=- c=ATM - - t=0 0 m=audio $ - - } } } } } In this example the connection field specifies only the connection type (ATM). The other fields are unspecified as they are not needed. The RGW1 in its response indicates its NSAP address. In this example the RGW1 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. Step 10 RGW1 to MGC1: MEGACO/1 [209.110.59.34]: 25000 Reply = 1236 { Context = 1 { Add = TermA, Add=EphA{ Media { Local { v=0 o=- 2873397496 0 ATM NSAP 47.0091.8100.0000.0060.3E64.FD01.0060.3E64.FD01.00 s=- c=ATM NSAP 47.0091.8100.0000.0060.3E64.FD01.0060.3E64.FD01.00 t=0 0 m=audio - AAL2/ITU 8 a=recvonly } } } } } } MGC2 after receiving the message from MGC1 generates an Add command towards the RGW2. The ContextID specified in the action is $. The first Madhubabu, et al. [Page 249] Internet-Draft Megaco/H.248 Call flow examples July 2001 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. MGC2 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 MGC2 to RGW2: MEGACO/1 [216.33.33.62]: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 = sendrecv, }, Local { v=0 o=- 2873397497 0 ATM - - s=- c=ATM - - t=0 0 m=audio $ - - }, Remote { v=0 o=- 2873397496 0 ATM NSAP 47.0091.8100.0000.0060.3E64.FD01.0060.3E64.FD01.00 s=- c=ATM NSAP 47.0091.8100.0000.0060.3E64.FD01.0060.3E64.FD01.00 t=0 0 m=audio - AAL2/ITU 8 } } } } } } RGW2 after receiving the new transaction from MGC2 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 Madhubabu, et al. [Page 250] Internet-Draft Megaco/H.248 Call flow examples July 2001 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 MGC2. The RGW2 allocates the necessary resources for processing the media descriptor for the ephemeral termination. The RGW2 responds to the MGC2 by providing an SDP descriptor with a locally assigned "eecid". The MG2 responds to MGC with the following transaction reply. Step 12 RGW2 to MGC2: MEGACO/1 [207.176.47.90]: 26000 Reply = 1237 { Context = 2 { Add = TermB, Add = EphB{ Media { Local { v=0 o=- 2873397714 0 ATM NSAP 47.0091.8100.0000.0040.2A74.EB03.0020.4421.2A04.00 s=- c=ATM NSAP 47.0091.8100.0000.0040.2A74.EB03.0020.4421.2A04.00 t=0 0 m=audio - AAL2/ITU 8 a=eecid:B3D58E32 } } } } } The MGC2 waits for the UserB to go offhook. Once the UserB goes offhook, RGW2 reports the notification of the offhook event to the MGC2. Step 13 RGW2 to MGC2: MEGACO/1 [207.176.47.90]: 26000 Transaction = 3000 { Context = 2 { Notify = TermB {ObservedEvents =1234 { 20000202T10020000:al/of}} } } The MGC2 responds to the RGW2 with the Notify response. Step 14 MGC2 to RGW2: MEGACO/1 [216.33.33.60]: 27000 Reply = 3000 { Madhubabu, et al. [Page 251] Internet-Draft Megaco/H.248 Call flow examples July 2001 Context = 2 {Notify = TermB} } The MGC2 generates a transaction towards RGW2 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.60]: 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 RGW2 to MGC2: MEGACO/1 [207.176.47.90]: 26000 Reply = 1238 { Context = 2 {Modify = TermB , Modify = EphB} } The MGC2 generates message to the MGC1 to indicate the "eecid" generated by the RGW2. The MGC1 generates a Modify message towards the RGW1 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 MGC1 to RGW1: MEGACO/1 [216.33.33.61]: 27000 Transaction = 1239 { Context = 1 { Madhubabu, et al. [Page 252] Internet-Draft Megaco/H.248 Call flow examples July 2001 Modify = TermA { Media { LocalControl { Mode = sendrecv} } } Signals { } }, Modify = EphA { Media { LocalControl { Mode = sendrecv} Local { v=0 o=- 2873397874 0 ATM - - s=- c=ATM - - t=0 0 m=audio $ - - a=bearerType:SVC on } Remote { v=0 o=- 2873397714 0 ATM NSAP 47.0091.8100.0000.0040.2A74.EB03.0020.4421.2A04.00 s=- c=ATM NSAP 47.0091.8100.0000.0040.2A74.EB03.0020.4421.2A04.00 t=0 0 m=audio $ AAL2/ITU 8 a=eecid:B3D58E32 } } } } } } 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 specifies the "eecid" to be used for the ephemeral termination EphA. The RGW1 using this "eecid" initiates the connection establishment. The Local SDP information with the media attribute "bearerType" indicates that an SVC is to be used and that the flag is on i.e. the SVC is to be set up by the terminating Media Gateway. The mode is changed to send receive. RGW1 responds to the MGC with the response for the Modify commands. Step 18 MG1 to MGC: MEGACO/1 [209.110.59.34]: 25000 Madhubabu, et al. [Page 253] Internet-Draft Megaco/H.248 Call flow examples July 2001 Reply = 1239 { Context = 1 {Modify = TermA, Modify = EphA} } The two users can exchange the media. 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 RGW1 to MGC1. Step 19 RGW1 to MGC1: MEGACO/1 [209.110.59.34]:25000 Transaction = 2002 { Context = 1 { Notify = TermA {ObservedEvents =1112 { 20010202T10030000:al/on} } } The MGC1 responds to the MG1s Notify message. Step 20 MGC1 to RGW1: MEGACO/1 [216.33.33.61]:27000 Reply = 2002 { Context = 1 { Notify = TermA } } The MGC2 after receiving the information from MGC1, 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 MGC2 to RGW2: MEGACO/1 [216.33.33.60]: 27000 Transaction = 1240 { Context = 2 { Modify = TermB { Signals {cg/bt} Media { LocalControl { Mode = recvonly} } }, Modify = EphB { Media { LocalControl { Mode = recvonly} } } Madhubabu, et al. [Page 254] Internet-Draft Megaco/H.248 Call flow examples July 2001 } } } The RGW2 responds to this modify request. Step 22 RGW2 to MGC2: MEGACO/1 [207.176.47.90]: 26000 Reply = 1240 { Context = 2 { Modify= TermB, Modify = EphB} } The MGC1 generates transactions with two subtracts commands one for physical and other for ephemeral terminations. Step 23: MGC1 to RGW1 MEGACO/1 [216.33.33.61]: 27000 Transaction = 1241 { Context = 1 { Subtract = TermA {Audit{ }}, Subtract = EphA {Audit{Statistics}} } } The RGW1 subtracts the two terminations from the context. The context itself is deleted with the subtract of the last termination from it. The RGW1 responds to this transaction from MGC1 with statistics on ephemeral termination. Step 24 RGW1 to MGC1: 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 } } } } Madhubabu, et al. [Page 255] Internet-Draft Megaco/H.248 Call flow examples July 2001 The User B after going onhook, the RGW2 generates Notify command towards the MGC2. Step 25 RGW2 to MGC2: MEGACO/1 [207.176.47.90]: 26000 Transaction = 3001 { Context = 2 { Notify = TermB {ObservedEvents =1235 { 20000202T10070000:al/on}} } } The MGC2 responds to the RGW2 with the Notify response. Step 26 MGC2 to RGW2: MEGACO/1 [216.33.33.61]: 27000 Reply = 3001 { Context = 2 {Notify = TermB} } The MGC2 generates subtract command towards RGW2 for removing TermB from valid context. Step 26 MGC2 to RGW2: MEGACO/1 [216.33.33.61]: 27000 Transaction = 1242 { Context = 2 { Subtract = TermB {Audit{ }}, Subtract = EphB {Audit{Statistics}} } } The RGW2 responds to the subtract commands generated by MGC2. Step 27 RGW2 to MGC2: 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 } Madhubabu, et al. [Page 256] Internet-Draft Megaco/H.248 Call flow examples July 2001 } } } The two users UserA and UserB are ready for initiating/receiving further calls. 10.1.2 Backward Bearer Connection Set-up Method In this call scenario we assume that the RGW1 and RGW2 are having ATM connectivity towards the PDN network. RGW1 is controlled by MGC1 and RGW2 is controlled by MGC2. The call is initiated by user connected to the RGW1. ______________________________________________________________________ | | | RGW1 | MGC1 | MGC2 | RGW2 __________________|_________________|_______________|________________ | | | | |<----------------| |-------------->| | Initial Modify | | Initial Modify| |---------------->| |<--------------| | Modify Resp | | Modify Resp | ------>| | | | OffHook|---------------->| | | | Notify OffHook | | | |<----------------| | | | Notify Resp | | | <-------| | | | Dial Tone| | | | ------->| | | | Digits |---------------->| | | | Notify Digits | | | |<----------------| | | | Notify Resp |--------------->| | | |MGC-MGC protocol| | | | Address info | | | | |-------------->| | | | Modify PhyB |-------> | | |<--------------|Ring | | | Modify Resp | | |<---------------| | | | MGC-MGC Ring indication | |<----------------| | | | Add PhyA SD:cg/rt | | <--------| Add $ Local Unspecified | | Ringback |---------------->| | | | Add PhyA Resp | | | | Add EphA Resp | | |<-------- | | |<--------------|OffHook | | | Notify OffHook| Madhubabu, et al. [Page 257] Internet-Draft Megaco/H.248 Call flow examples July 2001 | |--------------->| | | | MGC-MGC SDPexchange | | | |-------------->| | | | Add PhyB | | | | Add $ Local Unspecified | | | Remote Specified | | |<--------------| | | | Add PhyB Resp | | | | Add EphB Local Specified | |<---------------| | | | MGC-MGC | | |<----------------| | | | Modify EphA sendrecv | | |---------------->| | | | Modify EphA Resp| | | |/------------------------------------------------\| | MEDIA | |\------------------------------------------------/| ------->| | | | OnHook |---------------->| | | | Notify OnHook | | | |<----------------|--------------->| | | Notify Resp | MGC-MGC teardowninfo | | | |-------------->| | | | Modify PhyB cg/bt | | |<--------------| |<----------------| | | | Sub PhyA | | |<------- | Sub EphA | |<--------------| OnHook |---------------->| | Notify OnHook | | Sub PhyA Resp | |-------------->| | Sub EphA Reps Statistics |-------------->| | | | Sub PhyB | | | | Sub EphB | | | |<--------------| | | | Sub PhyB Resp | | | | Sub EphB Resp Statistics _________|_________________|________________|_______________|________ In Step 1 the MGC1 generates the Modify message towards the RGW1 and similarly MGC2 generates Modify message towards the RGW2 to check for off hook on the terminations. (A wildcard command may also be used in this scenario but for 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. 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 Madhubabu, et al. [Page 258] Internet-Draft Megaco/H.248 Call flow examples July 2001 descriptor. Step 1 MGC1 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 MGC1 accepts it and responds with the transaction reply. Step 2 MG1 to MGC2: 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 MGC1. The MG uses the same request id (1111) sent by the MGC1 in its initial command. The timestamp of the detected event is also passed as parameter to the observed event. Step 3 MG1 to MGC1: MEGACO/1 [209.110.59.34]: 25000 Transaction = 2000 { Context = - { Notify = TermA {ObservedEvents =1111 { 20010202T10000000:al/of}} } MGC1 generates the Notify response and responds with more messages towards the MG that generated the Notify command. Step 4 MGC1 to MG1: MEGACO/1 [216.33.33.61]: 27000 Reply = 2000 { Context = - {Notify = TermA} Madhubabu, et al. [Page 259] Internet-Draft Megaco/H.248 Call flow examples July 2001 } The MGC1 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 MGC1 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 MGC1 and starts processing the descriptors listed. Step 6 MG1 to MGC1: MEGACO/1 [209.110.59.34]: 25000 Reply = 1235 { Context = - {Modify = TermA} } The descriptors are processed in the order that is specified by the MGC1. 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 Madhubabu, et al. [Page 260] Internet-Draft Megaco/H.248 Call flow examples July 2001 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 MGC1. The MG again used the same request identifier as specified by the MGC1. Step 7 MG1 to MGC1: MEGACO/1 [209.110.59.34]: 25000 Transaction = 2001 { Context = - { Notify = TermA {ObservedEvents =1112 { 20010202T10010000:dd/ce {ds="2992", Meth=FM}}} } } MGC1 after receiving the Notify command responds back with the Notify response. Step 8 MGC1 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 controlled by MGC2. The MGC1 communicates to MGC2 that there is a call initiation for UserB. The MGC1 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. 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. The MGC1 thus initiates service-level call establishment by sending the following control message to the RGW1. Step 9 MGC to MG1: MEGACO/1 [216.33.33.61]: 27000 Transaction = 1236 { Context = $ { Add = TermA { Signals {cg/rt} } Add = $ { Media { Madhubabu, et al. [Page 261] Internet-Draft Megaco/H.248 Call flow examples July 2001 { LocalControl { Mode = Receiveonly, }, Local { v=0 o=- 2873397497 0 ATM - - s=- c=ATM - - t=0 0 m=audio $ - - } } } } } In this example the connection field specifies only the connection type (ATM). The other fields are unspecified as they are not needed. The RGW1 in its response indicates its NSAP address. In this example the RGW1 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. The RGW1 in its Local SDP information specifies the "eecid" that needs to be used by the other RGW for establishing an ATM SVC between RGW1 and RGW2. Step 10 RGW1 to MGC1: MEGACO/1 [209.110.59.34]: 25000 Reply = 1236 { Context = 1 { Add = TermA, Add=EphA{ Media { Local { v=0 o=- 2873397496 0 ATM NSAP 47.0091.8100.0000.0060.3E64.FD01.0060.3E64.FD01.00 s=- c=ATM NSAP 47.0091.8100.0000.0060.3E64.FD01.0060.3E64.FD01.00 t=0 0 m=audio - AAL2/ITU 8 a=eecid:b3d58e32 } } } } Madhubabu, et al. [Page 262] Internet-Draft Megaco/H.248 Call flow examples July 2001 } } MGC2 after receving the SDP information from MGC1 generates an Add command 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. MGC2 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 MGC2 to RGW2: MEGACO/1 [216.33.33.62]: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 = sendrecv, }, Local { v=0 o=- 2873397497 0 ATM - - s=- c=ATM - - t=0 0 m=audio $ - - a= bearerType:SVC on }, Remote { v=0 o=- 2873397496 0 ATM NSAP 47.0091.8100.0000.0060.3E64.FD01.0060.3E64.FD01.00 s=- c=ATM NSAP 47.0091.8100.0000.0060.3E64.FD01.0060.3E64.FD01.00 t=0 0 m=audio - AAL2/ITU 8 a=eecid:b3d58e32 } } } Madhubabu, et al. [Page 263] Internet-Draft Megaco/H.248 Call flow examples July 2001 } } } RGW2 after receiving the new transaction from MGC2 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 MGC2. The RGW2 allocates the necessary resources for processing the media descriptor for the ephemeral termination. The RGW2 creates an SVC connection using the "eecid" specified in the remote descrptor. The RGW2 as indicated by the MGC that an SVC is to be used as the flag is on in the Local SDP information. The RGW2 responds to MGC2 with the following transaction reply. Step 12 RGW2 to MGC2: MEGACO/1 [207.176.47.90]: 26000 Reply = 1237 { Context = 2 { Add = TermB, Add = EphB{ Media { Local { v=0 o=- 2873397714 0 ATM NSAP 47.0091.8100.0000.0040.2A74.EB03.0020.4421.2A04.00 s=- c=ATM NSAP 47.0091.8100.0000.0040.2A74.EB03.0020.4421.2A04.00 t=0 0 m=audio - AAL2/ITU 8 } } } } } The MGC2 waits for the UserB to go offhook. Once the UserB goes offhook, RGW2 reports the notification of the offhook event to the MGC2. Step 13 RGW2 to MGC2: MEGACO/1 [207.176.47.90]: 26000 Transaction = 3000 { Context = 2 { Notify = TermB {ObservedEvents =1234 { 20000202T10020000:al/of}} Madhubabu, et al. [Page 264] Internet-Draft Megaco/H.248 Call flow examples July 2001 } } The MGC2 responds to the RGW2 with the Notify response. Step 14 MGC2 to RGW2: MEGACO/1 [216.33.33.60]: 27000 Reply = 3000 { Context = 2 {Notify = TermB} } The MGC2 generates a transaction towards RGW2 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.60]: 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 RGW2 to MGC2: MEGACO/1 [207.176.47.90]: 26000 Reply = 1238 { Context = 2 {Modify = TermB , Modify = EphB} } The MGC2 generates message to the MGC1 to indicate using the "eecid" sent earlier the SVC is created by the RGW2. The MGC1 generates a Modify message towards the RGW1 to stop the ringback tone and to report Madhubabu, et al. [Page 265] Internet-Draft Megaco/H.248 Call flow examples July 2001 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 MGC1 to RGW1: MEGACO/1 [216.33.33.61]: 27000 Transaction = 1239 { Context = 1 { Modify = TermA { Media { LocalControl { Mode = sendrecv} } } Signals { } }, Modify = EphA { Media { LocalControl { Mode = sendrecv} } } } } } The empty signal descriptor in the Modify command for termination TermA, specifies to stop the ringback tone at the calling end. The mode is changed to send receive. RGW1 responds to the MGC1 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 media. 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 RGW1 to MGC1. Step 19 RGW1 to MGC1: MEGACO/1 [209.110.59.34]:25000 Transaction = 2002 { Context = 1 { Notify = TermA {ObservedEvents =1112 { 20010202T10030000:al/on} } } Madhubabu, et al. [Page 266] Internet-Draft Megaco/H.248 Call flow examples July 2001 The MGC1 responds to the MG1s Notify message. Step 20 MGC1 to RGW1: MEGACO/1 [216.33.33.61]:27000 Reply = 2002 { Context = 1 { Notify = TermA } } The MGC2 after receiving the information from MGC1, 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 MGC2 to RGW2: MEGACO/1 [216.33.33.60]: 27000 Transaction = 1240 { Context = 2 { Modify = TermB { Signals {cg/bt} Media { LocalControl { Mode = recvonly} } }, Modify = EphB { Media { LocalControl { Mode = recvonly} } } } } } The RGW2 responds to this modify request. Step 22 RGW2 to MGC2: MEGACO/1 [207.176.47.90]: 26000 Reply = 1240 { Context = 2 { Modify= TermB, Modify = EphB} } The MGC1 generates transactions with two subtracts commands one for physical and other for ephemeral terminations. Step 23: Madhubabu, et al. [Page 267] Internet-Draft Megaco/H.248 Call flow examples July 2001 MGC1 to RGW1 MEGACO/1 [216.33.33.61]: 27000 Transaction = 1241 { Context = 1 { Subtract = TermA {Audit{ }}, Subtract = EphA {Audit{Statistics}} } } The RGW1 subtracts the two terminations from the context. The context itself is deleted with the subtract of the last termination from it. The RGW1 responds to this transaction from MGC1 with statistics on ephemeral termination. Step 24 RGW1 to MGC1: 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 MGC2. Step 25 RGW2 to MGC2: MEGACO/1 [207.176.47.90]: 26000 Transaction = 3001 { Context = 2 { Notify = TermB {ObservedEvents =1235 { 20000202T10070000:al/on}} } } The MGC2 responds to the RGW2 with the Notify response. Step 26 MGC2 to RGW2: MEGACO/1 [216.33.33.60]: 27000 Reply = 3001 { Madhubabu, et al. [Page 268] Internet-Draft Megaco/H.248 Call flow examples July 2001 Context = 2 {Notify = TermB} } The MGC2 generates subtract command towards RGW2 for removing TermB from valid context. Step 26 MGC2 to RGW2: MEGACO/1 [216.33.33.61]: 27000 Transaction = 1242 { Context = 2 { Subtract = TermB {Audit{ }}, Subtract = EphB {Audit{Statistics}} } } The RGW2 responds to the subtract commands generated by MGC2. Step 27 RGW2 to MGC2: 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 two users UserA and UserB are ready for initiating/receiving further calls. Acknowledgements: The authors wish to thank several colleagues at Kenetec and in the industry who have contributed towards the development of these call flow document and who have reviewed and sent valuable technical comments. Special thanks to Mathi Packiam for providing timely comments. Basic call flows have been provided by the authors of the MGCP call flow document. Technical ideas/comments have been provided by Thillaivilagam Anand, Sarika Gupta, Mehul Shah, Peter Michielsen, Terry L Anderson and Sasitharan R. Madhubabu, et al. [Page 269] Internet-Draft Megaco/H.248 Call flow examples July 2001 AUTHOR'S ADDRESS Madhubabu Brahmanapally Kenetec Inc 550 Spring Street Naugatuck, CT 06770 Tel 203/723-4242 Extn-378 Fax 203/723-4187 Email: madhubabu@kenetec.com Prerepa Viswanadham Kenetec Inc 550 Spring Street Naugatuck, CT 06770 Tel 203/723-4242 Extn-373 Fax 203/723-4187 Email: dham.prerepa@kenetec.com Krishna Gundamaraju Kenetec Inc 550 Spring Street Naugatuck, CT 06770 Tel 203/723-4242 Extn-407 Fax 203/723-4187 Email: krishna.gundamaraju@kenetec.com Madhubabu, et al. [Page 270] Internet-Draft Megaco/H.248 Call flow examples Expires January 2002