Home > Articles > Networking

  • Print
  • + Share This
This chapter is from the book

This chapter is from the book

Protocols at work

Having seen the architecture where and media gateway to media gateway controllers protocols fit, we propose now to describe the call flows for some simple scenarios. We hope that, as we did for H.323, it will help readers to better understand the usage of the protocol. In addition to these call flows we have included an H.323 call flow for the same scenarios.

Scenario 1

03fig04.gifFigure 3.4. Scenario 1


User A calls user B through two residential gateways, A and B (see Fig. 3.4). There is no use of SS7 facilities. MGCP is used by the call agent to control the two residential gateways. We made the following assumptions for this scenario:

  • residential gateway (RGW) to RGW

  • no state hold in the GW

  • one centralized call agent that controls the two residential gateways

  • no supplementary services, just basic call

  • no data call (no network access server)

  • no charging or accounting

  • no QOS signaling

  • no network or equipment failure.

Network configuration

The configuration analyzed here is a simple network topology. The call agent which provides the intelligence for the IP telephony service controls two gateways. These gateways serve two non-overlapping geographical areas. The call agent functions in this configuration can be compared to the functions of a gatekeeper using the gatekeeper routed call signaling model.

Call flows

Table 3.2 shows the call flows for Scenario 1.

Table 3.2. Call flows for scenario 1

Round trips

User A

RGW A

Call Agent

RGW B

User B

Steps

(initial)

 

RQNT

 

1

 
 

ACK

 

2

   

0.5

Off-hook

NTFY

 

3

 

1

 

ACK

 

4

 

1

Dial-tone

RQNT

 

5

 

1.5

 

ACK

 

6

 

1.5+x

Digit

NTFY

 

7

 

2+x

 

ACK

 

8

 

2+x

(Progress)

RQNT+CRCX

 

9

 

2.5+x

 

ACK

 

10

 

5.5

 

CRCX

 

11

 

6

 

ACK

 

12

 

N

 

Database lookup

 

13

   
 

(call processing)

         

6.5

 

CRCX

 

14

 

7

 

ACK

 

15

 

7.5

 

MDCX

 

16

 

8

 

ACK

 

17

 

8.5

 

RQNT

Ring

18

 

9

 

ACK

 

19

 

9.5

(ringing)

RQNT

 

20

 

10

 

ACK

 

21

 

10.5

 

NTFY

Off-hook

22

 

11

 

ACK

 

23

 

11.5

 

RQNT

 

24

 

12

 

ACK

 

25

 

12.5

 

MDCX

 

26

 

13

 

ACK →

 

27

   
 

(call established)

         
             
 

(Talking)

         
             

0.5

On-hook

NTFY

 

28

 

1

 

ACK

 

29

 

1.5

 

DLCX

 

30

 

2

 

DLCX

 

31

 

2.5

 

RQNT

 

32

 

3

 

ACK

 

33

 

3.5

 

RQNT

34

  

4

 

ACK

35

  
  1. Call agent: instructs the RGW A to look for an off-hook event and report it. Sends a Notification Request to the RGW A.

  2. RGW A: sends an acknowledgement message to the call agent.

  3. RGW A: user A goes off-hook, the gateways detect the event and send a Notification to call agent.

  4. Call agent: sends an acknowledgement message to the RGW A.

  5. Call agent: the call agents look at the services associated to an off-hook action and send a Notification Request to the RGW A asking for more digits and request the GRW A to play the dial tone to user A.

  6. RGW A: sends an acknowledgement message to the call agent.

  7. RGW A: accumulates the dialed digits and sends a Notification to the call agent.

  8. Call agent: sends an acknowledgement message to the RGW A.

  9. Call agent: sends a Notification Request to stop collecting digits and watch for an on-hook transition. At this stage the call agent has got the necessary information to resolve the dialed number.

  10. RGW A: sends an acknowledgement message to the call agent.

  11. Call agent: seizes the incoming circuit. It sends a Create Connection message to the RGW A.

  12. RGW A: sends an acknowledgement message to the call agent along with the session description used to receive audio data.

  13. Call agent: the call agent queries a database to resolve the E.164 address and to find the remote gateway, RGW B, serving this number. This query may take a few other sets of messages. This request may also encapsulate authentication and authorization queries.

  14. Call agent: the call agent knows the IP address of the RGW B and having seized the incoming trunk will now seize the outgoing trunk by sending a Create Connection command to the RGW B.

  15. RGW B: sends an acknowledgement message to the call agent along with the session description used to receive audio data.

  16. Call agent: can now relay the received information back to the RGW A by sending a Modify Connection to the RGW A. At this point two legs of the call are established in half duplex mode.

  17. RGW A: sends an acknowledgement message to the call agent.

  18. Call agent: instructs the RGW B to generate ringing tones by sending a Notification Request.

  19. RGW B: sends an acknowledgement message to the call agent.

  20. Call agent: notifies A that B is ringing.

  21. RGW A: sends an acknowledgement message to the call agent.

  22. RGW B: the user B answers the call and the RGW B sends a Notification to the call agent that the user B is answering the call.

  23. Call agent: sends an acknowledgement message to the call agent.

  24. Call agent: sends a Notification Request to the RGW A to stop ringing.

  25. RGW A: sends an acknowledgement message to the call agent.

  26. Call agent: sends a Modify Connection message to the RGW A to change the communication mode from half duplex to full duplex.

  27. RGW A: sends an acknowledgement message to the call agent. The call is now taking place.

  28. RGW A: the user A terminates the call and the RGW A sends the on-hook event to the call agent through the notification message.

  29. Call agent: sends an acknowledgement message to the call agent.

  30. Call agent: sends a Delete Connection message to the RGW A. No ACK is necessary from the GW.

  31. Call agent: sends a Delete Connection message to the RGW B. No ACK is necessary from the GW.

  32. Call agent: issues a new Notification Request to the RGW A asking it to be ready for the next off-hook event.

  33. RGW A: sends an acknowledgement message to the call agent.

  34. Call agent: issues a new Notification Request to the RGW B asking it to be ready for the next off-hook event.

  35. RGW B: sends an acknowledgement message to the call agent.

Scenario 2

In this scenario we examine the call setup flows of a basic call. The user A calls user B. Basic assumptions are:

  • use of quasi associated mode

  • signaling is separated from voice.

Network configuration

03fig05.gifFigure 3.5. Scenario 2


The user A is attached to an analogue terminal (see Fig. 3.5). The CO (central office) that serves the user A is connected to the SS7 network through signaling transfer points. The service provider uses an IP backbone to carry its extra traffic. The interconnection between the circuit switched network and the IP backbone is done at two logical layers:

  • at the signaling layer, the STP is connected to the call agent through a signaling gateway that converts ISUP over MTP messages into a protocol over IP4 (kind of ISUP over IP, and not Q.931 over IP) . The call agent acts as an intermediary between the signaling gateway and the trunking gateway;

  • at the voice layer, the switch is connected to a trunking gateway. The trunking gateway is controlled by the call agent as well as the residential gateway by using the MGCP.

The functional split of the call agent is shown in Fig. 3.6.

03fig06.gifFigure 3.6. Call agent’s functional design


Call flows

Table 3.3 shows the call flows for scenario 2.

Table 3.3. Call flows for scenario 2

Round trips

CO

SS7

TGW

Call Agent

RGW

User

Steps

0.5

IAM

 

1

     

1

 

IAM

 

 

2

 

1.5

 

Database lookup

 

3

     

2

 

CRCX

 

4

   

2.5

 

ACK

 

5

   

3

 

CRCX

 

6

   

3.5

 

ACK

 

7

   

4

 

MDCX

 

8

   

4.5

 

ACK

 

9

   

5

 

RQNT

Ring

10

   

5.5

 

ACK

 

11

   

6

 

 

ACM

     
 

12

      

6.5

ACM

 

13

   
 

Off-hook

14

     

7

 

NTFY

 

15

  

7.5

 

ACK

 

16

  

8

 

RQNT

 

17

  

8.5

 

ACK

 

18

  

9

 

MDCX

 

19

  

9.5

 

ACK

 

20

  

10

 

 

ANM

 

21

 

10.5

ANM

 

22

   
 

(Talking)

 

23

    
 

On-hook

24

     

0.5

 

NTFY

 

25

  

1

 

ACK

 

26

  

1.5

 

DLCX

 

27

  

2

 

DLCX

 

28

  

2.5

 

 

REL

 

