Lately I saw this issue appear in many of the SIP Trunk that been provided by some of the ITSP Vendor and let’s not mention any name here I just started to blog ;D
I also face this problem in my site where I can make call to land line, National and international but not a mobile number which appear recently.
The first step is to identify if the calling and called numbers appear to the ITSP in a correct way that lead to a successful call The command is debug voice ccapi inout
In our case the calling and called number was correct so we had to go for the nest step
so the next command is to trace the SIP message in the router and the best command is debug ccsip messages
And it result That the Initial Invite is sent to ITSP SIP-TRUNK with no SDP inside it. you get Back a 183 session in Progress with unsupported ptime in the SDP
So The Issue is that I’m sending the INVITE from the call manager (192.168.200.53) with a delayed offer and CUBE forward it to ITSP with the same ( delayed offer no sdp included ) , then 183 session in progress is sent back which start negotiating the codec ( G711 A law is taking Priority in the offer ) but when the 183 reach the CUCM back it send 500 Internal error
Most ITSP I’ve come across requires SIP early offer. They use this to always decide on which codec to offer for the calls.
In an Early Offer, the session initiator (calling device) sends its capabilities (for example, codecs supported) in the SDP contained in the initial Invite (thus allowing the called device to choose its preferred codec for the session).
In a Delayed Offer, the session initiator does not send its capabilities in the initial Invite but waits for the called device to send its capabilities first (for example, the list of codecs supported by the called device, thus allowing the calling device to choose the codec to be used for the session).
In normal Setup, ISP forwards SDP messages to client with DTMF instruction so, I can ask My ISP about it, or force the answer by sending My information on My invite.