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

From: Rohan Mahy <[email-masked]>
Date: Thu, 18 Sep 2003 18:06:34 -0700

Bob,

Comments inline.

On Friday, September 12, 2003, at 04:52 AM, Bob Penfield wrote:
> ----- 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)

what is the the difference between a dial string and a a phone number?  
according to 2806bis, a phone-number is just 1*phonedigit .
it sure seems like a dial string can be expressed in there.

the only requirement then to have a valid tel-URI is to tack on a 
phone-context parameter.  this is trivial string concatenation.

> with
> the assumption that the SIP server of the host/domain of the SIP-URI 
> knows
> how to interpret it.

as Dean has already demonstrated that, you don't need ;user=phone to do 
that.  I don't see any value in having a special parameter (user=phone) 
unless it implies some structure.  You can already send unstructured 
dial strings in an ordinary SIP URI with user=ip.  There is no need IMO 
to have *two different* ways of expressing unstructured dial strings.

> I believe this is the way that a lot of implementations
> use user=phone now.

as we've seen at SIPit and on this thread, there are implementations 
using every conceivable semantic for this little parameter.  If we use 
unstructured strings we will break some other implementations. Lets 
pick one semantic and go forward.  No matter what we will pick we will 
break something, so we should pick the right thing.

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

First of all, we are working on a standard mechanism to enable 
configuration of phones and the like, which I certainly hope will 
include dial plans.

Even without such a mechanism, it is trivial for the endpoint to either 
use a SIP URI in the proper domain (use user=ip), or to generate a 
valid tel URI as the userinfo part and user user=phone, by tacking on a 
phone-context parameter after the dialed string.

For example:

sip:f69;phone-context=[email-masked];user=phone
... means that someone dialed *69 in the context of +14085264123

sip:[email-masked]
... means that someone INVITEd *69 in the abc.example.com domain.  you 
might want to interpret that.

sip:555;phone-context=[email-masked];user=phone
... means that someone dialed 555 in the context of peoria-pbx.acme.com

sip:901144203456789;phone-context=rmahy,[email-masked];user=phone
... can mean that rohan dialed 9-011-44-20-345 6789

a proxy can now very easily interpret these dial plans according to the 
appropriate context.  It can pass these URIs around to any proxy in the 
world without danger of accidentally misinterpreting them.  Requests 
which go to a proxy that doesn't understand a particular context will 
get rejected with a 404 (this is a GOOD thing).  This is a significant 
improvement over a misrouted request doing something really wring or 
unexpected by interpreting a dial string in the wrong context.

> It is often more practical to have the
> proxy interpret a dial string.

fine.  I've already demonstrated 2 ways to do that without polluting 
the semantics of userinfo when user=phone.

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

as I said above, there is no backwards compatible solution, since 
everyone is using different conventions and semantics.  lets just fix 
the problem and move on.

thanks,
-rohan

> 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: "Francois Audet" <[email-masked]>
Date: Fri, 19 Sep 2003 14:04:28 -0700

> From: Stastny Richard [mailto:[email-masked]] 
> Sent: Friday, September 19, 2003 13:55
> To: Audet, Francois [SC100:4K02:EXCH]; Rosen, Brian; Rohan Mahy
> Cc: Paul Kyzivat; Bob Penfield; [email-masked]
> Subject: AW: [Sip] SIPIT Interop problem with ;user=phone
> 
> 
> Thats what I meant in my original example:
> If you have a dumb phone, its sends everything to 
> sip:[email-masked] - which is a dialing string

Then you need one proxy per dialing plan (munich.proxy.com,
wien.proxy.com, us-west.proxy.com, cdn.proxy.com, beijing.proxy.com,
etc.). The advantage of the phone-context is that you can support
multiple dialing plans (like all multinational corporations do today),
but you can do it without deploying multiple proxies if you don't need
to. And the phone doesn't need to understand this.

To make it even more obvious, one user could have extension
3756 in California, and another one the same in Chicago. 

sip:3756;phone-context=[email-masked];user=phone is
different from
sip:3756;phone-context=[email-masked];user=phone.

But there is only one proxy (proxy.com). With your mechanism, you'd need
one proxy for chicago.proxy.com and another for santaclara.proxy.com.

> If you have a smart UA, it translates the dialstring to
> either a tel:nnn;phone-context=company.com
> or a tel:+nnnn - which is a E164 number
> BTW: this is preferred anyway.

Correct.

> If you have a very clever UA, e.g. a SNOM,
> it translates the dialstring into an E.164 number,
> queries ENUM, returns a sip:user@host and
> we do not have any problem at all ;-)
>  
> Richard
> PS: note that ;user=phone is not needed anywhere

---

From: "Stastny Richard" <[email-masked]>
Date: Sat, 20 Sep 2003 00:04:29 +0200

I understand your example, but I thought we are talking
about dunb UA without having dialing plans built in.
 
How do you tell your phone to send append in one case
santaclara.proxy.com and in the other case
chicago.proxy.com if you just dial 3756?
 
Either you use an access code, but then you have
a dialing plan built in, or you sent it with the
access code to the default proxy and let it doing the work,
 
or you use separate lines and swich between them.
 
Richard

	-----Ursprüngliche Nachricht----- 
	Von: Francois Audet [mailto:[email-masked]] 
	Gesendet: Fr 19.09.2003 23:04 
	An: Stastny Richard; 'Rosen, Brian'; 'Rohan Mahy' 
	Cc: 'Paul Kyzivat'; 'Bob Penfield'; [email-masked]' 
	Betreff: RE: [Sip] SIPIT Interop problem with ;user=phone

	sip:3756;phone-context=[email-masked];user=phone is 
	different from sip:3756;phone-context=[email-masked];user=phone. 

	Correct. 

	> PS: note that ;user=phone is not needed anywhere 

J*fj)b�	b��m��?�0�'�~���f��f��X��)ߣ�"�8b�X��+��DYׯzZ)�����ay�+y">�-��%RǬ����W�z{h��,r�n���y۟���z�b�{(�˫����*T��"����'�~��~��{^��h�g���'����bq�b�z�*