Re: [reSIProcate-users] Uri and user parameters (if you do anything with user parameters, please read, or I will break your code)
As noone else seem to have reacted, I will.
I don't know if we have ever received a tel URI, but the way it is handled is
to adapt to the current situation by using userParameters() for tel URIs and
extracting the parameters from user() for sip URIs.
The code would not be hard to change, and the "user parameters" notion seems to
be created just to handle this situation, but are not the parameters in the tel
URI case really URI parameters, and part of the userinfo in a sip URI?
That seems to indicate that the parameters should be found through Uri::param()
for tel URIs and Token(user)::param() for sip URIs (obviously getting rid of
userParameters()), i.e. your solution 1 .
Would you even need a getUserAsTelephoneSubscriber()?
We have never converted tel URIs to sip ones, and if your example is correct
I'm kind of glad we haven't: section 19.1.1 of RFC 3261 says "If the user
string contains a telephone number formatted as a telephone-subscriber, the
user parameter value "phone" SHOULD be present", and that (user=phone) is what
we use (is dialstring from 2543?). When parsing incoming numbers we don't
require it, so in this situation it would be less of a problem. Other equipment
seem to be more picky, though.
Rgds,
Mats
________________________________________
From: Byron Campen [bcampen@xxxxxxxxxxxx]
Sent: 07 May 2011 20:19
To: resiprocate-devel@xxxxxxxxxxxxxxx; resiprocate-users@xxxxxxxxxxxxxxx
Subject: [reSIProcate-users] 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