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:[EMAIL PROTECTED] 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:[EMAIL PROTECTED] rather than sip:[EMAIL PROTECTED] .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 [EMAIL PROTECTED]) It should be populating it with sip:[EMAIL PROTECTED];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:[EMAIL PROTECTED]>;tag=3307485377-144837 From: "Chad Brown" <sip:[EMAIL PROTECTED]>;tag=as1ce965cb Call-ID: [EMAIL PROTECTED] CSeq: 102 INVITE Contact: <sip:[EMAIL PROTECTED] 0.10.0.5> Content-Type: application/sdp Via: SIP/2.0/UDP 10.10.0.6:5060;branch=z9hG4bK03f598de Record-Route: <sip:[EMAIL PROTECTED];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:[EMAIL PROTECTED] SIP/2.0 Via: SIP/2.0/UDP 10.10.0.6:5060;branch=z9hG4bK78bbf6a8 Route: <sip:[EMAIL PROTECTED] 0.10.0.5> From: "Chad Brown" <sip:[EMAIL PROTECTED]>;tag=as1ce965cb To: <sip:[EMAIL PROTECTED]>;tag=3307485377-144837 Contact: <sip:[EMAIL PROTECTED]> Call-ID: [EMAIL PROTECTED] 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:[EMAIL PROTECTED] Sent: Friday, October 22, 2004 10:00 PM To: [EMAIL PROTECTED] 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:[EMAIL PROTECTED] .10.0.5 SIP/2.0 Asterisk v1.0 >>> Info: sipfw: recv from 10.10.0.6: ACK sip:[EMAIL PROTECTED] 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: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] 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: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] 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 [EMAIL PROTECTED] 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 [EMAIL PROTECTED] 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 [EMAIL PROTECTED] http://lists.digium.com/mailman/listinfo/asterisk-users To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
