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
<---
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
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 <---
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
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 <---
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 <---
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: <---
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 <<<< <---
No comments:
Post a Comment