Solved: SIP calls Get Disconnected after First RING!!!!!!!!!!

danny itza · ‎03-26-2013

Hi all,

I have been trying to make SIP calls from my Cisco 5300 RTR terminate to my ISP ( TATA) but still can’t get it to work call are getting disconnected after first Ring. Below are the equipment Involve.

E0 SIP Trunk

Nortel Switch ----------------->cisco 5300 RTR -------------------------> ISP

I see all calls hitting the dial-peer 4007 pots, and then hitting the dial-peer voice 4003 voip (test number is 912067343134). When I do a SIP TRACE using “debug ccsip messages” I see that my ISP is requesting “Require: timer”, like if the CALL setup Timer Expired . I increase the timer setup under “Sip” and set it to “min-se 48000” but still calls are being disconnected. I already checked my ISP and they are saying that the call is being disconnected on my side, and that they are using “codec g729r8”. I have the codec set to G729r8 on my side. Blow is the Sip Trace I did and attached are my configuration, debug ccsip all and debug voip ccapi inout.

Any Help and explanation of what is happening is Highly Appreciated and Thanks in advance for your assistance.

Call TRACE

BZE-AGGR-RAS03#

Mar 26 15:23:22.757:

Sent:

INVITE sip:912067343134@66.198.40.9:5060 SIP/2.0

Via: SIP/2.0/UDP 200.32.250.52:5060

From: <sip:200.32.250.52>;tag=186C4910-308

To: <sip:912067343134@66.198.40.9>

Date: Tue, 26 Mar 2013 15:23:22 GMT

Call-ID: EE538216-955F11E2-8F58AB8F-15D318CD@200.32.250.52

Supported: timer

Require: 100rel

Min-SE: 1800

Cisco-Guid: 3998290142-2506035682-2404756367-366155981

User-Agent: Cisco-SIPGateway/IOS-12.x

Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, COMET, REFER, SUBSCRIBE, NOTIFY, INFO

CSeq: 101 INVITE

Max-Forwards: 6

Remote-Party-ID: <sip:200.32.250.52>;party=calling;screen=no;privacy=off

Timestamp: 1364311402

Contact: <sip:200.32.250.52:5060>

Expires: 180

Allow-Events: telephone-event

Content-Type: application/sdp

Content-Length: 297

v=0

o=CiscoSystemsSIP-GW-UserAgent 6376 5818 IN IP4 200.32.250.52

s=SIP Call

c=IN IP4 200.32.250.52

t=0 0

m=audio 17266 RTP/AVP 18 101 19

c=IN IP4 200.32.250.52

a=rtpmap:18 G729/8000

a=fmtp:18 annexb=no

a=rtpmap:101 telephone-event/8000

a=fmtp:101 0-16

a=rtpmap:19 CN/8000

a=ptime:20

Mar 26 15:23:22.813:

Received:

SIP/2.0 100 Trying

Via: SIP/2.0/UDP 200.32.250.52:5060

From: <sip:200.32.250.52>;tag=186C4910-308

To: <sip:912067343134@66.198.40.9>;tag=gK02b8326a

Call-ID: EE538216-955F11E2-8F58AB8F-15D318CD@200.32.250.52

CSeq: 101 INVITE

Timestamp: 1364311402

Content-Length: 0

Mar 26 15:23:23.653:

Received:

SIP/2.0 180 Ringing

Via: SIP/2.0/UDP 200.32.250.52:5060

From: <sip:200.32.250.52>;tag=186C4910-308

To: <sip:912067343134@66.198.40.9>;tag=gK02b8326a

Call-ID: EE538216-955F11E2-8F58AB8F-15D318CD@200.32.250.52

CSeq: 101 INVITE

Contact: <sip:912067343134@66.198.40.9:5060>

Allow: INVITE,ACK,CANCEL,BYE,REGISTER,REFER,INFO,SUBSCRIBE,NOTIFY,PRACK,UPDATE,OPTIONS

Require: 100rel

RSeq: 30141

Content-Length: 254

Content-Disposition: session; handling=required

Content-Type: application/sdp

v=0

o=Sonus_UAC 8605 9205 IN IP4 66.198.40.9

s=SIP Media Capabilities

c=IN IP4 66.198.40.7

t=0 0

m=audio 9928 RTP/AVP 18 101

a=rtpmap:18 G729/8000

a=fmtp:18 annexb=no

a=rtpmap:101 telephone-event/8000

a=fmtp:101 0-15

a=sendrecv

a=maxptime:20

Mar 26 15:23:23.665:

Sent:

PRACK sip:912067343134@66.198.40.9:5060 SIP/2.0

