Step by Step Call flow analysis Through MGCP Gateways

MGCP is a master/slave protocol that allows a call-control device (such as Cisco UCM) to control and track the state of each voice port on the gateway, and there two things you need to know about MGCP Protocol.

• Master/slave protocol: routes calls in response to instructions from the call agent.
• MGCP is IEEE standard: RFC 2705 & RFC 3435 is an enhancement of MGCP that contains some new events and features.

In case of MGCP , the Dial plan administration is done within the call manager, so all call routing decisions are done based on Cisco UCM configuration.

ISDN Q931 backhaul

When Cisco Voice gateway receive call setup message from PSTN, Gateway will convert incoming TDM setup messages that contain Both Calling & Called Numbers to IP Packets and forward them to the Call manager as in our case Gateway doesn’t handle layer 3 messages, after that call manager will take the routing decisions and route the call to the appropriate destination.

Notes

• Gateways in the MGCP world are dump devices and not evolved in call routing decisions.
• Backhaul mean messages are tunneled through the Gateway to Cisco UCM.
• The domain name of MGCP GW on the CUCM configuration is case sensitive, so you need to make sure you typed it correctly.

Call Flow

• Gateway uses TCP Port 2428 to backhaul Q931 signaling messages to Cisco UCM for call routing decisions
• On the other hand, Gateway uses UDP Port 2427 to create what’s known as MGCP connection messages between Gateway and phone, which include SDP, RTP Ports, Codec negotiations, etc.

The first steps in Troubleshooting MGCP GW in our systematic approach will be checking E1/T1 Connections status, and this can be done using well-known command : show isdn status and the output should look like below

DE-DUS-ENT-CE1#show isdn status
Global ISDN Switchtype = primary-net5

%Q.931 is backhauled to CCM MANAGER 0x0003 on DSL 0. Layer 3 output may not apply

ISDN Serial0/0/0:15 interface
	dsl 0, interface ISDN Switchtype = primary-net5
	L2 Protocol = Q.921 0x0000  L3 Protocol(s) = CCM MANAGER 0x0003 
    Layer 1 Status:
	ACTIVE
    Layer 2 Status:
	TEI = 0, Ces = 1, SAPI = 0, State = MULTIPLE_FRAME_ESTABLISHED
    Layer 3 Status:
	0 Active Layer 3 Call(s)
    Active dsl 0 CCBs = 0
    The Free Channel Mask:  0xFFFF7FFF
    Number of L2 Discards = 2, L2 Session ID = 230
    Total Allocated ISDN CCBs = 0

from the output, we need to check two parameters which is the most important

• L3 Protocol(s) = CCM MANAGER 0x0003  ———> and this mean Q9321 messages we will receive is backhauled to CUCM
• State = MULTIPLE_FRAME_ESTABLISHED ———> indicates there is data link connectivity to the Telco ISDN switch. This is the state that you should see under normal operations. Any other state usually indicates a problem on the circuit

now we verified that GW is registered to CUCM and ISDN status is up and now can start receiving calls from PSTN

Tracing Incoming call

first will need to enable two commands to trace incoming/outgoing call

• debug mgcp packet
• debug isdn q931

The MGCP Gateway will send NTFY message every 15 sec (by default) as a keepalive. CUCM will acknowledge using 200 OK

DE-DUS-ENT-CE1#
Apr  9 12:59:44.566 GMT: MGCP Packet sent to 10.29.3.137:2427--->
NTFY 526602120 *@DE-DUS-ENT-CE1 MGCP 0.1
X: 0
O: 
<--- Apr 9 12:59:44.590 GMT: MGCP Packet received from 10.29.3.137:2427--->
200 526602120 
<---

Now I am gonna make a call “Inbound ” and will go through the messages one by one, and will start with the first message ‘call setup message’ from PSTN as shown below

Apr  9 12:53:44.972 GMT: ISDN Se0/0/0:15 Q931: RX <- SETUP pd = 8  callref = 0x569C 
	Sending Complete 
	Bearer Capability i = 0x9090A3 
		Standard = CCITT 
		Transfer Capability = 3.1kHz Audio 
		Transfer Mode = Circuit 
		Transfer Rate = 64 kbit/s 
	Channel ID i = 0xA98381 
		Exclusive, Channel 1 
	Progress Ind i = 0x8283 - Origination address is non-ISDN  
	Calling Party Number i = 0x1180, '420547123498' 
		Plan:ISDN, Type:International 
	Calling Party Number i = 0x1183, '420547123498' 
		Plan:ISDN, Type:International 
	Called Party Number i = 0x81, '215' 
		Plan:ISDN, Type:Unknown

