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

[Byron Campen]

	Consider the following SIP URI:

sip:2145551234;phone-context=+1 at example.com;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