Cart
One of the topics that we will focus on in great detail in the upcoming CCIE Voice Troubleshooting class is MGCP call setup and teardown. The information below is a capture from a trace (using deb mgcp packet and deb isdn q931) taken from an IOS MGCP gateway with the endpoint being a T1 PRI. The trace begins when an incoming call from the PSTN arrives and the destination is an IP phone that is registered to the UCM. Comments are provided above and within each message. Enjoy!
Q931 SETUP
Q931 SETUP message arrives. The destination is 2025552002. The bearer channel is channel #1 . The D channel which is used for signaling is the last channel (Serial 0/0/0:23). The SETUP message will be packetized by the gateway and sent to the “mgcp call agent” (the first choice Unified Communications Manager). This is process of taking the ISDN messages arriving on the PRI and packetizing them and sending them to the UCM is known as Q931 backhaul. The UCM listens on TCP port 2428- the gateway uses an ephemeral port that is dynamically selected.
May 30 13:04:07.404: ISDN Se0/0/0:23 Q931: RX <- SETUP pd = 8 callref = 0x0084 Bearer Capability i = 0x8090A2 Standard = CCITT Transfer Capability = Speech Transfer Mode = Circuit Transfer Rate = 64 kbit/s Channel ID i = 0xA98381 Exclusive, Channel 1 Progress Ind i = 0x8583 - Origination address is non-ISDN Calling Party Number i = 0x0080, N/A Plan:Unknown, Type:Unknown Called Party Number i = 0xA1, '2025552002' Plan:ISDN, Type:National
CRCX
The MGCP messaging sequence now begins. As a reminder the UCM will be listening on UDP port 2427. The Q931 SETUP would have been received by the UCM. The UCM is then able to route the call to the destination (the incoming CSS and incoming significant digits settings on the gateway configuration within UCM is used to route the call to the next hop which is the phone). The UCM will use SIP or SCCP for call setup on the line/phone side but in this instance we are interested in the MGCP call setup. So the first message is Create Connection (CRCX). The UCM is telling the gateway to provide the ip address and port number that will be used for this call. The UCM is the master and the gateway is the slave and so the UCM also provides a lot of other information to the gateway namely:
(1) C (CallId): globally unique conference id
(2) X (RequestIdentifier): random hexadecimal string generated- all responses to this create connection will contain X=1 within the message.
(3) L (LocalConnectionOptions): information about the call that will be setup- codec = 711u, sampling rate 20ms, s= off (vad), TOS = b8 = DSCP 46
(4) M (ConnectionMode): recvonly. UCM is not providing gateway information about the other party involved in the call just yet. This is because the phone has not answered yet so the UCM does not have that information. So the gateway will not be sending any packets at this stage.
(5) R (RequestedEvents): The D means invoke the “DTMF package” if the gateway receives 0-9, ACBD*#.
May 30 13:04:07.404: MGCP Packet received from 10.10.210.11:2427--->
CRCX 610 S0/SU0/DS1-0/1@SiteA-RTR MGCP 0.1 <<< 610 is the transaction number. Each message
<<< needs a response with this transaction id.
C: D000000002cd8630000000F580000084
X: 1
L: p:20, a:PCMU, s:off, t:b8, fxr/fx:t38
M: recvonly
R: D/[0-9ABCD*#]
Q: process,loop
<---
The gateway sends a 200 OK confirmation to the UCM providing the requested information that was in the CRCX. The gateway also provides the UCM a local call identifier (I: ConnectionID). In this instance the local call ID of I= 57 should be used when referencing this call. The “57″ is randomly generated and only has significance locally for the duration of this call. The information about codec’s and RTP port numbers cannot be carried in the 200 OK and therefore we have Session Description Protocol (SDP) information within the 200 OK. One of the most important lines within SDP is the “m=” line which is used to reveal the information about media. The RTP media types being used by the gateway are “0″ which is G711ulaw and 100 which is Named Signaling Events (NSE) used for fax and modem communications.
May 30 13:04:07.404: MGCP Packet sent to 10.10.210.11:2427--->
200 610 OK <<< 200 OK response. This the response to the request which had transaction id 610
I: 57 <<< Local call ID
v=0
o=- 87 0 IN IP4 10.10.110.1
s=Cisco SDP 0 <<< Beginning of SDP
c=IN IP4 10.10.110.1 <<< mgcp bind media source lo0
t=0 0
m=audio 16910 RTP/AVP 0 100 <<< RTP port number 16910, 0 is g711u, 100 is NSE
a=rtpmap:100 X-NSE/8000
a=fmtp:100 200-202 <<< fmtp= format specific params for rtp payload 100.
<<< 200, 201, 202 are Cisco NSE events related to T38 fax
a=X-sqn:0
a=X-cap: 1 audio RTP/AVP 100
a=X-cpar: a=rtpmap:100 X-NSE/8000
a=X-cpar: a=fmtp:100 200-202
a=X-cap: 2 image udptl t38
<---
Alerting, Ringback, RQNT
Below we have the Q931 Call Proceeding and Alerting being sent out to the PSTN- this is being received from the UCM on the Q931 backhaul link and converted to circuit switched signaling by the gateway DSPs and sent out to the PSTN. The Alerting means that the destination phone is ringing and hence ringback should be given to the caller. Who provides the ringback? The ringback is known as in-band information is played by our gateway to the PSTN. We inform the PSTN that we are playing ringback since the Progress Indicator is “8″ and this means “in-band” information is present.
May 30 13:04:07.408: ISDN Se0/0/0:23 Q931: TX -> CALL_PROC pd = 8 callref = 0x8084 Channel ID i = 0xA98381 Exclusive, Channel 1 May 30 13:04:07.408: ISDN Se0/0/0:23 Q931: TX -> ALERTING pd = 8 callref = 0x8084 Progress Ind i = 0x8088 - In-band info or appropriate now available
The PSTN now knows that we are going to play a tone/annoucement. Now we need to play it! The UCM tells the gw to play a ringback tone to the PSTN using the Notification Request message.
May 30 13:04:07.408: MGCP Packet received from 10.10.210.11:2427---> RQNT 611 S0/SU0/DS1-0/1@SiteA-RTR MGCP 0.1 X: 1 R: D/[0-9ABCD*#] S: G/rt <<<<<< S: signal request, G- generic media package, rt= ringback tone Q: process,loop <---
We confirm this to the UCM
May 30 13:04:07.416: MGCP Packet sent to 10.10.210.11:2427---> 200 611 OK <---
CONNECT, MDCX
The next message is the ISDN CONNECT message which means that the Called Party (IP Phone) has answered.
May 30 13:04:13.408: ISDN Se0/0/0:23 Q931: TX -> CONNECT pd = 8 callref = 0x8084 Display i = 'SiteA phone 2' May 30 13:04:13.420: ISDN Se0/0/0:23 Q931: RX <- CONNECT_ACK pd = 8 callref = 0x0084
At this stage the gateway needs to know about where to send RTP packets to. UCM tells the MGCP gw information about who to send RTP packets to using the Modify Connection (MDCX) message. We have to include SDP information in order to do this.
May 30 13:04:13.676: MGCP Packet received from 10.10.210.11:2427---> MDCX 613 S0/SU0/DS1-0/1@SiteA-RTR MGCP 0.1 C: D000000002cd8630000000F580000084 <<< same CallID as CRCX I: 57 <<< same local CallId as earlier X: 1 <<< same request identifier as earlier L: p:20, a:PCMU, s:off, t:b8, fxr/fx:t38 M: sendrecv <<< previously was recvonly- now two way audio. R: D/[0-9ABCD*#], FXR/t38 S: Q: process,loop v=0 o=- 87 0 IN EPN S0/SU0/DS1-0/1@SiteA-RTR s=Cisco SDP 0 <<< SDP header t=0 0 m=audio 22876 RTP/AVP 0 <<< IP Phone is listening on port 22876 using rtp payload "0" which is g711u c=IN IP4 10.10.200.128 <<< IP Phone IP address a=X-sqn:0 a=X-cap:1 image udptl t38 <---
The MDCX is ack’d by the UCM below.
May 30 13:04:13.692: MGCP Packet sent to 10.10.210.11:2427---> 200 613 OK <---
At this stage we have an active call. Let’s look at the process of call teardown.
Call Teardown- MDCX
We see the MDCX being used to revert to “recvonly” meaning stop sending packets to the IP phone.
May 30 13:04:18.616: MGCP Packet received from 10.10.210.11:2427---> MDCX 614 S0/SU0/DS1-0/1@SiteA-RTR MGCP 0.1 C: D000000002cd8630000000F580000084 <<< same CallID I: 57 <<< same local CallID X: 1 <<< same requestID M: recvonly <<< stop sending packets to IP Phone R: D/[0-9ABCD*#] <<< keep telling UCM about DTMF received from PSTN Q: process,loop <---
We send confirmation to the UCM.
May 30 13:04:18.620: MGCP Packet sent to 10.10.210.11:2427---> 200 614 OK <---
Q931 DISCONNECT
In this instance the IP Phone hangs up the call and we will see the DISCONNECT sent out to the PSTN. If the PSTN hung up the call we would see the DISCONNECT arrive from the PSTN.
May 30 13:04:18.624: ISDN Se0/0/0:23 Q931: TX -> DISCONNECT pd = 8 callref = 0x0002 Cause i = 0x8290 - Normal call clearing May 30 13:04:18.636: ISDN Se0/0/0:23 Q931: RX <- RELEASE pd = 8 callref = 0x0084 May 30 13:04:18.636:ISDN Se0/0/0:23 Q931: TX -> RELEASE_COMP pd = 8 callref = 0x0002
DLCX
The UCM instructs the gateway to stop listening on the RTP port number setup in the CRCX phase earlier. This is done with the Delete Connection (DLCX) message.
May 30 13:04:18.640: MGCP Packet received from 10.10.210.11:2427---> DLCX 615 S0/SU0/DS1-0/1@SiteA-RTR MGCP 0.1 C: D000000002cd8630000000F580000084 <<< same CallID I: 57 <<< same local CallID X: 1 <<< same requestID S: <---
The gateway confirms the DLCX and includes Connection Parameters (“P”) or QoS stats regarding the call. PS=packets sent, OS=octets sent, PR=packets received, OR=octets received, PL=packets lost, JI= jitter, LA=latency
May 30 13:04:18.664: MGCP Packet sent to 10.10.210.11:2427---> 250 615 OK P: PS=247, OS=39520, PR=245, OR=39200, PL=1, JI=0, LA=0 <<<< <---
That will do for MGCP call setup. We will be covering these topics and many more in the CCIE Voice Troubleshooting class on October 8-12 but I will be putting a few more of these articles shortly.
Vik Malhi CCIE # 13890
Facebook: http://www.facebook.com/VikMalhi
Twitter: @vikmalhi
Vik,
The DLCX isn’t the one the call teardown setup??? and regarding alerting,ringback & RQNT, I am under impression that S:G/rt is the one indicates the cisco phone is ringing, but apparently from this blog, it is very clear that alerting is the one indicating that phone is ringing not the S:G/rt…
This is really helpful and fundamentally very strong…
thank you
krishna.
The DLCX completes call teardown. This message is used by CM to inform the gateway to stop listening for RTP packets for this particular call. The MDCX prior to the DLCX is the beginning of call teardown in the sense that the MDCX is used by CM to inform the gateway to stop sending RTP packets to the phone/endpoint.
The ALERTING is used to tell the PSTN that the destination phone is ringing. The ALERTING contains a progress indicator (PI=8) to state that there is “in band information” which is a tone or announcement. This ALERTING is not an MGCP message though- this is Q931 signaling. The PSTN now knows there is “in band information” so is expecting a something! So the CM sends a RQNT with S:G/rt which in effect instructs the gateway to play the ringback to the PSTN.
Vik,
Soon after seeing this blog I tested and verified the same, but its not same output in the debug when I called PSTN number from Cisco phone. I don’t see S:G/rt, and so in this case where is the indication that pstn phone is ringing?? In debug isdn q931 i see the alerting trace but this indicates the cisco phone is ringing or pstn number is ringing?? if alerting indicates that pstn number is ringing, then what would the trace that indicates ringback to Cisco IP phone..
Thank you
Krishna.
Krishna
When you ring the PSTN from the IP phone then the PSTN phone does not hear ringback. The PSTN phone is ringing in this case and the IP phone is hearing ringback (done using SCCP).
Only when the PSTN rings the IP phone does the gateway get the instruction to play ringback.
Vik,
IP phone is hearing ringback (done using SCCP).. Isn’t it the CUCM instructing the IP phone to hear ringback?? If yes, my question what trace/output in deb mgcp packet or deb isdn q931 instructing CUCM to provide ringback to CUCM… I was wondering the ringback to IP phone is provided by deb isdn q931 trace which indicates alerting.. please correct me if I am wrong…
Thank you
Krishna.
correction in the second line…
deb isdn q931 instructing CUCM to provide ringback to IP phone…
Vik,
I found the answer for my question…I see the difference in the trace where it shows the debug as: when called from IP phone.
ISDN Se0/0/0:23 Q931: TX Alerting…
Thank you
Krishna.