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

From: "Rosen, Brian" <[email-masked]>
Date: Wed, 1 Oct 2003 16:44:00 -0400

edited for brevity

> >> 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.
> 
> 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?
Well, actually, humans often do know the difference, but that doesn't
matter.  It's the phone, and succeeding proxies that care, not the user.
Generally, a user enters a dialstring.

I've responded to the different context as the way to differentiate
in another message.

...snip...

> >> 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.
> 
> yes.  I believe that user=phone  should mean that the USERpart = a 
> PHONEnumber

Carefull.  That means it isn't a dial string :)

Brian

_______________________________________________
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: "Alexeitsev, D" <[email-masked]>
Date: Thu, 2 Oct 2003 10:34:40 +0200

Hello All,

Sorry if I'm getting too late, still I want add my two cents on this discussion

There are several possibilities how a User Equipment (UE) can send address information which is particularly true for the mobile phones. People dial network codes (for example "911") national number with prefix (for example "01234567899"), international number with prefix (for example "00123456789123" or "+123456789123") and so on.

I can not imagine that a UE can translate this dial strings in to E.164 numbers, just because this strings differs around the world.

So the UE just puts the string that a human dialled in to the Request-URI and now the interesting starts. I don't see the need of tel URI contexts as applied to the SIP protocol as there are already several ways in SIP how you can address the dial string analyser (thus define the context):

- address dialstring analyser in the host portion of SIP-URI, and put the dial string in to userpart
- address dialstring analyser in the Route: header field and put dial string in to tel URI
- address dialstring analyser in the IP header and put dial string in to tel URI (not recommended behaviour)

Note: Don't know why would someone use the last two items as they are just the separation of the information that can be put in one place: SIP-URI.

By addressing dialstring analyser, one has already defined the context, so there is no need to put one. No user=phone as the UE can not do the dialstring-to-E.164 conversion.

After dialstring analyser did his job there will be FQe164, that shall be used in the global Internet. My understanding was that the dialstring analyser then puts user=phone as the address information in SIP-URI userpart is FQe164 and it is formatted according to the RFC 2806.

Greetings,
Denis Alexeitsev

---

From: "Rosen, Brian" <[email-masked]>
Date: Fri, 3 Oct 2003 08:39:20 -0400

Denis

Most phones today put a dial string in the user part, put their outbound 
proxy in the host part, and set user=phone.  Right now, if you use such 
phones with a proxy server that is a dialstring analyzer, it will work.  
If the first hop proxy is not the dialstring analyzer, it would fail.  
It would work to change such phones to put a configurable route to  
dialstring analyzer in the INVITE, but the context makes that unnecessary,
as long as you can differentiate dialstrings from phone numbers.  This
thread has had several proposals on how to do that.  Please note that there
are phones that do dialstring analysis, and thus it is important for any
proxy in the path to know if dialstring analysis has already been
done.

Context is a useful concept, for both dialstrings and phone numbers, 
because one element may serve as the dialstring analyzer for a variety 
of environments.  It is common, for example, to have one proxy serve 
several sites.  Each site may have a somewhat different dial plan.  
In such a case, you want the dialstring analyzer to know which dial 
plan is needed.  That is what context does for you.

Finally, the result of dialstring analysis is a phone number, but it may
not be an E.164.  It could be a local number -- a 2,3 or 4 digit 
extension number, for example.

Brian

