[Home]

Summary:ASTERISK-03529: [patch - bugfix] Requests inside a dialog and strict routing vs. loose routing
Reporter:chuck_ramirez (chuck_ramirez)Labels:
Date Opened:2005-02-16 10:48:29.000-0600Date Closed:2008-01-15 15:46:04.000-0600
Priority:MinorRegression?No
Status:Closed/CompleteComponents:Channels/chan_sip/Interoperability
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:( 0) chan_sip.c.diff
( 1) chan_sip.c.diff
( 2) strictroute.txt
( 3) chan_sip.c.3609.diff
( 4) chan_sip-HEAD-20050521.patch
Description:Asterisk misbehaves when making a request inside a dialog and the next hop is a strict router (ie, no ;lr in record route).

It always uses contact information at R-URI, which is not true. When the next hop is a strict router it should use the next hop information as the R-URI as per RFC3261.

>From RFC3261.....


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.

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

I'm sending some captures (ngrep) along with my
comments.

This is a 200 OK (INVITE) received by Asterisk

=========================
U 2005/02/10 16:41:55.065538 143.173.202.82:5060 -> 143.173.202.83:5070
 SIP/2.0 200 OK..Via: SIP/2.0/UDP
143.173.202.83:5070;branch=z9hG4bK42c78895..Record-Route:
<sip:001178612341106@143.173.
 202.81;ftag=as182aa61c;lr>..Record-Route:
<sip:001178612341106@143.173.202.82:5060>..From: "Call
Center 1" <sip:55512@si
 p.trdc.telenova.com.br>;tag=as182aa61c..To:
<sip:001178612341106@sip.com>;tag=281B1720-1D3C..Call-ID:
3
 e3b393c407188e9311d01a03e43f144@sip.com..CSeq: 103
INVITE..Contact: <sip:747#1178612341106@143.173.194.
 37:5060>..date: Thu, 10 Feb 2005 20:41:43
GMT..server: Cisco-SIPGateway/IOS-12.x..allow-events:
telephone-event..Allow:
  INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, COMET,
REFER, SUBSCRIBE, NOTIFY, INFO..Content-Type:
application/sdp..Conten
 t-Length:  
257....v=0..o=CiscoSystemsSIP-GW-UserAgent 2591 2076
IN IP4 143.173.194.37..s=SIP Call..c=IN IP4 143.173.19
 4.37..t=0 0..m=audio 19458 RTP/AVP 18 100..c=IN IP4
143.173.194.37..a=rtpmap:18 G729/8000..a=fmtp:18
annexb=no..a=rtpma
 p:100 X-NSE/8000..a=fmtp:100 192-194..
=================================

At this point Asterisk builds a route list for
subsequent requests (record routes + contacts):

sip:001178612341106@143.173.202.82:5060
sip:001178612341106@143.173.202.81;ftag=as182aa61c;lr
sip:747#1178612341106@143.173.194.37:5060

But when Asterisk sends a BYE for this call:

=======================================
U 2005/02/10 16:41:57.400529 143.173.202.83:5070 ->
143.173.202.82:5060
 BYE sip:747#1178612341106@143.173.194.37:5060
SIP/2.0..Via: SIP/2.0/UDP
143.173.202.83:5070;branch=z9hG4bK67ce783e..Rout
 e:
<sip:001178612341106@143.173.202.81;ftag=as182aa61c;lr>,<sip:747#1178612341106@143.173.194.37:5060>..From:
"Call Cente
 r 1" <sip:55512@sip.com>;tag=as182aa61c..To:
<sip:001178612341106@sip.com>;tag=281B172
 0-1D3C..Contact:
<sip:55512@143.173.202.83:5070>..Call-ID:
3e3b393c407188e9311d01a03e43f144@sip.com..C
 Seq: 104 BYE..User-Agent: Asterisk
PBX..Proxy-Authorization: Digest username="55512",
realm="sip.com",
  algorithm=MD5,
uri="sip:747#1178612341106@143.173.194.37:5060",
nonce="420bc833181bca085f953885ace7fc72c107c8e0",
respo
 nse="75fcd1bf185ae29becd0b4f715f5cb17",
opaque=""..Content-Length: 0....
===========================================

