I just wanted to get some confirmation from the asterisk side first. Well...That sounds like the next step.
-----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] 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: [EMAIL PROTECTED] [mailto:asterisk-users- > [EMAIL PROTECTED] 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:[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 _______________________________________________ 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
