Called/Calling Party Transformation Pattern Behavior on UCM 7.0

While calling out you cannot DM the calling party number using ‘Calling Party Transformation Pattern’, on the same while calling in you cannot DM the called party number using ‘Called Party Transformation Pattern’.

If you require to manipulate as mentioned you can do it either on the Gateway or Trunk for the ‘calling in’ cases (unfortunately you don’t have much choice for such route) and on the Translation Pattern, Route List, Route Pattern, Gateway and Trunk for ‘calling out’ cases (you have lots of choice here!).

Limitations of such ‘Calling/Called Party Transformation Pattern’ is resolved on UCM 8.0 and later versions so far I heard but didn’t tested it yet.

Can you change the CSS of a pattern? It’s simple by Translation Pattern

I won’t make this note longer by explaining it, a simple example will help enough to understand it!

Think for the example: you have a pattern 9.[2-9]XXXXXX which is configured on partition: PT-SA-User (part of CSS-SA-User), route list: RL-SA-SLRG. Now you want your SB users dial the same pattern but their CSS doesnt’ have sufficient permission to access the partition PT-SA-User. So what to do? Just assign the partition under their CSS right? I know it’s the simplest method but to learn to change the permission we shall do it with Translation Pattern (TP).

On the configuration page of translation-pattern you will see there is one ‘Partition’ field and another is ‘CSS’ field, so what’s the reason to give both partition and CSS on the same page? The reason and rule is simple. Think ‘From the parition xxx’ and ‘To the CSS yyy’, so any incoming call from the Partition  xxx will fall down to the CSS yyy. That’s simple, right? Now let’s finish the job!

Create one TP with Partition: PT-SB-User, CSS: CSS-SA-User, put the exact pattern you need to change partition  i.e. 9[2-9]XXXXXX. That’s done! Now though the SB user CSS doesn’t contain the partition PT-SA-User, but the SB phones still can dial through the pattern configured with PT-SA-User, because we changed the permission with Translation Pattern!

Happy Labbing! I’m really missing those days of labbing! 😦

Maximum Number of Conference Participants on Hardware CFB: a small note

IOS earlier than 12.4(15)T supports 8 participants per conference session.

IOS equal or later than 12.4(15)T supports 32 participants per conference session.

Found on CUCM SRND: http://www.cisco.com/en/US/docs/voice_ip_comm/cucm/srnd/7x/media.html#wp1046210

“A conference based on these DSPs allows a maximum of 8 participants. When a conference begins, all 8 positions are reserved at that time. Starting with Cisco IOS Release 12.4(15)T, this limit on the maximum number of participants has been increased to 32.”

Understanding MGCP Packets: A brief overview and example with debugs

While studying MGCP protocol messages from debugs my head was spinning like ‘what the c**p message are those!’, had an weird idea to generate the call and capture all MGCP packets and write down explanation of each of the terms. I am weak on the MGCP debugs packets from the beginning of starting voice, now I just wanted to nail it down and wished to learn whole conversations between MGCP GW and the Call Agents. Tough one for me I know but who doesn’t want to learn something new? Took the challenge and I think now it’s quite easy for me. 🙂

Before starting the derivation let’s write down the MGCP Packet verbs and code explanations:

Code Verb
AUCX    AuditConnection.
AUEP    AuditEndpoint.
CRCX    CreateConnection.
DLCX    DeleteConnection.
EPCF    EndpointConfiguration.
MDCX    ModifyConnection.
RQNT    NotificationRequest.
NTFY    Notify.
RSIP    RestartInProgress.

Code Description
200    The requested transaction was executed normally.
250    The connection was deleted.

Code Description

400    The transaction could not be executed, due to a transient error.
401    The phone is already off hook.
402    The phone is already on hook.

Code Description
500    The transaction could not be executed, because the endpoint is unknown.
501    The transaction could not be executed, because the endpoint is not ready.
502     The transaction could not be executed, because the endpoint does not have sufficient resources.

I haven’t write down all the codes here to save my space on this post.
There are some more error codes can be found from the link:

http://www.networksorcery.com/enp/protocol/mgcp.htm

Now let’s collect the MGCP Packets from the gateway end with the debug command ‘debug mgcp packets’.
My setup had one PUB one SUB, phones are registered with the SUB.

The events during capturing debug packets:
First, I called one PSTN side phone from one IP Phone, collected the message for first attempt.
Second, recieved the call from PSTN phone, nothing was appeared on the gateway.
Third, when the call is established I shutted down the subscriber CallManager service, so PUB immediately took over the call.
Forth, Hanged up the call and the call was cleared.

Now lets start discussing the debug packets and understanding those one by one:

=========================================================
First, when initialing call and PSTN phone is ringing
=========================================================

– Connection Request (CRCX)
————————————————————————-
Aug  7 07:53:35.628: MGCP Packet received from 10.10.210.12:2427—>
CRCX 49 S0/SU0/DS1-0/2@HQ.ccievoice.com MGCP 0.1
C: D000000002743a14000000F500000006
X: 2
L: p:20, a:PCMU, s:off, t:b8
M: recvonly
R: D/[0-9ABCD*#]
Q: process,loop
<—

– Message that ‘requested transaction was executed normally’ (message code: 200)
——————————————————————————————————–
Aug  7 07:53:35.652: MGCP Packet sent to 10.10.210.12:2427—>
200 49 OK
I: 19

v=0
c=IN IP4 10.10.210.254
m=audio 18404 RTP/AVP 0 100
a=rtpmap:100 X-NSE/8000
a=fmtp:100 192-194,200-202
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 192-194,200-202
a=X-cap: 2 image udptl t38
<—

– Message to Modify Connection (MDCX) – this happens when called party confirms it’s existense and ringback tone is heard on the caller phone
———————————————————————————————————————————————————————–
Aug  7 07:53:35.776: MGCP Packet received from 10.10.210.12:2427—>

HQ#MDCX 50 S0/SU0/DS1-0/2@HQ.ccievoice.com MGCP 0.1
C: D000000002743a14000000F500000006
I: 19
X: 2
L: p:20, a:PCMU, s:off, t:b8
M: sendrecv
R: D/[0-9ABCD*#]
S:
Q: process,loop

v=0
o=- 25 0 IN EPN S0/SU0/DS1-0/2@HQ.ccievoice.com
s=Cisco SDP 0
t=0 0
m=audio 22760 RTP/AVP 0
c=IN IP4 10.234.130.209
<—

– Message that ‘requested transaction was executed normally’ (message code: 200)
——————————————————————————————————
Aug  7 07:53:35.780: MGCP Packet sent to 10.10.210.12:2427—>
200 50 OK
<—

=================================================================================================================
Second, recieved the call, RTP packets started going over on both the way, but nothing was appeared on the debug.
=================================================================================================================

===============================================================================================================
Third, Active Primary call-agent is down when a call is active and secondary call-agent is taking over the call
===============================================================================================================

– Message that the MGCP GW have noticed the primary call-agent service is down so
the gateway blocks idle circuits and waits for the exiting connections to be terminated gracefully (RSIP=RestartInProgress, RM:graceful)
————————————————————————————————————————————————————————
Aug  7 09:11:25.523: MGCP Packet sent to 10.10.210.12:2427—>
RSIP 70602705 *@HQ.ccievoice.com MGCP 0.1
RM: graceful
<—

– But immediately the secondary call-agent takes over the gateway and initiates a restart message to unblock the active channels (RSIP:RestartInProgress, RM:restart)
———————————————————————————————————————————————————————
Aug  7 09:11:25.523: MGCP Packet sent to 10.10.210.11:2427—>
RSIP 70602707 *@HQ.ccievoice.com MGCP 0.1
RM: restart
<—

– Gateway recieves 200 message from the secondary call agent (message code: 200)
——————————————————————————————————————
Aug  7 09:11:25.559: MGCP Packet received from 10.10.210.11:2427—>
200 70602707
<—

– Regular keepalive message from GW to call-agent
————————————————————–
Aug  7 09:11:25.563: MGCP Packet sent to 10.10.210:2427—>
NTFY 70602709 *@HQ.ccievoice.com MGCP 0.1
X: 0
O:
<—

– Active call-agent (backup) sends AUEP (AuditEndPoint) message to MGCP GW to check status of the gateway bearer channels.
The following AUEP message is to check the status of DS1-0/1 circuit.

detail of AUEP message can be found here though it’s applicable for BTS10200 SoftSwitch, but it gives an idea of AUEP:

http://www.cisco.com/en/US/docs/voice_ip_comm/bts/4.5/troubleshooting/guide/apxctg.html
—————————————————————————————————————————————————————–
Aug  7 09:11:25.591: MGCP Packet received from 10.10.210.11:2427—>
AUEP 74 S0/SU0/DS1-0/1@HQ.ccievoice.com MGCP 0.1
F: X, A, I
<—

– MGCP GW sends the status of the requested bearer channel regardless of active/block/idle state with ‘200’ message
————————————————————————————————————————————————
Aug  7 09:11:25.595: MGCP Packet sent to 10.10.210.11:2427—>
200 74
I:
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;ATM;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;ATM;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;ATM;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;ATM;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;ATM;LOCAL, v:T;G;D;L;H;R;ATM;SST;PRE
L: p:30-270, a:G.723.1-H;G.723;G.723.1a-H, b:6, e:on, gc:1, s:on, t:10, r:g, nt:IN;ATM;LOCAL, v:T;G;D;L;H;R;ATM;SST;PRE
L: p:30-330, a:G.723.1-L;G.723.1a-L, b:5, e:on, gc:1, s:on, t:10, r:g, nt:IN;ATM;LOCAL, v:T;G;D;L;H;R;ATM;SST;PRE
M: sendonly, recvonly, sendrecv, inactive, loopback, conttest, data, netwloop, netwtest
<—

– CA Agent again sends another AUEP message to check the status of DS1-0/2 circuit
———————————————————————————————————
Aug  7 09:11:25.595: MGCP Packet received from 10.10.210.11:2427—>
AUEP 75 S0/SU0/DS1-0/2@HQ.ccievoice.com MGCP 0.1
F: X, A, I
<—

– Gateway again replies with 200 message for the channel DS1-0/2
OT be noted that: the following channel is active on a call.

Here ‘I’ signifies to ‘Connection identification number’ and it will contain a value only when a connection is established, i.e. for an active call
————————————————————————————————————————————————————————-
Aug  7 09:11:25.599: MGCP Packet sent to 10.10.210:2427—>
200 75
I: 1A
X: 2
L: p:10-20, a:PCMU;PCMA;G.nX64, b:64, e:on, gc:1, s:on, t:10, r:g, nt:IN;ATM;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;ATM;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;ATM;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;ATM;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;ATM;LOCAL, v:T;G;D;L;H;R;ATM;SST;PRE
L: p:30-270, a:G.723.1-H;G.723;G.723.1a-H, b:6, e:on, gc:1, s:on, t:10, r:g, nt:IN;ATM;LOCAL, v:T;G;D;L;H;R;ATM;SST;PRE
L: p:30-330, a:G.723.1-L;G.723.1a-L, b:5, e:on, gc:1, s:on, t:10, r:g, nt:IN;ATM;LOCAL, v:T;G;D;L;H;R;ATM;SST;PRE
M: sendonly, recvonly, sendrecv, inactive, loopback, conttest, data, netwloop, netwtest
<—

– CA Agent again sends another AUEP message to check the status of DS1-0/3 circuit
———————————————————————————————————
Aug  7 09:11:25.599: MGCP Packet received from 10.10.210.11:2427—>
AUEP 76 S0/SU0/DS1-0/3@HQ.ccievoice.com MGCP 0.1
F: X, A, I
<—

– MGCP GW returns that the circuit is not established and the endpoint is unknown with the message ‘500’

Message code ‘500’ = ‘The transaction could not be executed, because the endpoint is unknown.’
————————————————————————————————————————————-
Aug  7 09:11:25.599: MGCP Packet sent to 10.10.210.11:2427—>
500 76 Endpt Unknown
<—

– Thus CA requests to check status for the bearer channels DS1-0/1 to DS1-0/23.
—————————————————————————————————
Aug  7 09:11:25.619: MGCP Packet received from 10.10.210.11:2427—>
AUEP 96 S0/SU0/DS1-0/23@HQ.ccievoice.com MGCP 0.1
F: X, A, I
<—

Aug  7 09:11:25.619: MGCP Packet sent to 10.10.210.11:2427—>
500 96 Endpt Unknown
<—

– Call Agent request the gateway for additional information of the active call on the bearer channel DS1-0/2 with message AUCX

“AUCX = AuditConnection”
——————————————————————————————————————————————————————–
Aug  7 09:11:25.619: MGCP Packet received from 10.10.210.11:2427—>
AUCX 97 S0/SU0/DS1-0/2@HQ.ccievoice.com MGCP 0.1
I: 1A
F: C, M
<—

– MGCP GW returns the additional information with ‘200’ message. It sends the Call Identification Number (C) and Connection Mode (M)

To be noted that: ‘C’ is not the caller id, it’s the call identification number
M: sendrecv means, the call is on active state
—————————————————————————————————————————————————————————
Aug  7 09:11:25.619: MGCP Packet sent to 10.10.210.11:2427—>
200 97
C: D000000002743a16000000F500000007
M: sendrecv
<—

– Call Agent request notification with the message RQNT as the connection was reported some ICMP Unreachable (R/iu) for the channel DS1-0/2
R/iu = RTP channel was reported for ICMP Unreachable (iu)

For more info about “R: R/iu” please visit the link:

http://tools.ietf.org/html/draft-foster-mgcp-basic-packages-07
————————————————————————————————————————————————————————-
Aug  7 09:11:25.627: MGCP Packet received from 10.10.210.11:2427—>
RQNT 98 S0/SU0/DS1-0/2@HQ.ccievoice.com MGCP 0.1
X: 2
R: R/iu
Q: process,loop
<—

– MGCP GW receives the message and reports the CA with message type 200
———————————————————————————————-
Aug  7 09:11:25.627: MGCP Packet sent to 10.10.210.11:2427—>
200 98 OK
<—

– As the connection was reported the gateway sends a RestartInProgress and restarts the call gracefully
———————————————————————————————————————————–
Aug  7 09:11:26.023: MGCP Packet sent to 10.10.210.12:2427—>
RSIP 70602705 *@HQ.ccievoice.com MGCP 0.1
RM: graceful
<—

=============================
Forth, Call is Disconnecting
=============================

– CA request the gateway to terminate the call with DLCX(DeleteConnection) message
———————————————————————————————————
HQ#
Aug  7 10:56:55.990: MGCP Packet received from 10.10.210.11:2427—>
DLCX 125 S0/SU0/DS1-0/2@HQ.ccievoice.com MGCP 0.1
C: D00000000274ec6e000000F500000001
I: 1B
X: 2
S:
<—

– Gateway resposes to CA with Confirmation of deletion the message

Message code ‘250’: ‘The Connection was deleted’
—————————————————————————————
Aug  7 10:56:56.010: MGCP Packet sent to 10.10.210.11:2427—>
250 125 OK
P: PS=3687, OS=589920, PR=0, OR=0, PL=0, JI=0, LA=0
<—

Switchback to Call Agent (CUCM): H.323 and MGCP Approach

One topic is ‘HOT’ on the discussion forums now a days and that is how MGCP and H.323 gateway switchback to backup CUCM when primary is down or switchback to primary CUCM when it’s up again. I have tested some scenarios on my lab and the following procedures can be followed for such requirements:

For H323 GW

The command ‘h225 timeout tcp establish x’ plays the roll here within dial-peers. If any call agent goes down while in a call, after configurable number of seconds if searches other dial-peers with the same destination-pattern configured and switchback to that dial-peer.
!
voice class h323 1
h225 timeout tcp establish 3
!
dial-peer voice 1 voip
destination-pattern 3…
voice-class h323 1
session target ipv4:SUB
no vad
!
!
dial-peer voice 2 voip
destination-pattern 3…
voice-class h323 1
session target ipv4:PUB
no vad
preference 1
!

For MGCP GW

Either manually configure this on gateway (if we don’t download the configuration with the command ccm-manager config):
!
ccm-manager switchback immediate
!

Or configuring it on the MGCP GW page at CUCM (must need the command ccm-manager config):

“Switchback Timing* = Immediate”,  It’s ‘Graceful’ by default.

This is just to mention that: you can switchover to backup Call Agent manually with the command ‘ccm-manager switchover-to-backup’ if the command ‘ccm-manager switchover immediate/graceful/scheduled’ is already not configured.

happy labbing! 🙂

If you want to know what MTP (Media Termination Point) does: I loved this discussion!

I was surfing the CSC (Cisco Support Community) discussions and stopped while this discussion took my attention.

https://supportforums.cisco.com/thread/2028260

You can also kill some of your time if you still have confusion on what Media Termination Point (MTP) does both in CUCM or IOS.

Call Forward Doesn’t Work for Hunt Group Member!!!

A weird problem I am facing with CCM4.2 (I have also checked with the CUCM7.0 ) on my production. The scenario is like this:

PSTN/Internal Phones—>Hunt Pilot—>Hunt List—>Hunt Group—>Hunt Member [forwarded to any PSTN/IP Phone]

For this particular type of case call forwarding is not working! I have selected the ‘User Preference’ from the Hunt Pilot ‘Call Forwarding’ option but it just give me busy tone rather than forwarding the calls. But if I dial directly to those particular numbers (not through hunt pilot), it’s forwarding properly as expected. Is it a bug? I’m not sure!!

But I have found one workaround 😀 if the call flow is exactly like below it works fine:

PSTN/Internal Phones—>Hunt Pilot—>Hunt List—>Hunt Group—>Hunt Member —(forwarded)—>non-Hunt #–>Forwarded #

On that case I have forwarded the number on my wish and it’s worked fine! I just configured the CFNA/Busy from the Hunt Pilot and is forwarded to that ‘non-Hunt#’ and the ‘User Preference’ is also unchecked, and nothing is configured on the hunt member lines.

Well, if you think you have faced the same issue before and you know the solution for this or if I’m missing something you know,  your kind comment would be highly appreciated.