Tuesday, 23 February 2016

CUBE URI Dialing


New features has been introduced in CUBE to support URI dialing

Enable URI Call Routing

By default CUBE will lookup the user field in the Request-URI of the INVITE message which should be made of digits. To support URI dialing, you need to enable domain-lookup call routing in the CUBE.

Domain lookup should be enabled globally or on the incoming dial-peer. Domain lookup isn't required on the outgoing dial-peer

voice service voip
 sip
  call-route url

or

dial-peer voice x voip
 voice-class sip call-route url

Inbound Dial-Peers

Inbound dial-peers can match based on SIP URI of the incoming INVITE message. The matching order is:

  1. Top Most VIA header in INVITE message
  2. Request-URI header in INVITE message
  3. TO header in INVITE message
  4. FROM header in INVITE message
  5. Called Number (incoming called-number)
  6. Calling Number (answer-address)
  7. Calling Number (destination-pattern)
  8. Dialpeer 0

voice class uri voice-class-uri-tag sip|tel
Specify a URI field for the voice class:
    host hostname-pattern
    host ipv4:ipv4-address
    host ipv6:ipv6-address
    host dns:dns-address
    pattern uri-pattern
    user-id username-pattern
!
dial-peer voice tag voip
 session protocol sipv2
 incoming uri { from | request | to | via} voice-class-uri-tag

You need to apply the command 'session protocol sipv2' in order to configure URI matching. Without this command, URI matching commands won't be listed

In a scenario where multiple SIP hops are involved in a call, there would be multiple via headers involved, and the topmost via header of an incoming SIP invite represents the last hop that forwarded the SIP request, and the bottom-most via header would represent the originator of the SIP request. Match based on VIA header of incoming INVITE message will match the last hop that forwarded the request (neighboring SIP entity), which is the topmost via header. Other VIA headers are ignored

INVITE sip:123@1.2.3.4:5060 SIP/2.0
Via: SIP/2.0/TCP 10.10.10.1:5093;branch=z9hG4bK-17716-1-0
Via: SIP/2.0/TCP 10.10.14.20:5093;branch=z9hG4bK-28280-1-0

Outgoing Dial Peer

Similarly, outbound dial-peers can match URIs of incoming INVITE message ordered as follow:

  1. URI of an incoming INVITE message & Carrier-ID Target
  2. Called Number & Carrier-ID Target
  3. URI of an incoming INVITE message
  4. Called Number

voice  class uri 2001 sip
host ipv4:10.2.1.1
!
dial-peer voice  1 VoIP
destination  uri 2001
carrier-id target orange
!
dial-peer voice  2 VoIP
destination-pattern 654321
carrier-id target orange
!
dial-peer voice  3 VoIP
destination uri 2001
!
dial-peer voice  4 voip
destination-pattern  654321

INVITE sip:654321@10.2.1.1 SIP/2.0
Via: SIP/2.0/UDP 10.1.1.1:5060;x-route-tag="cid:orange@10.1.1.1";branch=z9hG4bK-23955-1-0
From: "555" ;tag=1

Configuration Example

voice class uri InboundMatch sip
 pattern hquser*
!
voice class uri outgoingURI sip
 host dns:hqcluster.local
!
dial-peer voice 1913 voip
 session protocol sipv2
 session target ipv4:10.45.230.10
 incoming uri request InboundMatch
 voice-class sip call-route url
!
dial-peer voice 1912 voip
 session protocol sipv2
 session target ipv4:10.170.10.200
 destination uri outgoingURI

*********************************************************************

