[Home]

Summary:ASTERISK-06082: [branch] Errors in support for SIP strict routing
Reporter:Daniel Leeds (daniel leeds)Labels:
Date Opened:2006-01-14 16:21:08.000-0600Date Closed:2011-06-07 14:03:11
Priority:MajorRegression?No
Status:Closed/CompleteComponents:Core/General
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:( 0) SVN-trunk-r8687-debug.txt
Description:Asterisk ignores the information in “Record-Route” headers and thus breaks compliance with SIP RFC 3261.
This lack of compliance often results in wrong Request-URI after the BYE and REFER methods.
Consequently the applications HangUp() and Transfer() do not work properly in many scenarios.

Most acutely Asterisk is not in compliance with RFC-3261, Section: 12.2.1.1 and the following statement:
“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…”

Notice that this processing of the route set is MANDATORY in SIP implementations, and the “route sets” are defined by the “Record-Route” headers.

Please see quotations from RFC-3261 and Asterisk SIP Debug Output below in Additional Information:


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

RFC 3261, Section: 8.1.1.1 - Request-URI
“In some special circumstances, the presence of a pre-existing route set can affect the Request-URI of the message.  A pre-existing route set is an ordered set of URIs that identify a chain of servers, to which a UAC will send outgoing requests that are outside of a dialog. Commonly, they are configured on the UA by a user or service provider manually, or through some other non-SIP mechanism.  When a provider wishes to configure a UA with an outbound proxy, it is RECOMMENDED that this be done by providing it with a pre-existing route set with a single URI, that of the outbound proxy.

When a pre-existing route set is present, the procedures for populating the Request-URI and Route header field detailed in Section 12.2.1.1 MUST be followed (even though there is no dialog), using the desired Request-URI as the remote target URI.”

RFC 3261, Section: 12.1.1 - UAS behavior

“The route set MUST be set to the list of URIs in the Record-Route header field from the request, taken in order and preserving all URI parameters.  If no Record-Route header field is present in the request, the route set MUST be set to the empty set.  This route set, even if empty, overrides any pre-existing route set for future requests in this dialog.  The remote target MUST be set to the URI from the Contact header field of the request.”

RFC 3261, Section: 12.1.2 - UAC Behavior
The route set MUST be set to the list of URIs in the Record-Route header field from the response, taken in reverse order and preserving all URI parameters.  If no Record-Route header field is present in the response, the route set MUST be set to the empty set.  This route set, even if empty, overrides any pre-existing route set for future requests in this dialog.  The remote target MUST be set to the URI from the Contact header field of the response.

RFC 3261, Section: 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.

   For example, if the remote target is sip:user@remoteua and the route set contains:         <sip:proxy1>,<sip:proxy2>,<sip:proxy3;lr>,<sip:proxy4>
   The request will be formed with the following Request-URI and Route header field:    METHOD sip:proxy1
Route: <sip:proxy2>,<sip:proxy3;lr>,<sip:proxy4>,<sip:user@remoteua>

If the first URI of the route set does not contain the lr parameter, the proxy indicated does not understand the routing mechanisms described in this document and will act as specified in RFC 2543, replacing the Request-URI with the first Route header field value it receives while forwarding the message.  Placing the Request-URI at the end of the Route header field preserves the information in that Request-URI across the strict router (it will be returned to the Request-URI when the request reaches a loose- router).”  

RFC 3261, Definitions (page 24):
“Route Set: A route set is a collection of ordered SIP or SIPS URI which represent a list of proxies that must be traversed when sending a particular request.  A route set can be learned, through headers like Record-Route, or it can be configured”.

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

####################################################
# Below is Asterisk v1.2.1 SIP debug output        #
# of answering an incoming call and hanging up.    #
# Note that the Request-URI in the BYE method      #
# is wrong, as it does not account for the         #
# topmost Record-Route: header in the original     #
# incoming INVITE request.                         #
# The Request-URI after BYE should be:             #
# <sip:pstin_7748712@sphone.vopr.vonage.net:5061>  #
####################################################


<-- SIP read rom sphone.vopr.vonage.net:5061:
INVITE sip:pstin_7748712@asterisk.aa.eu:5060;suppress-features=- SIP/2.0
Via: SIP/2.0/UDP sphone.vopr.vonage.net:5061
Via: SIP/2.0/UDP inbound4.vonage.net:5060
Via: SIP/2.0/UDP transit.vonage.net:5060;branch=z9hG4bK15FF
Record-Route: <sip:pstin_7748712@sphone.vopr.vonage.net:5061>
Record-Route: <sip:pstin_7748712@inbound4.vonage.net:5060>
From: “pstn_1234567”<sip:transit.vonage.net>;tag=428326453
To: <sip:pstin_7748712@inbound4.vonage.net>
Call-ID: 4F93F317-836F11DA-B684B29D-2266172B@transit.vonage.net
CSeq: 101 INVITE
Contact: <sip:transit.vonage.net:5060>;rtpupdated=-
Max-Forwards: 13
Content-Type: application/sdp
Content-Length:   355

v=0
o=CiscoSystemsSIP-GW-UserAgent 3846 5784 IN IP4 transit.vonage.net
s=SIP Call
c=IN IP4 transit.vonage.net
t=0 0
m=audio 19064 RTP/AVP 0 18 2 100 101
c=IN IP4 transit.vonage.net
a=rtpmap:0 PCMU/8000
a=rtpmap:18 G729/8000
a=fmtp:18 annexb=no
a=rtpmap:2 G726-32/8000
a=rtpmap:100 X-NSE/8000
a=fmtp:100 192-194
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16

Reliably Transmitting (no NAT) to sphone.vopr.vonage.net:5061:
SIP/2.0 200 OK
Via: SIP/2.0/UDP sphone.vopr.vonage.net:5061;received=sphone.vopr.vonage.net
Via: SIP/2.0/UDP inbound4.vonage.net:5060
Via: SIP/2.0/UDP transit.vonage.net:5060;branch=z9hG4bK15FF
Record-Route: <sip:pstin_7748712@sphone.vopr.vonage.net:5061>
Record-Route: <sip:pstin_7748712@inbound4.vonage.net:5060>
From: “pstn_1234567”<sip:transit.vonage.net>;tag=428326453
To: <sip:pstin_7748712@inbound4.vonage.net>;tag=as108211ae
Call-ID: 4F93F317-836F11DA-B684B29D-2266172B@transit.vonage.net
CSeq: 101 INVITE
User-Agent: Asterisk v1.2.1
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY
Max-Forwards: 70
Contact: <sip:pstin_7748712@asterisk.aa.eu>
Content-Type: application/sdp
Content-Length: 486

v=0
o=root 3084 3084 IN IP4 asterisk.aa.eu
s=session
c=IN IP4 asterisk.aa.eu
t=0 0
m=audio 18628 RTP/AVP 4 18 3 0 8 2 5 10 7 110 97 101
a=rtpmap:4 G723/8000
a=rtpmap:18 G729/8000
a=fmtp:18 annexb=no
a=rtpmap:3 GSM/8000
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:2 G726-32/8000
a=rtpmap:5 DVI4/8000
a=rtpmap:10 L16/8000
a=rtpmap:7 LPC/8000
a=rtpmap:110 speex/8000
a=rtpmap:97 iLBC/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=silenceSupp:off - - - -


<-- SIP read from sphone.vopr.vonage.net:5061:
ACK sip:pstin_7748712@asterisk.aa.eu:5060 SIP/2.0
Via: SIP/2.0/UDP sphone.vopr.vonage.net:5061
Via: SIP/2.0/UDP inbound4.vonage.net:5060
Via: SIP/2.0/UDP transit.vonage.net:5060;branch=z9hG4bKD9C
From: “pstn_1234567”<sip:transit.vonage.net>;tag=428326453
To: <sip:pstin_7748712@inbound4.vonage.net>;tag=as108211ae
Call-ID: 4F93F317-836F11DA-B684B29D-2266172B@transit.vonage.net
CSeq: 101 ACK
Max-Forwards: 13
Content-Length: 0


