Tag Archives: CUBE

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 (        |
   |CallId                |   C  |  See description (        |
   |Capabilities          |   A  |  See description (        |
   |ConnectionId          |   I  |  See description (        |
   |ConnectionMode        |   M  |  See description (        |
   |ConnectionParameters  |   P  |  See description (        |
   |DetectEvents          |   T  |  See description (        |
   |DigitMap              |   D  |  A text encoding of a digit map.   |
   |EventStates           |   ES |  See description (        |
   |LocalConnectionOptions|   L  |  See description (       |
   |MaxMGCPDatagram       |   MD |  See description (       |
   |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         |
   |ObservedEvents        |   O  |  See description (       |
   |PackageList           |   PL |  See description (       |
   |QuarantineHandling    |   Q  |  See description (       |
   |ReasonCode            |   E  |  A string with a 3 digit integer   |
   |                      |      |  optionally followed by a set of   |
   |                      |      |  arbitrary characters (  |
   |RequestedEvents       |   R  |  See description (       |
   |RequestedInfo         |   F  |  See description (       |
   |RequestIdentifier     |   X  |  See description (       |
   |ResponseAck           |   K  |  See description (       |
   |RestartDelay          |   RD |  A number of seconds, encoded as   |
   |                      |      |  a decimal number.                 |
   |RestartMethod         |   RM |  See description (       |
   |SecondConnectionId    |   I2 |  Connection Id.                    |
   |SecondEndpointId      |   Z2 |  Endpoint Id.                      |
   |SignalRequests        |   S  |  See description (       |
   |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         |
   |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—>
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.



Tagged , , , , , , ,

CUBE URI-based Routing and Multiple Via Headers

Cisco introduced some pretty cool URI enhancements for CUBE from 15.4(1)T that have added some great extensions to the CUBE feature set, and specifically include some fine-grained SIP routing control.  These have been long overdue as IOS-based VoIP routing has been heavily dependent on numerical pattern matching due to Cisco’s ongoing support for H.323-style legacy configuration.

These enhancements are covered in a lovely Cisco doc here.  I’ve also blogged previously on a similar topic on how to utilize these and other new CUBE SIP features to provide Loop Prevention on CUBE.


To start, the basic configuration for URI dial-peer matching is somewhat trivial:

voice class uri voice-class-uri-tag sip|tel
    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

Here we see that incoming called-number is dropped and is instead routing using incoming uri.  Typically, we’d match the URI on a via header, with our voice class uri container applying a match on our preferred IP Address / DNS address.

I am referring to RFC compliant behaviour for the Via header from RFC 3261: Via

   The Via header field indicates the transport used for the transaction
   and identifies the location where the response is to be sent.  A Via
   header field value is added only after the transport that will be
   used to reach the next hop has been selected (which may involve the
   usage of the procedures in [4]).

   When the UAC creates a request, it MUST insert a Via into that
   request.  The protocol name and protocol version in the header field
   MUST be SIP and 2.0, respectively.  The Via header field value MUST
   contain a branch parameter.  This parameter is used to identify the
   transaction created by that request.  This parameter is used by both
   the client and the server.

Here we note that a SIP Request can contain multiple Via headers.  This is used as a loop prevention mechanism for SIP Routing.  This becomes incredibly import when multiple SIP Proxies forward requests.  This is well described here for the SIP initiate.


With this in mind, I came across an interesting scenario recently where a call route through an ITSP’s SIP Proxy network changed without my knowledge, meaning that the Via header ordered list in the inbound INVITE changed.  This resulted in not matching my voice class uri configuration.  This stymied me at first until I noted the following for this feature:

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. This feature supports matching by the last hop that 
forwarded the request (neighboringSIPentity), which is the topmost via 


From the PDF link’s worked examples, we can see the matching will use the following behaviour:

INVITE sip:123@ SIP/2.0

Via: SIP/2.0/TCP;branch=z9hG4bK-17716-1-0

Via: SIP/2.0/TCP;branch=z9hG4bK-28280-1-0


In my situation, I’d been using a voice class uri that looked something like this:

voice class uri ITSP sip
    host ipv4:
dial-peer voice tag voip
 session protocol sipv2
 incoming uri via ITSP
I would have expected the feature to consider the ordered list in decreasing priority, but the dial-peer never matched…  As per the feature description, only the “neighboringSIPentity” is considered.
Just something to note when deploying this feature in future.
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:



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:


A very useful document in my opinion.

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

CUBE SIP Profiles – Normalizing Incorrect RURI/To Headers using Diversion

Had a strange requirement today.  Needed to replicate a behaviour that is apparently quiet common on Asterisk, but haven’t seen it before myself.

Our ITSP implemented a new softswitch/SBC setup that currently appears to be limiting (may just be configuration) when they “forward” a call internally within the softswitch to a trunk.

Our situation is that a client has a hybrid setup where a DID range is shared between extensions registered to their on-site CUCM cluster, and the hosted ITSP softswitch.  The inbound voice traffic is via a PRI that terminates on the client’s Cisco Voice Gateway.

This brings in the following type of call flow:

  1. Inbound traffic from ISDN
  2. Route traffic to CUCM
  3. Match DNs in Internal Partition, if not, Route Pattern back out same SIP Trunk to CUBE
  4. CUBE has registered trunk to ITSP, Loop Prevention is implemented to avoid extensions bouncing back and forth between system

External traffic is routed via ITSP, and both sides need to support 4-digit dialling between systems.

The challenge came on the softswitch side getting calls from softswitch-registered endpoints to CUCM.  The ITSP needed to provision aliases for the CUCM extensions and implement forwarding rules to the SIP Trunk SIP Account.

The result wasn’t pretty when it hit the CUBE inbound:

006846: Mar 17 21:33:56.184: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:
INVITE sip:4396594@ SIP/2.0
Via: SIP/2.0/UDP;branch=z9hG4bK0cB81sdf867sdf7
From: “Jonathan%20%20Els” <sip:0112223333@>;tag=gK0c7b172a
To: <sip:4396594@>
Call-ID: 19662878_12345657@
CSeq: 957845045 INVITE
Max-Forwards: 70
Accept: application/sdp, application/isup, application/dtmf, application/dtmf-relay, multipart/mixed
Contact: “Jonathan%20%20Els” <sip:0112223333@;reg-info=1280c>
P-Preferred-Identity: “Jonathan%20%20Els” <sip:0112223333@>
Diversion: <sip:27445556666@>;privacy=off;screen=no; reason=unknown; counter=1
Supported: timer,100rel,precondition,replaces
Session-Expires: 1800
Min-SE: 90
Content-Length: 269
Content-Disposition: session; handling=required
Content-Type: application/sdp

o=Sonus_UAC 884721489 1041972446 IN IP4
s=SIP Media Capabilities
c=IN IP4
t=0 0
m=audio 48880 RTP/AVP 18 8 101
a=rtpmap:18 G729/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15

There’s a lot going on (*wrong :)) here…  Let’s break it down:

  • 4396594 – Called Party information is set to the SIP Account, not the DID that the hosted-PBX user tried to dial
  • 0112223333 – Calling number is set to the DID, and in local E.164 format
  • 27445556666 – Diversion header contains the Called Party information (i.e. based on the ITSP configuration described above, this is the “forwarding Alias”).  This is already in a plus-stripped E.164 format – not routable on our CUCM at the moment.
  • Jonathan%20%20Els – Oops, whitespace is duplicated and is URL encoded.


So, to normalize this, we need to do the following:

  1. Copy Diversion header DID and replace in the Inbound INVITE Request URI and To headers
  2. Calling Number is localized already – no need to cater for that
  3. Called number should be normalized to localized E.164 10-digit formatting – a task we will leave to CUCM to do.
  4. Encoded URL can be ignored – CUBE will translate this natively


As with all normalizations, we have 2 solutions available:

  • SIP Profiles in IOS
  • Lua Scripting in CUCM


I was requested to solve this in SIP Profiles.  To do this, we’ll need to make use of the  Support for Conditional Header Manipulation of SIP Headers feature that was implemented in 15.1(3)T:

The Support for Conditional Header Manipulation of SIP Headers feature provides the following enhancements to Cisco UBE:

  • The ability to pass unsupported parameters present in a mandatory header from one call leg to another.
  • The ability to copy contents from one header to another header in an outgoing SIP message.


Unfortunately the guide contains errors… thanks Cisco.  Here’s a working configuration to meet my requirement below:

Create copy list:

voice class sip-copylist 2
sip-header Diversion


Apply to copylist to inbound dial-peer:

dial-peer voice 200 voip
description *** ITSP ***
session protocol sipv2
session target sip-server
destination dpg 2
destination e164-pattern-map 2
incoming called-number .
voice-class codec 1
voice-class sip options-keepalive profile 2
voice-class sip copy-list 2
dtmf-relay rtp-nte sip-kpml
no vad

Copy Diversion in about sip-profile, and apply to RURI and To headers:

voice class sip-profiles 1
request INVITE peer-header sip Diversion copy “sip:(.*)@” u01
request INVITE sip-header SIP-Req-URI modify “.*@(.*)” “INVITE sip:\u01@\1″
request INVITE sip-header To modify “.*@(.*)” “To: <sip:\u01@\1″

Apply to CUCM dial-peer:

dial-peer voice 100 voip
description *** CUCM – SAIG ***
session protocol sipv2
session server-group 1
destination dpg 1
destination e164-pattern-map 1
incoming uri via CUCM
voice-class codec 1
voice-class sip profiles 1
voice-class sip options-keepalive profile 1
dtmf-relay rtp-nte sip-kpml
no vad

We still need to add routing for the SIP Account to actually HIT the outbound dial-peer, so we update our CUCM e164-pattern-map accordingly:

voice class e164-pattern-map 1
description *** To CUCM ***
e164 4396594


The final product sent to CUCM looks  good!


006848: Mar 17 21:33:56.192: //2592/C9846AB38DFD/SIP/Msg/ccsipDisplayMsg:
INVITE sip:27445556666@ SIP/2.0
Via: SIP/2.0/UDP;branch=z9hG4bK8EF1AD4
Remote-Party-ID: “Jonathan   Els” <sip:0112223333@mycube.local>;party=calling;screen=no;privacy=off
From: “Jonathan   Els” <sip:0112223333@myitsp.com>;tag=136DF10-11BA
To: <sip:27445556666@>
Date: Thu, 17 Mar 2016 21:33:56 GMT
Call-ID: C98506DB-EBBE11E5-8E03ED66-DEC6DF88@mycube.local
Supported: 100rel,timer,resource-priority,replaces,sdp-anat
Min-SE: 1800
Cisco-Guid: 3380898483-3955102181-2382228838-3737575304
User-Agent: Cisco-SIPGateway/IOS-15.5.2.T
CSeq: 101 INVITE
Timestamp: 1458250436
Contact: <sip:0112223333@mycube.local:5060>
Expires: 180
Allow-Events: kpml, telephone-event
Max-Forwards: 69
Diversion: <sip:27126575370@>;privacy=off;reason=unknown;counter=1;screen=no
Content-Type: application/sdp
Content-Disposition: session;handling=required
Content-Length: 298

o=CiscoSystemsSIP-GW-UserAgent 2555 5070 IN IP4
s=SIP Call
c=IN IP4
t=0 0
m=audio 17336 RTP/AVP 18 8 101
c=IN IP4
a=rtpmap:18 G729/8000
a=fmtp:18 annexb=yes
a=rtpmap:8 PCMA/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15

All that’s remaining is the change from 27XXXXXXXXX to 0XXXXXXXXX for called party information – a simple translation in CUCM can sort that out to keep the sip-profiles clean!



Tagged , , , , , , , , ,

Incorrect SIP Realm – CUBE Not Responding to 401 Unauthorized

Had an issue today where we had to migrate a client as our ITSP migrated the client to a different SBC platforms.  After re-pointing, the SIP Trunk was failing to register.

The sip-ua configuration needed is pretty simple:

credentials username <myusername> password 7 <myencryptedpassword> realm myrealm.com
authentication username <myusername> password 7 <myencryptedpassword> realm myrealm.com
nat symmetric check-media-src
nat symmetric role active
registrar dns:myrealm.com expires 3600
sip-server dns:myrealm.com

So… what do we see?

Firstly, our SIP trunk is down:


So, we made some calls and tried to pick up an error.  The following SIP Ladder showed us a problem:


So, the issue?  CUBE is not re-INVITEing to the ITSP, based on the supplied in the WWW-Authenticate header:

000611: Mar 17 17:11:09.936: //460/3CBC3A000000/SIP/Msg/ccsipDisplayMsg:
SIP/2.0 401 Unauthorized
Via: SIP/2.0/UDP;branch=z9hG4bK12A75C
From: “End User 1” <sip:+27456478349@myrealm.com>;tag=464B7C-1D14
To: <sip:+272347897120@myrealm.com>;tag=gK08bac03c
Call-ID: 14005099-EB9A11E5-81CCED66-DEC6DF88@
CSeq: 101 INVITE
WWW-Authenticate: Digest realm=”sip-2.ITSP_1″,nonce=”f3582aaf8sdf876b596d4f56a”
Content-Length: 0

Oops!  Looks like our ITSP is still busy developing their new platform?  We’re expecting Digest realm=”myrealm.com” but are getting something else!

So, what’s our solution?

Well…  to answer that, we actually need to look at the realm usage, which is well-defined in the appropriate SIP-UA RFC:



On the CUBE, our realm configuration is is actually needed for accommodating Multiple Registrars:


Most specifically, the login applied for Authorization/Authentication is well summed up here:

Determination of Authentication Details
When a SIP INVITE or SIP REGISTER request is challenged, the username and password details for authentication are determined in the following order:

  1. If the realm specified in the challenge matches the realm in the authentication configuration for a POTS dial peer, the system uses the corresponding username and password
  2. If the realm specified in the challenge doesn’t match the configured authentication for the POTS dial peer, then it will check for credentials configured for SIP UA.
  3. If the realm specified in the challenge does not match the realm configured for credentials, then it will check for authentication configurations for SIP UA.
  4. If the system does not find a matching authentication or credential for the received realm, then the request is terminated.
  5. If there is no realm specified for the authentication configuration, then the system uses the username received from the challenge to build the response message

So, in our case, we had a realm mismatch, and since only one realm was applied, and the ITSP didn’t prompt for a username in the challenge, CUBE failed the call.  This is working as designed.

The fix (besides raising this with the ITSP of course!) was to remove the realm config from the SIP User Agent configuration for authentication.  This allowed the CUBE to respond to requests successfully, as it searched the authentication configurations:

credentials username <myusername> password 7 <myencryptedpassword> realm myrealm.com
authentication username <myusername> password 7 <myencryptedpassword>
nat symmetric check-media-src
nat symmetric role active
registrar dns:myrealm.com expires 60
sip-server dns:myrealm.com

After being applied, the trunk immediately registered, and calls were successful.


Tagged , , ,

Implementing Loop Prevention on CUBE

We work quite a lot with a single ITSP in our smaller deployments, but keep hitting a problem with number porting.  We’re repeatedly facing a problem whereby the number porting is done up front, and often in the case of BE6K installations includes numerous number ranges, BRI’s, analog extensions etc.  Often at the time of porting we need to account for 20+ different patterns across 5 or so sites.

The problem crops up when asking for all these ported patterns/ranges in a single list to place on the CUBE.  Quickly it appears that different people requested it, the porting requests were done piecemeal, etc – long story getting all the numbers up front can become a bit tricky.  Not that there is a good reason from it.  It’s a bit of a joke.  But this is what happens.

Come to porting, and we miss a pattern or five.  Now (my favourite part), the upstream provider for our ITSP starts crying because (and wait for it)… we have brought down their network.  They can’t seem to implement loop prevention, and somehow the looping that results from an inbound INVITE only matching the intended outbound dial-peers bombs the providers Media Server – but my little 2RU 2921 stands firm.  I kid you not. 🙂

So, after laughing for about 5min, let’s implement Loop Prevention on our side.  This can be done with COR Lists (vomit), but I prefer to use the newer features in IOS 15.4+, and stick to whats prescribed in the CVD BE6K Edge document.

Here’s the dial plan config that’s pretty much completely scalable – implemented with only 2 dial peers!


voice class uri 1 sip
host ipv4:<cucm-ip-sub-primary>
host ipv4:<cucm-ip-sub-secondary>
voice class uri 2 sip
host ipv4:<itsp-ip>
voice class e164-pattern-map 1
description *** To CUCM ***
e164 <internal-dn-range1>
e164 <internal-dn-range2>
e164 <internal-dn-range3>
voice class e164-pattern-map 2
description *** To ITSP ***
e164 .T
voice class dpg 1
dial-peer 100
voice class dpg 2
dial-peer 200
voice class server-group 1
ipv4 <cucm-ip-sub-primary>
ipv4 <cucm-ip-sub-secondary> pref 1
description *** CUCM ***
voice class server-group 2
ipv4 <itsp-ip>
description *** ITSP ***
dial-peer voice 100 voip
description *** CUCM ***
session protocol sipv2
session server-group 1
destination dpg 2
destination e164-pattern-map 1
incoming uri via 1
voice-class codec 1
dtmf-relay rtp-nte sip-kpml
no vad
dial-peer voice 200 voip
description *** ITSP ***
session protocol sipv2
session server-group 2
destination dpg 1
destination e164-pattern-map 2
incoming uri via 2
voice-class codec 1
voice-class sip bind control source-interface <external-interface>
voice-class sip bind media source-interface <external-interface>
no vad
dtmf-relay rtp-nte sip-kpml


Some Notes:

  • The loop prevention hinges on the face that you exclude dial peers using dial-peer groups.  An absolutely fantastic feature.
  • Outbound destinations are serviced by server groups – another brilliant addition.
  • Inbound matching is done using the URI Enhancements provided in 15.x and up
  • I tend to prefer to localize E.164 in CUCM for a Central Breakout Design.  I just like the extensible nature of Called and Calling Transformations.  I believe that this is more in line with the CVD/SRND – could be debated though.


A possible modification could drop the server groups (the limitation is that these only support IP), and instead route using DNS SRVs.  I like this approach a lot, and try and implement as such whenever possible.

What’s lovely about this is that the skeleton never changes – I get my patterns added to the e164 pattern map, adjust my IP’s and I’m good to go.


Voila!  CUBE implemented in under 5min.  Hope this helps some of you out there.


Tagged , , , , ,

Forcing MTP Killed the Mid-Call

There’s a common misconception with Cisco SIP trunking that the desperate “Forced MTP” will always solve no audio, one-way audio, DTMF inter-working and every other media negotiation failure under the sun. This is unfortunately not always the case.


On a deployment completed quite a while back, we faced a no-audio media issue in 9.1.x (determined to be due to CSCup07303) where I initially raised the white flag due to time constraints and forced the MTP on the SIP Trunk.  The issue arose due to a UCCX re-direct for an after-hours call flow.  Not the topic for discussion here, but just some background information (more on this later).

Fast forward 5 months, and 3 remote sites were deployed for the same system, following a CBO SIP Trunking solution via the Campus site.  After deploying the 3rd site, the client complained that inbound calls were failing and I was asked to investigate.

I reviewed the call flow to find a classic INVITE/UPDATE/Re-INVITE scenario, with CUCM ending the call with a BYE due to a frustrated end user hanging up (Reason: Q.850;cause=16).

The call flow was as follows:

  1. Inbound INVITE (EO)/200 OK/ACK from Service Provider
  2. Re-INVITE(EO – a=inactive)/200 OK/ACK from CUCM>CUBE>SP
    1. i.e Audio Termination
    1. A classic CUCM Delayed Offer MOH media negotiation attempt

Unfortunately at this point the call had already failed, with many SIP messages still to follow (for another day) before the final BYE.

So, what is actually going on here?!?  Let’s look at the SIP Ladder:


The offending message is:

May 27 08:57:04.713: //1396205/8DF8940DA2FF/SIP/Msg/ccsipDisplayMsg:
SIP/2.0 200 OK
Via: SIP/2.0/UDP;branch=z9hG4bK5C8CBBB5
From: <sip:12341234567@>;tag=815B2478-2382
To: <sip:22334455667@>;tag=SDjuthc01-nz5qnrc7wqej3qxa.o
Call-ID: SDjuthc01-780d708b807543c356c407ad79c35b25-a848bn0
CSeq: 101 INVITE
Timestamp: 1432717024
Contact: Anonymous <sip:2345234523@;transport=udp>
Server: Sippy
Portasip-3264-action: answer 2
Content-Length: 245
Content-Type: application/sdp

o=Sippy 2031015826430718550 1 IN IP4
t=0 0
m=audio 62848 RTP/AVP 18 96
c=IN IP4
a=rtpmap:18 G729/8000
a=fmtp:18 annexb=no
a=rtpmap:96 telephone-event/8000

Root cause?

An RFC non-compliant upstream softswitch, sending a=inactive instead of a delayed media offer – in this case not conforming to 14.2 of RFC 3261.

A UAS providing an offer in a 2xx (because the INVITE did not contain an offer) SHOULD construct the offer as if the UAS were making a brand new call, subject to the constraints of sending an offer that updates an existing session, as described in [13] in the case of SDP. Specifically, this means that it SHOULD include as many media formats and media types that the UA is willing to support. The UAS MUST ensure that the session description overlaps with its previous session description in media formats, transports, or other parameters that require support from the peer. This is to avoid the need for the peer to reject the session description. If, however, it is unacceptable to the UAC, the UAC SHOULD generate an answer with a valid session description, and then send a BYE to terminate the session.

I raised a case with the service provider, who simply couldn’t resolve the problem, as the offending device was actually on an upstream inter-connect with another provider.  Chaos ensued explaining this to the client.

Luckily, Cisco has some methods to support this non-compliance – introduce Send sendrecv in Mid-Call INVITE

When Send “sendrecv” in mid call INVITE is enabled, this feature inserts an MTP into the media path between the calling and calling devices, allowing the media connection to be disconnected between the Unified CM device and the MTP, while establishing and maintaining media between the MTP and the held device with a=sendrecv. On call resumption, the MTP is removed from the media path.

Unfortunately, this fix meant I also had to downgrade MOH support to use G729 as well:

This feature addresses the mid-call Delayed Offer INVITE issue for audio direction, but it cannot resolve the issue of a device responding with its last used codec rather than the full list of all supported codecs. This issue can be problematic in cases where a codec change is required on re-establishment of media, such as placing a G.729 call on hold and connecting it to a music on hold source where G711 is preferred.

So.. why am I blaming the forced MTP?

Well, when it’s forced into the call to begin with, yes… it will result in early offer, but its always in the call, and media is therefore always set up and terminated with every mid-call Re-INVITE – via a=inactive SDP.  The end result is that setting Send “sendrecv” in mid call INVITE on the SIP Profile had absolutely no effect – I had to disable MTP on the trunk, set Early Offer from the SIP Profile adn finally set the sendrecv param on the SIP Profile as well.


Tagged , , , , ,
Collaboration Engineer

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

Gerry Keleghan's Blog

A Blog about Cisco Unified Communications


my personal journey to ccie collaboration

Striving for greatness

Thoughts on DevOps, emerging tech, and open source

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


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

Cisco Collab Engineering Tips

Michael White - CCIE #26626


Photography by Manos,


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

The Daily Post

The Art and Craft of Blogging

The WordPress.com Blog

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

%d bloggers like this: