Media Gateway Control (Megaco) Madhubabu Brahmanapally Internet Engineering Task Force Veraz Networks INTERNET-DRAFT Prerepa Viswanadham Document: draft-ietf-megaco-callflows-04.txt Marconi Category: Informational Krishna Gundamaraju Expires: April 25, 2005 ADC Telecommunications November 12 2004 Megaco/H.248 Call flow examples Status of this Memo By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on April 25, 2005 Abstract The Megaco/H.248 call flow examples draft illustrates the usage of Megaco - Version 1 protocol [Ref:3] 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 illustrate the supplementary call services using MEGACO. The call flows can be categorized in to two sub sections, - MEGACO only call scenario Madhubabu, et al. Informational - Expires April 2005 [Page 1] Internet-Draft Megaco/H.248 Call flow examples November2004 - MEGACO and other protocols The draft begins with showing MEGACO only call scenarios, where the called and calling party lie in MEGACO domain. Various 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 Madhubabu, et al. Informational - Expires April 2005 [Page 2] Internet-Draft Megaco/H.248 Call flow examples November2004 that the messages are according to the protocol grammar, in case of discrepancies the protocol draft should be considered for correctness. The Call flow diagrams 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. 1.1. Conventions used in this document ..............................4 1.2 References:......................................................4 2. Internet Telephony Call Flows.....................................4 2.1 Call between two residential gateways............................5 Case (a).calling party call termination.........................7 Case (b).called party call termination.........................19 Case (c).called party busy.....................................24 2.2 Call between Residential Gateway and Trunking Gateway...........26 2.3 Call between Trunking gateway and Residential Gateway...........37 2.4 Call between two Trunking gateways..............................46 2.5 Call between Residential gateway and SS7 trunk in TGW...........54 2.6 Call between SS7 trunk in TGW and residential gateway...........64 2.7 Call between SS7 trunk in TGW and R2 trunk in TGW...............74 2.8 Call between R2 trunk in TGW and SS7 trunk in TGW...............84 2.9 Call between R1 trunk in TGW and SS7 trunk in TGW...............94 2.10 Call between SS7 trunk in TGW and R1 trunk in TGW.............103 2.11 Call between ISDN trunk in TGW and SS7 trunk in TGW...........113 2.12 Continuity test from TGW......................................120 Case (a).....................................................120 Case (b).....................................................122 2.13 Call from residential gateway to H.323 Terminal...............123 2.14 Call from residential gateway to SIP user.....................132 3 Service Change Command Usage.....................................140 3.1 ROOT Termination...............................................140 3.1.1 MGC accepting registration...................................140 3.1.2 MGC rejecting registration...................................142 3.1.3 Handoff......................................................144 3.1.4 Disconnection................................................146 3.2 Service Change for Termination.................................149 3.2.1 MG generated Service Change..................................149 3.2.2 MGC generated Service Change.................................157 4.0 Audit Command Usage............................................160 4.1 Audit Value....................................................160 4.1.1 Audit value command on ROOT Termination......................160 4.1.2 Audit value on non-ROOT terminations.........................162 4.2 Audit Capability...............................................164 4.2.1 Audit Capability on ROOT termination.........................164 4.2.2 Audit Capability on non-Root Terminations....................165 5. IVR using MEGACO................................................166 5.1 Connecting Residential gateway to IVR..........................166 5.2 Disconnecting Residential User from IVR........................173 Madhubabu, et al. Informational - Expires April 2005 [Page 3] Internet-Draft Megaco/H.248 Call flow examples November2004 5.3 Connecting Trunking Gateway to IVR.............................176 5.4 Disconnecting Trunking gateway from IVR........................180 6. Wildcard ContextID usage........................................182 7. Wildcard TerminationId Usage....................................183 8. Supplementary services support..................................184 8.1 Call Transfer..................................................184 8.2 Call waiting...................................................207 9. Conferencing....................................................232 10.0 SDP for ATM...................................................266 10.1.1 Forward Bearer Connection Set-up Method.....................267 10.1.2 Backward Bearer Connection Set-up Method....................280 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 [Ref:2]. 1.2 References: 1) Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, November1996. 2) Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, April 1997. 3) C. Groves, M. Pantaleo et al. "Megaco Protocol Version 1.0", RFC 3525, June 2003. 4) Christian Huitema, et. Al. "Media Gateway Control Protocol (MGCP) Call Flows". < 5) Implementers' Guide for ITU Recommendation H.248. Mar 2002. 6) Megaco mail archive ftp://ftp.ietf.org/ietf-mail-archive/megaco/ 7) ITU-T Recommendation H.248.25 (07/2003), Gateway Control Protocol: Basic CAS Packages 8) ITU-T Recommendation H.248.28 (01/2004), Gateway Control Protocol: International CAS Packages 9) ITU-T Recommendation H.248.23 (07/2002), Gateway Control Protocol: Enhanced Alerting Packages 10) Rajesh Kumar et. al, Conventions for the use of the Session Description Protocol (SDP)for ATM Bearer Connections. RFC 3108, May 2001. 11) ITU-T Recommendation H.248.24 (05/2003), Gateway Control Protocol: Multi-Frequency Tone Generation and Detection Packages 2. Internet Telephony Call Flows This section illustrates sample Internet telephone calls. Calls between Madhubabu, et al. Informational - Expires April 2005 [Page 4] Internet-Draft Megaco/H.248 Call flow examples November2004 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 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. _____________________________________________________________________ | | | | USERA | RGW1 | MGC | RGW2 | USERB _____________|___________|___________|______________|_________________ | | | | | | | | | | | | |---------->| | | | |Modify to | | | | |Check Offhook | | |<----------| | | | |Modify to | | | | |check offhook | | | |---------->|<----------| | | |Modify Resp| Modify Resp | |----------->| | | | |UserA offhook | | | | |---------->| | | | |Notify offhook | | | |<----------| | | | |Notify Resp| | | | |<----------| | | | |Modify SD:cg/dt | | | |ED:al/on,dd/ce{Dmap1} | | | |DM:Dmap1 = 2XXX | | |<-----------| | | | |Dial Tone |---------->| | | | |Modify Resp| | | | | | | | |----------->| | | | Madhubabu, et al. Informational - Expires April 2005 [Page 5] Internet-Draft Megaco/H.248 Call flow examples November2004 |User Dials Digits | | | | |---------->| | | | |Notify digits | | | |<----------| | | | |Notify Response | | | |<----------| | | | | Add TermA | | | | | Add $, Local SDP Info -underspecified | | | | | | | | | | | | |---------->| | | | |Add Resp TermA | | | |Add Resp EphA Local SDP (Specified) | | | |---------->| | | | |Add TermB SD:al/ri ED:al/of | | | |Add $ Local SDP(Underspecified)| | | | Remote SDP (Specified) | | | | | | | | | |------------------>| | | | | UserB Phone Ringing | | |<----------| | | | |Add Resp TermB | | | |Add Resp EphB Local SDP Specified | |<----------| | | | |Modify TermA SD:cg/rt | | |<-----------| | | | | Ring back tone | | | | |---------->| | | | |Modify Resp TermA | | | | | |<------------------| | | | |UserB goes Offhook | | | |<----------| | | | |Notify Offhook | | | |---------->| | | | | Notify Resp | | | |---------->| | | | |Modify TermB SendRecv | | | |Modify EphB SendRecv | | | |<----------| | | | |Modify Resp| | | |<----------| | | | |Modify TermA SendRecv | | | |Modify EphA Remote(Specified) SendRecv | | |---------->| | | | |Modify Resp| | | |/------------------------------------------------------\| | RTP MEDIA | |\------------------------------------------------------/| Madhubabu, et al. Informational - Expires April 2005 [Page 6] Internet-Draft Megaco/H.248 Call flow examples November2004 |----------->| | | | |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 | |____________|___________|___________|___________________| Case (a) Call between two Residential Gateways - calling party call termination 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 hears a busy tone. A dial tone can be applied for the user to initiate 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 Madhubabu, et al. Informational - Expires April 2005 [Page 7] Internet-Draft Megaco/H.248 Call flow examples November2004 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 RGW1 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 which constructs and sends the Notify message towards the MGC. The MG uses the same request id (1111) sent by the MGC in its initial command. The timestamp of the detected event is also passed as parameter to the observed event. Step 3 RGW1 to MGC: MEGACO/1 [209.110.59.34]: 25000 Transaction = 2000 { Context = - { Notify = TermA {ObservedEvents =1111 { 20010202T10000000:al/of}} } Madhubabu, et al. Informational - Expires April 2005 [Page 8] Internet-Draft Megaco/H.248 Call flow examples November2004 MGC generates the Notify response and responds with more messages towards the MG that generated the Notify command. Step 4 MGC to RGW1: 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 RGW1: 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 RGW1 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 descriptors is signal descriptor, digit map descriptor followed by Events descriptor. The MG first processes the signal descriptor. The dial tone is applied to the Madhubabu, et al. Informational - Expires April 2005 [Page 9] Internet-Draft Megaco/H.248 Call flow examples November2004 Termination specified. The Digit map is updated in the Database of the termination. The Digit map is 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 a parameter to the digit map completion event. A notify command is generated from RGW1 to MGC. The MG again used the same request identifier as specified by the MGC. Step 7 RGW1 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 RGW1: 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. 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 and the Reserve group and the Reserve Value features are not used. Step 9 Madhubabu, et al. Informational - Expires April 2005 [Page 10] Internet-Draft Megaco/H.248 Call flow examples November2004 MGC to RGW1: MEGACO/1 [216.33.33.61]: 27000 Transaction = 1236 { Context = $ { Add = TermA { } 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 be created in 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 RGW1 to MGC: MEGACO/1 [209.110.59.34]: 25000 Reply = 1236 { Context = 1 { Add = TermA, Add=EphA{ Media { Local { v=0 o=- 2890844526 2890842807 IN IP4 209.110.59.34 s=- t= 00 c=IN IP4 209.110.59.33 Madhubabu, et al. Informational - Expires April 2005 [Page 11] Internet-Draft Megaco/H.248 Call flow examples November2004 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 RGW2: MEGACO/1 [216.33.33.61]:27000 Transaction = 1237 { Context = $ { Add = TermB { Media { LocalControl {Mode = Receiveonly} }, Signals {al/ri} Events =1234{al/of { Embed {events = 1235 {al/on}}}}, }, Add = $ {Media { LocalControl { Mode = Receiveonly, }, Local { v=0 c=IN IP4 $ m=audio $ RTP/AVP 4 }, Remote { v=0 o=- 2890844526 2890842807 IN IP4 209.110.59.34 s=- t= 00 c=IN IP4 209.110.59.33 Madhubabu, et al. Informational - Expires April 2005 [Page 12] Internet-Draft Megaco/H.248 Call flow examples November2004 m=audio 30000 RTP/AVP 4 } ; RTP profile for G.723 is 4 } } } } } RGW2 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 RGW2 reserves IP address 207.176.47.90 and port number 40000. The RGW2 responds to MGC with the following transaction reply. Step 12 RGW2 to MGC: MEGACO/1 [207.176.47.89]: 26000 Reply = 1237 { Context = 2 { Add = TermB, Add = EphB{ Media { Local { v=0 o=- 2890844527 2890842808 IN IP4 207.176.47.89 s=- t= 00 c=IN IP4 207.176.47.90 m=audio 40000 RTP/AVP 4 } } ; RTP profile for G723 is 4 } } } The Remote Gateway generates ring signal to the called party. The response of Add indicates successful alerting of the called party, the MGC then generates ring back tone to the calling party. Messages are exchanged in the form of Modify for the physical termination. The Originating Residential gateway after initiating the ringback tone generates response to the MGC to indicate Madhubabu, et al. Informational - Expires April 2005 [Page 13] Internet-Draft Megaco/H.248 Call flow examples November2004 successful execution of the command. Once the UserB goes offhook, RGW2 reports the offhook event to the MGC. Step 13 RGW2 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 RGW2 with the Notify response. Step 14 MGC to RGW2: MEGACO/1 [216.33.33.61]: 27000 Reply = 3000 { Context = 2 {Notify = TermB} } The MGC 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 RGW2: 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, } } Madhubabu, et al. Informational - Expires April 2005 [Page 14] Internet-Draft Megaco/H.248 Call flow examples November2004 } } The RGW2 responds to the request from MGC. Step 16 RGW2 to MGC: MEGACO/1 [207.176.47.89]: 26000 Reply = 1238 { Context = 2 {Modify = TermB , Modify = EphB} } The MGC generates message to 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 MGC 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} Remote { v=0 o=- 2890844527 2890842808 IN IP4 207.176.47.89 s=- t= 00 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 Madhubabu, et al. Informational - Expires April 2005 [Page 15] Internet-Draft Megaco/H.248 Call flow examples November2004 remote SDP information is updated for the ephemeral termination EphA and its mode is changed to send receive. RGW1 sends the response to the Modify command to the MGC. Step 18 RGW1 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 terminated either by the calling user or the called user. In this example it is assumed that the calling party has gone on-hook. After the conversation user A goes onhook initiating the call tear down. The same is reported in the Notify command from RGW1 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} } } The MGC responds to the RGW1s 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} Madhubabu, et al. Informational - Expires April 2005 [Page 16] Internet-Draft Megaco/H.248 Call flow examples November2004 Media { LocalControl { Mode = recvonly} } }, Modify = EphB { Media { LocalControl { Mode = recvonly} } } } } } The RGW2 responds to this modify request. Step 22 RGW2 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. Step 23: MGC to RGW1 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 RGW1 responds to this transaction from MGC with statistics on ephemeral termination. Step 24 RGW1 to MGC: MEGACO/1 [209.110.59.34]:25000 Reply = 1241 { Madhubabu, et al. Informational - Expires April 2005 [Page 17] Internet-Draft Megaco/H.248 Call flow examples November2004 Context = 1 { Subtract = TermA Subtract = EphA { St atistics { 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 } } } } After User B goes onhook the RGW2 generates Notify command towards the MGC. Step 25 RGW2 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 RGW2 with the Notify response. Step 26 MGC to RGW2: MEGACO/1 [216.33.33.61]: 27000 Reply = 3001 { Context = 2 {Notify = TermB} } The MGC generates subtract command towards RGW2 for removing TermB from valid context. Step 27 MGC to RGW2: MEGACO/1 [216.33.33.61]: 27000 Transaction = 1242 { Context = 2 { Subtract = TermB {Audit{ }}, Subtract = EphB {Audit{Statistics}} } Madhubabu, et al. Informational - Expires April 2005 [Page 18] Internet-Draft Megaco/H.248 Call flow examples November2004 } The RGW2 responds to the subtract commands generated by MGC. Step 28 RGW2 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 shown in step 1 to both the RGW1 and RGW2, to enable the users to participate/initiate in further calls. Case (b) Call between two Residential Gateways - called party call termination _____________________________________________________________________ | | | | USERA | RGW1 | MGC | RGW2 | USERB _____________|___________|___________|______________|_________________ Madhubabu, et al. Informational - Expires April 2005 [Page 19] Internet-Draft Megaco/H.248 Call flow examples November2004 | | | | | | | | | | |/------------------------------------------------------\| | 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) illustrated the call flow where the calling party initiates the call termination. 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. Madhubabu, et al. Informational - Expires April 2005 [Page 20] Internet-Draft Megaco/H.248 Call flow examples November2004 Step 19 RGW2 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 RGW2: 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 RGW1: 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. Informational - Expires April 2005 [Page 21] Internet-Draft Megaco/H.248 Call flow examples November2004 The RGW1 responds to this modify request. Step 22 RGW1 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 directed towards the RGW2, since UserB has initiated the call tear down. Step 23 MGC to RGW2: MEGACO/1 [216.33.33.61]: 27000 Transaction = 1241 { Context = 2 { Subtract = TermB {Audit {}}, Subtract = EphB {Audit {Statistics}} } } The RGW2 responds to the subtract commands generated by MGC. Step 24 RGW2 to MGC: MEGACO/1 [209.110.59.34]:25000 Reply = 1241 { 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 User A after hearing the busy tone goes onhook. The same activity Madhubabu, et al. Informational - Expires April 2005 [Page 22] Internet-Draft Megaco/H.248 Call flow examples November2004 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 RGW1s 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 RGW1 MEGACO/1 [216.33.33.61]: 27000 Transaction = 1242 { 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 RGW1 responds to this transaction from MGC with statistics on ephemeral termination. Step 28 RGW1 to MGC: MEGACO/1 [209.110.59.34]:25000 Reply = 1242 { Context = 1 { Subtract = TermA Subtract = EphA { Madhubabu, et al. Informational - Expires April 2005 [Page 23] Internet-Draft Megaco/H.248 Call flow examples November2004 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 the message shown in step 1 to both the RGW1 and RGW2, to enable the users to participate/initiate in further calls. Case (c) Call between two Residential Gateways - called party busy _____________________________________________________________________ | | | | USERA | RGW1 | MGC | RGW2 | USERB _____________|___________|___________|______________|_________________ | | | | | | | | | | | | |---------->| | | | |Modify to | | | | |Check Offhook | | |<----------| | | | |Modify to | | | | |check offhook | | | |---------->|<----------| | | |Modify Resp| Modify Resp | |----------->| | | | |UserA offhook | | | | |---------->| | | | |Notify offhook | | | | | | | | |<----------| | | | |Notify Resp| | | | |<----------| | | | |Modify SD:cg/dt | | | |ED:al/on,dd/ce{Dmap1} | | | |DM:Dmap1 = 2XXX | | |<-----------| | | | |Dial Tone |---------->| | | | |Modify Resp| | | | | | | | Madhubabu, et al. Informational - Expires April 2005 [Page 24] Internet-Draft Megaco/H.248 Call flow examples November2004 |----------->| | | | |User Dials Digits | | | | |---------->| | | | |Notify digits | | | |<----------| | | | |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 describe an unsuccesful call scenario where UserA calls UserB and as the UserB is already in a call, UserA receives busy tone. Steps 1 through 8 are similar to successful flow. 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 other call. Hence the call initiation from UserA becomes unsuccessful. MGC in this case issues a message, which instructs the MG, to apply busy tone on the Termination TermA. Step 9 MGC to RGW1: 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. Madhubabu, et al. Informational - Expires April 2005 [Page 25] Internet-Draft Megaco/H.248 Call flow examples November2004 Step 10: RGW1 to MGC: MEGACO/1 [209.110.59.34]: 25000 Reply = 1236 { Context = - { Modify = TermA } } 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: RGW1 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 RGW1: 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, Call progress generator package and the Network Package. The Trunking gateway supports RTP package, generic Madhubabu, et al. Informational - Expires April 2005 [Page 26] Intern et-Draft Megaco/H.248 Call flow examples November2004 package, and network package. We are not assuming any specific signaling protocol between the trunking Gateway and its peer. This makes callflow simple and independent of the type of signaling towards the other side of the Trunking gateway. _________________________________________________ | | | USERA | RGW1 | MGC | TGW _____________|___________|___________|___________ | | | | | | | | | |<----------| | | |Modify to | | | |check offhook | | |---------->| | | |Modify Resp| | |----------->| | | |UserA offhook | | |<-----------|---------->| | |Dial Tone |Notify offhook | | |<----------| | | |Notify Resp| | |----------->| | | |User Dials Digits | | | |---------->| | | |Notify digits | | |<----------| | | |Notify Response | | |<----------| | | | Add TermA | | | | Add $, Local SDP Info -underspecified | |---------->| | | |Add Resp TermA | | |Add Resp EphA Local SDP (Specified) | | |---------->| | | |Add Phy | | | |Add $ Local(Underspecified) | | | Remote SDP (Specified) | | |<----------| Madhubabu, et al. Informational - Expires April 2005 [Page 27] Internet-Draft Megaco/H.248 Call flow examples November2004 | | |Add Resp Phy | | |Add Resp EphB Local SDP Specified | |<----------| | | | Modify TermA SD: cb/rt| |<-----------| | | |user hears RingBack Tone | | |---------->| | | |Modify Resp TermA | | |<----------| | | |Modify TermA SendRecv | | |Modify EphA Remote(Specified) SendRecv | |---------->| | | |Modify Resp| | | | |---------->| | | |Modify Trunk1/line1 mode=sendRecv | | |Modify EphB mode = sendRecv | | |<----------| | | | Modify Resp Trunk1/line1 | | | Modify Resp EphB |/----------------------------------\| | 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 issues modify command to the residential gateway to check for offhook event on 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 Madhubabu, et al. Informational - Expires April 2005 [Page 28] Internet-Draft Megaco/H.248 Call flow examples November2004 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}} } } the MGC responds with the Notify response. Step 4 MGC to RGW: Madhubabu, et al. Informational - Expires April 2005 [Page 29] Internet-Draft Megaco/H.248 Call flow examples November2004 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}}} } } 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 ephem eral 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 { Media { { LocalControl { Mode = ReceiveOnly, }, Madhubabu, et al. Informational - Expires April 2005 [Page 30] Internet-Draft Megaco/H.248 Call flow examples November2004 } 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 message. Step 8 RGW to MGC: MEGACO/1 [209.110.59.34]: 25000 Reply = 1235 { Context = 1 { Add = TermA, Add=EphA { Media { Local { v=0 o=- 2890844528 2890842809 IN IP4 209.110.59.34 s=- t= 00 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 don't assume any specific Madhubabu, et al. Informational - Expires April 2005 [Page 31] Internet-Draft Megaco/H.248 Call flow examples November2004 signaling between the Trunking Gateway and its peer. 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 the circuits from the specified trunk. The ephemeral termination creation request has under specified local SDP information and fully specified 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 o=- 2890844528 2890842809 IN IP4 209.110.59.34 s=- t= 00 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 performs the necessary signaling actions towards the peer of the Trunking gateway. The trunk identifier allocated 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 Madhubabu, et al. Informational - Expires April 2005 [Page 32] Internet-Draft Megaco/H.248 Call flow examples November2004 TGW to MGC: MEGACO/1 [207.176.47.89]: 26000 Reply = 1236 { Context = 2 { Add = Trunk1/line1, Add = EphB{ Media { Local { v=0 o=- 2890844529 2890842810 IN IP4 207.176.47.89 s=- t= 00 c=IN IP4 207.176.47.90 m=audio 40000 RTP/AVP 4 } } ; RTP profile for G723 is 4 } } } The MGC after recieving the indication that alerting has been done towards the Trunking gateway side, will generate Modify command for the calling party for generation of ring back tone. The Residential gateway after generating the ring back tone responsds with the Modify Response to the MGC. As mentioned 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 to the RGW and changes the mode of the terminations 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 { Madhubabu, et al. Informational - Expires April 2005 [Page 33] Internet-Draft Megaco/H.248 Call flow examples November2004 v=0 o=- 2890844529 2890842810 IN IP4 207.176.47.89 s=- t= 00 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. This completes 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. Informational - Expires April 2005 [Page 34] Internet-Draft Megaco/H.248 Call flow examples November2004 The TGW after processing the mode change information in Modify command responds to it with the following message. 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 Madhubabu, et al. Informational - Expires April 2005 [Page 35] Internet-Draft Megaco/H.248 Call flow examples November2004 itself is deleted with the subtraction of the last termination from it. The MG1 respond s 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 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 20 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 Madhubabu, et al. Informational - Expires April 2005 [Page 36] Internet-Draft Megaco/H.248 Call flow examples November2004 nt/or=56789, ; octets received rtp/pl=10, ; % packets lost rtp/jit=30, rtp/delay=30 ; average latency } } } } 2.3 Call between Trunking gateway and Residential Gateway The previous section illustrated the call between a residential user and a Trunking gateway. There 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 between the Trunking gateway and its peer is taken care by an external entity, to avoid CAS/CCS specific details. ___________________________________________________________ | | | TGW | MGC | RGW | USERB _________ ___|___________|______________|_________________ | | | | | | | | |<----------| | | | Add Phy SD:cg/rt | | | Add $, Local SDP Info -underspecified | |---------->| | | |Add Resp Phy | | |Add Resp EphA 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 SDP Specified | | |<------------------| | | |UserB goes Offhook | | |<----------| | | |Notify Offhook | | |---------->| | Madhubabu, et al. Informational - Expires April 2005 [Page 37] Internet-Draft Megaco/H.248 Call flow examples November2004 | | Notify Resp | | |---------->| | | |Modify Phy SendRecv | | |Modify EphB SendRecv | | |<----------| | | |Modify Resp| | |<----------| | | |Modify Phy SendRecv | | |Modify EphA Remote SDP (Specified) SendRecv |---------->| | | |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 | |___________|___________|___________________| We assume here that the MGC knows about the call initiation by some non-MEGACO means (SIGTRAN for example). The MGC then instructs 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. Madhubabu, et al. Informational - Expires April 2005 [Page 38] Internet-Draft Megaco/H.248 Call flow examples November2004 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, }, 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 respons e 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 and 40000 as the port number for the RTP media stream. 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 o=- 2890844521 2890842812 IN IP4 207.176.47.89 s=- Madhubabu, et al. Informational - Expires April 2005 [Page 39] Internet-Draft Megaco/H.248 Call flow examples November2004 t= 00 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, instructs the RGW to alert User B in the ADD command for the physical termination TermB. The MGC uses $ contextID indicating the creation of Context at MG. The Ephemeral termination creation is also requested. The Remote SDP information is also passed as one of the parameters in the media descriptor. The signal descriptor in the Add command for physical termination instructs RGW to apply the ring signal on the termination TermB. Step 3 MGC to RGW: MEGACO/1 [216.33.33.61]: 27000 Transaction = 1235 { Context = $ { Add = TermB { Signals { al/ri } Events= 1111 { al/of { Embed { 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 o=- 2890844521 2890842812 IN IP4 207.176.47.89 s=- Madhubabu, et al. Informational - Expires April 2005 [Page 40] Internet-Draft Megaco/H.248 Call flow examples November2004 t= 00 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: MEGACO/1 [209.110.59.34]: 25000 Reply = 1235 { Context = 1 { Add = TermB, Add=EphB { Media { Local { v=0 o=- 2890844522 2890842813 IN IP4 209.110.59.34 s=- t= 00 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. Madhubabu, et al. Informational - Expires April 2005 [Page 41] Internet-Draft Megaco/H.248 Call flow examples November2004 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 = 1 {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 on both RGW and TGW. Step 7: MGC to RGW MEGACO/1 [216.33.33.61]: 27000 Transaction = 1236 { Context = 1 { Modify = TermB { Media { 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 Madhubabu, et al. Informational - Expires April 2005 [Page 42] Internet-Draft Megaco/H.248 Call flow examples November2004 Reply= 1236 { Context = 1 { Modify = TermB {} Modify = EphB { } } } The MGC also generates similar command towards the Trunking gateway that instructs it to change the mode of the terminations to send and receive. The MGC in the Modify for the ephemeral termination also specifies the remote SDP information. 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 o=- 2890844522 2890842813 IN IP4 207.176.47.89 s=- t= 00 c=IN IP4 207.176.47.90 m=audio 40000 RTP/AVP 4 } } ; 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 Madhubabu, et al. Informational - Expires April 2005 [Page 43] Internet-Draft Megaco/H.248 Call flow examples November2004 Reply = 1237 { Context = 2 { Modify = Trunk1/line1, Modify = EphA { } } } Once the mode of both the terminations changed to send receive the two users can start the conversation. The media stream is established. It is assumed here that the user connected to the peer of the trunking Gateway, who is also the call originator, initiates the call termination. The MGC is updated with this information by some non-MEGACO means (using SIGTRAN for example). 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 { } } } 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 { Madhubabu, et al. Informational - Expires April 2005 [Page 44] Internet-Draft Megaco/H.248 Call flow examples November2004 Subtract = Trunk1/line1{Audit{ }}, Subtract = EphA {Audit{Statistics}} } } The TGW r esponds with the Statistics of the ephemeral termination in the response to the Subtract command. The context is deleted as a side effect of deletion of 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 user of the RGW goes onhook. The RGW generates a Notify command towards the MGC. Step 15: RGW to MGC: MEGACO/1 [209.110.59.34]: 25000 Transaction = 2001 { Context = 1 { Notify = TermB {ObservedEvents =1112 { 20010202T10030000:al/on} } } } The MGC responds to the RGWs Notify message. Step 16 MGC to MG1: MEGACO/1 [216.33.33.61]: 27000 Reply = 2001 { Context = 1 { Notify = TermA } Madhubabu, et al. Informational - Expires April 2005 [Page 45] Internet-Draft Megaco/H.248 Call flow examples November2004 } The MGC generates subtract command towards the RGW to delete the physical and ephemeral terminations. Step 17 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. Step 18 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 when the response is 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 generate and receive further calls. 2.4 Call between two Trunking gateways The previous three sections illustrates calls between two residential gateways, and also between residential gateway and Trunking gateway. This callflow illustrates call between two trunking gateways connected to the same MGC. Madhubabu, et al. Informational - Expires April 2005 [Page 46] Internet-Draft Megaco/H.248 Call flow examples November2004 In this scenario also to avoid unnecessary complexity we still assume that some non-MEGACO means of signaling is performed by the MGC. The CAS/CCS signaling details towards the other side of the each Trunking gateway is avoided for simplicity. In this call scenario MGC generates messages for enabling media flow. No signaling is done on either the physical or ephemeral termination. ________________________________________ | | TGW1 | MGC | TGW2 _________ ___|___________|______________ | | | | | | |<----------| | | Add Phy SD:ringbacktone | Add $, Local SDP Info -underspecified |---------->| | |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 Madhubabu, et al. Informational - Expires April 2005 [Page 47] Internet-Draft Megaco/H.248 Call flow examples November2004 | |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 { 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. Madhubabu, et al. Informational - Expires April 2005 [Page 48] Internet-Draft Megaco/H.248 Call flow examples November2004 Step 2: TGW1 to MGC: MEGACO/1 [209.110.59.34]: 25000 Reply = 1234 { Co ntext = 1 { Add = Trunk1/line1, Add = EphA{ Media { Local { v=0 o=- 2890844522 2890842813 IN IP4 209.110.59.34 s=- t= 00 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 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 }, Madhubabu, et al. Informational - Expires April 2005 [Page 49] Internet-Draft Megaco/H.248 Call flow examples November2004 Remote { v=0 o=- 2890844522 2890842813 IN IP4 209.110.59.34 s=- t= 00 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 o=- 2890844523 2890842814 IN IP4 207.176.47.89 s=- t= 00 c=IN IP4 207.176.47.90 m=audio 40000 RTP/AVP 4 } } ; 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: Madhubabu, et al. Informational - Expires April 2005 [Page 50] Internet-Draft Megaco/H.248 Call flow examples November2004 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 o=- 2890844523 2890842814 IN IP4 207.176.47.89 s=- t= 00 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 { } } } Similar command is generated from the MGC towards the second Trunking gateway. Step 7 MGC to TGW1: MEGACO/1 [216.33.33.61]: 27000 Madhubabu, et al. Informational - Expires April 2005 [Page 51] Internet-Draft Megaco/H.248 Call flow examples November2004 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. Step 10: TGW2 to MGC: MEGACO/1 [207.176.47.89]:26000 Reply = 1238 { Madhubabu, et al. Informational - Expires April 2005 [Page 52] Internet-Draft Megaco/H.248 Call flow examples November2004 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 from MGC. The terminations are present in the idle state. Madhubabu, et al. Informational - Expires April 2005 [Page 53] Internet-Draft Megaco/H.248 Call flow examples November2004 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 | | |<-----------| | | | |user hears |---------->| | | | Dial Tone |Modify Resp| | | | | | | | |----------->| | | | |User Dials Digits | | | | |---------->| | | | |Notify digits | | | |<----------| --------------------------->| | |Notify Response IAM | | |<----------| | | Madhubabu, et al. Informational - Expires April 2005 [Page 54] Internet-Draft Megaco/H.248 Call flow examples November2004 | | Add TermA | | | | | Add $, Local SDP Info -underspecified | | | | | | | | |<----------------------------| | |---------->| ACM | | |Add Resp TermA | | | |Add Resp Local SDP (Specified) | | | |---------->| | | | |Add Phy | | | | |Add $ Local(Underspecified) | | | | Remote SDP (Specified) | | | |<----------| | | | |Add Resp Phy | | | |Add Resp EphB Local Specified| | | Modify TermA SD: cg/rt| | |<-----------| | | | | User hears Ring back tone | | | |---------->| | | | | Modify Resp TermA | | | | |<----------------------------| | | | ANM | | |<----------| | | | |Modify TermA SendRecv | | | |Modify EphA Remote(Specified) SendRecv | | |---------->| | | | |Modify Resp| | | | | |---------->| | | | | Modify Trunk1/line1 mode=sendrecv | | | Modify EphB mode=sendrecv | | | |<----------| | | | | Modify Resp Trunk1/line1 | | | | Modify Resp EphB | |/----------------------------------\| | | RTP MEDIA | | |\----------------------------------/| | |----------->| | | | |UserA goes OnHook | | | | |---------->| | | | |Notify OnHook | | | |<----------| | | | |Notify Resp| | | | |<----------| | | | |Subtract TermA | | | |Subtract EphA | | | | |---------------------------->| | | | REL | | |---------->| | | | |Subtract Resp TermA | | Madhubabu, et al. Informational - Expires April 2005 [Page 55] Internet-Draft Megaco/H.248 Call flow examples November2004 | |Subtract Resp EphA Statistics | | | |---------->| | | | |Subtract Phy | | | |Subtract EphB | | | |<----------------------------| | | | RLC | | | |<----------| | | | |Subtract Resp Phy | | | |Subtract Resp EphB 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} } Madhubabu, et al. Informational - Expires April 2005 [Page 56] Internet-Draft Megaco/H.248 Call flow examples November2004 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 {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 generates the Add command for adding the physical termination TermA and to create an ephemeral termination EphA. The local SDP Madhubabu, et al. Informational - Expires April 2005 [Page 57] Internet-Draft Megaco/H.248 Call flow examples November2004 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 { 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 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 { Madhubabu, et al. Informational - Expires April 2005 [Page 58] Internet-Draft Megaco/H.248 Call flow examples November2004 Local { v=0 o=- 2890844523 2890842814 IN IP4 209.110.59.34 s=- t= 00 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 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 o=- 2890844523 2890842814 IN IP4 209.110.59.34 s=- Madhubabu, et al. Informational - Expires April 2005 [Page 59] Internet-Draft Megaco/H.248 Call flow examples November2004 t= 00 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 o=- 2890844524 2890842815 IN IP4 207.176.47.89 s=- t= 00 c=IN IP4 207.176.47.90 m=audio 40000 RTP/AVP 4 } } ; RTP profile for G723 is 4 } } } The MGC after recieving the ACM (with the alerting information element set) , generates Modify command towards the Residential gateway for generating ring back tone to the calling subscriber. The gateway responds with successful execution of the command. 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: Madhubabu, et al. Informational - Expires April 2005 [Page 60] Internet-Draft Megaco/H.248 Call flow examples November2004 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 o=- 2890844524 2890842815 IN IP4 207.176.47.89 s=- t= 00 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 { Madhubabu, et al. Informational - Expires April 2005 [Page 61] Internet-Draft Megaco/H.248 Call flow examples November2004 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 } } The MGC now generates subtract commands both to the RGW and the TGW. Madhubabu, et al. Informational - Expires April 2005 [Page 62] Internet-Draft Megaco/H.248 Call flow examples November2004 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. Informational - Expires April 2005 [Page 63] Internet-Draft Megaco/H.248 Call flow examples November2004 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 call scenario explained in section 2.5, we illustrated the call flow between MGC and MG with SS7 signaling towards the trunk side. The residential Gateway user in that scenario initiated the call. In this scenario we illustrate a similar situation where a call is initiated by a user connected to the PSTN network that uses 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 | RGW | USERB ____________|________ ___|___________|______________|_________________ | | | | | | | | | | |----------------------->| | | | IAM | | | | | | | | Madhubabu, et al. Informational - Expires April 2005 [Page 64] Internet-Draft Megaco/H.248 Call flow examples November2004 | | | | | |<-----------------------| | | | ACM | | | | | | | | | |<----------| | | | | Add Trunk1/line1 | | | | Add $, Local SDP Info -underspecified | | |---------->| | | | |Add Resp Trunk1/line1 | | | |Add Resp EphB Local SDP (Specified) | | | |---------->| | | | |Add TermA SD: cg/ri ED: al/of | | | |Add $ Local(Underspecified) | | | | Remote SDP (Specified) | | | | | | | | | |------------------>| | | | | UserB Phone Ringing | | |<----------| | | | |Add Resp TermA | |<-----------------------|Add Resp EphA Local SDP Specified | CPG | |<------------------| | | | |UserB goes Offhook | |<-----------------------| | | | ANM | | | | | |<----------| | | | |Notify Offhook | | | |---------->| | | | | Notify Resp | | |<----------| | | | |Modify Trunk1/line1 SendRecv | | |Modify EphB Remote SDP(Specified) SendRecv| | |---------->| | | | |Modify Resp| | | | | |---------->| | | | |Modify Phy SendRecv | | | |Modify EphB SendRecv | | | |<----------| | | | |Modify Resp| | | |/-----------------------------------------\| | | RTP MEDIA | | |\-----------------------------------------/| |----------------------->| | | | REL | | | | | |---------->| | | | |Modify TermB SD:BusyTone | | | | |------------------>| | | | | Busy tone to UserB| | | |<----------| | Madhubabu, et al. Informational - Expires April 2005 [Page 65] Internet-Draft Megaco/H.248 Call flow examples November2004 | | |Modify Resp| | | |<----------| | | | |Subtract Phy | | | |Subtract EphB | | | |---------->| | | | |Subtract Resp Phy | | | |Subtract Resp EphB Statistics | | | | |<------------------| | | | | UserB goes Onhook | |<-----------------------| | | | RLC | | | | | |<----------| | | | |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 when the Signaling Gateway receives an IAM message from its peer. The MGC,after receiving the IAM message, Instructs the Signaling Gateway to respond with an 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 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 1 MGC to TGW MEGACO/1 [216.33.33.61]: 27000 Transaction = 1235 { Context = $ { Add = Trunk1/line1 {Media { Madhubabu, et al. Informational - Expires April 2005 [Page 66] Internet-Draft Megaco/H.248 Call flow examples November2004 LocalControl {Mode = SendRecv}}, }, Add = $ {Media { LocalControl { Mode = Receiveonly, }, Local { v=0 c=IN IP4 $ m=audio $ RTP/AVP 4 } } } } } } The Trunking gateway after processing the above message, creates a new context with a contextID in this example. 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 SDP parameters are specified in the response. The IP address chosen for the media transport in this example is 207.176.47.88, and the port number specified 30000. Step 2 TGW to MGC: MEGACO/1 [207.176.47.89]: 26000 Reply = 1235 { Context = 1 { Add = Trunk1/line1, Add = EphB { Media { Local { v=0 o=- 2890844524 2890842815 IN IP4 207.176.47.89 s=- t= 00 c=IN IP4 207.176.47.88 m=audio 30000 RTP/AVP 4 } } ; RTP profile for G723 is 4 } } } The MGC specifies the local SDP information it has received from Madhubabu, et al. Informational - Expires April 2005 [Page 67] Internet-Draft Megaco/H.248 Call flow examples November2004 the TG as the remote SDP information in the ADD command it generates towards the RG. The MGC also requests the RGW to apply ring singal and check for offhook on TermA. The commands for adding the physical termination TermA and the 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 3 MGC to RGW MEGACO/1 [216.33.33.61]: 27000 Transaction = 1236 { Context = $ { Add = TermA {Media { Events = 1111 {al/of} Signals = {al/ri} ; For application of ring signal LocalControl {Mode = SendRecv}}, }, Add = $ {Media { LocalControl { Mode = Receiveonly, }, Local { v=0 c=IN IP4 $ m=audio $ RTP/AVP 4 } Remote{ v=0 o=- 2890844524 2890842815 IN IP4 207.176.47.89 s=- t= 00 c=IN IP4 207.176.47.88 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 remote SDP information. The response from the MG specifies the local SDP information. Step 4 RGW to MGC: MEGACO/1 [209.110.59.34]: 25000 Madhubabu, et al. Informational - Expires April 2005 [Page 68] Internet-Draft Megaco/H.248 Call flow examples November2004 Reply = 1236 { Context = 2 { Add = TermA, Add = EphA{ Media { Local { v=0 o=- 2890844525 2890842816 IN IP4 209.110.59.34 s=- t= 00 c=IN IP4 209.110.59.33 m=audio 30000 RTP/AVP 4 } } ; RTP profile for G723 is 4 } } } Lets assume that the user goes 'offhook' after hearing the ring tone.The same event is reported to the MGC in the notify command. Step 5 RGW to MGC: MEGACO/1 [209.110.59.34]:25000 Transaction = 2000 { Context = 2 { Notify = TermA {ObservedEvents =1111 { 20010202T10000000:al/of}} } } the MGC responds the Notify command with the Notify response. Step 6 MGC to RGW: MEGACO/1 [216.33.33.61]: 27000 Reply = 2000 { Context = 2 {Notify = TermA} } After receiving the offhook event MGC instructs the Signaling Gateway to generate an ANM message towards its signaling peer. This message informs the peer that the called user has answered the call. The MGC updates the Trunking gateway with remote SDP information in the Modify command. Step 7 MGC to TGW MEGACO/1 [216.33.33.61]: 27000 Transaction = 1237 { Madhubabu, et al. Informational - Expires April 2005 [Page 69] Internet-Draft Megaco/H.248 Call flow examples November2004 Context = 1 { Modify = EphB {Media { LocalControl { Mode = SendRecv, }, Remote{ v=0 o=- 2890844525 2890842816 IN IP4 209.110.59.34 s=- t= 00 c=IN IP4 209.110.59.33 m=audio 30000 RTP/AVP 4 } } } } } } The Trunking gateway responds to the Modify command. Step 8 TGW to MGC: MEGACO/1 [207.176.47.89]: 26000 Reply = 1237 { Context = 1 { Modify = EphB } } The MGC updates the mode of the terminations on the Residential Gateway Step 9 MGC to RGW: MEGACO/1 [216.33.33.61]: 27000 Transaction = 1238 { Context = 2 { Modify = TermA { Media { LocalControl { Mode = sendrecv} } } }, Modify = EphA { Media { LocalControl { Mode = sendrecv} } Madhubabu, et al. Informational - Expires April 2005 [Page 70] Internet-Draft Megaco/H.248 Call flow examples November2004 } } } The RGW after receiving the mode change information in Modify command responds to it. Step 10 RGW to MGC: MEGACO/1 [209.110.59.34]: 25000 Reply = 1238 { Context = 2 {Modify = TermA, Modify = EphA} } The RTP media can be transferred between the two. The call will be disconnected when one of the two users initiates call teardown. In this example we assume that 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 9 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. Step 10 RGW to MGC: MEGACO/1 [209.110.59.34]: 25000 Reply = 1239 { Context = 2 { Modify = TermA, } } The media connection tear down process is completed by responding to the REL message with the RLC. The MGC subtracts the terminations added in the two Madhubabu, et al. Informational - Expires April 2005 [Page 71] Internet-Draft Megaco/H.248 Call flow examples November2004 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 11 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 command with the statistics on the Ephemeral termination. Step 12 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 } } } } After hearing the busy tone lets assume that the UserB goes onhook. The RG conveys this information to the MGC using the following NOTIFY message. Step 13 RGW to MGC: MEGACO/1 [209.110.59.34]:25000 Transaction = 2001 { Context = 2 { Notify = TermA {ObservedEvents =1236 { 20010202T20000000:al/on}} } } Madhubabu, et al. Informational - Expires April 2005 [Page 72] Internet-Draft Megaco/H.248 Call flow examples November2004 The MGC responds the Notify command with the Notify response. Step 14 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. Informational - Expires April 2005 [Page 73] Internet-Draft Megaco/H.248 Call flow examples November2004 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 that does 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 H.248.28 package is taken as the input for illustrating the events and signals used for communication between MG and MGC. The assumption of the 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 | SS7TGW | MGC | R2TGW | 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. Informational - Expires April 2005 [Page 74] Internet-Draft Megaco/H.248 Call flow examples November2004 | | |----------->| | | | |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 Remote specified (mode = sendrecv) | | |<-----------| | | | |Modify REsp Eph | | |<----------| | | | |Modify Eph mode=sendrecv| | | |---------->| | | | |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 | | | | |---------->| | | Madhubabu, et al. Informational - Expires April 2005 [Page 75] Internet-Draft Megaco/H.248 Call flow examples November2004 | |Sub Phy Resp | | | |Sub Eph Resp Statistics | | | | |----------->| | | | |Sub Phy | | | | |Sub Eph | | | | |<-----------| | | | |Sub Phy Resp| | | | |Sub Eph Resp Statistics | |____________|___________|____________|________________| When the MGC receives the IAM through the signaling gateway, it generates a Modify message towards the Trunking gateway that supports H.248.28 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 instructed 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 } Madhubabu, et al. Informational - Expires April 2005 [Page 76] Internet-Draft Megaco/H.248 Call flow examples November2004 } 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 R2TGW to MGC: MEGACO/1 [209.110.59.34]: 25000 Transaction = 2000 { Context = - { Notify = Trunk1/line1 {ObservedEvents =1111 { 20010202T10000000:R2/sa}} } } the MGC responds the Notify command with the Notify response. Step 4 MGC to R2TGW: 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. After receiving the answer message from the peer R2 exchange the R2TGW generates message to notify this event. Step 5 R2TGW to MGC: MEGACO/1 [209.110.59.34]: 25000 Transaction = 2001 { Context = - { Notify = Trunk1/line1 {ObservedEvents =1112 { 20010202T10000000:R2/ans}} } } The MGC responds to the Notify command with the Notify response. Step 6 MGC to R2TGW: MEGACO/1 [216.33.33.61]: 27000 Reply = 2001 { Madhubabu, et al. Informational - Expires April 2005 [Page 77] Internet-Draft Megaco/H.248 Call flow examples November2004 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 underspecified that instructs the TGW to choose the under specified parameters. Step 7 MGC to R2TGW 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 processing the Add command creates a new context with contextID 1 in this example. 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 { Madhubabu, et al. Informational - Expires April 2005 [Page 78] Internet-Draft Megaco/H.248 Call flow examples November2004 Add = Trunk1/line1, Add = EphA { Media { Local { v=0 o=- 2890844525 2890842816 IN IP4 209.110.59.34 s=- t= 00 c=IN IP4 209.110.59.33 m=audio 30000 RTP/AVP 4 } } ; RTP profile for G723 is 4 } } } After receiving the response from the R2TGW, the MGC generates similar transaction with two ADD commands to the other TGW. The local SDP information indicated in the response from the R2TGW is specified as remote SDP information for the SS7TGW. The MGC conveys this information in the Add command. Step 9 MGC to SS7TGW MEGACO/1 [216.3 3.33.61]: 27000 Transaction = 1236{ Context = $ { Add = Trunk2/line1 {Media { LocalControl {Mode = SendRecv}}, }, Add = $ {Media { LocalControl { Mode = Receiveonly, }, Local { v=0 c=IN IP4 $ m=audio $ RTP/AVP 4 } Remote{ v=0 o=- 2890844525 2890842816 IN IP4 209.110.59.34 s=- t= 00 c=IN IP4 209.110.59.33 m=audio 30000 RTP/AVP 4 } } ; RTP profile for G723 is 4 } Madhubabu, et al. Informational - Expires April 2005 [Page 79] Internet-Draft Megaco/H.248 Call flow examples November2004 } } 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 SS7TGW to MGC: MEGACO/1 [207.176.47.89]: 26000 Reply = 1236{ Context = 2 { Add = Trunk2/line1, Add = EphB{ Media { Local { v=0 o=- 2890844525 2890842816 IN IP4 207.176.47.89 s=- t= 00 c=IN IP4 207.176.47.90 m=audio 30000 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 11 MGC to R2TGW MEGACO/1 [216.33.33.61]: 27000 Transaction = 1237{ Context = 1 { Modify = EphA {Media { LocalControl { Mode = SendRecv, }, Remote{ v=0 o=- 2890844525 2890842816 IN IP4 207.176.47.89 s=- t= 00 Madhubabu, et al. Informational - Expires April 2005 [Page 80] Internet-Draft Megaco/H.248 Call flow examples November2004 c=IN IP4 207.176.47.90 m=audio 30000 RTP/AVP 4 } } } } } } The R2 Trunking gateway responds to the Modify command. Step 12 R2TGW to MGC: MEGACO/1 [207.176.47.89]: 26000 Reply = 1237{ Context = 1 { Modify = EphA } } The RTP media flow is now established and the two users connected to the SS7 trunk and R2 trunk can start the conversation. After conversation any 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 and the Signaling gateway forwards the same 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 R2TGW: MEGACO/1 [216.33.33.61]: 27000 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 Madhubabu, et al. Informational - Expires April 2005 [Page 81] Internet-Draft Megaco/H.248 Call flow examples November2004 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 SS7TGW to remove the terminations from the newly created context. Step 15 MGC to SS7TGW: 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 with the statistics on the Ephemeral termination. Step 16 SS7TGW 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 } } } } The MGC after receiving the response from the TGW instructs the Signaling gateway to generate a RLC (Release complete) message towards the peer SS7 switch. After detecting the clear back signal received from the peer R2 exchange the R2TGW generates a Notify command towards the MGC. Madhubabu, et al. Informational - Expires April 2005 [Page 82] Internet-Draft Megaco/H.248 Call flow examples November2004 Step 17 R2TGW to MGC: MEGACO/1 [209.110.59.34]:25000 Transaction = 2002 { Context = - { Notify = TermA {ObservedEvents =1113 { 20030202T10000000:R2/clear}} } } the MGC responds the Notify command with the Notify response. Step 18 MGC to R2TGW: 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 { 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. Informational - Expires April 2005 [Page 83] Internet-Draft Megaco/H.248 Call flow examples November2004 } } } } 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 H.248.28 package is considered for illustrating the events and signals used for communication between MG and MGC. The assumption of the H.248.28, that the compelled signaling is part of the MG to generate signals or detect events holds true for this call scenario also. ______________________________________________________________________ | | | | R2Exchange | R2TGW | MGC | SS7TGW | 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 | | | | |----------->| | | | |Notify OE:addr | | | | |----------->| | | | | IAM |--------------->| | |<-----------| | IAM | Madhubabu, et al. Informational - Expires April 2005 [Page 84] Internet-Draft Megaco/H.248 Call flow examples November2004 | |Notify Resp | |<---------------| | | |<-----------| CON | | | | CON | | | |<-----------| | | | |Modify Phy | | | |<-----------| | | | | Answer | | | | | |----------->| | | | |Modify Resp | | | | |<-----------| | | | | Add Phy | | | | | Add $ Local Unspecified | | |----------->| | | | |Add Phy Resp| | | | |Add Eph Resp Local Specified | | | |----------->| | | | | Add Phy | | | | | Add $ Local Unspecified | | | | Remote Specified | | | |<-----------| | | | |Add Phy Resp| | | | |Add Eph Resp local specified | | |<-----------| | | | |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. Informational - Expires April 2005 [Page 85] Internet-Draft Megaco/H.248 Call flow examples November2004 | | |----------->| | | | |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 Madhubabu, et al. Informational - Expires April 2005 [Page 86] Internet-Draft Megaco/H.248 Call flow examples November2004 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. The Notify command is generated towards the MGC. Step 3 R2TGW to MGC: MEGACO/1 [209.110.59.34]:25000 Transaction = 2000 { Context = - { Notify = TermA {ObservedEvents =1111 { 20010202T10000000:R2/sz}} } } the MGC responds the Notify command with the Notify response. Step 4 MGC to R2TGW: 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 R2TGW to MGC: MEGACO/1 [209.110.59.34]:25000 Transaction = 2001 { Context = - { Notify = TermA {ObservedEvents =1112 { 20010302T10000000:R2/address { di=2992, si=2804 , sc=1 } }} } } the MGC responds the Notify command with the Notify response. Step 6 MGC to R2TGW: MEGACO/1 [216.33.33.61]: 27000 Reply = 2001 { Context = - {Notify = TermA} } The MGC then instructs the Signaling gateway to initiate the necessary signaling towards the exchange to Madhubabu, et al. Informational - Expires April 2005 [Page 87] Internet-Draft Megaco/H.248 Call flow examples November2004 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. We assume the called party to be an automatic answering terminal in this example. So the SS7 switch responds with the CON message. After receiving the CON message, the MGC sends a Modify command towards the R2 TGW to indicate that the answer signal needs to be applied to the termination 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 [209.110.59.34]: 25000 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, Madhubabu, et al. Informational - Expires April 2005 [Page 88] Internet-Draft Megaco/H.248 Call flow examples November2004 }, Local { v=0 c=IN IP4 $ m=audio $ RTP/AVP 4 } } } } } } After processing the ADD command the R2 Trunking gateway creates a new context with a context id of 1 in this example. 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 o=- 2890844525 2890842816 IN IP4 209.110.59.34 s=- t= 00 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 SS7TGW. The local SDP information specified by the R2TGW is used as remote SDP information for the SS7TGW. The MGC conveys this information in the Add command. Step 11 MGC to SS7TGW MEGACO/1 [216.33.33.61]: 27000 Madhubabu, et al. Informational - Expires April 2005 [Page 89] Internet-Draft Megaco/H.248 Call flow examples November2004 Transaction = 1237{ Context = $ { Add = Trunk2/line1 {Media { LocalControl {Mode = SendRecv}}, }, Add = $ {Media { LocalControl { Mode = Receiveonly, }, Local { v=0 c=IN IP4 $ m=audio $ RTP/AVP 4 } Remote{ v=0 o=- 2890844525 2890842816 IN IP4 209.110.59.34 s=- t= 00 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 SS7TGW to MGC: MEGACO/1 [207.176.47.89]: 26000 Reply = 1237{ Context = 2 { Add = Trunk2/line1, Add = EphB{ Media { Local { v=0 o=- 2890844525 2890842816 IN IP4 207.176.47.89 s=- t= 00 c=IN IP4 207.176.47.90 m=audio 40000 RTP/AVP 4 Madhubabu, et al. Informational - Expires April 2005 [Page 90] Internet-Draft Megaco/H.248 Call flow examples November2004 } } ; 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 SS7TGW 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 o=- 2890844525 2890842816 IN IP4 207.176.47.89 s=- t= 00 c=IN IP4 207.176.47.90 m=audio 40000 RTP/AVP 4 } } } } } } The R2 Trunking gateway responds to the Modify command. Step 14 R2TGW to MGC: MEGACO/1 [209.110.59.34]: 25000 Reply = 1238{ Context = 1 { Modify = EphA } } The RTP media transfer can now take place. After completing the conversation 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 H.248.28 package. The clear Madhubabu, et al. Informational - Expires April 2005 [Page 91] Internet-Draft Megaco/H.248 Call flow examples November2004 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 = 2002 { 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 REL (Release) message towards the SS7 switch to initate call release. The SS7 switch responds to this message with the RLC(Release Complete) 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 Transaction = 1239{ Context = 1 { Subtract = Trunk1/line1{Audit{ }}, Subtract = EphA {Audit{Statistics}} } } The R2TGW responds to the subtract commands generated by MGC. Step 18 R2TGW to MGC: MEGACO/1 [209.110.59.34]:25000 Reply = 1239{ Context = 1 { Subtract = Trunk1/line1 Subtract = EphA { Statistics { Madhubabu, et al. Informational - Expires April 2005 [Page 92] Internet-Draft Megaco/H.248 Call flow examples November2004 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 SS7TGW: 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 SS7TGW 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 rtp/jit=30, rtp/delay=30 ; average latency } } } } Madhubabu, et al. Informational - Expires April 2005 [Page 93] Internet-Draft Megaco/H.248 Call flow examples November2004 2.9 Call between R1 trunk in TGW and SS7 trunk in TGW In the previous section we illustrated the Megaco messages between MGC and two Trunking gateways, one that perform CCS SS7 and the other that performs CAS R2 signaling. This section illustrates another similar scenario, but now the call is initiated by a user who is connected to a R1 exchange to the user connected to an exchange that can be reached through an CCS SS7 signaling cloud. Both the Trunking gateways are assumed to be controlled by the same Media Gateway Controller. The packages that are considered are H.248.25 package for R1, network package, MF tone detection package and RTP package. ______________________________________________________________________ | | | | R1Exchange | R1TGW | MGC | SS7TGW | SS7 Switch ____________|____________|___________|______________|_________________ | | | | | | |<-----------| | | | |Modify ED:sz{SD:sa ED:addr, cl} | | |----------->| | | | |Modify Resp | | | |----------->| | | | | Seize | | | | |<-----------| | | | |SeizeAck |----------->| | | | |Notify OE:sa| | | |----------->| | | | | KP | | | | |----------->| | | | | Digit1 | | | | | : | | | | | : | | | | |----------->| | | | | ST | | | | | |----------->| | | | |Notify OE:addr | | | | |----------->| | | | | IAM |--------------->| | |<-----------| | IAM | | |Notify Resp | |<---------------| | | |<-----------| ACM | | | | ACM | | | |<-----------| | | | |Modify Phy | | | |<-----------| | | | | Answer | | | | | |----------->| | | Madhubabu, et al. Informational - Expires April 2005 [Page 94] Internet-Draft Megaco/H.248 Call flow examples November2004 | |Modify Resp | | | | |<-----------| | | | | Add Phy | | | | | Add $ Local Unspecified | | |----------->| | | | |Add Phy Resp| | | | |Add Eph Resp Local Specified | | | |----------->| | | | | Add Phy | | | | | Add $ Local Unspecified | | | | Remote Specified | | | |<-----------| | | | |Add Phy Resp| | | | |Add Eph Resp Local Specified | | |<-----------| | | | |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 | | | | |<-----------| | | | |Sub Phy Resp| | | | |Sub Eph Resp Statistics | |____________|____________|____________|________________| Madhubabu, et al. Informational - Expires April 2005 [Page 95] Internet-Draft Megaco/H.248 Call flow examples November2004 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 an embedded signal seizeack to be applied after detection of seize event. The embedded signal is accompanied by another embedded event descriptor with the clear event to detect the clear forward signal when 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 notified to the MGC. The R1TGW meanwhile does the embedded descriptor processing for the seize event and 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 R1TGW to MGC: MEGACO/1 [209.110.59.34]:25000 Madhubabu, et al. Informational - Expires April 2005 [Page 96] Internet-Draft Megaco/H.248 Call flow examples November2004 Transaction = 2000 { Context = - { Notify = Trunk1/line1 {ObservedEvents =1111 { 20010202T10000000:R1/sz}} } } the MGC responds the Notify command with the Notify response. Step 4 MGC to R1TGW: 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. Step 5 R1TGW to MGC: MEGACO/1 [209.110.59.34]:25000 Transaction = 2001 { Context = - { Notify = Trunk1/line1 {ObservedEvents =1112 { 20010302T10000000:mfd/ce{ds=2992}} } } the MGC responds to the Notify command with a Notify response. Step 6 MGC to R1TGW: MEGACO/1 [216.33.33.61]: 27000 Reply = 2001 { Context = - {Notify = Trunk1/line1} } The MGC then instructs the Signaling Gateway to initiate the necessary signaling towards the exchange to which the destination user is connected. In this example the MGC has to instruct the Signaling Gateway to generate SS7 messages towards the SS7 switch. The IAM (Initial Address Message) is sent with all the necessary address signaling information. In this example assume that the peer SS7 switch sends back a CON (Connect) message after receiving the IAM message as we have assumed the called party to be an automatic answering terminal for simpliity. The MGC sends a Modify command towards the R1 TGW to indicate that the called party has Madhubabu, et al. Informational - Expires April 2005 [Page 97] Internet-Draft Megaco/H.248 Call flow examples November2004 gone offhook. The answer signal is sent in the Signals descriptor. Step 7 MGC to R1TGW 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 R1TGW to MGC: MEGACO/1 [209.110.59.34]: 25000 Reply = 1235 { Context = - { Modify = Trunk1/line1 } } After knowing that a CON message has been received the MGC generates commands towards both the trunking gateways to add physical circuits and create ephemeral terminations. The MGC in its message to the R1TGW lists the answer signal in the signal descriptor 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 } Madhubabu, et al. Informational - Expires April 2005 [Page 98] Internet-Draft Megaco/H.248 Call flow examples November2004 } } } } } After processing the ADD command the R1 Trunking gateway creates a new context with a context id 1 in this example. 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 o=- 2890844525 2890842816 IN IP4 209.110.59.34 s=- t= 00 c=IN IP4 209.110.59.33 m=audio 30000 RTP/AVP 4 } } ; RTP profile for G723 is 4 } } } After receving the response to the ADD command from the R1TGW, the MGC generates a similar transaction with two ADD commands towars the SS7TGW. The local SDP information specified in by the R1TGW is used as remote SDP information for SS7TGW. The MGC conveys this information in the Add command. Step 11 MGC to SS7TGW MEGACO/1 [216.33.33.61]: 27000 Transaction = 1237 { Context = $ { Add = Trunk2/line1 {Media { LocalControl {Mode = SendRecv}}, }, Madhubabu, et al. Informational - Expires April 2005 [Page 99] Internet-Draft Megaco/H.248 Call flow examples November2004 Add = $ {Media { LocalControl { Mode = Receiveonly, }, Local { v=0 c=IN IP4 $ m=audio $ RTP/AVP 4 } Remote{ v=0 o=- 2890844525 2890842816 IN IP4 209.110.59.34 s=- t= 00 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 remote SDP information. The response from the MG specifies the local SDP information. Step 12 SS7GW to MGC: MEGACO/1 [207.176.47.89]: 26000 Reply = 1237 { Context = 2 { Add = Trunk2/line1, Add = EphB{ Media { Local { v=0 o=- 2890844525 2890842816 IN IP4 207.176.47.89 s=- t= 00 c=IN IP4 207.176.47.90 m=audio 40000 RTP/AVP 4 } } ; RTP profile for G723 is 4 } } } Madhubabu, et al. Informational - Expires April 2005 [Page 100] Internet-Draft Megaco/H.248 Call flow examples November2004 The MGC after receiving the response generates a modify command to the R1TGW to inform the local SDP information of SS7TGW 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 o=- 2890844525 2890842816 IN IP4 207.176.47.89 s=- t= 00 c=IN IP4 207.176.47.90 m=audio 40000 RTP/AVP 4 } } } } } } The R1 Trunking gateway responds to the Modify command with the following reply Step 14 R1TGW to MGC: MEGACO/1 [207.176.47.89]: 26000 Reply = 1238 { Context = 1 { Modify = EphA } } The RTP media transfer can now t ake place. We assume that the user connected through the R1 signaling domain terminates the call. The clear forwards signal generated by the R1 exchange connected to the R1 TGW is detected and is reported to the MGC in the Notify command as the clear event in the H.248.25 package. As part of the embedded event descriptor processing at the R1TGW a clear back signal is played towards the peer R1 exchange. Madhubabu, et al. Informational - Expires April 2005 [Page 101] Internet-Draft Megaco/H.248 Call flow examples November2004 Step 15: R1TGW to MGC: MEGACO/1 [209.110.59.34]:25000 Transaction = 2002 { Context = 1 { Notify = TermA {ObservedEvents =1112 { 20010402T10030000:R1/clear} } } } The MGC responds to the R1TGWs Notify message with the following reply. Step 16 MGC to R1TGW: MEGACO/1 [216.33.33.61]:27000 Reply= 2002 { Context = 1 { Notify = TermA } } The MGC instructs the Signaling Gateway to generate a REL (Release) message towards the peer SS7 switch on receipt of which the peer generates a 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}} } } 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 Madhubabu, et al. Informational - Expires April 2005 [Page 102] Internet-Draft Megaco/H.248 Call flow examples November2004 nt/or=56789, ; octets received rtp/pl=10, ; % packets lost rtp/jit=30, rtp/delay=30 ; average latency } } } } The MGC generates a similar transaction with two Subtract commands for subtracting both the physical and ephemeral terminations from the SS7TGW. Step 19 MGC to SS7TGW: 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 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 performs R1 signaling and the other that performs the CCSSS7 signaling. In this example the user in the CCS SS7 signaling Madhubabu, et al. Informational - Expires April 2005 [Page 103] Internet-Draft Megaco/H.248 Call flow examples November2004 network originates the call. The destination user is connected to the PSTN network with R1 signaling. ______________________________________________________________________ | | | | SS7 Switch | SS7TGW | MGC | R1TGW | 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 | | | | | |<----------| | | | |Add Phy | | | | |Add $ Local (Unspecified) | | |---------->| | | | |Add Phy Resp | | | |Add Eph Resp | | | | |----------->| | | | |Add Phy | | | | |Add $ Local (Unspecified) | | | | Remote (Specified) | Madhubabu, et al. Informational - Expires April 2005 [Page 104] Internet-Draft Megaco/H.248 Call flow examples November2004 | | |<-----------| | | | |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| | | | |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 Madhubabu, et al. Informational - Expires April 2005 [Page 105] Internet-Draft Megaco/H.248 Call flow examples November2004 H.248.25 package. The signal descriptor has the seize signal and the event descriptor has the event seizeack. The seizeack event has an embeddeded signal "address". The Trunking gateway is instructed 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 peer 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 R1TGW to MGC: MEGACO/1 [209.110.59.34]:25000 Transaction = 2000 { Context = - { Notify = Trunk1/line1{ObservedEvents =1111 { 20010202T10000000:R1/sd}} Madhubabu, et al. Informational - Expires April 2005 [Page 106] Internet-Draft Megaco/H.248 Call flow examples November2004 } } the MGC responds the Notify command with the Notify response. Step 4 MGC to R1TGW: MEGACO/1 [216.33.33.61]: 27000 Reply = 2000 { Context = - {Notify = Trunk1/line1} } The MGC now instructs the Signaling Gateway to generate the ACM (address complete message) towards the SS7 switch that has generated the IAM message. The R1TGW, after receiving the answer event from the peer R1 exchange, generates message to notify this event. Step 5 R1TGW to MGC: MEGACO/1 [209.110.59.34]:25000 Transaction = 2001 { Context = - { Notify = Trunk1/line1{ObservedEvents =1112 { 20010202T10000000:R1/ans}} } } the MGC responds the Notify command with the Notify response. Step 6 MGC to R1TGW: MEGACO/1 [216.33.33.61]: 27000 Reply = 2001 { Context = - {Notify = Trunk1/line1} } MGC instructs the Signaling Gateway to generate the ANM (Answer) message towards the peer SS7 switch. It also generates commands to add terminations into specific contexts. It generates a single transaction with two Add commands towards the R1TGW. One command is to add the physical circuit group Trunk1/line and the other for the ephemeral termination. The SDP information is underspecified that instructs the TGW to choose the underspecified parameters. Step 7 MGC to R1TGW MEGACO/1 [216.33.33.61]: 27000 Madhubabu, et al. Informational - Expires April 2005 [Page 107] Internet-Draft Megaco/H.248 Call flow examples November2004 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 } } } } } } After processing the Add command the R1 Trunking creates a new context with a context id of 1 in this example. 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 o=- 2890844525 2890842816 IN IP4 209.110.59.34 s=- t= 00 c=IN IP4 209.110.59.33 m=audio 30000 RTP/AVP 4 } } ; RTP profile for G723 is 4 } } Madhubabu, et al. Informational - Expires April 2005 [Page 108] Internet-Draft Megaco/H.248 Call flow examples November2004 } After receiving the response to the ADD command from R1TGW, the MGC generates a similar transaction with two ADD commands towards the SS7TGW. The local SDP information specified by the R1TGW is used as remote SDP information for the SS7TGW. The MGC conveys this information in the ADD command. Step 9 MGC to SS7TGW MEGACO/1 [216.33.33.61]: 27000 Transaction = 1236{ Context = $ { Add = Trunk2/line1 {Media { LocalControl {Mode = SendRecv}}, }, Add = $ {Media { LocalControl { Mode = Receiveonly, }, Local { v=0 c=IN IP4 $ m=audio $ RTP/AVP 4 } Remote{ v=0 o=- 2890844525 2890842816 IN IP4 209.110.59.34 s=- t= 00 c=IN IP4 209.110.59.33 m=audio 30000 RTP/AVP 4 } } ; RTP profile for G723 is 4 } } } The SS7 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 SS7TGW to MGC: MEGACO/1 [207.176.47.89]: 26000 Reply = 123 6{ Context = 2 { Madhubabu, et al. Informational - Expires April 2005 [Page 109] Internet-Draft Megaco/H.248 Call flow examples November2004 Add = Trunk2/line1, Add = EphB{ Media { Local { v=0 o=- 2890844525 2890842816 IN IP4 207.176.47.89 s=- t= 00 c=IN IP4 207.176.47.90 m=audio 30000 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 11 MGC to R1TGW MEGACO/1 [216.33.33.61]: 27000 Transaction = 1237{ Context = 1 { Modify = EphA {Media { LocalControl { Mode = SendRecv, }, Remote{ v=0 o=- 2890844525 2890842816 IN IP4 207.176.47.89 s=- t= 00 c=IN IP4 207.176.47.90 m=audio 30000 RTP/AVP 4 } } } } } } The R1 Trunking gateway responds to the Modify command. Step 12 R1TGW to MGC: MEGACO/1 [209.110.59.34]: 25000 Madhubabu, et al. Informational - Expires April 2005 [Page 110] Internet-Draft Megaco/H.248 Call flow examples November2004 Reply = 1237{ Context = 1 { Modify = EphA } } The RTP media flow is established and the two users connected to the SS7 trunk and R1 trunk can start the conversation. After the end of the conversation any of the user can disconnect the call and in this example the user connected to the SS7 domain releases the call. The SS7 switch generates a REL message towards the MGC and the Signaling gateway forwards the same to 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 R1TGW: MEGACO/1 [216.33.33.61]: 27000 Transaction = 1238{ 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 } } Meanwhile the MGC generates the subtract message towards the originating SS7TGW to remove the terminations from the newly created context. Step 15 MGC to SS7TGW: Madhubabu, et al. Informational - Expires April 2005 [Page 111] Internet-Draft Megaco/H.248 Call flow examples November2004 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 SS7TGW 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 } } } } The MGC, after receiving the response from the SS7TGW, instructs the Signaling Gateway to generate the RLC (Release Complete) message towards the peer SS7 switch. The R1 TGW after receiving the clear back signal from the peer 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 {ObservedEvents =1113 { 20030202T10000000:R1/clear}} } } the MGC responds the Notify command with the Notify response. Step 18 Madhubabu, et al. Informational - Expires April 2005 [Page 112] Internet-Draft Megaco/H.248 Call flow examples November2004 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 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 SS7 and ISDN signaling respectively. In this example we assume that an ISDN user initiates that call. Madhubabu, et al. Informational - Expires April 2005 [Page 113] Internet-Draft Megaco/H.248 Call flow examples November2004 ______________________________________________________________________ | | | | ISDNSwitch | ISDNTGW/SG | MGC | SS7TGW/SG | SS7Switch ____________|____________|___________|______________|_________________ | | | | | |----------->| | | | | Setup |---------->| | | | | Setup | | | | | |----------->| | | | | IAM |--------------->| | | | | IAM | | | | |<---------------| | | |<-----------| ACM (User free)| | | | ACM (User free) | | |<----------| | | |<-----------| Alerting| | | | Alerting | | |<---------------| | | |<-----------| ANM | | |<----------| ANM | | |<-----------| Connect | | | | Connect |<----------| | | | |Add Phy | | | | |Add $ Local unspecfied | | |---------->| | | | |Add Phy Resp | | | |Add Eph Resp Local Specified | | | |----------->| | | | |Add Phy | | | | |Add $ Local Unspecified | | | | Remote Specified | | | |<-----------| | | | |Add Phy Resp| | | | |Add Eph Resp Local Specified| | |<----------| | | | |Modify EPh Remote Specified | | |---------->| | | | |Modify Eph Resp | | | |/----------------------\| | | | RTP MEDIA | | | |\----------------------/| | |----------->| | | | | Disconnect |---------->| | | | | Disconnect|----------->| | | | | REL |--------------->| | | | | REL | | | | |<---------------| | | |<-----------| RLC | | | | RLC | | Madhubabu, et al. Informational - Expires April 2005 [Page 114] Internet-Draft Megaco/H.248 Call flow examples November2004 | | |----------->| | | | |Sub Phy | | | | |Sub Eph | | | |<----------| | | | | Release | | | |<-----------| |<-----------| | | Release | |Sub Phy Resp| | | | |Sub Eph Resp Statistics | |----------->| | | | | Release Complete | | | | |---------->| | | | |Release Complete | | | |<----------| | | | |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 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. Informational - Expires April 2005 [Page 115] Internet-Draft Megaco/H.248 Call flow examples November2004 } } } } } } After receiving the ADD command the ISDN Trunking gateway creates a new context with context id 1 in this example. 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 SDP parameters are specified in the response. The IP address chosen for the media transport in this example is 207.176.47.90, 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 o=- 2890844525 2890842816 IN IP4 207.176.47.89 s=- t= 00 c=IN IP4 207.176.47.90 m=audio 30000 RTP/AVP 4 } } ; RTP profile for G723 is 4 } } } After receiving the response to the ADD command from the ISDN TGW the MGC generates a similar transaction with two ADD commands towards the SS7TGW. The local SDP information specified by the ISDNTGW is used as remote SDP information for the SS7TGW. The MGC conveys this information in the Add command. Step 3 MGC to SS7TGW MEGACO/1 [216.33.33.61]: 27000 Transaction = 1235{ Context = $ { Add = Trunk2/line1 {Media { LocalControl {Mode = SendRecv}}, Madhubabu, et al. Informational - Expires April 2005 [Page 116] Internet-Draft Megaco/H.248 Call flow examples November2004 }, Add = $ {Media { LocalControl { Mode = Receiveonly, }, Local { v=0 c=IN IP4 $ m=audio $ RTP/AVP 4 } Remote{ v=0 o=- 2890844525 2890842816 IN IP4 207.176.47.89 s=- t= 00 c=IN IP4 207.176.47.90 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 SS7TGW to MGC: MEGACO/1 [207.176.44.44]: 26000 Reply = 1235{ Context = 2 { Add = Trunk2/line1, Add = EphB{ Media { Local { v=0 o=- 2890844525 2890842816 IN IP4 207.176.44.44 s=- t= 00 c=IN IP4 207.176.44.45 m=audio 30000 RTP/AVP 4 } } ; RTP profile for G723 is 4 } } Madhubabu, et al. Informational - Expires April 2005 [Page 117] Internet-Draft Megaco/H.248 Call flow examples November2004 } The MGC, after receiving the response, generates a modify command to the ISDNTGW to inform the local SDP information of SS7TGW as the remote SDP for the ISDNTGW. Step 5 MGC to ISDNTGW MEGACO/1 [216.33.33.61]: 27000 Transaction = 1236{ Context = 1 { Modify = EphA {Media { LocalControl { Mode = SendRecv, }, Remote{ v=0 o=- 2890844525 2890842816 IN IP4 207.176.44.44 s=- t= 00 c=IN IP4 207.176.44.45 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 now established and the connected parties can now start the conversation. After completing the conversation the call can be terminated either by the ISDN user or by the user connected to the 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. Madhubabu, et al. Informational - Expires April 2005 [Page 118] Internet-Draft Megaco/H.248 Call flow examples November2004 Step 7 MGC to ISDNTGW: MEGACO/1 [216.33.33.61]: 27000 Transaction = 1237{ Context = 1 { Subtract = Trunk1/line1{Audit{ }}, Subtract = EphA {Audit{Statistics}} } } 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 SS7TGW that terminates SS7 media trunks. Step 9 MGC to SS7TGW: 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 TGW2 to MGC: MEGACO/1 [209.110.44.44]:26000 Madhubabu, et al. Informational - Expires April 2005 [Page 119] Internet-Draft Megaco/H.248 Call flow examples November2004 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, rtp/delay=30 ; average latency } } } } 2.12 Continuity test from TGW In this section we will illustrate the usage of Megaco commands for performing continuity tests. The basic continuity package as defined in the protocol is used here. 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. In both the scenarios the MG responds to the messages from the MGC. But how the MGC communicates with other MGCs or Switches is outside the scope of this draft. Case (a) __________________________________________________________________ | MG | MGC _______________________________|___________________________________ | | |<----------------------------------| | Modify TermA SD:ct/ct ED:ct/cmp state=test |---------------------------------->| | Modify TermA Resp | <------------| | Continuity Signal | | | ------------>| | Continuity Signal Resp | Madhubabu, et al. Informational - Expires April 2005 [Page 120] Internet-Draft Megaco/H.248 Call flow examples November2004 |---------------------------------->| | Notify TermA OE:ct/cmp {resp=success} |<----------------------------------| | Notify TermA Resp | _____________|___________________________________|__________________ The case of originating the 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 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 starts 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 starts waiting to detect 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 Madhubabu, et al. Informational - Expires April 2005 [Page 121] Internet-Draft Megaco/H.248 Call flow examples November2004 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 TGW with the following response. Step 4 MGC to TGW: MEGACO/1 [216.33.33.61]: 27000 Reply = 2000 { Context = - {Notify = Trunk1/line1} } Case (b) In the previous 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 | _____________|___________________________________|__________________ Madhubabu, et al. Informational - Expires April 2005 [Page 122] Internet-Draft Megaco/H.248 Call flow examples November2004 The continuity package signal "rsp" is used for this purpose. The signal duration and frequency are provisioned at the TGW. When the MGC is requested by a PSTN switch to respond for the continuity test, it 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 Transactio n = 1234 { Context = '-' { Modify = Trunk1/line1 {Media { TerminationState {ServiceState = test} LocalControl { mode = loopback} } Signals = { ct/rsp } } } } There can be two possible cases for responding to the continuity test originated from the PSTN network. In the first case the Trunking Gateway generates a signal whose frequency is different from the frequency of the received signal and in the second case it loops back the received signal to the switch that originated it. In 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 or failure of the continuity test by 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 Madhubabu, et al. Informational - Expires April 2005 [Page 123] Internet-Draft Megaco/H.248 Call flow examples November2004 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 | | | | |------------------>| | | | ARQ | | | |<------------------| | | | ACF | | | |------------------------------------>| | | Setup | | | |<----------------| | | | ARQ | | | |---------------->| | | | ACF | | |<------------------------------------| | | Alerting | |<--------------| | | |Add Phy | | | |Add $ Local Unspecified | | <------| | | | RingBack tone | | | |-------------->| | | |Add Phy Resp | | | |Add Eph Resp Local Specified | | | |<------------------------------------| | | Connect | | |<----------------------------------->| Madhubabu, et al. Informational - Expires April 2005 [Page 124] Internet-Draft Megaco/H.248 Call flow examples November2004 | | 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 | | Busy Tone |<----------------------------------->| | | CLC SessionId = 2 | |-------------->| | | | Modify Resp | | | | |<------------------------------------| | | Release Complete | | |------------------>| | | | DRQ |<----------------| |<--------------| | DRQ | |Sub Phy |<------------------|---------------->| |Sub Eph Stats | DCF | DCF | _______|_______________|___________________|_________________|_______ The MGC generates modify command towards the residential gateway to check for offhook event on 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 { Madhubabu, et al. Informational - Expires April 2005 [Page 125] Internet-Draft Megaco/H.248 Call flow examples November2004 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 detected 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 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: Madhubabu, et al. Informational - Expires April 2005 [Page 126] Internet-Draft Megaco/H.248 Call flow examples November2004 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 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. After receiving the Admission confirmation message from the Gatekeeper, it 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 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 { Madhubabu, et al. Informational - Expires April 2005 [Page 127] Internet-Draft Megaco/H.248 Call flow examples November2004 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 o=- 2890844525 2890842816 IN IP4 209.110.59.34 s=- t= 00 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. Informational - Expires April 2005 [Page 128] Internet-Draft Megaco/H.248 Call flow examples November2004 } 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 OLC message exchange process 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 o=- 2890844525 2890842816 IN IP4 209.110.59.34 s=- t= 00 c=IN IP4 209.110.59.33 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: MEGACO/1 [207.176.47.89]: 26000 Madhubabu, et al. Informational - Expires April 2005 [Page 129] Internet-Draft Megaco/H.248 Call flow examples November2004 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 = 1237 { 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 RGW to MGC: MEGACO/1 [207.176.47.89]: 26000 Reply = 1237 { Context = 1 { Modify= TermA, Modify = EphA} } After hearing the busy tone lets assume that the User A goes on hook. This event is notified to the MGC through a NOTIFY message. Step 13: Madhubabu, et al. Informational - Expires April 2005 [Page 130] Internet-Draft Megaco/H.248 Call flow examples November2004 RGW to MGC: MEGACO/1 [209.110.59.34]:25000 Transaction = 2002 { Context = 1 { Notify = TermA {ObservedEvents =1235{ 20010202T10030000:al/on} } } The MGC responds to the RGWs Notify message. Step 14 MGC to RGW: 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 it subtracts the physical and ephemeral termination at the Residential gateway. After this the user is free to participate in any further calls. Step 15 MGC to RGW MEGACO/1 [216.33.33.61]: 27000 Transacti on = 1237 { 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 = 1237 { Context = 1 { Subtract = TermA Subtract = EphA { Statistics { rtp/ps=1234, ; packets sent nt/os=56789, ; octets sent Madhubabu, et al. Informational - Expires April 2005 [Page 131] Internet-Draft Megaco/H.248 Call flow examples November2004 rtp/pr=987, ; packets received nt/or=65432, ; octets received rtp/pl=10, ; % packets lost rtp/jit=30, rtp/delay=30 ; average latency } } } } 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 Local Unspecified | | Remote SPecified | Madhubabu, et al. Informational - Expires April 2005 [Page 132] Internet-Draft Megaco/H.248 Call flow examples November2004 |-------------------->| | | Add Phy Resp | | | Add Eph Local Specified | <------| | | RingBack Tone | | | |------------------------>| | | ACK (SDP Specified) | |/---------------------------------------------\| | RTP Media | |\---------------------------------------------/| ------>| | | 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}}} } Madhubabu, et al. Informational - Expires April 2005 [Page 133] Internet-Draft Megaco/H.248 Call flow examples November2004 } } 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 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}}} } } Madhubabu, et al. Informational - Expires April 2005 [Page 134] Internet-Draft Megaco/H.248 Call flow examples November2004 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 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 Residentia l 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 } } Madhubabu, et al. Informational - Expires April 2005 [Page 135] Internet-Draft Megaco/H.248 Call flow examples November2004 } } 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 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 { { Madhubabu, et al. Informational - Expires April 2005 [Page 136] Internet-Draft Megaco/H.248 Call flow examples November2004 LocalControl { Mode = sendrecv, }, } Add = $ { Media { { LocalControl { Mode = sendrecv, }, Local { v=0 c=IN IP4 $ m=audio $ RTP/AVP 4 } Remote{ 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 } } } } } 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 o=- 2890844525 2890842816 IN IP4 209.110.59.34 s=- Madhubabu, et al. Informational - Expires April 2005 [Page 137] Internet-Draft Megaco/H.248 Call flow examples November2004 t= 00 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 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: Madhubabu, et al. Informational - Expires April 2005 [Page 138] Internet-Draft Megaco/H.248 Call flow examples November2004 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 { 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 { Madhubabu, et al. Informational - Expires April 2005 [Page 139] Internet-Draft Megaco/H.248 Call flow examples November2004 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 MGC accepting registration. The MEGACO protocol defines 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 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 |------------------------------------>| Madhubabu, et al. Informational - Expires April 2005 [Page 140] Internet-Draft Megaco/H.248 Call flow examples November2004 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 the 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} } } } 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). Madhubabu, et al. Informational - Expires April 2005 [Page 141] Internet-Draft Megaco/H.248 Call flow examples November2004 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 MGC rejecting registration. 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 reply, with not including a ServiceChangeMgcId parameter. If the MG receives an ServiceChangeMgcId , it sends a ServiceChange to the MGC specified in the ServiceChangeMgcId. In this example the MG generate a registration command towards the secondary MGC (This MGC may not be a Madhubabu, et al. Informational - Expires April 2005 [Page 142] Internet-Draft Megaco/H.248 Call flow examples November2004 pre-provisioned 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=216.33.33.62:27000 | |---------------------------------------------->| | 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 Madhubabu, et al. Informational - Expires April 2005 [Page 143] Internet-Draft Megaco/H.248 Call flow examples November2004 Reply = 1234 { Context = - {ServiceChange = ROOT { Services {mgcid=216.33.33.62:27000, 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]: 20000 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 Reply = 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 Madhubabu, et al. Informational - Expires April 2005 [Page 144] Internet-Draft Megaco/H.248 Call flow examples November2004 MG subsequently generates the handoff message to the MGC specified in the Service change mgId in the message generated by the controlling MGC. ____________________________________________________________________ | | 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 Madhubabu, et al. Informational - Expires April 2005 [Page 145] Internet-Draft Megaco/H.248 Call flow examples November2004 Reply = 1234 { Context = - { ServiceChange = ROOT } } 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. Madhubabu, et al. Informational - Expires April 2005 [Page 146] Internet-Draft Megaco/H.248 Call flow examples November2004 _______________________________________________________________________ | Media Gateway | Media Gateway Controller ___________________________________|___________________________________ | : | | : | | : | | MG lost communication with MGC | | | |------------------------------------>| |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 Madhubabu, et al. Informational - Expires April 2005 [Page 147] Internet-Draft Megaco/H.248 Call flow examples November2004 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: 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 o=- 2890844525 2890842816 IN IP4 209.110.59.34 s=- t= 00 c=IN IP4 209.110.59.33 m=audio 30000 RTP/AVP 0 a=ptime:30 }, Remote { v=0 o=- 2890844525 2890842816 IN IP4 209.110.44.44 Madhubabu, et al. Informational - Expires April 2005 [Page 148] Internet-Draft Megaco/H.248 Call flow examples November2004 s=- t= 00 c=IN IP4 209.110.44.45 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 } } } 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) _______________________________________________________________________ | Madhubabu, et al. Informational - Expires April 2005 [Page 149] Internet-Draft Megaco/H.248 Call flow examples November2004 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 | _____________|_____________________________________|____________________ Step 1 MG to MGC: MEGACO/1 [216.33.33.61]: 25000 Transaction = 4321 { Context = 123 { ServiceChange = TermA {Services { Method=Graceful, Reason="905 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 { Madhubabu, et al. Informational - Expires April 2005 [Page 150] Internet-Draft Megaco/H.248 Call flow examples November2004 } } } 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. 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 Madhubabu, et al. Informational - Expires April 2005 [Page 151] Internet-Draft Megaco/H.248 Call flow examples November2004 ___________________________________|___________________________________ | | | | |------------------------------------>| |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 { 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 { } Madhubabu, et al. Informational - Expires April 2005 [Page 152] Internet-Draft Megaco/H.248 Call flow examples November2004 } } 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 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 ___________________________________|___________________________________ Madhubabu, et al. Informational - Expires April 2005 [Page 153] Internet-Draft Megaco/H.248 Call flow examples November2004 | | | | |------------------------------------>| |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: 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 Madhubabu, et al. Informational - Expires April 2005 [Page 154] Internet-Draft Megaco/H.248 Call flow examples November2004 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. _______________________________________________________________________ | Media Gateway | Media Gateway Controller ___________________________________|___________________________________ | | | | |------------------------------------>| |ServiceChange CtxId=NULL TermA | | Method = Forced | Madhubabu, et al. Informational - Expires April 2005 [Page 155] Internet-Draft Megaco/H.248 Call flow examples November2004 | | |<------------------------------------| | 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. 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. _______________________________________________________________________ | Madhubabu, et al. Informational - Expires April 2005 [Page 156] Internet-Draft Megaco/H.248 Call flow examples November2004 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 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 Madhubabu, et al. Informational - Expires April 2005 [Page 157] Internet-Draft Megaco/H.248 Call flow examples November2004 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. Informational - Expires April 2005 [Page 158] Internet-Draft Megaco/H.248 Call flow examples November2004 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 Madhubabu, et al. Informational - Expires April 2005 [Page 159] Internet-Draft Megaco/H.248 Call flow examples November2004 Reply = 4321 { Context = - { ServiceChange = TermA { } } } 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 { } } Madhubabu, et al. Informational - Expires April 2005 [Page 160] Internet-Draft Megaco/H.248 Call flow examples November2004 } } The MG after receiving the command from MGC constructs the response with all the contextID that is active in that MG. Step 2 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 { Madhubabu, et al. Informational - Expires April 2005 [Page 161] Internet-Draft Megaco/H.248 Call flow examples November2004 Context = - { AuditValue= ROOT Media { TerminationState{ MaxNumberOfContexts = 100, MaxTerminationsPerContext = 2, NormalMGExecutionTime = 1000, NormalMGCExecutionTime = 1000, ProvisionalResponseTimerValue=1000, } 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 { Madhubabu, et al. Informational - Expires April 2005 [Page 162] Internet-Draft Megaco/H.248 Call flow examples November2004 Media { TerminationState { ServiceState = InService, Buffer = OFF }, Stream = 1 { LocalControl { Mode = SendReceive, nt/jit=40 }, Local { v=0 o=- 2890844525 2890842816 IN IP4 209.110.59.34 s=- t= 00 c=IN IP4 209.110.59.33 m=audio 30000 RTP/AVP 0 a=ptime:30 }, Remote { v=0 o=- 2890844525 2890842816 IN IP4 207.176.47.89 s=- t= 00 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}, Sta tistics { 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{ Madhubabu, et al. Informational - Expires April 2005 [Page 163] Internet-Draft Megaco/H.248 Call flow examples November2004 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.)} } } } 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 Madhubabu, et al. Informational - Expires April 2005 [Page 164] Internet-Draft Megaco/H.248 Call flow examples November2004 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: 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, Madhubabu, et al. Informational - Expires April 2005 [Page 165] Internet-Draft Megaco/H.248 Call flow examples November2004 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 _____________|___________|___________|__________________ | | | | | | | | | |<----------| | | |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| | | | | | Madhubabu, et al. Informational - Expires April 2005 [Page 166] Internet-Draft Megaco/H.248 Call flow examples November2004 |----------->| | | |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 | |\----------------------------------/| |____________|___________| ___________| 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 = - { Madhubabu, et al. Informational - Expires April 2005 [Page 167] Internet-Draft Megaco/H.248 Call flow examples November2004 Modify = TermA { Media { LocalControl { Mode = ReceiveOnly} } , Events = 1111 {al/of { Signals {cg/dt},Embed { Events = 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 { 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 Madhubabu, et al. Informational - Expires April 2005 [Page 168] Internet-Draft Megaco/H.248 Call flow examples November2004 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 MGC to MG1: MEGACO/1 [216.33.33.61]: 27000 Transaction = 1235 { Context = $ { Add = TermA { Signals { cg/rt } } Add = $ { Media { { LocalControl { Mode = ReceiveOnly, Madhubabu, et al. Informational - Expires April 2005 [Page 169] Internet-Draft Megaco/H.248 Call flow examples November2004 }, 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 o=- 2890844525 2890842816 IN IP4 209.110.59.34 s=- t= 00 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 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 Madhubabu, et al. Informational - Expires April 2005 [Page 170] Internet-Draft Megaco/H.248 Call flow examples November2004 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 o=- 2890844525 2890842816 IN IP4 209.110.59.34 s=- t= 00 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. Informational - Expires April 2005 [Page 171] Internet-Draft Megaco/H.248 Call flow examples November2004 MEGACO/1 [207.176.47.89]: 26000 Reply = 1236 { Context = 2 { Add = EphB{ Media { Local { v=0 o=- 2890844525 2890842816 IN IP4 207.176.47.89 s=- t= 00 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} } } S ignals { } }, Modify = EphA { Media { LocalControl { Mode = sendrecv} Remote { v=0 o=- 2890844525 2890842816 IN IP4 207.176.47.89 s=- t= 00 c=IN IP4 207.176.47.90 m=audio 40000 RTP/AVP 4 } } ; RTP profile for G723 is 4 Madhubabu, et al. Informational - Expires April 2005 [Page 172] Internet-Draft Megaco/H.248 Call flow examples November2004 } } } } 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 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 Madhubabu, et al. Informational - Expires April 2005 [Page 173] Internet-Draft Megaco/H.248 Call flow examples November2004 | | |---------->| | | |Subtract EphB | | |<----------| | | |Subtract Resp EphB Statistics |____________|___________|___________| Step 1 MG2 to MGC: MEGACO/1 [207.176.47.89]: 26000 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 { Madhubabu, et al. Informational - Expires April 2005 [Page 174] Internet-Draft Megaco/H.248 Call flow examples November2004 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 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 } } } } Madhubabu, et al. Informational - Expires April 2005 [Page 175] Internet-Draft Megaco/H.248 Call flow examples November2004 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 | | |<-----------------------| | | 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 Signali ng 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. Madhubabu, et al. Informational - Expires April 2005 [Page 176] Internet-Draft Megaco/H.248 Call flow examples November2004 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 } } } } } } 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 207.176.47.90, 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 o=- 2890844525 2890842816 IN IP4 207.176.47.89 s=- t= 00 c=IN IP4 207.176.47.90 m=audio 30000 RTP/AVP 4 } } ; RTP profile for G723 is 4 } Madhubabu, et al. Informational - Expires April 2005 [Page 177] Internet-Draft Megaco/H.248 Call flow examples November2004 } } 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 } Remote{ v=0 o=- 2890844525 2890842816 IN IP4 207.176.47.89 s=- t= 00 c=IN IP4 207.176.47.90 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.44.44]: 26000 Reply = 1235 { Context = 2 { Add = EphB{ Media { Local { v=0 Madhubabu, et al. Informational - Expires April 2005 [Page 178] Internet-Draft Megaco/H.248 Call flow examples November2004 o=- 2890844525 2890842816 IN IP4 207.176.44.44 s=- t= 00 c=IN IP4 207.176.44.45 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 o=- 2890844525 2890842816 IN IP4 207.176.44.44 s=- t= 00 c=IN IP4 207.176.44.45 m=audio 30000 RTP/AVP 4 } } } } } } 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 } } Madhubabu, et al. Informational - Expires April 2005 [Page 179] Internet-Draft Megaco/H.248 Call flow examples November2004 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 |____________|___________|___________| 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{ }}, Madhubabu, et al. Informational - Expires April 2005 [Page 180] Internet-Draft Megaco/H.248 Call flow examples November2004 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 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 Madhubabu, et al. Informational - Expires April 2005 [Page 181] Internet-Draft Megaco/H.248 Call flow examples November2004 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}} 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 Madhubabu, et al. Informational - Expires April 2005 [Page 182] Internet-Draft Megaco/H.248 Call flow examples November2004 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 { Mode = ReceiveOnly} } , Events = 1111 {al/of { signals { cg / dt } , embed { event=1112 { al/on , dd/ce { dmap1} } } } } Madhubabu, et al. Informational - Expires April 2005 [Page 183] Internet-Draft Megaco/H.248 Call flow examples November2004 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. Informational - Expires April 2005 [Page 184] Internet-Draft Megaco/H.248 Call flow examples November2004 |Notify Response | | | |<----------------| | | |Modify ED:dd/ce{DigitMap=dmap1},al/on SD:cg/dt | <-----|---------------->| | | Dial | Modify Resp | | | Tone | | | | ------>| | | | Digits |---------------->| | | |Notify Digits | | | |<----------------| | | |Notify Response | | | |<----------------| | | | Add Phy | | | |Add $ Local Unspecified | | |---------------->| | | |Add Phy Resp | | | |Add Eph Resp Local specified | | | |-------------->| | | |Add Phy | | | |Add $ Local unspecified | | | Remote Specified | | |<--------------| | | | Add Phy Resp | | | | Add Eph Resp Local specified | |<----------------| | | |Modify ringback | | | <------|---------------->| | | ring | Modify Resp | | | back | | | | tone | | | | | |<--------------| | | |Notify OffHook | | | |-------------->| | | |Noti fy Resp | | | |-------------->| | | | Modify TermB mode=sendrecv | | | ED=al/fl, al/on | | | Modify EPhB mode=sendrecv | | |<--------------| | | | Modify Resp TermB | | | Modify Resp EphB | |<----------------| | | | Modify Eph Remote Specified | | |---------------->| | | | Modify Resp | | | |/-------------------------------\| | | RTP MEDIA | | |\-------------------------------/| | Madhubabu, et al. Informational - Expires April 2005 [Page 185] Internet-Draft Megaco/H.248 Call flow examples November2004 | |<--------------| | | | Notify Flash | | | |-------------->| | |<----------------| Notify Resp | | | Modify RecvOnly | --->| | |---------------->| DialTone| | | Modify Resp |<--------------| | | | Notify Digits | | | |-------------->| | | | Notify Resp | | | |-------------------------------->| | | Add Phy | | | Add $ Local Unspecified | | | Remote Specified | | |<--------------------------------| | | Add Phy Resp | | | Add Eph Resp Local Specified | |-------------->| | | | Modify TermB SD: cg/rt | | |<--------------| | | | Modify Resp TermB | | |<--------------------------------| | | Notify OffHook | | |-------------------------------->| | | Notify Resp | | |-------------------------------->| | | Modify TermC mode=sendrecv | | | Modify EphC mode=sendrecv | | |<--------------------------------| | | Modify Resp TermC | | | Modify Resp EphC | | |-------------->| | | | Modify Eph Remote | | |<--------------| | | | Modify Resp | | | | |/---------------\| | | | RTP Media | | | |\---------------/| | |<--------------| | | | Notify OnHook | | | |-------------->| | | | Notify Resp | | | |-------------->| | | | Sub Phy | | | | Sub Eph | | | |<--------------| | | | Sub Phy Resp | | | | Sub Eph Resp Statistics | Madhubabu, et al. Informational - Expires April 2005 [Page 186] Internet-Draft Megaco/H.248 Call flow examples November2004 | |-------------------------------->| | | Modify EphC Remote | | |<--------------------------------| | | Modify Eph Resp | |<----------------| | | | Modify EphA Remote | | |---------------->| | | | Modify RespEphA | | | |/-------------------------------------------------\| | RTP MEDIA | |\-------------------------------------------------/| |---------------->| | | | Notify OnHook | | | |---------------->| | | | Notify Resp | | | | |-------------------------------->| | | Modify Phy busyTone | | |<--------------------------------| | | Modify Resp | |<----------------| | | | 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 Madhubabu, et al. Informational - Expires April 2005 [Page 187] Internet-Draft Megaco/H.248 Call flow examples November2004 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} } } } 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 ge nerate 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}} Madhubabu, et al. Informational - Expires April 2005 [Page 188] Internet-Draft Megaco/H.248 Call flow examples November2004 } } 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 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, Madhubabu, et al. Informational - Expires April 2005 [Page 189] Internet-Draft Megaco/H.248 Call flow examples November2004 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}}} } } 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. 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. Madhubabu, et al. Informational - Expires April 2005 [Page 190] Internet-Draft Megaco/H.248 Call flow examples November2004 Step 9 MGC to MG1: MEGACO/1 [216.33.33.61]: 27000 Transaction = 1236 { Context = $ { Add = TermA { } 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 o=- 2890844525 2890842816 IN IP4 209.110.59.34 s=- t= 00 Madhubabu, et al. Informational - Expires April 2005 [Page 191] Internet-Draft Megaco/H.248 Call flow examples November2004 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 o=- 2890844525 2890842816 IN IP4 209.110.59.34 s=- t= 00 Madhubabu, et al. Informational - Expires April 2005 [Page 192] Internet-Draft Megaco/H.248 Call flow examples November2004 c=IN IP4 209.1 10.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 o=- 2890844525 2890842816 IN IP4 207.176.47.89 s=- t= 00 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 towards the originating RGW1, to generate ringback tone to the userA. After processing the command the RGW1 generates modify response to the MGC. 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. Madhubabu, et al. Informational - Expires April 2005 [Page 193] Internet-Draft Megaco/H.248 Call flow examples November2004 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 Embed { signals cg/dt, events =1235 { dd/ce{dmap1}, al/on }}}, Media { LocalControl { Mode = SendRecv, } } } Modify = EphB{ Media { LocalControl { Mode = SendRecv, } } } } Madhubabu, et al. Informational - Expires April 2005 [Page 194] Internet-Draft Megaco/H.248 Call flow examples November2004 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 o=- 2890844525 2890842816 IN IP4 207.176.47.89 s=- t= 00 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 Madhubabu, et al. Informational - Expires April 2005 [Page 195] Internet-Draft Megaco/H.248 Call flow examples November2004 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 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 MGC then generates a modify command to the UserA, to make the mode of the both physical and ephemeral terminations to recvonly so that there is no media between userA and UserB. 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 {ObservedEvents =1235 { Madhubabu, et al. Informational - Expires April 2005 [Page 196] Internet-Draft Megaco/H.248 Call flow examples November2004 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 embed { events = 1111 {{ al/on } }}} } Add = $ { Media { { LocalControl { Mode = ReceiveOnly, }, Local { v=0 c=IN IP4 $ m=audio $ RTP/AVP 4 } Remote { v=0 o=- 2890844525 2890842816 IN IP4 207.176.47.89 s=- t= 00 c=IN IP4 207.176.47.90 m=audio 40000 RTP/AVP 4 } Madhubabu, et al. Informational - Expires April 2005 [Page 197] Internet-Draft Megaco/H.248 Call flow examples November2004 } ; 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 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. 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 Reply = 1240 { Context = 3 { Add = TermC, Add=EphC{ Media { Local { v=0 o=- 2890844525 2890842816 IN IP4 209.110.59.35 s=- t= 00 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 { Madhubabu, et al. Informational - Expires April 2005 [Page 198] Internet-Draft Megaco/H.248 Call flow examples November2004 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 { 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 { Madhubabu, et al. Informational - Expires April 2005 [Page 199] Internet-Draft Megaco/H.248 Call flow examples November2004 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 ephemeral termination EphB of 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 = EphB { Media{ LocalControl{ mode = sendrecv }, Remote { v=0 o=- 2890844525 2890842816 IN IP4 209.110.59.35 s=- t= 00 c=IN IP4 192.168.0.160 m=audio 50000 RTP/AVP 4 } ; RTP profile for G.723 is 4 } } Madhubabu, et al. Informational - Expires April 2005 [Page 200] Internet-Draft Megaco/H.248 Call flow examples November2004 } } The RGW2 responds with the Modify response. Step 32 MG2 to MGC: MEGACO/1 [207.176.47.89]: 26000 Reply = 1243 { Context = 2 {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 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 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 { Madhubabu, et al. Informational - Expires April 2005 [Page 201] Internet-Draft Megaco/H.248 Call flow examples November2004 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} } } }, Modify = EphA { Media { LocalControl { Mode = sendrecv} Remote { v=0 o=- 2890844525 2890842816 IN IP4 209.110.59.35 Madhubabu, et al. Informational - Expires April 2005 [Page 202] Internet-Draft Megaco/H.248 Call flow examples November2004 s=- t= 00 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 { LocalCon trol { Mode = sendrecv} } } }, Modify = EphC { Media { LocalControl { Mode = sendrecv} Remote { v=0 o=- 2890844525 2890842816 IN IP4 209.110.59.34 s=- t= 00 c=IN IP4 209.110.59.33 m=audio 30000 RTP/AVP 4 } } ; RTP profile for G723 is 4 } Madhubabu, et al. Informational - Expires April 2005 [Page 203] Internet-Draft Megaco/H.248 Call flow examples November2004 } } } 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 { Madhubabu, et al. Informational - Expires April 2005 [Page 204] Internet-Draft Megaco/H.248 Call flow examples November2004 Context = 3 { Modify = TermC { 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: Madhubabu, et al. Informational - Expires April 2005 [Page 205] Internet-Draft Megaco/H.248 Call flow examples November2004 MEGACO/1 [209.110.59.34]:25000 Reply = 1248 { 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 } } } } 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}} } Madhubabu, et al. Informational - Expires April 2005 [Page 206] Internet-Draft Megaco/H.248 Call flow examples November2004 } 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 { 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| | | |-------------------------------->| Madhubabu, et al. Informational - Expires April 2005 [Page 207] Internet-Draft Megaco/H.248 Call flow examples November2004 | | Initial Modify | |---------------->|<--------------| | |Modify Response | Modify Resp | | | |<--------------------------------| | | Modify Response | |---------------->| | | | Notify OffHook | | | |<----------------| | | |Notify Response | | | |<----------------| | | |Modify ED:dd/ce{DmapName=dmap1},al/on SD:cg/dt | <-----|---------------->| | | Dial | Modify Resp | | | Tone | | | | ------>| | | | Digits |---------------->| | | |Notify Digits | | | |<----------------| | | |Notify Response | | | |<----------------| | | | Add Phy | | | |Add $ Loca l Unspecified | | |---------------->| | | |Add Phy Resp | | | |Add EphAResp Local specified | | | |-------------->| | | |Add Phy | | | |Add $ Local unspecified | | | Remote Specified | | |<--------------| | | | Add Phy Resp | | | | Add Eph Resp Local specified | |<----------------| | | | Modify TermA SD: cg/rt | | <------| | | | ring back tone | | | |---------------->| | | | Modify RespTermA|<--------------| | | | Notify TermB offhook | | |-------------->| | | |Notify resp TermB | | |-------------->| | | | Modify TermB mode=sendrecv | | | Modify EphB mode=sendrecv | | |<--------------| | | | Modify Resp TermB | | | Modify Resp EphB | | Modify Resp TermA | | Madhubabu, et al. Informational - Expires April 2005 [Page 208] Internet-Draft Megaco/H.248 Call flow examples November2004 |<----------------| | | | Modify Eph Remote Specified | | |---------------->| | | | Modify Resp | | | |/-------------------------------\| | | RTP MEDIA | | |\-------------------------------/| | | |<--------------------------------| | | Notify OffHook | | |<--------------------------------| | | Notify Resp | | |<--------------------------------| | | Notify Digits | | |-------------------------------->| | | Notify Response | | |-------------------------------->| | | Add Phy SD:cg/rt | | | Add $ Local Unspecified| | | Remote Specified | | |<--------------------------------| | | Add Phy Resp | | | Add Eph Resp Local SPecified | |-------------->| | | |Modify SD:callwaiting tone | | |<--------------| | | |Modify Resp | | | |<--------------| | | | Notify Flash | | |<----------------| | | |Modify Eph recvonly | | | |-------------->| | | | Notify Resp | | |---------------->| | | | Modify Resp |-------------->| | | | Modify Eph | | | |<--------------| | | | ModifyEphBResp|/---------------\| | | | RTP MEDIA | | | |\---------------/| | |<--------------------------------| | | Notify OnHook | | |-------------------------------->| | | Notify Resp | | |-------------->| | | | Modify SD:cg/bt | | |<--------------| | | | Modify Resp | | | |<--------------| | Madhubabu, et al. Informational - Expires April 2005 [Page 209] Internet-Draft Megaco/H.248 Call flow examples November2004 | | 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 | | | |-------------->| | | | 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 Madhubabu, et al. Informational - Expires April 2005 [Page 210] Internet-Draft Megaco/H.248 Call flow examples November2004 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} } 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}} } } Madhubabu, et al. Informational - Expires April 2005 [Page 211] Internet-Draft Megaco/H.248 Call flow examples November2004 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 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 Madhubabu, et al. Informational - Expires April 2005 [Page 212] Internet-Draft Megaco/H.248 Call flow examples November2004 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 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 Madhubabu, et al. Informational - Expires April 2005 [Page 213] Internet-Draft Megaco/H.248 Call flow examples November2004 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 o=- 2890844525 2890842816 IN IP4 209.110.59.34 s=- t= 00 Madhubabu, et al. Informational - Expires April 2005 [Page 214] Internet-Draft Megaco/H.248 Call flow examples November2004 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 o=- 2890844525 2890842816 IN IP4 209.110.59.34 s=- t= 00 Madhubabu, et al. Informational - Expires April 2005 [Page 215] Internet-Draft Megaco/H.248 Call flow examples November2004 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 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 o=- 2890844525 2890842816 IN IP4 207.176.47.89 s=- t= 00 c=IN IP4 207.176.47.90 m=audio 40000 RTP/AVP 4 } } ; RTP profile for G723 is 4 } } } The MGC after recieving the ADD response from RGW2, generates Modify command towards RGW1, to generate ring back tone to the user. The RGW1 after processing the command generates Modify response to the MGC. 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. Madhubabu, et al. Informational - Expires April 2005 [Page 216] Internet-Draft Megaco/H.248 Call flow examples November2004 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 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. Madhubabu, et al. Informational - Expires April 2005 [Page 217] Internet-Draft Megaco/H.248 Call flow examples November2004 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: 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 o=- 2890844525 2890842816 IN IP4 207.176.47.89 s=- t= 00 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 Madhubabu, et al. Informational - Expires April 2005 [Page 218] Internet-Draft Megaco/H.248 Call flow examples November2004 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}} } } 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)} Madhubabu, et al. Informational - Expires April 2005 [Page 219] Internet-Draft Megaco/H.248 Call flow examples November2004 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 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 termin ation 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. Madhubabu, et al. Informational - Expires April 2005 [Page 220] Internet-Draft Megaco/H.248 Call flow examples November2004 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/on}, }, Add = $ {Media { LocalControl { Mode = Receiveonly, }, Local { v=0 c=IN IP4 $ m=audio $ RTP/AVP 4 }, Remote { v=0 o=- 2890844525 2890842816 IN IP4 207.176.47.89 s=- t= 00 c=IN IP4 207.176.47.90 m=audio 40000 RTP/AVP 4 } ; RTP profile for G.723 is 4 } } } } } MG3 after receiving the new transaction from MGC starts processing it. It creates a new context with contextID 3. It adds the physical termination TermC 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 MG3 reserves IP address 192.168.0.160 and port number 50000. The MG3 responds to MGC with the following transaction reply. Step 26 Madhubabu, et al. Informational - Expires April 2005 [Page 221] Internet-Draft Megaco/H.248 Call flow examples November2004 MG3 to MGC: MEGACO/1 [209.110.60.35]: 25000 Reply = 1241 { Context = 3 { Add = TermC, Add = EphC{ Media { Local { v=0 o=- 2890844525 2890842816 IN IP4 209.110.60.35 s=- t= 00 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}, } } 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. Madhubabu, et al. Informational - Expires April 2005 [Page 222] Internet-Draft Megaco/H.248 Call flow examples November2004 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. Even though not shown explicitly a message is sent to UserA to set the modes of both physical and ephemeral terminations to recvonly, thus ensuring that EphA remote descriptor even tough pointing to UserB, doesnt generate any media. 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} } } Signals { } }, Modify = EphB { Media { LocalControl { Mode = sendrecv} Madhubabu, et al. Informational - Expires April 2005 [Page 223] Internet-Draft Megaco/H.248 Call flow examples November2004 Remote { v=0 o=- 2890844525 2890842816 IN IP4 209.110.60.35 s=- t= 00 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. Informational - Expires April 2005 [Page 224] Internet-Draft Megaco/H.248 Call flow examples November2004 } } } 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{ }}, Madhubabu, et al. Informational - Expires April 2005 [Page 225] Internet-Draft Megaco/H.248 Call flow examples November2004 Subtract = EphC {Audit{Statistics}} } } 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} } Madhubabu, et al. Informational - Expires April 2005 [Page 226] Internet-Draft Megaco/H.248 Call flow examples November2004 } } } } The MG2 responds to this modify request. 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 =1235 { 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 { Madhubabu, et al. Informational - Expires April 2005 [Page 227] Internet-Draft Megaco/H.248 Call flow examples November2004 Mode = sendrecv} } } Signals { } }, Modify = EphB { Media { LocalControl { Mode = sendrecv} Remote { v=0 o=- 2890844525 2890842816 IN IP4 209.110.59.34 s=- t= 00 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} } } Madhubabu, et al. Informational - Expires April 2005 [Page 228] Internet-Draft Megaco/H.248 Call flow examples November2004 } 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 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} } Madhubabu, et al. Informational - Expires April 2005 [Page 229] Internet-Draft Megaco/H.248 Call flow examples November2004 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. 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 { Madhubabu, et al. Informational - Expires April 2005 [Page 230] Internet-Draft Megaco/H.248 Call flow examples November2004 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 = 3003 { 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 { 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. Madhubabu, et al. Informational - Expires April 2005 [Page 231] Internet-Draft Megaco/H.248 Call flow examples November2004 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 | |---------------->|<--------------| | |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 | | | |<----------------| | | | Add Phy | | | |Add $ Local Unspecified | | | | | | | | | | |---------------->| | | |Add Phy Resp | | | |Add EphAResp Local specified | | Madhubabu, et al. Informational - Expires April 2005 [Page 232] Internet-Draft Megaco/H.248 Call flow examples November2004 | |-------------->| | | |Add TermB SD: cg/ri | | |Add $ Local unspecified Remote Specified | |-------------->| | | | Add Phy Resp | | | |Add EphB Resp Local Specified | |<----------------| | | | Modify TermA SD: cg/rt | | <------|---------------->| | | ring | Modify TermA Resp | | back | |<--------------| | tone | | Notify TermB OE:offhook | | |-------------->| | | |Notify Resp TermB | |<----------------| | | | Modify EphA Remote Specified | | |---------------->| | | | Modify Resp | | | |/-------------------------------\| | | RTP MEDIA | | |\-------------------------------/| | | |<--------------| | | | Notify Flash | | | |-------------->| | |<----------------| Notify Resp | | | Modify RecvOnly | ---------->| | |---------------->| DialTone | | | Modify Resp |<--------------| | | | Notify Digits | | | |-------------->| | | | Notify Resp | | | |-------------------------------->| | | Add TermC | | | Add $ Local Unspecified Remote Specified | |<--------------------------------| | | Add Phy Resp Add EphC Resp Local Specified | |-------------->| | | | Modify Ringback tone | | |<--------------| | | | Modify Resp | | | |<--------------------------------| | | Notify OffHook | | |-------------------------------->| | | Notify Resp | | |-------------->| | | | Modify EphBRemote | | |<--------------| | | | Modify EphB Resp | Madhubabu, et al. Informational - Expires April 2005 [Page 233] Internet-Draft Megaco/H.248 Call flow examples November2004 | |/-------------------------------\| | | RTP Media | | |\-------------------------------/| | |<--------------| | | | Notify Flash | | | |-------------->| | | | Notify Resp | | |<----------------| | | | Add $ Local unspecified | | |---------------->| | | | Add EphD Resp | | | | |-------------------------------->| | | Add $ Local unspecified. Remote specified | |<--------------------------------| | | Add EphF Resp Local specified |<----------------| | | | Mod EphD Remote specified | | |---------------->| | | | Mod EphD Resp | | | | |-------------->| | | | Add $ Local unspecified remote specified | |<--------------| | | | Add EphE Resp | | |<----------------| | | | Mod EphA | | | |---------------->| | | | Mod EphA Resp | | | | | / \ | | | | | | |/------------------------------- ---------------\| | RTP MEDIA | |\-------------------------------------------------/| | |<---- ----------| | | | 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 | Madhubabu, et al. Informational - Expires April 2005 [Page 234] Internet-Draft Megaco/H.248 Call flow examples November2004 |\-------------------------------------------------/| | |<--------------------------------| | | 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 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 Madhubabu, et al. Informational - Expires April 2005 [Page 235] Internet-Draft Megaco/H.248 Call flow examples November2004 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. Step 3 MG1 to MGC: MEGACO/1 [209.110.59.34]:25000 Transaction = 2000 { Context = - { Notify = TermA {ObservedEvents =1111 { 20010202T10000000:al/of}} } } Madhubabu, et al. Informational - Expires April 2005 [Page 236] Internet-Draft Megaco/H.248 Call flow examples November2004 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 { 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 Madhubabu, et al. Informational - Expires April 2005 [Page 237] Internet-Draft Megaco/H.248 Call flow examples November2004 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 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. Madhubabu, et al. Informational - Expires April 2005 [Page 238] Internet-Draft Megaco/H.248 Call flow examples November2004 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 o=- 2890844525 2890842816 IN IP4 209.110.59.34 Madhubabu, et al. Informational - Expires April 2005 [Page 239] Internet-Draft Megaco/H.248 Call flow examples November2004 s=- t= 00 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 o=- 2890844525 2890842816 IN IP4 209.110.59.34 Madhubabu, et al. Informational - Expires April 2005 [Page 240] Internet-Draft Megaco/H.248 Call flow examples November2004 s=- t= 00 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 o=- 2890844525 2890842816 IN IP4 207.176.47.89 s=- t= 00 c=IN IP4 207.176.47.90 m=audio 40000 RTP/AVP 4 } } ; RTP profile for G723 is 4 } } } The MGC generates a Modify message towards the RGW1 to generate ringback tone to the calling party user TermA, as the processing of signal descriptor at RGW2 was successfuly responded by RGW2. The RGW1 generates response for the Modify command from the MGC. Madhubabu, et al. Informational - Expires April 2005 [Page 241] Internet-Draft Megaco/H.248 Call flow examples November2004 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 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 embed { signals cg/dt, events = 1235 { dd/ce{dmap1}, al/on }}}, Media { LocalControl { Mode = SendRecv, } } } Modify = EphB{ Media { LocalControl { Mode = SendRecv, } } } Madhubabu, et al. Informational - Expires April 2005 [Page 242] Internet-Draft Megaco/H.248 Call flow examples November2004 } 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 o=- 2890844525 2890842816 IN IP4 207.176.47.89 s=- t= 00 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 Madhubabu, et al. Informational - Expires April 2005 [Page 243] Internet-Draft Megaco/H.248 Call flow examples November2004 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 | | | | | | | | | +---------------+ +---------------+ | | | +------------------------------------------------------+ +------------------------------------------------------+ | 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. Madhubabu, et al. Informational - Expires April 2005 [Page 244] Internet-Draft Megaco/H.248 Call flow examples November2004 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 {ObservedEvents =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 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 Madhubabu, et al. Informational - Expires April 2005 [Page 245] Internet-Draft Megaco/H.248 Call flow examples November2004 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 embed { events = 1111{ al/on } } } } Add = $ { Media { { LocalControl { Mode = ReceiveOnly, }, Local { v=0 c=IN IP4 $ m=audio $ RTP/AVP 4 } Remote { v=0 o=- 2890844525 2890842816 IN IP4 207.176.47.89 s=- t= 00 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 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 Madhubabu, et al. Informational - Expires April 2005 [Page 246] Internet-Draft Megaco/H.248 Call flow examples November2004 MG1 to MGC: MEGACO/1 [209.110.59.34]: 25000 Reply = 1240 { Context = 3 { Add = TermC, Add=EphC{ Media { Local { v=0 o=- 2890844525 2890842816 IN IP4 209.110.59.34 s=- t= 00 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 Reply = 1241 { Context = 2 { Modify= TermB, } } The UserC after receiving the ring signal goes offhook. The offhook Madhubabu, et al. Informational - Expires April 2005 [Page 247] Internet-Draft Megaco/H.248 Call flow examples November2004 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, } } } } The Residential gateway responds with the Modify response command. Madhubabu, et al. Informational - Expires April 2005 [Page 248] Internet-Draft Megaco/H.248 Call flow examples November2004 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 doesnt generate RTP towards UserB. Madhubabu, et al. Informational - Expires April 2005 [Page 249] Internet-Draft Megaco/H.248 Call flow examples November2004 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 { Madhubabu, et al. Informational - Expires April 2005 [Page 250] Internet-Draft Megaco/H.248 Call flow examples November2004 Notify = TermB {ObservedEvents =1234 { 20050202T10000000:al/fl}} } } 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 | Madhubabu, et al. Informational - Expires April 2005 [Page 251] Internet-Draft Megaco/H.248 Call flow examples November2004 | +---------------+ +---------------+ | | | | | | | | | | | | | | | Phy C | +-+ | Eph C | | <---->| |<--->|*|<---->| LocalC |<------> | | | +-+ | RemoteB | | | | | | | | | +---------------+ +---------------+ | | | +------------------------------------------------------+ 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 ter mination. 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 Madhubabu, et al. Informational - Expires April 2005 [Page 252] Internet-Draft Megaco/H.248 Call flow examples November2004 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{ 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 } } } } } Madhubabu, et al. Informational - Expires April 2005 [Page 253] Internet-Draft Megaco/H.248 Call flow examples November2004 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 { { 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 Madhubabu, et al. Informational - Expires April 2005 [Page 254] Internet-Draft Megaco/H.248 Call flow examples November2004 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 { 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 | | Madhubabu, et al. Informational - Expires April 2005 [Page 255] Internet-Draft Megaco/H.248 Call flow examples November2004 | +---------------+ | Local A | | | | |-------~------| Remote B |<-------- | | | +------| | | | | Phy A | | +---------------+ | <---->| | | +---------------+ | | | | | | EphD | | | | | +------| Local A |<------> | | |<------------>| Remote C | | | +---------------+ +---------------+ | | | +------------------------------------------------------+ +------------------------------------------------------+ | RGW2 | | Context2 | | +---------------+ +---------------+ | | | | | | | | | | | | | | | Phy B | +-+ | Eph B | | <---->| |<--->|*|<---->| LocalB |<------> | | | +-+ | RemoteC | | | | | | | | | +---------------+ +---------------+ | | | +------------------------------------------------------+ +------------------------------------------------------+ | RGW3 +---------------+ | | Context2 | EPHC | | | +---------------+ | Local C | | | | |<------------>| Remote B |<-------> | | | +------>| | | | | Phy C | | +---------------+ | <---->| | | +---------------+ | | | | | | EphF | | | | | +------>| Local C |<------> | | |<------------>| Remote A | | | +---------------+ +---------------+ | | | +------------------------------------------------------+ The UserA an d 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 Madhubabu, et al. Informational - Expires April 2005 [Page 256] Internet-Draft Megaco/H.248 Call flow examples November2004 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 { 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 Madhubabu, et al. Informational - Expires April 2005 [Page 257] Internet-Draft Megaco/H.248 Call flow examples November2004 } ; 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 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. Madhubabu, et al. Informational - Expires April 2005 [Page 258] Internet-Draft Megaco/H.248 Call flow examples November2004 +------------------------------------------------------+ | RGW1 +---------------+ | | Context1 | EPHA | | | +---------------+ | Local A | | | | |<------------>| Remote B |<-------> | | | +------>| | | | | Phy A | | +---------------+ | <---->| | | +---------------+ | | | | | | EphD | | | | | +------>| Local A |<------> | | |<------------>| Remote C | | | +---------------+ +---------------+ | | | +------------------------------------------------------+ +------------------------------------------------------+ | RGW2 +---------------+ | | Context2 | EPHB | | | +---------------+ | Local B | | | | |<------------>| Remote C |<-------> | | | +----->| | | | | Phy B | | +---------------+ | <---->| | | +---------------+ | | | | | | EphD | | | | | +------>| Local B |<------> | | |<------------>| Remote A | | | +---------------+ +---------------+ | | | +------------------------------------------------------+ +------------------------------------------------------+ | RGW3 +---------------+ | | Context3 | EPHC | | | +---------------+ | Local C | | | | |<------------>| Remote B |<-------> | | | +----->| | | | | Phy C | | +---------------+ | <---->| | | +---------------+ | | | | | | EphF | | | | | +----->| Local C |<------> | | |<------------>| Remote A | | | +---------------+ +---------------+ | | | +------------------------------------------------------+ Madhubabu, et al. Informational - Expires April 2005 [Page 259] Internet-Draft Megaco/H.248 Call flow examples November2004 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 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 { Madhubabu, et al. Informational - Expires April 2005 [Page 260] Internet-Draft Megaco/H.248 Call flow examples November2004 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}} } } 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 Madhubabu, et al. Informational - Expires April 2005 [Page 261] Internet-Draft Megaco/H.248 Call flow examples November2004 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 } } } } Media connection is present only between UserA and UserC as shown in figure below. +------------------------------------------------------+ | RGW1 | | Context1 | | +---------------+ +---------------+ | | | | | | | | | | | | | | | Phy A | | Eph D | | <---->| |<------------>| LocalA |<------> Madhubabu, et al. Informational - Expires April 2005 [Page 262] Internet-Draft Megaco/H.248 Call flow examples November2004 | | | | 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. Step 56 MGC to MG3: MEGACO/1 [216.33.33.61]: 27000 Reply = 4004 { Context = 3 { Notify = TermC } } Madhubabu, et al. Informational - Expires April 2005 [Page 263] Internet-Draft Megaco/H.248 Call flow examples November2004 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: MEGACO/1 [216.33.33.61]: 27000 Transaction = 1254 { Context = 3 { Subtract = TermC {Audit{ }}, Subtract = EphF {Audit{Statistics}} } Madhubabu, et al. Informational - Expires April 2005 [Page 264] Internet-Draft Megaco/H.248 Call flow examples November2004 } 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} } Step 63: Madhubabu, et al. Informational - Expires April 2005 [Page 265] Internet-Draft Megaco/H.248 Call flow examples November2004 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:10] 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 Gat eway 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. Informational - Expires April 2005 [Page 266] Internet-Draft Megaco/H.248 Call flow examples November2004 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| Madhubabu, et al. Informational - Expires April 2005 [Page 267] Internet-Draft Megaco/H.248 Call flow examples November2004 | |--------------->| | | | MGC-MGC SDPexchange | | | |-------------->| | | | 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 Madhubabu, et al. Informational - Expires April 2005 [Page 268] Internet-Draft Megaco/H.248 Call flow examples November2004 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 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}} } Madhubabu, et al. Informational - Expires April 2005 [Page 269] Internet-Draft Megaco/H.248 Call flow examples November2004 MGC1 generates the Notify response and responds with more messages tow ards the MG that generated the Notify command. Step 4 MGC1 to MG1: MEGACO/1 [216.33.33.61]: 27000 Reply = 2000 { Context = - {Notify = TermA} } 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 Madhubabu, et al. Informational - Expires April 2005 [Page 270] Internet-Draft Megaco/H.248 Call flow examples November2004 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 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. Madhubabu, et al. Informational - Expires April 2005 [Page 271] Internet-Draft Megaco/H.248 Call flow examples November2004 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 { 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 { Madhubabu, et al. Informational - Expires April 2005 [Page 272] Internet-Draft Megaco/H.248 Call flow examples November2004 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 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 embed {events = 1235 {al/on}}}, }, Add = $ {Media { LocalControl { Mode = sendrecv, }, Local { v=0 o=- 2873397497 0 ATM - - s=- c=ATM - - Madhubabu, et al. Informational - Expires April 2005 [Page 273] Internet-Draft Megaco/H.248 Call flow examples November2004 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 specified in the command. The signal descriptor lists "ring" signal to be applied on the termination. The event descriptor li sts 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 Madhubabu, et al. Informational - Expires April 2005 [Page 274] Internet-Draft Megaco/H.248 Call flow examples November2004 } } } } } 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 { 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 { Madhubabu, et al. Informational - Expires April 2005 [Page 275] Internet-Draft Megaco/H.248 Call flow examples November2004 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 { 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 Madhubabu, et al. Informational - Expires April 2005 [Page 276] Internet-Draft Megaco/H.248 Call flow examples November2004 } 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 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. Informational - Expires April 2005 [Page 277] Internet-Draft Megaco/H.248 Call flow examples November2004 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 Madhubabu, et al. Informational - Expires April 2005 [Page 278] Internet-Draft Megaco/H.248 Call flow examples November2004 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 } } } } 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}} } } Madhubabu, et al. I nformational - Expires April 2005 [Page 279] Internet-Draft Megaco/H.248 Call flow examples November2004 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 } } } } The two users UserA and UserB are ready for initiating/receiving further calls. 10.1.2 Backward Bearer Connection Set-up Method Madhubabu, et al. Informational - Expires April 2005 [Page 280] Internet-Draft Megaco/H.248 Call flow examples November2004 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 TermASD:cg/rt | | <--------| Add $ Local Unspecified | | Ringback |---------------->| | | | Add TermA Resp | | | | Add EphA Resp | | |<-------- | | |<--------------|OffHook | | | Notify OffHook| | |--------------->| | | | MGC-MGC SDPexchange | | | |-------------->| | | | Add TermB | | | | Add $ Local Unspecified | | | Remote Specified Madhubabu, et al. Informational - Expires April 2005 [Page 281] Internet-Draft Megaco/H.248 Call flow examples November2004 | | |<--------------| | | | Add TermB Resp| | | | Add EphB Local Specified | | |-------------->| | | | Modify TermB mode=sendrecv | | | Modify EphB mode=sendrecv | | |<--------------| | | | Modify Resp TermB | | | Modify Resp EphB | |<---------------| | | | MGC-MGC | | |<----------------| | | | Modify TermA sendrecv | | | Modify EphA remote specified mode=sendrecv | |---------------->| | | | Modify TermA Resp | | | Modify EphA Resp| | | |/------------------------------------------------\| | MEDIA | |\------------------------------------------------/| ------->| | | | OnHook |---------------->| | | | Notify OnHook | | | |<----------------|--------------->| | | Notify Resp | MGC-MGC teardowninfo | | | |-------------->| | | | Modify TermB cg/bt | | |<--------------| |<----------------| | | | Sub TermA | | |<------- | Sub EphA | |<--------------| OnHook |---------------->| | Notify OnHook | | Sub TermA Resp | |-------------->| | Sub EphA Reps Statistics |-------------->| | | | Sub TermB | | | | Sub EphB | | | |<--------------| | | | Sub TermB 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 Madhubabu, et al. Informational - Expires April 2005 [Page 282] Internet-Draft Megaco/H.248 Call flow examples November2004 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 o nly. The stream parameter is used with only the Local control 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}} } Madhubabu, et al. Informational - Expires April 2005 [Page 283] Internet-Draft Megaco/H.248 Call flow examples November2004 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} } 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 Madhubabu, et al. Informational - Expires April 2005 [Page 284] Internet-Draft Megaco/H.248 Call flow examples November2004 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 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 Madhubabu, et al. Informational - Expires April 2005 [Page 285] Internet-Draft Megaco/H.248 Call flow examples November2004 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 { 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 { Madhubabu, et al. Informational - Expires April 2005 [Page 286] Internet-Draft Megaco/H.248 Call flow examples November2004 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 } } } } } } 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 t o 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 embed {events = 1235 {al/on}}}, }, Add = $ {Media { LocalControl { Mode = sendrecv, }, Local { Madhubabu, et al. Informational - Expires April 2005 [Page 287] Internet-Draft Megaco/H.248 Call flow examples November2004 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 } } } } } } 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 Madhubabu, et al. Informational - Expires April 2005 [Page 288] Internet-Draft Megaco/H.248 Call flow examples November2004 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}} } } 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 { Madhubabu, et al. Informational - Expires April 2005 [Page 289] Internet-Draft Megaco/H.248 Call flow examples November2004 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 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} Remote { v=0 Madhubabu, et al. Informational - Expires April 2005 [Page 290] Internet-Draft Megaco/H.248 Call flow examples November2004 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 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} } } 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 Madhubabu, et al. Informational - Expires April 2005 [Page 291] Internet-Draft Megaco/H.248 Call flow examples November2004 } } 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: MGC1 to RGW1 MEGACO/1 [216.33.33.61]: 27000 Transaction = 1241 { Context = 1 { Subtract = TermA {Audit{ }}, Madhubabu, et al. Informational - Expires April 2005 [Page 292] Internet-Draft Megaco/H.248 Call flow examples No vember2004 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 { Context = 2 {Notify = TermB} } Madhubabu, et al. Informational - Expires April 2005 [Page 293] Internet-Draft Megaco/H.248 Call flow examples November2004 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 thanks their colleagues at their respective companies 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 Seshagiri Rao, Dutt Kalpatapu, Rajeev Khurana and Mathi Packiam for providing their timely comments. Basic call flows have been provided by the authors of the MGCP call flow document. Technical ideas/review comments have been provided by Mathi Packiam, Thillaivilagam Anand, Terry L Anderson, Jerry Wang, Al Varney, Sarika Gupta, Mehul Shah, Peter Michielsen, Madhubabu, et al. Informational - Expires April 2005 [Page 294] Internet-Draft Megaco/H.248 Call flow examples November2004 Nagakumar devarakonda, sugumar rajarathinam, Wang Julin, Raphel Tryster, Pramod Bhagath, Aleksandar Ryabin, Surapaneni Rao, vikas bajaj and Sasitharan R. Disclaimer of Validity This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Copyright Statement Copyright (C) The Internet Society (2004). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. AUTHOR'S ADDRESS Madhubabu Brahmanapally Veraz Networks 926 Rock Ave, San Jose, CA 95054 Tel 408-750-8477 Fax 408-546-0081 Email: madhubabu@veraznet.com Prerepa Viswanadham 1000 Marconi Drive Warrendale, PA 15086-7502 Tel 724-742-6897 Fax 724-742-6800 Email : prerepa.viswanadham@marconi.com Krishna Gundamaraju ADC Telecommunications 8 Technology Drive Westborough, MA 01581 Tel 508-870-2572 Fax 508-366-6513 Email: krishna_gundamaraju@adc.com Madhubabu, et al. Informational - Expires April 2005 [Page 295]