cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
1660
Views
5
Helpful
6
Replies

SIP trunk on CUCM 7 - T.38 Issues

dsalamanca
Level 1
Level 1

hello,

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

6 Replies 6

Chris Deren
Hall of Fame
Hall of Fame

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

Chris

Hello Chris,

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

Regards,

Daniel

Hi,

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.

Thanks,
Murali

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.

Regards,

Hi,

Are you sure,  it worked before with T38, as ATA186 doesn't support T38 or cisco fax relay. It only supports fax passthrough. You may have to use passthrough if you have ATA 186.

http://www.cisco.com/en/US/products/hw/gatecont/ps514/products_qanda_item09186a00800946e1.shtml

Thanks,

Murali

Hello,

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!

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: