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-0600 | Date Closed: | 2008-01-15 15:46:04.000-0600 |
Priority: | Minor | Regression? | No |
Status: | Closed/Complete | Components: | 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 |