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

From: "Rosen, Brian" <[email-masked]>
Date: Fri, 19 Sep 2003 13:23:38 -0400

The sip entities know the difference and it matters.
There is clearly a difference between a local number within
a context and a dial string, which is also within a context.
7247426826 is a legal number within my local context, but
I can't dial that.  I can dial 6826, 300-6826, 9-724-742-6826
or 9-1-724-742-6826 to get it.  On the other hand 9-724-742-6826
is not a number in my local context, it's a dial string.
300-6826 is both a dial string and a legal number.
Your post has more examples of where there is confusion
between dial strings and phone numbers.

A UA that is not equipped to translate a dial string
to a phone number sends a dial string, in a context if you
would like.  A proxy that translated the dial string to
a phone number knows that's what it is doing.  A proxy that
routes phone numbers may or may not know how to translate
a dial string to a phone number, those are two separate
functions.

We need to mark the URI with what it represents.

I have never argued for adding p/w to a tel uri.  I think
it's usefull to have in a dial string.  But then I'd
never put a dial string in a tel uri.  Tel URIs carry
phone numbers.  It says so :)

Brian

> -----Original Message-----
> From: Rohan Mahy [mailto:[email-masked]]
> Sent: Friday, September 19, 2003 12:07 PM
> To: Rosen, Brian
> Cc: 'Francois Audet'; 'Paul Kyzivat'; 'Bob Penfield'; [email-masked]'
> Subject: Re: [Sip] SIPIT Interop problem with ;user=phone
> 
> 
> Brian,
> 
> I don't think even humans can distinguish between dial strings and 
> phone numbers without the appropriate context.  For example, the 
> following is both a real dial string at Cisco for intersite dialing, 
> and a local phone number in Stockholm (and probably many other places 
> as well).
> 
> 85268570
> 
> likewise, I worked at NASA in 1993 who had a 7-digit dialplan.  Most 
> dial strings there where indistinguishable from local 7-digit numbers 
> in use North America (this was before 10-digit dialing came 
> to Atlanta, 
> New York, etc..).
> 
> AFAIK, most users do not understand the distinction you are 
> making.  Is 
> *69 a phone number or a dial string?  How about 411 in North 
> America?  
> What about "0" in North America  and "9" in many other parts of the 
> world?  Was that a phone number or a dial string?  I have concluded 
> that as long as the set of digits is properly labeled with 
> the correct 
> context it really doesn't matter, and that this type of distinction 
> between dial strings and phone numbers is artificial and academic.
> 
> If you would like to use some additional private conventions inside 
> your domains that is fine, but I don't think we are going to get 
> consensus on the difference between a phone number and a dial 
> string in 
> this forum.
> 
> Finally, I think the intention of 2806bis is to ignore pauses 
> and waits 
> of various tones, and I think we agree that those don't need to go 
> inside a tel URI.
> 
> thanks,
> -rohan
> 
> 
> On Friday, September 19, 2003, at 06:17 AM, Rosen, Brian wrote:
> 
> > I've never seen E/F substitution for */#, and I've never seen any
> > sip device that did it, but it's a possible way forward.
> >
> > I do think that some RFC would have to change the wording of
> > 2806bis to allow dial strings.  The authors seemed to explicitly
> > declare them out of scope of the document.  Generally, we don't
> > usually claim "that which is not specifically disallowed is legal"
> > as a way around "out of scope" wording in our documents.
> >
> > I remain unhappy that dial strings, untranslated phone numbers
> > and translated phone numbers are indistinguishable.  They are 
> > different,
> > they are handled differently, and they should be distinguishable.
> > I don't understand why some people are so adamant that they 
> should all
> > be represented in EXACTLY the same way (tel uri or sip uri with
> > or without user=phone).  They are not the same things, and they
> > should have distinctive representations.
> >
> > Brian
> >
> >> -----Original Message-----
> >> From: Rohan Mahy [mailto:[email-masked]]
> >> Sent: Thursday, September 18, 2003 9:17 PM
> >> To: Rosen, Brian
> >> Cc: 'Francois Audet'; 'Paul Kyzivat'; 'Bob Penfield'; 
> [email-masked]'
> >> Subject: Re: [Sip] SIPIT Interop problem with ;user=phone
> >>
> >>
> >> On Monday, September 15, 2003, at 10:23 AM, Rosen, Brian wrote:
> >>> Well this goes to the issue Paul and I have disagreed on.
> >>>
> >>> I think the wording of the tel uri RFC is quite clear that you
> >>> can't pass a dial string in one.  You certainly can't 
> pass one with
> >>> star and pound.   Therefore, I claim, there is no way to pass
> >>> a dial string
> >>
> >> Brian,  What part of a dial string doesn't fit into: 
> 1*phonedigit   ?
> >>
> >> phonedigit = "0" / "1" / "2" / "3" / "4" / "5" / "6" / "7" /
> >> "8" / "9" /
> >>               "A" / "B" / "C" / "D" / "E" / "F"
> >>
> >> E corresponds to *  and F corresponds to #
> >>
> >> thanks,
> >> -rohan
> >>
> >>
> >>> , unless you put it in a username on a SIP uri,
> >>> and denote that it is a dial string, for which a phone number is
> >>> a proper subset for most dial plans, by specifying user=phone.
> >>>
> >>> Paul disagrees.  He thinks he can send a dial string in a tel uri.
> >>> Without some kind of resolution of that issue, we have a problem.
> >>>
> >>> Brian
> >>> -----Original Message-----
> >>> From: Francois Audet [mailto:[email-masked]]
> >>> Sent: Monday, September 15, 2003 12:10 PM
> >>> To: 'Paul Kyzivat'
> >>> Cc: 'Rosen, Brian'; 'Bob Penfield'; [email-masked]'
> >>> Subject: RE: [Sip] SIPIT Interop problem with ;user=phone
> >>>
> >>>
> >>>> -----Original Message-----
> >>>> From: Paul Kyzivat [mailto:[email-masked]]
> >>>> Sent: Monday, September 15, 2003 06:58
> >>>> To: Audet, Francois [SC100:4K02:EXCH]
> >>>> Cc: 'Rosen, Brian'; 'Bob Penfield'; [email-masked]'
> >>>> Subject: Re: [Sip] SIPIT Interop problem with ;user=phone
> >>> [ stuff deleted as it looks like we are in agreement ]
> >>>> I'm not sure about the "most" part. Some do, some don't. 
> As spec is
> >>>> currently written, the equivalence between tel and
> >> sip/user=phone is
> >>>> only one way. (IF the userpart comes from a tel, then there
> >>>> SHOULD be a
> >>>> user=phone, but the presence of user=phone does not imply the
> >>>> userpart
> >>>> conforms to tel.)
> >>>>
> >>>> I personally am happy with the more strict 
> interpretation. But I am
> >>>> trying to hold out an olive branch in order to reach a level
> >>>> of agreement.
> >>> OK. It seems that we are in agreement.
> >>> My suggestion is to ask the question to the group of is anybody
> >>> objects to make it explicit that user=phones means that the
> >> sip URI is
> >>> derived
> >>> from a tel URI?
> >>> If the answer is no, then I think we can probably finally put this
> >>> issue
> >>> to rest. Otherwise, we need to rework the whole thing...
> >>> So... Does anybody strongly object to explicitly making the
> >> user=phone
> >>> atttribute mean that the SIP URI was derived from a tel URI?
> >>>>> Applying the rules of RFC3261/19.1.6 instead, we'd get:
> >>>>>
> >>>>>
> >>>>> sip:1234;phone-context=[email-masked];user=phone
> >>>>>
> >>>>> Which (like the tel URI) specifically identifies the
> >>>> dialing plan and
> >>>>> does not require one DNS entry per dialling plan.
> >>>>
> >>>>
> >>>> I agree that this is also a fine usage.
> >>>>
> >>>> But what is benefit of this over using the tel format and
> >>>> then passing
> >>>> the request to sip:foo.bar?
> >>> The tel URI format assumes that the proxy knows which proxy
> >> is aware
> >>> of the
> >>> phone context
> >>> and tel URIs (it could be itself, or it could know which
> >> proxy to route
> >>> sessions to).
> >>> The sip URI format lets you route it to a specific proxy
> >> that is aware
> >>> of
> >>> the phone
> >>> context, potentially with "generic" SIP proxies in between
> >> that have
> >>> no idea
> >>> how to route
> >>> based on phone contextes (or even tel URIs). T
> >>>
> >>>
> >>> They both have merits.
> >>>
> >>> _______________________________________________
> >>> 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, 19 Sep 2003 16:55:33 -0400