> -----Original Message-----
> From: Alexeitsev, D [mailto:[email-masked]]
> Sent: Thursday, October 02, 2003 4:35 AM
> To: [email-masked]
> Subject: AW: [Sip] SIPIT Interop problem with ;user=phone
> 
> 
> Hello All,
> 
> There are several possibilities how a User Equipment (UE) can 
> send address information which is particularly true for the 
> mobile phones. People dial network codes (for example "911") 
> national number with prefix (for example "01234567899"), 
> international number with prefix (for example 
> "00123456789123" or "+123456789123") and so on.
> 
> I can not imagine that a UE can translate this dial strings 
> in to E.164 numbers, just because this strings differs around 
> the world.
> 
> So the UE just puts the string that a human dialled in to the 
> Request-URI and now the interesting starts. I don't see the 
> need of tel URI contexts as applied to the SIP protocol as 
> there are already several ways in SIP how you can address the 
> dial string analyser (thus define the context):
> 
> - address dialstring analyser in the IP header and put dial 
> string in to tel URI (not recommended behaviour)
> 
> Note: Don't know why would someone use the last two items as 
> they are just the separation of the information that can be 
> put in one place: SIP-URI.
> 
> By addressing dialstring analyser, one has already defined 
> the context, so there is no need to put one. No user=phone as 
> the UE can not do the dialstring-to-E.164 conversion.
> 
> After dialstring analyser did his job there will be FQe164, 
> that shall be used in the global Internet. My understanding 
> was that the dialstring analyser then puts user=phone as the 
> address information in SIP-URI userpart is FQe164 and it is 
> formatted according to the RFC 2806.
> 
> Greetings,
> Denis Alexeitsev
>

---

From: "Francois Audet" <[email-masked]>
Date: Fri, 3 Oct 2003 09:06:05 -0700

That's the whole point. It's the only proposal that scales. The other
proposals have the problem that they don't scale because they assume a
single dialing plan per proxy.

This proposals allows as many dialling plans as you want. This is useful for
multi-tennant, geographically disperse enterprises, virtual private
telephony services, etc.

-----Original Message-----
From: Alex Audu [mailto:[email-masked]] 
Sent: Friday, October 03, 2003 07:55
To: Audet, Francois [SC100:4K02:EXCH]
Cc: 'Rohan Mahy'; 'Rosen, Brian'; 'Paul Kyzivat'; 'Dean Willis'; 'Stastny
Richard'; 'Bob Penfield'; [email-masked]'
Subject: Re: [Sip] SIPIT Interop problem with ;user=phone

Hello Francois, 
How will your proposal scale?  I am not too sure. 
Regards, 
Alex. 
Francois Audet wrote: 
  
> Several times in this thread, I have given motivations for 
> functionality you can get if you follow my proposal, such as 
> one proxy 
> handling multiple digit maps (for example in a multi-tenant 
> situation). 
>   You have not addressed these cases.  Nobody has provided 
> any technical 
> reason why my proposal doesn't work, and I have given many 
> reasons why 
> it works.  I will have an ID out in a few days which describes the 
> motivations and detailed scenarios for my approach.  Until 
> then, let's 
> please pause this thread. 
Finally! Agreed 100%.

---

From: "Alexeitsev, D" <[email-masked]>
Date: Mon, 6 Oct 2003 15:32:52 +0200

Hello Brian, All

Thanks a lot for this summary,

Few points/questions that I still have

What is the advantage of having context that is a given URI or set of URIs specific if there are already mechanisms in SIP to URI-independently address the dialstring analyser using "configurable route" procedures?

In my opinion the whole dialstring issue can be solved by the currently available mechanisms:

SIP URI has the context definition as it has the mandatory hostportion. The problem with the digit analyser not being the outbound proxy is solved by the "configurable route" procedures.

What people are seeking is probably the description on how to resolve the tel URI in the SIP environment. And this can simply done by putting the context in to the hostportion of SIP-URI and the address of dialstring analyser in to the Route header (if needed).

Anyway I don't see any need for the tel URIs in the SIP Request-URI due to the given conversion simplicity.

The only thing that requires consideration is how and if it is needed at all to show that the resolution of dial string to a telephone number was done.

Greetings,
Denis Alexeitsev

-----Ursprüngliche Nachricht-----
Von: Rosen, Brian [mailto:[email-masked]]
Gesendet: Freitag, 3. Oktober 2003 14:39
An: Alexeitsev, Denis; [email-masked]
Betreff: RE: [Sip] SIPIT Interop problem with ;user=phone

Denis

Brian