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

From: "Rosen, Brian" <[email-masked]>
Date: Thu, 11 Sep 2003 10:58:26 -0400

It doesn't address dial strings, which is a big problem.
For example
> >Otherwise, the 'local-phone-number' (from Table 4 of 
> >2543) should apply.
is problematic I think.

I don't have a problem with the "+" or phone context
and user=phone implying it's equivalent to a tel uri.

Brian

> -----Original Message-----
> From: Christer Holmberg (JO/LMF) 
> [mailto:[email-masked]]
> Sent: Thursday, September 11, 2003 10:27 AM
> To: Christer Holmberg (JO/LMF); 'Bob Penfield'; [email-masked]
> Subject: RE: [Sip] SIPIT Interop problem with ;user=phone
> 
> 
> 
> Hi,
> 
> So, is Bob's proposal something which could be accepted, or 
> at least worked futher on?
> 
> Regards,
> 
> Christer Holmberg
> Ericsson Finland
> 
> 
> > -----Original Message-----
> > From: Christer Holmberg (JO/LMF) 
> > Sent: 4. syyskuuta 2003 13:14
> > To: 'Bob Penfield'; [email-masked]
> > Subject: RE: [Sip] SIPIT Interop problem with ;user=phone
> > 
> > 
> > 
> > Hi,
> > 
> > I would support Bob's proposal, saying that a "+" indicates 
> > global-phone-number, according to RFC2806(or bis). I don't 
> > think there would be any backward compability issues, because 
> > I doubt anyone is using "+" for any other purpose - at least 
> > not as the first character of the user part. Of course, nodes 
> > that really REQUIRE user=phone to be present, in order to 
> > accept the request in the first, place would have to be changed.
> > 
> > Of course, user=tel could also be used, but I really see no 
> > use for that if the "+" rule applies. Also, user=tel COULD 
> > cause backward compability issues.
> > 
> > Then, since there doesn't seem to be an agreement on what 
> > user=phone really means, related BOTH to the userpart syntax 
> > and the message routing, we could remove it completely.
> > 
> > Regards,
> > 
> > Christer Holmberg
> > Ericsson Finland
> > 
> > 
> > 
> > 
> > 
> > > -----Original Message-----
> > > From: Bob Penfield [mailto:[email-masked]]
> > > Sent: 4. syyskuuta 2003 2:43
> > > To: [email-masked]
> > > Subject: Re: [Sip] SIPIT Interop problem with ;user=phone
> > > 
> > > 
> > > 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
> > > 
> > 
> > _______________________________________________
> > 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
> 

_______________________________________________
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: "Bob Penfield" <[email-masked]>
Date: Fri, 12 Sep 2003 07:52:03 -0400

----- Original Message ----- 
From: "Rosen, Brian" <[email-masked]>

> and user=phone implying it's equivalent to a tel uri.

If we allow user=phone without the restriction that the userinfo be a
tel-URI (i.e. neither a + or a phone-context present), it would allow the
userinfo to be a dial string (which 2543's local-phone-number allows) with
the assumption that the SIP server of the host/domain of the SIP-URI knows
how to interpret it. I believe this is the way that a lot of implementations
use user=phone now. Having dial plans in the endpoints may not be practical
from a maintenance perspective unless there is a standard way for the
endpoint to download a dial plan. It is often more practical to have the
proxy interpret a dial string.

I think we need to specify user=phone in a backward compatible way that
matches the way most implementations use it today.

cheers,
(-:bob

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 12 Sep 2003 09:02:48 -0400

> matches the way most implementations use it today.

I think this is quite appropriate in order to ensure backward 
compatibility with current practice.

But we then have two possible representations for the dial string case:

	sip:[email-masked];user=phone
	tel:12345;phone-context=acme.com

In many ways these are equivalent, but they do have subtle differences 
in semantics:

- the sip form has well defined routing rules for getting it to a server 
that ought to understand it

- the tel form has more latitute in how it is processed. There can be 
servers that are familiar with the phone context and can expand it 
without otherwise being responsible for the domain of the same name.

- the tel form doesn't provide any guaranteed way to route it to a 
server that understands it.

- the applicability of the tel form isn't limited to sip.

Perhaps they both have their place. But if we are to have interop 
between phones of one vendor and severs of another, then we must 
eventually agree on how phones map dial strings to something that 
servers can process.

	Paul