Reliably Transmitting (no NAT) to sphone.vopr.vonage.net:5061:
BYE sip:transit.vonage.net:5060 SIP/2.0
Via: SIP/2.0/UDP asterisk.aa.eu:5060;branch=z9hG4bK5a430a24;rport
Route: <sip:pstin_7748712@inbound4.vonage.net:5060>,<sip:transit.vonage.net:5060>
From: <sip:pstin_7748712@inbound4.vonage.net>;tag=as108211ae
To: “pstn_1234567”<sip:transit.vonage.net>;tag=428326453
Contact: <sip:pstin_7748712@asterisk.aa.eu>
Call-ID: 4F93F317-836F11DA-B684B29D-2266172B@transit.vonage.net
CSeq: 103 BYE
User-Agent: Asterisk v1.2.1
Max-Forwards: 70
Proxy-Authorization: Digest username="pstin_7748712", realm="sphone.vopr.vonage.net", algorithm=MD5, uri="sip:sphone.vopr.vonage.net", nonce="455097506", response="4e2131ede158b2f71ce3bea4a7cb04c7", opaque=""
Date: Fri, 13 Jan 2006 03:28:26 GMT
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY
Content-Length: 0

#####################################################
# Here note that Asterisk did not get a reply to    #
# its BYE request because the Request-URI was wrong #
#####################################################

Retransmitting #1 (no NAT) to sphone.vopr.vonage.net:5061:
BYE sip:transit.vonage.net:5060 SIP/2.0
Via: SIP/2.0/UDP asterisk.aa.eu:5060;branch=z9hG4bK5a430a24;rport
Route: <sip:pstin_7748712@inbound4.vonage.net:5060>,<sip:transit.vonage.net:5060>
From: <sip:pstin_7748712@inbound4.vonage.net>;tag=as108211ae
To: “pstn_1234567”<sip:transit.vonage.net>;tag=428326453
Contact: <sip:pstin_7748712@asterisk.aa.eu>
Call-ID: 4F93F317-836F11DA-B684B29D-2266172B@transit.vonage.net
CSeq: 103 BYE
User-Agent: Asterisk v1.2.1
Max-Forwards: 70
Proxy-Authorization: Digest username="pstin_7748712", realm="sphone.vopr.vonage.net", algorithm=MD5, uri="sip:sphone.vopr.vonage.net", nonce="455097506", response="4e2131ede158b2f71ce3bea4a7cb04c7", opaque=""
Date: Fri, 13 Jan 2006 03:28:26 GMT
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY
Content-Length: 0

Retransmitting #2 (no NAT) to sphone.vopr.vonage.net:5061:
BYE sip:transit.vonage.net:5060 SIP/2.0
Via: SIP/2.0/UDP asterisk.aa.eu:5060;branch=z9hG4bK5a430a24;rport
Route: <sip:pstin_7748712@inbound4.vonage.net:5060>,<sip:transit.vonage.net:5060>
From: <sip:pstin_7748712@inbound4.vonage.net>;tag=as108211ae
To: “pstn_1234567”<sip:transit.vonage.net>;tag=428326453
Contact: <sip:pstin_7748712@asterisk.aa.eu>
Call-ID: 4F93F317-836F11DA-B684B29D-2266172B@transit.vonage.net
CSeq: 103 BYE
User-Agent: Asterisk v1.2.1
Max-Forwards: 70
Proxy-Authorization: Digest username="pstin_7748712", realm="sphone.vopr.vonage.net", algorithm=MD5, uri="sip:sphone.vopr.vonage.net", nonce="455097506", response="4e2131ede158b2f71ce3bea4a7cb04c7", opaque=""
Date: Fri, 13 Jan 2006 03:28:26 GMT
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY
Content-Length: 0


Retransmitting #3 (no NAT) to sphone.vopr.vonage.net:5061:
BYE sip:transit.vonage.net:5060 SIP/2.0
Via: SIP/2.0/UDP asterisk.aa.eu:5060;branch=z9hG4bK5a430a24;rport
Route: <sip:pstin_7748712@inbound4.vonage.net:5060>,<sip:transit.vonage.net:5060>
From: <sip:pstin_7748712@inbound4.vonage.net>;tag=as108211ae
To: “pstn_1234567”<sip:transit.vonage.net>;tag=428326453
Contact: <sip:pstin_7748712@asterisk.aa.eu>
Call-ID: 4F93F317-836F11DA-B684B29D-2266172B@transit.vonage.net
CSeq: 103 BYE
User-Agent: Asterisk v1.2.1
Max-Forwards: 70
Proxy-Authorization: Digest username="pstin_7748712", realm="sphone.vopr.vonage.net", algorithm=MD5, uri="sip:sphone.vopr.vonage.net", nonce="455097506", response="4e2131ede158b2f71ce3bea4a7cb04c7", opaque=""
Date: Fri, 13 Jan 2006 03:28:26 GMT
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY
Content-Length: 0


Retransmitting #4 (no NAT) to sphone.vopr.vonage.net:5061:
BYE sip:transit.vonage.net:5060 SIP/2.0
Via: SIP/2.0/UDP asterisk.aa.eu:5060;branch=z9hG4bK5a430a24;rport
Route: <sip:pstin_7748712@inbound4.vonage.net:5060>,<sip:transit.vonage.net:5060>
From: <sip:pstin_7748712@inbound4.vonage.net>;tag=as108211ae
To: “pstn_1234567”<sip:transit.vonage.net>;tag=428326453
Contact: <sip:pstin_7748712@asterisk.aa.eu>
Call-ID: 4F93F317-836F11DA-B684B29D-2266172B@transit.vonage.net
CSeq: 103 BYE
User-Agent: Asterisk v1.2.1
Max-Forwards: 70
Proxy-Authorization: Digest username="pstin_7748712", realm="sphone.vopr.vonage.net", algorithm=MD5, uri="sip:sphone.vopr.vonage.net", nonce="455097506", response="4e2131ede158b2f71ce3bea4a7cb04c7", opaque=""
Date: Fri, 13 Jan 2006 03:28:26 GMT
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY
Content-Length: 0


Retransmitting ASTERISK-1 (no NAT) to sphone.vopr.vonage.net:5061:
BYE sip:transit.vonage.net:5060 SIP/2.0
Via: SIP/2.0/UDP asterisk.aa.eu:5060;branch=z9hG4bK5a430a24;rport
Route: <sip:pstin_7748712@inbound4.vonage.net:5060>,<sip:transit.vonage.net:5060>
From: <sip:pstin_7748712@inbound4.vonage.net>;tag=as108211ae
To: “pstn_1234567”<sip:transit.vonage.net>;tag=428326453
Contact: <sip:pstin_7748712@asterisk.aa.eu>
Call-ID: 4F93F317-836F11DA-B684B29D-2266172B@transit.vonage.net
CSeq: 103 BYE
User-Agent: Asterisk v1.2.1
Max-Forwards: 70
Proxy-Authorization: Digest username="pstin_7748712", realm="sphone.vopr.vonage.net", algorithm=MD5, uri="sip:sphone.vopr.vonage.net", nonce="455097506", response="4e2131ede158b2f71ce3bea4a7cb04c7", opaque=""
Date: Fri, 13 Jan 2006 03:28:26 GMT
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY
Content-Length: 0


Retransmitting ASTERISK-2 (no NAT) to sphone.vopr.vonage.net:5061:
BYE sip:transit.vonage.net:5060 SIP/2.0
Via: SIP/2.0/UDP asterisk.aa.eu:5060;branch=z9hG4bK5a430a24;rport
Route: <sip:pstin_7748712@inbound4.vonage.net:5060>,<sip:transit.vonage.net:5060>
From: <sip:pstin_7748712@inbound4.vonage.net>;tag=as108211ae
To: “pstn_1234567”<sip:transit.vonage.net>;tag=428326453
Contact: <sip:pstin_7748712@asterisk.aa.eu>
Call-ID: 4F93F317-836F11DA-B684B29D-2266172B@transit.vonage.net
CSeq: 103 BYE
User-Agent: Asterisk v1.2.1
Max-Forwards: 70
Proxy-Authorization: Digest username="pstin_7748712", realm="sphone.vopr.vonage.net", algorithm=MD5, uri="sip:sphone.vopr.vonage.net", nonce="455097506", response="4e2131ede158b2f71ce3bea4a7cb04c7", opaque=""
Date: Fri, 13 Jan 2006 03:28:26 GMT
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY
Content-Length: 0
Comments:By: Daniel Leeds (daniel leeds) 2006-01-17 00:43:44.000-0600

