Home > Articles > Networking

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.

InformIT Promotional Mailings & Special Offers

I would like to receive exclusive offers and hear about products from InformIT and its family of brands. I can unsubscribe at any time.

Overview


Pearson Education, Inc., 221 River Street, Hoboken, New Jersey 07030, (Pearson) presents this site to provide information about products and services that can be purchased through this site.

This privacy notice provides an overview of our commitment to privacy and describes how we collect, protect, use and share personal information collected through this site. Please note that other Pearson websites and online products and services have their own separate privacy policies.

Collection and Use of Information


To conduct business and deliver products and services, Pearson collects and uses personal information in several ways in connection with this site, including:

Questions and Inquiries

For inquiries and questions, we collect the inquiry or question, together with name, contact details (email address, phone number and mailing address) and any other additional information voluntarily submitted to us through a Contact Us form or an email. We use this information to address the inquiry and respond to the question.

Online Store

For orders and purchases placed through our online store on this site, we collect order details, name, institution name and address (if applicable), email address, phone number, shipping and billing addresses, credit/debit card information, shipping options and any instructions. We use this information to complete transactions, fulfill orders, communicate with individuals placing orders or visiting the online store, and for related purposes.

Surveys

Pearson may offer opportunities to provide feedback or participate in surveys, including surveys evaluating Pearson products, services or sites. Participation is voluntary. Pearson collects information requested in the survey questions and uses the information to evaluate, support, maintain and improve products, services or sites, develop new products and services, conduct educational research and for other purposes specified in the survey.

Contests and Drawings

Occasionally, we may sponsor a contest or drawing. Participation is optional. Pearson collects name, contact information and other information specified on the entry form for the contest or drawing to conduct the contest or drawing. Pearson may collect additional personal information from the winners of a contest or drawing in order to award the prize and for tax reporting purposes, as required by law.

Newsletters

If you have elected to receive email newsletters or promotional mailings and special offers but want to unsubscribe, simply email information@informit.com.

Service Announcements

On rare occasions it is necessary to send out a strictly service related announcement. For instance, if our service is temporarily suspended for maintenance we might send users an email. Generally, users may not opt-out of these communications, though they can deactivate their account information. However, these communications are not promotional in nature.

Customer Service

We communicate with users on a regular basis to provide requested services and in regard to issues relating to their account we reply via email or phone in accordance with the users' wishes when a user submits their information through our Contact Us form.

Other Collection and Use of Information


Application and System Logs

Pearson automatically collects log data to help ensure the delivery, availability and security of this site. Log data may include technical information about how a user or visitor connected to this site, such as browser type, type of computer/device, operating system, internet service provider and IP address. We use this information for support purposes and to monitor the health of the site, identify problems, improve service, detect unauthorized access and fraudulent activity, prevent and respond to security incidents and appropriately scale computing resources.

Web Analytics

Pearson may use third party web trend analytical services, including Google Analytics, to collect visitor information, such as IP addresses, browser types, referring pages, pages visited and time spent on a particular site. While these analytical services collect and report information on an anonymous basis, they may use cookies to gather web trend information. The information gathered may enable Pearson (but not the third party web trend services) to link information with application and system log data. Pearson uses this information for system administration and to identify problems, improve service, detect unauthorized access and fraudulent activity, prevent and respond to security incidents, appropriately scale computing resources and otherwise support and deliver this site and its services.

Cookies and Related Technologies

This site uses cookies and similar technologies to personalize content, measure traffic patterns, control security, track use and access of information on this site, and provide interest-based messages and advertising. Users can manage and block the use of cookies through their browser. Disabling or blocking certain cookies may limit the functionality of this site.

Do Not Track

This site currently does not respond to Do Not Track signals.

Security


Pearson uses appropriate physical, administrative and technical security measures to protect personal information from unauthorized access, use and disclosure.

Children


This site is not directed to children under the age of 13.

Marketing


Pearson may send or direct marketing communications to users, provided that

  • Pearson will not use personal information collected or processed as a K-12 school service provider for the purpose of directed or targeted advertising.
  • Such marketing is consistent with applicable law and Pearson's legal obligations.
  • Pearson will not knowingly direct or send marketing communications to an individual who has expressed a preference not to receive marketing.
  • Where required by applicable law, express or implied consent to marketing exists and has not been withdrawn.

Pearson may provide personal information to a third party service provider on a restricted basis to provide marketing solely on behalf of Pearson or an affiliate or customer for whom Pearson is a service provider. Marketing preferences may be changed at any time.

Correcting/Updating Personal Information


If a user's personally identifiable information changes (such as your postal address or email address), we provide a way to correct or update that user's personal data provided to us. This can be done on the Account page. If a user no longer desires our service and desires to delete his or her account, please contact us at customer-service@informit.com and we will process the deletion of a user's account.

Choice/Opt-out


Users can always make an informed choice as to whether they should proceed with certain services offered by InformIT. If you choose to remove yourself from our mailing list(s) simply visit the following page and uncheck any communication you no longer want to receive: www.informit.com/u.aspx.

Sale of Personal Information


Pearson does not rent or sell personal information in exchange for any payment of money.

While Pearson does not sell personal information, as defined in Nevada law, Nevada residents may email a request for no sale of their personal information to NevadaDesignatedRequest@pearson.com.

Supplemental Privacy Statement for California Residents


California residents should read our Supplemental privacy statement for California residents in conjunction with this Privacy Notice. The Supplemental privacy statement for California residents explains Pearson's commitment to comply with California law and applies to personal information of California residents collected in connection with this site and the Services.

Sharing and Disclosure


Pearson may disclose personal information, as follows:

  • As required by law.
  • With the consent of the individual (or their parent, if the individual is a minor)
  • In response to a subpoena, court order or legal process, to the extent permitted or required by law
  • To protect the security and safety of individuals, data, assets and systems, consistent with applicable law
  • In connection the sale, joint venture or other transfer of some or all of its company or assets, subject to the provisions of this Privacy Notice
  • To investigate or address actual or suspected fraud or other illegal activities
  • To exercise its legal rights, including enforcement of the Terms of Use for this site or another contract
  • To affiliated Pearson companies and other companies and organizations who perform work for Pearson and are obligated to protect the privacy of personal information consistent with this Privacy Notice
  • To a school, organization, company or government agency, where Pearson collects or processes the personal information in a school setting or on behalf of such organization, company or government agency.

Links


This web site contains links to other sites. Please be aware that we are not responsible for the privacy practices of such other sites. We encourage our users to be aware when they leave our site and to read the privacy statements of each and every web site that collects Personal Information. This privacy statement applies solely to information collected by this web site.

Requests and Contact


Please contact us about this Privacy Notice or if you have any requests or questions relating to the privacy of your personal information.

Changes to this Privacy Notice


We may revise this Privacy Notice through an updated posting. We will identify the effective date of the revision in the posting. Often, updates are made to provide greater clarity or to comply with changes in regulatory requirements. If the updates involve material changes to the collection, protection, use or disclosure of Personal Information, Pearson will provide notice of the change through a conspicuous notice on this site or other appropriate way. Continued use of the site after the effective date of a posted revision evidences acceptance. Please contact us if you have questions or concerns about the Privacy Notice or any objection to any revisions.

Last Update: November 17, 2020