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
Figure 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 |
-
Call agent: instructs the RGW A to look for an off-hook event and report it. Sends a Notification Request to the RGW A.
-
RGW A: sends an acknowledgement message to the call agent.
-
RGW A: user A goes off-hook, the gateways detect the event and send a Notification to call agent.
-
Call agent: sends an acknowledgement message to the RGW A.
-
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.
-
RGW A: sends an acknowledgement message to the call agent.
-
RGW A: accumulates the dialed digits and sends a Notification to the call agent.
-
Call agent: sends an acknowledgement message to the RGW A.
-
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.
-
RGW A: sends an acknowledgement message to the call agent.
-
Call agent: seizes the incoming circuit. It sends a Create Connection message to the RGW A.
-
RGW A: sends an acknowledgement message to the call agent along with the session description used to receive audio data.
-
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.
-
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.
-
RGW B: sends an acknowledgement message to the call agent along with the session description used to receive audio data.
-
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.
-
RGW A: sends an acknowledgement message to the call agent.
-
Call agent: instructs the RGW B to generate ringing tones by sending a Notification Request.
-
RGW B: sends an acknowledgement message to the call agent.
-
Call agent: notifies A that B is ringing.
-
RGW A: sends an acknowledgement message to the call agent.
-
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.
-
Call agent: sends an acknowledgement message to the call agent.
-
Call agent: sends a Notification Request to the RGW A to stop ringing.
-
RGW A: sends an acknowledgement message to the call agent.
-
Call agent: sends a Modify Connection message to the RGW A to change the communication mode from half duplex to full duplex.
-
RGW A: sends an acknowledgement message to the call agent. The call is now taking place.
-
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.
-
Call agent: sends an acknowledgement message to the call agent.
-
Call agent: sends a Delete Connection message to the RGW A. No ACK is necessary from the GW.
-
Call agent: sends a Delete Connection message to the RGW B. No ACK is necessary from the GW.
-
Call agent: issues a new Notification Request to the RGW A asking it to be ready for the next off-hook event.
-
RGW A: sends an acknowledgement message to the call agent.
-
Call agent: issues a new Notification Request to the RGW B asking it to be ready for the next off-hook event.
-
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
Figure 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.
Figure 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 |
-
CO: issues an initial address message (IAM) to the call agent through its STP.
-
SS7: the Signaling Transfer Point (STP) routes the ISUP message to the signaling gateway attached to the call agent.
-
Call agent: queries a database to find out the IP address of the residential gateway serving the destination number.
-
Call agent: sends a Create Connection message to the trunking gateway to connect to the incoming trunk (uses the circuit identification code (CIC)).
-
TGW: sends an acknowledgement message to the call agent.
-
Call agent: seizes the incoming trunk and reserves the outgoing trunk circuit by sending a Create Connection message to the residential gateway.
-
RGW: sends an acknowledgement message to the call agent.
-
Call agent: will now indicate this information to the TGW by sending a Modify Connection to the TGW.
-
TGW: sends an acknowledgement message to the call agent.
-
Call agent: requests the residential gateway to ring the called line by sending a Notification Request message to the RGW.
-
RGW: sends an acknowledgement message to the call agent.
-
Call Agent: when the call agent receives the ACK from the RGW, it issues Address Complete message to the signaling gateway.
-
SS7: the STP conveys this information back to the CO.
-
User: terminal goes off-hook.
-
RGW: detects this event and notifies the call agent by sending a Notification message.
-
Call agent: sends an acknowledgement message to the call agent.
-
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.
-
RGW: sends an acknowledgement message to the call agent.
-
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.
-
TGW: sends an acknowledgement message to the call agent.
-
Call agent: can now send an answer message to the signaling gateway.
-
SS7: the STP sends this information to the CO.
-
Both parties are talking.
-
RGW: the user B’s terminal goes on-hook.
-
The RGW sends a Notification message to the call agent.
-
Call agent: sends an acknowledgement message to the call agent.
-
Call agent: sends a Delete Connection message to the RGW.
-
Call agent: sends a Delete Connection message to the TGW.
-
Call agent: issues a RELEASE message to the signaling gateway.
-
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
Figure 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.
Figure 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 |
-
The trunking gateway registers with the GK.
-
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.
-
The same exchange occurs for the residential gateway.
-
Idem.
-
The initial address message is sent by the ingress CO to the GK through the SS7 signaling gateway.
-
On receipt of this message the GK looks up its database in order to decide where to route the incoming call.
-
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.
-
Once the TCP connection is established, the GK issues the Setup message using the fastStart procedure as described in the specification.
-
The GK goes through the same exchange of messages with the residential gateway.
-
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.
-
The user’s phone rings and the residential gateway sends the Alerting message to the GK.
-
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.