In chan_sip.c on line# 05959 the function build_route(), does collect the route information from the "Record-Route" headers:

Unfortunately, this route information is ignored while sending a BYE request within the same SIP dialogue. And this is a violation of RFC-3261, Section: 12.2.1.1

This route information is also ignored when sending a REFER request, despite that transmit_refer() calls reqprep() and the latter seems to pay attention to the routing information, as evidenced by the line# 04049:
c = is_strict ? p->route->hop : p->okcontacturi

For those who still doubt that it is mandatory to process routing information while sending a BYE or REFER within an existing SIP dialogue, I refer them to the RFC-3261 or other SIP protocol implementations.

I have checked 3 such implementations:  Cisco Hardphones, CounterPath X-Pro SoftPhones, and SIPX, and they all take the route set info into consideartation.
Only Asterisk ignores the route info from the "Record-Route" headers !
By: Serge Vecher (serge-v) 2006-01-17 07:43:49.000-0600

Daniel: could you please provide a patch in diff -u format with your proposed changes against the svn trunk?
By: Daniel Leeds (daniel leeds) 2006-01-17 08:33:46.000-0600

vechers <-- I wish that I could.  I am not familiar with chan_sip.c source code sufficiently to try to attempt this.  I need help from somebody who knows this source much better than I do.  I can only determine that the route set is ignored when Asterisk builds the Request-URI for the BYE or REFER requests.

I cannot even find where in the source code, the Request-URI is generated for the BYE request :(
By: Olle Johansson (oej) 2006-01-18 12:09:14.000-0600

Thank you for a very detailed bug report. It is a known problem that will be fixed at some point, but I can't say when at this point. If someone comes up with a patch, they're more than welcome :-)
By: Daniel Leeds (daniel leeds) 2006-01-19 02:43:17.000-0600

I'd like to give it a try.  Strict routing is very common.
Can you point me to the code that is responsible for creating the Request-URI in BYE requests ?
By: Daniel Leeds (daniel leeds) 2006-01-23 02:25:58.000-0600

Since bug# 6240 is confirmed by you and others, please change its status to "confirmed".
By: Olle Johansson (oej) 2006-01-23 09:42:33.000-0600

I've added a debug output when asterisk thinks it's using strict routing.
Update to latest trunk (HEAD) and test again.
Are you seeing that message in this transaction?
By: David Aldworth (daldworth) 2006-01-24 15:24:39.000-0600

Daniel, any luck on a patch? We're getting reports of problems with other SIP rfc compliant soft switches not liking our implementation of 1.2.2 due to this exact problem. We might be able to help if we can get pointed in the right direct. We know chan_sip.c but are in the same boat, not sure where to put this information. In the meantime we're rolling back to 1.2.0beta1. That version did not exhibit this behaviour.
By: hypherion (hypherion) 2006-01-25 15:42:38.000-0600

I have noticed this problem as well.  Transfer() does not work when trying to REFER a call to Vonage that comes in with no caller ID information.
By: Daniel Leeds (daniel leeds) 2006-01-26 06:30:51.000-0600

In the file SVN-trunk-r8687-debug.txt I attached the Asterisk debug output with verbosity and debug level set to 4.

The strict routing problem is still present.

The BYE request IS:
BYE sip:transit.vonage.net:5060 SIP/2.0

The BYE request SHOULD BE:
BYE sip:pstin_7748712@sphone.vopr.vonage.net:5061 SIP/2.0

