Incoming SIP call disconnected after 22 seconds

Arturo Bianchi · ‎09-21-2010

Hi,

I have the following problem with a SIP trunk via IPsec between UC540 and a gateway, when the call begins at GW, the audio drops after about 25 seconds. The IPSec tunnel is terminated on ASA, the GWt is behind ASA, no problem for the phone calls started from UC but those initiated by GW fall probably due to errors in SIP protocol.

This is the sequence of SIP session:

What happens?

The UC does not receive the ACK and resend to the "200 OK" for 2 times then the GW closes the connection with a BYE after 20-25 seconds? I removed access-list and ip inspect from wan port of UC540 but but nothing changes; the audio goes perfectly until the GW sends the unexpected BYE :-(

Here are few lines of configuration set or changed from CLI:

voice service voip
sip
bind control source-interface BVI1
bind media source-interface BVI1

crypto isakmp key xxxxxxxxxxxxxx address 1.2.3.4

crypto map sito 1 ipsec-isakmp
set peer 1.2.3.4
set transform-set ESP-3DES-SHA
set pfs group2
match address 192
qos pre-classify

interface FastEthernet0/0
crypto map sito

ip nat inside source list 190 interface FastEthernet0/0 overload

access-list 190 remark NAT
access-list 190 deny ip any 192.168.0.0 0.0.1.255
access-list 190 permit ip 10.1.0.0 0.0.15.255 any
access-list 190 permit ip 192.168.2.0 0.0.0.255 any
access-list 190 deny ip any any log

access-list 192 remark Tunnel IPSec
access-list 192 permit ip 192.168.2.0 0.0.0.255 192.168.0.0 0.0.1.255

Everything else was set using the CCA; note that if I use a public SIP server do not see any problem and I do not have to force the IP address used by the SIP-UA with the command:

voice service voip
sip
bind control source-interface BVI1
bind media source-interface BVI1

I have not yet determined if it was a problem ACK lost if they are lost to the ASA or elsewhere or on UC540. Indeed, it seems a problem due to filtering, NAT and firewall because it occurs only for incoming calls on UC540.

Note: obviously, ASA and UC have public IP on the WAN port so there are no more than one NAT on the apparatus.

Thanks,

Arturo

Steven Holl · ‎09-22-2010

Where was this capture taken in perspective of the topology? What IP addresses are what?

David Hornstein · ‎09-22-2010

I am no CLI guru at all, but I had a similar issue with my UC520 when i first setup a SIP trunk to my ITSP, Engin in Australia.

All calls would drop consistantly every 40 seconds.

I had to use a generic SIP template via CCA, as Engin is not a predefined template.

It was discovered, that I had to use 'connection re-use' within SIP-UA section of the script and my phones stopped dropping calls.

Up to that point, my calls would drop, most anoying.

But something changed in terms of how my UC520 software behaves. Now that I am using the 8.0.4.zip package on my UC520, i found that connection-reuse was no longer needed.

Just for grins and giggles, before you jump to SBSC for support, see is adding 'connection-reuse' or 'con' to sip-ua will make a difference .

regards Dave

Steven Holl · ‎09-22-2010

That's interesting that made a difference, since all that does is use the same ephemeral port for outbound INVITEs (basically multiplexing all SIP call

control onto the same UDP flow). If anything, I'd only see that changing behavior for when a second call gets brought up across the link, but not based on a timer expiration.

This may be an issue on the firewall. The question is if the ACK is making it back to CME or not. If it isn't, the firewall likely isn't sending it out, and I'd open support from the firewall perspective regarding SIP NAT/inspection, instead of with STAC for the CME.

Arturo Bianchi · ‎09-22-2010

Traffic was captured on ASA with capture wizard, the GW has ip .0.6 and the UC has .2.1; this is traffic on inside port,
on internet side we have IPSec traffic...

I do not remember if in the same test session, but here is +/- what you see on the UC with debug:

001129: Sep 21 21:39:19.876: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:
Sent:
SIP/2.0 200 OK

Via: SIP/2.0/UDP 192.168.0.6:5060;branch=z9hG4bKa8efd7e07f02a9e3f

From: <5555555000>;tag=da6f4c43dc

To: <555555555>;tag=5BEE28-1247

Date: Tue, 21 Sep 2010 21:39:15 GMT

Call-ID: ebc75047c6ba5c28

CSeq: 15585 INVITE

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

Allow-Events: telephone-event

Remote-Party-ID: "Agente 007" <201>;party=called;screen=no;privacy=off

Contact: <555555555>

Supported: replaces

Supported: sdp-anat

Server: Cisco-SIPGateway/IOS-12.x

Content-Type: application/sdp

Content-Disposition: session;handling=required

Content-Length: 210

v=0

o=CiscoSystemsSIP-GW-UserAgent 5381 9930 IN IP4 192.168.2.1

s=SIP Call

t=0 0

m=audio 17016 RTP/AVP 8 101

c=IN IP4 192.168.2.1

a=rtpmap:8 PCMA/8000

a=rtpmap:101 telephone-event/8000

a=fmtp:101 0-16

001144: Sep 21 21:39:20.320: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:
Sent:
SIP/2.0 200 OK

Via: SIP/2.0/UDP 192.168.0.6:5060;branch=z9hG4bKa8efd7e07f02a9e3f

From: <5555555000>;tag=da6f4c43dc