As we can see it is using the contact as the URI of
this request, which also appears as the last route
header.

As per RFC3261 (16.12.1) if the next hop is a strict
router (no ;lr in route header) it should use that
information as the R-URI, which is not the behaviour
of Asterisk.

Moreover, it should include all routes learned in the
request Route header (including the one that will
receive the request) when we are treating with loose
routers.

I have provided a simple fix in the reqp function that should work for most cases. If you need that (as it is not 100% according RFC), please let me know (then I will sign the disclaimer)
Comments:By: Mark Spencer (markster) 2005-02-16 15:05:43.000-0600

At what point in SIP's creation did this seem like a good idea?
By: chuck_ramirez (chuck_ramirez) 2005-02-16 16:08:12.000-0600

Before calling init_req, instead of always using p->okcontacturi as the new URI in request it should have another test, looking for ;lr in p->route->hop

If ;lr is not present, then the new URI should be p->route->hop, as it is a strict router.

In this case the route headers will be OK, as you are already using p->route->next as the first route header.
By: nick (nick) 2005-02-16 16:37:35.000-0600

Why don't you post your patch so that we at least have something to work off of...

Nick
By: chuck_ramirez (chuck_ramirez) 2005-02-17 10:06:21.000-0600

I've attached a patch over HEAD 17-02-2005.

For me works fine with both loose and strict routers.

Cheers.
By: Olle Johansson (oej) 2005-02-17 10:42:18.000-0600

This is propably what I wanted to solve previously but could not figure out how to do it. I will test this patch and report back.

Chuck_ramirez: Thank you for contributing. We need a disclaimer for this source in order to work with it. See the bug tracker instructions.
By: Olle Johansson (oej) 2005-02-17 10:49:21.000-0600

YOur patch file is backwards, removing your new stuff (the minus signs) ;-)

So if the routing header goes in the contact field, I guess we need to add our okcontact to the end of the routing table, right?
By: chuck_ramirez (chuck_ramirez) 2005-02-17 12:56:56.000-0600

Sorry for the backwards patch! I'm sending the forward patch! :)

The "okcontacturi" is already at the end of routing table (the routing table is built at build_route: it uses Record-Route headers plus contacts).

To be 100% according to the RFC the "okcontacturi" should not be used in route headers when the next hop is a loose router (but this is not a huge problem).
By: Olle Johansson (oej) 2005-02-18 07:28:53.000-0600

Please confirm your disclaimer...
By: chuck_ramirez (chuck_ramirez) 2005-02-18 08:48:57.000-0600

The disclaimer was sent yesterday evening.
By: Mark Spencer (markster) 2005-03-01 00:32:25.000-0600

