Tag Archives: CME

Interpreting MGCP Debug Parameters

I manage a number of deployments that still feature ISDN extensively, so debug mgcp packet is something that I’m reading off IOS CLI on a fairly routine basis at the moment.

There are a lot of blog posts that cover reading MGCP debugs pretty well, but one thing that I struggled with for a while was being able to quickly interpret the  debug parameters and what they stood for in each respective MGCP message.  Often these are fairly intuitive, but sometimes a quick point of reference is needed.

I looked around on Cisco forums etc., and really there just isn’t anything that covers this well.  Eventually I resorted to the RFC, and was pleasantly unsurprised that all the parameters were well tabulated and easily reference-able.

I’ve included the list below for reference, but as always it is best to go straight to RFC 3435 to get this information!

 


3.2.2 Parameter Lines

Parameter lines are composed of a parameter name, which in most cases
   is composed of one or two characters, followed by a colon, optional
   white space(s) and the parameter value.  The parameters that can be
   present in commands are defined in the following table:


    ------------------------------------------------------------------
   |Parameter name        | Code |  Parameter value                   |
   |----------------------|------|------------------------------------|
   |BearerInformation     |   B  |  See description (3.2.2.1).        |
   |CallId                |   C  |  See description (3.2.2.2).        |
   |Capabilities          |   A  |  See description (3.2.2.3).        |
   |ConnectionId          |   I  |  See description (3.2.2.5).        |
   |ConnectionMode        |   M  |  See description (3.2.2.6).        |
   |ConnectionParameters  |   P  |  See description (3.2.2.7).        |
   |DetectEvents          |   T  |  See description (3.2.2.8).        |
   |DigitMap              |   D  |  A text encoding of a digit map.   |
   |EventStates           |   ES |  See description (3.2.2.9).        |
   |LocalConnectionOptions|   L  |  See description (3.2.2.10).       |
   |MaxMGCPDatagram       |   MD |  See description (3.2.2.11).       |
   |NotifiedEntity        |   N  |  An identifier, in RFC 821 format, |
   |                      |      |  composed of an arbitrary string   |
   |                      |      |  and of the domain name of the     |
   |                      |      |  requesting entity, possibly com-  |
   |                      |      |  pleted by a port number, as in:   |
   |                      |      |    Call-agent@ca.example.net:5234  |
   |                      |      |  See also Section 3.2.1.3.         |
   |ObservedEvents        |   O  |  See description (3.2.2.12).       |
   |PackageList           |   PL |  See description (3.2.2.13).       |
   |QuarantineHandling    |   Q  |  See description (3.2.2.14).       |
   |ReasonCode            |   E  |  A string with a 3 digit integer   |
   |                      |      |  optionally followed by a set of   |
   |                      |      |  arbitrary characters (3.2.2.15).  |
   |RequestedEvents       |   R  |  See description (3.2.2.16).       |
   |RequestedInfo         |   F  |  See description (3.2.2.17).       |
   |RequestIdentifier     |   X  |  See description (3.2.2.18).       |
   |ResponseAck           |   K  |  See description (3.2.2.19).       |
   |RestartDelay          |   RD |  A number of seconds, encoded as   |
   |                      |      |  a decimal number.                 |
   |RestartMethod         |   RM |  See description (3.2.2.20).       |
   |SecondConnectionId    |   I2 |  Connection Id.                    |
   |SecondEndpointId      |   Z2 |  Endpoint Id.                      |
   |SignalRequests        |   S  |  See description (3.2.2.21).       |
   |SpecificEndPointId    |   Z  |  An identifier, in RFC 821 format, |
   |                      |      |  composed of an arbitrary string,  |
   |                      |      |  followed by an "@" followed by    |
   |                      |      |  the domain name of the gateway to |
   |                      |      |  which this endpoint is attached.  |
   |                      |      |  See also Section 3.2.1.3.         |
   |RemoteConnection-     |   RC |  Session Description.              |
   |         Descriptor   |      |                                    |
   |LocalConnection-      |   LC |  Session Description.              |
   |         Descriptor   |      |                                    |
    ------------------------------------------------------------------

   The parameters are not necessarily present in all commands.  The
   following table provides the association between parameters and
   commands.  The letter M stands for mandatory, O for optional and F
   for forbidden.  Unless otherwise specified, a parameter MUST NOT be
   present more than once.

This table is great as I can simply look up the parameter code in my MGCP packet debug and do a quick interpretation.  I also find this very handy when reading off MGCP Connection ID’s and other call-specific tracing that can be cross-referenced in SDL!


 

For example, in a simple AUEP (Audit Endpoint), we see:

 

*Jul 17 11:14:18.332: MGCP Packet received from 192.168.123.213:2427—>
AUEP 31 S0/SU2/DS1-0/1@RTR1.uc.lab MGCP 0.1
F: X, A, I
<—

