Intermittent SIP/2.0 488 Not Acceptable Media in response to re-invites when Early Offer is used.

[Tristan Cober]

So we have a situation where we have a 3rd party IP PBX integrated with CUCM via a SIP trunk. The IP PBX has it own Voice Mail system it uses, so calls from phones registered to call manager to phones on the IP PBX will reach the Voice Mail that is integrated with the IP PBX.

We were having Ringback and MoH issues to phones on the IP PBX during transfers that were only fixed by setting MTP Required on the SIP Trunk to the IP PBX (we have no control over the IP PBX).

Enter our issue with experiencing 488 Not Acceptable Media in response to Re-Invites (w/ SDP) when the IP PBX sends CUCM a Re-Invite to transfer to the Voice Mail system integrated with the IP PBX. Previously when we had Early Offer (best effort, no MTP) we were also experiencing this 488 Not Acceptable Media issue.

The most confusing part of this whole ordeal is that it is not 100% of the time, but at best estimates around half of the Re-Invites to the Voice Mail on the IP PBX will be rejected with a 488 Not Acceptable Media. The best part? Call flow, MTP used, SDP content, Calling/Called numbers, all are completely the same in calls that work versus calls that don't work. Infact, it would appear that nothing in the Re-Invite (w/ SDP) itself is what is inherently the cause of the problem. Even more confusing is that inbound calls from the PSTN that traverse CUCM never experience this issue; only phones registered to CUCM experience the problems with Re-Invites.

I am having great difficulty making any useful headway out of the traces we have taken, and the SDL traces are extremely cryptic and not very telling as to what the issue may or may not be. I have attached the portion of the Trace containing the failed call in hope that someone can point out where CUCM seems to decide on a whim to send the 488 Not Acceptable Media response.

I currently have a TAC case open on this issue as well, however nothing definitive has yet come up.

[Mohammed al Baqari]

Hi,

'488 Not Acceptable Media response' indicates that both systems are having a codec mismatch. Could be that you have a transcoder and when there are available sessions in the transcoder calls are working. When the transcoder sessions are fully occupied, calls are failing.

Start with checking the codec config on your CUCM and IP PBX. Also, during an active working call, share the output of show sccp conn from your gateway.

[Tristan Cober]

Hi,

Thanks for taking the time to respond. In this case there is no Xcoder being used as everything is set to G711 across the trunk in this case. There is no gateway involved in the integration as it is a direct SIP Trunk from CUCM to the IP PBX, so the only traces I can provide are from CUCM.

Nothing appears wrong in the SDPs being exchanged or the Contacts, and a check of MTP usage shows there to be plenty of resources left.

If this were a usual 488 error, it probably wouldn't be giving TAC the runaround for 2+ weeks :(

[Dennis Mink]

Mohammed, FYI "488 Not acceptable media" is NOT restricted to a codec mismatch, it can also indicate a location bandwidth issue. I know this from experience

[Tristan Cober]

Well, I knew I wasn't crazy (or at least I keep telling myself that). Looks like the version of Call Manager we are using has run into a bug. Took plenty of searching until the right keywords clicked.

Unfortunately the workarounds are a bitter pill to swallow, so I will need to have a chat with the IP PBX provider to get the Delayed Offer working fully.

SIP Trunk with Early Media may respond 488 to quick mid-call invite

CSCur60158

Description

Symptom:
During an outbound call via SIP trunk with early media, if cucm receives a mid-call INVITE immediately after receiving the 200 OK. CUCM may reject the mid-call INVITE by 488 Not Acceptable Media

If CUCM has sent out Ack for one dialogue it should handle the upcoming SIP messages.

Conditions:
Issue found in CUCM 9.1.2.12900-11

When making outbound call through SIP trunk with early media, this issue may be triggered.
Issue not seen with DO trunk.

Workaround:
Use delay offer to make the call

Further Problem Description:
If CUCM has sent out Ack for one dialogue it should handle the upcoming SIP messages.
If not in right state it should queue it. 
For particular to this scenario it should queue the signal till SIPCdpc receives the CcSetupCompReq and move to active state.

Known Affected Releases:

(6)

10.0(1.10000.24)

10.5(1.10000.7)

10.5(2.10000.5)

8.6(2.10000.30)

9.1(1.10000.11)

9.1(2.10000.28)