[Home]

Summary:ASTERISK-20561: Asterisk 1.8 allows the # character in SIP URI, 10 and higher versions do not - need to document in UPGRADE.txt possibly other places?
Reporter:Deniz (deniz)Labels:
Date Opened:2012-10-15 03:17:58Date Closed:2012-11-05 11:59:21.000-0600
Priority:MajorRegression?
Status:Closed/CompleteComponents:Channels/chan_sip/General
Versions:1.8.17.0 Frequency of
Occurrence
Related
Issues:
Environment:Attachments:
Description:When setting CALLERID(num)=#0012345678 asterisk is generating from-header:

from: <sip:#0012345678@192.168.110.12>

My understanding of RFC 3261 usernames are just allowed to contain alphanumeric characters, escape-sequences and some special characters (which do not include #).
RFC 3261 refers to rfc2396 for more details which describes # as delimiter and not allowed to be part of URI.

So, this character has to be replaced by "%23".
Comments:By: Walter Doekes (wdoekes) 2012-10-16 02:20:49.603-0500

You're right:
{noformat}
alphanum =  ALPHA / DIGIT
mark =  "-" / "_" / "." / "!" / "~" / "*" / "'"
                      / "(" / ")"
unreserved =  alphanum / mark
user-unreserved =  "&" / "=" / "+" / "$" / "," / ";" / "?" / "/"

user =  1*( unreserved / escaped / user-unreserved )
{noformat}

However, this is already fixed in asterisk 10 and higher.

Compare:
{noformat}
char *ast_uri_encode(const char *string, char *outbuf, int buflen, struct ast_flags spec)
{
       const char *ptr  = string;      /* Start with the string */
       char *out = outbuf;
       const char *mark = "-_.!~*'()"; /* no encode set, RFC 2396 section 2.3, RFC 3261 sec 25 */
       const char *user_unreserved = "&=+$,;?/"; /* user-unreserved set, RFC 3261 sec 25 */
{noformat}
with 1.8:
{noformat}
char *ast_uri_encode(const char *string, char *outbuf, int buflen, int do_special_char)
{
       const char *ptr  = string;      /* Start with the string */
       char *out = outbuf;
       const char *mark = "-_.!~*'()"; /* no encode set, RFC 2396 section 2.3, RFC 3261 sec 25 */
{noformat}

The easiest fix is to upgrade.

This change wasn't included in 1.8 for a reason, which I guess goes something like this:
/people expect their URIs in a certain way now, you can't change that mid-branch/

A quick glance through UPGRADE.txt does not show this change though. Perhaps that needs to be addressed.
By: Matt Jordan (mjordan) 2012-10-18 14:20:23.500-0500

Looking back at the commit message (r303509) and the review (https://reviewboard.asterisk.org/r/1081/), I'm sure that's why it was done that way.  Tilghman's comment "Excellent work.  You addressed exactly the concerns I had with modifying that function yet again." says a lot about the risk associated with modifying that function in a release branch.

I'd say the correct action here is to update the UPGRADE file in the appropriate versions and not backport the patch to 1.8.