29

 
  1. CO: issues an initial address message (IAM) to the call agent through its STP.

  2. SS7: the Signaling Transfer Point (STP) routes the ISUP message to the signaling gateway attached to the call agent.

  3. Call agent: queries a database to find out the IP address of the residential gateway serving the destination number.

  4. Call agent: sends a Create Connection message to the trunking gateway to connect to the incoming trunk (uses the circuit identification code (CIC)).

  5. TGW: sends an acknowledgement message to the call agent.

  6. Call agent: seizes the incoming trunk and reserves the outgoing trunk circuit by sending a Create Connection message to the residential gateway.

  7. RGW: sends an acknowledgement message to the call agent.

  8. Call agent: will now indicate this information to the TGW by sending a Modify Connection to the TGW.

  9. TGW: sends an acknowledgement message to the call agent.

  10. Call agent: requests the residential gateway to ring the called line by sending a Notification Request message to the RGW.

  11. RGW: sends an acknowledgement message to the call agent.

  12. Call Agent: when the call agent receives the ACK from the RGW, it issues Address Complete message to the signaling gateway.

  13. SS7: the STP conveys this information back to the CO.

  14. User: terminal goes off-hook.

  15. RGW: detects this event and notifies the call agent by sending a Notification message.

  16. Call agent: sends an acknowledgement message to the call agent.

  17. Call agent: in order to be able to detect the termination of a call, the call agent asks the RGW to report an on-hook event by sending a Notification Request message.

  18. RGW: sends an acknowledgement message to the call agent.

  19. Call agent: now the voice channel has to be turned into the full duplex mode; the call agent does this by sending a Modify Connection message to the TGW.

  20. TGW: sends an acknowledgement message to the call agent.

  21. Call agent: can now send an answer message to the signaling gateway.

  22. SS7: the STP sends this information to the CO.

  23. Both parties are talking.

  24. RGW: the user B’s terminal goes on-hook.

  25. The RGW sends a Notification message to the call agent.

  26. Call agent: sends an acknowledgement message to the call agent.

  27. Call agent: sends a Delete Connection message to the RGW.

  28. Call agent: sends a Delete Connection message to the TGW.

  29. Call agent: issues a RELEASE message to the signaling gateway.

  30. SS7: the STP conveys this information back to the CO.

Analysis

It should be noted that MGCP specification allows the combination of commands to be sent in one PDU, e.g. steps 24–27 in scenario 1 and steps 17–20 in scenario 2, and can be combined as MDCX+RQNT PDU. This combination allows a reduction in the number of messages necessary to set up a call.

On the other hand:

  • in order to establish a phone to phone call, MGCP requires at least 11 round trips;5

  • in the MGCP architecture, the call agent has to manage explicit interactions with the media gateway, as opposed to the current H.323 model where these interactions are performed by an H.323-compliant gateway;

  • MGCP gives the flexibility for per user or per call-based events to be created. A dialing plan per user, for example;

  • MGCP gives more control to the call agent or the media gateway controller, since it allows the call agent to act as a call-control element like an H.323 gatekeeper using the gatekeeper routed call model, while at the same time controlling tightly the media gateway functionality that is not available in H.323v2;

  • when MGCP is used in the trunking mode, its advantage with respect to the number of PDU exchanges between the call agent and the media gateway is obvious. This is due mainly to the fact that MGCP uses the UDP as the transport protocol as opposed to TCP in H.323;

  • MGCP architecture and its related functionalities enable the decrease of cost per port for a media gateway but increase the cost per port for a call agent or media gateway controller.

The H.323 case

03fig07.gifFigure 3.7. Scenario 3, the H.323 case


This is the same as scenario 2 but using H.323 (see Fig. 3.7). Basic assumptions are:

  • using gatekeeper routed call model

  • the signaling gateway communicates with the gatekeeper and not with the gateway

  • using Fast Connect procedure

  • there is no GRQ; the GK addresses are statically configured

  • no media can be sent by the called endpoint prior to the Connect message (calling endpoint sets the media WaitForConnect element to True in the Setup message)

  • no call proceeding message will be sent by the gateway, since it is expected that the Connect message will arrive before four seconds elapse

  • the RGW and TGW belong to the same zone – they are under the control of the GK

  • there are no Admission Request messages per call. We use the pregranted mode with the following flags set to true by the gatekeeper in its RCF messages to the gateways:

    MakeCall

    UseGKCallSignalAddressToMakeCall

    AnswerCall

    UseGKCallSignalAddressToAnswer

  • the RGW exchange admission messages prior to Setup message.