Brian,

I am going to make here essentially the same point that Francois made in 
response to another of your messages. See below.

	Paul

> a context and a dial string, which is also within a context.

So, what you are saying is that there are two contexts here, one for 
local numbers and one for dial strings. I think we are all in agreement 
on that. We are only disagreeing on how to identify those.

> between dial strings and phone numbers.

Using Francois's example names for contexts and your phone numbers 
above, I would represent all of those as:

tel:7247426826;phone-context=global.marconi.com
tel:6826;phone-context=dial-digit-us.marconi.com
tel:3006826;phone-context=dial-digit-us.marconi.com
tel:97247426826;phone-context=dial-digit-us.marconi.com
tel:9-1-724-742-6826;phone-context=dial-digit-us.marconi.com
tel:300-6826;phone-context=global.marconi.com

sip:7247426826;phone-context=[email-masked];user=phone
sip:6826;phone-context=[email-masked];user=phone
sip:3006826;phone-context=[email-masked];user=phone
sip:97247426826;phone-context=[email-masked];user=phone
sip:9-1-724-742-6826;phone-context=[email-masked];user=phone
sip:300-6826;phone-context=[email-masked];user=phone

I *think* you want to use the same context for both dial strings and 
local numbers, and use user=foo to distinguish between them - perhaps 
something like

sip:7247426826;phone-context=[email-masked];user=phone
sip:6826;phone-context=[email-masked];user=DIALED
sip:3006826;phone-context=[email-masked];user=DIALED
sip:97247426826;phone-context=[email-masked];user=DIALED
sip:9-1-724-742-6826;phone-context=[email-masked];user=DIALED
sip:300-6826;phone-context=[email-masked];user=phone

A possible disadvantage of this is that you then can't use tel: for dial 
strings. The other disadvantage is that its using two nails where only 
one is needed.

Do you have some fundamental problem with having different context names 
for dial strings and local numbers?

> We need to mark the URI with what it represents.

No disagreement with any of the above. In the examples above, that 
marking would occur by virtue of the proxy translating,

   from: tel:6826;phone-context=dial-digit-us.marconi.com
     to: tel:7247426826;phone-context=global.marconi.com

Of course, it would be better if the proxy translated all the way to a 
global number if there is one.

> it's usefull to have in a dial string. 

My phone doesn't have either a "," or a "w" key.

AFAIK, those are rarely if ever parts of real dial strings. They are 
meta information sometimes encoded for various purposes. But they don't 
seem relevant here.

	Paul