[Asterisk-Dev] chan_sip bug

Fri Oct 29 12:05:19 MST 2004

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/20041029/be6f7e13/attachment.htm