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

From: "Rosen, Brian" <[email-masked]>
Date: Fri, 12 Sep 2003 08:49:05 -0400

I agree that user=phone with no "+" and no context in most phones
means that the username is a dial string, and for backwards compatibility,
that's the way we must leave it.  Getting rid of user=phone means that there
is no way to distinguish between a dial string and a username that looks
like a dial string.  That's bad.  If we leave it at that, I won't have
a lot of heartburn.

I'd prefer to have a more unambiguous designation for a dial string.
I'd prefer a way to distinguish the following from each other:
	A raw dial string
	A real phone number
	The results of an ENUM translation
	a numeric username

I also wonder if we shouldn't have a way to distinguish 1-800-BUY-MINE
as a dialable phone number.

local-phone-number syntax is okay.  Note it substitutes "p" for ","
Seems like allowing the comma would be acceptable, escaped if you'd
like, although strictly speaking "user-unreserved" allows comma.

Brian

> -----Original Message-----
> From: Bob Penfield [mailto:[email-masked]]
> Sent: Friday, September 12, 2003 7:52 AM
> To: [email-masked]
> Subject: Re: [Sip] SIPIT Interop problem with ;user=phone
> 
> 
> 
> ----- Original Message ----- 
> From: "Rosen, Brian" <[email-masked]>
> 
> > 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.
> >
> 
> 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
> 
> > 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
> 

_______________________________________________
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: Paul Kyzivat <[email-masked]>
Date: Fri, 12 Sep 2003 09:18:07 -0400

> I'd prefer a way to distinguish the following from each other:

I think we already have it.

> 	A raw dial string

For a dial string of 1234, either:
	tel:1234;phone-context=your-dialplan.foo.bar
   or
	sip:[email-masked];user=phone

> 	A real phone number

either:
	tel:+12345678901
   or
	sip:[email-masked];user=phone

> 	The results of an ENUM translation

typically, a sip url without user=phone. But more generally any old url 
usable with sip. This is just like the translation from AOR to contact 
address - we don't have any way to tell one from the other by 
inspection, and they aren't disjoint sets.

> 	a numeric username

sip:[email-masked]

> as a dialable phone number.

I presume you mean something other than tel:+1-800-289-6463?

How about sip:[email-masked]?

	Paul