SIP trunk on CUCM 7 - T.38 Issues

Unanswered Question
Apr 20th, 2012
User Badges:


We have a SIP trunk going from our CUCM to a SIP provider, the faxes are being sent right but we cannot receive faxes.

Capturing traffic I see that the provider sends some INVITE messages correctly, but in the last one always the CUCM answers with a 488 message "Not acceptable Media" as you can see in the attachment.

Is there anything that I can change in the configuration to avoid this problem? I thought that T.38 would work by default on a SIP trunk.

Any help will be appreciated.

Thanks in advance

  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 5 (1 ratings)
Chris Deren Fri, 04/20/2012 - 06:11
User Badges:
  • Super Silver, 17500 points or more
  • Hall of Fame,
  • Cisco Designated VIP,

    2017 IP Telephony, Contact Center, Unified Communications

What is your topology, is there a CUBE here?  If so can you post the config of your CUBE?


dsalamanca Sun, 04/22/2012 - 08:29
User Badges:

Hello Chris,

There is no CUBE here, the CUCM trunk points to the provider's device directly



marmugam Sun, 04/22/2012 - 17:37
User Badges:
  • Cisco Employee,


I got one side of call-leg from your description, but what is complete e2e call flow?

Sonus----SIP---CCM-----???????------Fax machine

++ From the packet capture it looks like protocol based T38, but We dont support protocol based t38 in SCCP, only NSE based T38  swicthover is supported in sccp. If by anyhance CCM is talking sccp to far end device  which is connected to fax machine, then you would see 488 media error. 

++ Or other suspect is MTP invoked in the call flow, which is not configured for codec passthrough.

Please check the above  two possibilities, if not please collect the detailed CCM traces with the calling details and pass it to us.


dsalamanca Mon, 04/23/2012 - 03:26
User Badges:

On the other side there is an ATA 186 connected.

I will get some traces from the CUCM side, but curiously it was working perfectly for some time and suddenly stopped.


dsalamanca Tue, 04/24/2012 - 00:49
User Badges:


The problem is solved "by itself", but I see that something changed from the operator side. I think that they changed something and they rolled back now and is working again so it was not a problem on the Cisco network side.

Thank you for the ATA information, will be useful for future troubleshooting!


This Discussion