Network configuration

The user A is attached to an analogue terminal. The CO that serves the user A is connected to the SS7 network through signaling transfer points. The service provider uses an IP backbone to carry its extra traffic. The interconnection between the circuit switched network and the IP backbone is done at two logical layers:

  • at the signaling layer, the STP is connected to the gatekeeper through a signaling gateway that converts ISUP over MTP messages into a proprietary protocol over IP. The gatekeeper acts as an intermediary between the signaling gateway and the trunking gateway;

  • at the voice layer, the switch is connected to a trunking gateway. Both of the gateways are controlled by their own media gateway controllers and the gatekeeper.

Functional decomposition of the gatekeeper is shown in Fig. 3.8.

03fig08.gifFigure 3.8. Gatekeeper functional decomposition


Call flows

Table 3.4 shows the call flows for h.323.

Table 3.4. Call flows for H.323

Round trips

CO

SS7

GW

TGW

Gatekeeper

RGW

User

0.5

RRQ

     

1

RCF

     
 

TGW registered

      

1.5

RRQ

     

2

RCF

     
 

RGW registered

      

3

IAM

     

3.5

IAM

     

4

Database lookup

      

4.5

TCP SYN

     

5

SYN ACK

     

5.5

SETUP (fastStart)

     

6

TCP SYN

     

6.5

SYN ACK

     

7

SETUP (fastStart)→

      
 

Ring

      

7.5

ALERTING

     

8

ACM

     

8.5

ACM

     

9

Off-hook

      

9.5

TCP SYN

     

10

SYN ACK

     

10.5

CONNECT

     

11

TCP SYN

     

11.5

SYN ACK

     

12

CONNECT

     

12.5

ANM

     

13

ANM

     
 

(Talking)

      
 

On-hook

      

0.5

DRQ

     

1

DCF

     

1.5

DRQ

     

2

DCF

     

2.5

REL

     

3

REL

     
  1. The trunking gateway registers with the GK.

  2. The GK confirms the registration of the gateway and indicates it will use the GRC mode and exchanges any necessary tokens that can be used for the next coming protocols exchanges and indicates also the use of pregrantedARQs.

  3. The same exchange occurs for the residential gateway.

  4. Idem.

  5. The initial address message is sent by the ingress CO to the GK through the SS7 signaling gateway.

  6. On receipt of this message the GK looks up its database in order to decide where to route the incoming call.

  7. Because H.323 version 2 mandates the use of TCP for call-control signaling messages, the GK must first establish the TCP channel with the trunking gateway.

  8. Once the TCP connection is established, the GK issues the Setup message using the fastStart procedure as described in the specification.

  9. The GK goes through the same exchange of messages with the residential gateway.

  10. At this time logical channels are opened by the endpoints and they know where to send the RTP packets for the IP interface and where to send the PCM for the telephony interface.

  11. The user’s phone rings and the residential gateway sends the Alerting message to the GK.

  12. The GK issues the ACM message to the CO through the SS7 signaling gateway and the switch gets ready to send the incoming PCM to the outgoing port of one of its voice trunks.

Analysis

The observation of these simplified call flows shows that the current H.323 protocol is not suited for trunking as well as MGCP is. One of the reasons is the use of TCP. Although more reliable, TCP does not fulfill the performance requirements imposed by the SS7 signaling network. There are at least two solutions to this problem:

  • use of long-live TCP connections between gateways and the respective gatekeepers. This solution assumes that the configuration of the network is more static than dynamic, therefore these connections can be kept alive for long periods (improves steps 9.5, 10, 11, 11.5);

  • use of UDP instead of TCP. The release 3 of H.323 will allow as an optional mode (see Annex E of H.323) the use of UDP for the fastStart procedure. It is possible to extend the proposed communication model of this annex to other signaling protocols (H.225 and H.245) of H.323.

Obviously, H.323 does not have the same features as the MGCP with regard to media control, but on the other hand MGCP as defined today does not have all the features of H.323, especially those being provided by H.245 that are very useful with intelligent endpoints.

  • + Share This
  • 🔖 Save To Your Account