[Home]

Summary:ASTERISK-02707: Wrong Request URI - RFC3261
Reporter:chadbrown (chadbrown)Labels:
Date Opened:2004-10-29 20:18:28Date Closed:2004-10-30 11:20:24
Priority:MajorRegression?No
Status:Closed/CompleteComponents:Channels/chan_sip/Interoperability
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:( 0) Asterisk_Sip_Debug_badv2.txt
Description:This bug was found while testing a device by INGATE called the SIParator for the purposes of traversing NAT.

The Siparator's job is to help SIP traverse NATs. In our scenerio it's function is rather simple:

Asterisk <--------> Siparator <-------->Broadvox

10.10.0.6    10.10.0.5/67.136.5.30     66.243.109.210


Both inbound and outbound sip traffic was routed through the siparator without any problems on Asterisk Stable from 09/16/04.

However, something changed in chan_sip shortly after that time which broke our solution. All current CVS head and Stable builds have the same problem described in the "additional information" section.

Please note that I included an output from sip debug. I also have comparison logs of both a good and bad call for both Asterisk and SIParator. If needed I can provide them.

****** ADDITIONAL INFORMATION ******

I traced the problem with outbound calls to an improper ACK. After forwarding several logs to INGATE tech support they sent me the following detail:

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_466QliT14zp26IqP6KYbo9s6ZERZM0fQuq8nzGMs71r0jwT2UOVGyjPobFW@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@10.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@10.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
Comments:By: chadbrown (chadbrown) 2004-10-29 20:35:24

It looks like this may be a duplicate of a post 2687. I applogize for any confusion. At a minimum I hope the additional information and log can be helpfull to your effort.

I have advanced logs ready to upload from both Asterisk and SIParator. If this would be helpful please let me know.

Thanks in advance for your consideration.
By: Brian West (bkw918) 2004-10-29 20:36:59

Please post to 2687 and read the posting guidlines.  This is not a MAJOR bug.