Received:
INVITE sip:hquser1@hqcluster.local SIP/2.0
Via: SIP/2.0/TCP 10.45.230.10:5060;branch=z9hG4bK2379042ad5
From: "SBUSER1-CALLER" ;tag=28~8901f810-e3b7-43de-b8ef-31fe13e397a7-18206035
To:
Date: Mon, 22 Feb 2016 10:35:46 GMT
Call-ID: 6cfb280-6ca1e482-1a-ae62d0a@10.45.230.10
Supported: timer,resource-priority,replaces
Min-SE:  1800
User-Agent: Cisco-CUCM9.1
Allow: INVITE, OPTIONS, INFO, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, SUBSCRIBE, NOTIFY
CSeq: 101 INVITE
Expires: 180
Allow-Events: presence, kpml
Supported: X-cisco-srtp-fallback,X-cisco-original-called
Call-Info: ;method="NOTIFY;Event=telephone-event;Duration=500"
Cisco-Guid: 0114274944-0000065536-0000000026-0182856970
Session-Expires:  1800
P-Asserted-Identity: "SBUSER1-CALLER"
Remote-Party-ID: "SBUSER1-CALLER" ;party=calling;screen=yes;privacy=off
Contact:
Max-Forwards: 70
Content-Length: 0

Request URI Pass-Through

By default CUBE will replace the host portion in Req-URI & TO headers of INVITE message with the configured session target as follow:

dial-peer voice 1913 voip
 session protocol sipv2
 session target ipv4:10.45.230.10
 incoming uri request InboundMatch
 voice-class sip call-route url
!
dial-peer voice 1912 voip
 session protocol sipv2
 session target ipv4:10.170.10.200
 destination uri outgoingURI

----->
Received:
INVITE sip:hquser1@hqcluster.local SIP/2.0
Via: SIP/2.0/TCP 10.45.230.10:5060;branch=z9hG4bK2379042ad5
From: "SBUSER1-CALLER" ;tag=28~8901f810-e3b7-43de-b8ef-31fe13e397a7-18206035
To: <sip:hquser1@hqcluster.local>
Date: Mon, 22 Feb 2016 10:35:46 GMT
Call-ID: 6cfb280-6ca1e482-1a-ae62d0a@10.45.230.10
Supported: timer,resource-priority,replaces
Min-SE:  1800
User-Agent: Cisco-CUCM9.1
Allow: INVITE, OPTIONS, INFO, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, SUBSCRIBE, NOTIFY
CSeq: 101 INVITE
Expires: 180
Allow-Events: presence, kpml
Supported: X-cisco-srtp-fallback,X-cisco-original-called
Call-Info: ;method="NOTIFY;Event=telephone-event;Duration=500"
Cisco-Guid: 0114274944-0000065536-0000000026-0182856970
Session-Expires:  1800
P-Asserted-Identity: "SBUSER1-CALLER"
Remote-Party-ID: "SBUSER1-CALLER" ;party=calling;screen=yes;privacy=off
Contact:
Max-Forwards: 70
Content-Length: 0

<----- span="">
Sent:
INVITE sip:hquser1@10.170.10.200:5060 SIP/2.0
Via: SIP/2.0/UDP 10.170.170.2:5060;branch=z9hG4bK44CE2352
Remote-Party-ID: "SBUSER1-CALLER" ;party=calling;screen=yes;privacy=off
From: "SBUSER1-CALLER" ;tag=970E872C-1947
To: <sip:hquser1@10.170.10.200>
Date: Mon, 22 Feb 2016 15:18:36 GMT
Call-ID: 61038AB0-D8AE11E5-AF45D397-811E4C2B@10.170.170.2
Supported: timer,resource-priority,replaces,sdp-anat
Min-SE:  1800
Cisco-Guid: 2310550400-0000065536-0000000046-0182856970
User-Agent: Cisco-SIPGateway/IOS-15.4.3.M3
Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, SUBSCRIBE, NOTIFY, INFO, REGISTER
CSeq: 101 INVITE
Timestamp: 1456154316
Contact:
Expires: 180
Allow-Events: telephone-event
Max-Forwards: 69
Session-Expires:  1800
Content-Length: 0

In URI dialing this isn't a desirable behavior as the preference is to maintain the domain-name for the destination system to be able to perform domain-lookup. Typical example when routing calls from CUCM to Lync or vice-versa.

