[Asterisk-Users] chan_sip changes affecting ACK? - Bug?

Mon Oct 25 10:02:17 MST 2004

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: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

 -----Original Message-----  
From: Chad Brown [mailto:chad.brown at identitymine.com]
Sent: Friday, October 22, 2004 10:00 PM
To: asterisk-users at lists.digium.com
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:e_RY4_466QliT14zp26IqP6KYbo9s6ZERZM0fQuq8nzGMs71r0jwT2UOVGyjPobFW at 10
.10.0.5 SIP/2.0

Asterisk v1.0

>>> Info: sipfw: recv from 10.10.0.6: ACK sip:12534056726 at 10.10.0.5
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: asterisk-users-bounces at lists.digium.com
[mailto:asterisk-users-bounces at lists.digium.com] 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: asterisk-users-bounces at lists.digium.com
[mailto:asterisk-users-bounces at lists.digium.com] 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
Asterisk-Users at lists.digium.com
http://lists.digium.com/mailman/listinfo/asterisk-users
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-users