Via: SIP/2.0/UDP 200.32.250.52:5060

From: <sip:200.32.250.52>;tag=186C4910-308

To: <sip:912067343134@66.198.40.9>;tag=gK02b8326a

Date: Tue, 26 Mar 2013 15:23:22 GMT

Call-ID: EE538216-955F11E2-8F58AB8F-15D318CD@200.32.250.52

CSeq: 102 PRACK

RAck: 30141 101 INVITE

Content-Length: 0

Mar 26 15:23:23.721:

Received:

SIP/2.0 200 OK

Via: SIP/2.0/UDP 200.32.250.52:5060

From: <sip:200.32.250.52>;tag=186C4910-308

To: <sip:912067343134@66.198.40.9>;tag=gK02b8326a

Call-ID: EE538216-955F11E2-8F58AB8F-15D318CD@200.32.250.52

CSeq: 102 PRACK

Content-Length: 0

Mar 26 15:23:29.761:

Received:

SIP/2.0 200 OK

Via: SIP/2.0/UDP 200.32.250.52:5060

From: <sip:200.32.250.52>;tag=186C4910-308

To: <sip:912067343134@66.198.40.9>;tag=gK02b8326a

Call-ID: EE538216-955F11E2-8F58AB8F-15D318CD@200.32.250.52

CSeq: 101 INVITE

Accept: application/sdp, application/isup, application/dtmf, application/dtmf-relay, multipart/mixed

Contact: <sip:912067343134@66.198.40.9:5060>

Allow: INVITE,ACK,CANCEL,BYE,REGISTER,REFER,INFO,SUBSCRIBE,NOTIFY,PRACK,UPDATE,OPTIONS

Require: timer

Supported: timer,replaces

Session-Expires: 1800;refresher=uac

Content-Length: 0

Mar 26 15:23:29.769:

Sent:

ACK sip:912067343134@66.198.40.9:5060 SIP/2.0

Via: SIP/2.0/UDP 200.32.250.52:5060

From: <sip:200.32.250.52>;tag=186C4910-308

To: <sip:912067343134@66.198.40.9>;tag=gK02b8326a

Date: Tue, 26 Mar 2013 15:23:22 GMT

Call-ID: EE538216-955F11E2-8F58AB8F-15D318CD@200.32.250.52

Max-Forwards: 6

Content-Length: 0

CSeq: 101 ACK

Mar 26 15:23:29.773:

Sent:

BYE sip:912067343134@66.198.40.9:5060 SIP/2.0

Via: SIP/2.0/UDP 200.32.250.52:5060

From: <sip:200.32.250.52>;tag=186C4910-308

To: <sip:912067343134@66.198.40.9>;tag=gK02b8326a

Date: Tue, 26 Mar 2013 15:23:22 GMT

Call-ID: EE538216-955F11E2-8F58AB8F-15D318CD@200.32.250.52

User-Agent: Cisco-SIPGateway/IOS-12.x

Max-Forwards: 6

Timestamp: 1364311409

CSeq: 103 BYE

Content-Length: 0

Mar 26 15:23:29.837:

Received:

SIP/2.0 200 OK

Via: SIP/2.0/UDP 200.32.250.52:5060

From: <sip:200.32.250.52>;tag=186C4910-308

To: <sip:912067343134@66.198.40.9>;tag=gK02b8326a

Call-ID: EE538216-955F11E2-8F58AB8F-15D318CD@200.32.250.52

CSeq: 103 BYE

Content-Length: 0

Regards,

Danny

Ayodeji Okanlawon · ‎03-26-2013

From this logs now we see that the issue is with your provider..

We get a 180 ringing at 23:59:52...

Mar 26 23:59:52.431: Received:

SIP/2.0 180 Ringing

The gateway didnt get a 200 OK and after 20 sec the call was terminated

Mar 27 00:00:12.435: Sent:

CANCEL sip:912067343134@66.198.40.9:5060 SIP/2.0

You need to go back to your ITSP and find out whats going on..Why are they not sending a 200 OK response to our INVITE.

Please rate all useful posts

"opportunity is a haughty goddess who waste no time with those who are unprepared"

Please rate all useful posts

View solution in original post

Ayodeji Okanlawon · ‎03-26-2013

On another note, I will suggest you enable PRACK again. It looks as if they want PRACK before they send a 200 OK.

Please rate all useful posts

"opportunity is a haughty goddess who waste no time with those who are unprepared"

Please rate all useful posts

View solution in original post

Ayodeji Okanlawon · ‎03-27-2013

Danny,

I am glad to have helped. So cals are working without PRACK?

Please rate all useful posts

"opportunity is a haughty goddess who waste no time with those who are unprepared"