...because these are the contents of the first "Record-Route" header in the original INVITE request.

Also look at the relevant non-SIP debug output, in the file SVN-trunk-r8687-debug.txt:
list_route: hop: <sip:pstin_7748712@sphone.vopr.vonage.net:5061>


Daniel
By: Daniel Leeds (daniel leeds) 2006-01-27 04:16:08.000-0600

oej <--  In your last message I think you referred to an additional debug output code in the reqprep() function in chan_sip.c

However, I noticed that the function reqprep() is NEVER called when the BYE request is being built and the following piece of debug code is never executed.

/* Check for strict or loose router */
if (p->route && !ast_strlen_zero(p->route->hop) && strstr(p->route->hop,";lr") == NULL) {
is_strict = 1;
if (sipdebug)
ast_log(LOG_DEBUG, "Strict routing enforced for session %s\n", p->callid);
}
By: Olle Johansson (oej) 2006-01-31 08:37:07.000-0600

Creating a svn branch to work with this issue.

http://svn.digium.com/svn/asterisk/team/oej/strictrouting/
By: Daniel Leeds (daniel leeds) 2006-01-31 09:44:54.000-0600

Very good!

Perhaps I could contribute some code patches if you would show me where in the code the Request-URI is built for the BYE request.

I think, reqprep() is not even called when building the BYE request.

Also, where can I find info how to debug chan_sip.c in real time on live Asterisk system?  e.g: set breakpoints, single-step through the C code, inspect variables, etc...

What debug tools do you use?


Daniel

P.S.
I am an experienced MS-Windows developer (C and x86 assembler), but I have no idea how to debug Asterisk modules under Linux, like the chan_sip.c  :(
By: Olle Johansson (oej) 2006-01-31 09:54:01.000-0600

Played around with this a bit, please check out the branch and please try to see if anything is changed. I have no strict router to test with, if I can't borrow an account from someone... (hint, hint).
By: Daniel Leeds (daniel leeds) 2006-01-31 12:22:49.000-0600

I might be able to help with the account.
What country are you in ?
By: Olle Johansson (oej) 2006-01-31 12:35:11.000-0600

Stockholm, Sweden :-)

Reach me on oej at edvina.net or on IRC as oej

Thanks!

/O
By: Mark Spencer (markster) 2006-02-20 12:28:47.000-0600

Daniel, can you contact me here at Digium to setup a time that I can login and look at this problem on your live machine?
By: Olle Johansson (oej) 2006-02-22 08:54:27.000-0600

Can't repeat the problem with the provided account. Test code now in the "strictrouting" branch.
By: Olle Johansson (oej) 2006-02-28 09:56:01.000-0600

I need some feedback from you all in order to be able to move forward on this. Please check out the "strictrouting" branch and test it, tell me whether it fixes anything or simply breaks everything. Thanks!
By: Olle Johansson (oej) 2006-03-10 01:58:55.000-0600

Seems like everyone lost interest in this. Will close this bug report if you don't reply or comment soon.
By: mikma (mikma) 2006-03-10 12:48:41.000-0600

It doesn't look like is_strict influences the request uri when sending BYE in a dialog that was created by an incoming INVITE, since okcontacturi will be empty for incoming calls.

Shouldn't reqprep be changed to:

       } else if (!ast_strlen_zero(p->okcontacturi)) {
               c = is_strict ? p->route->hop : p->okcontacturi; /* Use for BYE
or REINVITE */
       } else if (!ast_strlen_zero(p->uri)) {
-                c = p->uri;
+                c = is_strict ? p->route->hop : p->uri;
       } else {
By: Olle Johansson (oej) 2006-03-10 14:22:01.000-0600

All those "strip domains and options" are historical artifacts we need to get rid of... ;-)
By: Daniel Leeds (daniel leeds) 2006-03-16 00:16:41.000-0600

Olle,

I'm back from vacation.
...and have not lost interest in this bug.

I sent you a private email to edvina, with the login info to my Asterisk box, so you can observe the problem yourself.


Daniel
By: George Robinson (george robinson) 2006-03-17 17:43:13.000-0600