This patch does not appear to apply to CVS head :(  Did the tabs get converted to spaces perhaps?  I can probably manually merge it...  Also, I'm not sure I understand what else is required for true RFC complaince...  Can you explain?
By: chuck_ramirez (chuck_ramirez) 2005-03-14 14:33:39.000-0600

Sorry for the delayed response.

Suppose that you receive a 200 OK with the information below (only loose routers):

Record-Route: <b@proxy2.com;lr>
Record-Route: <a@proxy1.com;lr>
Contact: sip:endpoint@user.com

Then, a request inside that dialog MUST have:

R-URI: sip:endpoint@user.com (as in Contact header)
Route: <b@proxy2.com;lr>,<a@proxy1.com;lr>

What Asterisk currently does is:

R-URI: sip:endpoint@user.com (as in Contact header)
Route: <a@proxy1.com;lr>,<endpoint@user.com>


Now, suppose that you receive a 200 OK with the information below (the next hop is a strict router):

Record-Route: <b@proxy2.com>
Record-Route: <a@proxy1.com;lr>
Contact: sip:endpoint@user.com

Then, a request inside that dialog MUST have:

R-URI: sip:b@proxy2.com
Route: <a@proxy1.com;lr>,<endpoint@user.com>

What Asterisk currently does is:

R-URI: sip:endpoint@user.com (as in Contact header)
Route: <a@proxy1.com;lr>,<endpoint@user.com>


There are two examples in RFC3261 at section 16.12.1 that explain the strict and loose routing procedures.
By: Olle Johansson (oej) 2005-03-17 07:29:03.000-0600

Patch for CVS head uploaded. Can't test it, haven't got any strict routing in my network. From reading the patch, this is what I said earlier that we didn't solve with my earlier contact patch.

I haven't changed anything but spelling, but have disclaimer on file anyway.

Let's add this to CVS and get feedback. THen we can concentrate on loose routing.
By: chuck_ramirez (chuck_ramirez) 2005-03-22 09:43:32.000-0600

To be 100% according to RFC3261 - when we are dealing with loose routers - the last hop in the route list (p->route) should no be added to "Route" header. That hop is already at the URI.
By: Terry Wilson (twilson) 2005-04-11 11:25:09

Reminder sent to chuck_ramirez, oej

Not a marshall, but thought I'd see if this fixed or not.
By: gdalgliesh (gdalgliesh) 2005-05-18 15:50:49

Anyone have patch that works with current CVS head as of 5/18/05?

[root@asterisk asterisk]# patch -p0 -F5 < /root/software/chan_sip.patch
patching file channels/chan_sip.c
Hunk #1 succeeded at 3510 (offset 268 lines).
Hunk #2 succeeded at 3300 (offset 1 line).
Hunk #3 FAILED at 3315.
Hunk #4 succeeded at 3627 (offset 268 lines).
1 out of 4 hunks FAILED -- saving rejects to file channels/chan_sip.c.rej
By: gdalgliesh (gdalgliesh) 2005-05-21 01:36:06

I have uploaded a current version of patch for HEAD after applying the HUNK 3 manually.

It appears that a patch although has some improvement related
R-URI: sip:endpoint@user.com being taken from Contact header is a previous Note indicates it should although it Route: statement still seem to be wrong.

BUT a bigger problem is that if asterisk gets back a 486 it crashes.

--- (8 headers 0 lines)---
asterisk*CLI>
<-- SIP read from 69.1.2.31:5068:
SIP/2.0 486 Busy
Via: SIP/2.0/UDP 64.1.2.5:5060;branch=z9hG4bK62988f50
From: "4431110293" <sip:4431110293@64.1.2.5>;tag=as692e5693
To: <sip:4101118556@69.1.2.31:5068>;tag=2d05ce6a77aa42df
Call-ID: 180ca6305426872a3bd1929b75046fbd@64.1.2.5
CSeq: 102 INVITE
User-Agent: Grandstream BT100 1.0.5.16
Content-Length: 0


--- (8 headers 0 lines)---
   -- Got SIP response 486 "Busy" back from 69.1.2.31
asterisk*CLI>
Disconnected from Asterisk server
Executing last minute cleanups
Asterisk cleanly ending (0).
By: davetroy (davetroy) 2005-07-01 16:29:28

1) Please disregard chan_sip-HEAD-20050521.patch; contains some test code and is not correct.

2) Please see new patch chan_sip.c.3609.diff.  This patch to current CVS head adds on to the code as originally submitted and takes care of the statement in RFC3261 that, "If the route set is not empty, and its first URI does not contain the lr parameter... the UAC MUST then place the remote target URI into the Route header field as the last value."  Conversely, if lr is present, then we MUST NOT place the remote target URI intot he Route header field as the last value.

The attached patch addresses this problem, which has not yet been addressed.  Seems to be better behaved in our testing; request addition to CVS.  I have a disclaimer on file.
By: Olle Johansson (oej) 2005-07-20 12:53:30

Will test this now. Anyone else that has tested this patch?
By: Olle Johansson (oej) 2005-08-28 21:27:25

Seems like a working patch.
By: Kevin P. Fleming (kpfleming) 2005-08-29 19:02:47

Committed to CVS HEAD, thanks!
By: Digium Subversion (svnbot) 2008-01-15 15:46:04.000-0600

Repository: asterisk
Revision: 6443

U   trunk/channels/chan_sip.c

------------------------------------------------------------------------
r6443 | kpfleming | 2008-01-15 15:46:03 -0600 (Tue, 15 Jan 2008) | 2 lines

use proper next hop in strict routing mode (issue ASTERISK-3529)

------------------------------------------------------------------------

http://svn.digium.com/view/asterisk?view=rev&revision=6443