Please rate all useful posts

View solution in original post

Ayodeji Okanlawon · ‎03-26-2013

Danny,

Yes its yoiur gateway that is sending the BYE immediately after receiving the 200 OK from the provider. It looks like your gateway expects some SDP in the 200 okay, but your provider is already sending SDP in 180 ringing.

You can try and disable PRACK and lets see if your ITSP will send media in 200 OK. According to the RFC the only time when the SDP attributes in 180/183 response differ to 200 OK is only when you use PRACK. SO if you disable PRACK and your ITSP doesnt send SDP in 200 OK exactly as is in 180 ringing, then theier implementation is illegal..

Please rate all useful posts

"opportunity is a haughty goddess who waste no time with those who are unprepared"

Please rate all useful posts

danny itza · ‎03-26-2013

Hi Aokanlawon,

thanks for the Quik Response, can you please tell me what commands I use to disable the "PRACK" on my Router????

I'l wait for your reply...

Ayodeji Okanlawon · ‎03-26-2013

voice service voip

sip

no rel1xx require "100rel"

Test again and send debug cccsip messages

Please rate all useful posts

"opportunity is a haughty goddess who waste no time with those who are unprepared"

Please rate all useful posts

danny itza · ‎03-26-2013

Hi Aokanlawon,

I disable the " PRACK" using ( no rel1xx require "100rel") and made a TEST calls but still the calls are Disconencted.. Below is the debug cccsip messages I obtained.

SIP Call messages tracing is enabled
BZE-AGGR-RAS03#
BZE-AGGR-RAS03#
BZE-AGGR-RAS03#
Mar 26 23:59:51.595: Sent:
INVITE sip:912067343134@66.198.40.9:5060 SIP/2.0
Via: SIP/2.0/UDP 200.32.250.52:5060
From: <200.32.250.52>;tag=1A45215C-2131
To: <912067343134>
Date: Tue, 26 Mar 2013 23:59:51 GMT
Call-ID: 151B99C4-95A811E2-AE7DAB8F-15D318CD@200.32.250.52
Supported: timer,100rel
Min-SE: 48000
Cisco-Guid: 354130372-2510819810-2927340431-366155981
User-Agent: Cisco-SIPGateway/IOS-12.x
Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, COMET, REFER, SUBSCRIBE, NOTIFY, INFO
CSeq: 101 INVITE
Max-Forwards: 6
Remote-Party-ID: <200.32.250.52>;party=calling;screen=no;privacy=off
Timestamp: 1364342391
Contact: <200.32.250.52:5060>
Expires: 180
Allow-Events: telephone-event
Content-Type: application/sdp
Content-Length: 272

v=0
o=CiscoSystemsSIP-GW-UserAgent 756 3351 IN IP4 200.32.250.52
s=SIP Call
c=IN IP4 200.32.250.52
t=0 0
m=audio 18520 RTP/AVP 18 101
c=IN IP4 200.32.250.52
a=rtpmap:18 G729/8000
a=fmtp:18 annexb=no
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=ptime:20

Mar 26 23:59:51.651: Received:
SIP/2.0 100 Trying
Via: SIP/2.0/UDP 200.32.250.52:5060
From: <200.32.250.52>;tag=1A45215C-2131
To: <912067343134>;tag=gK0eccc9d0
Call-ID: 151B99C4-95A811E2-AE7DAB8F-15D318CD@200.32.250.52
CSeq: 101 INVITE
Timestamp: 1364342391
Content-Length: 0

Mar 26 23:59:52.431: Received:
SIP/2.0 180 Ringing
Via: SIP/2.0/UDP 200.32.250.52:5060
From: <200.32.250.52>;tag=1A45215C-2131
To: <912067343134>;tag=gK0eccc9d0
Call-ID: 151B99C4-95A811E2-AE7DAB8F-15D318CD@200.32.250.52
CSeq: 101 INVITE
Contact: <912067343134>
Allow: INVITE,ACK,CANCEL,BYE,REGISTER,REFER,INFO,SUBSCRIBE,NOTIFY,PRACK,UPDATE,OPTIONS
Content-Length: 257
Content-Disposition: session; handling=required
Content-Type: application/sdp

v=0
o=Sonus_UAC 26164 19598 IN IP4 66.198.40.9
s=SIP Media Capabilities
c=IN IP4 66.198.40.6
t=0 0
m=audio 20086 RTP/AVP 18 101
a=rtpmap:18 G729/8000
a=fmtp:18 annexb=no
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
a=sendrecv
a=maxptime:20

