Are there any changes to chan_sip since 09/16/04 in the stable branch that could affect the way Asterisk issues an ACK? The reason I ask...I have a product by INGATE called the Siparator which assists in NAT traversal. It worked great until I upgraded to Asterisk v1.0. After comparing the logs it looks like asterisk may no longer send the GUID type ACK response the Siparator is expecting. Take a quick look at the difference below. (BTW 10.10.0.6 is the Asterisk box) Asterisk build from 09/16/04: (These are examples not necessarily the same call) Siparator log says:>>> Info: sipfw: recv from 10.10.0.6: ACKsip:e_RY4_466QliT14zp26IqP6KYbo9s6ZERZM0fQuq8nzGMs71r0jwT2UOVGyjPobFW@10 .10.0.5 SIP/2.0 Asterisk sip debug says: Transmitting: ACK sip:eKvj1A8MZuPxroET_BXewOVi3uR-3Ad_liBBCrJQq8dbq7VO-p-RGl6icEsXi2TZX@10 .10.0.5 SIP/2.0 Via: SIP/2.0/UDP 10.10.0.6:5060;branch=z9hG4bK4441b7b5 Route: <sip:eKvj1A8MZuPxroET_BXewOVi3uR-3Ad_liBBCrJQq8dbq7VO-p-RGl6icEsXi2TZX@1 0.10.0.5> From: "Chad Brown" <sip:asterisk@10.10.0.6>;tag=as490d60cd To: <sip:12534056726@10.10.0.5>;tag=3307489924-529483 Contact: <sip:asterisk@10.10.0.6> Call-ID: 08b25b4e793c9fda031a818f7922c61a@10.10.0.6 CSeq: 102 ACK User-Agent: Asterisk PBX Content-Length: 0 Asterisk build v1.0 (These are examples not necessarily the same call) Siparator log says:>>> Info: sipfw: recv from 10.10.0.6: ACK sip:12534056726@10.10.0.5SIP/2.0 Asterisk sip debug says: Transmitting: ACK sip:12534056726@10.10.0.5 SIP/2.0 Via: SIP/2.0/UDP 10.10.0.6:5060;branch=z9hG4bK4be3d57b Route: <sip:eDXTNO6dkwsoA4_uBoSao6QR6sGzyTc9suJBrvzuYOVHclaWI7YmOtc3aQUmYltVy@1 0.10.0.5> From: "Chad Brown" <sip:asterisk@10.10.0.6>;tag=as5c7a2a79 To: <sip:12534056726@10.10.0.5>;tag=3307285355-806590 Contact: <sip:asterisk@10.10.0.6> Call-ID: 29fbc7297c33271446d86cfc474d0b75@10.10.0.6 CSeq: 102 ACK User-Agent: Asterisk PBX Content-Length: 0 My guess is that the Siparator keeps track of separate streams with the long GUID string and then does an appropriate transform. Since the GUID is gone in v1.0 so is Siparators ability to translate/transform the call. Thanks for you help! Chad Brown - IdentityMine -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.digium.com/pipermail/asterisk-users/attachments/20041022/e0553a23/attachment.htm
Olle E. Johansson
2004-Oct-23 02:29 UTC
[Asterisk-Users] chan_sip changes affecting ACK? - Bug?
Chad, I need a more complete SIP debug than just one packet to try to look into this issue. If the device registers, both a REGISTER transaction and a subsequent call with the ACK - THank you! /O
Olle,
No...Thank you! You are the perfect guy to look at this problem as well
since ultimately I need to switch to chan_sip2 given the outboundproxy
functionality.
My testing shows that not only stable has this issue but so does head.
That said, the problem could carry over to chan_sip2. Anyway...
I originally sent several log files from both the Siparator and Asterisk
but the message was refused from the list because of size.
Attached are 2 asterisk sip debug files. I fear that some of the
information scrolled off the screen during debug. If these don't have
enough information please let me know. When I get back to the office I
will log sip debug to a file rather than console as I was so I don't
loose anything.
If you would like to see the separator logs I will need to send them to
you directly because they are 300K a piece and go over the limit for
this list.
Thanks,
Chad
-----Original Message-----
From: asterisk-users-bounces@lists.digium.com
[mailto:asterisk-users-bounces@lists.digium.com] On Behalf Of Olle E.
Johansson
Sent: Saturday, October 23, 2004 2:29 AM
To: Asterisk Users Mailing List - Non-Commercial Discussion
Subject: Re: [Asterisk-Users] chan_sip changes affecting ACK? - Bug?
Chad,
I need a more complete SIP debug than just one packet to try to look
into this
issue. If the device registers, both a REGISTER transaction and a
subsequent
call with the ACK - THank you!
/O
_______________________________________________
Asterisk-Users mailing list
Asterisk-Users@lists.digium.com
http://lists.digium.com/mailman/listinfo/asterisk-users
To UNSUBSCRIBE or update options visit:
http://lists.digium.com/mailman/listinfo/asterisk-users
-------------- next part --------------
to 10.10.0.110:5060
-- Executing Dial("SIP/101-eac7",
"SIP/12534056726@10.10.0.5") in new stack
We're at 10.10.0.6 port 17666
Answering/Requesting with root capability 4
Answering with capability 0x2(GSM)
Answering with capability 0x8(ALAW)
Answering with non-codec capability 0x1(G723)
12 headers, 12 lines
Reliably Transmitting:
INVITE sip:12534056726@10.10.0.5 SIP/2.0
Via: SIP/2.0/UDP 10.10.0.6:5060;branch=z9hG4bK6016290f
From: "Chad Brown" <sip:101@10.10.0.6>;tag=as2041d236
To: <sip:12534056726@10.10.0.5>
Contact: <sip:101@10.10.0.6>
Call-ID: 1a03af943d7201bc6da3a14e3750865c@10.10.0.6
CSeq: 102 INVITE
User-Agent: Asterisk PBX
Date: Thu, 21 Oct 2004 17:14:13 GMT
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER
Content-Type: application/sdp
Content-Length: 255
v=0
o=root 8649 8649 IN IP4 10.10.0.6
s=session
c=IN IP4 10.10.0.6
t=0 0
m=audio 17666 RTP/AVP 0 3 8 101
a=rtpmap:0 PCMU/8000
a=rtpmap:3 GSM/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=silenceSupp:off - - - -
(no NAT) to 10.10.0.5:5060
-- Called 12534056726@10.10.0.5
impbx01*CLI>
Sip read:
SIP/2.0 100 Trying
Via: SIP/2.0/UDP 10.10.0.6:5060;branch=z9hG4bK6016290f
From: "Chad Brown" <sip:101@10.10.0.6>;tag=as2041d236
Call-ID: 1a03af943d7201bc6da3a14e3750865c@10.10.0.6
CSeq: 102 INVITE
Server: SIParator/4.1.3
To: <sip:12534056726@10.10.0.5>
Content-Length: 0
8 headers, 0 lines
impbx01*CLI>
Sip read:
SIP/2.0 180 Ringing
To: <sip:12534056726@10.10.0.5>;tag=3307367608-554546
From: "Chad Brown" <sip:101@10.10.0.6>;tag=as2041d236
Call-ID: 1a03af943d7201bc6da3a14e3750865c@10.10.0.6
CSeq: 102 INVITE
Contact:
<sip:e2i_cjrQXf_07gGdSVIMofwc5VYtECYEoQaBUD_SIhNyCrwe9EIMs75QA6vHgd8Xz@10.10.0.5>
Content-Type: application/sdp
Via: SIP/2.0/UDP 10.10.0.6:5060;branch=z9hG4bK6016290f
Content-Length: 187
v=0
o=NexTone-MSW 1234 467212419 IN IP4 10.10.0.5
s=sip call
c=IN IP4 10.10.0.5
t=0 0
m=audio 58030 RTP/AVP 0
a=silenceSupp:off
a=ecan:b on g168
a=ptime:20
a=rtpmap:0 PCMU/8000
9 headers, 10 lines
-- SIP/10.10.0.5-13c2 is ringing
Transmitting (no NAT):
SIP/2.0 180 Ringing
Via: SIP/2.0/UDP 10.10.0.110:5060;branch=z9hG4bK1ed3fe76
From: "Chad Brown - ext 101"
<sip:101@sip.identitymine.com>;tag=001193d886a3010e3ae0c0a4-4f179b0e
To: <sip:12534056726@sip.identitymine.com>;tag=as33b30738
Call-ID: 001193d8-86a3001b-1cd49d4c-76746a4f@10.10.0.110
CSeq: 101 INVITE
User-Agent: Asterisk PBX
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER
Contact: <sip:12534056726@10.10.0.6>
Content-Length: 0
to 10.10.0.110:5060
impbx01*CLI>
Sip read:
SIP/2.0 200 OK
To: <sip:12534056726@10.10.0.5>;tag=3307367608-554546
From: "Chad Brown" <sip:101@10.10.0.6>;tag=as2041d236
Call-ID: 1a03af943d7201bc6da3a14e3750865c@10.10.0.6
CSeq: 102 INVITE
Contact:
<sip:eJ7Tp7r12vK-plwl1R4IhUifBHIlEYbMje2Wq3qLiWpSLcSfN6MCsjkU-yOFq6kIT@10.10.0.5>
Content-Type: application/sdp
Via: SIP/2.0/UDP 10.10.0.6:5060;branch=z9hG4bK6016290f
Record-Route: <sip:280dcf6a@10.10.0.5;lr>
Content-Length: 187
v=0
o=NexTone-MSW 1234 467212419 IN IP4 10.10.0.5
s=sip call
c=IN IP4 10.10.0.5
t=0 0
m=audio 58030 RTP/AVP 0
a=silenceSupp:off
a=ecan:b on g168
a=ptime:20
a=rtpmap:0 PCMU/8000
10 headers, 10 lines
Found RTP audio format 0
Peer audio RTP is at port 10.10.0.5:58030
Found description format PCMU
Capabilities: us - 0x8000e(GSM|ULAW|ALAW|H263), peer -
audio=0x4(ULAW)/video=0x0(EMPTY), combined - 0x4(ULAW)
Non-codec capabilities: us - 0x1(G723), peer - 0x0(EMPTY), combined - 0x0(EMPTY)
list_route: hop: <sip:280dcf6a@10.10.0.5;lr>
list_route: hop:
<sip:eJ7Tp7r12vK-plwl1R4IhUifBHIlEYbMje2Wq3qLiWpSLcSfN6MCsjkU-yOFq6kIT@10.10.0.5>
set_destination: Parsing <sip:280dcf6a@10.10.0.5;lr> for address/port to
send to
set_destination: set destination to 10.10.0.5, port 5060
Transmitting:
ACK sip:12534056726@10.10.0.5 SIP/2.0
Via: SIP/2.0/UDP 10.10.0.6:5060;branch=z9hG4bK08fa5d64
Route:
<sip:eJ7Tp7r12vK-plwl1R4IhUifBHIlEYbMje2Wq3qLiWpSLcSfN6MCsjkU-yOFq6kIT@10.10.0.5>
From: "Chad Brown" <sip:101@10.10.0.6>;tag=as2041d236
To: <sip:12534056726@10.10.0.5>;tag=3307367608-554546
Contact: <sip:101@10.10.0.6>
Call-ID: 1a03af943d7201bc6da3a14e3750865c@10.10.0.6
CSeq: 102 ACK
User-Agent: Asterisk PBX
Content-Length: 0
(no NAT) to 10.10.0.5:5060
-- SIP/10.10.0.5-13c2 answered SIP/101-eac7
We're at 10.10.0.6 port 17116
Answering with preferred capability 0x4(ULAW)
Answering with capability 0x2(GSM)
Answering with capability 0x8(ALAW)
Answering with non-codec capability 0x1(G723)
Reliably Transmitting (no NAT):
SIP/2.0 200 OK
Via: SIP/2.0/UDP 10.10.0.110:5060;branch=z9hG4bK1ed3fe76
From: "Chad Brown - ext 101"
<sip:101@sip.identitymine.com>;tag=001193d886a3010e3ae0c0a4-4f179b0e
To: <sip:12534056726@sip.identitymine.com>;tag=as33b30738
Call-ID: 001193d8-86a3001b-1cd49d4c-76746a4f@10.10.0.110
CSeq: 101 INVITE
User-Agent: Asterisk PBX
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER
Contact: <sip:12534056726@10.10.0.6>
Content-Type: application/sdp
Content-Length: 255
v=0
o=root 8649 8649 IN IP4 10.10.0.6
s=session
c=IN IP4 10.10.0.6
t=0 0
m=audio 17116 RTP/AVP 0 3 8 101
a=rtpmap:0 PCMU/8000
a=rtpmap:3 GSM/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=silenceSupp:off - - - -
to 10.10.0.110:5060
-- Attempting native bridge of SIP/101-eac7 and SIP/10.10.0.5-13c2
impbx01*CLI>
Sip read:
ACK sip:12534056726@10.10.0.6:5060 SIP/2.0
Via: SIP/2.0/UDP 10.10.0.110:5060;branch=z9hG4bK4bcf39c0
From: "Chad Brown - ext 101"
<sip:101@sip.identitymine.com>;tag=001193d886a3010e3ae0c0a4-4f179b0e
To: <sip:12534056726@sip.identitymine.com>;tag=as33b30738
Call-ID: 001193d8-86a3001b-1cd49d4c-76746a4f@10.10.0.110
CSeq: 101 ACK
User-Agent: CSCO/7
Content-Length: 0
-------------- next part --------------
From: "Chad Brown" <sip:asterisk@10.10.0.6>;tag=as490d60cd
Call-ID: 08b25b4e793c9fda031a818f7922c61a@10.10.0.6
CSeq: 102 INVITE
Contact:
<sip:eKvj1A8MZuPxroET_BXewOVi3uR-3Ad_liBBCrJQq8dbq7VO-p-RGl6icEsXi2TZX@10.10.0.5>
Content-Type: application/sdp
Via: SIP/2.0/UDP 10.10.0.6:5060;branch=z9hG4bK4441b7b5
Record-Route: <sip:4a37c67a@10.10.0.5;lr>
Content-Length: 187
v=0
o=NexTone-MSW 1234 467334735 IN IP4 10.10.0.5
s=sip call
c=IN IP4 10.10.0.5
t=0 0
m=audio 58032 RTP/AVP 0
a=silenceSupp:off
a=ecan:b on g168
a=ptime:20
a=rtpmap:0 PCMU/8000
10 headers, 10 lines
Found audio format UNKN
Found description format PCMU
Capabilities: us - 524302, them - 4/0, combined - 4
Non-codec capabilities: us - 1, them - 0, combined - 0
list_route: hop: <sip:4a37c67a@10.10.0.5;lr>
list_route: hop:
<sip:eKvj1A8MZuPxroET_BXewOVi3uR-3Ad_liBBCrJQq8dbq7VO-p-RGl6icEsXi2TZX@10.10.0.5>
set_destination: Parsing <sip:4a37c67a@10.10.0.5;lr> for address/port to
send to
set_destination: set destination to 10.10.0.5, port 5060
Transmitting:
ACK
sip:eKvj1A8MZuPxroET_BXewOVi3uR-3Ad_liBBCrJQq8dbq7VO-p-RGl6icEsXi2TZX@10.10.0.5
SIP/2.0
Via: SIP/2.0/UDP 10.10.0.6:5060;branch=z9hG4bK4441b7b5
Route:
<sip:eKvj1A8MZuPxroET_BXewOVi3uR-3Ad_liBBCrJQq8dbq7VO-p-RGl6icEsXi2TZX@10.10.0.5>
From: "Chad Brown" <sip:asterisk@10.10.0.6>;tag=as490d60cd
To: <sip:12534056726@10.10.0.5>;tag=3307489924-529483
Contact: <sip:asterisk@10.10.0.6>
Call-ID: 08b25b4e793c9fda031a818f7922c61a@10.10.0.6
CSeq: 102 ACK
User-Agent: Asterisk PBX
Content-Length: 0
(no NAT) to 10.10.0.5:5060
-- SIP/10.10.0.5-0744 answered SIP/101-2878
We're at 10.10.0.6 port 12570
Answering with preferred capability 4
Answering with capability 2
Answering with capability 8
Answering with non-codec capability 1
Reliably Transmitting (no NAT):
SIP/2.0 200 OK
Via: SIP/2.0/UDP 10.10.0.110:5060;branch=z9hG4bK2ac6b76c
From: "Chad Brown - ext 101"
<sip:101@sip.identitymine.com>;tag=001193d886a300482359b5ac-0ecac181
To: <sip:12534056726@sip.identitymine.com>;tag=as0943736e
Call-ID: 001193d8-86a30009-5dea4b03-583b7dbb@10.10.0.110
CSeq: 101 INVITE
User-Agent: Asterisk PBX
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER
Contact: <sip:12534056726@10.10.0.6>
Content-Type: application/sdp
Content-Length: 255
v=0
o=root 1940 1940 IN IP4 10.10.0.6
s=session
c=IN IP4 10.10.0.6
t=0 0
m=audio 12570 RTP/AVP 0 3 8 101
a=rtpmap:0 PCMU/8000
a=rtpmap:3 GSM/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=silenceSupp:off - - - -
to 10.10.0.110:5060
-- Attempting native bridge of SIP/101-2878 and SIP/10.10.0.5-0744
impbx01*CLI>
Sip read:
ACK sip:12534056726@10.10.0.6:5060 SIP/2.0
Via: SIP/2.0/UDP 10.10.0.110:5060;branch=z9hG4bK7e2ea034
From: "Chad Brown - ext 101"
<sip:101@sip.identitymine.com>;tag=001193d886a300482359b5ac-0ecac181
To: <sip:12534056726@sip.identitymine.com>;tag=as0943736e
Call-ID: 001193d8-86a30009-5dea4b03-583b7dbb@10.10.0.110
CSeq: 101 ACK
User-Agent: CSCO/7
Content-Length: 0
-------------- next part --------------
a=fmtp:101 0-15
12 headers, 11 lines
Using latest request as basis request
Sending to 10.10.0.110 : 5060 (non-NAT)
Found RTP audio format 0
Found RTP audio format 8
Found RTP audio format 18
Found RTP audio format 101
Peer audio RTP is at port 10.10.0.110:19404
Found description format PCMU
Found description format PCMA
Found description format G729
Found description format telephone-event
Capabilities: us - 0x8000e(GSM|ULAW|ALAW|H263), peer -
audio=0x10c(ULAW|ALAW|G729A)/video=0x0(EMPTY), combined - 0xc(ULAW|ALAW)
Non-codec capabilities: us - 0x1(G723), peer - 0x1(G723), combined - 0x1(G723)
Found user '101'
Looking for 12534056726 in trusted
list_route: hop: <sip:101@10.10.0.110:5060>
Transmitting (no NAT):
SIP/2.0 100 Trying
Via: SIP/2.0/UDP 10.10.0.110:5060;branch=z9hG4bK14abe6ee
From: "Chad Brown - ext 101"
<sip:101@sip.identitymine.com>;tag=001193d886a3000c13c96f5b-25455014
To: <sip:12534056726@sip.identitymine.com>;tag=as68d0496a
Call-ID: 001193d8-86a30005-2d7ba0b0-4bf0ca5b@10.10.0.110
CSeq: 101 INVITE
User-Agent: Asterisk PBX
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER
Contact: <sip:12534056726@10.10.0.6>
Content-Length: 0
to 10.10.0.110:5060
-- Executing Dial("SIP/101-8c77",
"SIP/12534056726@10.10.0.5") in new stack
We're at 10.10.0.6 port 12388
Answering/Requesting with root capability 4
Answering with capability 0x2(GSM)
Answering with capability 0x8(ALAW)
Answering with non-codec capability 0x1(G723)
12 headers, 12 lines
Reliably Transmitting:
INVITE sip:12534056726@10.10.0.5 SIP/2.0
Via: SIP/2.0/UDP 10.10.0.6:5060;branch=z9hG4bK00e6821d
From: "Chad Brown" <sip:asterisk@10.10.0.6>;tag=as5c7a2a79
To: <sip:12534056726@10.10.0.5>
Contact: <sip:asterisk@10.10.0.6>
Call-ID: 29fbc7297c33271446d86cfc474d0b75@10.10.0.6
CSeq: 102 INVITE
User-Agent: Asterisk PBX
Date: Wed, 20 Oct 2004 18:23:18 GMT
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER
Content-Type: application/sdp
Content-Length: 255
v=0
o=root 8669 8669 IN IP4 10.10.0.6
s=session
c=IN IP4 10.10.0.6
t=0 0
m=audio 12388 RTP/AVP 0 3 8 101
a=rtpmap:0 PCMU/8000
a=rtpmap:3 GSM/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=silenceSupp:off - - - -
(no NAT) to 10.10.0.5:5060
-- Called 12534056726@10.10.0.5
impbx01*CLI>
Sip read:
SIP/2.0 100 Trying
Via: SIP/2.0/UDP 10.10.0.6:5060;branch=z9hG4bK00e6821d
From: "Chad Brown" <sip:asterisk@10.10.0.6>;tag=as5c7a2a79
Call-ID: 29fbc7297c33271446d86cfc474d0b75@10.10.0.6
CSeq: 102 INVITE
Server: SIParator/4.1.0
To: <sip:12534056726@10.10.0.5>
Content-Length: 0
8 headers, 0 lines
impbx01*CLI>
Sip read:
SIP/2.0 180 Ringing
To: <sip:12534056726@10.10.0.5>;tag=3307285355-806590
From: "Chad Brown" <sip:asterisk@10.10.0.6>;tag=as5c7a2a79
Call-ID: 29fbc7297c33271446d86cfc474d0b75@10.10.0.6
CSeq: 102 INVITE
Contact:
<sip:eSQaWt-bp7wmoGkGFP4SAqR9gAQrLzLqVFfwP9dFIcby_yhF8qHZG-f1JSgIwt2hb@10.10.0.5>
Content-Type: application/sdp
Via: SIP/2.0/UDP 10.10.0.6:5060;branch=z9hG4bK00e6821d
Content-Length: 187
v=0
o=NexTone-MSW 1234 467130168 IN IP4 10.10.0.5
s=sip call
c=IN IP4 10.10.0.5
t=0 0
m=audio 58110 RTP/AVP 0
a=silenceSupp:off
a=ecan:b on g168
a=ptime:20
a=rtpmap:0 PCMU/8000
9 headers, 10 lines
-- SIP/10.10.0.5-f8bf is ringing
Transmitting (no NAT):
SIP/2.0 180 Ringing
Via: SIP/2.0/UDP 10.10.0.110:5060;branch=z9hG4bK14abe6ee
From: "Chad Brown - ext 101"
<sip:101@sip.identitymine.com>;tag=001193d886a3000c13c96f5b-25455014
To: <sip:12534056726@sip.identitymine.com>;tag=as68d0496a
Call-ID: 001193d8-86a30005-2d7ba0b0-4bf0ca5b@10.10.0.110
CSeq: 101 INVITE
User-Agent: Asterisk PBX
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER
Contact: <sip:12534056726@10.10.0.6>
Content-Length: 0
to 10.10.0.110:5060
impbx01*CLI>
Sip read:
SIP/2.0 200 OK
To: <sip:12534056726@10.10.0.5>;tag=3307285355-806590
From: "Chad Brown" <sip:asterisk@10.10.0.6>;tag=as5c7a2a79
Call-ID: 29fbc7297c33271446d86cfc474d0b75@10.10.0.6
CSeq: 102 INVITE
Contact:
<sip:eDXTNO6dkwsoA4_uBoSao6QR6sGzyTc9suJBrvzuYOVHclaWI7YmOtc3aQUmYltVy@10.10.0.5>
Content-Type: application/sdp
Via: SIP/2.0/UDP 10.10.0.6:5060;branch=z9hG4bK00e6821d
Record-Route: <sip:26998a73@10.10.0.5;lr>
Content-Length: 187
v=0
o=NexTone-MSW 1234 467130168 IN IP4 10.10.0.5
s=sip call
c=IN IP4 10.10.0.5
t=0 0
m=audio 58110 RTP/AVP 0
a=silenceSupp:off
a=ecan:b on g168
a=ptime:20
a=rtpmap:0 PCMU/8000
10 headers, 10 lines
Found RTP audio format 0
Peer audio RTP is at port 10.10.0.5:58110
Found description format PCMU
Capabilities: us - 0x8000e(GSM|ULAW|ALAW|H263), peer -
audio=0x4(ULAW)/video=0x0(EMPTY), combined - 0x4(ULAW)
Non-codec capabilities: us - 0x1(G723), peer - 0x0(EMPTY), combined - 0x0(EMPTY)
list_route: hop: <sip:26998a73@10.10.0.5;lr>
list_route: hop:
<sip:eDXTNO6dkwsoA4_uBoSao6QR6sGzyTc9suJBrvzuYOVHclaWI7YmOtc3aQUmYltVy@10.10.0.5>
set_destination: Parsing <sip:26998a73@10.10.0.5;lr> for address/port to
send to
set_destination: set destination to 10.10.0.5, port 5060
Transmitting:
ACK sip:12534056726@10.10.0.5 SIP/2.0
Via: SIP/2.0/UDP 10.10.0.6:5060;branch=z9hG4bK4be3d57b
Route:
<sip:eDXTNO6dkwsoA4_uBoSao6QR6sGzyTc9suJBrvzuYOVHclaWI7YmOtc3aQUmYltVy@10.10.0.5>
From: "Chad Brown" <sip:asterisk@10.10.0.6>;tag=as5c7a2a79
To: <sip:12534056726@10.10.0.5>;tag=3307285355-806590
Contact: <sip:asterisk@10.10.0.6>
Call-ID: 29fbc7297c33271446d86cfc474d0b75@10.10.0.6
CSeq: 102 ACK
User-Agent: Asterisk PBX
Content-Length: 0
(no NAT) to 10.10.0.5:5060
-- SIP/10.10.0.5-f8bf answered SIP/101-8c77
We're at 10.10.0.6 port 10262
Answering with preferred capability 0x4(ULAW)
Answering with capability 0x2(GSM)
Answering with capability 0x8(ALAW)
Answering with non-codec capability 0x1(G723)
Reliably Transmitting (no NAT):
SIP/2.0 200 OK
Via: SIP/2.0/UDP 10.10.0.110:5060;branch=z9hG4bK14abe6ee
From: "Chad Brown - ext 101"
<sip:101@sip.identitymine.com>;tag=001193d886a3000c13c96f5b-25455014
To: <sip:12534056726@sip.identitymine.com>;tag=as68d0496a
Call-ID: 001193d8-86a30005-2d7ba0b0-4bf0ca5b@10.10.0.110
CSeq: 101 INVITE
User-Agent: Asterisk PBX
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER
Contact: <sip:12534056726@10.10.0.6>
Content-Type: application/sdp
Content-Length: 255
v=0
o=root 8669 8669 IN IP4 10.10.0.6
s=session
c=IN IP4 10.10.0.6
t=0 0
m=audio 10262 RTP/AVP 0 3 8 101
a=rtpmap:0 PCMU/8000
a=rtpmap:3 GSM/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=silenceSupp:off - - - -
to 10.10.0.110:5060
-- Attempting native bridge of SIP/101-8c77 and SIP/10.10.0.5-f8bf
impbx01*CLI>
Sip read:
ACK sip:12534056726@10.10.0.6:5060 SIP/2.0
Via: SIP/2.0/UDP 10.10.0.110:5060;branch=z9hG4bK30b1b6be
From: "Chad Brown - ext 101"
<sip:101@sip.identitymine.com>;tag=001193d886a3000c13c96f5b-25455014
To: <sip:12534056726@sip.identitymine.com>;tag=as68d0496a
Call-ID: 001193d8-86a30005-2d7ba0b0-4bf0ca5b@10.10.0.110
CSeq: 101 ACK
User-Agent: CSCO/7
Content-Length: 0
8 headers, 0 lines
11 headers, 0 lines
Reliably Transmitting:
OPTIONS sip:10.10.0.110 SIP/2.0
Via: SIP/2.0/UDP 10.10.0.6:5060;branch=z9hG4bK40f5a9b2
From: "asterisk" <sip:asterisk@10.10.0.6>;tag=as3c8e3a61
To: <sip:10.10.0.110>
Contact: <sip:asterisk@10.10.0.6>
Call-ID: 7cde84ff2190c25f12ebe7a07a8f98d7@10.10.0.6
CSeq: 102 OPTIONS
User-Agent: Asterisk PBX
Date: Wed, 20 Oct 2004 18:23:46 GMT
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER
Content-Length: 0
(no NAT) to 10.10.0.110:5060
impbx01*CLI>
Sip read:
SIP/2.0 200 OK
Via: SIP/2.0/UDP 10.10.0.6:5060;branch=z9hG4bK40f5a9b2
From: "asterisk" <sip:asterisk@10.10.0.6>;tag=as3c8e3a61
To: <sip:10.10.0.110>;tag=001193d886a3000d18ef9b5b-6e8f8846
Call-ID: 7cde84ff2190c25f12ebe7a07a8f98d7@10.10.0.6
CSeq: 102 OPTIONS
Server: CSCO/7
Content-Type: application/sdp
Content-Length: 233
Allow: OPTIONS,INVITE,BYE,CANCEL,REGISTER,ACK,NOTIFY,REFER
v=0
o=Cisco-SIPUA 0 0 IN IP4 10.10.0.110
s=SIP Call
c=IN IP4 10.10.0.110
t=0 0
m=audio 1 RTP/AVP 0 8 18 101
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:18 G729/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
10 headers, 11 lines
The INGATE engineer is pointing the finger firmly at asterisk. Any comments from the Asterisk folks? See below: Chad, The problem is that the Asterisk server is not following the RFC. Not only is it not following it in the "bad call", but it is not following it in the "good call" either. It just so happens that they are doing it "wrong" differently in each case. In the case of the "good call", things seem to work anyway despite the incorrect format of the ACK. As you will see in the excerpts from the RFC, assuming that the Asterisk is acting as a loose router, then the the remote target of the route set of this dialog is set by the Contact: header of the 200 OK. That URI should be used by the UA as the Request URI of the ACK, but it isn't. (The Asterisk is populating it Request URI with sip:12534056726@10.10.0.5 rather than sip:ecKI8yNvOZWrd2qnhDGUTZ9BvvshiozBoPrTyia6jgXy8k9Ck6bEibDBlUk2GLdml@10 .10.0.5). Therefore, the SIParator is sending the ACK where it is being told. It is just being told the wrong place. If it had received the correct URI, it would have decrypted it and sent it to the correct place. In the case of the "Good Call", the Asterisk IS populating the Request URI correctly, however, it should then include a Route header with the route set values in order. Instead, it is adding the Route header and populating it with the contents of the Contact field(sip:e_RY4_466QliT14zp26IqP6KYbo9s6ZERZM0fQuq8nzGMs71r0jwT2UOVGyjPo bFW@10.10.0.5.) It should be populating it with sip:26998a73@10.10.0.5;lr.>From RFC3261.....13.2.2.4 2xx Responses [...] The header fields of the ACK are constructed in the same way as for any request sent within a dialog (see Section 12) with the exception of the CSeq and the header fields related to authentication. 12.2.1.1 Generating the Request [...] The UAC uses the remote target and route set to build the Request-URI and Route header field of the request. If the route set is empty, the UAC MUST place the remote target URI into the Request-URI. The UAC MUST NOT add a Route header field to the request. If the route set is not empty, and the first URI in the route set contains the lr parameter (see Section 19.1.1), the UAC MUST place the remote target URI into the Request-URI and MUST include a Route header field containing the route set values in order, including all parameters. If the route set is not empty, and its first URI does not contain the lr parameter, the UAC MUST place the first URI from the route set into the Request-URI, stripping any parameters that are not allowed in a Request-URI. The UAC MUST add a Route header field containing the remainder of the route set values in order, including all parameters. The UAC MUST then place the remote target URI into the Route header field as the last value.. 200OK Sent to the Asterisk by the SIParator..... (Bad Call) SIP/2.0 200 OK To: <sip:12534056726@10.10.0.5>;tag=3307485377-144837 From: "Chad Brown" <sip:asterisk@10.10.0.6>;tag=as1ce965cb Call-ID: 539db1a427cc815b432e3c7a15e79b8e@10.10.0.6 CSeq: 102 INVITE Contact: <sip:ecKI8yNvOZWrd2qnhDGUTZ9BvvshiozBoPrTyia6jgXy8k9Ck6bEibDBlUk2GLdml@1 0.10.0.5> Content-Type: application/sdp Via: SIP/2.0/UDP 10.10.0.6:5060;branch=z9hG4bK03f598de Record-Route: <sip:4a37c67a@10.10.0.5;lr> Content-Length: 187 v=0 o=NexTone-MSW 1234 467330188 IN IP4 10.10.0.5 s=sip call c=IN IP4 10.10.0.5 t=0 0 m=audio 58024 RTP/AVP 0 a=silenceSupp:off a=ecan:b on g168 a=ptime:20 a=rtpmap:0 PCMU/8000 ACK sent back by the Asterisk.....(Bad Call) ACK sip:12534056726@10.10.0.5 SIP/2.0 Via: SIP/2.0/UDP 10.10.0.6:5060;branch=z9hG4bK78bbf6a8 Route: <sip:ecKI8yNvOZWrd2qnhDGUTZ9BvvshiozBoPrTyia6jgXy8k9Ck6bEibDBlUk2GLdml@1 0.10.0.5> From: "Chad Brown" <sip:asterisk@10.10.0.6>;tag=as1ce965cb To: <sip:12534056726@10.10.0.5>;tag=3307485377-144837 Contact: <sip:asterisk@10.10.0.6> Call-ID: 539db1a427cc815b432e3c7a15e79b8e@10.10.0.6 CSeq: 102 ACK User-Agent: Asterisk PBX Content-Length: 0 In summary, the problem is being caused by the incorrect format of the ACKs coming from the Asterisk. This should be corrected there. Please let me know if you have any questions. Thanks Shane Cleckler Mgr Systems Engineering Ingate Systems -----Original Message----- From: Chad Brown [mailto:chad.brown@identitymine.com] Sent: Friday, October 22, 2004 10:00 PM To: asterisk-users@lists.digium.com Cc: Shane Cleckler Subject: chan_sip changes affecting ACK? Are there any changes to chan_sip since 09/16/04 in the stable branch that could affect the way Asterisk issues an ACK? The reason I ask...I have a product by INGATE called the Siparator which assists in NAT traversal. It worked great until I upgraded to Asterisk v1.0. After comparing the logs it looks like asterisk may no longer like the GUID type ACK response the Siparator is expecting. Take a quick look at the difference. (BTW 10.10.0.6 is the Asterisk) Asterisk from 09/16/04:>>> Info: sipfw: recv from 10.10.0.6: ACKsip:e_RY4_466QliT14zp26IqP6KYbo9s6ZERZM0fQuq8nzGMs71r0jwT2UOVGyjPobFW@10 .10.0.5 SIP/2.0 Asterisk v1.0>>> Info: sipfw: recv from 10.10.0.6: ACK sip:12534056726@10.10.0.5SIP/2.0 My guess is that the Siparator keeps track of separate streams with the long GUID string and then does an appropriate transform. Since the GUID is gone in v1.0 so is Siparators ability to translate/transform the call. I attached the actual logs from the Siparator for any SIP gurus out there to review. Take a look at the following timestamps and what leads up to them: Badcall - 01:54:38 Goodcall - 18:56:37 Thanks for you help! Chad Brown - IdentityMine -----Original Message----- From: asterisk-users-bounces@lists.digium.com [mailto:asterisk-users-bounces@lists.digium.com] On Behalf Of Chad Brown Sent: Saturday, October 23, 2004 8:22 AM To: Asterisk Users Mailing List - Non-Commercial Discussion Subject: RE: [Asterisk-Users] chan_sip changes affecting ACK? - Bug? Olle, No...Thank you! You are the perfect guy to look at this problem as well since ultimately I need to switch to chan_sip2 given the outboundproxy functionality. My testing shows that not only stable has this issue but so does head. That said, the problem could carry over to chan_sip2. Anyway... I originally sent several log files from both the Siparator and Asterisk but the message was refused from the list because of size. Attached are 2 asterisk sip debug files. I fear that some of the information scrolled off the screen during debug. If these don't have enough information please let me know. When I get back to the office I will log sip debug to a file rather than console as I was so I don't loose anything. If you would like to see the separator logs I will need to send them to you directly because they are 300K a piece and go over the limit for this list. Thanks, Chad -----Original Message----- From: asterisk-users-bounces@lists.digium.com [mailto:asterisk-users-bounces@lists.digium.com] On Behalf Of Olle E. Johansson Sent: Saturday, October 23, 2004 2:29 AM To: Asterisk Users Mailing List - Non-Commercial Discussion Subject: Re: [Asterisk-Users] chan_sip changes affecting ACK? - Bug? Chad, I need a more complete SIP debug than just one packet to try to look into this issue. If the device registers, both a REGISTER transaction and a subsequent call with the ACK - THank you! /O _______________________________________________ Asterisk-Users mailing list Asterisk-Users@lists.digium.com http://lists.digium.com/mailman/listinfo/asterisk-users To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Donny Kavanagh
2004-Oct-25 10:04 UTC
[Asterisk-Users] chan_sip changes affecting ACK? - Bug?
You may want to post this to asterisk-dev and possibly open a bug, if all that is said is correct. Donny -----Original Message----- From: Chad Brown [mailto:chad.brown@identitymine.com] Sent: Monday, October 25, 2004 1:02 PM To: Asterisk Users Mailing List - Non-Commercial Discussion Subject: RE: [Asterisk-Users] chan_sip changes affecting ACK? - Bug? The INGATE engineer is pointing the finger firmly at asterisk. Any comments from the Asterisk folks? See below: Chad, The problem is that the Asterisk server is not following the RFC. Not only is it not following it in the "bad call", but it is not following it in the "good call" either. It just so happens that they are doing it "wrong" differently in each case. In the case of the "good call", things seem to work anyway despite the incorrect format of the ACK. As you will see in the excerpts from the RFC, assuming that the Asterisk is acting as a loose router, then the the remote target of the route set of this dialog is set by the Contact: header of the 200 OK. That URI should be used by the UA as the Request URI of the ACK, but it isn't. (The Asterisk is populating it Request URI with sip:12534056726@10.10.0.5 rather than sip:ecKI8yNvOZWrd2qnhDGUTZ9BvvshiozBoPrTyia6jgXy8k9Ck6bEibDBlUk2GLdml@10 .10.0.5). Therefore, the SIParator is sending the ACK where it is being told. It is just being told the wrong place. If it had received the correct URI, it would have decrypted it and sent it to the correct place. In the case of the "Good Call", the Asterisk IS populating the Request URI correctly, however, it should then include a Route header with the route set values in order. Instead, it is adding the Route header and populating it with the contents of the Contact field(sip:e_RY4_466QliT14zp26IqP6KYbo9s6ZERZM0fQuq8nzGMs71r0jwT2UOVGyjPo bFW@10.10.0.5.) It should be populating it with sip:26998a73@10.10.0.5;lr.>From RFC3261.....13.2.2.4 2xx Responses [...] The header fields of the ACK are constructed in the same way as for any request sent within a dialog (see Section 12) with the exception of the CSeq and the header fields related to authentication. 12.2.1.1 Generating the Request [...] The UAC uses the remote target and route set to build the Request-URI and Route header field of the request. If the route set is empty, the UAC MUST place the remote target URI into the Request-URI. The UAC MUST NOT add a Route header field to the request. If the route set is not empty, and the first URI in the route set contains the lr parameter (see Section 19.1.1), the UAC MUST place the remote target URI into the Request-URI and MUST include a Route header field containing the route set values in order, including all parameters. If the route set is not empty, and its first URI does not contain the lr parameter, the UAC MUST place the first URI from the route set into the Request-URI, stripping any parameters that are not allowed in a Request-URI. The UAC MUST add a Route header field containing the remainder of the route set values in order, including all parameters. The UAC MUST then place the remote target URI into the Route header field as the last value.. 200OK Sent to the Asterisk by the SIParator..... (Bad Call) SIP/2.0 200 OK To: <sip:12534056726@10.10.0.5>;tag=3307485377-144837 From: "Chad Brown" <sip:asterisk@10.10.0.6>;tag=as1ce965cb Call-ID: 539db1a427cc815b432e3c7a15e79b8e@10.10.0.6 CSeq: 102 INVITE Contact: <sip:ecKI8yNvOZWrd2qnhDGUTZ9BvvshiozBoPrTyia6jgXy8k9Ck6bEibDBlUk2GLdml@1 0.10.0.5> Content-Type: application/sdp Via: SIP/2.0/UDP 10.10.0.6:5060;branch=z9hG4bK03f598de Record-Route: <sip:4a37c67a@10.10.0.5;lr> Content-Length: 187 v=0 o=NexTone-MSW 1234 467330188 IN IP4 10.10.0.5 s=sip call c=IN IP4 10.10.0.5 t=0 0 m=audio 58024 RTP/AVP 0 a=silenceSupp:off a=ecan:b on g168 a=ptime:20 a=rtpmap:0 PCMU/8000 ACK sent back by the Asterisk.....(Bad Call) ACK sip:12534056726@10.10.0.5 SIP/2.0 Via: SIP/2.0/UDP 10.10.0.6:5060;branch=z9hG4bK78bbf6a8 Route: <sip:ecKI8yNvOZWrd2qnhDGUTZ9BvvshiozBoPrTyia6jgXy8k9Ck6bEibDBlUk2GLdml@1 0.10.0.5> From: "Chad Brown" <sip:asterisk@10.10.0.6>;tag=as1ce965cb To: <sip:12534056726@10.10.0.5>;tag=3307485377-144837 Contact: <sip:asterisk@10.10.0.6> Call-ID: 539db1a427cc815b432e3c7a15e79b8e@10.10.0.6 CSeq: 102 ACK User-Agent: Asterisk PBX Content-Length: 0 In summary, the problem is being caused by the incorrect format of the ACKs coming from the Asterisk. This should be corrected there. Please let me know if you have any questions. Thanks Shane Cleckler Mgr Systems Engineering Ingate Systems -----Original Message----- From: Chad Brown [mailto:chad.brown@identitymine.com] Sent: Friday, October 22, 2004 10:00 PM To: asterisk-users@lists.digium.com Cc: Shane Cleckler Subject: chan_sip changes affecting ACK? Are there any changes to chan_sip since 09/16/04 in the stable branch that could affect the way Asterisk issues an ACK? The reason I ask...I have a product by INGATE called the Siparator which assists in NAT traversal. It worked great until I upgraded to Asterisk v1.0. After comparing the logs it looks like asterisk may no longer like the GUID type ACK response the Siparator is expecting. Take a quick look at the difference. (BTW 10.10.0.6 is the Asterisk) Asterisk from 09/16/04:>>> Info: sipfw: recv from 10.10.0.6: ACKsip:e_RY4_466QliT14zp26IqP6KYbo9s6ZERZM0fQuq8nzGMs71r0jwT2UOVGyjPobFW@10 .10.0.5 SIP/2.0 Asterisk v1.0>>> Info: sipfw: recv from 10.10.0.6: ACK sip:12534056726@10.10.0.5SIP/2.0 My guess is that the Siparator keeps track of separate streams with the long GUID string and then does an appropriate transform. Since the GUID is gone in v1.0 so is Siparators ability to translate/transform the call. I attached the actual logs from the Siparator for any SIP gurus out there to review. Take a look at the following timestamps and what leads up to them: Badcall - 01:54:38 Goodcall - 18:56:37 Thanks for you help! Chad Brown - IdentityMine -----Original Message----- From: asterisk-users-bounces@lists.digium.com [mailto:asterisk-users-bounces@lists.digium.com] On Behalf Of Chad Brown Sent: Saturday, October 23, 2004 8:22 AM To: Asterisk Users Mailing List - Non-Commercial Discussion Subject: RE: [Asterisk-Users] chan_sip changes affecting ACK? - Bug? Olle, No...Thank you! You are the perfect guy to look at this problem as well since ultimately I need to switch to chan_sip2 given the outboundproxy functionality. My testing shows that not only stable has this issue but so does head. That said, the problem could carry over to chan_sip2. Anyway... I originally sent several log files from both the Siparator and Asterisk but the message was refused from the list because of size. Attached are 2 asterisk sip debug files. I fear that some of the information scrolled off the screen during debug. If these don't have enough information please let me know. When I get back to the office I will log sip debug to a file rather than console as I was so I don't loose anything. If you would like to see the separator logs I will need to send them to you directly because they are 300K a piece and go over the limit for this list. Thanks, Chad -----Original Message----- From: asterisk-users-bounces@lists.digium.com [mailto:asterisk-users-bounces@lists.digium.com] On Behalf Of Olle E. Johansson Sent: Saturday, October 23, 2004 2:29 AM To: Asterisk Users Mailing List - Non-Commercial Discussion Subject: Re: [Asterisk-Users] chan_sip changes affecting ACK? - Bug? Chad, I need a more complete SIP debug than just one packet to try to look into this issue. If the device registers, both a REGISTER transaction and a subsequent call with the ACK - THank you! /O _______________________________________________ Asterisk-Users mailing list Asterisk-Users@lists.digium.com http://lists.digium.com/mailman/listinfo/asterisk-users To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users _______________________________________________ Asterisk-Users mailing list Asterisk-Users@lists.digium.com http://lists.digium.com/mailman/listinfo/asterisk-users To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
HAHAHAHAHA I opened up a pig but not a bug. bkw> -----Original Message----- > From: asterisk-users-bounces@lists.digium.com [mailto:asterisk-users- > bounces@lists.digium.com] On Behalf Of Steve Underwood > Sent: Monday, October 25, 2004 12:17 PM > To: Asterisk Users Mailing List - Non-Commercial Discussion > Subject: Re: [Asterisk-Users] chan_sip changes affecting ACK? - Bug? > > Brian West wrote: > > >Have you opened a bug up? > > > >bkw > > > > > In biology lessons at school we did, but that was a long time ago :-) > > Steve > > _______________________________________________ > Asterisk-Users mailing list > Asterisk-Users@lists.digium.com > http://lists.digium.com/mailman/listinfo/asterisk-users > To UNSUBSCRIBE or update options visit: > http://lists.digium.com/mailman/listinfo/asterisk-users
I just wanted to get some confirmation from the asterisk side first. Well...That sounds like the next step. -----Original Message----- From: asterisk-users-bounces@lists.digium.com [mailto:asterisk-users-bounces@lists.digium.com] On Behalf Of Brian West Sent: Monday, October 25, 2004 10:08 AM To: 'Asterisk Users Mailing List - Non-Commercial Discussion' Subject: RE: [Asterisk-Users] chan_sip changes affecting ACK? - Bug? Have you opened a bug up? bkw> -----Original Message----- > From: asterisk-users-bounces@lists.digium.com [mailto:asterisk-users- > bounces@lists.digium.com] On Behalf Of Chad Brown > Sent: Monday, October 25, 2004 12:02 PM > To: Asterisk Users Mailing List - Non-Commercial Discussion > Subject: RE: [Asterisk-Users] chan_sip changes affecting ACK? - Bug? > > The INGATE engineer is pointing the finger firmly at asterisk. Any > comments from the Asterisk folks? See below: > > Chad, > The problem is that the Asterisk server is not following the RFC. Not > only is it not following it in the "bad call", but it is not following > it in the "good call" either. It just so happens that they are doingit> "wrong" differently in each case. In the case of the "good call", > things seem to work anyway despite the incorrect format of the ACK. > > As you will see in the excerpts from the RFC, assuming that theAsterisk> is acting as a loose router, then the the remote target of the routeset> of this dialog is set by the Contact: header of the 200 OK. That URI > should be used by the UA as the Request URI of the ACK, but it isn't. > (The Asterisk is populating it Request URI with > sip:12534056726@10.10.0.5 rather than >sip:ecKI8yNvOZWrd2qnhDGUTZ9BvvshiozBoPrTyia6jgXy8k9Ck6bEibDBlUk2GLdml@10> .10.0.5). Therefore, the SIParator is sending the ACK where it isbeing> told. It is just being told the wrong place. If it had received the > correct URI, it would have decrypted it and sent it to the correct > place. > > In the case of the "Good Call", the Asterisk IS populating the Request > URI correctly, however, it should then include a Route header with the > route set values in order. Instead, it is adding the Route header and > populating it with the contents of the Contact >field(sip:e_RY4_466QliT14zp26IqP6KYbo9s6ZERZM0fQuq8nzGMs71r0jwT2UOVGyjPo> bFW@10.10.0.5.) It should be populating it with > sip:26998a73@10.10.0.5;lr. > > > > >From RFC3261..... > 13.2.2.4 2xx Responses > [...] > The header fields of the ACK are constructed > in the same way as for any request sent within a dialog (seeSection> 12) with the exception of the CSeq and the header fields related to > authentication. > > 12.2.1.1 Generating the Request > [...] > The UAC uses the remote target and route set to build theRequest-URI> > and Route header field of the request. > > If the route set is empty, the UAC MUST place the remote target URI > into the Request-URI. The UAC MUST NOT add a Route header field to > the request. > > If the route set is not empty, and the first URI in the route set > contains the lr parameter (see Section 19.1.1), the UAC MUST place > the remote target URI into the Request-URI and MUST include a Route > header field containing the route set values in order, includingall> parameters. > > If the route set is not empty, and its first URI does not containthe> lr parameter, the UAC MUST place the first URI from the route set > into the Request-URI, stripping any parameters that are not allowed > in a Request-URI. The UAC MUST add a Route header field containing > the remainder of the route set values in order, including all > parameters. The UAC MUST then place the remote target URI into the > Route header field as the last value.. > > > 200OK Sent to the Asterisk by the SIParator..... (Bad Call) > > SIP/2.0 200 OK > To: <sip:12534056726@10.10.0.5>;tag=3307485377-144837 > From: "Chad Brown" <sip:asterisk@10.10.0.6>;tag=as1ce965cb > Call-ID: 539db1a427cc815b432e3c7a15e79b8e@10.10.0.6 > CSeq: 102 INVITE > Contact: ><sip:ecKI8yNvOZWrd2qnhDGUTZ9BvvshiozBoPrTyia6jgXy8k9Ck6bEibDBlUk2GLdml@1> 0.10.0.5> > Content-Type: application/sdp > Via: SIP/2.0/UDP 10.10.0.6:5060;branch=z9hG4bK03f598de > Record-Route: <sip:4a37c67a@10.10.0.5;lr> > Content-Length: 187 > > v=0 > o=NexTone-MSW 1234 467330188 IN IP4 10.10.0.5 > s=sip call > c=IN IP4 10.10.0.5 > t=0 0 > m=audio 58024 RTP/AVP 0 > a=silenceSupp:off > a=ecan:b on g168 > a=ptime:20 > a=rtpmap:0 PCMU/8000 > > > > ACK sent back by the Asterisk.....(Bad Call) > > > ACK sip:12534056726@10.10.0.5 SIP/2.0 > Via: SIP/2.0/UDP 10.10.0.6:5060;branch=z9hG4bK78bbf6a8 > Route: ><sip:ecKI8yNvOZWrd2qnhDGUTZ9BvvshiozBoPrTyia6jgXy8k9Ck6bEibDBlUk2GLdml@1> 0.10.0.5> > From: "Chad Brown" <sip:asterisk@10.10.0.6>;tag=as1ce965cb > To: <sip:12534056726@10.10.0.5>;tag=3307485377-144837 > Contact: <sip:asterisk@10.10.0.6> > Call-ID: 539db1a427cc815b432e3c7a15e79b8e@10.10.0.6 > CSeq: 102 ACK > User-Agent: Asterisk PBX > Content-Length: 0 > > > In summary, the problem is being caused by the incorrect format of the > ACKs coming from the Asterisk. This should be corrected there.Please> let me know if you have any questions. > > Thanks > Shane Cleckler > Mgr Systems Engineering > Ingate Systems > > -----Original Message----- > From: Chad Brown [mailto:chad.brown@identitymine.com] > Sent: Friday, October 22, 2004 10:00 PM > To: asterisk-users@lists.digium.com > Cc: Shane Cleckler > Subject: chan_sip changes affecting ACK? > > > Are there any changes to chan_sip since 09/16/04 in the stable branch > that could affect the way Asterisk issues an ACK? > > > > The reason I ask...I have a product by INGATE called the Siparatorwhich> assists in NAT traversal. It worked great until I upgraded to Asterisk > v1.0. After comparing the logs it looks like asterisk may no longerlike> the GUID type ACK response the Siparator is expecting. Take a quicklook> at the difference. (BTW 10.10.0.6 is the Asterisk) > > > > Asterisk from 09/16/04: > > >>> Info: sipfw: recv from 10.10.0.6: ACK >sip:e_RY4_466QliT14zp26IqP6KYbo9s6ZERZM0fQuq8nzGMs71r0jwT2UOVGyjPobFW@10> .10.0.5 SIP/2.0 > > > > Asterisk v1.0 > > >>> Info: sipfw: recv from 10.10.0.6: ACK sip:12534056726@10.10.0.5 > SIP/2.0 > > > > My guess is that the Siparator keeps track of separate streams withthe> long GUID string and then does an appropriate transform. Since theGUID> is gone in v1.0 so is Siparators ability to translate/transform the > call. > > > > I attached the actual logs from the Siparator for any SIP gurus out > there to review. Take a look at the following timestamps and whatleads> up to them: > > > > Badcall - 01:54:38 > > Goodcall - 18:56:37 > > > > Thanks for you help! > > > > Chad Brown - IdentityMine > > > -----Original Message----- > From: asterisk-users-bounces@lists.digium.com > [mailto:asterisk-users-bounces@lists.digium.com] On Behalf Of ChadBrown> Sent: Saturday, October 23, 2004 8:22 AM > To: Asterisk Users Mailing List - Non-Commercial Discussion > Subject: RE: [Asterisk-Users] chan_sip changes affecting ACK? - Bug? > > Olle, > > No...Thank you! You are the perfect guy to look at this problem aswell> since ultimately I need to switch to chan_sip2 given the outboundproxy > functionality. > > My testing shows that not only stable has this issue but so does head. > That said, the problem could carry over to chan_sip2. Anyway... > > I originally sent several log files from both the Siparator andAsterisk> but the message was refused from the list because of size. > > Attached are 2 asterisk sip debug files. I fear that some of the > information scrolled off the screen during debug. If these don't have > enough information please let me know. When I get back to the office I > will log sip debug to a file rather than console as I was so I don't > loose anything. > > If you would like to see the separator logs I will need to send themto> you directly because they are 300K a piece and go over the limit for > this list. > > Thanks, > > Chad > > -----Original Message----- > From: asterisk-users-bounces@lists.digium.com > [mailto:asterisk-users-bounces@lists.digium.com] On Behalf Of Olle E. > Johansson > Sent: Saturday, October 23, 2004 2:29 AM > To: Asterisk Users Mailing List - Non-Commercial Discussion > Subject: Re: [Asterisk-Users] chan_sip changes affecting ACK? - Bug? > > Chad, > I need a more complete SIP debug than just one packet to try to look > into this > issue. If the device registers, both a REGISTER transaction and a > subsequent > call with the ACK - THank you! > > /O > _______________________________________________ > Asterisk-Users mailing list > Asterisk-Users@lists.digium.com > http://lists.digium.com/mailman/listinfo/asterisk-users > To UNSUBSCRIBE or update options visit: > http://lists.digium.com/mailman/listinfo/asterisk-users > > > > > _______________________________________________ > Asterisk-Users mailing list > Asterisk-Users@lists.digium.com > http://lists.digium.com/mailman/listinfo/asterisk-users > To UNSUBSCRIBE or update options visit: > http://lists.digium.com/mailman/listinfo/asterisk-users_______________________________________________ Asterisk-Users mailing list Asterisk-Users@lists.digium.com http://lists.digium.com/mailman/listinfo/asterisk-users To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users