[reSIProcate-users] Uri and user parameters (if you do anything with user parameters, please read, or I will break your code)

[Byron Campen <bcampen@xxxxxxxxxxxx>]

        Consider the following SIP URI:

sip:2145551234;phone-context=+1@xxxxxxxxxxx;user=dialstring

        When parsed, calling user() gets us "2145551234;phone-context=+1", and 
calling userParameters() gets us the empty string. On the other hand, if we 
instead start from the following tel URI:

tel:2145551234;phone-context=+1

        And convert to a SIP URI using fromTel(), we arrive at the same SIP URI 
as above, except now user() returns "2145551234", and userParameters() returns 
"phone-context=+1". This behavior is inconsistent, but also very old. Chances 
are very good that any way of fixing the inconsistency will break someone's 
code. Additionally, the phone-context parameter on the TEL URI is not 
accessible via the standard param() interfaces; it must be accessed and parsed 
via userParameters(). It would be nice if we could use the usual interface 
here. Here are the options, as I see it:

1) This option would break code that expects to find the phone-context in 
Uri::mUserParameters, or that expects mUser to _not_ contain the parameters 
after using fromTel(): Remove userParameters() entirely, parse parameters on 
tel URIs just like we parse them on SIP URIs, and have fromTel() concatenate 
the digit string and the string of parameters when forming the new user-part. 
Calling user() on the above SIP URI would always yield 
"2145551234;phone-context=+1", regardless of whether it was parsed as a SIP 
URI, or converted from a TEL URI. getUserAsTelephoneSubscriber() would return a 
Token with Token::mValue=="2145551234", and the phone-context parameter 
accessible through Token::exists(p_phoneContext) and 
Token::param(p_phoneContext), just like it does now.

2) This option would break code that expects to find the ";phone-context=+1" in 
mUser when parsed as a SIP URI: Leave userParameters() and fromTel() alone, but 
have the SIP URI parse code look for a semi-colon in the user-part if either a 
user=phone or user=dialstring parameter is found, and if so, populate 
mUserParameters. getUserAsTelephoneSubscriber()/setUserAsTelephoneSubscriber() 
would be updated to access the params via mUserParameters. The TEL URI parse 
code can either be modified to make params accessible via the usual 
param()/exists() interfaces, or can be left alone (put them in 
mUserParameters). This approach is the more expensive (both computationally and 
memory-wise) of the two options (we retain mUserParameters, and we must do 
additional work in the parse code for SIP URIs).

        If your code uses user parameters, please let me know which one of 
these approaches will end up breaking stuff for you, so I can get an idea of 
how to fix this while causing minimal inconvenience for everyone.

Best regards,
Byron Campen