Packet Capture show "Not Acceptable Media" on CUCM Sip Trunk

[dan hale]

Hi All, I have a CUCM SIP trunk that points to a third party Session Border Controller (non-Cisco) and when I send T38 faxes thru it....it always fails.

If I call the number directly I hear the fax tones. Below is the call flow:

PSTN ---> Cisco 3845 (MGCP) CUCM (ver. 9.1.2) SIP Trunk -----> Third party SBC -----> Fax Server

Working with the third party vendor we did a packet capture and it shows (I think) my CUCM giving a "Not Acceptable Media" but, upon further review of the message header...if I'm reading the wireshark packet capture right I now think it may be the SBC and not CUCM sending the message.

I've attached two images one of the call flow and one of the actual message header.

I would appreciate any comments on if I'm reading the packet capture correct.....I sanitized the image but, CUCM is 10.0.XXX.XXX and the SBC is 20X.XXX.XXX.

FYI...if I go directly to the fax server it works!

Thanks,

Dan

[Alok Jaiswal]

From the screenshot it seems that the second invite coming in from the SBC has something which is causing CUCM to send 488 not acceptable media.

Please check the second invite and try to verify what's the difference in 200 OK it has sent previously.

Also if on CUCM you are using a delayed offer try to make it early offer under the sip profile assigned to the SIP trunk towards SBC.

Regards,

Alok

[Mohammed al Baqari]

Hi,

You vendor is correct in saying that cucm is rejecting the call with media not acceptable. 

We need to see the SDP contents in the INVITE message sent from SBC to CUCM. Also, we need to know what is behind CUCM and is it connected to PRI gateway or CUBE. 

CUCM will passthrough T38 fax relay and it might be the gateway behind CUCM rejecting it and CUCM is passing the message back to SBC. 

[dan hale]

Hi Mohammed, attached is the image of the first SDP invite from the SBC to CUCM.

I only have the image of the SDP content that was further down the packet. 20X.XXX.XXX.XXX is the SBC.

There is a PRI gateway behind CUCM...the call flow is:

PSTN ---> Cisco 3845 (MGCP) CUCM (ver. 9.1.2) SIP Trunk -----> Third party SBC -----> Fax Server

Thanks,

Dan

[Mohammed al Baqari]

Thx Dan.

I don't see T38 negotiated in the INVITE (no T38 in SDP content).

Anyway, what is the region configuration between FAX Server and MGCP gateway on CUCM?

Also, please turn on 'debug isdn q931' and 'debug mgcp packet' on the gateway and share the debugs for a test call. 

[dan hale]

Thank you Mohammed....I've never looked at the packet capture for faxing to see if T38 is in there or not. 

Attached is the text file that has the "debug q931" and "debug MGCP packet"

You will see the called number as 69XXXXX

10.0.50.14 is a CUCM subscriber

I've also attached a picture of the region info. Both the CUCM SIP trunk and MGCP gateway in CUCM are using this same gateway region.

Thanks,

Dan

[Mohammed al Baqari]

Hi Dan,

I exported the logs for the specific call to fax. Seems that MGCP T38 switchover is successful and CUCM is failing in completing the fax switchover. 

Can you make a test call and upload traces for last 60 mins?

!!!!! ..... This is the switchover message sent from CUCM to MGCP gateway after receiving T38 INVITE from SBC

.Apr 25 21:23:07.534: MGCP Packet received from 10.0.50.14:2427--->
MDCX 36433524 S0/SU1/DS1-1/6@VoIP--08121-2.nodomain.com MGCP 0.1
C: D00000000abc8a68000000F5800045b9
I: 42D47F
X: 6
L: a:image/t38
M: sendrecv
R: D/[0-9ABCD*#], FXR/t38
S:
Q: process,loop

v=0
o=- 4379775 0 IN EPN S0/SU1/DS1-1/6@VoIP--08121-2.nodomain.com
s=Cisco SDP 0
t=0 0
m=image 63808 udptl t38
c=IN IP4 192.213.32.12
a=X-sqn:0
a=X-cap:1 image udptl t38
<---

!!!... This is the acknowledgement from MGCP gateway to CUCM confirming the switchover

.Apr 25 21:23:07.538: MGCP Packet sent to 10.0.50.14:2427--->
200 36433524 OK

v=0
c=IN IP4 192.168.254.102
m=image 19390 udptl t38
a=X-sqn:0
a=X-cap: 1 audio RTP/AVP 100
a=X-cpar: a=rtpmap:100 X-NSE/8000
a=X-cpar: a=fmtp:100 192-194,200-202
a=X-cap: 2 image udptl t38
<---

[dan hale]

Hi Mohammed, attached are the trace files. I did not take for the last 60min since the files were so big but, for a two minute time frame. I checked my CDR's and the call came in at 8:44:30 PM and disconnected at 8:45:10 PM. The called number was 6940129. I was not sure which CUCM server they would show from since we have several so I attached two of them that I think would show the trace.

Thanks for your help,

Dan

[Mohammed al Baqari]

Hi Dan,

In the previous post, I saw your MGCP gateway completing the switchover to T38 successfully. But based on your earlier ladder diagram, I thought CUCM is terminating the call.

Based on the current trace, I saw MGCP gateway completing the switchover to T38 successfully as well as CUCM and SBC. However, after that SBC sends a BYE message without cause code header. 

I think this is the accurate problem and I don't think the previous diagram which was shared was referenced to the right fax call because its not matching the previous mgcp logs and the ones you provided today. 

I think the SBC needs to be checked on why sending BYE message.

See the call flow below.

[dan hale]

Hi Mohammed, I have a little more info that I attached as images below.

It appears that the packet is getting all the way to the fax server and from what looks like it the fax server is sending back a "no signal" back to the SBC.

It also appears that CUCM when sending the packet to the SBC is sending via T38 and the SBC is also sending a T38 to the fax server.

Based on images would you agree? Have you seen the "no signal" error before?

Thanks,

Dan

[dan hale]

Hi Mohammed, I wanted to send you a follow up. Turns out that there was another Border controller that we needed to route to. The one border controller was doing call control but, there was a second one across the point to point link that was providing Media Resources. There was no IP route to this second border controller.

Once we identified and saw this different IP address in the packet captures we were able to figure out that the call also needed access to that second controller. The reason we did not see it sooner was that the IP address was very similar just one octet off.

Once we added the IP route to the second controller all started working.

Thanks for your help,

Dan

[Mohammed al Baqari]

Also, there was another call flow in the trace where T38 switchover was completed successfully and the call was later terminated by caller as normal call clearing.

See call flow attached

[dan hale]

Hi Mohammed, the other faxes of the previous call flow trace you may have seen may have been from a phone.

See if I call the number from a phone I hear fax tones and I can confirm via CDR's that its taking the correct path thru the SBC. Also if I go program the CUCM SIP trunk to go directly to the Fax Server (not going thru the SBC)  it also works.

Its always failing when going to the third party SBC via a fax machine. What you saw may have been me calling it from my phone.

I've uploaded the debugs, trace file, and PCAP called 6940129. On another note we have a legacy fax server that I have another CUCM SIP trunk that's programmed to go directly to the fax server (no SBC in the middle) that works and when I do a "show voice call summary" thru out the day I see T38 faxes.

Thanks for your help,Dan

[Mohammed al Baqari]

Next I can think about the following:

1. during the call share the output of 'show call activ voice br' and 'show call active fax br'

2. perform a packet capture on the router (if your IOS version support capture feature) to see if encapsulated udp is passing through or not. With this option we need to have a debug in parallel to get the udp port number negotiated during the call setup.