We see the following in the incoming 180 ringing messages
From: "Test" <sip:YYYYZZZZZZ@172.19.0.2>;tag=BB093E40-2045 To: <sip:XXXXXX@172.18.5.1>;tag=1691575197-1455790561828
followed by a 500 internal server error
Feb 18 16:16:03.852: //245306/72966EEF81A1/SIP/Msg/ccsipDisplayMsg: Sent: SIP/2.0 500 Internal Server Error Via: SIP/2.0/UDP 10.157.3.132:5060;branch=z9hG4bK3d75bb22 From: "Test" <sip:firstname.lastname@example.org>;tag=b07d47d12f69000d0a6b21a9-212b717b To: <sip:9XXXXXX@10.31.255.1>;tag=BB0941CA-2316
Most likely the issue is caused by this 9XXXXXX@10.31.255.1
Can you check the call flow and see where this number is coming from and if this can be corrected.
We have this topology: cisco sip phone ---- CME -- sip trunk ---- ITSP
In this section phone dial number 9XXXXXX and cme received INVITE from sip phone:
Feb 18 16:16:02.573: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:
INVITE sip:9XXXXXX@10.31.255.1;user=phone SIP/2.0
Via: SIP/2.0/UDP 10.157.3.132:5060;branch=z9hG4bK3d75bb22
From: "Test" <sip:email@example.com>;tag=b07d47d12f69000d0a6b21a9-212b717b
In this section CME cut acccess code 9 and send INVITE to ITSP with number XXXXXX:
Feb 18 16:16:02.575: //245307/72966EEF81A1/SIP/Msg/ccsipDisplayMsg:
INVITE sip:XXXXXX@172.18.5.1:5060 SIP/2.0
Via: SIP/2.0/UDP 172.19.0.2:5060;branch=z9hG4bK2C6DA21D2
Remote-Party-ID: "Test" <sip:YYYYZZZZZZ@172.19.0.2>;party=calling;screen=yes;privacy=off
From: "Test" <sip:YYYYZZZZZZ@172.19.0.2>;tag=BB093E40-2045
I think sip phone must reply with PRACK to CME for 183 Session Progress. But phone did not send. Therefore CME reply with 500 error. This is my own opinion.
can you please share the complete debug log of fail call.
debug voice ccapi inout
debug ccsip message
debug ccsip events
debug ccsip error
try disabling the authentication on ip trust list and see the behavior.
#voice service voip
#no ip address trusted authenticate
Your provider is first sending SDP answer in 183 Session Progress with following o-line;
o=BroadWorks 5034711447 1 IN IP4 172.18.5.1
Later on, CME again receives SDP answer in 180 Ringing and there, o-line is as follows;
o=BroadWorks 5034712083 1 IN IP4 172.18.5.1
In my opinion, SDP body should not change in re-transmitted SDP answer and that might be the cause why CME is dropping a call. You should check it once with your provider.
Hmm, so result is same. Once gateway receives 180 Ringing, its sending 500 error to calling phone.
I can only think of o-line error received in 180 Ringing SDP body. If you have a choice, will suggest you to check with provider once why they are sending different o-line in 180 SDP.
Service provider said that is normal because this is session number. I think if problem is o line, why cme answer with PRACK to 180 Ringing and then send 500 error ?
You should show the following excerpt from RFC 3264 to them;
If the version in the origin line does not increment, the SDP MUST be identical to the SDP with that version number.
So in our case when we receive 183 Session Progress, session version number is 1. When we get 180 Ringing, session version is still 1 but session id has been changed under o-line. This means SDP is not identical now with respect to previous SDP and in my opinion, this violets the RFC which says that if version number is same, the SDP must be identical.
Other point you can see that o-line is same in 183 Session Progress and 200 OK SDP, means both SDP's are identical, but 180 Ringing SDP is different. This again gives me a strong feeling that issue is with 180 Ringing SDP.
Regarding your other question, then why PRACK is sent. This might be cause in SIP, if you don't like any header in the message and can not proceed with the call, you eventually complete the transaction before dropping the call. For example, when INVITE is being sent and received 200 OK where there is some issue with SDP content, you will drop the call by sending BYE but only after sending ACK.
You can wait if someone else on forum would like to comment or in case of urgency, you would like to check with TAC.
I analyzed debug ccsip error and i found this on cme before sending 500 error:
Orig Container is NULL...should have value except in case of sending OOD Options ping.
What is it mean ? Problem is origin line ? I must demonstrate to ITSP that problem is origin line. Thank you!