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

2. 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

3. 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

4. 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="">

5. 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="">

2. 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="">