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

From: "Rosen, Brian" <[email-masked]>
Date: Fri, 19 Sep 2003 16:02:18 -0400

Richard

A user at a dumb phone always enters a dial string.
No argument.

However, at some point, either a UA translates a dial string
to a phone number, or a downstream proxy does it.  At that point
it isn't a dial string, it's a phone number, and it might be
in a context (it could be global).  What I've mentioned is
a case, which I think is pretty common, where the number is
not represented the same way as a dial string and a phone number,
and yet is in the same domain.

Let's take a practical example.  Suppose I have a domain with
a reasonably smart proxy server and a mix of phones.  Some phones
have dialstring translation, some don't.  The proxy server
can translate dial strings to phone numbers, and it also can
route phone numbers.  Obviously it can do both (ie translate then
route).

Now, how does the proxy know if it needs to translate?  That is,
how does it know that a uri passed to it is a dial string vs
a phone number?  If I pass it a phone number and it decides to
apply it's dialstring processing, that will fail.  If I pass a 
dial string and it just routes, that will fail.  It has to know
what it is given.  In my example it was [email-masked]
That's a phone number, and a dial string, but it's two different
destinations.  In my numbering plan, it's my phone.  In my dialing
plan it's an extension in another office.

Brian

Brian

> -----Original Message-----
> From: Stastny Richard [mailto:[email-masked]]
> Sent: Friday, September 19, 2003 3:33 PM
> To: Rosen, Brian; Rohan Mahy
> Cc: Francois Audet; Paul Kyzivat; Bob Penfield; [email-masked]
> Subject: AW: [Sip] SIPIT Interop problem with ;user=phone
> 
> 
> Brian,
>  
> If you pick up a phone and enter digits, it ALWAYS a dialing string
> and you are ALWAYS in ONE and ONLY ONE dialing plan..
>  
> You never enter a phone number directly, you always
> dial (if you dial a local number, the mapping may be 1:1)
>  
> So if you enter a dial string in a SIP phone and iu sends
> it with [email-masked] to your defaulr sip server, this server
> then evaluates the dialing plan and translates it to a numbering plan.
>  
> Btw, thats exactly how fwd, iptel sipphone, ... are implemeted.
>  
> Richard
> 
> 	-----Ursprüngliche Nachricht----- 
> 	Von: Rosen, Brian [mailto:[email-masked]] 
> 	Gesendet: Fr 19.09.2003 19:37 
> 	An: Stastny Richard; Rohan Mahy 
> 	Cc: Francois Audet; Paul Kyzivat; Bob Penfield; [email-masked] 
> 	Betreff: RE: [Sip] SIPIT Interop problem with ;user=phone
> 	
> 	
> 
> 	Richard
> 	
> 	My phone number within my local domain is 742-6826.
> 	I could change the convention and make it 724-742-6826 or
> 	1-724-742-6826 if you want.
> 	
> 	My dial plan would send a call to a different phone if you
> 	dialed any of those strings.
> 	
> 	If you send an INVITE [email-masked] it will ring
> 	my sipphone. 
> 	
> 	If I dial 7426826, it won't ring my sip phone.  I have to dial
> 	6826 or 9-742-6826  or even 300-6826.
> 	
> 	Using your algorithm, I would assume 7426826 was a dial string,
> 	and that would be wrong.
> 	
> 	Brian
> 	
> 	> -----Original Message-----
> 	> From: Stastny Richard [mailto:[email-masked]]
> 	> Sent: Friday, September 19, 2003 1:24 PM
> 	> To: Rosen, Brian; Rohan Mahy
> 	> Cc: Francois Audet; Paul Kyzivat; Bob Penfield; [email-masked]
> 	> Subject: AW: [Sip] SIPIT Interop problem with ;user=phone
> 	>
> 	>
> 	> See below
> 	>
> 	>       -----Ursprüngliche Nachricht-----
> 	>       Von: Rosen, Brian [mailto:[email-masked]]
> 	>       Gesendet: Fr 19.09.2003 15:17
> 	>       An: 'Rohan Mahy'
> 	>       Cc: 'Francois Audet'; 'Paul Kyzivat'; 'Bob Penfield';
> 	> [email-masked]'
> 	>       Betreff: RE: [Sip] SIPIT Interop problem with 
> ;user=phone
> 	>      
> 	>      
> 	>
> 	>       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.
> 	>
> 	> Richard: A string of digits is a string of digits.
> 	>
> 	> The simplest way to distinguish is:
> 	>
> 	> 1. If you just see a string of digits, you have to assume its
> 	> a dial string
> 	>
> 	> until you know better.
> 	>
> 	> 2. If you analysed the digits and found out its an E.164
> 	> number, normalise it
> 	>
> 	> to tel:+xxxx, or sip:[email-masked]
> 	>
> 	> 3. If you analysed it and found out it is a local 
> number, then either
> 	>
> 	> use tel:xxxx; phone-context=foo.bar or 
> sip:[email-masked];user=phone
> 	>
> 	> I do not understand the problem
> 	>
> 	> Richard
> 	>
> 	>      
> 	>      
> 	>       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: Dean Willis <[email-masked]>
Date: Mon, 22 Sep 2003 11:06:22 -0500

