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

From: Gordon Ledgard <[email-masked]>
Date: Fri, 22 Aug 2003 10:29:39 -0400

Hi. Robert Sparks asked....

>>    -----Original Message-----
>>    From: Robert Sparks [mailto:[email-masked]]
>>    Sent: Friday, August 22, 2003 10:11 AM
>>    To: [email-masked]
>>    Subject: [Sip] SIPIT Interop problem with ;user=phone

>>    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.

My take on this would be to ask a further question.. What other
semantics do people expect "user=phone" to infer? Are they
making some other assumptions about the device based on this
parameter? 

If the answer is that people are using "user=phone" simply as a
shortcut to conclude that the user part is a phone number to speed
up parsing and look-up, then the

     " ;user=phone is present in a URI then the userinfo part
       MUST be formatted as a telephone-subscriber. "

statement can stand.

Having said that, this leads to a bunch of issues with PBX sorts of
applications that need to map a 10 or 11 digit telephone number into
a local extension, and vicey versey. The proxies, B2BUAs or, or service
platforms would need to insert and yank the ;"user=phone" parameter
on and off based on when the call entered or left the local domain.
On top of that, these agents would need to understand the other
semantics being infered by "user=phone" in order to do this properly,
which may well be impossible.

In that case, the language of the spec ought to be even more strict,
and say " "user=phone" means that the user part is a phone number, and
no other assumtions about the device can be made.." or words to that
effect. Which leads to the question... why have it? Just parse it.

Thoughts?

Gordon R. Ledgard
Principal Engineer
IPeria, Inc.

-----Original Message-----
From: Robert Sparks [mailto:[email-masked]]
Sent: Friday, August 22, 2003 10:11 AM
To: [email-masked]
Subject: [Sip] SIPIT Interop problem with ;user=phone

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? 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?

RjS

_______________________________________________
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

_______________________________________________
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: "Conroy, Lawrence (SMTP)" <[email-masked]>
Date: Fri, 22 Aug 2003 15:56:45 +0100

Hi Folks,
    My vote's for exactly the statement that Robert proposes;
"if ';user=phone' is included, then the userpart MUST be formatted as 
a telephone-subscriber"

Note that:
At 10:10 am -0400 22/8/03, Robert Sparks wrote:
>In fact, all the specification says is
the quoted statement is not the same as the above proposal.

This proposal does *NOT* mean that any userpart that is numerical
MUST have this parameter appended - it says nothing of this.

I see this parameter, where present, as an assertion that the
userpart can be treated as a telephone-subscriber. Any assumptions
that a PBX chooses to make on what THAT implies is it's own business.

The proposal doesn't mean that a PBX needs to add the parameter if it
doesn't want to do this. The quoted SHOULD strength means it can dodge
that one if it has good reason.

[From dim recollection, wasn't this one added originally to deal
  with Compuserve numerical addresses vs. phone numbers? Long ago
  in a land far away...]

In summary, I'm happy with this proposal

all the best,
   Lawrence

-- 
-----------------------------------------------------------------------
Roke Manor Research    : This information is provided "as is" and is not
<mailto:[email-masked]>: intended to create any contractual or legal
<tel:+441794833666>    : relationship.