Summary:	ASTERISK-16061: Register statement in sip.conf does not accept slash in user part (valid per RFC 3261)
Reporter:	John Covert (jcovert)	Labels:
Date Opened:	2010-05-06 12:10:08	Date Closed:	2010-05-12 13:24:18
Priority:	Minor	Regression?	No
Status:	Closed/Complete	Components:	Channels/chan_sip/Interoperability
Versions:		Frequency of Occurrence
Related Issues:
Environment:		Attachments:
Description:	The definition of the user part of a SIP URI from Section 25 (page 221) of RFC 3261 is: user             =  1*( unreserved / escaped / user-unreserved ) user-unreserved  =  "&" / "=" / "+" / "$" / "," / ";" / "?" / "/" note specifically that "/" is "user-unreserved" and can be specified without any escaping. One of my providers requires the following _valid_ SIP URI for registration: sip:abcd/efgh@provider.net This results in the error message Format for registration is [peer?][transport://]user[@domain][:secret[:authuser]]@host[:port][/extension][~expiry] at line n I am temporarily working around the problem by disabling the check for the '/' in  AST_NONSTANDARD_RAW_ARGS(pre2, pre1.userpart, '/'); but if "transport://" is to be accepted in a register statement, looking for it is going to have to be done more carefully, since _any_ character (even the first) of the "user" part may be a slash.  It should be possible to look for the three character string "://", since ":" is NOT one of the valid user part characters.  Watch out though: it is a valid part of a password -- but a reasonable restriction would be that the password for the register must be in the "secret=" of a corresponding sip.conf [section] referenced in the host part.
Comments:	By: John Covert (jcovert) 2010-05-06 12:11:17 "reasonable restriction" would only apply to a password beginning with TWO slashes. By: Paul Belanger (pabelanger) 2010-05-06 12:42:10 What about register => udp://abcd/efgh:@provider.net By: John Covert (jcovert) 2010-05-06 14:44:35 It's only minor if that actually works as a work-around.  (Well, ok, I've patched my system to work around it as well, but not in a way that is generally applicable.) By: Paul Belanger (pabelanger) 2010-05-06 14:57:20 Don't worry about 'minor', it only represents the number of affected people. What about my previous post? register => udp://abcd/efgh:@provider.net By: John Covert (jcovert) 2010-05-06 15:46:03 OK.  I backed my temporary code workaround out and tried udp://abcd/efgh@provider8/provider8 It works; it picks up the password from the [provider8] section below. It is, however, a regression: 1.6.1.16 parsed it correctly without requiring the udp:// in front, because that code explicitly looked for "://" to determine if there was a transport type present. /john By: John Covert (jcovert) 2010-05-06 19:09:53 by the way, as part of any correction it would be advisable to remove the line beginning #define SIP_RESERVED ... as it is not referenced in the code any more. By: Paul Belanger (pabelanger) 2010-05-06 19:58:49 I suspect this is related to ASTERISK-14045, either way.  Since this worked before, regression is possible. By: Tilghman Lesher (tilghman) 2010-05-06 20:12:28 Please quote any field that may contain characters that would otherwise be interpreted as delimiters.  As this is Asterisk configuration file syntax, RFCs do not apply. register => "abcd/efgh"@provider.net By: Paul Belanger (pabelanger) 2010-05-12 13:24:17 Talking with #asterisk-dev, this is not a bug.