You can pass-through Req-URI and TO headers using the command 'voice-class sip requri-passing' which needs to be applied globally or on the outgoing dial-peer

Note: Remote-Party-ID, From and Contact headers will be modified to reflect the session target in the host portion

dial-peer voice 1913 voip
 session protocol sipv2
 session target ipv4:10.45.230.10
 incoming uri request InboundMatch
 voice-class sip call-route url
!
dial-peer voice 1912 voip
 session protocol sipv2
 session target ipv4:10.170.10.200
 destination uri outgoingURI
 voice-class sip requri-passing

The debugs will look as follow:

----->
Received:
INVITE sip:hquser1@hqcluster.local SIP/2.0
Via: SIP/2.0/TCP 10.45.230.10:5060;branch=z9hG4bK2379042ad5
From: "SBUSER1-CALLER" ;tag=28~8901f810-e3b7-43de-b8ef-31fe13e397a7-18206035
To: <sip:hquser1@hqcluster.local>
Date: Mon, 22 Feb 2016 10:35:46 GMT
Call-ID: 6cfb280-6ca1e482-1a-ae62d0a@10.45.230.10
Supported: timer,resource-priority,replaces
Min-SE:  1800
User-Agent: Cisco-CUCM9.1
Allow: INVITE, OPTIONS, INFO, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, SUBSCRIBE, NOTIFY
CSeq: 101 INVITE
Expires: 180
Allow-Events: presence, kpml
Supported: X-cisco-srtp-fallback,X-cisco-original-called
Call-Info: ;method="NOTIFY;Event=telephone-event;Duration=500"
Cisco-Guid: 0114274944-0000065536-0000000026-0182856970
Session-Expires:  1800
P-Asserted-Identity: "SBUSER1-CALLER"
Remote-Party-ID: "SBUSER1-CALLER" ;party=calling;screen=yes;privacy=off
Contact:
Max-Forwards: 70
Content-Length: 0

<----- span="">
Sent:
INVITE sip:hquser1@hqcluster.local SIP/2.0
Via: SIP/2.0/UDP 10.170.170.2:5060;branch=z9hG4bK44CF3C
Remote-Party-ID: "SBUSER1-CALLER" ;party=calling;screen=yes;privacy=off
From: "SBUSER1-CALLER" ;tag=971004A4-14C8
To: <sip:hquser1@hqcluster.local>
Date: Mon, 22 Feb 2016 15:20:14 GMT
Call-ID: 9B388AED-D8AE11E5-AF4BD397-811E4C2B@10.170.170.2
Supported: timer,resource-priority,replaces,sdp-anat
Min-SE:  1800
Cisco-Guid: 3290550400-0000065536-0000000047-0182856970
User-Agent: Cisco-SIPGateway/IOS-15.4.3.M3
Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, SUBSCRIBE, NOTIFY, INFO, REGISTER
CSeq: 101 INVITE
Timestamp: 1456154414
Contact:
Expires: 180
Allow-Events: telephone-event
Max-Forwards: 69
Session-Expires:  1800
Content-Length: 0

302 Contact Header Pass-Through

Similar to Req-URI, you can pass-through contact header only in outgoing 302 messages. This is important in call forward scenarios in order to maintain host portion of contact header instead of replacing it with session target

voice service voip
 sip
 contact-passing

or

dial-peer voice tag voip
 session protocol sipv2
 voice-class sip contact-passing

Remote-Party-ID Normalization

The next step is to fix the caller-ID display. Incoming INVITE  in below debug contains caller ID, caller URI and caller DN which is basically blended addressing.

Received:
INVITE sip:hquser1@hqcluster.local SIP/2.0
Via: SIP/2.0/TCP 10.45.230.10:5060;branch=z9hG4bK2379042ad5
From: "SBUSER1-CALLER" ;tag=28~8901f810-e3b7-43de-b8ef-31fe13e397a7-18206035
To:
Date: Mon, 22 Feb 2016 10:35:46 GMT
Call-ID: 6cfb280-6ca1e482-1a-ae62d0a@10.45.230.10
Supported: timer,resource-priority,replaces
Min-SE:  1800
User-Agent: Cisco-CUCM9.1
Allow: INVITE, OPTIONS, INFO, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, SUBSCRIBE, NOTIFY
CSeq: 101 INVITE
Expires: 180
Allow-Events: presence, kpml
Supported: X-cisco-srtp-fallback,X-cisco-original-called
Call-Info: ;method="NOTIFY;Event=telephone-event;Duration=500"
Cisco-Guid: 0114274944-0000065536-0000000026-0182856970
Session-Expires:  1800
P-Asserted-Identity: "SBUSER1-CALLER"
Remote-Party-ID: "SBUSER1-CALLER" ;party=calling;screen=yes;privacy=off
Contact:
Max-Forwards: 70
Content-Length: 0

CUBE will override Remote-Party-ID header to reflect the session target in the host portion. Also, it will strip x-cisco-number as it is unsupported header. At the receiving endpoint, the caller number won't be displayed and the caller URI will be wrongly displayed.

Sent:
INVITE sip:hquser1@hqcluster.local SIP/2.0
Via: SIP/2.0/UDP 10.170.170.2:5060;branch=z9hG4bK44CF3C
Remote-Party-ID: "SBUSER1-CALLER" ;party=calling;screen=yes;privacy=off
From: "SBUSER1-CALLER" ;tag=971004A4-14C8
To:
Date: Mon, 22 Feb 2016 15:20:14 GMT
Call-ID: 9B388AED-D8AE11E5-AF4BD397-811E4C2B@10.170.170.2
Supported: timer,resource-priority,replaces,sdp-anat
Min-SE:  1800
Cisco-Guid: 3290550400-0000065536-0000000047-0182856970
User-Agent: Cisco-SIPGateway/IOS-15.4.3.M3
Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, SUBSCRIBE, NOTIFY, INFO, REGISTER
CSeq: 101 INVITE
Timestamp: 1456154414
Contact:
Expires: 180
Allow-Events: telephone-event
Max-Forwards: 69
Session-Expires:  1800
Content-Length: 0

This can be fixed by applying normalization.

  1. Copy Remote-Party-ID header from incoming INVITE message to u01 variable
  2. Paste Remote-Party-ID header to outgoing INVITE message from u01 variable

!!! … Define which headers are allowed to be copied from incoming SIP message
voice class sip-copylist 1
 sip-header Remote-Party-ID

!!! … Create normalization rule to modify the required header. First copy the peer-header (which is incoming header) to variable then paste it as outgoing header
voice class sip-profiles 10
 request INVITE peer-header sip Remote-Party-ID copy "(.*)" u01
 request INVITE sip-header Remote-Party-ID modify "(.*)" "Remote-Party-ID: \u01"

!!! … Assign the copy-list to inbound dial-peer
dial-peer voice 1913 voip
 session protocol sipv2
 session target ipv4:10.45.230.10
 incoming uri request InboundMatch
 voice-class sip call-route url
 voice-class sip copy-list 1

!!! … Assign the normalization rule to outgoing dial-peer
dial-peer voice 1912 voip
 session protocol sipv2
 session target ipv4:10.170.10.200
 destination uri outgoingURI
 voice-class sip profiles 10
 voice-class sip requri-passing

Sent:
INVITE sip:hquser1@hqcluster.local SIP/2.0
Via: SIP/2.0/UDP 10.170.170.2:5060;branch=z9hG4bK47AF844
Remote-Party-ID: "SBUSER1-CALLER" ;party=calling;screen=yes;privacy=off
From: "SBUSER1-CALLER" ;tag=9CF9483C-13B4
To:
Date: Tue, 23 Feb 2016 18:53:06 GMT
Call-ID: 82872A36-D99511E5-BF28D397-811E4C2B@10.170.170.2
Supported: timer,resource-priority,replaces,sdp-anat
Min-SE:  1800
Cisco-Guid: 2873105024-0000065536-0000000111-0182856970
User-Agent: Cisco-SIPGateway/IOS-15.4.3.M3
Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, SUBSCRIBE, NOTIFY, INFO, REGISTER
CSeq: 101 INVITE
Timestamp: 1456253586
Contact:
Expires: 180
Allow-Events: telephone-event
Max-Forwards: 69
Session-Expires:  1800
Content-Length: 0

