Subject: Re: [Sip] SIPIT Interop problem with ;user=phone

From: "Bob Penfield" <[email-masked]>
Date: Wed, 3 Sep 2003 19:42:56 -0400

Getting back to the problem Robert described in the original mail, the
interoperability problems are a result of that fact that what is a valid
userinfo part of a SIP URL with a user=phone parameter has steadily gotten
stricter without any consideration for backwards compatibility. The specific
problem he described resulted because a SIP URL created with 2543 rules was
rejected by a server applying 3261/2806 rules. The new 2806bis rules are
even stricter. I have no problem with those rules for tel-URLs.

In spite of the lack of normative text on user-phone, the statements in 2543
and 3261 to the effect that it is used to distinguish phone numbers from
usernames leads one to the reasonable conclusion that when it is present,
the 'telephone-subscriber' BNF applies. This is the conclusion that we and a
number of our vendors and customers came to when we ran into interop
problems.

However, its not that simple since a 'telephone-subscriber' keeps changing.

>From some of the posting on this subject, there seems to be value in
distinguishing a telephone number from username that happens to look like a
telephone number without requiring that the user part be a tel-URL. What I
would propose is that while we make the rules for user=phone clearer, they
ought to be closer to the 2543 rules which in my experience a lot of
existing implementation seem to follow. If the userinfo begins with "+" or
contains a phone-context, then it is reasonable to interpret it as a
tel-URL. Otherwise, the 'local-phone-number' (from Table 4 of 2543) should
apply. A server which is not responsible for the domain of the SIP URL
should not reject a SIP URL because phone-context is missing. Actually, I
believe it is reasonable to take the SIP URL host part as the 'default'
phone-context when it is missing.

Also, we could add 'user=tel' for userinfo that MUST be tel-URLs. In that
case, rejecting a local number without a phone-context would be perfectly
reasonable.

cheers,
(-:bob

Robert F. Penfield
Chief Software Architect
Acme Packet, Inc.
130 New Boston Street
Woburn, MA 01801
[email-masked]

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [email-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip

---

From: Alan Johnston <[email-masked]>
Date: Mon, 25 Aug 2003 15:39:15 -0500

At 10:10 AM 8/22/2003 -0400, Robert Sparks wrote:
>I've seen a few interoperability failures at SIPIT 13 revolving
>around the use of ;user=phone in sip URIs.
>
>We have some implementations assuming that the presence of ;user=phone
>means that the first part of the userinfo portion of the URI MUST
>be formatted as a telephone-subscriber. Asking around, I've found
>that many people believe this is the case, but the spec does not
>support this claim. In fact, all the specification says is
>that if the userinfo portion is formatted as a telephone-subscriber
>then the URI SHOULD also contain ;user=phone.
>
>So, is this an oversight? Are we allowing URIs with ;user=phone
>but a non telephone-subscriber formatted userinfo part on purpose?
>
>Those with code making the above assumption fail to interoperate
>with devices that gather an arbitrary number of digits and
>just slap ;user=phone in the URI when creating a request.
>For example:
>
><sip:[email-masked];user=phone>
>
>They reject this as a malformed URI since 15 doesn't parse per
>telephone-subscriber. Is this being too strict?

Yes - it is very strange to reject this URI.  The SIP PSTN Call Flows 
document currently and always has shown URIs of this form, e.g.
sip:[email-masked];user=phone

The SIP world is full of telephone and gateways that include the user=phone 
parameter - it seems way, way, too late to be defining strict semantics for 
this parameter or all kinds of bad interoperability things will happen.

>Should they
>try to interpret this as a "number that has meaning in their
>local scope"? It certainly isn't safe to pretend the ;user=phone
>wasn't there and try to interpret "15" as a username. What's
>the right thing for them to do?
>
>A companion question is should a UA arbitrarily hang ;user=phone
>off a digit string it collects from its user, or should it
>transform that string into a telephone-subscriber formatted
>number?
>
>Both questions have clear answers if we explicitly add that
>if ;user=phone is present in a URI then the userinfo part
>MUST be formatted as a telephone-subscriber. Would anyone
>object to adding this requirement?

This isn't backwards compatible, so I'd say no.

Thanks,
Alan Johnston
MCI

>RjS