To: <555555555>;tag=5BEE28-1247

Date: Tue, 21 Sep 2010 21:39:15 GMT

Call-ID: ebc75047c6ba5c28

CSeq: 15585 INVITE

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

Allow-Events: telephone-event

Remote-Party-ID: "Agente 007" <201>;party=called;screen=no;privacy=off

Contact: <555555555>

Supported: replaces

Supported: sdp-anat

Server: Cisco-SIPGateway/IOS-12.x

Content-Type: application/sdp

Content-Disposition: session;handling=required

Content-Length: 210

v=0

o=CiscoSystemsSIP-GW-UserAgent 5381 9930 IN IP4 192.168.2.1

s=SIP Call

t=0 0

m=audio 17016 RTP/AVP 8 101

c=IN IP4 192.168.2.1

a=rtpmap:8 PCMA/8000

a=rtpmap:101 telephone-event/8000

a=fmtp:101 0-16

001160: Sep 21 21:39:20.336: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:
Received:
ACK sip:555555555@192.168.2.1:5060 SIP/2.0

Via: SIP/2.0/UDP 192.168.0.6:5060;branch=z9hG4bK1e0598d2bbd9e5504

Max-Forwards: 70

From: <5555555000>;tag=da6f4c43dc

To: <555555555>;tag=5BEE28-1247

Call-ID: ebc75047c6ba5c28

CSeq: 15585 ACK

User-Agent: Patton SN4554 2BIS EUI 00A0BA05A8D9 R5.6 2010-07-15 SIP M5T SIP Stack/4.0.29.29

Content-Length: 0

001174: Sep 21 21:39:20.340: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:
Sent:
SIP/2.0 200 OK

Via: SIP/2.0/UDP 192.168.0.6:5060;branch=z9hG4bKa8efd7e07f02a9e3f

From: <5555555000>;tag=da6f4c43dc

To: <555555555>;tag=5BEE28-1247

Date: Tue, 21 Sep 2010 21:39:15 GMT

Call-ID: ebc75047c6ba5c28

CSeq: 15585 INVITE

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

Allow-Events: telephone-event

Remote-Party-ID: "Agente 007" <201>;party=called;screen=no;privacy=off

Contact: <555555555>

Supported: replaces

Supported: sdp-anat

Server: Cisco-SIPGateway/IOS-12.x

Content-Type: application/sdp

Content-Disposition: session;handling=required

Content-Length: 210

v=0

o=CiscoSystemsSIP-GW-UserAgent 5381 9930 IN IP4 192.168.2.1

s=SIP Call

t=0 0

m=audio 17016 RTP/AVP 8 101

c=IN IP4 192.168.2.1

a=rtpmap:8 PCMA/8000

a=rtpmap:101 telephone-event/8000

a=fmtp:101 0-16

Since a couple of times (out of 100!) The call has gone, may be a timeout issue somewhere?

73,

Arturo

Arturo Bianchi · ‎09-22-2010

Here at a glance what you see on the UC (another call):

000569: Sep 22 20:05:37.424: Received: INVITE sip:111555111@192.168.2.1:5060 SIP/2.0
000570: Sep 22 20:05:37.472: Sent:     SIP/2.0 100 Trying
000571: Sep 22 20:05:37.480: Sent:     SIP/2.0 180 Ringing
000572: Sep 22 20:05:41.388: Sent:     SIP/2.0 200 OK
000573: Sep 22 20:05:41.480: Sent:     SIP/2.0 200 OK
000574: Sep 22 20:05:41.552: Received: ACK sip:111555111@192.168.2.1:5060 SIP/2.0
000575: Sep 22 20:05:41.556: The Call Setup Information is: STATE_ACTIVE
000576: Sep 22 20:05:41.556: Number of Media Streams: 1
000577: Sep 22 20:05:41.576: Received: ACK sip:111555111@192.168.2.1:5060 SIP/2.0
000578: Sep 22 20:06:07.745: Received: BYE sip:111555111@192.168.2.1:5060 SIP/2.0
000579: Sep 22 20:06:07.753: The Call Setup Information is: STATE_DEAD :-(
000580: Sep 22 20:06:07.753: Number of Media Streams: 1
000581: Sep 22 20:06:07.753: Disconnect Cause (CC): 16 - Disconnect Cause (SIP): 200
000582: Sep 22 20:06:07.757: Sent: SIP/2.0 200 OK - Reason: Q.850;cause=16

73,

Arturo.

Steven Holl · ‎09-23-2010

This debug shows the ACK coming in, and not being processed. The third OK should not have gone out. 'debug ccsip all' would shed more light on why it didn't process that ACK.

It's odd that it takes so long for that ACK to come in, though; it should have come in soon after the first OK got sent out. That seems to point to something going on with the network between. Regardless, though, that call should have been brought up properly when the ACK came in.

Arturo Bianchi · ‎09-25-2010

Hi,

I can reproduce the problem accurately and seems to be tied somehow to the Patton gateway or legacy PBX connected on ISDN... ...Answers or unanswered calls are cut off after exactly 30 seconds only if the call is being committed on the second channel of any of two ISDN lines.

I'm trying to investigate and resolve, perhaps it is a subtle error in the configuration of gw...

Thanks, I hope to have good news.

73,

Arturo.

Arturo Bianchi · ‎10-08-2010

Bad news, the Customer is tired! I had to throw in the towel and give up ...

73,

Arturo.