Background of Issue:

 A TV station reported SIP calls used for IFBs were dropping after 15 minutes.  The LQ at this TV station connects to a remote SIP server. The customer’s troubleshooting results point some data being dropped by the firewall.

Troubleshooting Results from the customer:

The MTP Change I made yesterday afternoon did fix the issue.  But not in a way I was expecting and to ClearCom’s point it is the network, but in an unexpected way.

• With the MTP Off, the Call Manager relays the Mid-call Re-INVITE to the Voice Gateway as it should.  But that Re-INVITE isn’t getting to the VG as expected, even though the rest of the Signaling does.

• With the MTP On, I  can see that the Call Manager relays the Mid-call Re-INVITE to the Voice Gateway and that Re-INVITE is received.

• I can also see  that the contents of the SIP message changes between examples, because with the MTP on, the UCM acts as an intermediary between the Voice Gateway and the LQ device.  In this capacity the MTP is acting as a signaling transcoder.

• At the network Layer, Source and Destination IP addressing between the UCM and the Voice Gateway are the same in both examples, only the Payload changes.  The only thing in the network that can block traffic at this level is Application Layer inspection on the firewall.  (Sorry Zach…)

 So the conclusion is:

• When the payload in the SIP message is generated by the LQ, Application Inspection is rejecting the Mid-call Re-INVITE and the call drops when the UCM attempts to refresh the session at half the Min-SE timer (15 Minutes).

• When the payload in the SIP message is generated by the UCM acting as an intermediary, Application Inspection is Ok with the payload contents and does not block the  traffic, allowing UCM to refresh the session and  the call does not drop.

 Choices for a permanent fix:

• The Easy: Enable MTP for all calls on the UCM Configuration of the LQ.

  • This will be a little more resource intensive on the Call Managers.

  • It will force the Audio on these calls to traverse the WAN from WTVT to TVHO and back again for every call.  Meaning a WAN outage during a show will cause a loss of audio on all IFB calls on the LQ.

• The More Difficult: Leave the MTP Off and have the Fox TV Network Team investigate the path for Application Layer inspection and either Disable or put in an exception for this traffic.

  • This would reduce utilization on the UCMs

  • This should eliminate the need to have the audio traverse the WAN lowering that risk to your broadcasts.

  • This may not entirely eliminate issues since this is still an EO-DO call and we may still need to implement an MTP to support the call, but we can cross that bridge if we come to it with a local HW solution.

This packet is being blocked at Layer 5.