now we received a call from PSTN Side, and if you noticed, the called Number is only 215, and this means the Provider is not sending the whole Number “DID Number”, PSTN just send the last 3 digits, and this message will be directed to CUCM to be routed to the proper extension

CUCM will send the first mgcp message here which is CReate Connection message “CRCX” to the GW, In this message the call-agent instructs the gateway to establish a connection with an endpoint, and in our case, connection supposed to taking place between GW and IP Phone, but now in this step, GW is setting up its side of the call and will be waiting for information from CUCM about the target phone in the upcoming messages

The parameters in the CReate Connection provide what is necessary to build an understanding of each connection. The parameters include the codec, packetization period, QoS marking, usage of echo cancellation, silence suppression

Apr  9 12:53:45.000 GMT: MGCP Packet received from 10.29.3.137:2427--->
CRCX 52481 S0/SU0/DS1-0/1@DE-DUS-ENT-CE1 MGCP 0.1
C: D000000003d943d4000000F58000569c
X: 1
L: p:20, a:PCMU, s:off, t:b8
M: recvonly
R: D/[0-9ABCD*#]
Q: process,loop
<--- 

[table id=6 /]

Till now Call manager informed the GW to send its connection parameter and the reply from GW supposed to be 200 ok with SDP
below you will see the first line for 200 ok message and GW will provide its IP address, Port Number and in our Example here GW sent its IP address: 10.22.66.185 and RTP Port Number 24488 and the Next step supposed to be informing IP Phone to send RTP Traffic to IP address and Port Number GW is using

Apr  9 12:53:45.008 GMT: MGCP Packet sent to 10.29.3.137:2427--->
200 52481 OK
I: F68

v=0
c=IN IP4 10.22.66.185
m=audio 24488 RTP/AVP 0 100
a=rtpmap:100 X-NSE/8000
a=fmtp:100 192-194
<---

[table id=7 /]

The next step now will be call proceeding Q931 message followed by Alerting message from CUCM Side toward PSTN as below

Apr  9 12:53:45.032 GMT: ISDN Se0/0/0:15 Q931: TX -> CALL_PROC pd = 8  callref = 0xD69C 
	Channel ID i = 0xA98381 
		Exclusive, Channel 1
Apr  9 12:53:45.032 GMT: ISDN Se0/0/0:15 Q931: TX -> ALERTING pd = 8  callref = 0xD69C 
	Progress Ind i = 0x8088 - In-band info or appropriate now available 

Now, since we can see Alerting message sent to PSTN, this means we are informing PSTN that we found the destination, Number is correct, it’s not busy and now it’s ringing please provide a ring back tone to the caller.

you will find also progress indicator 0x8088 In-band info or appropriate now available, to inform the PSTN that GW will provide ring back tone to the caller, and the next action will be CUCM task to inform GW to provide ringback tone to the caller

and this will be done using RQNT  (Request for Notification)  >> G/rt  ———> Generate Ringback tone

Apr  9 12:53:45.032 GMT: MGCP Packet received from 10.29.3.137:2427--->
RQNT 52482 S0/SU0/DS1-0/1@DE-DUS-ENT-CE1 MGCP 0.1
X: 1
R: D/[0-9ABCD*#]
S: G/rt
Q: process,loop
<---
Apr  9 12:53:45.036 GMT: MGCP Packet sent to 10.29.3.137:2427--->
200 52482 OK
<---

when the IP Phone answer the call, GW will send Connect message to the PSTN and will receive connect acknowledgment from PSTN Side

Apr  9 12:53:46.016 GMT: ISDN Se0/0/0:15 Q931: TX -> CONNECT pd = 8  callref = 0xD69C 
Apr  9 12:53:46.048 GMT: ISDN Se0/0/0:15 Q931: RX <- CONNECT_ACK pd = 8  callref = 0x569C

the IP Phone answer in this point of time, then CUCM will send a connect to the PSTN, and then we get connect acknowledgment coming back from the PSTN

we remember in create connection message, the GW was receiving only, as in that time GW was only setting up its side of the call, but when IP Phone answer, IP Phone will inform CUCM about RTP Port Number its using, now we can see modify connection message being sent to the GW, and in this MDCX message the critical part is adjusting this connection to send receive instead of receive only, as connection now need to be initiated between GW and IP Phone, so MDCX message will contain SDP to provide the information about IP Phone [RTP Port number + IP address] to let GW communicate with the phone and RTP Packets to flow from GW to the IP Phone

Apr  9 12:53:46.220 GMT: MGCP Packet received from 10.29.3.137:2427--->
MDCX 52483 S0/SU0/DS1-0/1@DE-DUS-ENT-CE1 MGCP 0.1
C: D000000003d943d4000000F58000569c
I: F68
X: 1
L: p:20, a:PCMU, s:off, t:b8
M: sendrecv
R: D/[0-9ABCD*#]
S: 
Q: process,loop

v=0
o=- 3944 0 IN EPN S0/SU0/DS1-0/1@DE-DUS-ENT-CE1
s=Cisco SDP 0
t=0 0
m=audio 28034 RTP/AVP 0
c=IN IP4 10.163.21.16
<---

below is 200 ok response from GW for previous Modify Connection message

Apr  9 12:53:46.220 GMT: MGCP Packet sent to 10.29.3.137:2427--->
200 52483 OK
<---

Now Connections is established between IP Phone and the GW and RTP packets are flowing End to End

Now, Calling Party hung up the call, and can see this in the below disconnect message that we got from PSTN,

Apr  9 12:54:00.237 GMT: ISDN Se0/0/0:15 Q931: RX <- DISCONNECT pd = 8  callref = 0x569C 
	Cause i = 0x8A90 - Normal call clearing 
	Progress Ind i = 0x8288 - In-band info or appropriate now available 

Now, Since the caller ended the call and as a result of that, CUCM will instruct GW to update its connection as the RTP connection is no longer there “as the Caller hung up” and we need to stop the GW from listening on Port Number that was used for that connection and stop sending RTP Traffic to IP Phone using Modify Connection message,

you will notice in the M line, now we revert back to recvonly mode again and this means, GW didn’t kill the call from its side yet “receive only mean GW still listening on port number we used in the set up during the connection ” and in that point, you might be wondering,
Why we didn’t send a Delete connection directly instead of two stages for terminating the call?

The answer is: because in some cases let’s say the User did not hang up, let’s say he pressed Hold or transfer or any other function, this means modifications might be required to the current session, maybe CUCM will direct the GW to connect to MOH Server for MOH Stream, etc.

and this is the case behind two stages for tearing down the call, first will be Modify Connection and GW will respond with 200 OK as below

Apr  9 12:54:00.265 GMT: MGCP Packet received from 10.29.3.137:2427--->
MDCX 52486 S0/SU0/DS1-0/1@DE-DUS-ENT-CE1 MGCP 0.1
C: D000000003d943d4000000F58000569c
I: F68
X: 1
M: recvonly
R: D/[0-9ABCD*#]
Q: process,loop
<--- Apr 9 12:54:00.265 GMT: MGCP Packet sent to 10.29.3.137:2427--->
200 52486 OK
<---

The last message from CUCM in our mgcp call will be DeLete Connection “DLCX”, and in this message, CUCM instructing GW to stop listening to RTP Port Number that was used during the connection to End the call and free the Bearer channel

Apr  9 12:54:00.293 GMT: MGCP Packet received from 10.29.3.137:2427--->
DLCX 52487 S0/SU0/DS1-0/1@DE-DUS-ENT-CE1 MGCP 0.1
C: D000000003d943d4000000F58000569c
I: F68
X: 1
S: 
<--- Apr 9 12:54:00.313 GMT: MGCP Packet sent to 10.29.3.137:2427--->
250 52487 OK
P: PS=702, OS=112320, PR=703, OR=112480, PL=0, JI=0, LA=0
<---

If you noticed in GW acknowledgment, GW did not send 200 ok as usual, instead, it’s sending 250 ok, and this because it contains additional information related to QoS.

[table id=8 /]

and this will be followed by a Release message to the PSTN Side and receiving acknowledgment coming back from the PSTN

Apr  9 12:54:00.337 GMT: ISDN Se0/0/0:15 Q931: TX -> RELEASE pd = 8  callref = 0xD69C
Apr  9 12:54:00.357 GMT: ISDN Se0/0/0:15 Q931: RX <- RELEASE_COMP pd = 8  callref = 0x569C