Derive Session Target from SIP-URI

CUBE can use the host portion of Req-URI header in incoming INVITE message to findout the session target. If the host portion is an IP address, CUBE will directly signal the IP. However, in URI Dialing the host portion usually is a domain-name. Hence, CUBE will resolve the domain name and signal the result IP.

dial-peer voice 1912 voip
 session protocol sipv2
 session target sip-uri
 destination uri outgoingURI
 voice-class sip profiles 10
 voice-class sip requri-passing

Wednesday, 3 February 2016

MGCP Switchover


  • MGCP GW sends keepalives to primary CUCM every 15 sec using empty NTFY message
  • CUCM acknowledges the message using 200OK
  • If no-response is received within 30 sec, MGCP will consider CUCM dead and will try to switchover to next CUCM.
  • In case secondary isn’t available, the gateway can fall back to using the default H.323 session application, if it is configured.

Note: The difference between switchover and fallback. Switchover between CUCM servers while fallback will take place when all CUCM servers aren't responding.

  • If the Primary CUCM fails:
    • D-channel will remain up since Q921 messages terminate on the gateway
    • Backhaul will go down since Q931 messages terminate on CUCM
  • During CUCM Switchover, calls will be treated as follow:
    • Active calls will be preserved because D-Channel is up
    • New calls will be rejected because backhaul is to CUCM is down
    • Calls in Transition state will be cleared
  • The messaging will be as follow:

  • After NTFY messages being sent for 30 seconds without response, MGCP Gateway will send RSIP Graceful message to Primary Failed CUCM (without a response from CUCM)

Jan 27 21:49:11 MST: MGCP Packet sent to 10.170.4.11:2427--->
RSIP 329754022 *@kl2951-router.shelfdrilling.com MGCP 0.1
RM: graceful
<--- p="">

  • MGCP Gateway will send RSIP Restart message to Secondary CUCM

Jan 27 21:49:11 MST: MGCP Packet sent to 10.170.4.10:2427--->
RSIP 329754024 *@kl2951-router.shelfdrilling.com MGCP 0.1
RM: restart
<--- p="">

  • Secondary CUCM will respond with 200OK Acknowledgement confirming that it is alive

Jan 27 21:49:11 MST: MGCP Packet received from 10.170.4.10:2427--->
200 329754024
<--- p="">

  • Secondary CUCM will send AUEP messages for each Voice Port or PRI Channel requesting X (RequestIdentifer), I (ConnectionId), A (Capabilities)

Jan 27 21:49:11 MST: MGCP Packet received from 10.170.4.10:2427--->
AUEP 760 S0/SU0/DS1-0/1@kl2951-router.shelfdrilling.com MGCP 0.1
F: X, A, I
<--- p="">

  • MGCP Gateway will respond with 200OK acknowledgement providing the requested details.

