cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
890
Views
0
Helpful
18
Replies
Beginner

SIP Trunk problems with CME

Hello! I have some problems with SIP Trunk when I call to local city numbers from cisco 3905 7821 sip phones. I attached sip debug. Please help me!

Everyone's tags (1)
18 REPLIES 18
Cisco Employee

We see the following in the

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:1198@10.31.255.1>;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.

Manish

Beginner

Hi, Manish!

Hi, Manish!

Thank you for reply. 9 is access code. When we call to local city numbers from internal numbers, we dial 9 and XXXXXX numbers. 

Cisco Employee

But the calling or called

But the calling or called number should not show up as 9XXXXXX in the SIP messages, it should be the actual number. Manish
Beginner

We have this topology: cisco

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:
Received:
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:1198@10.31.255.1>;tag=b07d47d12f69000d0a6b21a9-212b717b
To: <sip:9XXXXXX@10.31.255.1>

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:
Sent:
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
To: <sip:XXXXXX@172.18.5.1>

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. 

Cisco Employee

can you please share the

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

Br, Nadeem Please rate all useful post.
Beginner

HI Nadim!

HI Nadeem!

Thank you for reply. Calls fom all sccp phones on this cme works fine. This problem has only sip 3905 and sip 7821 phones. I attached debug of suucessfully call from sccp phone. What do you think about PRACK messages ? 

Engager

Hi,

Hi,

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.

- Vivek

Beginner

HI Vivek!

HI Vivek!

Thank you for reply. Calls fom all sccp phones on this cme works fine. This problem has only sip 3908 and sip 7821 phones. I attached debug of suucessfully call from sccp phone.

Engager

One probable reason why it is

One probable reason why it is working with SCCP phone is because if SDP answer in 180 Ringing is invalid (because of incorrect o-line), CME can ignore this message and no further action is to be taken on SCCP leg, however in the case of SIP phone, CME needs to decode the SDP answer in 180 Ringing and send it to the calling phone but since SDP body is invalid and can not send invalid SDP body to calling phone, it drops the call by sending 500 internal error to calling phone. I am not 100% sure what is happening inside but you would like to disable 100rel and see if it makes any difference.
Beginner

On CME 100rel disabled with

On CME 100rel disabled with this command:

voice service voip

sip

rel1xx disable

I attached debug of call with disabled 100rel.

Engager

Hi,

Hi,

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.

- Vivek

Beginner

Hi, Vivek!

Hi, Vivek!

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 ?

Engager

You should show the following

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.

- Vivek

Highlighted
Beginner

Hi, Vivek!

Hi, Vivek!

I analyzed debug ccsip error and i found this on cme before sending 500 error:

//330941/6D8E53800000/SIP/Error/sipSPIAddPrivacyHeader:
 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!

CreatePlease to create content
Content for Community-Ad
August's Community Spotlight Awards