Oej,

You lost me.
What are "strip domains" ?

George
By: Daniel Leeds (daniel leeds) 2006-04-03 06:44:47

Olle,

Did you login into my Asterisk box to experience the problem with strict SIP routers yourself ?

I kept the box on for weeks for you already...

Daniel
By: Olle Johansson (oej) 2006-04-04 03:03:49

Daniel: I did not see that e-mail. Please re-send.
By: Daniel Leeds (daniel leeds) 2006-04-04 07:32:51

Olle,

I just resent the email to edvina again
By: Daniel Leeds (daniel leeds) 2006-04-12 07:38:29

Olle,

Did you get that email I resent over a week ago ?
By: Serge Vecher (serge-v) 2006-06-05 09:59:08

hmmm, the diff of strictrouting to trunk is ~.5Mb. Looks like automerge has borked  something ...
By: Olle Johansson (oej) 2006-06-27 12:33:25

Daniel: Yes, I've tried with your account and can't repeat the problem... I do need to be able to test this somewhere...
By: Serge Vecher (serge-v) 2006-08-15 12:29:29

Daniel: where are we with this?
By: Serge Vecher (serge-v) 2006-08-25 11:30:23

*ping*
By: Daniel Leeds (daniel leeds) 2006-09-04 15:09:27

I set up a SIP/Linux box to demonstrate this problem to Olle, but he called the SIP POTS gateway from his number in Sweden despite that I EXPLICITLY told him to call this gateway from a POTS number that does NOT identify itself through CallerID.  (CallerID works in USA for Swedeish numbers).

The SIP<-->POTS gateway provider Vonage does strict SIP routing only for Out-of-Area incoming POTS calls, hence Olle did not see the problem with strict routing.

Since Olle did not follow my direction in duplicating this strict SIP routing problem, I gave up and took down the SIP/Linux box (it's been up for 6 months!), and I stopped checking this forum.  

The problem still exists for Asterisk and all strict routing SIP proxies/gateways.

I could set up a test system again and give a root access to someone who can write Astersik code to solve this non-compliancy.  I cannot write such code myself :(

Regards,
Daniel


By: jmls (jmls) 2006-11-01 10:22:45.000-0600

oej, Daniel Leeds, would it be possible to restart this process to try to get to the bottom of the problem ?
By: Daniel Leeds (daniel leeds) 2006-11-01 20:33:54.000-0600

Yes, but since I don't know C++ (only plain C), I can only document and set up the testing environment for this SIP routing problem.

Without somebody like oej to write code corrections, we will not succeed in fixing this problem.


By: Serge Vecher (serge-v) 2006-11-08 09:20:03.000-0600

chan_sip, imho, as well as most of Asterisk, is written in plain c (not c++).
By: Serge Vecher (serge-v) 2007-02-26 16:00:38.000-0600

Daniel?
By: Daniel Leeds (daniel leeds) 2007-02-28 14:45:35.000-0600

Hi,

I'm still here, but I'm unable to fix this problem.
I am not an Asterix programmer ;(

Daniel
By: Serge Vecher (serge-v) 2007-02-28 15:14:31.000-0600

have you gotten a chance to test 1.4 svn to see if things are any different there?
By: Daniel Leeds (daniel leeds) 2007-02-28 18:10:42.000-0600

No, I haven't.  When nobody was interested in my Asterisk test system, I tore down my Linux box with Asterisk and installed Windows on it, so now I don't have a readily available testing * environment.

Has any work been done on the function build_route() in  chan_sip.c  in svn 1.4?

If yes - I will test it.


Regards,
Daniel
By: Olle Johansson (oej) 2007-05-30 02:40:35

I did some work in the strictrouting branch, but closed it since I did not get any feedback at all. I need testers to test code before I commit a change like this. So nothing has been done to 1.4 really. Please tell me when you're ready to test and I'll try to get the branch back.
By: Joshua C. Colp (jcolp) 2008-01-31 11:45:48.000-0600

I'm suspending this for oej since he has gotten no go to try to bring it back and give it a test. If you are interested feel free to reopen.