[Asterisk-Dev] chan_sip bug

Thu Nov 4 16:33:51 MST 2004

Greetings Chad et al,

            Having been in the chan_sip.c up to my eyebrows making major
changes for the last two months I believe you should go ahead and open
the bug just to get the problem logged and noted.

            Having said that, the chan_sip.c code openly refers to the
RFC headache you are describing as the !@%^%&*&^%$#  SIP problem and the
confusion it causes even the programmers.

            If I am guessing right this is an MD5 string in the wrong
place problem. 

Do you still get problem when the md5secret or the secret is not used.?

            If you can post more of the "sip debug" output I can help
you create the fix and you can change the code on your box and
recompile.

            Race Vanderdecken

-----Original Message-----
From: asterisk-dev-bounces at lists.digium.com
[mailto:asterisk-dev-bounces at lists.digium.com] On Behalf Of Chad Brown
Sent: 29 October 2004 15:05
To: asterisk-dev at lists.digium.com
Subject: [Asterisk-Dev] chan_sip bug

Team,

I am experiencing a sip problem when using a device by INGATE called the
SIParator for the purposes of traversing NAT. The advice I received from
Digium was to open a bug. However, I thought that before I did that I
would post to this list and ask for opinions.

The INGATE engineer is pointing the finger firmly at asterisk. See
INGATE's response to my problem 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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.digium.com/pipermail/asterisk-dev/attachments/20041104/f14c3404/attachment.htm