[Search] [txt|pdf|bibtex] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 01                                                            
Internet Engineering Task Force                        Christian Huitema
INTERNET DRAFT                                        Flemming Andreasen
<draft-huitema-megaco-mgcp-flows-01.txt>                        Bellcore
January 20, 1999                                         Mauricio Arango
Expires: June 18, 1999                                           RSL COM
                                                               Prakash K
                                                            TELESOFT INC


            Media Gateway Control Protocol (MGCP) Call Flows
   Christian Huitema, Flemming Andreasen, Mauricio Arango, Prakash K




Status of this document

This document is an Internet-Draft and is in full conformance with all
provisions of Section 10 of RFC2026 except for the right to produce
derivative works.

This document is an Internet-Draft.  Internet-Drafts are working docu-
ments 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."

To view the entire list of current Internet-Drafts, please check the
"1id-abstracts.txt" listing contained in the Internet-Drafts Shadow
Directories on ftp.is.co.za (Africa), ftp.nordu.net (Northern Europe),
ftp.nis.garr.it (Southern Europe), munnari.oz.au (Pacific Rim),
ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast).



Abstract

The Media Gateway Control Protocol (MGCP) organizes the communication
between a Media Gateway controller, or call agent, and a Media Gateway,
e.g. a Voice over IP gateway or a Network Access Server.  MGCP is
defined in a companion document [1].  This document provides example of
MGCP usage by providing a variety of call flows, in the case of
telephony and network access servers.




Huitema, Andreasen, Arango, Prakash                             [Page 1]


Internet draft              MGCP Call Flows              20 January 1999


Table of Contents                                             Page

1.  Introduction ..............................................  2
2.  Internet Telephony Call Flows. ............................  2
3.  Interaction between an MGCP gateway and an H.323 entity ...  2
4.  Interworking between SIP and MGCP .........................  2
5.  Data calls ................................................  2
6.  Audit and Restart .........................................  2
7.  Using MGCP to control an IVR ..............................  2
8.  Acknowledgements ..........................................  2
9.  References ................................................  2
10.  Authors' Addresses .......................................  2







































Huitema, Andreasen, Arango, Prakash                             [Page 2]


Internet draft              MGCP Call Flows              20 January 1999


1.  Introduction

In order to understand the way the MGCP interface will be used, we have
described here several possible call flows between a TGW, which is a
trunking gateway that implements MGCP, and an RGW, which is a residen-
tial gateway that implements MGCP, as well as several call flows
describing how MGCP could be used to control a network access service.
For each of these call flows it is assumed that the default event pack-
ages are as follows:

TGW  Trunk package

RGW  Line package

NAS  Network Access Server package

The diagrams also show a Common Database (CDB) that can be queried for
authorization and routing information, and an Accounting Gateway (ACC)
that collects accounting information at the start and the end of calls.

These diagrams are solely meant to exhibit the behavior of the MGCP, and
to help understanding this protocol. They are not meant as a tutorial on
the implementation of a Call Agent. They may very well include miscel-
laneous errors and imprecisions.



























Huitema, Andreasen, Arango, Prakash                             [Page 3]


Internet draft              MGCP Call Flows              20 January 1999


2.  Internet Telephony Call Flows.

We present seven Internet Telephony call flows:

*    A basic call between two "trunking gateways",

*    A basic call from a "residential gateway" to a "trunking gateway",

*    A basic call  from a "trunking gateway" to a "residential gateway".

*    A basic call from an R2 trunk in a TGW to an SS7 trunk in a TGW.

*    A basic call from an ISDN trunk in a business gateway to an SS7
     trunk in a TGW.

*    A basic call with continuity test, from a "trunking gateway" to a
     "residential gateway".

*    A "hairpin" connection between two endpoints on a trunking gateway,
     using regular call set-up procedures.

*    A "hairpin" connection between two endpoints on a residential gate-
     way, using accelerated procedures.




























Huitema, Andreasen, Arango, Prakash                             [Page 4]


Internet draft              MGCP Call Flows              20 January 1999


2.1.  Connection from a TGW to another TGW

The figure below gives the flow that results in a connection between two
trunking gateways.

                 ______________________________________
                | sw1|  SG1|  TGW1|   CA |  TGW2|  SG2|
                |____|_____|______|______|______|_____|
                | IAM|  -> |      |      |      |     |
                |    |  IAM|  - - |  ->  |      |     |
                |    |     |   <- |  CRCX|      |     |
                |    |     |  ACK |  ->  |      |     |
                |    |     |      |  CRCX|  ->  |     |
                |    |     |      |    <-|  ACK |     |
                |    |     |      |  IAM |  - - |  -> |
                |    |     |      |      |      |  IAM|
                |    |     |      |      |      |   <-|
                |    |     |      |    <-|  - - |  ACM|
                |    |     |   <- |  ACM |      |     |
                |  <-|  - -|  ACM |      |      |     |
                |    |  ...|      |      |      |     |
                |    |     |      |      |      |   <-|
                |    |     |      |    <-|  - - |  ACM|
                |    |     |   <- |  MDCX|      |     |
                |    |     |  ACK |  ->  |      |     |
                |    |   <-|  - - |  ANM |      |     |
                |  <-|  ANM|      |      |      |     |
                | REL|  -> |      |      |      |     |
                |    |  REL|  - - |  ->  |      |     |
                |    |     |   <- |  DLCX|      |     |
                |    |     |  Perf|  ->  |      |     |
                |    |     |  data|      |      |     |
                |    |   <-|  - - |  RLC |      |     |
                |  <-|  RLC|      |      |      |     |
                |    |     |      |  DLCX|  ->  |     |
                |    |     |      |    <-|  Perf|     |
                |    |     |      |      |  data|     |
                |    |     |      |  REL |  - - |  -> |
                |    |     |      |      |      |  REL|
                |    |     |      |      |      |   <-|
                |    |     |      |    <-|  - - |  RLC|
                |____|_____|______|______|______|_____|


During these exchanges the MGCP is used by the Call Agent to control the
two endpoints located on the two TGW.

The exchanges start with the arrival from the first switch (SW1) of an



Huitema, Andreasen, Arango, Prakash                             [Page 5]


Internet draft              MGCP Call Flows              20 January 1999


SS7/ISUP "IAM" message, relayed by the signalling gateway to the Call
Agent.  The call agent performs the routing, and determines that the
call will have to be relayed towards the second switch (SW2), using a
trunk located on TGW2.

The call agent starts the exchange by seizing the endpoint referenced in
the IAM message:

        CRCX 1204 trunk-group-1/17@tgw1.whatever.net MGCP 0.1
        C: A3C47F21456789F0
        L: p:10, a:G.711
        M: recvonly


Upon reception of that command, the trunking gateway prepares a connec-
tion description.

        200 1204 OK
        I:FDE234C8

        v=0
        c=IN IP4 128.96.41.1
        m=audio 3456 RTP/AVP 0


The call agent, upon reception of this acknowledgement, sends a connec-
tion request to the trunking gateway, asking the gateway to reserve a
trunk in the group connected to the second switch:

        CRCX 1205 trunk-group-2/$@tgw2.whatever.net MGCP 0.1
        C: A3C47F21456789F0
        M: sendrecv

        v=0
        c=IN IP4 128.96.41.1
        m=audio 3456 RTP/AVP 0


The call agent selects a trunk in the group, and acknowledges the crea-
tion:

        200 1204 OK
        I:abc0

        v=0
        c=IN IP4 128.96.63.25
        m=audio 1296 RTP/AVP 0




Huitema, Andreasen, Arango, Prakash                             [Page 6]


Internet draft              MGCP Call Flows              20 January 1999


The two commands have created a one way path, suitable for forwarding
ring tones and announcements to the calling party.  The call agent can
now relay the call by sending an IAM message to the second switch.  When
the ACM is received, it is immediately relayed to the first switch.

After some time, the call is answered, and an ANM message is relayed
from the second switch to the call agent. The call agent will first
validate the call by asking the first end-point to place the connection
in duplex mode:

        MDCX 1206 trunk-group-1/17@tgw1.whatever.net MGCP 0.1
        C: A3C47F21456789F0
        I:FDE234C8
        M: sendrecv

        v=0
        c=IN IP4 128.96.63.25
        m=audio 1296 RTP/AVP 0


The trunking gateway executes and acknowledges the modification:

        200 1206 OK

        The call agent can now relay the ANM message to the calling
        switch, and both parties can talk.

        At the end of the call, in our example, the calling party hangs
        up.  The first switch sends a release message to the call agent,
        through the signalling gateway.  The call agent releases the
        connection on the first endpoint:

                DLCX 1207 trunk-group-1/17@tgw1.whatever.net MGCP 0.1
                C: A3C47F21456789F0
                I:FDE234C8

        The gateway acknowledges the deletion, sending the connection
        parameters:

                250 1217 OK
                P: PS=1245, OS=62345, PR=780, OR=45123, PL=10, JI=27,LA=48

        The call agent can now confirm the release of the trunk, sending
        an RLC message to the first switch.

        In parallel, the call agent releases the connection to the
        second endpoint:




Huitema, Andreasen, Arango, Prakash                             [Page 7]


Internet draft              MGCP Call Flows              20 January 1999


                DLCX 1208 trunk-group-2/13@tgw2.whatever.net MGCP 0.1
                C: A3C47F21456789F0
                I:abc0


        The gateway acknowledges the deletion, sending the connection
        parameters:

                250 1218 OK
                P: PS=790, OS=45700, PR=1230, OR=61875, PL=15, JI=27,LA=48

        After receiving the acknowledgement, the call agent can relay
        the release message to the second switch. The switch will in
        turn acknowledge the release.





































Huitema, Andreasen, Arango, Prakash                             [Page 8]


Internet draft              MGCP Call Flows              20 January 1999


        2.2.  Basic call, RGW to TGW

     ______________________________________________________________________
    |  Usr  |    RGW   |       CA     |  CDB|  ACC|    TGW   |  SS7/|  CO |
    |       |          |              |     |     |          |  ISUP|     |
    |_______|__________|______________|_____|_____|__________|______|_____|
    |       |     <-   |      RQNT    |     |     |          |      |     |
    |       |    Ack   |       ->     |     |     |          |      |     |
    |  Off  |          |              |     |     |          |      |     |
    | -hook |   (local |              |     |     |          |      |     |
    | (Dial |  action) |              |     |     |          |      |     |
    | -tone)|          |              |     |     |          |      |     |
    | Digits|   Notify |       ->     |     |     |          |      |     |
    |       |     <-   |      Ack     |     |     |          |      |     |
    | (pro- |     <-   |   CRCX+RQNT  |     |     |          |      |     |
    | gress)|    Ack   |       ->     |     |     |          |      |     |
    |       |          |     Query    |     |     |          |      |     |
    |       |          |  (E.164 S,D) |  -> |     |          |      |     |
    |       |          |       <-     |  IP |     |          |      |     |
    |       |          |      CRCX    |  - -|  - -|     ->   |      |     |
    |       |          |              |     |     |  (cut in)|      |     |
    |       |          |       <-     |  - -|  - -|    ack   |      |     |
    |       |          |      IAM     |  - -|  - -|    - -   |   -> |     |
    |       |     <-   |     MDCX     |     |     |          |  IAM |  -> |
    |       |    Ack   |       ->     |     |     |          |   <- |  ACM|
    |       |          |       <-     |  - -|  - -|    - -   |  ACM |     |
    |       |     <-   |  Notification|     |     |          |      |     |
    |       |          |    Request   |     |     |          |      |     |
    |       |    Ack   |       ->     |     |     |          |      |     |
    |       |          |              |     |     |          |   <- |  ANM|
    |       |          |       <-     |  - -|  - -|    - -   |  ANM |     |
    |       |     <-   |   MDCX+RQNT  |     |     |          |      |     |
    |       |    Ack   |       ->     |     |     |          |      |     |
    |       |  (cut in)|   Call start |  - -|  -> |          |      |     |
    |_______|__________|______________|_____|_____|__________|______|_____|
















Huitema, Andreasen, Arango, Prakash                             [Page 9]