Jan 27 21:49:11 MST: MGCP Packet sent to 10.170.4.10:2427--->
200 760
I: 6
X: 1
L: p:10-20, a:PCMU;PCMA;G.nX64, b:64, e:on, gc:1, s:on, t:10, r:g, nt:IN;LOCAL, v:T;G;D;L;H;R;ATM;SST;PRE
L: p:10-220, a:G.729;G.729a;G.729b, b:8, e:on, gc:1, s:on, t:10, r:g, nt:IN;LOCAL, v:T;G;D;L;H;R;ATM;SST;PRE
L: p:10-110, a:G.726-16;G.728, b:16, e:on, gc:1, s:on, t:10, r:g, nt:IN;LOCAL, v:T;G;D;L;H;R;ATM;SST;PRE
L: p:10-70, a:G.726-24, b:24, e:on, gc:1, s:on, t:10, r:g, nt:IN;LOCAL, v:T;G;D;L;H;R;ATM;SST;PRE
L: p:10-50, a:G.726-32, b:32, e:on, gc:1, s:on, t:10, r:g, nt:IN;LOCAL, v:T;G;D;L;H;R;ATM;SST;PRE
M: sendonly, recvonly, sendrecv, inactive, loopback, conttest, data, netwloop, netwtest
<--- p="">

  • If there is no active call, I will be empty and X will be '0'.
  • If there is an active call, I will point to ConnectionId of the call and X will point to RequestIdentifier of the call

  • Once Secondary CUCM completes the query of AUEP, it will send AUCX message using I (ConnectionId) requesting for C (CallId) and M (ConnectionMode)

Jan 27 21:49:11 MST: MGCP Packet received from 10.170.4.10:2427--->
AUCX 790 S0/SU0/DS1-0/1@kl2951-router.shelfdrilling.com MGCP 0.1
I: 6
F: C, M
<--- p="">

  • MGCP GW will acknowledge the message with 200OK and provide the details

Jan 27 21:49:11 MST: MGCP Packet sent to 10.170.4.10:2427--->
200 790
C: D000000002924996000000F500000001
M: sendrecv
<--- p="">

  • Secondary CUCM will request MGCP Gateway to monitor DTMF Events using RQNT message. MGCP will acknowledge the request

Jan 27 21:49:12 MST: MGCP Packet received from 10.170.4.10:2427--->
RQNT 791 S0/SU0/DS1-0/1@kl2951-router.shelfdrilling.com MGCP 0.1
X: 1
R: R/iu
Q: process,loop
<--- p="">

Jan 27 21:49:12 MST: MGCP Packet sent to 10.170.4.10:2427--->
200 791 OK
<--- p="">

  • Secondary CUCM will send Q.931 Status Enquiry message to the PRI device attached to the gateway to confirm the status of any calls CUCM believes are preserved.

Jan 27 21:49:12 MST: ISDN Se0/0/0:15 Q931: TX -> STATUS_ENQ pd = 8  callref = 0x0001
Jan 27 21:49:12 MST: ISDN Se0/0/0:15 Q931: RX <- pd="8<span" status="" style="mso-spacerun: yes;"> 
callref = 0x8001
        Cause i = 0x829E - Response to STATUS ENQUIRY or number unassigned
        Call State i = 0x0A

Note: You can't enable or disable MGCP call preservation at GW or CUCM level unlike H323.

Note the difference between SIP/H323 & MGCP. Here call preservation matters if its PRI or non-PRI endpoint because of backhaul concept. However, in SIP/H323, it won't matter since those protocols are independent.

  • During fallback, MGCP gateway will keep probing CUCM servers and once any of them is restored, MGCP GW (in fallback mode) will Rehome to register with that CUCM.
  • The message will be RSIP Graceful > RSIP Restart > 200OK > AUEP > 200OK
  • There are multiple modes of switchback:
    • Graceful (after last call completed) - Default
    • Immediate (even with active calls)
    • Never (disable switchback)
    • Schedule (schedule switchback)
    • Uptime (wait for x time of CUCM restoration before switchback. This is guard time to avoid flapping)

MGCP Call SETUP


MGCP TGW with PRI interfaces introduced new concept which is MGCP Backhaul. Another connection will be established between MGCP GW and CUCM over port TCP 2428. This connection will pass Q931 messages received over PRI to CUCM for processing. MGCP GW won't process Q931 messages locally. It will only terminate Q921 messages from PRI.

  1. The gateway and the PSTN switch exchange ISDN Q.921 Layer 2 information. This registers the gateway with the ISDN switch and ensures that the ISDN connection remains active. Q.921 information stops at the gateway.

mgcp-gateway#sh isdn status
Global ISDN Switchtype = primary-ni

