04-20-2012 05:03 AM - edited 03-16-2019 10:44 AM
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
04-20-2012 06:11 AM
What is your topology, is there a CUBE here? If so can you post the config of your CUBE?
Chris
04-22-2012 08:29 AM
Hello Chris,
There is no CUBE here, the CUCM trunk points to the provider's device directly
Regards,
Daniel
04-22-2012 05:37 PM
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
04-23-2012 03:26 AM
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,
04-23-2012 09:11 AM
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
04-24-2012 12:49 AM
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!
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: