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

From: "Rosen, Brian" <[email-masked]>
Date: Wed, 1 Oct 2003 14:12:58 -0400

Getting back to this.  I was working on other things.

One overriding criticism I have for this post is that it assumes
that a gateway is the ultimate destination for a call with user=phone.
It isn't.  A sipphone is just as likely a destination as a gateway.
If I assign an E.164, or an internal number, to a phone so that 
callers with TDM equipment can call them (or simplistic user interfaces
that encourage meaningless strings of digits as the user part of
a nice sip AOR), then when I call it, many, many existing systems
will append user=phone to the request URI.  

Much more in line

> -----Original Message-----
> From: Dean Willis [mailto:[email-masked]]
> Sent: Monday, September 22, 2003 12:06 PM
> To: Rosen, Brian
> Cc: 'Stastny Richard'; Rohan Mahy; Francois Audet; Paul Kyzivat; Bob
> Penfield; [email-masked]
> Subject: RE: [Sip] SIPIT Interop problem with ;user=phone
> 
> 
> 
> Ah! I think we have something here!
> 
> Brian said:
> > 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.
> 
> 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.
Woah.  I think gateways are the least interesting part of the problem.

I agree that a gateway doesn't need or care about user=phone.

I agree that gateways sometimes have the ability to transform dial strings
to phone numbers.  I think that only adds to the confusion we now have.
Gateways that I know about can't differentiate between a dial string
and a phone number; they treat all input as dial strings.  If the
environment
those gateways were a part of had phone numbers that were not dial strings,
they would be incapable of dialing the phone numbers.  Some element would
have to make sure the user part was a dial string.  It would be useful,
I think, for there to be a way to tell the difference.  Then such gateways
could selectively apply the transformation logic.

> 
> 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.
I don't know of any device that does this.  Specifically, no device
that I know of has any way to know what the characteristics of the
destination is - gateway, sipphone, H.323 phone,...

If you said "as a way to indicate that this is a phone number,
maybe we could get somewhere.
> 
> 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.
Again, I know of no device that does this.  No device that I know of
has any way to know whether a numeric user part has anything to
do with PSTN signalling or not, whether there is a gateway of any
kind involved. or whether the numeric string is translatable to
PSTN signalling

> 
> 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.
Ahh, at last.  Yes, this is ONE possible use of user=phone.

> 
> 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.
Agree this could be a use of user=phone, and I agree it may not be the
best use.  I think we need a way to know if this is a phone number or
a dial string.  It's not clear to me that we need to know if there
was dial string to phone number conversion somewhere along the line.
I can't think of why you need that.  A uri originating
as a phone number is interchangeable, I think, with a dial string
transformed to a phone number.  The requirement is to differentiate
dial strings from phone numbers, not the history of how we came to
have one or the other.

> 
> 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.
Yeah, I first was confused by this, but I now understand that if you
have, for example, a real E.164, but your gateway faces a PBX, you usually
can't give the PBX the E.164.  You have to transform it into a dial
string (prepend with 9 for example).

This again argues for a way to know if a uri is a dial string or a 
phone number.

> 
> 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.
Agree again that this is one use user=phone has been put to.
Generally, we treat user input as a dial string, but we don't really
have to, that's just a convention.

> 
> Brian further expounds:
> 
> > 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.
> > 
> 
> In this case, you appear to be using mode 6 as described above.
No, my point was that if I have one phone that sends a dial string,
and another phone that sends a phone number, at some point, someone
has to know that they are interpreted differently.

> 
> 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.
Well, agree except for the "globally routable" part.  It's routable.
but it may not be globally routable.

Today, some phones with this capability do add user=phone.  Some don't.
> 
> 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.
Right.  Most of the phones I know that send dial strings add user=phone.
Can't claim that they all do.

> 
> 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.
Well, this is the problem the thread started with.  Agree that this is
where we are, and it's not good.

> 
> 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).
Quibble with wording, but agree that the originator adds user=phone under
some circumstances, and targets generally don't care.

> 
> 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.
I don't see that everyone else has that point of view, but I think you
have done a good job of explaining why the destination is not
interested in user=phone.  An intermediate proxy might be, but today,
it's problematic.

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

_______________________________________________
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: Wed, 01 Oct 2003 15:35:46 -0400

> has to know that they are interpreted differently.

Brian,

You keep bringing up the same issues, but you haven't responded to 
earlier proposals that address your concerns. Specifically, how does the 
following not meet your needs?

- one phone-context to represent a dial string
- a different phone-context to represent a (local) phone number.

As best I can tell, this should meet your needs, even if it isn't in the 
form you would prefer.

Proxies that translate a dial string into a phone number also make the 
appropriate change to the the phone-context. Anybody that receives such 
a thing and doesn't understand the context can either pass it on to 
somebody else that might, or can simply fail.

BTW, I agree that the presence or absence of gateways doesn't change 
this problem at all.

	Paul

---

From: Rohan Mahy <[email-masked]>
Date: Wed, 1 Oct 2003 13:17:07 -0700

On Wednesday, October 1, 2003, at 11:12 AM, Rosen, Brian wrote:

> a dial string.

I still don't get what you are on about here.  How does a HUMAN know if 
something is a phone number or a dial string?  they don't.  likewise, 
as long as we are leaving out wait and pause, you can represent all 
dial strings as a local-number in the ABNF of a tel URL. If you want to 
make a distinction here, why not just make one using phone-context?

> It's not clear to me that we need to know if there

again, you can use phone-context to disambiguate this if you'd like.

> have to, that's just a convention.

You can trivially scope this by adding an appropriate phone-context 
parameter here.

> has to know that they are interpreted differently.

I believe I already gave several examples using phone-context that 
allow you to disambiguate these.

>> user=phone) is at the heart of the discussion we're having.

yes.  I believe that user=phone  should mean that the USERpart = a 
PHONEnumber

> interested in user=phone.  An intermediate proxy might be, but today,

If I sent to a gateway:  INVITE sip:[email-masked];user=phone

and the gateway knew how to transform a global-number into whatever 
form was expected on its PSTN interface, then the user=phone is a 
property used by the TARGET.  the target could be a proxy, if the host 
part of the request URI corresponds to a domain for which that server 
is authoritative.

>> isn't particularly useful.

I think mode 3 is actually very useful as a convention.

thanks,
-rohan