What has remote side requested information on?

 

Firstly, the side has requested information in a comma-separated list:

|RequestedInfo         |   F  |

 

The list contains the following:

|RequestIdentifier     |   X  |
|Capabilities          |   A  |
|ConnectionId          |   I  |

 

Simple stuff.

 

#dontcalltac

Advertisements
Tagged , , , , , , ,

ISR G2 PVDM3 Video Conferencing Deprecated

If you are in the process of preparing for the CCIE lab, you will be interested and very happy to see this!  A terrible “feature” finally put out to pasture.  So many caveats and considerations to get this to work 😦

A very good move for Cisco as they continue to migrate their video architecture.

The Feature Deprecation Announcement is below:

http://www.cisco.com/c/en/us/products/collateral/unified-communications/tdm-gateways/bulletin-c25-735945.html

 

In 2009, the Cisco® Integrated Services Routers Generation 2 (ISR G2), along with the Cisco Packet Voice Digital Signal Processor Module (PVDM3), introduced an experimental video conferencing feature with Cisco IOS® Software Release 15.1(4)M. This feature enabled the ISR G2 to provide homogeneous video switching features for selected Cisco IP phone models with resolutions of 720p or lower, such as the Cisco Unified IP Phone 7985G, 9951, and 9971. The platform was limited to video switching and did not support video mixing or overlays.

Video transcoding was also possible for a few channels (fewer than 5) for point-to-point video calls using Cisco Unified Border Element (CUBE).

While the intention was to fully support this feature via the use of a Unified Conferencing Video license, the feature was never fully productized or supported. Cisco provided limited best effort support on an as-needed basis.

This feature will be disabled with Cisco IOS Software Release 15.5(3)M. This issue is addressed with the following defect:

CSCus97643: PVDM3: Cisco IOS Software based video transcoder and conferencing commands purged.

 

The bug itself can be viewed here.

For a full list of IOS-supported features that integrate with CUCM, please see the following:

http://www.cisco.com/c/en/us/products/collateral/routers/3900-series-integrated-services-routers-isr/data-sheet-c78-729824.html

A very useful document in my opinion.

Tagged , , , , , , , , , , , ,

SIP SRST Dialling Fails Due to Header Addressing – CSCur95578

Haven’t been able to post in a while as my current project is keeping me very busy!

As the core multi-cluster deployment is now complete, we’ve moved on to site deployments, which has posed a significant challenge as I am attempting to streamline and automate the user and site configuration for about 3000 sites spread across 9 leaf clusters.

One of challenges was to define a working SRST template to account for some very specific business requirements, including differentiated Class of Restriction in SRST for older SCCP and newer SIP models.  We also opted not to pursue SRST Manager, so a balance was struck between feature support and limiting configuration overhead, as the client’s support  team is quite small for the scope of deployment, and simplicity was the key.  This was all finalized and lab-tested and we were ready to proceed to site deployments and testing SRST on live sites.

However, at the first site test SRST failed!  Problem description was:

  • MGCP fallback was successful
  • SCCP and SIP phones registered successfully
  • SCCP devices were able to make/receive external calls
  • SIP devices could make external calls, but could not receive external calls
  • SIP devices could not make/receive internal calls
  • When making a call from a SIP device, no ring-back was heard, and the remote party’s phone didn’t ring.

Based on the problem description, I was immediately able to determine the following:

  1. Problem was a SIP signalling issue
  2. No ring back – calling party was never receiving 18X
  3. No called party ringing – remote party never received, or wasn’t processing the INVITE from IOS gateway

Very strange, as this was working in the lab!

I looked at my basic voice service voip and voice register global configuration, and could not find anything a-miss:

!
voice service voip
allow-connections sip to sip
allow-connections h323 to h323
allow-connections sip to h323
allow-connections h323 to sip
supplementary-service sip refer
supplementary-service sip moved-temporarily
fax protocol t38 version 0 ls-redundancy 0 hs-redundancy 0 fallback pass-through g711alaw
sip
registrar server
bind all source <loopback-interface>
g729 annexb-all
asymmetric payload full
!

!
voice register global
timeouts interdigit 5
system message Service Interruption
max-dn <#>
max-pool <#>
timezone 29
dialplan-pattern 1 0XXXXXX… extension-length 4 extension-pattern X… demote
!

So, time to look at the call flow signalling…  I pulled debug ccsip messages from the gateway

Sample SIP Trace