Internet draft              MGCP Call Flows              20 January 1999


       __________________________________________________________________
      |   Usr  |   RGW  |       CA     |  CDB|  ACC|   TGW |  SS7/|  CO |
      |        |        |              |     |     |       |  ISUP|     |
      |________|________|______________|_____|_____|_______|______|_____|
      |        |        |              |     |     |       |   <- |  REL|
      |        |        |       <-     |  - -|  - -|   - - |  REL |     |
      |        |    <-  |     Delete   |     |     |       |      |     |
      |        |        |   Connection |     |     |       |      |     |
      |        |        |     Delete   |     |     |       |      |     |
      |        |        |   Connection |  - -|  - -|   ->  |      |     |
      |        |   Perf |              |     |     |       |      |     |
      |        |   Data |       ->     |     |     |       |      |     |
      |        |        |       <-     |  - -|  - -|  perf |      |     |
      |        |        |              |     |     |  data |      |     |
      |        |        |    Call end  |  - -|  -> |       |      |     |
      | On-hook|  Notify|       ->     |     |     |       |      |     |
      |        |    <-  |      Ack     |     |     |       |      |     |
      |        |    <-  |  Notification|     |     |       |      |     |
      |        |        |    Request   |     |     |       |      |     |
      |        |   Ack  |       ->     |     |     |       |      |     |
      |________|________|______________|_____|_____|_______|______|_____|


        During these exchanges the MGCP is used by the Call Agent to
        control both the TGW and the residential gateway. The exchanges
        occur on two sides.

        The first command is a NotificationRequest, sent by the Call
        Agent to the residential gateway. The request will consist of
        the following lines:

                RQNT 1201 endpoint/1@rgw-2567.whatever.net MGCP 0.1
                N: ca@ca1.whatever.net:5678
                X: 0123456789AC
                R: hd(E(dl;hu, D/[0-9#*T](D);)
                D: (0T|00T|[1-7]xxx|8xxxxxxx|#xxxxxxx|*xx|91xxxxxxxxxx|9011x.T)
                S:


        That transaction illustrates the power of the "embedded" action.
        The gateway is instructed to look for an off-hook event, and,
        upon its detection, to provide a dial-tone and to start looking
        for DTMF digits.  The gateway immediately acknowledges the com-
        mand, repeating in the acknowledgement message the transaction
        id that the Call Agent attached to the query.

                200 1201 OK




Huitema, Andreasen, Arango, Prakash                            [Page 10]


Internet draft              MGCP Call Flows              20 January 1999


        When the off hook event is noticed, the gateway provides the
        dial tone to the line (the delay between off-hook and dialtone
        is thus minimal.)

        The gateway will start accumulating digits according to that
        digit map. When it has noticed a sufficient set of values, it
        will notify the observed string to the Call Agent:

                NTFY 2002 endpoint/1@rgw-2567.whatever.net MGCP 0.1
                N: ca@ca1.whatever.net:5678
                X: 0123456789AC
                O: 912018294266


        The Call Agent immediately acknowledges that notification.

                200 2002 OK


        The Call Agent will then seize the incoming circuit, creating a
        connection.  The create connection commands piggybacks a notifi-
        cation request, to stop collecting digits yet continue watch for
        an on-hook transition:

                CRCX 1204 endpoint/1@rgw-2567.whatever.net MGCP 0.1
                C: A3C47F21456789F0
                L: p:10, a:G.711;G.726-32
                M: recvonly
                X: D/0123456789AD
                R: hu
                S:


             We should note at this point that the call agent could send
             the acknowledgement of the Notify and the CRCX in a single
             UDP packet, as explained in the "piggy backing" section of
             [1].  There are many possible groupings of that nature in
             the various examples.

        The gateway immediately acknowledges the creation, sending back
        the identification of the newly created connection and the ses-
        sion description used to receive audio data:

                200 1204 OK
                I:FDE234C8

                v=0
                c=IN IP4 128.96.41.1



Huitema, Andreasen, Arango, Prakash                            [Page 11]


Internet draft              MGCP Call Flows              20 January 1999


                m=audio 3456 RTP/AVP 0 96
                a=rtpmap:96 G726-32/8000


        The SDP announcement, in our example, specifies the address at
        which the gateway is ready to receive audio data (128.96.41.1),
        the transport protocol (RTP), the RTP port (3456) and the audio
        profile (AVP). The audio profile refers to RFC 1890, which
        defines that the payload type 0 has been assigned for G.711
        transmission. The gateway is also ready to use ADPCM encoding at
        32 kbps (G.726 -4). There is no standard payload type associated
        to ADPCM, so the gateway mentions its readiness to use a non
        standard payload associated to the dynamic type 96. The "rtpmap"
        attribute entry associates the payload type 96 to G726-32/4.

        The Call Agent, having seized the incoming trunk and completed a
        routing look up to identify the outgoing gateway, must now seize
        the outgoing trunk. It does so by sending a connection command
        to the e-gress gateway:

                CRCX 1205 card23/21@trgw-7.whatever.net MGCP 0.1
                C: A3C47F21456789F0
                L: p:10, a:G.711;G.726-32
                M: sendrecv

                v=0
                c=IN IP4 128.96.41.1
                m=audio 3456 RTP/AVP 0 96
                a=rtpmap:96 G726-32/8000


        The CreateConnection command has the same parameters as the com-
        mand sent to the ingress gateway, with two differences:

        *    The EndpointId points towards the outgoing trunk,

        *    The message carries the session description returned by the
             ingress gateway,

        *    Because the session description is present, the "mode"
             parameter is set to "send/receive".

        We observe that the call identifier is identical for the two
        connections. This is normal: the two connections belong to the
        same call, which has a global identifier in our system.

        The trunking gateway will acknowledge the connection command,
        sending in the session description its own parameters such as



Huitema, Andreasen, Arango, Prakash                            [Page 12]


Internet draft              MGCP Call Flows              20 January 1999


        address, ports and RTP profile:

                200 1205 OK
                I:32F345E2

                v=0
                c=IN IP4 128.96.63.25
                m=audio 1296 RTP/AVP 0 96
                a=rtpmap:96 G726-32/8000


        The Call Agent will relay the information to the ingress gate-
        way, using a ModifyConnection command:

                MDCX 1206 endpoint/1@rgw-2567.whatever.net MGCP 0.1
                C: A3C47F21456789F0
                I:FDE234C8
                M: recvonly

                v=0
                c=IN IP4 128.96.63.25
                m=audio 1296 RTP/AVP 0 96
                a=rtpmap:96 G726-32/8000


        The residential gateway immediately acknowledges the modifica-
        tion:

                200 1206 OK


        At this stage, the Call Agent has established a half duplex
        transmission path. The phone attached to the residential gateway
        will be able to receive the signals, such as tones or announce-
        ments, that the remote switch may send through the trunking
        gateway.

        When the call progresses, the Call Agent will receive from the
        remote switch progress messages, for example an "address com-
        plete" message (ACM). The Call Agent will analyze the message to
        determine whether signal are transmitted in band. If this is not
        the case, the Call Agent will instruct the RGW to generate ring-
        ing tones by sending a NotificationRequest:

                RQNT 1207 endpoint/1@rgw-2567.whatever.net MGCP 0.1
                X: 0123456789AE
                R: hu
                S: v



Huitema, Andreasen, Arango, Prakash                            [Page 13]


Internet draft              MGCP Call Flows              20 January 1999


        The gateway immediately acknowledges the command:

                200 1207 OK


        After the called user answers the call, the Call Agent will
        receive an answering message (ANM) from the CO switch. At that
        point, it will send a ModifyConnection command, to the residen-
        tial gateway, to place the connection in full duplex mode. The
        command embeds NotificationRequest to stop the ringing tones.

                MDCX 1209 endpoint/1@rgw-2567.whatever.net MGCP 0.1
                C: A3C47F21456789F0
                I:FDE234C8
                M: sendrecv
                X: 0123456789AF
                R: hu
                S:


        The residential gateway will acknowledge this command:

                200 1209 OK


        At this point, the connection is established.

        When the Call Agent receives the REL message from the CO switch,
        it will have to tear down the call. It will do so by sending to
        both gateways a DeleteConnection command:

                DLCX 1210 endpoint/1@rgw-2567.whatever.net MGCP 0.1
                C: A3C47F21456789F0
                I:FDE234C8

                DLCX 1211 card23/21@trgw-7.whatever.net MGCP 0.1
                C: A3C47F21456789F0
                I:32F345E2


        The gateways will respond with acknowledgements that should
        include a "call parameters" header fields:

                250 1210 OK
                P: PS=1245, OS=62345, PR=780, OR=45123, PL=10, JI=27,LA=48

                250 1211 OK
                P: PS=790, OS=45700, PR=1230, OR=61875, PL=15, JI=27,LA=48



Huitema, Andreasen, Arango, Prakash                            [Page 14]


Internet draft              MGCP Call Flows              20 January 1999


        At this point, the phone attached to the residential gateway, in
        our scenario, goes on-hook. This event is notified to the Call
        Agent, according to the policy received in the last Notifica-
        tionRequest by sending a Notify command:

                NTFY 2005 endpoint/1@rgw-2567.whatever.net MGCP 0.1
                X: 0123456789AF
                O: hu


        After this notification, the Call Agent should send an ack-
        nowledgement:

                200 2005 OK


        It should then issue a new NotificationRequest, to be ready to
        receive the next off-hook detected by the residential gateway:

                RQNT 1212 endpoint/1@rgw-2567.whatever.net MGCP 0.1
                X: 0123456789B0
                R: hd(E(dl;hu, [0-9#*T](D);)
                D: (0T|00T|[1-7]xxx|8xxxxxxx|#xxxxxxx|*xx|91xxxxxxxxxx|9011x.T)
                S:


        The gateway will acknowledge this message:

                200 1212 OK


        Both gateways, at this point, are ready for the next call.



















Huitema, Andreasen, Arango, Prakash                            [Page 15]


Internet draft              MGCP Call Flows              20 January 1999


        2.3.  Basic call, TGW to RGW

      ___________________________________________________________________
     | CO |  SS7/|    TGW   |       CA      |  CDB|  ACC|   RGW  |  Usr |
     |    |  ISUP|          |               |     |     |        |      |
     |____|______|__________|_______________|_____|_____|________|______|
     | IAM|   -> |          |               |     |     |        |      |
     |    |  IAM |    - -   |       ->      |     |     |        |      |
     |    |      |          |      Check    |  -> |     |        |      |
     |    |      |          |       <-      |  IP |     |        |      |
     |    |      |     <-   |     Create    |     |     |        |      |
     |    |      |          |   Connection  |     |     |        |      |
     |    |      |    Ack   |       ->      |     |     |        |      |
     |    |      |          |     Create    |     |     |        |      |
     |    |      |          |   Connection  |  - -|  - -|    ->  |      |
     |    |      |          |       <-      |  - -|  - -|   Ack  |      |
     |    |      |     <-   |     Modify    |     |     |        |      |
     |    |      |          |   Connection  |     |     |        |      |
     |    |      |    Ack   |       ->      |     |     |        |      |
     |    |      |          |  Notification |     |     |        |      |
     |    |      |          |     Request   |  - -|  - -|    ->  |  ring|
     |    |      |          |       <-      |  - -|  - -|   Ack  |      |
     |    |   <- |    - -   |       ACM     |     |     |        |      |
     | <- |  ACM |          |               |     |     |        |      |
     |    |      |          |               |     |     |        |  off |
     |    |      |          |               |     |     |        |  hook|
     |    |      |          |       <-      |  - -|  - -|  Notify|      |
     |    |      |          |       Ack     |  - -|  - -|    ->  |      |
     |    |      |          |  Notification |     |     |        |      |
     |    |      |          |     Request   |  - -|  - -|    ->  |      |
     |    |      |          |       <-      |  - -|  - -|   Ack  |      |
     |    |      |     <-   |    Modify     |     |     |        |      |
     |    |      |          |   Connection  |     |     |        |      |
     |    |      |    Ack   |       ->      |     |     |        |      |
     |    |      |  (cut-in)|   Call start  |  - -|  -> |        |      |
     |    |   <- |    - -   |       ANM     |     |     |        |      |
     | <- |  ANM |          |               |     |     |        |      |
     |____|______|__________|_______________|_____|_____|________|______|













Huitema, Andreasen, Arango, Prakash                            [Page 16]


Internet draft              MGCP Call Flows              20 January 1999


         _____________________________________________________________
        | CO|  SS7/|  TGW |       CA     |  CDB|  ACC|   RGW  |  Usr |
        |   |  ISUP|      |              |     |     |        |      |
        |___|______|______|______________|_____|_____|________|______|
        |   |      |      |              |     |     |        |  on  |
        |   |      |      |              |     |     |        |  hook|
        |   |      |      |       <-     |  - -|  - -|  Notify|      |
        |   |      |      |      Ack     |  - -|  - -|    ->  |      |
        |   |      |      |    Delete    |     |     |        |      |
        |   |      |      |   Connection |  - -|  - -|    ->  |      |
        |   |      |   <- |    Delete    |     |     |        |      |
        |   |      |      |   Connection |     |     |        |      |
        |   |   <- |  - - |      REL     |     |     |        |      |
        | <-|  REL |      |              |     |     |        |      |
        |   |      |  Perf|              |     |     |        |      |
        |   |      |  data|       ->     |     |     |        |      |
        |   |      |      |       <-     |  - -|  - -|  perf  |      |
        |   |      |      |              |     |     |   data |      |
        |   |      |      |    Call end  |  - -|  -> |        |      |
        |   |      |      |  Notification|     |     |        |      |
        |   |      |      |    Request   |  - -|  - -|    ->  |      |
        |   |      |      |       <-     |  - -|  - -|   Ack  |      |
        |___|______|______|______________|_____|_____|________|______|


        This diagram shows the various exchange of messages during a
        call from a telephone user on the circuit-switched PSTN to a
        residential user connected to a residential gateway. During
        these exchanges the Call Agent uses MGCP to control both the TGW
        and the residential gateway. The exchanges occur on two sides.


        Upon reception of the IAM message, the Call Agent immediately
        sends a CreateConnection request to the trunking gateway to con-
        nect to the incoming trunk, creating a connection:


                CRCX 1237 card23/21@trgw-7.whatever.net MGCP 0.1
                C: A3C47F21456789F0
                L: p:10, a:G.711;G.726-32
                M: recvonly


        The trunking gateway immediately acknowledges the creation,
        sending back the identification of the newly created connection
        and the session description used to receive audio data:

                200 1237 OK



Huitema, Andreasen, Arango, Prakash                            [Page 17]


Internet draft              MGCP Call Flows              20 January 1999


                I: FDE234C8

                v=0
                c=IN IP4 128.96.41.1
                m=audio 3456 RTP/AVP 0 96
                a=rtpmap:96 G726-32/8000


        The SDP announcement, in our example, specifies the address at
        which the gateway is ready to receive audio data (128.96.41.1),
        the transport protocol (RTP), the RTP port (3456) and the audio
        profile (AVP). The audio profile refers to RFC 1890, which
        defines that the payload type 0 has been assigned for G.711
        transmission. The gateway is also ready to use ADPCM encoding at
        32 kbps (G.726 -4). There is no standard payload type associated
        to ADPCM, so the gateway mentions its readiness to use a non
        standard payload associated to the dynamic type 96. The "rtpmap"
        attribute entry associates the payload type 96 to G726/4.

        The Call Agent, having seized the incoming trunk, must now
        reserve the outgoing circuit. It does so by sending a connection
        command to the residential gateway:

                CRCX 1238 endpoint/1@rgw-2567.whatever.net MGCP 0.1
                C: A3C47F21456789F0
                L: p:10, a:G.711;G.726-32
                M: sendrecv

                v=0
                c=IN IP4 128.96.41.1
                m=audio 3456 RTP/AVP 0 96
                a=rtpmap:96 G726-32/8000


        The CreateConnection command has the same parameters as the com-
        mand sent to the ingress gateway, with two differences:


        *    The EndpointId points towards the outgoing trunk,

        *    The message carries the session description returned by the
             ingress gateway,

        *    Because the session description is present, the "mode"
             parameter is set to "send/receive".

        We observe that the call identifier is identical for the two
        connections. This is normal: the two connection belong to the



Huitema, Andreasen, Arango, Prakash                            [Page 18]


Internet draft              MGCP Call Flows              20 January 1999


        same call, which has a global identifier in our system.

        The residential gateway will acknowledge the connection command,
        sending in the session description its own parameters such as
        address, ports and RTP profile:

                200 1238 OK
                I:32F345E2

                v=0
                c=IN IP4 128.96.63.25
                m=audio 1296 RTP/AVP 0 96
                a=rtpmap:96 G726-32/8000


        The Call Agent will relay the information to the ingress gate-
        way, using a ModifyConnection command:

                MDCX 1239 card23/21@trgw-7.whatever.net MGCP 0.1
                C: A3C47F21456789F0
                I:FDE234C8
                M: recvonly

                v=0
                c=IN IP4 128.96.63.25
                m=audio 1296 RTP/AVP 0 96
                a=rtpmap:96 G726-32/8000


        The trunking gateway immediately acknowledges the modification:


                200 1239 OK


        At this stage, the Call Agent has established a half-duplex
        transmission path. The Call Agent must now tells the residential
        gateway to ring the called line. It will send a NotificationRe-
        quest, consisting of the following lines:

                RQNT 1240 endpoint/1@rgw-2567.whatever.net MGCP 0.1
                X: 0123456789B1
                R: hd
                S: rg


        The residential gateway, at that point, is instructed to look
        for an off-hook event, and to report it. It will first



Huitema, Andreasen, Arango, Prakash                            [Page 19]


Internet draft              MGCP Call Flows              20 January 1999


        acknowledge the command, repeating in the acknowledgement mes-
        sage the transaction id that the Call Agent attached to the
        query.

                200 1240 OK


        Upon reception of this message, the Call Agent sends an address
        complete message (ACM) to the calling switch, which we assume
        will generate ringing tones for the calling user.

        When the gateway notices the off hook event, it sends a Notify
        command to the Call Agent:

                NTFY 2001 endpoint/1@rgw-2567.whatever.net MGCP 0.1
                X: 0123456789B0
                O: hd


        The Call Agent immediately acknowledges that notification.

                200 2001 OK


        The Call Agent now asks the residential gateway to send a Notify
        command on the occurrence of an on-hook event. It does so by
        sending a NotificationRequest to the residential gateway:


                RQNT 1241 endpoint/1@rgw-2567.whatever.net MGCP 0.1
                X: 0123456789B1
                R: hu


        The gateway acknowledges that command:

        200 1241 OK


        In parallel, the Call Agent will send a ModifyConnection command
        to the trunking gateway, to place the connection in full duplex
        mode:

                MDCX 1242 card23/21@trgw-7.whatever.net MGCP 0.1
                C: A3C47F21456789F0
                I:FDE234C8
                M: sendrecv




Huitema, Andreasen, Arango, Prakash                            [Page 20]


Internet draft              MGCP Call Flows              20 January 1999


        The trunking gateway will acknowledge that command:

                200 1242 OK


        The Call Agent can now send an answer message (ANM) to the cal-
        ling switch.

        After some time, the Call Agent will have to tear down the call.
        In our example, this is triggered by the residential user, who
        hangs up. The Notify command is sent to the Call Agent:


                NTFY 2005 endpoint/1@rgw-2567.whatever.net MGCP 0.1
                X: 0123456789B1
                O: hu


        The Call Agent acknowledges the notification.

                200 2005 OK


        It will then send to both gateways a DeleteConnection command:

                DLCX 1243 endpoint/1@rgw-2567.whatever.net MGCP 0.1
                C: A3C47F21456789F0
                I:32F345E2

                DLCX 1244 card23/21@trgw-7.whatever.net MGCP 0.1
                C: A3C47F21456789F0
                I:FDE234C8


        The gateways will respond with a message that should include a
        "call parameters" header fields:

                250 1243 OK
                P: PS=1245, OS=62345, PR=780, OR=45123, PL=10, JI=27, LA=48

                250 1244 OK
                P: PS=790, OS=45700, PR=1230, OR=61875, PL=15, JI=27, LA=48


        The Call Agent should now issue a new NotificationRequest to the
        residential gateway to detect the next off-hook event:





Huitema, Andreasen, Arango, Prakash                            [Page 21]


Internet draft              MGCP Call Flows              20 January 1999


                RQNT 1245 endpoint/1@rgw-2567.whatever.net MGCP 0.1
                X: 0123456789B2
                R: hd


        The residential gateway will acknowledge this command:

                200 1245 OK


        Both gateways, at this point, are ready for the next call.








































Huitema, Andreasen, Arango, Prakash                            [Page 22]


Internet draft              MGCP Call Flows              20 January 1999


        2.4.  Basic call from an R2 trunk in a TGW to an SS7 trunk in a
        TGW

        ________________________________________________________________
       |    CO  |     R2    |       CA      |     TGW   |   SS7/|   CO |
       |        |     TGW   |               |           |   ISUP|      |
       |________|___________|_______________|___________|_______|______|
       |        |     <-    |      NTRQ     |           |       |      |
       |        |     Ack   |       ->      |           |       |      |
       | Trunk  |           |               |           |       |      |
       | seizure|           |               |           |       |      |
       |     &  |           |               |           |       |      |
       | Called |           |               |           |       |      |
       | &callng|           |               |           |       |      |
       | number |           |               |           |       |      |
       | digit  |           |               |           |       |      |
       | collec-|           |               |           |       |      |
       |  tion  |     ->    |               |           |       |      |
       |        |   Notify  |       ->      |           |       |      |
       |        |     <-    |       Ack     |           |       |      |
       |        |     <-    |   Notification|           |       |      |
       |        |           |     Request   |           |       |      |
       |        |     Ack   |       ->      |           |       |      |
       |        |     <-    |     Create    |           |       |      |
       |        |           |   Connection  |           |       |      |
       |        |     Ack   |       ->      |           |       |      |
       |        |           |     Create    |           |       |      |
       |        |           |   Connection  |     ->    |       |      |
       |        |           |               |   (cut in)|       |      |
       |        |           |       <-      |     ack   |       |      |
       |        |           |       IAM     |     - -   |   ->  |      |
       |        |     <-    |     Modify    |           |   IAM |   -> |
       |        |           |   Connection  |           |       |      |
       |        |     Ack   |       ->      |           |   <-  |   ACM|
       |        |           |       <-      |     - -   |   ACM |      |
       |        |           |               |           |   <-  |   ANM|
       |        |           |       <-      |     - -   |   ANM |      |
       |        |     <-    |     Modify    |           |       |      |
       |        |           |   Connection  |           |       |      |
       |        |     Ack   |       ->      |           |       |      |
       |        |   (cut in)|               |           |       |      |
       |________|___________|_______________|___________|_______|______|









Huitema, Andreasen, Arango, Prakash                            [Page 23]


Internet draft              MGCP Call Flows              20 January 1999


         _____________________________________________________________
        |     CO  |     R2   |       CA      |   TGW  |   SS7/|   CO |
        |         |    TGW   |               |        |   ISUP|      |
        |_________|__________|_______________|________|_______|______|
        |         |          |               |        |   <-  |   REL|
        |         |          |       <-      |   - -  |   REL |      |
        |         |          |     Delete    |        |       |      |
        |         |     <-   |   Connection  |        |       |      |
        |         |   Clear- |               |        |       |      |
        |     <-  |    back  |     Delete    |        |       |      |
        |  Clear- |          |   Connection  |    ->  |       |      |
        |    fwd  |     ->   |               |        |       |      |
        |         |    Rel-  |               |        |       |      |
        |     <-  |   guard  |               |        |       |      |
        |         |    Perf  |               |        |       |      |
        |         |    Data  |       ->      |        |       |      |
        |         |          |       <-      |   Perf |       |      |
        |         |          |               |   data |       |      |
        |         |     <-   |   Notification|        |       |      |
        |         |          |     Request   |        |       |      |
        |         |    Ack   |       ->      |        |       |      |
        |_________|__________|_______________|________|_______|______|


        The above diagram describes the call flow between a trunk with
        R2 signaling in a trunking gateway and an SS7 trunk in a trunk-
        ing gateway. R2 is a type of Channel Associated Signaling (CAS)
        and this call flow assumes the use of an R2 package. The follow-
        ing diagram describes a simplified R2 package. In this package
        digit arrival events are not observed by the Call Agent and
        therefore cannot be part of a NotificationRequest. The first
        event that the Call Agent can observe in an R2 trunk is a
        "call-in" event which is a combination of the arrival at the
        gateway of a trunk seizure signal and collection of the called
        (destination) and calling (source) and calling party numbers
        from the R2 registers. The notification for a call-in event
        occurs when digit collection is completed. The clear forward
        event indicates that the exchange at the other side released the
        trunk.

         ______________________________________________________________
           Symbol     Definition             R     S      Duration
         ______________________________________________________________
           ci         Call in                x
           cf         Clear forward          x
           dn         Destination number
           sn         Source number
         ______________________________________________________________



Huitema, Andreasen, Arango, Prakash                            [Page 24]


Internet draft              MGCP Call Flows              20 January 1999


        |         |                      |     |                      |


        The first command is a NotificationRequest, sent by the Call
        Agent to the R2 trunking gateway. The request will consist of
        the following lines:

                RQNT 1201 trunk-group-1/*@r2tgw-2567.whatever.net MGCP 0.1
                N: ca@ca1.whatever.net:5678
                X: 0123456789AB
                R: ci

        The gateway, at that point, is instructed to look for a call-in
        event in any of the trunks corresponding to a trunk group named
        trunk-group-1. The gateway responds with the acknowledgement
        message:

                200 1201 OK

        When the call-in event is detected, the gateway sends a Notify
        to the Call Agent:

                NTFY 2001 trunk-group-1/5@r2tgw-2567.whatever.net MGCP 0.1
                N: ca@ca1.whatever.net:5678
                X: 0123456789AB
                O: ci, dn(5313456789), sn(5845430978)

        This notification indicates the occurrence of a call-in event in
        trunk #5 in trunk-group-1. It also contains the collected desti-
        nation (dn) and source (sn) party numbers. The Call Agent
        immediately acknowledges that notification.

                200 2001 OK

        At this stage, the Call Agent sends a NotificationRequest to
        wait for a trunk release signal: RQNT 1203 trunk-group-
        1/5@r2tgw-2567.whatever.net MGCP 0.1 X: 0123456789AD R: cf The
        Call Agent immediately acknowledges that command.

                200 1203 OK

        The Call Agent will then seize the incoming circuit, creating a
        connec- tion:

                CRCX 1204 trunk-group-1/5@r2tgw-2567.whatever.net MGCP 0.1
                C: A3C47F21456789F0
                L: p:10, a:G.711;G.726-32
                M: recvonly



Huitema, Andreasen, Arango, Prakash                            [Page 25]


Internet draft              MGCP Call Flows              20 January 1999


        The gateway immediately acknowledges the creation, sending back
        the identification of the newly created connection and the ses-
        sion description used to receive audio data:


                200 1204 OK
                I:FDE234C8

                v=0
                c=IN IP4 128.96.41.1
                m=audio 3456 RTP/AVP 0 96
                a=rtpmap:96 G726-32/8000

        The Call Agent, having seized the incoming trunk and completed a
        routing look up to identify the outgoing gateway, seizes the
        outgoing trunk. It does so by sending a connection command to
        the egress gate- way:

                CRCX 1205 card23/21@trgw-7.whatever.net MGCP 0.1
                C: A3C47F21456789F0
                L: p:10, a:G.711;G.726-32
                M: sendrecv

                v=0
                c=IN IP4 128.96.41.1
                m=audio 3456 RTP/AVP 0 96
                a=rtpmap:96 G726-32/8000

        The SS7 trunking gateway acknowledges the connection command,
        sending in the session description its own parameters such as
        address, ports and RTP profile:

                200 1205 OK
                I:32F345E2

                v=0
                c=IN IP4 128.96.63.25
                m=audio 1297 RTP/AVP 0 96
                a=rtpmap:96 G726-32/8000

        The Call Agent relays the information to the ingress gateway,
        using a ModifyConnection command:

                MDCX 1206 trunk-group-1/5@r2tgw-2567.whatever.net MGCP 0.1
                C: A3C47F21456789F0
                I:FDE234C8
                M: recvonly




Huitema, Andreasen, Arango, Prakash                            [Page 26]


Internet draft              MGCP Call Flows              20 January 1999


                v=0
                c=IN IP4 128.96.63.25
                m=audio 1297 RTP/AVP 0 96
                a=rtpmap:96 G726-32/8000

        The R2 trunking gateway immediately acknowledges the modifica-
        tion:

                200 1206 OK

        At this stage, the Call Agent has established a half duplex
        transmission path. The subscriber that originated the call will
        be able to receive signals, such as tones or announcements, that
        the remote switch may send through the trunking gateways.

        After the called user answers the call, the Call Agent will
        receive an answering message (ANM) from the CO switch. At that
        point, it sends a ModifyConnection command, to place the connec-
        tion in full-duplex mode:

                MDCX 1209 trunk-group-1/5@r2tgw-2567.whatever.net MGCP 0.1
                C: A3C47F21456789F0
                I:FDE234C8
                M: sendrecv

        The R2 trunking gateway acknowledges the modify command:

                200 1209 OK

        At this point, the connection is established.

        When the Call Agent receives the REL message from the CO switch,
        it will have to tear down the call. It will do so by sending to
        both gateways a DeleteConnection command:

                DLCX
                1210 trunk-group-1/5@r2tgw-2567.whatever.net MGCP 0.1
                C: A3C47F21456789F0
                I:FDE234C8

                DLCX 1211 card23/21@trgw-7.whatever.net MGCP 0.1
                C: A3C47F21456789F0
                I:32F345E2

        The gateways will respond with acknowledgements that should
        include a "call parameters" header fields:

                250 1210 OK



Huitema, Andreasen, Arango, Prakash                            [Page 27]


Internet draft              MGCP Call Flows              20 January 1999


                P: PS=1245, OS=62345, PR=780, OR=45123, PL=10, JI=27,
                LA=48

                250 1211 OK
                P: PS=790, OS=45700, PR=1230, OR=61875, PL=15, JI=27,
                LA=48

        Finally, the Call Agent issues a new NotificationRequest, to be
        ready to receive the next call-in event detected by the trunking
        gateway at the specified trunk:

                RQNT 1212 trunk-group-1/5@r2tgw-2567.whatever.net MGCP 0.1
                X: 0123456789B0
                R: hd

        The gateway will acknowledge this message:

                200 1212 OK

        Both gateways, at this point, are ready for the next call.































Huitema, Andreasen, Arango, Prakash                            [Page 28]


Internet draft              MGCP Call Flows              20 January 1999


        2.5.  Basic call, from an ISDN gateway to an SS7/TGW


   _________________________________________________________________________
  |   PBX |   Business |         CA        |     TGW   |   SS7/|     CO    |
  |       |      GW    |                   |           |   ISUP|           |
  |_______|____________|___________________|___________|_______|___________|
  | SETUP |      ->    |         ->        |           |       |           |
  |    <- |      <-    |     CALLPROC.     |           |       |           |
  |       |      <-    |        CRCX       |           |       |           |
  |       |     Ack    |         ->        |           |       |           |
  |       |            |        CRCX       |     ->    |       |           |
  |       |            |                   |   (cut in)|       |           |
  |       |            |         <-        |     ack   |       |           |
  |       |            |         IAM       |     ->    |       |           |
  |       |      <-    |        MDCX       |           |   IAM |     ->    |
  |       |     Ack    |         ->        |           |   <-  |     ACM   |
  |       |            |         <-        |     - -   |   ACM |           |
  |    <- |      <-    |        ALERT      |           |       |           |
  |       |      <-    |        RQNT       |           |       |           |
  |       |     Ack    |         ->        |           |       |           |
  |    <- |   Ringing  |                   |           |       |           |
  |       |            |                   |           |   <-  |     ANM   |
  |       |            |         <-        |     - -   |   ANM |           |
  |       |      <-    |      RQNT+MDCX    |           |       |           |
  |       |     Ack    |         ->        |           |       |           |
  |       |            |                   |           |   <-  |     REL   |
  |       |            |         <-        |     - -   |   REL |           |
  |       |      <-    |        DLCX       |           |       |           |
  |       |            |        DLCX       |     ->    |       |           |
  |       |     Perf   |                   |           |       |           |
  |       |     Data   |         ->        |           |       |           |
  |       |            |         <-        |    Perf   |       |           |
  |       |            |                   |    data   |       |           |
  |       |            |         RLC       |     - -   |   ->  |     ->    |
  |    <- |      <-    |        RLSE       |           |       |           |
  | RLCOM |      ->    |         ->        |           |       |           |
  |_______|____________|___________________|___________|_______|___________|


        The above diagram describes the call flow between a trunk with
        ISDN signaling in a business gateway and an SS7 trunk in a
        trunking gateway.

        This call flow assumes that the ISDN Q.931 signaling messages
        are "back-hauled" to the call agent.  The tunnelling protocol,
        together with configuration tables, allows the call agent to
        associate the signalling messages to the endpoint corresponding



Huitema, Andreasen, Arango, Prakash                            [Page 29]


Internet draft              MGCP Call Flows              20 January 1999


        to the B-channel. The specifics of the tunnelling protocol are
        being worked on by the IETF.

        The call is triggered by the arrival of a SETUP command, which
        is relayed to the Call Agent. The call agent analyzes teh com-
        mand, to obtain the destination (dn) and source (sn) party
        numbers. The call agent sends a call progress message, which is
        tunneled to the gateay and relayed over the D-Channel.  The Call
        Agent then seizes the incoming circuit, creating a connection:

                CRCX 1204 isdn-trunk-group-1/3@isdngw-45.whatever.net MGCP 0.1
                C: A3C47F21456789F0
                L: p:10, a:G.711;G.726-32
                M: recvonly


        The gateway immediately acknowledges the creation, sending back
        the identification of the newly created connection and the ses-
        sion descrip- tion used to receive audio data:


        200 1204 OK I:FDE234C8

        v=0 c=IN IP4 128.96.41.1 m=audio 3456 RTP/AVP 0 96 a=rtpmap:96
        G726-32/8000

        The Call Agent, having seized the incoming trunk and completed a
        routing look up to identify the outgoing gateway, seizes the
        outgoing trunk. It does so by sending a connection command to
        the egress gate- way:

                CRCX 1205 card23/21@trgw-7.whatever.net MGCP 0.1
                C: A3C47F21456789F0
                L: p:10, a:G.711;G.726-32
                M: sendrecv

                v=0
                c=IN IP4 128.96.41.1
                m=audio 3456 RTP/AVP 0 96
                a=rtpmap:96 G726-32/8000

        The SS7 trunking gateway acknowledges the connection command,
        sending in the session description its own parameters such as
        address, ports and RTP profile:

                200 1205 OK
                I:32F345E2




Huitema, Andreasen, Arango, Prakash                            [Page 30]


Internet draft              MGCP Call Flows              20 January 1999


                v=0
                c=IN IP4 128.96.63.25
                m=audio 1297 RTP/AVP 0 96
                a=rtpmap:96 G726-32/8000

        The Call Agent relays the information to the ingress gateway,
        using a ModifyConnection command:

                MDCX 1206 isdn-trunk-group-1/3@isdngw-45.whatever.net MGCP 0.1
                C: A3C47F21456789F0
                I:FDE234C8
                M: recvonly

                v=0
                c=IN IP4 128.96.63.25
                m=audio 1297 RTP/AVP 0 96
                a=rtpmap:96 G726-32/8000

        The business gateway immediately acknowledges the modification:

                200 1206 OK

        At this stage, the Call Agent has established a half duplex
        transmission path. The subscriber that originated the call will
        be able to receive signals, such as tones or announcements, that
        the remote switch may send through the trunking gateways.

        When the call progresses, the Call Agent will receive from the
        remote switch progress messages, for example an "address com-
        plete" message (ACM). The Call Agent will tunnel an ALERT mes-
        sage to the originating PBX.  It may, if needed, send a notifi-
        cation request command to the gateway, to generate alerting
        tones over the B-channel:

                RQNT 1207 isdn-trunk-group-1/3@isdngw-45.whatever.net MGCP 0.1
                X: 0123456789AE
                S: rt

        The gateway immediately acknowledges the command:

                200 1207 OK

        After the called user answers the call, the Call Agent will
        receive an answering message (ANM) from the CO switch. At that
        point, it will send a ModifyConnection command to the business
        gateway, to place the connection in full duplex mode, and an
        embedded NotificationRequest  to stop the ringing tones:




Huitema, Andreasen, Arango, Prakash                            [Page 31]


Internet draft              MGCP Call Flows              20 January 1999


                MDCX 1209 isdn-trunk-group-1/3@isdngw-45.whatever.net MGCP 0.1
                C: A3C47F21456789F0
                I: FDE234C8
                M: sendrecv
                X: 0123456789AF
                S:

        The business gateway will acknowledge the command:

                200 1209 OK

        At this point, the connection is established.

        When the Call Agent receives the REL message from the CO switch,
        it will have to tear down the call. It will do so by sending to
        both gateways a DeleteConnection command:

                DLCX 1210 isdn-trunk-group-1/3@isdngw-45.whatever.net MGCP 0.1
                C: A3C47F21456789F0
                I:FDE234C8

                DLCX 1211 card23/21@trgw-7.whatever.net MGCP 0.1
                C: A3C47F21456789F0
                I:32F345E2

        The gateways will respond with acknowledgements that should
        include a "call parameters" header fields:

        250 1210 OK P: PS=1245, OS=62345, PR=780, OR=45123, PL=10,
        JI=27, LA=48

        250 1211 OK P: PS=790, OS=45700, PR=1230, OR=61875, PL=15,
        JI=27, LA=48

        Having freed the local resource, the call agent will confirm the
        release by sending a RLC message to the next switch, and will
        also send a release message through the Q.931 tunnel to the PBX.
        The PBX will send back a release confirmation.

        Both gateways, at this point, are ready for the next call.











Huitema, Andreasen, Arango, Prakash                            [Page 32]


Internet draft              MGCP Call Flows              20 January 1999


        2.6.  Basic call with continuity test, TGW to RGW

            _______________________________________________________
           | CO |  SS7/|  TGW|      CA    |  CDB|  ACC|  RGW|  Usr|
           |    |  ISUP|     |            |     |     |     |     |
           |____|______|_____|____________|_____|_____|_____|_____|
           | IAM|   -> |     |            |     |     |     |     |
           |    |  IAM |  - -|      ->    |     |     |     |     |
           |    |      |     |    Check   |  -> |     |     |     |
           |    |      |     |      <-    |  IP |     |     |     |
           |    |      |  <- |   Create   |     |     |     |     |
           |    |      |     |  Connection|     |     |     |     |
           |    |      |  Ack|      ->    |     |     |     |     |
           | COT|   -> |     |            |     |     |     |     |
           |    |  COT |  - -|      ->    |     |     |     |     |
           |    |      |  <- |   Modify   |     |     |     |     |
           |    |      |     |  Connection|     |     |     |     |
           |    |      |     |   Create   |     |     |     |     |
           |    |      |     |  Connection|  - -|  - -|  -> |     |
           |    |      |     |      <-    |  - -|  - -|  Ack|     |
           |____|______|_____|____________|_____|_____|_____|_____|


        This diagram shows the various exchange of messages during the
        beginning of a call from a telephone user on the circuit-
        switched PSTN to a residential user connected to a residential
        gateway. During these exchanges the Call Agent uses MGCP to con-
        trol both the TGW and the residential gateway. The circuit
        switch decides to execute a continuity test during the call
        establishment. The exchanges occur on two sides.

        Upon reception of the IAM message, the Call Agent recognizes
        that a continuity test has been requested.  It immediately sends
        a CreateConnection request to the trunking gateway to connect to
        the incoming trunk, creating a connection:

                CRCX 1237 card23/21@trgw-7.whatever.net MGCP 0.1
                C: A3C47F21456789F0
                L: p:10, a:G.711;G.726-32
                M: conttest


        The trunking gateway recognizes that the mode is set to
        "conttest".  It places the circuit in "continuity test" mode,
        ready to send back the 2010 Hz return tone if it receives a 1780
        Hz tone. The gateway acknowledges the creation of the connec-
        tion, sending back the identification of the newly created con-
        nection and the session description used to receive audio data:



Huitema, Andreasen, Arango, Prakash                            [Page 33]


Internet draft              MGCP Call Flows              20 January 1999


                200 1237 OK
                I: FDE234C8

                v=0
                c=IN IP4 128.96.41.1
                m=audio 3456 RTP/AVP 0 96
                a=rtpmap:96 G726-32/8000


        At this point, the call agent is waiting for the result of the
        continuity test.  The calling switch is sending the test tone
        (1780 Hz); if it receives the return tone (2010 Hz), it will
        send a "continuity passed" message (COT).  At this point, the
        call agent will send a modify connection message to the gateway,
        in order to place the connection in "recvonly" mode:

                MDCX 1238 card23/21@trgw-7.whatever.net MGCP 0.1
                C: A3C47F21456789F0
                I: FDE234C8
                M: recvonly

        The gateway will immediately acknowledge that command:

                200 1238 OK


        The Call Agent will then proceed with the establishment of the
        call.























Huitema, Andreasen, Arango, Prakash                            [Page 34]


Internet draft              MGCP Call Flows              20 January 1999


        2.7.  Hairpin connection, regular set-up

        The figure below gives the flow that results in an hairpin con-
        nection on the same gateway.  In this flow, we assume that the
        exchange of messages is exactly comparable to what would happen
        in a call relayed between two trunking gateways, with the sole
        difference that the call will be relayed on a local connection.

                    ________________________________________
                   | sw1|  sw2|  SG |   CA |  TGW-1|  TGW-2|
                   |____|_____|_____|______|_______|_______|
                   | IAM|  - -|  -> |      |       |       |
                   |    |     |  IAM|  ->  |       |       |
                   |    |     |     |  CRCX|   ->  |       |
                   |    |     |     |    <-|   ACK |       |
                   |    |     |     |  CRCX|   - - |   ->  |
                   |    |     |     |    <-|   - - |   ACK |
                   |    |     |   <-|  IAM |       |       |
                   |    |   <-|  IAM|      |       |       |
                   |    |  ACM|  -> |      |       |       |
                   |    |     |  ACM|  ->  |       |       |
                   |    |     |   <-|  ACM |       |       |
                   |  <-|  - -|  ACM|      |       |       |
                   |    |  ...|     |      |       |       |
                   |    |  ANM|  -> |      |       |       |
                   |    |     |  ANM|  ->  |       |       |
                   |    |     |     |  MDCX|   ->  |       |
                   |    |     |     |    <-|   ACK |       |
                   |    |     |   <-|  ANM |       |       |
                   |  <-|  - -|  ANM|      |       |       |
                   | REL|  - -|  -> |      |       |       |
                   |    |     |  REL|  ->  |       |       |
                   |    |     |     |  DLCX|   ->  |       |
                   |    |     |     |    <-|   ACK |       |
                   |    |     |   <-|  RLC |       |       |
                   |  <-|  - -|  RLC|      |       |       |
                   |    |     |     |  DLCX|   ->  |       |
                   |    |     |     |    <-|  Perf |       |
                   |    |     |     |      |  data |       |
                   |    |     |   <-|  REL |       |       |
                   |    |   <-|  REL|      |       |       |
                   |    |  RLC|  -> |      |       |       |
                   |    |     |  RLC|  ->  |       |       |
                   |____|_____|_____|______|_______|_______|


        During these exchanges the MGCP is used by the Call Agent to
        control two endpoints located on the same TGW.



Huitema, Andreasen, Arango, Prakash                            [Page 35]


Internet draft              MGCP Call Flows              20 January 1999


        The exchanges start with the arrival from the first switch (SW1)
        of an SS7/ISUP "IAM" message, relayed by the signalling gateway
        to the Call Agent.  The call agent performs the routing, and
        determines that the call will have to be relayed towards the
        second switch (SW2), using a trunk located on the same gateway.

        The call agent starts the exchange by seizing the endpoint
        referenced in the IAM message:

                CRCX 1204 trunk-group-1/17@tgw.whatever.net MGCP 0.1
                C: A3C47F21456789F0
                L: nt=LOCAL
                M: recvonly


        Upon reception of that command, the trunking gateway prepares a
        "local" connection description.

                200 1204 OK
                I:FDE234C8

                v=0
                c=IN tgw.whatever.net trunk-group-1/17
                m=audio 0 LOCAL 0


        The call agent, upon reception of this acknowledgement, sends a
        connection request to the trunking gateway, asking the gateway
        to reserve a trunk in the group connected to the second switch:

                CRCX 1205 trunk-group-2/$@tgw.whatever.net MGCP 0.1
                C: A3C47F21456789F0
                L: nt=LOCAL
                M: sendrecv

                v=0
                c=IN tgw.whatever.net trunk-group-1/17
                m=audio 0 LOCAL 0


        The call agent selects a trunk in the group, and acknowledges
        the creation:

                200 1204 OK
                I:abc0

                v=0
                c=IN tgw.whatever.net trunk-group-2/13



Huitema, Andreasen, Arango, Prakash                            [Page 36]


Internet draft              MGCP Call Flows              20 January 1999


                m=audio 0 LOCAL 0


        The two commands have created a one way path, suitable for for-
        warding ring tones and announcements to the calling party.  The
        call agent can now relay the call by sending an IAM message to
        the second switch.  When the ACM is received, it is immediately
        relayed to the first switch.

        After some time, the call is answered, and an ANM message is
        relayed from the second switch to the call agent. The call agent
        will first validate the call by asking the first end-point to
        place the connection in duplex mode:

                MDCX 1206 trunk-group-1/17@tgw.whatever.net MGCP 0.1
                C: A3C47F21456789F0
                I:FDE234C8
                M: sendrecv

                v=0
                c=IN tgw.whatever.net trunk-group-2/13
                m=audio 0 LOCAL 0


        The trunking gateway executes and acknowledges the modification:

                200 1206 OK

                The call agent can now relay the ANM message to the cal-
                ling switch, and both parties can talk.

                At the end of the call, in our example, the calling
                party hangs up.  The first switch sends a release mes-
                sage to the call agent, through the signalling gateway.
                The call agent releases the connection on the first end-
                point:

                        DLCX 1207 trunk-group-1/17@tgw.whatever.net MGCP 0.1
                        C: A3C47F21456789F0
                        I:FDE234C8

                The gateway acknowledges the deletion, sending the con-
                nection parameters:

                        250 1217 OK
                        P: OS=62345, OR=62345

                The call agent can now confirm the release of the trunk,



Huitema, Andreasen, Arango, Prakash                            [Page 37]


Internet draft              MGCP Call Flows              20 January 1999


                sending an RLC message to the first switch.

                In parallel, the call agent releases the connection to
                the second endpoint:

                        DLCX 1208 trunk-group-2/13@tgw.whatever.net MGCP 0.1
                        C: A3C47F21456789F0
                        I:abc0


                The gateway acknowledges the deletion, sending the con-
                nection parameters:

                        250 1218 OK
                        P: OS=62345, OR=62345

                After receiving the acknowledgement, the call agent can
                relay the release message to the second switch. The
                switch will in turn acknowledge the release.
































Huitema, Andreasen, Arango, Prakash                            [Page 38]


Internet draft              MGCP Call Flows              20 January 1999


                2.8.  Hairpin connection, accelerated set-up

                The figure below gives the flow that results in an hair-
                pin connection on the same gateway.  Contrary to the
                previous example, we will assume that the call agent
                uses a special-case software, and takes full benefit of
                the call's locality to accelerate the call set-up.

                   _________________________________________________
                  |  User1  |    User2  |     RGW   |       CA     |
                  |_________|___________|___________|______________|
                  |         |           |     <--   |      RQNT    |
                  |         |           |    ACK    |       -->    |
                  | OFF HOOK|    ---    |     -->   |              |
                  |   <--   |     ---   |   dialtone|              |
                  | digits  |     ---   |    NTFY   |       -->    |
                  |         |           |           |              |
                  |         |           |     <--   |       ACK    |
                  |         |           |           |              |
                  |         |           |     <--   |   CRCX+RQNT, |
                  |         |    Ring   |     <--   |   CRCX+RQNT  |
                  |         |           |    ACK    |       -->    |
                  |         |           |    ACK    |       -->    |
                  |         |  OFF HOOK |    NTFY   |       -->    |
                  |         |           |     <--   |       ACK    |
                  |         |           |     <--   |      RQNT    |
                  |         |           |     ACK   |       -->    |
                  |         |           |           |              |
                  | on-hook |     ---   |    NTFY   |       -->    |
                  |         |           |     <--   |       ACK    |
                  |         |           |     <--   |    DLCX+RQNT |
                  |         |           |     <--   |      DLCX    |
                  |         |           |     ACK   |       -->    |
                  |         |           |     ACK   |       -->    |
                  |         |   on-hook |    NTFY   |       -->    |
                  |         |           |     <--   |       ACK    |
                  |         |           |     <--   |      RQNT    |
                  |         |           |     ACK   |       -->    |
                  |_________|___________|___________|______________|

                The first command is a NotificationRequest, sent by the
                Call Agent to the residential gateway. The request will
                consist of the following lines:

                        RQNT 1201 endpoint/1@rgw-2567.whatever.net MGCP 0.1
                        N: ca@ca1.whatever.net:5678
                        X: 0123456789AC
                        R: hd(E(dl;hu, D/[0-9#*T](D);)



Huitema, Andreasen, Arango, Prakash                            [Page 39]


Internet draft              MGCP Call Flows              20 January 1999


                        D: (0T|00T|[1-7]xxx|8xxxxxxx|#xxxxxxx|*xx|91xxxxxxxxxx|9011x.T)

                The gateway immediately acknowledges the command,
                repeating in the acknowledgement message the transaction
                id that the Call Agent attached to the query.

                        200 1201 OK


                When the off hook event is noticed, the gateway provides
                the dial tone to the line (the delay between off-hook
                and dialtone is thus minimal.) The gateway will then
                start accumulating digits according to that digit map.
                When it has noticed a sufficient set of values, it will
                notify the observed string to the Call Agent:

                        NTFY 2002 endpoint/1@rgw-2567.whatever.net MGCP 0.1
                        N: ca@ca1.whatever.net:5678
                        X: 0123456789AC
                        O: 912018294266


                The Call Agent immediately acknowledges that notifica-
                tion.

                        200 2002 OK


                The call agent analyzes the called number and determines
                that this is an hairpin connection: the called party is
                located on the same gateway, on endpoint/2.  The Cal-
                lAgent can prepare two simultaneous CreateConnection
                commands, creating the two legs of the connection.
                Because we are not too concerned at this stage with tax
                evasion, the The Call Agent will then seize the incoming
                circuit, creating a connection.  The create connection
                sent to the first endpoint piggybacks a notification
                request, to stop collecting digits yet continue watch
                for an on-hook transition. The CreateConnection sent to
                the second endpoint piggybacks a request to generate
                ringing and look for off-hook. Both commands can be sent
                in a single UDP packet:

                          CRCX 1204 endpoint/1@rgw-2567.whatever.net MGCP 0.1
                          C: A3C47F21456789F0
                          X: 0123456789AD
                          M: sendrecv
                          R: hu



Huitema, Andreasen, Arango, Prakash                            [Page 40]


Internet draft              MGCP Call Flows              20 January 1999


                          S:

                          v=0
                          c=LOCAL rgw-2567.whatever.net endpoint/2
                          m=audio 0 LOCAL 0
                          .
                          CRCX 1205 endpoint/2@rgw-2567.whatever.net MGCP 0.1
                          C: A3C47F21456789F0
                          X: 9875659876
                          M: sendrecv
                          R: hd
                          S: rg

                          v=0
                          c=LOCAL rgw-2567.whatever.net endpoint/1
                          m=audio 0 LOCAL 0


                     We should note that the call agent does not send
                     the local connection options since it knows that it
                     is a local (a.k.a. "hairpin") connection: the con-
                     nections are entirely described by the SDP text.

                The gateway immediately acknowledges the creations,
                sending back in two messages the identification of the
                newly created connections:

                          200 1204 OK
                          I:FDE234C8
                          .
                          200 1204 OK
                          I:9867659A


                The residential gateway, at that point, is instructed to
                look for an off-hook event on the second endpoint, and
                to report it. When the gateway notices the off hook
                event, it sends a Notify command to the Call Agent:

                          NTFY 2001 endpoint/1@rgw-2567.whatever.net MGCP 0.1
                          X: 9875659876
                          O: hd


                The Call Agent immediately acknowledges that notifica-
                tion:

                          200 2001 OK



Huitema, Andreasen, Arango, Prakash                            [Page 41]


Internet draft              MGCP Call Flows              20 January 1999


                The Call agent will now send a NotificationRequest com-
                mand to the gateway, asking to look for an off-hook
                event on the second end-point:

                          RQNT 1206 endpoint/2@rgw-2567.whatever.net MGCP 0.1
                          X: 987565989A
                          R: hu
                          S:

                The gateway acknowledges that command:

                          200 1206 OK

                At this point the call is active between the two
                residential gateway users.

                When the first user goes off hook, it sends a notifica-
                tion to the call agent:

                          NTFY 2010 endpoint/1@rgw-2567.whatever.net MGCP 0.1
                          X: 987565989A
                          O: hu

                The call agent acknowledges the notification.  It can,
                in a single UDP message, send the acknowledgement and
                the DeleteConnection commands that will clear the call.
                For the first gateway, the command embeds a notification
                request that readies that gateway for the next call:

                          200 2010 OK
                          .
                          DLCX 1210 endpoint/1@rgw-2567.whatever.net MGCP 0.1
                          C: A3C47F21456789F0
                          I: FDE234C8
                          N: ca@ca1.whatever.net:5678
                          X: 012345673FDE
                          R: hd(E(dl;hu, D/[0-9#*T](D);)
                          S:
                          .
                          DLCX 1211 endpoint/2@rgw-2567.whatever.net MGCP 0.1
                          C: A3C47F21456789F0
                          I: 9867659A
                          X: A3C5F0
                          R: hu
                          S:

                The gateway will acknowledge the commands in a single
                UDP message that will carry the "local connection"



Huitema, Andreasen, Arango, Prakash                            [Page 42]


Internet draft              MGCP Call Flows              20 January 1999


                version of the connection parameters.

                          250 1243 OK
                          P: OS=62345, OR=62345
                          .
                          250 1244 OK
                          P: OS=62345, OR=62345

                When the second user goes off hook, the gateway sends a
                Notify commands

                          NTFY 2020 endpoint/2@rgw-2567.whatever.net MGCP 0.1
                          X: A3C5F0
                          O: hu

                The Call agent follows with a notification requests,
                transmitted in the same packet as the acknowledgement,
                in order to ready the line for the next call:

                          200 2020 OK
                          .
                          RQNT 1220 enpoint/1@rgw-2567.whatever.net MGCP 0.1
                          N: ca@ca1.whatever.net:5678
                          X: 0123456793E5
                          R: hd(E(dl;hu, D/[0-9#*T](D);)
                          S:


                The gateway acknowledges the command, signalling that
                the second endpoint is now ready.

                          200 1220 OK



















Huitema, Andreasen, Arango, Prakash                            [Page 43]


Internet draft              MGCP Call Flows              20 January 1999


                2.9.  Hairpin connection, double end-point model

                The figure below gives the flow that results in an hair-
                pin connection on the same gateway.  In this flow, we
                assume that we use the "double endpoint" extensions to
                the create-connection command.

                        ________________________________________
                       | sw1|  sw2|  SG |   CA |  TGW-1|  TGW-2|
                       |____|_____|_____|______|_______|_______|
                       | IAM|  - -|  -> |      |       |       |
                       |    |     |  IAM|  ->  |       |       |
                       |    |     |     |  CRCX|   ->  |  (->) |
                       |    |     |     |    <-|   ACK |  (ACK)|
                       |    |     |   <-|  IAM |       |       |
                       |    |   <-|  IAM|      |       |       |
                       |    |  ACM|  -> |      |       |       |
                       |    |     |  ACM|  ->  |       |       |
                       |    |     |   <-|  ACM |       |       |
                       |  <-|  - -|  ACM|      |       |       |
                       |    |  ...|     |      |       |       |
                       |    |  ANM|  -> |      |       |       |
                       |    |     |  ANM|  ->  |       |       |
                       |    |     |   <-|  ANM |       |       |
                       |  <-|  - -|  ANM|      |       |       |
                       | REL|  - -|  -> |      |       |       |
                       |    |     |  REL|  ->  |       |       |
                       |    |     |     |  DLCX|   ->  |       |
                       |    |     |     |    <-|  Perf |       |
                       |    |     |     |      |  data |       |
                       |    |     |   <-|  RLC |       |       |
                       |  <-|  - -|  RLC|      |       |       |
                       |    |     |     |  DLCX|   ->  |       |
                       |    |     |     |    <-|  Perf |       |
                       |    |     |     |      |  data |       |
                       |    |     |   <-|  REL |       |       |
                       |    |   <-|  REL|      |       |       |
                       |    |  RLC|  -> |      |       |       |
                       |    |     |  RLC|  ->  |       |       |
                       |____|_____|_____|______|_______|_______|


                During these exchanges the MGCP is used by the Call
                Agent to control two endpoints located on the same TGW.

                The exchanges start with the arrival from the first
                switch (SW1) of an SS7/ISUP "IAM" message, relayed by
                the signalling gateway to the Call Agent.  The call



Huitema, Andreasen, Arango, Prakash                            [Page 44]


Internet draft              MGCP Call Flows              20 January 1999


                agent performs the routing, and determines that the call
                will have to be relayed towards the second switch (SW2),
                using a trunk located on the same gateway.

                The call agent starts the exchange by seizing the end-
                point referenced in the IAM message:

                        CRCX 1204 trunk-group-1/17@tgw.whatever.net MGCP 0.1
                        C: A3C47F21456789F0
                        L: nt=LOCAL
                        M: sendrecv
                        E2: trunk-group-2/$


                Upon reception of that command, the trunking gateway
                prepares a "local" connection description between the
                specified endpoint (trunk-group-1/17) and an endpoint
                that it selects within the secund trunk group (trunk-
                group-2/13).  The gateway acknowledges the two creations
                in a single message:

                        200 1204 OK
                        I:FDE234C8
                        Z2:trunk-group-2/13@tgw.whatever.net
                        I2:abc0


                The command has created a path, between the two end-
                points. The call agent can now relay the call by sending
                an IAM message to the second switch.  When the ACM is
                received, it is immediately relayed to the first switch.

                After some time, the call is answered, and an ANM mes-
                sage is relayed from the second switch to the call
                agent.  The call agent immediately relays the ANM mes-
                sage to the calling switch, and both parties can talk.

                At the end of the call, in our example, the calling
                party hangs up.  The first switch sends a release mes-
                sage to the call agent, through the signalling gateway.
                The call agent releases the connection on the first end-
                point:

                        DLCX 1207 trunk-group-1/17@tgw.whatever.net MGCP 0.1
                        C: A3C47F21456789F0
                        I:FDE234C8

                The gateway acknowledges the deletion, sending the



Huitema, Andreasen, Arango, Prakash                            [Page 45]


Internet draft              MGCP Call Flows              20 January 1999


                connection parameters:

                        250 1217 OK
                        P: OS=62345, OR=62345

                The call agent can now confirm the release of the trunk,
                sending an RLC message to the first switch.

                In parallel, the call agent releases the connection to
                the second endpoint:

                        DLCX 1208 trunk-group-2/13@tgw.whatever.net MGCP 0.1
                        C: A3C47F21456789F0
                        I:abc0


                The gateway acknowledges the deletion, sending the con-
                nection parameters:

                        250 1218 OK
                        P: OS=62345, OR=62345

                After receiving the acknowledgement, the call agent can
                relay the release message to the second switch. The
                switch will in turn acknowledge the release.


























Huitema, Andreasen, Arango, Prakash                            [Page 46]


Internet draft              MGCP Call Flows              20 January 1999


                3.  Interaction between an MGCP gateway and an H.323
                entity

                MGCP is not intended to replace H.323, or even to com-
                pete with it. In fact, we should mostly consider it as a
                tool to enable distributed implementations of H.323. The
                combination of gateways and call agent behaves as a dis-
                tributed H.323 system, using MGCP for internal communi-
                cation. This system appears to H.323 users as a larger
                H.323 system, or, if one prefers, as an H.323 gatekeeper
                that implements the Gatekeeper routed call model.

                In order to demonstrate the compatibility between MGCP
                and H.323, we provide here a step by step demonstration
                of 2 call set up scenarios:

                *    Call from an MGCP controlled residential gateway to
                     an H.323 entity,

                *    Call from an H.323 entity to an MGCP controlled
                     residential gateway.

                We suppose, in these scenarios, that the H.323 entity is
                capable of using the fast start procedure defined in
                H.323v2.


























Huitema, Andreasen, Arango, Prakash                            [Page 47]


Internet draft              MGCP Call Flows              20 January 1999


                3.1.  Call from a residential gateway (RGW) to an H.323
                user

         _____________________________________________________________________
        |     Usr    |     RGW   |       CA     |    H.323  |    Usr   |  GK |
        |____________|___________|______________|___________|__________|_____|
        |            |     <-    |      RQNT    |           |          |     |
        |            |     Ack   |       ->     |           |          |     |
        |            |           |              |           |          |     |
        |  Off-hook  |   Notify  |       ->     |           |          |     |
        |     <-     |     Ack   |              |           |          |     |
        | (Dial-tone)|     <-    |      RQNT    |           |          |     |
        |            |     Ack   |       ->     |           |          |     |
        |            |           |              |           |          |     |
        |   Digits   |   Notify  |       ->     |           |          |     |
        |     <-     |     Ack   |              |           |          |     |
        | (progress) |     <-    |   CRCX+RQNT  |           |          |     |
        |            |     Ack   |       ->     |           |          |     |
        |            |           |  (processing)|           |          |     |
        |            |           |    TCP-SYN   |     ->    |          |     |
        |            |           |       <-     |  SYN, ACK |          |     |
        |            |           |    Set-up+   |           |          |     |
        |            |           |   faststart  |     ->    |          |     |
        |            |           |              |     ARQ   |   - - -  |  -> |
        |            |           |              |     <-    |   - - -  |  ACF|
        |            |           |       <-     |  alerting |    ring  |     |
        |            |           |    TCP ACK   |     ->    |          |     |
        | (ring back)|     <-    |      RQNT    |           |          |     |
        |            |     Ack   |       ->     |           |          |     |
        |            |           |       <-     |  connect +|  off hook|     |
        |            |           |              |  faststart|          |     |
        |            |           |    TCP ACK   |     ->    |          |     |
        |            |     <-    |   MDCX+RQNT  |           |          |     |
        |            |     Ack   |       ->     |           |          |     |
        |            |           |  (call est.) |           |          |     |
        |   on hook  |   Notify  |       ->     |           |          |     |
        |     <-     |     Ack   |              |           |          |     |
        |     <-     |  DLCX+RQNT|              |           |          |     |
        |  perf data |     ->    |              |           |          |     |
        |            |           |    Rel. C.   |     ->    |          |     |
        |            |           |    TCP-FIN   |     ->    |          |     |
        |            |           |       <-     |  FIN, ACK |          |     |
        |            |           |    TCP ACK   |     ->    |          |     |
        |            |           |              |  (signal) |  On-hook |     |
        |            |           |              |     DRQ   |   - - -  |  -> |
        |            |           |              |     <-    |   - - -  |  DCF|
        |____________|___________|______________|___________|__________|_____|




Huitema, Andreasen, Arango, Prakash                            [Page 48]


Internet draft              MGCP Call Flows              20 January 1999


                During these exchanges the MGCP is used by the call
                agent to control the residential gateways. The call will
                be routed to an H.323 entity. The first command is a
                notification request, sent by the call agent to the
                residential gateway. The request will consist of the
                following lines:

                        RQNT 1201 endpoint/1@rgw-2567.whatever.net MGCP 0.1
                        N: ca@ca1.whatever.net:5678
                        X: 0123456789AB
                        R: hd


                The gateway, at that point, is instructed to look for an
                off-hook event, and to report it. It will first ack-
                nowledge the request, repeating in the acknowledgement
                message the transaction id that the call agent attached
                to the query.

                        200 1201 OK


                Note that this command is not actually simultaneous with
                the call. It can be issued long before the actual call,
                for example when the gateway is turned on, or after the
                end of a previous call.

                When the off hook event is noticed, the gateway sends a
                Notify command to the call agent:

                           NTFY 2001 endpoint/1@rgw-2567.whatever.net MGCP 0.1
                           N: ca@ca1.whatever.net:5678
                           X: 0123456789AB
                           O: hd


                The call agent immediately acknowledges that notifica-
                tion.

                           200 2001 OK


                The call agent examines the services associated to an
                off hook action (it could take special actions in the
                case of a direct line). In most cases, it will send a
                notification request, asking for digits. The current
                example provides the gateway with a digit map, and
                requests the gateway to play a dialtone:



Huitema, Andreasen, Arango, Prakash                            [Page 49]


Internet draft              MGCP Call Flows              20 January 1999



                           RQNT 1202 endpoint/1@rgw-2567.whatever.net MGCP 0.1
                           N: ca@ca1.whatever.net:5678
                           X: 0123456789AC
                           R: hu, [0-9#*T](D)
                           D: (0T | 00T | [1-7]xxx | 8xxxxxxx | #xxxxxxx | *xx | 91xxxxxxxxxx | 9011x.T)
                           S: dl


                The gateway immediately acknowledges that request.

                            200 1202 OK


                The gateway will start accumulating digits according to
                that digit map.  When it has noticed a sufficient set of
                values, it will notify the observed string to the call
                agent:

                           NTFY 2002 endpoint/1@rgw-2567.whatever.net MGCP 0.1
                           N: ca@ca1.whatever.net:5678
                           X: 0123456789AC
                           O: 912018294266


                The call agent immediately acknowledges that notifica-
                tion.

                           200 2002 OK


                At this stage, the call agent seizes the incoming cir-
                cuit, creating a connection.  It will also send together
                with that creation request a notification request, to
                stop collecting digits yet continue watch for an on-hook
                transition:

                           CRCX 1204 endpoint/1@rgw-2567.whatever.net MGCP 0.1
                           C: A3C47F21456789F0
                           L: p:10, a:G.711;G.726-32
                           M: recvonly
                           X: 0123456789AD
                           R: hu


                The gateway immediately acknowledges the creation, send-
                ing back the identification of the newly created connec-
                tion and the session description used to receive audio



Huitema, Andreasen, Arango, Prakash                            [Page 50]


Internet draft              MGCP Call Flows              20 January 1999


                data:

                           200 1204 OK
                           I:  FDE234C8

                           v=0
                           c=IN IP4 128.96.41.1
                           m=audio 3456 RTP/AVP 0


                The SDP announcement, in our example, specifies the
                address at which the gateway is ready to receive audio
                data (128.96.41.1), the transport protocol (RTP), the
                RTP port (3456) and the audio profile (AVP). The audio
                profile refers to RFC 1890, which defines that the pay-
                load type 0 has been assigned for G.711 transmission.

                The call agent, having seized the incoming trunk,
                proceeds with call routing. Using local databases, it
                determines that the dialed digits (912018294266)
                correspond to a H.323 entity. It will set up a TCP-IP
                connection and send an H.225/Q.931 "set-up" message to
                the H.323 entity. In this message, the "faststart" ele-
                ment carries a set of open logical channel proposals,
                derived from the SDP description received from the cal-
                ling gateway:

























Huitema, Andreasen, Arango, Prakash                            [Page 51]


Internet draft              MGCP Call Flows              20 January 1999



                        faststart-1 OpenLogicalChannel ::= {
                           forwardLogicalChannelNumber   1,
                           forwardLogicalChannelParameters {
                              dataType   g711Ulaw64k 160, -- 20 ms G.711 frame
                              multiplexParameters
                                 h2250LogicalChannelParameters H2250LogicalChannelParameters  {
                                     sessionID 1,
                                     silenceSuppression   FALSE
                                 }
                           }
                        }

                        faststart-2 OpenLogicalChannel ::= {
                           forwardLogicalChannelNumber   2,
                           forwardLogicalChannelParameters {
                              dataType              nullData, -- pro forma
                              multiplexParameters   none
                           },
                           reverseLogicalChannelParameters   {
                              dataType   g711Ulaw64k 160, -- 20 ms frame
                              multiplexParameters
                                 h2250LogicalChannelParameters H2250LogicalChannelParameters {
                                    sessionID 2,
                                    mediaChannel unicastAddress iPAddress {
                                       network  '80602901'H, -- 128.96.41.1
                                       tsapIdentifier 3456 -- port
                                    },
                                    mediaControlChannel unicastAddress iPAddress {
                                       network  '80602901'H, -- 128.96.41.1
                                       tsapIdentifier 3457 -- port
                                    },
                                    silenceSuppression FALSE
                                 }
                           }
                        }


                The H.323 alerts the user, and sends an H.225/Q.931
                "alerting" message.  On reception of this message, the
                call agent will send a notification request that
                instruct the RGW to generate alerting tones:

                           RQNT 1206 endpoint/1@rgw-2567.whatever.net MGCP 0.1
                           X: 0123456789AE
                           R: hu
                           S: v




Huitema, Andreasen, Arango, Prakash                            [Page 52]


Internet draft              MGCP Call Flows              20 January 1999


                When the called user accepts the call, the H.323 entity
                sends an H.225/Q.931

                set-up
                 message to the call agent. If the H.323 entity accepted
                the fast start procedure, the faststart
                 parameter will contain the confirmation of the open
                logical channel creations in the two directions of com-
                munication:

                        faststart-1 OpenLogicalChannel ::= {
                           forwardLogicalChannelNumber   1,
                           forwardLogicalChannelParameters {
                              dataType   g711Ulaw64k 160, -- 20 ms frame
                              multiplexParameters h2250LogicalChannelParameters {
                                 sessionID 1,
                                 mediaChannel unicastAddress iPAddress {
                                                 network  '80603F19'H,
                                                 tsapIdentifier 3456, -- port
                                 } ,
                                 mediaControlChannel unicastAddress iPAddress {
                                                 network  '80603F19'H,
                                                 tsapIdentifier 3457, -- port
                                 } ,
                                 silenceSuppression   FALSE
                              }
                          }
                        }
                        faststart-2 OpenLogicalChannel ::= {
                           forwardLogicalChannelNumber   2,
                           forwardLogicalChannelParameters {
                              dataType   g711Ulaw64k 160, -- 20 ms frame
                                    multiplexParameters h2250LogicalChannelParameters  {
                                        sessionID 2,
                                        silenceSuppression   FALSE
                                    }
                              }
                        }


                The call agent will send a modification request to the
                residential gateway, in order to establish a full duplex
                connection. The SDP payload, in that request, is derived
                from the parameters of the logical channel for transmis-
                sion from the gateway to the H.323 entity.






Huitema, Andreasen, Arango, Prakash                            [Page 53]


Internet draft              MGCP Call Flows              20 January 1999



                           MDCX 1209 endpoint/1@rgw-2567.whatever.net MGCP 0.1
                           C: A3C47F21456789F0
                           I:  FDE234C8
                           M: sendrecv
                           X: 0123456789AF
                           R: hu

                           v=0
                           c=IN IP4 128.96.63.25
                           m=audio 1296 RTP/AVP 0


                The gateway will acknowledge this request:

                           200 1209 OK


                At this point, the connection is established.

                In our example, the call is terminated when the calling
                party hangs up. This triggers a Notify command to the
                call agent:

                           NTFY 2005 endpoint/1@rgw-2567.whatever.net MGCP 0.1
                           X: 0123456789AF
                           O: hu


                After this notification, the call agent should send an
                acknowledgement:

                           200 2005 OK


                The call agent will then clear the call, by sending a
                delete connection request to the calling gateway. This
                request is combined with a notification request, to be
                ready to detect the next call issued by the residential
                gateway:

                           DLCX 1210 endpoint/1@rgw-2567.whatever.net MGCP 0.1
                           C: A3C47F21456789F0
                           I: FDE234C8
                           X: 0123456789B0
                           R: hd





Huitema, Andreasen, Arango, Prakash                            [Page 54]


Internet draft              MGCP Call Flows              20 January 1999


                The gateway will respond with a message that should
                include a "call parameters" header field:

                           250 1210 OK
                           P: PS=1245, OS=62345, PR=780, OR=45123, PL=10, JI=27, LA=48


                The call agent will in parallel sends an H.225/Q.931
                "release complete" message to the H.323 entity. It will
                then tear down the TCP-IP connection.  The gateway, at
                this point, is ready for the next call. The H.323 user
                will be ready as soon as the H.323 entity notices that
                the phone is back on hook.






































Huitema, Andreasen, Arango, Prakash                            [Page 55]


Internet draft              MGCP Call Flows              20 January 1999


                3.2.  Basic call, H.323 to RGW

          ___________________________________________________________________
         |  User |    H.323   |   GK  |       CA     |     RGW   |    Usr   |
         |_______|____________|_______|______________|___________|__________|
         |  call |      ->    |       |              |           |          |
         |       |     ARQ    |   ->  |              |           |          |
         |       |      <-    |   ACF |              |           |          |
         |       |   TCP SYN  |  - - -|       ->     |           |          |
         |       |      <-    |  - - -|    SYN+ACK   |           |          |
         |       |   set-up+  |       |              |           |          |
         |       |  fast start|  - - -|       ->     |           |          |
         |       |            |       |     (call    |           |          |
         |       |            |       |  processing) |           |          |
         |       |            |       |   CRCX+RQNT  |     ->    |    ring  |
         |       |            |       |       <-     |     Ack   |          |
         |       |      <-    |  - - -|    alerting  |           |          |
         |       |   TCP ACK  |  - - -|       ->     |           |          |
         |       |  (ringing) |       |              |           |          |
         |       |            |       |       <-     |   Notify  |  off hook|
         |       |            |       |      Ack     |     ->    |          |
         |       |            |       |      RQNT    |     ->    |          |
         |       |            |       |       <-     |     Ack   |          |
         |       |      <-    |  - - -|   connect +  |           |          |
         |       |            |       |   fast start |           |          |
         |       |   TCP ACK  |  - - -|       ->     |           |          |
         |       |            |       |     (call    |           |          |
         |       |            |       |  established)|           |          |
         |       |            |       |              |           |          |
         |       |            |       |       <-     |   Notify  |  on hook |
         |       |            |       |      Ack     |     ->    |          |
         |       |            |       |      (no     |           |          |
         |       |            |       |  suspension) |           |          |
         |       |            |       |      RQNT    |     ->    |          |
         |       |            |       |       <-     |     Ack   |          |
         | hangup|   detected |       |              |           |          |
         |       |   Rel. C.  |       |              |           |          |
         |       |   TCP FIN  |  - - -|       ->     |           |          |
         |       |      <-    |  - - -|    FIN ACK   |           |          |
         |       |            |       |   DLCX+RQNT  |     ->    |          |
         |       |            |       |       <-     |  perf data|          |
         |       |     DRQ    |   ->  |              |           |          |
         |       |      <-    |   DCF |              |           |          |
         |_______|____________|_______|______________|___________|__________|


                This diagram shows the various exchange of messages dur-
                ing a call from an H.323 user to a residential user.



Huitema, Andreasen, Arango, Prakash                            [Page 56]


Internet draft              MGCP Call Flows              20 January 1999


                During these exchanges the MGCP is used by the call
                agent to control the residential gateway.

                When the user initiates the call, the H.323 entity will
                perform a RAS transaction with its designated Gate-
                keeper. As a result of this transaction, it will learn
                the TCP-IP address of the call agent, and will set up a
                TCP-IP connection with the call agent. Once the TCP-IP
                connection is established, the H.323 entity sends a
                Q.931/H.225 connect message to the call agent. The mes-
                sage, in its user-to-user parameter, includes a "fast
                start" parameter that lists a set of OpenLogicalChannel
                proposals, such as for example:

                        faststart-1 OpenLogicalChannel ::= {
                           forwardLogicalChannelNumber   1,
                           forwardLogicalChannelParameters {
                              dataType   g711Ulaw64k 160, -- 20 ms G.711 frame
                              multiplexParameters h2250LogicalChannelParameters {
                                 sessionID 1,
                                 silenceSuppression   FALSE
                              }
                           }
                        }
                        faststart-2 OpenLogicalChannel ::= {
                           forwardLogicalChannelNumber   2,
                           forwardLogicalChannelParameters {
                              dataType   nullData, -- pro forma
                              multiplexParameters   none
                           },
                           reverseLogicalChannelParameters   {
                              dataType   g711Ulaw64k 160, -- 20 ms frame
                              multiplexParameters h2250LogicalChannelParameters {
                                 sessionID 2,
                                 mediaChannel unicastAddress iPAddress {
                                              network  '80602901'H, -- 128.96.41.1
                                              tsapIdentifier 3456, -- port
                                 },
                                 mediaControlChannel unicastAddress iPAddress {
                                              network  '80602901'H, -- 128.96.41.1
                                              tsapIdentifier 3457, -- port
                                 },
                                 silenceSuppression FALSE
                              }
                           }
                        }





Huitema, Andreasen, Arango, Prakash                            [Page 57]


Internet draft              MGCP Call Flows              20 January 1999


                Upon reception of the set-up message, the call agent
                will perform called routing functions and determine the
                end point that correspond to the called party number. It
                will reserve the outgoing circuit. It does so and at the
                same time it requests ringing, by sending to the
                residential gateway a create connection request combined
                with a notification request:

                           CRCX 1238 endpoint/1@rgw-2567.whatever.net MGCP 0.1
                           C: A3C47F21456789F0
                           L: p:10, a:G.711
                           M: sendrecv
                           X: 0123456789B1
                           R: hd
                           S: rg

                           v=0
                           c=IN IP4 128.96.41.1
                           m=audio 3456 RTP/AVP 0


                In this command, the SDP announcement is obtained by
                translating the "faststart" parameters corresponding to
                the receive channel announced by the caller - channel 2
                in our case. The IP address, RTP port and authorized
                payload are derived from the "reverseLogicalChannel-
                Parameters" data elements.  We derive the authorized
                payload type from the "dataType" element.  We have how-
                ever to check that this value is proposed in at least
                one of the forward channels.

                The gateway will acknowledge the connection request,
                sending in the session description its own parameters
                such as address, ports and RTP profile:

                           200 1238 OK
                           I:  32F345E2

                           v=0
                           c=IN IP4 128.96.63.25
                           m=audio 1296 RTP/AVP 0


                The phone is ringing, and the gateway, is instructed to
                look for an off-hook event, and to report it. The call
                agent sends an alerting message to the calling switch,
                which we assume will generate ringing tones for the cal-
                ling user.



Huitema, Andreasen, Arango, Prakash                            [Page 58]


Internet draft              MGCP Call Flows              20 January 1999


                When the off hook event is noticed, the gateway sends a
                Notify command to the call agent:

                           NTFY 2001 endpoint/1@rgw-2567.whatever.net MGCP 0.1X: 0123456789B0
                           O: hd


                The call agent immediately acknowledges that notifica-
                tion.

                           200 2001 OK


                The call agent must now ask the residential gateway to
                notify the occurrence of an on-hook event. It does so by
                sending a notification request to the residential gate-
                way:

                           RQNT 1241 endpoint/1@rgw-2567.whatever.net MGCP 0.1X: 0123456789B1
                           R: hu


                The gateway acknowledges that request:

                           200 1241 OK


                In parallel, the call agent will send a "connect" mes-
                sage to the H.323 agent. The message includes the "fast
                start" parameter, which will validate and complement the
                proposals that the caller sent:




















Huitema, Andreasen, Arango, Prakash                            [Page 59]


Internet draft              MGCP Call Flows              20 January 1999



                        faststart-1 OpenLogicalChannel ::= {
                           forwardLogicalChannelNumber   1,
                           forwardLogicalChannelParameters {
                              dataType   g711Ulaw64k 160, -- 20 ms frame
                              multiplexParameters h2250LogicalChannelParameters {
                                 sessionID 1,
                                 mediaChannel unicastAddress iPAddress {
                                                 network  '80603F19'H,
                                                 tsapIdentifier 3456, -- port
                                 } ,
                                 mediaControlChannel unicastAddress iPAddress {
                                                 network  '80603F19'H,
                                                 tsapIdentifier 3457, -- port
                                 } ,
                                 silenceSuppression   FALSE
                              }
                           }
                        }
                        faststart-2 OpenLogicalChannel ::= {
                           forwardLogicalChannelNumber   2,
                           forwardLogicalChannelParameters {
                              dataType   g711Ulaw64k 160, -- 20 ms frame
                              multiplexParameters h2250LogicalChannelParameters (
                                 sessionID 1,
                                 silenceSuppression   FALSE
                              }
                           }
                        }


                After some time, in our example, the residential user
                hangs up. The notify request is sent to the call agent:

                           NTFY 2005 endpoint/1@rgw-2567.whatever.net MGCP 0.1
                           X: 0123456789B1
                           O: hu


                The call agent acknowledges the notification.

                           200 2005 OK


                Upon reception of that notification, the call agent
                should send a "suspend" message to the calling H.323
                entity, but the Q.931 suspend message should not be sent
                in H.225. In order to preserve the user experience, the



Huitema, Andreasen, Arango, Prakash                            [Page 60]


Internet draft              MGCP Call Flows              20 January 1999


                call agent will simply initiate a timer, after which it
                would actually release the call. (In North-America, the
                call is not actually terminated if the called party
                hangs up. If it hangs down in a short interval, the call
                will be resumed.) The call agent, in any case, sends a
                notification request to the gateway, to look for an
                off-hook event.

                           RQNT 1243 endpoint/1@rgw-2567.whatever.net MGCP 0.1
                           X: 0123456789B2
                           R: hd


                The gateway will acknowledge this request:

                              200 1243 OK


                In our example, the calling user releases the call
                immediately. The H.323 agent sends a "release complete"
                message to the call agent, which will then send a delete
                connection request to the residential gateway.  The
                request sent to the gateway is combined with a request
                to detect a off-hook event, which will be used to detect
                rare conditions where the user would have gone off hook
                simultaneously with the release on the other side:

                           DLCX 1244 endpoint/1@rgw-2567.whatever.net MGCP 0.1
                           C: A3C47F21456789F0
                           X: 0123456789B3
                           R: hd
                           I:  FDE234C8


                The gateway will respond with a message that should
                include a "call parameters" header fields:

                           200 1244 OK
                           P: PS=1245, OS=62345, PR=780, OR=45123, PL=10, JI=27, LA=48


                The gateway, at this point, is ready for the next call.









Huitema, Andreasen, Arango, Prakash                            [Page 61]


Internet draft              MGCP Call Flows              20 January 1999


                4.  Interworking between SIP and MGCP

                The use of SDP in both MGCP and SIP makes interworking
                between these protocols very easy.  In order to demon-
                strate this interworking, we provide here a step by step
                demonstration of 2 call set-up scenarios:

                *    Call from an MGCP controlled residential gateway to
                     a SIP agent,

                *    Call from a SIP agent to an MGCP controlled
                     residential gateway.







































Huitema, Andreasen, Arango, Prakash                            [Page 62]


Internet draft              MGCP Call Flows              20 January 1999


                4.1.  Call from a residential gateway (RGW) to a SIP
                user

          ___________________________________________________________________
         |     Usr    |     RGW   |       CA     |       SIP      |    Usr  |
         |____________|___________|______________|________________|_________|
         |            |     <-    |      RQNT    |                |         |
         |            |     Ack   |       ->     |                |         |
         |            |           |              |                |         |
         |  Off-hook  |   Notify  |       ->     |                |         |
         |            |     <-    |              |                |         |
         |     Ack    |           |              |                |         |
         | (Dial-tone)|     <-    |      RQNT    |                |         |
         |            |     Ack   |       ->     |                |         |
         |            |           |              |                |         |
         |    Digit   |   Notify  |       ->     |                |         |
         |            |     <-    |      Ack     |                |         |
         | (progress) |     <-    |              |                |         |
         |  CRCX+RQNT |           |              |                |         |
         |            |     Ack   |       ->     |                |         |
         |            |           |  (processing)|                |         |
         |            |           |     INVITE   |        ->      |         |
         |    ring    |           |              |                |         |
         |            |           |       <-     |    resp. 180   |         |
         |            |           |              |    (ringing)   |         |
         |  (ringing) |     <-    |      RQNT    |                |         |
         |            |     Ack   |       ->     |                |         |
         |            |           |              |                |         |
         |            |           |       <-     |  resp. 200 (OK)|         |
         |  off hook  |           |              |                |         |
         |            |           |      Ack     |        ->      |         |
         |            |     <-    |   MDCX+RQNT  |                |         |
         |            |     Ack   |       ->     |                |         |
         |            |           |     (call    |                |         |
         |            |           |  established)|                |         |
         |   on hook  |   Notify  |       ->     |                |         |
         |            |     <-    |      Ack     |                |         |
         |            |     <-    |   DLCX+RQNT  |                |         |
         |            |  perf data|       ->     |                |         |
         |            |           |      BYE     |        ->      |         |
         |            |           |       <-     |  resp. 200 (OK)|         |
         |            |           |              |     (local)    |  On-hook|
         |____________|___________|______________|________________|_________|


                During these exchanges the MGCP is used by the call
                agent to control the residential gateways. The call will
                be routed to a SIP agent. The first command is a



Huitema, Andreasen, Arango, Prakash                            [Page 63]


Internet draft              MGCP Call Flows              20 January 1999


                notification request, sent by the call agent to the
                residential gateway.  The request will consist of the
                following lines:

                           RQNT 1201 endpoint/1@rgw-2567.whatever.net MGCP 0.1
                           N: ca@ca1.whatever.net:5678
                           X: 0123456789AB
                           R: hd


                The gateway, at that point, is instructed to look for an
                off-hook event, and to report it.  It will first ack-
                nowledge the request, repeating in the acknowledgement
                message the transaction id that the call agent attached
                to the query.

                           200 1201 OK


                     Note that this command is not actually simultaneous
                     with the call. It can be issued long before the
                     actual call, for example when the gateway is turned
                     on, or after the end of a previous call.

                When the off hook event is noticed, the gateway ini-
                tiates a notification request to the call agent:

                           NTFY 2001 endpoint/1@rgw-2567.whatever.net MGCP 0.1
                           N: ca@ca1.whatever.net:5678
                           X: 0123456789AB
                           O: hd


                The call agent immediately acknowledges that notifica-
                tion.

                           200 2001 OK


                The call agent examines the services associated to an
                off hook action (it could take special actions in the
                case of a direct line).  In most cases, it will send a
                notification request, asking for digits. It will also
                provide the gateway with a digit map, and requests the
                gateway to play a dialtone:






Huitema, Andreasen, Arango, Prakash                            [Page 64]


Internet draft              MGCP Call Flows              20 January 1999



                           RQNT 1202 endpoint/1@rgw-2567.whatever.net MGCP 0.1
                           N: ca@ca1.whatever.net:5678
                           X: 0123456789AC
                           R: hu, D/[0-9#*T](D)
                           D: (0T | 1xxxxxxxxxx | [2-9]xxxxxx | [4789]11 | 011x.T)
                           S: dl


                The gateway immediately acknowledges that request.

                           200 1202 OK


                The gateway will start accumulating digits according to
                that digit map. When it has noticed a sufficient set of
                values, it will notify the observed string to the call
                agent:

                           NTFY 2002 endpoint/1@rgw-2567.whatever.net MGCP 0.1
                           N: ca@ca1.whatever.net:5678
                           X: 0123456789AC
                           O: 912018294266


                The call agent immediately acknowledges that notifica-
                tion.

                           200 2002 OK


                At this stage, the call agent seizes the incoming cir-
                cuit, creating a connection. It will also send together
                with that creation request a notification request, to
                stop collecting digits yet continue watch for an on-hook
                transition:

                           CRCX 1204 endpoint/1@rgw-2567.whatever.net MGCP 0.1
                           C: A3C47F21456789F0
                           L: p:10, a:G.711;G.726-32
                           M: recvonly
                           X: 0123456789AD
                           R: hu


                The gateway immediately acknowledges the creation, send-
                ing back the identification of the newly created connec-
                tion and the session description used to receive audio



Huitema, Andreasen, Arango, Prakash                            [Page 65]


Internet draft              MGCP Call Flows              20 January 1999


                data:

                           200 1204 OK
                           I:FDE234C8

                           v=0
                           c=IN IP4 128.96.41.1
                           m=audio 3456 RTP/AVP 0 96
                           a=rtpmap:96 G726-32/8000


                The SDP announcement, in our example, specifies the
                address at which the gateway is ready to receive audio
                data (128.96.41.1), the transport protocol (RTP), the
                RTP port (3456) and the audio profile (AVP).  The audio
                profile refers to RFC 1890, which defines that the pay-
                load type 0 has been assigned for G.711 transmission.
                The gateway is also ready to use ADPCM encoding at 32
                kbps (G.726 -4). There is no standard payload type asso-
                ciated to ADPCM, so the gateway mentions its readiness
                to use a non standard payload associated to the dynamic
                type 96. The "rtpmap" attribute entry associates the
                payload type 96 to G726-32/4.

                The call agent, having seized the incoming trunk,
                proceeds with call routing.  Using local databases, it
                determines that the dialed digits (912018294266)
                correspond to a SIP agent.  It will send an invitation
                to that agent:

                           INVITE sip:huitema@sip-station.bellcore.com SIP/2.0
                           Via: SIP/2.0/UDP 128.96.41.12
                           From: sip:123456789@ca.whatever.net
                           To: Christian Huitema <huitema@sip-station.bellcore.com>
                           Call-ID: A3C47F21456789F0@ca.whatever.net
                           Cseq: 1 INVITE
                           Content-type: application/sdp
                           Content-Length: ...

                           v=0
                           c=IN IP4 128.96.41.1
                           m=audio 3456 RTP/AVP 0 96
                           a=rtpmap:96 G726-32/8000


                The SDP attachment, in the INVITE message, is directly
                copied from the acknowledgement of the Create Connection
                request. The SIP agent alerts the user, and sends an



Huitema, Andreasen, Arango, Prakash                            [Page 66]


Internet draft              MGCP Call Flows              20 January 1999


                immediate acknowledgement:

                           SIP/2.0 180 Ringing
                           Via: SIP/2.0/UDP 128.96.41.12
                           From: Christian Huitema <huitema@sip-station.bellcore.com>
                           To: 123456789@ca.whatever.net
                           Call-ID: A3C47F21456789F0@ca.whatever.net
                           Cseq: 1 INVITE


                The call agent will send a notification request that
                instruct the RGW to generate alerting tones:

                           RQNT 1206 endpoint/1@rgw-2567.whatever.net MGCP 0.1
                           X: 0123456789AE
                           R: hu
                           S: v


                When the called user accepts the call, the SIP agent
                sends an acceptation message to the call agent:

                           SIP/2.0 200 OK
                           Via: SIP/2.0/UDP 128.96.41.12
                           From: "Christian Huitema" <sip:huitema@sip-station.bellcore.com>
                           To: sip:123456789@ca.whatever.net
                           Call-ID: A3C47F21456789F0@ca.whatever.net
                           CSeq: 1 INVITE
                           Content-type: application/sdp
                           Content-Length:...

                           v=0
                           c=IN IP4 128.96.63.25
                           m=audio 1296 RTP/AVP 0 96
                           a=rtpmap:96 G726-32/8000


                The gateway immediately acknowledges the call set up:

                           ACK huitema@sip-station.bellcore.com SIP/2.0
                           Via: SIP/2.0/UDP 128.96.41.12
                           From: 123456789@ca.whatever.net
                           To: huitema@sip-station.bellcore.com (Christian Huitema)
                           Call-ID: 187602141351@ca.whatever.net


                Then, the call agent will send a modification request to
                the residential gateway, in order to establish a full



Huitema, Andreasen, Arango, Prakash                            [Page 67]


Internet draft              MGCP Call Flows              20 January 1999


                duplex connection.  The SDP payload, in that request, is
                copied from the SIP agent's response:


                           MDCX 1209 endpoint/1@rgw-2567.whatever.net MGCP 0.1
                           C: A3C47F21456789F0
                           I:FDE234C8
                           M: sendrecv
                           X: 0123456789AF
                           R: hu

                           v=0
                           c=IN IP4 128.96.63.25
                           m=audio 1296 RTP/AVP 0 96
                           a=rtpmap:96 G726-32/8000
                           +


                The gateway will acknowledge this request:

                           200 1209 OK


                At this point, the connection is established.  In our
                example, the call is terminated when the calling party
                hangs up.  This triggers a Notify command to the call
                agent:


                           NTFY 2005 endpoint/1@rgw-2567.whatever.net MGCP 0.1
                           X: 0123456789AF
                           O: hu


                After this notification, the call agent should send an
                acknowledgement:


                           200 2005 OK


                The call agent will then clear the call, by sending a
                delete connection request to the calling gateway.  This
                request is combined with a notification request, to be
                ready to detect the next call issued by the residential
                gateway:





Huitema, Andreasen, Arango, Prakash                            [Page 68]


Internet draft              MGCP Call Flows              20 January 1999



                           DLCX 1210 endpoint/1@rgw-2567.whatever.net MGCP 0.1
                           C: A3C47F21456789F0

                           I:FDE234C8
                           X: 0123456789B0
                           R: hd


                The gateway will respond with a message that should
                include a "call parameters" header field:


                           250 1210 OK
                           P: PS=1245, OS=62345, PR=780, OR=45123, PL=10, JI=27, LA=48


                The call agent will in parallel sends a BYE request to
                the SIP agent:

                            BYE sip:huitema@sip-station.bellcore.com SIP/2.0
                            Via: SIP/2.0/UDP 128.96.41.12
                            From: sip:123456789@ca.whatever.net
                            To: "Christian Huitema" <sip:huitema@sip-station.bellcore.com>
                            Call-ID: A3C47F21456789F0@ca.whatever.net
                            CSeq: 2 BYE


                The SIP agent will acknowledge that request:

                           SIP/2.0 200 OK
                           Via: SIP/2.0/UDP 128.96.41.12
                           From: "Christian Huitema" <sip:huitema@sip-station.bellcore.com>
                           To: sip:123456789@ca.whatever.net
                           Call-ID: A3C47F21456789F0@ca.whatever.net
                           CSeq: 2 BYE  SIP/2.0 200 OK


                The gateway, at this point, is ready for the next call.
                The SIP user will be ready as soon as the SIP agent
                notices that the phone is back on hook.










Huitema, Andreasen, Arango, Prakash                            [Page 69]


Internet draft              MGCP Call Flows              20 January 1999


                4.2.  Basic call, SIP to RGW

            _______________________________________________________________
           |  User |  SIP agent|         CA        |     RGW   |    Usr   |
           |_______|___________|___________________|___________|__________|
           |  call |     ->    |                   |           |          |
           |       |   INVITE  |         ->        |           |          |
           |       |           |  (call processing)|           |          |
           |       |           |      CRCX+RQNT    |     ->    |          |
           |  ring |           |                   |           |          |
           |       |           |         <-        |           |          |
           |  Ack  |           |                   |           |          |
           |       |     <-    |     resp. 180     |           |          |
           |       |  (ringing)|      (ringing)    |           |          |
           |       |           |         <-        |   Notify  |  off hook|
           |       |           |         Ack       |     ->    |          |
           |       |           |        RQNT       |     ->    |          |
           |       |           |         <-        |     Ack   |          |
           |       |     <-    |   resp. 200 (OK)  |           |          |
           |       |     ACK   |         ->        |           |          |
           |       |           |        (call      |           |          |
           |       |           |    established)   |           |          |
           |       |           |                   |           |          |
           |       |           |         <-        |   Notify  |  on hook |
           |       |           |         Ack       |     ->    |          |
           |       |           |      (no susp.    |           |          |
           |       |           |       message)    |           |          |
           |       |           |        RQNT       |     ->    |          |
           |       |           |         <-        |     Ack   |          |
           |       |           |                   |           |          |
           | hangup|  detected |                   |           |          |
           |       |     BYE   |         ->        |           |          |
           |       |           |      DLCX+RQNT    |     ->    |          |
           |       |           |         <-        |  perf data|          |
           |_______|___________|___________________|___________|__________|


                This diagram shows the various exchange of messages dur-
                ing a call from a
                 SIP user to a residential user.  During these exchanges
                the MGCP is used by the call agent to control the
                residential gateway.

                When the user initiates the call, the SIP agent will
                send an invitation to the call agent. (Our diagram
                assumes that the SIP agent sends that invitation
                directly; in fact, there could be several relays.) An
                example of invitation could be:



Huitema, Andreasen, Arango, Prakash                            [Page 70]


Internet draft              MGCP Call Flows              20 January 1999



                           INVITE sip:watson@boston.bell-telephone.com SIP/2.0
                           Via: SIP/2.0/UDP 169.130.12.5
                           From: "A. Bell" <sip:a.g.bell@bell-telephone.com>
                           To: "T. A. Watson" <sip:watson@bell-telephone.com>
                           Call-ID: 187602141351@worcester.bell-telephone.com
                           CSeq: 1 INVITE
                           Subject: Mr. Watson, come here.
                           Content-type: application/sdp
                           Content-Length: ...

                           v=0
                           o=bell 53655765 2353687637 IN IP4 128.3.4.5
                           c=IN IP4 135.180.144.94
                           m=audio 3456 RTP/AVP 0 3 4 5


                Upon reception of the set-up message, the call agent
                will perform call routing functions and determine the
                end point that corresponds to the invited user.  It will
                then reserve the outgoing circuit.  It does so at the
                same time that it requests ringing, by sending to the
                residential gateway a connection request combined with a
                notification request:


                           CRCX 1238 endpoint/1@rgw-2567.whatever.net MGCP 0.1
                           C: A3C47F21456789F0
                           L: p:10, a:G.711
                           M: sendrecv
                           X: 0123456789B1
                           R: hd
                           S: rg

                           v=0
                           o=bell 53655765 2353687637 IN IP4 128.3.4.5
                           c=IN IP4 135.180.144.94
                           m=audio 3456 RTP/AVP 0 3 4 5


                In this command, the SDP announcement is directly copied
                from the invitation. The gateway will acknowledge the
                connection request, sending in the session description
                its own parameters such as address, ports and RTP pro-
                file:






Huitema, Andreasen, Arango, Prakash                            [Page 71]


Internet draft              MGCP Call Flows              20 January 1999



                           200 1238 OK
                           I:32F345E2

                           v=0
                           c=IN IP4 128.96.63.25
                           m=audio 1296 RTP/AVP 0 3


                The phone is ringing, and the gateway, is instructed to
                look for an off-hook event, and to report it.  The call
                agent sends an alerting message to the calling SIP
                agent, which will generate ringing tones for the calling
                user:

                           SIP/2.0 180 Ringing
                           Via: SIP/2.0/UDP 169.130.12.5
                           From: "A. Bell" <sip:a.g.bell@bell-telephone.com>
                           To: sip:watson@bell-telephone.com
                           Call-ID: 187602141351@worcester.bell-telephone.com
                           CSeq: 1 INVITE


                When the off hook event is noticed, the gateway ini-
                tiates a notification request to the call agent:


                           NTFY 2001 endpoint/1@rgw-2567.whatever.net MGCP 0.1
                           X: 0123456789B0
                           O: hd


                The call agent immediately acknowledges that notifica-
                tion.


                           200 2001 OK


                The call agent must now ask the residential gateway to
                notify the occurrence of an on-hook event.  It does so
                by sending a notification request to the residential
                gateway:


                           RQNT 1241 endpoint/1@rgw-2567.whatever.net MGCP 0.1
                           X: 0123456789B1
                           R: hu



Huitema, Andreasen, Arango, Prakash                            [Page 72]


Internet draft              MGCP Call Flows              20 January 1999


                The gateway acknowledges that request:

                           200 1241 OK


                In parallel, the call agent will send a final answer to
                the SIP agent. The message, in its payload, copies the
                SDP announcement that was sent by the gateway:

                           SIP/2.0 200 OK
                           From: "A. Bell" <sip:a.g.bell@bell-telephone.com>
                           To: sip:watson@bell-telephone.com
                           Call-ID: 187602141351@worcester.bell-telephone.com
                           CSeq: 1 INVITE
                           Contact: sip://watson@boston.bell-telephone.com
                           Content-Length: ...

                           v=0
                           c=IN IP4 128.96.63.25
                           m=audio 1296 RTP/AVP 0 3


                The SIP agent acknowledges the set-up:

                           ACK sip:watson@boston.bell-telephone.com SIP/2.0
                           Via: SIP/2.0/UDP 169.130.12.5
                           From: "A. Bell" <sip:a.g.bell@bell-telephone.com>
                           To: "T. A. Watson" <sip:watson@bell-telephone.com>
                           Call-ID: 187602141351@worcester.bell-telephone.com
                           CSeq: 1 ACK


                At this point, the call is established.  After some
                time, in our example, the residential user hangs up. The
                notify request is sent to the call agent:

                           NTFY 2005 endpoint/1@rgw-2567.whatever.net MGCP 0.1
                           X: 0123456789B1
                           O: hu


                The call agent acknowledges the notification.

                           200 2005 OK


                Upon reception of that notification, the call agent
                should send a "suspend" message to the calling SIP



Huitema, Andreasen, Arango, Prakash                            [Page 73]


Internet draft              MGCP Call Flows              20 January 1999


                agent, but there is no such message in SIP. In order to
                preserve the user experience, the call agent will simply
                initiate a timer, after which it would actually release
                the call. (In North-America, the call is not actually
                terminated if the called party hangs up.  If it hangs
                down in a short interval, the call will be resumed.) The
                call agent, in any case, sends a notification request to
                the gateway, to look for an off-hook event.

                           RQNT 1243 endpoint/1@rgw-2567.whatever.net MGCP 0.1
                           X: 0123456789B2
                           R: hd


                The gateway will acknowledge this request:

                           200 1243 OK


                In our example, the calling user releases the call
                immediately. The SIP agent sends a BYE message to the
                call agent:

                           BYE sip:watson@boston.bell-telephone.com SIP/2.0
                           Via: SIP/2.0/UDP 169.130.12.5
                           From: "A. Bell" <sip:a.g.bell@bell-telephone.com>
                           To: "T. A. Watson" <sip:watson@bell-telephone.com>
                           Call-ID: 187602141351@worcester.bell-telephone.com
                           CSeq: 2 BYE


                The call agent acknowledges that message:

                           SIP/2.0 200 OK
                           From: "A. Bell" <sip:a.g.bell@bell-telephone.com>
                           To: sip:watson@bell-telephone.com
                           Call-ID: 187602141351@worcester.bell-telephone.com
                           CSeq: 2 BYE


                The call agent then sends a delete connection request to
                the residential gateway. The request sent to the gateway
                is combined with a request to detect a off-hook event,
                which will be used to detect rare conditions where the
                user would have gone off hook simultaneously with the
                release on the other side:





Huitema, Andreasen, Arango, Prakash                            [Page 74]


Internet draft              MGCP Call Flows              20 January 1999



                           DLCX 1244 endpoint/1@rgw-2567.whatever.net MGCP 0.1
                           C: A3C47F21456789F0
                           X: 0123456789B3
                           R: hd
                           I:FDE234C8


                The gateway will respond with a message that should
                include a "call parameters" header fields:

                           200 1244 OK
                           P: PS=1245, OS=62345, PR=780, OR=45123, PL=10, JI=27, LA=48


                The gateway, at this point, is ready for the next call.



































Huitema, Andreasen, Arango, Prakash                            [Page 75]


Internet draft              MGCP Call Flows              20 January 1999


                5.  Data calls

                We present here a set of call flows corresponding to
                data calls:

                *    Basic data call,

                *    Outgoing data call through a NAS,

                *    Call back, using a NAS,

                *    Data call to a NAS, using L2TP,

                *    Basic data call with continuity test.





































Huitema, Andreasen, Arango, Prakash                            [Page 76]


Internet draft              MGCP Call Flows              20 January 1999


                5.1.  Basic data call to a NAS

        _______________________________________________________________________
       |     PC    |  CO |  SS7/|      NAS    |        CA      |  ACC|  Radius|
       |           |     |  ISUP|             |                |     |        |
       |___________|_____|______|_____________|________________|_____|________|
       |  dials in |     |      |             |                |     |        |
       |           |  IAM|   -> |             |                |     |        |
       |           |     |  IAM |      - -    |        ->      |     |        |
       |           |     |      |             |  Check called  |     |        |
       |           |     |      |             |     number.    |     |        |
       |           |     |      |             |     Notices    |     |        |
       |           |     |      |             |    data call.  |     |        |
       |           |     |      |             |    Call start  |  -> |        |
       |           |     |      |      <-     |      Create    |     |        |
       |           |     |      |             |    Connection  |     |        |
       |           |     |      |             |      (data)    |     |        |
       |           |     |      |      Ack    |        ->      |     |        |
       |           |     |      |             |   Connection   |     |        |
       |           |     |      |             |  is completed. |     |        |
       |           |     |      |             |      Call      |     |        |
       |           |     |      |             |   established  |  -> |        |
       |           |     |   <- |      - -    |       ANM      |     |        |
       |           |  <- |  ANM |             |                |     |        |
       |   modem   |  - -|  - - |      ->     |                |     |        |
       |     <-    |  - -|  - - |   handshake |                |     |        |
       |    PPP    |  - -|  - - |      ->     |                |     |        |
       |           |     |      |    obtain   |                |     |        |
       |           |     |      |   user-id,  |                |     |        |
       |           |     |      |   password  |                |     |        |
       |           |     |      |     Check   |       - -      |  - -|    ->  |
       |           |     |      |      <-     |       - -      |  - -|   Ack  |
       |     <-    |  - -|  - - |  Validates  |                |     |        |
       |           |     |      |    call,    |                |     |        |
       |     <-    |  - -|  - - |   procures  |                |     |        |
       |           |     |      |      IP     |                |     |        |
       |           |     |      |    address  |                |     |        |
       | Connected |     |      |             |                |     |        |
       |    to     |     |      |             |                |     |        |
       |    the    |     |      |             |                |     |        |
       |  Internet |     |      |             |                |     |        |
       |___________|_____|______|_____________|________________|_____|________|









Huitema, Andreasen, Arango, Prakash                            [Page 77]


Internet draft              MGCP Call Flows              20 January 1999


             ______________________________________________________________
            |     PC     |  CO |  SS7/|   NAS |      CA    |  ACC|  Radius|
            |            |     |  ISUP|       |            |     |        |
            |____________|_____|______|_______|____________|_____|________|
            |   Closes   |     |      |       |            |     |        |
            | connection.|     |      |       |            |     |        |
            |            |  REL|   -> |       |            |     |        |
            |            |     |  REL |   - - |      ->    |     |        |
            |            |     |      |   <-  |   Delete   |     |        |
            |            |     |      |       |  Connection|     |        |
            |            |     |      |  Perf |            |     |        |
            |            |     |      |  data |      ->    |     |        |
            |            |     |   <- |  - -  |     RLC    |     |        |
            |            |  <- |  RLC |       |            |     |        |
            |            |     |      |       |   Call end |  -> |        |
            |____________|_____|______|_______|____________|_____|________|


                This diagram shows the exchange of messages during a
                call from a modem user to an Internet Service Provider,
                using a trunking gateway that doubles as a Network
                Access Server. During these exchanges the MGCP is used
                by the Call Agent to control both the trunking gateway.
                Since there is no "other end" of the call, only the
                trunk gateway is involved in the call.

                Upon reception of the IAM message, the Call Agent deter-
                mines that the call is a data call (e.g., by bearer
                capability, the called number, etc.). Using configura-
                tion databases, the Call Agent selects the type of modem
                parameters and authentication parameters that correspond
                to the called number and to the calling number. It uses
                this knowledge to send a CreateConnection command to the
                NAS, programming the incoming trunk:

                        CRCX 1237 card23/21@trgw-7.whatever.net MGCP 0.1
                        C: A3C47F21456789F0
                        M: data
                        X: 0123456789B1
                        R: cl, ax

                        v=0
                        m=nas/radius
                        c=IN IP4 radius.example.net
                        a=bearer:v.32
                        a=framing:ppp-asynch
                        a=dialed:18001234567
                        a=dialing:2345678901



Huitema, Andreasen, Arango, Prakash                            [Page 78]


Internet draft              MGCP Call Flows              20 January 1999


                The trunking gateway checks that it has adequate
                resources for the call. If the trunking gateway did not
                have adequate resources, for example if it could not
                support the requested modem type, it should refuse the
                creation and send an error response to the Call Agent.
                If the gateway has sufficient resources, it immediately
                acknowledges the creation, sending back the identifica-
                tion of the newly created connection. (There is no need
                to transmit a session description in the case of a data
                call.)

                        200 1237 OK
                        I: FDE234C8


                The Call Agent, knowing that this is a data call, can
                immediately acknowledge the establishment of the connec-
                tion, sending an ANM message back to the calling switch.

                The trunk gateway connects the incoming trunk to a DSP
                loaded with the specified modem code. Once the call is
                established, the modem of the calling PC will start a
                training sequence with the modem associated to the trunk
                in the trunk gateway. The caller will then proceed to a
                normal PPP synchronization, which probably implies a PPP
                login. The authentication parameters, in our example,
                are checked using Radius. The Radius server that will be
                used is typically chosen as a function of the called
                number, which identifies the data service that the cal-
                ling modem requested. In fact, the number can also be
                used to identify the specific form of authentication
                that is requested (but not usually).

                In our example, the call is completed when the calling
                modem hangs up. This triggers an ISUP release message,
                which is forwarded to the Call Agent. The Call Agent
                will request the NAS to delete the connection:

                        DLCX 1244 card23/21@trgw-7.whatever.net MGCP 0.1
                        C: A3C47F21456789F0
                        I: FDE234C8


                The gateways will respond with a message that should
                include a "call parameters" header fields:

                        250 1244 OK
                        P: PS=1245, OS=62345, PR=780, OR=45123



Huitema, Andreasen, Arango, Prakash                            [Page 79]


Internet draft              MGCP Call Flows              20 January 1999


                We should note that, because this is a data call, the
                call parameters only include a count of the packets and
                octets that were sent and received.
















































Huitema, Andreasen, Arango, Prakash                            [Page 80]


Internet draft              MGCP Call Flows              20 January 1999


                5.2.  Outgoing data call through a NAS

         _____________________________________________________________________
        |     PC    |  CO |  SS7/|     NAS    |      CA     |  ACC|   Router |
        |           |     |  ISUP|            |             |     |          |
        |___________|_____|______|____________|_____________|_____|__________|
        |           |     |      |            |             |     |  notices |
        |           |     |      |            |             |     |  packet  |
        |           |     |      |            |             |     |   to PC  |
        |           |     |      |            |      <-     |  - -|    NTFY  |
        |           |     |      |            |      Ack    |  - -|     ->   |
        |           |     |      |            |  Decides to |     |          |
        |           |     |      |            |   place an  |     |          |
        |           |     |      |            |   outgoing  |     |          |
        |           |     |      |            |     call.   |     |          |
        |           |     |      |            |  Call start |  -> |          |
        |           |     |      |      <-    |    Create   |     |          |
        |           |     |      |            |  Connection |     |          |
        |           |     |      |            |    (data)   |     |          |
        |           |     |      |     Ack    |      ->     |     |          |
        |           |     |   <- |     - -    |      IAM    |     |          |
        |  (rings)  |  <- |  IAM |            |             |     |          |
        |           |  ACM|   -> |            |             |     |          |
        |           |     |  ACM |     - -    |      ->     |     |          |
        |  (answer) |  ANM|   -> |            |             |     |          |
        |           |     |  ANM |     - -    |      ->     |     |          |
        |           |     |      |            |  Connection |     |          |
        |           |     |      |            |  complete.  |     |          |
        |           |     |      |            |    Call     |     |          |
        |           |     |      |            |  established|  -> |          |
        |    PPP    |  - -|  - - |      ->    |             |     |          |
        |     <-    |  - -|  - - |  Validates |             |     |          |
        |           |     |      |    call,   |             |     |          |
        |           |     |      |  announces |             |     |          |
        |           |     |      |  IP address|      - -    |  - -|     ->   |
        | Connected |     |      |            |             |     |          |
        |  to the   |     |      |            |             |     |          |
        |  Internet |     |      |            |             |     |          |
        |           |     |      |            |             |     |          |
        |___________|_____|______|____________|_____________|_____|__________|











Huitema, Andreasen, Arango, Prakash                            [Page 81]


Internet draft              MGCP Call Flows              20 January 1999


          ___________________________________________________________________
         |     PC     |  CO |  SS7/|     NAS    |      CA    |  ACC|  Router|
         |            |     |  ISUP|            |            |     |        |
         |____________|_____|______|____________|____________|_____|________|
         |   Closes   |     |      |            |            |     |        |
         | connection.|     |      |            |            |     |        |
         |            |  REL|   -> |            |            |     |        |
         |            |     |  REL |     - -    |      ->    |     |        |
         |            |     |      |      <-    |    Delete  |     |        |
         |            |     |      |            |  Connection|     |        |
         |            |     |      |    ceases  |            |     |        |
         |            |     |      |  announcing|            |     |        |
         |            |     |      |  IP address|     - -    |  - -|    ->  |
         |            |     |      |     Perf   |            |     |        |
         |    data    |  -> |      |            |            |     |        |
         |            |     |   <- |     - -    |     RLC    |     |        |
         |            |  <- |  RLC |            |            |     |        |
         |            |     |      |            |   Call end |  -> |        |
         |____________|_____|______|____________|____________|_____|________|


                This diagram shows the exchange of messages during a
                call from an an Internet Service Provider to a modem,
                using a trunking gateway that doubles as a Network
                Access Server. During these exchanges the MGCP is used
                by the Call Agent to control both the NAS, and will also
                be used between the Call Agent and a default router of
                the ISP.

                In the example configuration, the calls are set on
                demand, when data have to actually be sent from the
                Internet to the dial-up user. When no connection is
                established, the local routing is configured to send the
                packets towards a default router which may or may not be
                the same machine as the NAS. In redundant configura-
                tions, there could be many default routers. Each of
                these default routers has been programmed (through a
                notification request) to send a notification to the Call
                Agent when it receives a packet on the default route:

                        NTFY 2005 default-route@router25.whatever.net MGCP 0.1
                        X:
                        0123456789AF
                        O: pa(192.96.41.1)


                After this notification, the Call Agent should send an
                acknowledgement:



Huitema, Andreasen, Arango, Prakash                            [Page 82]


Internet draft              MGCP Call Flows              20 January 1999


                        200 2005 OK


                (We should note here that using MGCP for this function
                is a stretch. There are other protocols, notably RMON,
                that already provide an adequate service. These proto-
                cols could be used instead of MGCP without affecting the
                discussion that follows.)

                The Call Agent deduces from the notification that a cir-
                cuit should be established towards the dial-up user, or
                towards the dial-up router. Using configuration data-
                bases, the Call Agent selects the number that should be
                called, and also the type of modem parameters and
                authentication parameters that correspond to the called
                number. The Call Agent uses its routing table to select
                an adequate NAS, with an available outgoing trunk. It
                uses a create connection command to seize this outgoing
                trunk:

                        CRCX 1237 card23/21@trgw-7.whatever.net MGCP 0.1
                        C: A3C47F21456789F0
                        M: data
                        X: 0123456789B1
                        R: cl

                        v=0
                        m=nas/none
                        c=IN IP4 128.96.41.1
                        a=subnet:IN IP4 123.45.67.64/26
                        a=bearer:isdn64
                        a=framing:ppp-hdlc
                        a=dialed:18001234567
                        a=dialing:2345678901


                The gateway immediately acknowledges the creation, send-
                ing back the identification of the newly created connec-
                tion. (There is no session description in the case of a
                data call.)

                        200 1237 OK
                        I: FDE234C8


                Once the trunk has been seized, the Call Agent will send
                an IAM message to the switch that controls the trunk.
                The dialed PC will "ring" and eventually take the call,



Huitema, Andreasen, Arango, Prakash                            [Page 83]


Internet draft              MGCP Call Flows              20 January 1999


                triggering the arrival of progress messages and then an
                answer message (ANM). At that point, the Call Agent
                knows that the call is established.

                The DSP associated to the incoming trunk has been loaded
                with the specified modem code - a simple HDLC framing in
                our example. Once the call is established, the calling
                PC will train with the modem associated with the trunk.
                In our example, no authentication is requested: the Call
                Agent has identified the dialed user through its called
                number.


                Once the association is established and the IP service
                is validated, the gateway announces that it serves the
                local user. In our example, there is no address confi-
                guration performed through PPP: the dialed user has a
                permanent address, which has been programmed when it
                subscribed to the service. However, one the circuit is
                validated, the gateway should start announcing its
                access to this permanent address in the routing tables.
                In our example, the dialed station is in fact an access
                point to a local network, and the NAS should start
                announcing accessibility of that local network
                (123.45.67.64/26) through the local routing procedures
                (an IGP such as RIP, OSPF or EIGRP).

                Note that the current design makes the hypothesis that
                the Call Agent "tells" the address of the LAN to the
                NAS. This is a very debatable design. If a secure IGP is
                used (e.g. using embedded keyed MD5 authentication, or
                using IPSEC) then the routing prefix will be naturally
                exchanged through this IGP. On the other hand, some form
                of configuration can provide a "double check" against
                user errors.

                In our example, the call is completed when the called
                modem hangs up. This triggers an ISUP release message,
                which is forwarded to the Call Agent. The Call Agent
                will request the NAS to delete the connection:

                        DLCX 1244 card23/21@trgw-7.whatever.net MGCP 0.1
                        C: A3C47F21456789F0
                        I: FDE234C8


                The gateways will respond with a message that should
                include a "call parameters" header fields:



Huitema, Andreasen, Arango, Prakash                            [Page 84]


Internet draft              MGCP Call Flows              20 January 1999


                        250 1244 OK
                        P: PS=1245, OS=62345, PR=780, OR=45123


                We should note that, because this is a data call, the
                call parameters only include a count of the packets and
                octets that were sent and received.

                5.3.  Call back, using a NAS

                There are three classic forms of call-back:

                1-   ANI-based Callback

                2-   PPP Callback (Microsoft Callback is a variant of
                     this)

                3-   Login-based callback

                The ANI based call-back can be implemented entirely in
                the Call Agent, as indicated in the following diagram:

             ______________________________________________________________
                PC      CO    SS7/   NAS              CA               ACC
                              ISUP
             ______________________________________________________________
               dials    IAM    ->
                              IAM    - -              ->
                                               Notices that the
                                           called number corresponds
                                            to a call back service,
                                             and that the calling
                                            number has subscribed
                                               to that service.
                                                Terminates the
                                                incoming call.
                               <-    - -              REL
                        <-    REL
                        RLC    ->
              hangup          RLC    - -              ->
                                               Decides to place
                                               an outgoing call.
                                                  Call start           ->
                                     <-             Create
                                               Connection (data)
                                     Ack              ->
                               <-    - -              IAM
              (rings)   <-    IAM



Huitema, Andreasen, Arango, Prakash                            [Page 85]


Internet draft              MGCP Call Flows              20 January 1999


            |________|_____|______|_____|___________________________|_____|



                The PPP callback suppose that the modem first estab-
                lishes an incoming connection, and go through the
                authentication exchange. The following diagram provides
                an example of these exchanges:











































Huitema, Andreasen, Arango, Prakash                            [Page 86]


Internet draft              MGCP Call Flows              20 January 1999


          ____________________________________________________________________
         |    PC   |  CO |  SS7/|     NAS    |        CA      |  ACC|  Radius|
         |         |     |  ISUP|            |                |     |        |
         |_________|_____|______|____________|________________|_____|________|
         | dials in|     |      |            |                |     |        |
         |         |  IAM|   -> |            |                |     |        |
         |         |     |  IAM |     - -    |        ->      |     |        |
         |         |     |      |            |  Checks called |     |        |
         |         |     |      |            |     number.    |     |        |
         |         |     |      |            |     Notices    |     |        |
         |         |     |      |            |    data call.  |     |        |
         |         |     |      |            |    Call start  |  -> |        |
         |         |     |      |      <-    |      Create    |     |        |
         |         |     |      |            |    Connection  |     |        |
         |         |     |      |            |      (data)    |     |        |
         |         |     |      |     Ack    |        ->      |     |        |
         |         |     |      |            |    Connection  |     |        |
         |         |     |      |            |    completed.  |     |        |
         |         |     |      |            |      Call      |     |        |
         |         |     |      |            |   established  |  -> |        |
         |         |     |   <- |     - -    |       ANM      |     |        |
         |         |  <- |  ANM |            |                |     |        |
         |  modem  |  - -|  - - |      ->    |                |     |        |
         |    <-   |  - -|  - - |  handshake |                |     |        |
         |   PPP   |  - -|  - - |      ->    |                |     |        |
         |         |     |      |   obtain   |                |     |        |
         |         |     |      |  user-id,  |                |     |        |
         |         |     |      |   password |                |     |        |
         |         |     |      |    Check   |       - -      |  - -|    ->  |
         |         |     |      |      <-    |       - -      |  - -|   Ack  |
         |         |     |      |   reports  |                |     |        |
         |         |     |      |  call back |                |     |        |
         |         |     |      |  condition |                |     |        |
         |         |     |      |     NTFY   |        ->      |     |        |
         |         |     |      |      <-    |       ACK      |     |        |
         |         |     |      |            |     Decides    |     |        |
         |         |     |      |            |   to place an  |     |        |
         |         |     |      |            |  outgoing call.|     |        |
         |         |     |      |      <-    |      Delete    |     |        |
         |         |     |      |            |    Connection  |     |        |
         |         |     |      |    Perf    |                |     |        |
         |         |     |      |     data   |        ->      |     |        |
         |         |     |   <- |     - -    |       REL      |     |        |
         |         |  <- |  REL |            |                |     |        |
         |         |  REL|   -> |            |                |     |        |
         |  hangup |     |  REL |     - -    |        ->      |     |        |
         |_________|_____|______|____________|________________|_____|________|




Huitema, Andreasen, Arango, Prakash                            [Page 87]


Internet draft              MGCP Call Flows              20 January 1999


       __________________________________________________________________________
      |     PC     |  CO |  SS7/|        NAS       |      CA     |  ACC|  Radius|
      |            |     |  ISUP|                  |             |     |        |
      |____________|_____|______|__________________|_____________|_____|________|
      |            |     |      |                  |  Call start |  -> |        |
      |            |     |      |         <-       |    Create   |     |        |
      |            |     |      |                  |  Connection |     |        |
      |            |     |      |                  |    (data)   |     |        |
      |            |     |      |        Ack       |      ->     |     |        |
      |            |     |   <- |        - -       |      IAM    |     |        |
      |   (rings)  |  <- |  IAM |                  |             |     |        |
      |            |  ACM|   -> |                  |             |     |        |
      |            |     |  ACM |        - -       |      ->     |     |        |
      |  (answer)  |  ANM|   -> |                  |             |     |        |
      |            |     |  ANM |        - -       |      ->     |     |        |
      |            |     |      |                  |  Connection |     |        |
      |            |     |      |                  |  complete.  |     |        |
      |            |     |      |                  |    Call     |     |        |
      |            |     |      |                  |  established|  -> |        |
      |     PPP    |  - -|  - - |         ->       |             |     |        |
      |     <-     |  - -|  - - |  Validates call, |             |     |        |
      | Connected  |     |      |                  |             |     |        |
      |   to the   |     |      |                  |             |     |        |
      |  Internet  |     |      |                  |             |     |        |
      |            |     |      |                  |             |     |        |
      |   Closes   |     |      |                  |             |     |        |
      | connection.|     |      |                  |             |     |        |
      |            |  REL|   -> |                  |             |     |        |
      |            |     |  REL |        - -       |      ->     |     |        |
      |            |     |      |         <-       |    Delete   |     |        |
      |            |     |      |                  |  Connection |     |        |
      |            |     |      |     Perf data    |      ->     |     |        |
      |            |     |   <- |        - -       |      RLC    |     |        |
      |            |  <- |  RLC |                  |             |     |        |
      |            |     |      |                  |   Call end  |  -> |        |
      |____________|_____|______|__________________|_____________|_____|________|



                This diagram shows the exchange of messages during a
                call from a modem user to an Internet Service Provider,
                using a trunking gateway that doubles as a Network
                Access Server. During these exchanges the MGCP is used
                by the Call Agent to control the NAS.

                Upon reception of the IAM message, the Call Agent
                notices that the called number corresponds to a data
                service. Using configuration databases, the Call Agent



Huitema, Andreasen, Arango, Prakash                            [Page 88]


Internet draft              MGCP Call Flows              20 January 1999


                selects the type of modem parameters and authentication
                parameters that correspond to the called number and to
                the calling number. It uses this knowledge to send a
                connection command to the NAS, programming the incoming
                trunk:

                        CRCX 1237 card23/21@trgw-7.whatever.net MGCP 0.1
                        C: A3C47F21456789F0
                        M: data
                        X: 0123456789B1
                        R: cl, cbk

                        v=0
                        m=nas/radius
                        c=radius.example.net
                        a=bearer:v.32
                        a=framing:ppp-asynch
                        a=dialed:18001234567
                        a=dialing:2345678901


                The gateway immediately acknowledges the creation, send-
                ing back the identification of the newly created connec-
                tion. (There is no session description in the case of a
                data call.)

                        200 1237 OK
                        I: FDE234C8


                The Call Agent, knowing that this is a data call, can
                immediately acknowledge the establishment of the connec-
                tion, sending an ANM message back to the calling switch.

                The DSP associated to the incoming trunk has been loaded
                with the specified modem code. Once the call is esta-
                blished, the modem of the calling PC will be synchron-
                ized with the modem associated to the trunk. The caller
                will then proceed to a normal PPP synchronization, which
                probably implies a PPP login. The login parameters, in
                our example, are checked using Radius. The Radius server
                that will be used is typically chosen as a function of
                the called number, which identifies the data service
                that the calling modem requested. In fact, the number
                can also be used to identify the specific form of
                authentication that is requested.

                In the call back example, the Radius server will



Huitema, Andreasen, Arango, Prakash                            [Page 89]


Internet draft              MGCP Call Flows              20 January 1999


                indicate that the call cannot be completed as such, and
                that the user should be called back (for example, using
                a "Callback Framed" service type in its access-accept
                response.) The NAS will thus send a Notify message to
                the Call Agent, indicating that a call-back is
                requested:

                        NTFY 2005 card23/21@trgw-7.whatever.net MGCP 0.1
                        X: 0123456789B1
                        O: cbk(user-id)


                After this notification, the Call Agent should send an
                acknowledgement:

                        200 2005 OK


                The Call Agent will check that the call back request can
                be followed through. In its databases, it will find the
                regular address associated to the "user-id," and prepare
                to set up a call to that address. It will first clear
                the incoming call, sending a DeleteConnection command to
                the NAS:

                In our example, the call is completed when the calling
                modem hangs up. This triggers an ISUP release message,
                which is forwarded to the Call Agent. The Call Agent
                will request the NAS to delete the connection, and reset
                the list of observed events:

                        DLCX 1244 card23/21@trgw-7.whatever.net MGCP 0.1
                        C: A3C47F21456789F0
                        I: FDE234C8
                        X: 0123456789B2
                        R:


                The gateways will respond with a message that should
                include a "call parameters" header fields:

                        250 1244 OK
                        P: PS=2, OS=345, PR=1, OR=123


                We should note that, because this is a data call, the
                call parameters only include a count of the packets and
                octets that were sent and received.



Huitema, Andreasen, Arango, Prakash                            [Page 90]


Internet draft              MGCP Call Flows              20 January 1999


                The Call Agent will then proceed to set up an outgoing
                data call. This call may be routed through the same NAS
                that received the incoming call, but can also be routed
                through an entirely different endpoint , for example if
                the calling user has moved out of its normal region.














































Huitema, Andreasen, Arango, Prakash                            [Page 91]


Internet draft              MGCP Call Flows              20 January 1999


                5.4.  Data call to a NAS, using L2TP

        ________________________________________________________________________
       |     PC    |  CO |  SS7/|       NAS     |       CA     |  ACC|    LNS  |
       |           |     |  ISUP|               |              |     |         |
       |___________|_____|______|_______________|______________|_____|_________|
       |  dials in |     |      |               |              |     |         |
       |           |  IAM|   -> |               |              |     |         |
       |           |     |  IAM |       - -     |       ->     |     |         |
       |           |     |      |               |  Check called|     |         |
       |           |     |      |               |    number.   |     |         |
       |           |     |      |               |    Notices   |     |         |
       |           |     |      |               |   data call. |     |         |
       |           |     |      |               |   Call start |  -> |         |
       |           |     |      |       <-      |     Create   |     |         |
       |           |     |      |               |   Connection |     |         |
       |           |     |      |               |     (data)   |     |         |
       |           |     |      |       Ack     |       ->     |     |         |
       |           |     |      |               |   Connection |     |         |
       |           |     |      |               |   complete.  |     |         |
       |           |     |      |               |      Call    |     |         |
       |           |     |      |               |  established |  -> |         |
       |           |     |   <- |       - -     |      ANM     |     |         |
       |           |  <- |  ANM |               |              |     |         |
       |   modem   |  - -|  - - |       ->      |              |     |         |
       |     <-    |  - -|  - - |    handshake  |              |     |         |
       |    PPP    |  - -|  - - |       ->      |              |     |         |
       |           |     |      |     obtain    |              |     |         |
       |           |     |      |    user-id,   |              |     |         |
       |           |     |      |    password   |              |     |         |
       |           |     |      |    Establish  |              |     |         |
       |           |     |      |     Tunnel    |              |     |         |
       |           |     |      |     SCC-REQ   |      - -     |  - -|    ->   |
       |           |     |      |       <-      |      - -     |  - -|  SCC-REP|
       |           |     |      |       <-      |      - -     |  - -|  SCC-CON|
       |           |     |      |     IC-REQ    |      - -     |  - -|    ->   |
       |           |     |      |       <-      |      - -     |  - -|  IC-REP |
       |           |     |      |       <-      |      - -     |  - -|  IC-CON |
       |           |     |      |  Spoof PPP/LCP|      - -     |  - -|    ->   |
       |     <-    |  - -|  - - |   Relays PPP  |      - -     |  - -|    ->   |
       | Connected |     |      |               |              |     |         |
       |  to the   |     |      |               |              |     |         |
       |  Internet |     |      |               |              |     |         |
       |___________|_____|______|_______________|______________|_____|_________|







Huitema, Andreasen, Arango, Prakash                            [Page 92]


Internet draft              MGCP Call Flows              20 January 1999


            _______________________________________________________________
           |     PC     |  CO |  SS7/|     NAS   |      CA    |  ACC|  LNS|
           |            |     |  ISUP|           |            |     |     |
           |____________|_____|______|___________|____________|_____|_____|
           |   Closes   |     |      |           |            |     |     |
           | connection.|     |      |           |            |     |     |
           |            |  REL|   -> |           |            |     |     |
           |            |     |  REL |     - -   |      ->    |     |     |
           |            |     |      |     <-    |    Delete  |     |     |
           |            |     |      |           |  Connection|     |     |
           |            |     |      |    Perf   |            |     |     |
           |            |     |      |    data   |      ->    |     |     |
           |            |     |   <- |     - -   |     RLC    |     |     |
           |            |  <- |  RLC |           |            |     |     |
           |            |     |      |     CDN   |     - -    |  - -|  -> |
           |            |     |      |  Stop-CC-N|     - -    |  - -|  -> |
           |            |     |      |           |   Call end |  -> |     |
           |____________|_____|______|___________|____________|_____|_____|



                This diagram shows the exchange of messages during a
                call from a modem user to an Internet Service Provider,
                using a trunking gateway that doubles as a Network
                Access Server. During these exchanges the MGCP is used
                by the Call Agent to control the NAS. The PPP informa-
                tion is relayed to a network server (LNS) using L2TP.

                Upon reception of the IAM message, the Call Agent
                notices that the called number corresponds to a data
                service. Using configuration databases, the Call Agent
                selects the type of modem parameters and authentication
                parameters that correspond to the called number and to
                the calling number. It uses this knowledge to send a
                connection command to the NAS, programming the incoming
                trunk:

                        CRCX 1237 card23/21@trgw-7.whatever.net MGCP 0.1
                        C: A3C47F21456789F0
                        M: data
                        X: 0123456789B1
                        R: cl

                        v=0
                        c=IN IP4 access.example.net
                        m=nas/l2tp
                        k=clear:some-shared-secret
                        a=bearer:v.32



Huitema, Andreasen, Arango, Prakash                            [Page 93]


Internet draft              MGCP Call Flows              20 January 1999


                        a=framing:ppp-asynch
                        a=dialed:18001234567
                        a=dialing:2345678901


                The gateway immediately acknowledges the creation, send-
                ing back the identification of the newly created connec-
                tion. (There is no need to transmit a session descrip-
                tion in the case of a data call.)

                        200 1237 OK
                        I: FDE234C8


                The Call Agent, knowing that this is a data call, can
                immediately acknowledge the establishment of the connec-
                tion, sending an ANM message back to the calling switch.

                The DSP associated to the incoming trunk has been loaded
                with the specified modem code. Once the call is esta-
                blished, the modem of the calling PC will be synchron-
                ized with the modem associated to the trunk. The caller
                will then proceed to a normal PPP synchronization, which
                probably implies a PPP login.


                Once PPP has been properly synchronized, the NAS estab-
                lishes a tunnel towards the LNS. Because L2TP is a two-
                layer protocol, the NAS must first establish an L2TP
                control connection between itself and the LNS. This con-
                nection may or may not have been established prior to
                the call set-up.


                Tunnel establishment requires a shared secret between
                the LNS and the NAS; in our example, that secret is
                passed by the Call Agent, along with the name of the
                LNS. Once the supporting tunnel is installed, the NAS
                has to establish an L2TP tunnel, to relay the "incoming
                call." Once the call is established, the PPP packets
                received on the trunk will be relayed over the L2TP tun-
                nel, and vice-versa.

                In our example, the call is completed when the calling
                modem hangs up. This triggers an ISUP release message,
                which is forwarded to the Call Agent. The Call Agent
                will request the NAS to delete the connection:




Huitema, Andreasen, Arango, Prakash                            [Page 94]


Internet draft              MGCP Call Flows              20 January 1999


                        DLCX 1244 card23/21@trgw-7.whatever.net MGCP 0.1
                        C: A3C47F21456789F0
                        I: FDE234C8


                The gateways will respond with a message that should
                include a "call parameters" header fields:

                        250 1244 OK
                        P: PS=1245, OS=62345, PR=780, OR=45123


                We should note that, because this is a data call, the
                call parameters only include a count of the packets and
                octets that were sent and received.

                5.5.  Basic data call with continuity test


































Huitema, Andreasen, Arango, Prakash                            [Page 95]


Internet draft              MGCP Call Flows              20 January 1999


          ___________________________________________________________________
         |    PC   |  CO |  SS7/|     NAS   |        CA      |  ACC|  Radius|
         |         |     |  ISUP|           |                |     |        |
         |_________|_____|______|___________|________________|_____|________|
         | dials in|     |      |           |                |     |        |
         |         |  IAM|   -> |           |                |     |        |
         |         |     |  IAM |     - -   |        ->      |     |        |
         |         |     |      |           |  Check called  |     |        |
         |         |     |      |           |     number.    |     |        |
         |         |     |      |           |     Notices    |     |        |
         |         |     |      |           |    data call,  |     |        |
         |         |     |      |           |    continuity  |     |        |
         |         |     |      |           |      test.     |     |        |
         |         |     |      |           |    Call start  |  -> |        |
         |         |     |      |     <-    |      Create    |     |        |
         |         |     |      |           |    Connection  |     |        |
         |         |     |      |           |    (loopback)  |     |        |
         |         |     |      |     Ack   |        ->      |     |        |
         |         |  COT|   -> |           |                |     |        |
         |         |     |  COT |     - -   |        ->      |     |        |
         |         |     |      |     <-    |      Modify    |     |        |
         |         |     |      |           |    Connection  |     |        |
         |         |     |      |           |      (data)    |     |        |
         |         |     |      |     Ack   |        ->      |     |        |
         |         |     |      |           |   Connection   |     |        |
         |         |     |      |           |  is completed. |     |        |
         |         |     |      |           |      Call      |     |        |
         |         |     |      |           |   established  |  -> |        |
         |         |     |   <- |     - -   |       ANM      |     |        |
         |         |  <- |  ANM |           |                |     |        |
         |  modem  |  - -|  - - |     ->    |                |     |        |
         |    <-   |  - -|  - - |  handshake|                |     |        |
         |   PPP   |  - -|  - - |     ->    |                |     |        |
         |_________|_____|______|___________|________________|_____|________|


                This diagram shows the various exchange of messages dur-
                ing the beginning of a call from a data user on the
                circuit-switched PSTN to a NAS. During these exchanges
                the Call Agent uses MGCP to control the NAS and the
                residential gateway. The circuit switch decides to exe-
                cute a continuity test during the call establishment.
                The exchanges occur on two sides.

                Upon reception of the IAM message, the Call Agent recog-
                nizes that a continuity test has been requested.  It
                immediately sends a CreateConnection request to the NAS
                to connect to the incoming trunk, creating a connection:



Huitema, Andreasen, Arango, Prakash                            [Page 96]


Internet draft              MGCP Call Flows              20 January 1999


                        CRCX 1237 card23/21@trgw-7.whatever.net MGCP 0.1
                        C: A3C47F21456789F0
                        L: p:10, a:G.711;G.726-32
                        M: loopback
                        X: 0123456789B1
                        R: cl

                        v=0
                        m=nas/radius
                        c=IN IP4 radius.example.net
                        a=bearer:v.32
                        a=framing:ppp-asynch
                        a=dialed:18001234567
                        a=dialing:2345678901


                The trunking gateway recognizes that the mode is set to
                "loopback".  It places the circuit in "loopback" mode
                (we assume that this is the adequate way to perform con-
                tinuity test in this specific environment). The gateway
                is then ready to send back a 2010 Hz return tone if it
                receives a 2010 Hz test tone. The gateway acknowledges
                the creation of the connection, sending back the iden-
                tification of the newly created connection:

                        200 1237 OK
                        I: FDE234C8


                At this point, the call agent is waiting for the result
                of the continuity test.  The calling switch is sending
                the test tone (2010 Hz); if it receives the return tone
                (2010 Hz), it will send a "continuity passed" message
                (COT).  At this point, the call agent will send a modify
                connection message to the NAS, in order to place the
                connection in "data" mode:

                        MDCX 1238 card23/21@trgw-7.whatever.net MGCP 0.1
                        C: A3C47F21456789F0
                        I: FDE234C8
                        M: data

                The NAS will immediately acknowledge that command:

                        200 1238 OK


                The NAS will then proceed with the establishment of the



Huitema, Andreasen, Arango, Prakash                            [Page 97]


Internet draft              MGCP Call Flows              20 January 1999


                modem call.


















































Huitema, Andreasen, Arango, Prakash                            [Page 98]


Internet draft              MGCP Call Flows              20 January 1999


                6.  Audit and Restart

                The following call flows provide examples of the audit
                and restart commands.

                6.1.  Using the Audit commands

           __________________________________________________________________
          | CO |  SS7|   TGW |         CA       |   CDB |   ACC |  RGW|  Usr|
          |____|_____|_______|__________________|_______|_______|_____|_____|
          |    |     |       |                  |       |       |     |     |
          |    |     |   <-  |   Audit Endpoint |       |       |     |     |
          |    |     |       |    (endpoints)   |       |       |     |     |
          |    |     |   Ack |         ->       |       |       |     |     |
          |    |     |   <-  |       Audit      |       |       |     |     |
          |    |     |       |     Endpoint     |       |       |     |     |
          |    |     |       |   (capabilities) |       |       |     |     |
          |    |     |   Ack |         ->       |       |       |     |     |
          |    |     |       |                  |       |       |     |     |
          |    |     |       |  Audit Endpoint  |  - - -|  - - -|  -> |     |
          |    |     |       |    (endpoints)   |       |       |     |     |
          |    |     |       |         <-       |  - - -|  - - -|  Ack|     |
          |    |     |       |  Audit Endpoint  |  - - -|  - - -|  -> |     |
          |    |     |       |   (capabilities) |       |       |     |     |
          |    |     |       |         <-       |  - - -|  - - -|  Ack|     |
          |    |     |       |                  |       |       |     |     |
          | IAM|  -> |       |                  |       |       |     |     |
          |    |  IAM|  - - -|         ->       |       |       |     |     |
          |    |     |       |   (proceed with  |       |       |     |     |
          |    |     |       |    call setup)   |       |       |     |     |
          |    |     |       |        ...       |       |       |     |     |
          |    |  <- |  - - -|        ANM       |       |       |     |     |
          | <- |  ANM|       |                  |       |       |     |     |
          |    |     |       |                  |       |       |     |     |
          |    |     |   <-  |  Audit Endpoint  |       |       |     |     |
          |    |     |       |       (misc)     |       |       |     |     |
          |    |     |   Ack |         ->       |       |       |     |     |
          |    |     |   <-  |  Audit Connection|       |       |     |     |
          |    |     |   Ack |         ->       |       |       |     |     |
          |    |     |       |                  |       |       |     |     |
          |    |     |       |   Audit Endpoint |       |       |     |     |
          |    |     |       |       (misc)     |  - - -|  - - -|  -> |     |
          |    |     |       |         <-       |  - - -|  - - -|  Ack|     |
          |    |     |       |  Audit Connection|  - - -|  - - -|  -> |     |
          |    |     |       |         <-       |  - - -|  - - -|  Ack|     |
          |    |     |       |                  |       |       |     |     |
          |____|_____|_______|__________________|_______|_______|_____|_____|




Huitema, Andreasen, Arango, Prakash                            [Page 99]


Internet draft              MGCP Call Flows              20 January 1999


                This diagram shows the various exchanges of messages
                during auditing of a trunk gateway and a residential
                gateway. First, both gateways are auditing to learn
                about the endpoints supported by each. Secondly, capa-
                bilities information is audited for one of these end-
                points. The procedure is carried out for the residential
                gateway as well. A call then arrives from the PSTN and
                is established exactly as described in the "basic call
                from TGW to RGW". After the call has been established,
                both endpoints involved in the call are audited -- this
                time in order to retrieve endpoint info and subsequently
                connection info associated with the call.

                The Call Agent initially sends an AuditEndpoint command
                to the trunking gateway in order to discover what end-
                points the trunking gateway has:

                        AUEP 1200 *@trgw-7.whatever.net MGCP 0.1
                        F:


                Since we use the wildcard naming convention, we cannot
                retrieve any endpoint specific information but the
                RequestedInfo field must still be included. Had we
                specified any RequestedInfo, the trunking gateway would
                simply have ignored it.

                The trunking gateway immediately acknowledges the audit-
                ing command and sends back the list of endpoints it con-
                tains. Our trunking gateway has two cards in it --
                card23 and card24 each supporting two circuits:

                        200 1200 OK
                        Z: card23/20@trgw-7.whatever.net
                        Z: card23/21@trgw-7.whatever.net
                        Z: card24/20@trgw-7.whatever.net
                        Z: card24/21@trgw-7.whatever.net


                Now that the Call Agent has learned about the endpoints
                present in the trunking gateway, it requests capability
                information for one of the endpoints. We here assume
                that all similar endpoints have the same capabilities
                and thus only audit one of them for capabilities,
                although it is possible that different endpoints have
                different capabilities:

                        AUEP 1201 card23/20@trgw-7.whatever.net



Huitema, Andreasen, Arango, Prakash                           [Page 100]


Internet draft              MGCP Call Flows              20 January 1999


                        F: A


                The trunking gateway acknowledges the command by return-
                ing to the Call Agent a response describing the capabil-
                ities it supports for the endpoint in question:

                        200 1201 OK
                        L: a:G.711;G.726-32, p:10-100, e:on, s:off, v:T;D,
                           m:sendonly;recvonly;sendrecv;inactive;conttest


                The Call Agent thereby learns, that the endpoint sup-
                ports two codecs; G.711 and G.726-32 which can each be
                used with a packetization period of between 10 and 100
                msec. Echo cancellation is supported while silence
                suppression is not, and the event packages supported are
                Trunk and DTMF.  Since Trunk is the first package speci-
                fied it is furthermore the default package. Also, con-
                nections can be established in either of the modes "Send
                Only", "Receive Only", "Send/Receive", "Inactive", and
                "Continuity Test". Finally, several parameters were not
                specified and default or deduced values will therefore
                apply. These parameters are Bandwidth (deduce from
                codec), Gain Control (supported), Type of Service (sup-
                ported), Resource Reservation (best effort), Encryption
                Key (no encryption), or Type of Network (guess) was pro-
                vided and default or deduced values for each of these
                will therefore apply.  Next the Call Agent queries the
                residential gateway to discover what endpoints are
                present in it:

                        AUEP 2000 *@rgw.whatever.net MGCP 0.1
                        F:


                As before, we use the wildcard naming convention and can
                therefore not retrieve any endpoint specific informa-
                tion, however the RequestedInfo field must still be
                included. If any values had been specified for it, they
                would simply be ignored.

                The residential gateway acknowledges the command and
                includes a list of endpoints it contains:

                        200 2000 OK
                        Z: endpoint/1@rgw-2567.whatever.net
                        Z: endpoint/2@rgw-2567.whatever.net



Huitema, Andreasen, Arango, Prakash                           [Page 101]


Internet draft              MGCP Call Flows              20 January 1999


                The Call Agent thereby learns, that the residential
                gateway contains the two endpoints endpoint/1 and end-
                point/2.  Having learned about the endpoints present,
                the Call Agent next requests capability information for
                one of the endpoints. Again, we assume that all similar
                endpoints have the same capabilities and thus only audit
                one of them for capabilities, although it is possible
                that different endpoints have different capabilities:

                        AUEP 2001 endpoint/1@rgw-2567.whatever.net
                        F: A


                The residential gateway acknowledges the command by
                returning to the Call Agent a response describing the
                capabilities it supports for the endpoint in question:

                        200 1201 OK
                        L: a:G.711;G.726-32, p:10-100, e:on, s:off, v:L;D,
                           m:sendonly;recvonly;sendrecv;inactive
                        L: a:G.723.1; p:30-90, e:on, s:on, v:L;D,
                           m:sendonly;recvonly;sendrecv;inactive;confrnce


                The Call Agent thereby learns, that the endpoint sup-
                ports three codecs; G.711, G.726-32, and G.723.1.

                G.711 and G.726-32 can each be used with a packetization
                period of between 10 and 100 msec. Echo cancellation is
                supported while silence suppression is not, and the
                event packages supported are Line and DTMF. Since Line
                is the first package specified it is furthermore the
                default package. Also, connections can be established in
                either of the modes "Send Only", "Receive Only",
                "Send/Receive", and "Inactive". Finally, several parame-
                ters were not specified and default or deduced values
                will therefore apply.  These parameters are Bandwidth
                (deduce from codec), Gain Control (supported), Type of
                Service (supported), Resource Reservation (best effort),
                Encryption Key (no encryption), or Type of Network
                (guess) was provided and default or deduced values for
                each of these will therefore apply.

                G.723.1 can be used with a packetization period of
                between 30 and 90 msec. Both echo cancellation and
                silence suppression are supported, and the event pack-
                ages supported are Line and DTMF with Line being the
                default package. Connections can be established in



Huitema, Andreasen, Arango, Prakash                           [Page 102]


Internet draft              MGCP Call Flows              20 January 1999


                either of the modes "Send Only", "Receive Only",
                "Send/Receive", "Inactive", and "Conference". Finally,
                default or deduced values will be applied for the param-
                eters that were not supplied.

                The Call Agent now knows all endpoints as well as their
                capabilities in the trunking and the residential gate-
                way.

                An IAM signaling a call for the residential gateway now
                arrives from the PSTN. The call is then setup as
                described in Section 2.2.  After the call has been suc-
                cessfully setup, the Call Agent now decides to audit the
                endpoint in the trunking gateway for information about
                RequestedEvents, DigitMap, SignalRequests, RequestIden-
                tifier, NotifiedEntity, ConnectionIdentifiers, and
                DetectEvents:

                        AUEP 1202 card23/21@trgw-7.whatever.net MGCP 0.1
                        F: R,D,S,X,N,I,T


                The trunking gateway acknowledges the command by return-
                ing to the Call Agent a response with the requested info
                for the endpoint in question:

                        200 1202 OK
                        R:
                        D:
                        S:
                        X:
                        N: [128.96.41.12]
                        I: FDE234C8, ABCD123
                        T:


                The Call Agent thus sees, that there are currently no
                RequestedEvents, no DigitMap, no SignalRequests, no
                RequestIdentifier, and no DetectEvents for the endpoint
                in question. Instead of supplying empty list for these
                parameters, the gateway could simply have omitted them
                altogether in the response.

                In the last command the call agent sent to the endpoint,
                it had not specified a NotifiedEntity, thus the notified
                entity returned here is the source IP address of the
                call agent encoded in RFC 821 format.  Finally, the end-
                point currently has two connections associated with it.



Huitema, Andreasen, Arango, Prakash                           [Page 103]


Internet draft              MGCP Call Flows              20 January 1999


                The first one was created during the call setup. Depend-
                ing on previous message exchanges, the second one may or
                may not be valid.  If the call agent believes it is
                stale, it could simply instruct the gateway to delete
                it.

                In this case, the Call Agent decides to audit the con-
                nection FDE234C8 for further information and it there-
                fore sends an AuditConnection command to the endpoint
                for information about CallId, NotifiedEntity, LocalCon-
                nectionOptions, Mode, LocalConnectionDescriptor,
                RemoteConnectionDescriptor, and ConnectionParameters:

                        AUCX 1203 card23/21@trgw-7.whatever.net MGCP 0.1
                        I: FDE234C8
                        F: C,N,L,M,LD,RD,P


                When the trunking gateway receives the command it
                immediately sends a response to the Call Agent with the
                requested info:

                        200 1203 OK
                        C: A3C47F21456789F0
                        N: [128.96.41.12]
                        L: p:10, a:G.711;G.726-32
                        M: sendrecv
                        P: PS=1245, OS=62345, PR=780, OR=45123, PL=10, JI=27,LA=48

                        v=0
                        c=IN IP4 128.96.41.1
                        m=audio 1296 RTP/AVP 0
                        v=0
                        c=IN IP4 128.96.63.25
                        m=audio 1296 RTP/AVP 0 96
                        a=rtpmap:96 G726-32/8000


                Thus the CallId, LocalConnectionOptions, and Mode are as
                expected for this connection. The same holds for the
                RemoteConnectionDescriptor which is supplied as the last
                parameter separated by an empty line. The last connec-
                tion handling command issued to the endpoint for this
                connection did not include the NotifiedEntity parameter,
                so the notified entity defaults to the source IP address
                for that command which is encoded in RFC 821 format.
                Finally, the Call Agent also obtained the current packet
                statistics for the call.



Huitema, Andreasen, Arango, Prakash                           [Page 104]


Internet draft              MGCP Call Flows              20 January 1999


                Next, the Call Agent audits the endpoint in the residen-
                tial gateway for information about RequestedEvents,
                DigitMap, SignalRequests, RequestIdentifier, NotifiedEn-
                tity, ConnectionIdentifiers, and DetectEvents:

                        AUEP 2002 endpoint/1@rgw-2567.whatever.net MGCP 0.1
                        F: R,D,S,X,N,I,T


                The trunking gateway acknowledges the command by return-
                ing to the Call Agent a response with the requested info
                for the endpoint in question:

                        200 2002 OK
                        R: L/hu
                        D: (0T|00T|[1-7]xxx|8xxxxxxx|#xxxxxxx|*xx|91xxxxxxxxxx|9011x.T)
                        S:
                        X: 0123456789B1
                        N: [128.96.41.12]
                        I: 32F345E2
                        T: hu


                The Call Agent thus sees, that currently, the only event
                being looked for is the "On hook" event from the Line
                package. Since the Line package is the default package,
                the gateway could have simply specified this as "hu"
                instead. Although the residential gateway is currently
                not accumulating any digits, a digit map is still sup-
                plied. This digit map is the last one used by the end-
                point used -- we here assume the endpoint was previously
                originated a call, e.g. as in Section 2.1. There are
                currently no signals being applied so the SignalRequests
                parameter is simply empty. There is however an active
                NotificationRequest thus the RequestIdentifier for that
                one is supplied. As before, no NotifiedEntity has been
                specified for the last NotificationRequest for this end-
                point, so the source IP address of that request is sup-
                plied as the notified entity. There is only one Connec-
                tionId for this endpoint, namely 32F345E2 as expected.
                Finally, since the last NotificationRequest did not
                specify any special value for DetectEvents, this parame-
                ter simply defaults to the same as RequestedEvents. In
                this case we omitted the specification of the Line pack-
                age in the event name since the Line package is the
                default package for this endpoint.

                Having audited the endpoint, the Call Agent decides to



Huitema, Andreasen, Arango, Prakash                           [Page 105]


Internet draft              MGCP Call Flows              20 January 1999


                audit the connection for that endpoint and the Call
                Agent therefore sends an AuditConnection command to the
                requesting information about CallId, NotifiedEntity,
                LocalConnectionOptions, Mode, LocalConnectionDescriptor,
                RemoteConnectionDescriptor and ConnectionParameters.

                        AUCX 2003 endpoint/1@rgw-2567.whatever.net MGCP 0.1
                        I: 32F345E2
                        F: C,N,L,M,LD,RD,P


                When the residential gateway receives the command it
                immediately sends a response to the Call Agent with the
                requested info:

                        200 2003 OK
                        C: A3C47F21456789F0
                        N: [128.96.41.12]
                        L: p:10, a:G.711;G.726-32
                        M: sendrecv

                        v=0
                        c=IN IP4 128.96.63.25
                        m=audio 1296 RTP/AVP 0 96
                        a=rtpmap:96 G726-32/8000

                        v=0
                        c=IN IP4 128.96.41.1
                        m=audio 1296 RTP/AVP 0
                        P: PS=1245, OS=62345, PR=780, OR=45123, PL=10, JI=27,LA=48


                Thus the CallId, LocalConnectionOptions, and Mode are as
                expected for this connection. The same holds for the
                LocalConnectionDescriptor which is supplied as the last
                parameter separated by an empty line. The last connec-
                tion handling command issued to the endpoint for this
                connection did not include the NotifiedEntity parameter,
                so the notified entity defaults to the source IP address
                for that command which is encoded in RFC 821 format.
                Finally, the Call Agent also obtained the current packet
                statistics for the call.









Huitema, Andreasen, Arango, Prakash                           [Page 106]


Internet draft              MGCP Call Flows              20 January 1999


                6.2.  Using the RestartInProgress command

           __________________________________________________________________
          | Management System       |           TGW          |  CA-1 |  CA-2|
          |_________________________|________________________|_______|______|
          |                         |                        |       |      |
          | Preparing for taking    |                        |       |      |
          | endpoints out of        |                        |       |      |
          | service when idle.      |           RSIP         |   ->  |      |
          |                         |  (graceful: indefinite)|       |      |
          |                         |            <-          |   Ack |      |
          |                         |                        |       |      |
          | Preparing to take       |                        |       |      |
          | endpoints out of        |                        |       |      |
          | service in 5 minutes    |           RSIP         |   ->  |      |
          | (graceful: 5 min)       |                        |       |      |
          |                         |            <-          |   Ack |      |
          |                         |                        |       |      |
          | Circuit failure leads   |                        |       |      |
          | to an endpoint becoming |                        |       |      |
          | unavailable.            |           RSIP         |   ->  |      |
          | (forced: 0 min)         |                        |       |      |
          |                         |            <-          |   Ack |      |
          |                         |                        |       |      |
          | Courtesy message        |                        |       |      |
          | that all endpoints are  |                        |       |      |
          | now out of service      |           RSIP         |   ->  |      |
          | (forced: 0 min)         |                        |       |      |
          |                         |            <-          |   Ack |      |
          |                         |                        |       |      |
          | All endpoints back      |                        |       |      |
          | in service              |           RSIP         |  - - -|   -> |
          | (restart: 0 min)        |                        |       |      |
          |                         |            <-          |  - - -|  Ack |
          |                         |                        |       |      |
          |_________________________|________________________|_______|______|


                This diagram shows the various exchanges of messages
                during restart of some of the endpoints in a trunking
                gateway. Our example assumes the existence of an exter-
                nal management system controlling the gateway, and the
                resulting changes in endpoint availability are then com-
                municated to the Call Agent via the RestartInProgress
                command. First all endpoints are to be taken out-of-
                service gracefully, and later a warning is sent to the
                Call Agent, that all endpoints will now be taken out of
                service within 5 minutes. Following this, we assume a



Huitema, Andreasen, Arango, Prakash                           [Page 107]


Internet draft              MGCP Call Flows              20 January 1999


                problem occurs on the gateway resulting in the immediate
                unavailability of a circuit. A little later, the gateway
                then informs the Call Agent that all endpoints are now
                out of service. Finally, we assume that the trunking
                gateway rebooted and placed all endpoints back in ser-
                vice which the gateway informs its default Call Agent
                about.

                The trunking gateway initially sends a RestartInProgress
                command to the Call Agent (CA-1) informing it of an
                intention to take all endpoints out of service:

                        RSIP 1200 *@trgw-7.whatever.net MGCP 0.1
                        RM: graceful
                        RD: 0


                The Call Agent thereby sees, that the trunking gateway
                is planning on making all its endpoints unavailable
                gracefully. Since the restart delay is specified to be
                zero, the Call Agent furthermore knows, that it can
                safely leave all existing connections on the gateway,
                however it should not attempt to establish any new con-
                nections for these endpoints -- or at least only estab-
                lish connections related to existing calls.

                The Call Agent immediately acknowledges the command:

                        200 1200 OK


                Later, the external management system decides that it
                will no longer wait indefinitely for the existing con-
                nections to cease to exist. The gateway therefore sends
                a RestartInProgress message to the Call Agent informing
                it, that all the endpoints will become unavailable
                within 5 minutes (300 seconds), and any connections
                existing at that point in time will be torn down:

                        RSIP 1201 *@trgw-7.whatever.net MGCP 0.1
                        RM: graceful
                        RD: 300


                The Call Agent immediately acknowledges the command:

                        200 1201 OK




Huitema, Andreasen, Arango, Prakash                           [Page 108]


Internet draft              MGCP Call Flows              20 January 1999


                The Call Agent now has 5 minutes to tear down any exist-
                ing connections.

                Before the 5 minutes have elapsed, we imagine a hardware
                problem develops with one of the circuits on card23 in
                the trunking gateway and that the circuit immediately
                must be taken out service. The gateway informs the Call
                Agent about this by issuing the RestartInProgress com-
                mand as follows:

                        RSIP 1202 card23/20@trgw-7.whatever.net MGCP 0.1
                        RM: forced


                In this case, no restart delay was specified since a
                "forced" restart always takes effect immediately. If a
                restart delay had been specified, it would simply have
                been ignored. Any connections that existed for the end-
                point will have been lost.

                The Call Agent immediately acknowledges the command and
                notes that card23/20 is out of service:

                        200 1202 OK



                A little later, the 5 minutes grace period the Call
                Agent was notified about earlier has now passed, and -
                as a courtesy - the trunking gateway informs the Call
                Agent that all endpoints have now been taken out of ser-
                vice:

                        RSIP 1203 *@trgw-7.whatever.net MGCP 0.1
                        RM: forced


                Although the Call Agent has already been informed that
                card23/20 is out of service, the trunking gateway
                includes it in the list of endpoints here anyway. This
                is perfectly valid since placing an out-of-service end-
                point in out-of-service can be considered idempotent as
                long as the gateway deletes all connections associated
                with those endpoints (out-of-service endpoints should
                not have any connections created on them). However, this
                would not be the case with placing in-service endpoints
                in-service as such operations have side-effects on
                existing connections. In that case, the Call Agent would



Huitema, Andreasen, Arango, Prakash                           [Page 109]


Internet draft              MGCP Call Flows              20 January 1999


                therefore assume, that endpoints already in-service had
                been restarted to be in-service again.

                The Call Agent immediately acknowledges the command:

                        200 1203 OK



                At this point, all endpoints in the trunking gateway are
                now out of service.

                We then assume that the trunking gateway is rebooted and
                all endpoints are placed back in service. After the
                reboot, the trunking gateway informs its default Call
                Agent (CA-2), that all its endpoints are now back in
                service by sending the following RestartInProgress com-
                mand:

                        RSIP 1204 *@trgw-7.whatever.net MGCP 0.1
                        RM: restart
                        RD: 0


                Since the restart delay specified is zero, all endpoints
                are in-service at this point in time. However, it should
                be noted, that this does not necessarily imply that the
                same endpoints are available as before. For instance,
                card23 could have been removed from the trunking gateway
                to correct the aforementioned circuit problem.

                The Call Agent (CA-2) recognizes that CA-1 is the pre-
                ferred Call Agent for this trunking gateway and when
                CA-2 acknowedges the command, it therefore includes CA-1
                as the NotifiedEntity. Furthermore, CA-2 notes that any
                connections that may have existed for these endpoints
                prior to receiving this command no longer exists. CA-2
                is expected to communicate this information to CA-1 in
                order to achieve the internal Call Agent synchronization
                required:

                        200 1204 OK
                        N: CA-1@whatever.net








Huitema, Andreasen, Arango, Prakash                           [Page 110]


Internet draft              MGCP Call Flows              20 January 1999


                7.  Using MGCP to control an IVR

                This section describes the call flows between the CA,MG
                and IVR in order to understand the way MGCP organises
                the communication between the Media gateway
                controller/call agent and the Media gateway or an IVR.

                The IVR is controlled by the call agent using only the
                existing MGCP primitives.

                The number of calls that an IVR can support is defined
                as the number of endpoints on that IVR. These end points
                may be maintained by the IVR itself in which case the
                Call agent always uses wildcards for createconnection or
                it may be maintained by the Call agent.  There are a
                variety of scripts that can be executed on a particular
                ivr endpoint.They may be as simple as just playing a
                message (in which case the IVR is used as a simple
                anouncement server) or playing a message collect digits
                and give it to the call agent or as complex as an admin-
                istrative script which allows a remote administrator to
                configure the call agent .

                The format of the script and the implementation of the
                script may be vendor specific.

                The only assumtion is that the call agent is pre config-
                ured with the script names and it knows what script to
                use when.

                The MGCP primitives are interpreted by the IVR in the
                following way

                CreateConnection:
                     When this command is received by the IVR it allo-
                     cates the resources and returns the RTP profile
                     associated with the logical endpoint.  The connec-
                     tion mode should always be inactive. Note that the
                     IVR starts executing the script if the  connection
                     mode is not set to inactive.

                ModifyConnection:
                     This is used by the Call agent to trigger the exe-
                     cution of the script. Here the connection mode is
                     set to sendrecv.If it is set to sendonly the IVR
                     can play message or tones but cannot collect dtmf.

                NotificationRequest:



Huitema, Andreasen, Arango, Prakash                           [Page 111]


Internet draft              MGCP Call Flows              20 January 1999


                     Notifies the Call agent when the script has fin-
                     ished executed and returns the result.For now the
                     result is only in the form of digits.

                DeleteConnection:
                     Stops executing the script if it is not already
                     terminated and frees the resources.

                NOTE : The call flows do not show the Delete connection
                on the Incoming side when the IVR terminates. This is
                because the incomming call may be routed to another des-
                tination by the call agent depending on the notification
                results got from the IVR.

                7.1.  Connecting a Residential Gateway to the IVR


                7.1.1.  Connection from RGW to IVR

                       __________________________________________
                      |   USER   |   RGW  |      CA     |   IVR |
                      |__________|________|_____________|_______|
                      |          |   <--  |      RQNT   |       |
                      |          |   ACK  |      -->    |       |
                      | OFF HOOK |   NTFY |      -->    |       |
                      |          |   <--  |      ACK    |       |
                      |          |   <--  |   CRCX+RQNT |       |
                      |          |   ACK  |      -->    |       |
                      |          |        |   CRCX+RQNT |   --> |
                      |          |        |      <--    |   ACK |
                      |          |   <--  |      MDCX   |       |
                      |          |   ACK  |      -->    |       |
                      |          |        |     MDCX    |   --> |
                      |          |        |      <--    |   ACK |
                      |__________|________|_____________|_______|


                The first command is a NotificationRequest, sent by the
                Call Agent to the residential gateway. The request will
                consist of the following lines:

                        RQNT 1201 endpoint/1@rgw-2567.whatever.net MGCP 0.1
                        N: ca@ca1.whatever.net:5678
                        X: 0123456789AC
                        R: hd


                The gateway immediately acknowledges the command,



Huitema, Andreasen, Arango, Prakash                           [Page 112]


Internet draft              MGCP Call Flows              20 January 1999


                repeating in the acknowledgement message the transaction
                id that the Call Agent attached to the query.

                        200 1201 OK


                When the off hook event is noticed the gateway will
                notify the event to the Call Agent:

                        NTFY 2002 endpoint/1@rgw-2567.whatever.net MGCP 0.1
                        N: ca@ca1.whatever.net:5678
                        X: 0123456789AC
                        O: hd


                The Call Agent immediately acknowledges that notifica-
                tion.

                        200 2002 OK


                The Call Agent will then seize the incoming circuit,
                creating a connec- tion.  The create connection command
                piggybacks a notification request, to watch for an on-
                hook transition:

                        CRCX 1204 endpoint/1@rgw-2567.whatever.net MGCP 0.1
                        C: A3C47F21456789F0
                        L: p:10, a:G.711;G.726-32
                        M: recvonly
                        X: D123456789AD
                        R: hu


                The gateway immediately acknowledges the creation, send-
                ing back the identification of the newly created connec-
                tion and the session descrip- tion used to receive audio
                data:

                        200 1204 OK
                        I:FDE234C8

                        v=0
                        c=IN IP4 128.96.41.1
                        m=audio 3456 RTP/AVP 0 96
                        a=rtpmap:96 G726-32/8000





Huitema, Andreasen, Arango, Prakash                           [Page 113]


Internet draft              MGCP Call Flows              20 January 1999


                The Call Agent, having seized the incoming trunk and
                deciding that the call has to be terminated on the IVR
                and that a script will be executed, sends a connection
                command to the IVR.

                        CRCX 1205 #@ivr45.whatever.net MGCP 0.1
                        C: A3C47F21456789F0
                        L: p:10, a:G.711;G.726-32
                        M: inactive

                        v=0
                        c=IN IP4 128.96.41.1
                        m=audio 3456 RTP/AVP 0 96
                        a=rtpmap:96 G726-32/8000


                The CreateConnection is sent to  a generic endpoint,
                asking the IVR to pick one of its available ports.

                The IVR will acknowledge the connection command, sending
                in the identification of the selected endpoint, the con-
                nection identifier and the session description its own
                parameters such as address, ports and RTP profile:

                        200 1205 OK
                        Z:17@ivr45.whatever.net
                        I:32F345E2

                        v=0
                        c=IN IP4 128.96.63.25
                        m=audio 1296 RTP/AVP 0 96
                        a=rtpmap:96 G726-32/8000


                The Call Agent will relay the information to the Media
                gateway, using a ModifyConnection command:

                        MDCX 1206 endpoint/1@rgw-2567.whatever.net MGCP 0.1
                        C: A3C47F21456789F0
                        I:FDE234C8
                        M: sendrecv

                        v=0
                        c=IN IP4 128.96.63.25
                        m=audio 1296 RTP/AVP 0 96
                        a=rtpmap:96 G726-32/8000





Huitema, Andreasen, Arango, Prakash                           [Page 114]


Internet draft              MGCP Call Flows              20 January 1999


                The media gateway immediately acknowledges the modifica-
                tion:

                        200 1206 OK


                At this point the caller is ready, a duplex path has
                been established between the caller and the IVR, all the
                resources have been allocated and the Call agent has to
                trigger the script execution. It does this by sending a
                ModificationRequest with an embedded NotificationRequest
                command to the IVR.

                        MDCX 1207 17@ivr45.whatever.net MGCP 0.1
                        C: A3C47F21456789F0
                        M: sendrecv
                        X: D23456789AD
                        R: Script/oc, Script/of
                        D: Script/perl(http://database.whatever.net/script-23.prl)


                The IVR immediately acknowledges the modification:

                        200 1207 OK


                At this point the caller is interacting with the IVR.
                This ends with either the caller going on hook or the
                IVR deciding it has to notify the Call agent.

                7.1.2.  Disconnecting the user from IVR:(termination by
                IVR)

                          ____________________________________
                         | USER |   RGW |     CA   |    IVR  |
                         |______|_______|__________|_________|
                         |      |       |    <--   |    NTFY |
                         |      |       |    ACK   |    -->  |
                         |      |       |   DLCX-- |    -->  |
                         |      |       |    <--   |   ---ACK|
                         |______|_______|__________|_________|


                When the call agent receives

                        NTFY 2002 17@ivr45.whatever.net MGCP 0.1
                        N: ca@ca1.whatever.net:5678
                        X: D23456789AD



Huitema, Andreasen, Arango, Prakash                           [Page 115]


Internet draft              MGCP Call Flows              20 January 1999


                        O: script/oc(54321)


                The Call agent immediately acknowledges the notifica-
                tion:

                        200 2002 OK


                and send a delete connection to the IVR

                        DLCX 1211 script23/21@ivr45.whatever.net MGCP 0.1
                        C: 567F21456789F0
                        I:32F345E2


                the IVR frees up the resources and responds with

                        200 1211 OK
                        P: PS=1245, OS=62345, PR=780, OR=45123, PL=10, JI=27,LA=48


                The call agent may now deal with the incoming call by
                sending a delete connection, execute another script on
                the IVR, or route the call to another gateway, and so
                on.

                7.1.3.  Disconnecting The User From Ivr:(Termination By
                Caller)

                          ___________________________________
                         |  USER   |   RGW |    CA  |   IVR |
                         |_________|_______|________|_______|
                         | On hook |   NTFY|   -->  |       |
                         |         |   <-- |    ACK |       |
                         |         |       |   DLCX |   --> |
                         |         |       |   <--  |   ACK |
                         |         |   <-- |   DLCX |       |
                         |         |   ACK |    --> |       |
                         |_________|_______|________|_______|


                When the call agent receives

                        NTFY 2056 endpoint/1@rgw-2567.whatever.net MGCP 0.1
                        N: ca@ca1.whatever.net:5678
                        X: D123456789AD
                        O: hu



Huitema, Andreasen, Arango, Prakash                           [Page 116]


Internet draft              MGCP Call Flows              20 January 1999


                it responds with

                        200 2056 OK


                and deletes the connections on both the IVR

                        DLCX 1211 17@ivr45.whatever.net MGCP 0.1
                        C: A3C47F21456789F0
                        I:32F345E2


                IVR frees up the resources and responds with

                        200 1211 OK
                        P: PS=1245, OS=62345, PR=780, OR=45123, PL=10, JI=27,LA=48


                and the media gateway

                        DLCX 1261 endpoint/1@rgw-2567.whatever.net MGCP 0.1
                        C: A3C47F21456789F0
                        I:FDE234C8


                Gateway frees up the resources and responds with

                        200 1261 OK
                        P: PS=1245, OS=62345, PR=780, OR=45123, PL=10, JI=27,LA=48


                7.2.  Connection between a TGW and an IVR

                7.2.1.  Setting up the connection from TGW to IVR

                The figure below gives the flow for the IVR connected to
                a TGW














Huitema, Andreasen, Arango, Prakash                           [Page 117]


Internet draft              MGCP Call Flows              20 January 1999


                      ___________________________________________
                     | SS7/ISUP |   TGW |   CA          |   IVR |
                     |__________|_______|_______________|_______|
                     | IAM      |  ---  |   -->         |       |
                     |          |   <-- |   CRCX        |       |
                     |          |   ACK |   -->         |       |
                     | <--      |   --- |   ACM         |       |
                     |          |       |   CRCX+RQNT-->|       |
                     |          |   <-- |   ---ACK      |       |
                     |          |   <-- |   -MDCX       |       |
                     |          |   ACK |   -->         |       |
                     | <--      |   --- |   ANM         |       |
                     |          |       |   MDCX        |   --> |
                     |          |   <-- |   ----ACK     |       |
                     |__________|_______|_______________|_______|


                When the CA detects an incoming call it sends a
                CreateConnection command to the media gateway.

                        CRCX 1204 ss7end/1@tgw90.whatever.net MGCP 0.1
                        C: A3C47F21456789F0
                        L: p:10, a:G.711;G.726-32
                        M: recvonly


                The media gateway responds with

                        200 1204 OK
                        I:FDE234C8

                        v=0
                        c=IN IP4 128.96.41.1
                        m=audio 3456 RTP/AVP 0 96
                        a=rtpmap:96 G726-32/8000


                The CA then creates a connection on the IVR

                        CRCX 1205 #@ivr45.whatever.net MGCP 0.1
                        C: A3C47F21456789F0
                        L: p:10, a:G.711;G.726-32
                        M: inactive

                        v=0
                        c=IN IP4 128.96.41.1
                        m=audio 3456 RTP/AVP 0 96
                        a=rtpmap:96 G726-32/8000



Huitema, Andreasen, Arango, Prakash                           [Page 118]


Internet draft              MGCP Call Flows              20 January 1999


                The IVR will acknowledge the connection command, sending
                in the session description its own parameters such as
                address, ports and RTP profile:

                        200 1205 OK
                        Z: 17@ivr45.whatever.net
                        I:32F345E2

                        v=0
                        c=IN IP4 128.96.63.25
                        m=audio 1296 RTP/AVP 0 96
                        a=rtpmap:96 G726-32/8000


                The Call Agent will relay the information to the Media
                gateway, using a ModifyConnection command:

                        MDCX 1206 endpoint/1@rgw-2567.whatever.net MGCP 0.1
                        C: A3C47F21456789F0
                        I:FDE234C8
                        M: sendrecv

                        v=0
                        c=IN IP4 128.96.63.25
                        m=audio 1296 RTP/AVP 0 96
                        a=rtpmap:96 G726-32/8000


                The media gateway immediately acknowledges the modifica-
                tion:

                        200 1206 OK


                At this point the caller is ready,a duplex path has been
                established between the caller and the IVR ,all the
                resources have been allocated and the Call agent has to
                trigger the script execution. It does this by sending a
                ModifyConnection command to the IVR, with an embedded
                notification request.

                        MDCX 1206 17@ivr45.whatever.net MGCP 0.1
                        C: A3C47F21456789F0
                        I:32F345E2
                        X: D23456789AD
                        M: sendrecv
                        R: Script/oc, Script/of
                        D: Script/perl(http://database.whatever.net/script-12.prl)



Huitema, Andreasen, Arango, Prakash                           [Page 119]


Internet draft              MGCP Call Flows              20 January 1999


                The IVR immediately acknowledges the modification:

                        200 1206 OK


                At this point the caller is interacting with the
                IVR.This ends with either the caller going on hook or
                the IVR deciding it has to notify the Call agent.

                7.2.2.  Disconnecting The User From IVR:TGW

                Termination by the IVR:

                        ________________________________________
                       | SS7/ISUP |   TGW |     CA   |    IVR  |
                       |__________|_______|__________|_________|
                       |          |       |    <--   |   --NTFY|
                       |          |       |   ACK--  |    -->  |
                       |          |       |   DLCX-- |    -->  |
                       |          |       |    <--   |   ---ACK|
                       |__________|_______|__________|_________|


                7.2.3.  Termination by the Caller

                 ______________________________________________________
                | SS7/ISUP |   TGW |             CA           |   IVR |
                |    REL   |   --- |             -->          |       |
                |          |       |                          |       |
                |          |       |            DLCX          |   --> |
                |          |       |            <--           |   ACK |
                |          |   <-- |            -DLCX         |       |
                |          |   ACK |             -->          |       |
                |    <--   |   --- |             RLC          |       |
                |__________|_______|__________________________|_______|
















Huitema, Andreasen, Arango, Prakash                           [Page 120]


Internet draft              MGCP Call Flows              20 January 1999


                7.3.  Hairpin IVR connection, double end-point model

                The figure below gives the flow that results in an hair-
                pin connection to an IVR device located on the same
                gateway as the trunk on which the call is incoming.  In
                this flow, we assume that we use the "double endpoint"
                extensions to the create-connection command, and, as an
                example, assume that the IVR exchange results in an
                automatic disconnection.

                       _________________________________________
                      | sw1|  sw2|  SG |   CA  |  TGW-1|   IVR |
                      |____|_____|_____|_______|_______|_______|
                      | IAM|  - -|  -> |       |       |       |
                      |    |     |  IAM|  ->   |       |       |
                      |    |     |     |  CRCX+|   ->  |  (->) |
                      |    |     |     |  RQNT |   ->  |  (->) |
                      |    |     |     |    <- |   ACK |  (ACK)|
                      |    |     |   <-|  ANM  |       |       |
                      |  <-|  - -|  ANM|       |       |       |
                      |    |     |     |    <- |   - - |  NTFY |
                      |    |     |     |   ACK |   - - |   ->  |
                      |    |     |     |  DLCX |   ->  |       |
                      |    |     |     |    <- |  Perf |       |
                      |    |     |     |       |  data |       |
                      |    |     |   <-|  REL  |       |       |
                      |  <-|  - -|  REL|       |       |       |
                      |    |     |     |  DLCX |       |   ->  |
                      |    |     |     |    <- |   - - |  Perf |
                      |    |     |     |       |       |  data |
                      |____|_____|_____|_______|_______|_______|


                During these exchanges the MGCP is used by the Call
                Agent to control two endpoints located on the same TGW.

                The exchanges start with the arrival from the first
                switch (SW1) of an SS7/ISUP "IAM" message, relayed by
                the signalling gateway to the Call Agent.  The call
                agent performs the routing, and determines that the call
                will have to be relayed towards the second switch (SW2),
                using a trunk located on the same gateway.

                The call agent starts the exchange by seizing the end-
                point referenced in the IAM message, and by requesting a
                local connection between that endpoint and the IVR dev-
                ice.  The command also instruct the IVR to start execut-
                ing a script on the selected IVR endpoint:



Huitema, Andreasen, Arango, Prakash                           [Page 121]


Internet draft              MGCP Call Flows              20 January 1999


                        CRCX 1204 trunk-group-1/17@tgw.whatever.net MGCP 0.1
                        C: A3C47F21456789F0
                        L: nt=LOCAL
                        M: sendrecv
                        2/E: IVR/$
                        2/X: D23456789AD
                        2/R: Script/oc, Script/of
                        2/D: Script/perl(http://database.whatever.net/script-12.prl)


                Upon reception of that command, the trunking gateway
                prepares a "local" connection description between the
                specified endpoint (trunk-group-1/17) and an endpoint
                that it selects within the IVR (IVR/6).  The gateway
                acknowledges the two creations in a single message:

                        200 1204 OK
                        I:FDE234C8

                        v=0
                        c=IN tgw.whatever.net trunk-group-1/17
                        m=audio 0 LOCAL 0
                        2/Z:IVR/13@tgw.whatever.net
                        2/I:abc0
                        2/
                        v=0
                        c=IN tgw.whatever.net IVR/13
                        m=audio 0 LOCAL 0


                The command has created a path between the endpoint and
                the IVR. Because the IVR is in fact answering the call,
                the call agent can immediately relay an ANM message to
                the calling switch.

                At this point the caller is interacting with the IVR.
                This ends with either the caller going on hook or the
                IVR deciding it has to notify the Call agent.

                        NTFY 2001 IVR/13@tgw.whatever.net MGCP 0.1
                        X: D23456789AD
                        O: Script/oc(123245)


                The call agent immediately acknowledges the notifica-
                tion:

                        200 2001 OK



Huitema, Andreasen, Arango, Prakash                           [Page 122]


Internet draft              MGCP Call Flows              20 January 1999


                The call agent should then remove the connections. The
                call agent releases the connection on the first end-
                point:

                        DLCX 1207 trunk-group-1/17@tgw.whatever.net MGCP 0.1
                        C: A3C47F21456789F0
                        I:FDE234C8

                The gateway acknowledges the deletion, sending the con-
                nection parameters:

                        250 1217 OK
                        P: OS=62345, OR=62345

                The call agent can now notify the release of the trunk
                to the switch which will in response send an RLC mes-
                sage.

                In parallel, the call agent releases the connection to
                the IVR:

                        DLCX 1208 IVR/13@tgw.whatever.net MGCP 0.1
                        C: A3C47F21456789F0
                        I:abc0


                The gateway acknowledges the deletion, sending the con-
                nection parameters:

                        250 1218 OK
                        P: OS=62345, OR=62345




















Huitema, Andreasen, Arango, Prakash                           [Page 123]


Internet draft              MGCP Call Flows              20 January 1999


                8.  Acknowledgements

                We want to thank here the many reviewers who helped
                design the MGCP flows, notably Ike Elliott and  Chip
                Sharp.

                9.  References

                [0]  Arango, M., A. Dugan, I. Elliott, C. Huitema, S.
                     Pickett, "Media Gateway Control Protocol (MGCP)",
                     work in progress.

                [1]  ITU-T, Recommendation Q.761, "FUNCTIONAL DESCRIP-
                     TION OF THE ISDN USER PART OF SIGNALLING SYSTEM No.
                     7", (Malaga-Torremolinos, 1984; modified at Hel-
                     sinki, 1993)

                [2]  ITU-T, Recommendation Q.762, "GENERAL FUNCTION OF
                     MESSAGES AND SIGNALS OF THE ISDN USER PART OF SIG-
                     NALLING SYSTEM No. 7", (Malaga-Torremolinos, 1984;
                     modified at Helsinki, 1993)

                *    ITU-T, Recommendation H.323, "VISUAL TELEPHONE SYS-
                     TEMS AND EQUIPMENT FOR LOCAL AREA NETWORKS WHICH
                     PROVIDE A NON-GUARANTEED QUALITY OF SERVICE."

                *    ITU-T, Recommendation H.225, "Call Signaling Proto-
                     cols and Media Stream Packetization for Packet
                     Based Multimedia Communications Systems."

                *    ITU-T, Recommendation H.245, "LINE TRANSMISSION OF
                     NON-TELEPHONE SIGNALS."

                *    Handley, Shulzrinne, Schooler, Rosenberg, "SIP:
                     Session Initiation Protocol", work in progress

                10.  Authors' Addresses

                                   Christian Huitema
                                   Bellcore
                                   MCC 1J236B
                                   445 South Street
                                   Morristown, NJ 07960
                                   U.S.A.

                                   Phone: +1 973-829-4266
                                   EMail: huitema@bellcore.com




Huitema, Andreasen, Arango, Prakash                           [Page 124]


Internet draft              MGCP Call Flows              20 January 1999


                                   Flemming Andreasen
                                   Bellcore
                                   RRC-1M223
                                   444 Hoes Lane
                                   Piscataway, NJ 08854-4157
                                   U.S.A.

                                   Phone: +1 732 699-7351
                                   EMail: fandreas@notes.cc.bellcore.com

                                   Mauricio Arango
                                   RSL COM Latin America
                                   6300 N.W. 5th Way, Suite 100
                                   Ft. Lauderdale, FL 33309

                                   Phone: (954) 492-0913
                                   Email: marango@rslcom.com


                                   Prakash K
                                   TELESOFT INC
                                   3000, Custer Road
                                   Suite 270
                                   Plano, Texas - 75075
                                   U.S.A

                                   Tel: 972-596-4158
                                   Fax: 817-323-1605
                                   EMail: prakashk@indts.com






















Huitema, Andreasen, Arango, Prakash                           [Page 125]