Ah! I think we have something here!

> and yet is in the same domain.

Actually, this isn't quite right. Proxies transform URIs. They can do
all sorts of transformations -- changing the domain, the user part,
parameters, etc. for any number of reasons and using any number of
mechanisms to specify that transformation. It's never a dial-string when
it's being processed by a proxy. It might CONTAIN information that is
meant to represent a dial-string, but it's a request URI as long as
we're thinking about the problem from the proxy's perspective.

Eventually, that request (and its associated, potentially transformed
URI) may be delivered to a telephony gateway. The gateway's job is to
construct appropriate PSTN signaling based on the request-URI. By
today's convention, simple gateways take the user part of the request
URI and use it as the signaling input to the PSTN -- i.e., a "dial
string". More sophisticated gateways verify that the host-part of the
request (if any) targets the gateway. Even more sophisticated gateways
perform their own transformations on the user part, perhaps applying
regular expressions or similar programatic mechanisms. Oddly enough, no
gateway that I'm aware of treats a request any differently if it has a
user=phone parameter than it does if there is no user=phone parameter,
and there's not even any way to test for this in the expression language
of such gateways, as far as I know.

So who does pay attention to a parameter of user=phone? Potentially, it
is considered by intermediate proxies, who are trying to decide 1) What
transformation to make to the request URI, if any, and 2) Where to send
the request next.

I believe there have been suggestions that proxies use user=phone in
several distinct ways:

1) As a way to indicate that this request URI is intended for eventaul
delivery (unless otherwise transformed) to a PSTN gateway.

2) As a way to indicate that the request URI MUST be delivered to a PSTN
gateway, and that the user-part of the request-URI is expected to be
meaningly translatable to PSTN signaling by a gateway in the domain or
context of the request.

3) As a way to inidcate that the SIP or SIPS request-URI was constructed
from a tel URI, which transformation may or may not be reversable.

4) As a way to indicate that some prior device in the processing chain
has transformed the user-part of the request URI FROM a dial-string to
some sort of unique user-part so that it can be used in routing. This
might be better addressed by a "history" sort of operation.

5) As a way to indicate that some prior device in the processing chain
has transformed the user part INTO a dial-string which can be correctly
interpreted by a specific PSTN gateway. This might be better addressed
by a "history" sort of operation.

6) As a way to indicate that the originating UA doesn't know what to do
with user-input and that further transformation is required by a proxy
for the request-URI to resolve to the intended target.

> plan it's an extension in another office.

In this case, you appear to be using mode 6 as described above.

Discussion: 

Some phones know how to transform a sequence of user-entered digits into
a routable request. These phones, when presented a user input loooking
like a string of digits, use this capability to generate a request URI
targeting the (effectively) globally-routable destination. Such a
request has no user=phone parameter.

Other phones do NOT know how to do this translation and just paste the
collected digits into the user-part of a request and add user=phone.

A routing proxy, receiving a request, applies different routing and
transformation logic to a request having user=phone than it does to a
request not having that parameter. This may result in identical outputs
for requests with/without user=phone, or it may result in divergent
outputs.

Conclusion:
 
I believe that in this usage, the presence of user=phone in a request
indicates something about the ORIGINATOR of the request (this request
came from a stupid phone) and not something about the TARGET of the
request (this request is meant to go to the PSTN).

I think this distinction (Exactly WHO is a "phone" when the request says
user=phone) is at the heart of the discussion we're having. And I don't
believe your usage is at all consistent with what I've heard from many
other people on this list, who believe that "user=phone" is a property
of the request's TARGET, not a property of the request's ORIGINATOR.

Admittedly, when viewed this way, it makes more sense than some
suggestions. Note that modes 1 and 2 above break things, and mode 3
isn't particularly useful.

I'm still not sure where this leaves us, but am beginning to hope that
we understand the underlying confusion.

--
Dean

---

From: Rohan Mahy <[email-masked]>
Date: Thu, 25 Sep 2003 07:31:12 -0700

On Friday, September 19, 2003, at 01:02 PM, Rosen, Brian wrote:

> destinations.  In my numbering plan, it's my phone.

Brian,

I expect that your address should be more like this:

sip:[email-masked]
sip:[email-masked]
tel:6826;phone-context=pit.marconi.com
tel:7246826;phone-context=marconi.com
tel:7246826;phone-context=+1222
tel:+12227246826

which would make the dial string for the extension in the other office  
simply:

tel:7246826;phone-context=pit.marconi.com

but since you haven't given me much more to go on, I will assume two  
different contexts.  One for the numbers you dial on your phone, and  
another for your internal representation of a "phone number"  whatever  
that is.

someone could express your phone number as:
tel:7248626;phone-context=pit.marconi.com

which then gets converted to:
sip:7248626;phone-context=[email-masked];user=phone

where a marconi.com proxy retargets to one of your AORs:
sip:[email-masked]

when you dial a particular a dial string:
sip:7248626;phone-context=pit-dial- 
[email-masked];user=phone

the marconi.com proxy can apply the pittsburgh dial plan and generate  
whatever target it is supposed to generate.  maybe:
sip:[email-masked]  or tel:+442081118626, or whatever it means.

thanks,
-rohan

>  In my dialing