Category Archives: IOS Media Resources

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 , , , , , , , , , , , ,

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 , , , , ,

DTMF Interworking and the MTP

I came across this a while back when deep diving MTP when preparing for the lab.  I’ve pretty much got it down now, but I keep coming back to it as a reference point.

I really struggled a lot with this at the CCNP level.  Not sure about MTPs conceptually?  Look no further!

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 Blog

The latest news on and the WordPress community.