09-21-2010 02:22 PM - edited 03-21-2019 03:02 AM
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
09-22-2010 07:21 AM
Where was this capture taken in perspective of the topology? What IP addresses are what?
09-22-2010 07:59 AM
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
09-22-2010 08:35 AM
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.
09-22-2010 12:58 PM
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=da6f4c43dc5555555000>
To: <555555555>;tag=5BEE28-1247555555555>
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=off201>
Contact: <555555555>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=da6f4c43dc5555555000>
To: <555555555>;tag=5BEE28-1247555555555>
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=off201>
Contact: <555555555>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=da6f4c43dc5555555000>
To: <555555555>;tag=5BEE28-1247555555555>
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=da6f4c43dc5555555000>
To: <555555555>;tag=5BEE28-1247555555555>
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=off201>
Contact: <555555555>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
09-22-2010 01:22 PM
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.
09-23-2010 09:30 AM
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.
09-25-2010 06:54 AM
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.
10-08-2010 01:33 AM
Bad news, the Customer is tired! I had to throw in the towel and give up ...
73,
Arturo.
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide