[reSIProcate] Uri and user parameters (if you do anything with user parameters, please read, or I will break your code)
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