%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 = 0, L2 Session ID = 14
    Total Allocated ISDN CCBs = 0

  1. An ISDN Q.931 Setup call-control message arrives. The gateway puts it in a packet addressed to TCP port 2428 and sends it to the CallManager using PRI Backhaul. The CallManager responds by instructing the gateway to create a connection. The gateway sends an acknowledgement that contains SDP information about its IP, Port, Codec, DTMF Relay, etc

Jan 27 21:48:21 MST: MGCP Packet received from 10.170.4.11:2427--->
CRCX 945 S0/SU0/DS1-0/1@kl2951-router.shelfdrilling.com MGCP 0.1
C: D000000002924996000000F500000001      !!! … Unique Call ID
X: 1     !!! … Unique RequestIdentifier
L: p:20, a:PCMU, s:off, t:00     !!! … Local Connection Options
M: recvonly     !!! … Call Mode
R: D/[0-9ABCD*#]     !!! … RequestedEvents
Q: process,loop
<--- p="">

Jan 27 21:48:21 MST: MGCP Packet sent to 10.170.4.11:2427--->
200 945 OK
I: 6     !!! … MGCP GW will provide CUCM with unique ConnectionId which will be created between MGCP GW and Phone

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

  1. The CallManager then sends three Q.931 messages: Call Proceeding, Alerting, and Connect through the gateway to the PSTN. These messages let the other side of the connection know that CallManager is placing the call, and then that the call has been answered.

We are assuming that Ringback will be provided by Telco to caller and CUCM will not cut-through MGCP gateway to get Ringback from CUCM. If Ringback will be provided by CUCM, CUCM will send MDCX message to MGCP Gateway to provide the Details of ANN Server. MGCP Gateway will connect to ANN Server to get Ringback and send it across to caller over PSTN

  1. After the call is brought up, the CallManager sends the gateway an MGCP MDCX message providing the details of the phone (IP, Port, Codec, etc)

Jan 27 21:48:22 MST: MGCP Packet received from 10.170.4.11:2427--->
MDCX 947 S0/SU0/DS1-0/1@kl2951-router.shelfdrilling.com MGCP 0.1
C: D000000002924996000000F500000001
I: 6
X: 1
L: p:20, a:G.729, s:off, t:b8
M: sendrecv
R: D/[0-9ABCD*#]
S:
Q: process,loop

v=0
o=- 6 0 IN EPN S0/SU0/DS1-0/1@kl2951-router.shelfdrilling.com
s=Cisco SDP 0
t=0 0
m=audio 19160 RTP/AVP 18
c=IN IP4 10.170.0.10
<--- p="">

Jan 27 21:48:22 MST: MGCP Packet sent to 10.170.4.11:2427--->
200 947 OK
<--- p="">

  1. The CallManager gets Q931 acknowledgement of the connection from the other side of the call and RTP stream will be flowing between endpoints

Notes:
a. Backhaul messages are having DSCP value AF31 by default (use the command 'show mgcp | i dscp')
b. In case CUCM fails, MGCP GW ISDN PRI D-Channel won't come up (it will always show status=TEI ASSIGNED). This is because backhaul connection is down; therefore; Q931 messages are failing.

When one of the parties terminates the call:

  1. CUCM signals MGCP GW to terminate the connection using DLCX message

Jan 27 21:32:06 MST: MGCP Packet received from 10.170.4.10:2427--->
DLCX 729 S0/SU0/DS1-0/31@kl2951-router.shelfdrilling.com MGCP 0.1
C: D0000000029246b2000000F500000004
I: 5
X: 1f
S:
<--- p="">

  1. MGCP Gateway will acknowledge the message using 250OK and which includes call statistics report sent to CUCM

Jan 27 21:32:06 MST: MGCP Packet sent to 10.170.4.10:2427--->
250 729 OK
P: PS=11674, OS=233480, PR=11679, OR=233448, PL=3, JI=10, LA=55
<--- p="">