[Asterisk-Users] chan_sip changes affecting ACK? - Bug?

Brian West brian at bkw.org
Mon Oct 25 10:08:21 MST 2004


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




More information about the asterisk-users mailing list