Mar 27 00:00:12.435: Sent:
CANCEL sip:912067343134@66.198.40.9:5060 SIP/2.0
Via: SIP/2.0/UDP 200.32.250.52:5060
From: <200.32.250.52>;tag=1A45215C-2131
To: <912067343134>
Date: Tue, 26 Mar 2013 23:59:51 GMT
Call-ID: 151B99C4-95A811E2-AE7DAB8F-15D318CD@200.32.250.52
CSeq: 101 CANCEL
Max-Forwards: 6
Timestamp: 1364342412
Content-Length: 0

Mar 27 00:00:12.491: Received:
SIP/2.0 200 OK
Via: SIP/2.0/UDP 200.32.250.52:5060
From: <200.32.250.52>;tag=1A45215C-2131
To: <912067343134>;tag=gK0eccc9d0
Call-ID: 151B99C4-95A811E2-AE7DAB8F-15D318CD@200.32.250.52
CSeq: 101 CANCEL
Content-Length: 0

Mar 27 00:00:12.507: Received:
SIP/2.0 487 Request Terminated
Via: SIP/2.0/UDP 200.32.250.52:5060
From: <200.32.250.52>;tag=1A45215C-2131
To: <912067343134>;tag=gK0eccc9d0
Call-ID: 151B99C4-95A811E2-AE7DAB8F-15D318CD@200.32.250.52
CSeq: 101 INVITE
Content-Length: 0

Mar 27 00:00:12.511: Sent:
ACK sip:912067343134@66.198.40.9:5060 SIP/2.0
Via: SIP/2.0/UDP 200.32.250.52:5060
From: <200.32.250.52>;tag=1A45215C-2131
To: <912067343134>;tag=gK0eccc9d0
Date: Tue, 26 Mar 2013 23:59:51 GMT
Call-ID: 151B99C4-95A811E2-AE7DAB8F-15D318CD@200.32.250.52
Max-Forwards: 6
Content-Length: 0
CSeq: 101 ACK

Ayodeji Okanlawon · ‎03-26-2013

From this logs now we see that the issue is with your provider..

We get a 180 ringing at 23:59:52...

Mar 26 23:59:52.431: Received:

SIP/2.0 180 Ringing

The gateway didnt get a 200 OK and after 20 sec the call was terminated

Mar 27 00:00:12.435: Sent:

CANCEL sip:912067343134@66.198.40.9:5060 SIP/2.0

You need to go back to your ITSP and find out whats going on..Why are they not sending a 200 OK response to our INVITE.

Please rate all useful posts

"opportunity is a haughty goddess who waste no time with those who are unprepared"

Please rate all useful posts

Ayodeji Okanlawon · ‎03-26-2013

On another note, I will suggest you enable PRACK again. It looks as if they want PRACK before they send a 200 OK.

Please rate all useful posts

"opportunity is a haughty goddess who waste no time with those who are unprepared"

Please rate all useful posts

danny itza · ‎03-27-2013

Hi Aokanlawon,

Finally the calls are Terminating succesfully. It had to do with the "PRACK" as you mensioned earlier. I called the ITSP at fisrt they were requesting the "PRACK" but then they disable that option on thier end,and they Never Informed me, I went and disabled the Option on my side and the calls Terminating Succesfully, I think the ITSP did more changes on thier side becasue I have the same configuration, I was Using when I started the TEST..........

You Help me ALOT in Identifying the Problem ..thanks for evreything ,,Wish you the BEST......take care..

Danny

Ayodeji Okanlawon · ‎03-27-2013

Danny,

I am glad to have helped. So cals are working without PRACK?

Please rate all useful posts

"opportunity is a haughty goddess who waste no time with those who are unprepared"

Please rate all useful posts

danny itza · ‎03-28-2013

Hi Aokanlawon,

Yes, calls are working without "PRACK"

Below is the configuration I used but I am sure the ITSP did some changes on thier side, becuase this is the same Configuration I was using when we started the SIP Trunk connectionit never work and then I ADD the "PRACK" which made calls termiante but get disconnected, and finaly at the END I had to remove the "PRACK" which Made the calls terminate Succesfully,,,,LACK of COMMUNICATION with the ITSP.. ..LOL.. and THANKS AGAIN for YOUR HELP......

Below is the COnfig I Am using,,,,,,

!

voice service voip
fax protocol pass-through g711alaw
h323
no ras brq
h245 caps mode restricted
sip
bind all source-interface FastEthernet0
!

!
dial-peer voice 4003 voip
description OUT_TATA_SONUS
preference 1
destination-pattern 912067343134
session protocol sipv2
session target ipv4:66.198.40.9:5060
dtmf-relay rtp-nte h245-alphanumeric
no vad
!