[Asterisk-Users] chan_sip changes affecting ACK? - Bug?
Chad Brown
chad.brown at identitymine.com
Mon Oct 25 11:10:34 MST 2004
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 at lists.digium.com
[mailto:asterisk-users-bounces at 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 at lists.digium.com [mailto:asterisk-users-
> bounces at 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 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 at 10.10.0.5 rather than
>
sip:ecKI8yNvOZWrd2qnhDGUTZ9BvvshiozBoPrTyia6jgXy8k9Ck6bEibDBlUk2GLdml at 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 at 10.10.0.5.) It should be populating it with
> sip:26998a73 at 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 at 10.10.0.5>;tag=3307485377-144837
> From: "Chad Brown" <sip:asterisk at 10.10.0.6>;tag=as1ce965cb
> Call-ID: 539db1a427cc815b432e3c7a15e79b8e at 10.10.0.6
> CSeq: 102 INVITE
> Contact:
>
<sip:ecKI8yNvOZWrd2qnhDGUTZ9BvvshiozBoPrTyia6jgXy8k9Ck6bEibDBlUk2GLdml at 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 at 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 at 10.10.0.5 SIP/2.0
> Via: SIP/2.0/UDP 10.10.0.6:5060;branch=z9hG4bK78bbf6a8
> Route:
>
<sip:ecKI8yNvOZWrd2qnhDGUTZ9BvvshiozBoPrTyia6jgXy8k9Ck6bEibDBlUk2GLdml at 1
> 0.10.0.5>
> From: "Chad Brown" <sip:asterisk at 10.10.0.6>;tag=as1ce965cb
> To: <sip:12534056726 at 10.10.0.5>;tag=3307485377-144837
> Contact: <sip:asterisk at 10.10.0.6>
> Call-ID: 539db1a427cc815b432e3c7a15e79b8e at 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 at identitymine.com]
> Sent: Friday, October 22, 2004 10:00 PM
> To: asterisk-users at 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: ACK
>
sip:e_RY4_466QliT14zp26IqP6KYbo9s6ZERZM0fQuq8nzGMs71r0jwT2UOVGyjPobFW at 10
> .10.0.5 SIP/2.0
>
>
>
> Asterisk v1.0
>
> >>> Info: sipfw: recv from 10.10.0.6: ACK sip:12534056726 at 10.10.0.5
> SIP/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 at lists.digium.com
> [mailto:asterisk-users-bounces at 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 at lists.digium.com
> [mailto:asterisk-users-bounces at 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 at 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 at 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 at 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
More information about the asterisk-users
mailing list