005298: Oct 29 10:24:38.192: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:
Received:
INVITE sip:0223333733@192.168.1.1;user=phone SIP/2.0
Via: SIP/2.0/UDP 10.1.2.3:5060;branch=z9hG4bK03efbc86
From: “Mr End User” <sip:0223333780@192.168.1.1>;tag=c47295a8075762c24ee36b42-7321fcdb
To: <sip:0223333733@192.168.1.1>
Call-ID: c47295a8-075701fc-0adbec71-182993ef@10.1.2.3
Max-Forwards: 70
Date: Thu, 29 Oct 2015 10:24:37 GMT
CSeq: 101 INVITE
User-Agent: Cisco-CP7841/10.3.1
Contact: <sip:d029fdee-4ea8-b62e-793a-8db0132ff40f@10.1.2.3:5060;transport=udp>
Expires: 180
Accept: application/sdp
Allow: ACK,BYE,CANCEL,INVITE,NOTIFY,OPTIONS,REFER,REGISTER,UPDATE,SUBSCRIBE,INFO
Remote-Party-ID: “Mr End User” <sip:0223333780@192.168.1.1>;party=calling;id-type=subscriber;privacy=off;screen=yes
Supported: replaces,join,sdp-anat,norefersub,resource-priority,X-cisco-srtp-fallback,X-cisco-xsi-8.5.1
Allow-Events: kpml,dialog
Content-Length: 350
Content-Type: application/sdp
Content-Disposition: session;handling=optional

v=0
o=Cisco-SIPUA 19428 0 IN IP4 10.1.2.3
s=SIP Call
t=0 0
m=audio 31580 RTP/AVP 9 0 8 116 18 101
c=IN IP4 10.1.2.3
a=rtpmap:9 G722/8000
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:116 iLBC/8000
a=fmtp:116 mode=20
a=rtpmap:18 G729/8000
a=fmtp:18 annexb=no
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
a=sendrecv

005327: Oct 29 10:24:38.196: //65387/17A79D7C8B2A/SIP/Msg/ccsipDisplayMsg:
Sent:
SIP/2.0 100 Trying
Via: SIP/2.0/UDP 10.1.2.3:5060;branch=z9hG4bK03efbc86
From: “Mr End User” <sip:0223333780@192.168.1.1>;tag=c47295a8075762c24ee36b42-7321fcdb
To: <sip:0223333733@192.168.1.1>
Date: Thu, 29 Oct 2015 10:24:38 GMT
Call-ID: c47295a8-075701fc-0adbec71-182993ef@10.1.2.3
CSeq: 101 INVITE
Allow-Events: kpml, telephone-event
Server: Cisco-SIPGateway/IOS-15.4.3.M1
Content-Length: 0
005361: Oct 29 10:24:38.200: //65388/17A79D7C8B2A/SIP/Msg/ccsipDisplayMsg:
Sent:
INVITE sip:0223333733@10.2.3.4:5060 SIP/2.0
Via: SIP/2.0/UDP 10.0.0.1:5060;branch=z9hG4bK4001264
Remote-Party-ID: “Mr End User” <sip:3780@10.0.0.1>;party=calling;screen=yes;privacy=off
From: “Mr End User” <sip:3780@10.0.0.1>;tag=A32FEE28-18F2
To: <sip:0223333733@10.2.3.4>
Date: Thu, 29 Oct 2015 10:24:38 GMT
Call-ID: 17A8D664-7D5E11E5-8B30FF52-8FAD66E0@10.0.0.1
Supported: 100rel,timer,resource-priority,replaces
Min-SE: 1800
Cisco-Guid: 0396860796-2103316965-2334850898-2410505952
User-Agent: Cisco-SIPGateway/IOS-15.4.3.M1
Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, SUBSCRIBE, NOTIFY, INFO, REGISTER
CSeq: 101 INVITE
Timestamp: 1446114278
Contact: <sip:3780@10.0.0.1:5060>
Expires: 180
Allow-Events: kpml, telephone-event
Max-Forwards: 69
Content-Type: application/sdp
Content-Disposition: session;handling=required
Content-Length: 324

v=0
o=CiscoSystemsSIP-GW-UserAgent 7919 527 IN IP4 10.0.0.1
s=SIP Call
c=IN IP4 10.0.0.1
t=0 0
m=audio 24612 RTP/AVP 0 8 18 101
c=IN IP4 10.0.0.1
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:18 G729/8000
a=fmtp:18 annexb=yes
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
a=ptime:20

005363: Oct 29 10:24:38.700: //65388/17A79D7C8B2A/SIP/Msg/ccsipDisplayMsg:
Sent:
INVITE sip:0223333733@10.2.3.4:5060 SIP/2.0
Via: SIP/2.0/UDP 10.0.0.1:5060;branch=z9hG4bK4001264
Remote-Party-ID: “Mr End User” <sip:3780@10.0.0.1>;party=calling;screen=yes;privacy=off
From: “Mr End User” <sip:3780@10.0.0.1>;tag=A32FEE28-18F2
To: <sip:0223333733@10.2.3.4>
Date: Thu, 29 Oct 2015 10:24:38 GMT
Call-ID: 17A8D664-7D5E11E5-8B30FF52-8FAD66E0@10.0.0.1
Supported: 100rel,timer,resource-priority,replaces
Min-SE: 1800
Cisco-Guid: 0396860796-2103316965-2334850898-2410505952
User-Agent: Cisco-SIPGateway/IOS-15.4.3.M1
Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, SUBSCRIBE, NOTIFY, INFO, REGISTER
CSeq: 101 INVITE
Timestamp: 1446114278
Contact: <sip:3780@10.0.0.1:5060>
Expires: 180
Allow-Events: kpml, telephone-event
Max-Forwards: 69
Content-Type: application/sdp
Content-Disposition: session;handling=required
Content-Length: 324

v=0
o=CiscoSystemsSIP-GW-UserAgent 7919 527 IN IP4 10.0.0.1
s=SIP Call
c=IN IP4 10.0.0.1
t=0 0
m=audio 24612 RTP/AVP 0 8 18 101
c=IN IP4 10.0.0.1
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:18 G729/8000
a=fmtp:18 annexb=yes
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
a=ptime:20

Suddenly the problem was immediately apparent, but made no sense!  So, what is happening here?

  • Side A phone IP : 10.1.2.3
  • Side B phone IP : 10.2.3.4
  • IOS Loopback IP : 192.168.1.1
  • IOS Ethernet IP : 10.0.0.1

As we can see from the trace:

  1. Despite the Loopback binding, the IOS device was sourcing outbound SIP traffic from the outbound physical interface, instead of the loopback
  2. Outbound INVITE is sent to Side B, but is clearly never processed, as IOS never receives a 1XX Trying/Ringing.  As a result, IOS never sends on a 18X Ringing to Side A, and ring back is never played to the calling party
  3. Multiple INVITEs are re-sent to Side B, which never responds to the call (call setup eventually ended with a  CANCEL from Side A)

Why is this happening!?  Well, the SRST reference in the phone was the Loopback IP, and as a result, the phones registered to the Loopback interface in SRST mode.  As such, they are only going to respond to call setup signalling sourced from this IP – Side B is effectively ignoring the call setup request.

As I’m sure you can guess, this behaviour is not expected, and I immediately thought this was a bug.  What had changed between lab testing and production?  IOS version…  The remote deployment teams had been deploying routers without an upgrade to the Cisco-recommended version that we had tested in the lab.  To validate my conclusion, I looked on cisco.com Bug Search, and got a 1st time hit on the following:

https://tools.cisco.com/bugsearch/bug/CSCur95578

CME-SIP call fails when sip bind is applied under voice service voip

CSCur95578

Description

Symptom:
When a voice gateway falls back to the SRST mode, system message that is configured in the “voice register gloal” section is not displayed on SIP phones

Conditions:
– Voice gateway use the loopback IP address as CME source address
– SIP phones lost the communication to Cisco Unified Call Manager and fall back to SRST mode

Workaround:
Downgrade to an IOS without the fix for CSCup30934 Use a physical IP as CME source address.

We upgraded to the recommended IOS version and re-tested – with immediate positive results.

Conclusion:

This defect outlined a very important point regarding SRST/CME.  In non-trivial deployments with multiple LAN interfaces (or if there are WAN-remote registration devices), always source traffic from a bound interface when traffic is destined to internal devices.  In our case, I could have removed the bind, but the gateway was redundantly connected to 2 core switches with Layer 3 links, which was always going to pose a problem.  Almost without fail, a loopback is the preferred option.

However… some may correctly comment that this may break ITSP call flows if a local SIP Trunking solution is in use – it will, and must be accounted for.  In my base the remote site used ISDN technology, but when a SIP Trunking solution is in use, the ITSP-facing dial peers should be referenced with voice-class sip bind commands.

Great links on this topic here:

 

#dontcalltac

Tagged , , , ,
Collaboration Engineer

All things Technology - Posts to save for when you need them

Gerry Keleghan's Blog

A Blog about Cisco Unified Communications

ccieme

my personal journey to ccie collaboration

Striving for greatness

Thoughts on emerging tech, open source, and life

Network Experts Blog

“Knowledge comes by eyes always open and working hands.”

SIP Adventures

A unified communications blog by Andrew Prokop

The Cloverhound Blog

Cloverhound Employees Talk Unified Communications and Contact Center

Warcop

Fog navigator. Get out of the clouds. Down to earth solutions. @Warcop

Cisco Collab Engineering Tips

Michael White - CCIE #26626

Darkroomstory

Photography by Manos,

afterthenumber

Thoughts and experiences of a Cisco Collaboration engineer after clearing the CCIE lab...

Longreads

The best longform stories on the web

The Daily Post

The Art and Craft of Blogging

The WordPress.com Blog

The latest news on WordPress.com and the WordPress community.