Subject: Re: [Enum] Re: [voipeer] Re: [Geopriv] Re: [Simple] tel URIsin commonpolicy

From: "Stastny Richard" <[email-masked]>
Date: Thu, 18 Aug 2005 21:05:17 +0200

Jonathan,
 
I think you made a very important point here for
a BCP coming out for voipeer:
 
>INVITE tel:+1973952500 SIP/2.0
>Route: sip:<whatever-you-want>@gateway.provider.com
 
instead of the currently used 
sip:tel:+1973952500 @gateway.provider.com;user=phone
 
I will try to summarize:

1. The user A normally enters a dialstring, which
should be signalled with
a. sip:[email-masked];user=dialstring;phone-context=+1
(luckily there does not exist a global dialling plan, so always
a context can be submitted)
other examples are:
sip:[email-masked];user=dialstring;phone-context=+431
or 
sip:[email-masked];user=dialstring;phone-context=companyA.com
 
b. only if the user enters a full E.164 number with + (or the device is
able to convert this by its own, the signalling should be
either with a tel:+4319793321
or with sip:[email-masked]
The preferred way should be recommended
 
2. the SIP server of user A provider is now trying
to figure out what to do with the dialstring, e.g. using local mapping
or translate it to an E.164 number
Now the provider either tries to look up ENUM to get a SIP
URI or forward the call to a gateway to the PSTN
by one of the above proposed methods

>INVITE tel:+1973952500 SIP/2.0
>Route: sip:<whatever-you-want>@gateway.provider.com
or
sip:tel:+1973952500 @gateway.provider.com;user=phone
 
There is only one issue left out: there is more then dialstrings
which always have local context and full E.164 numbers
it is national numbers and non-E.164 numbers defined
in RFC3966 defining the tel: URI
 
These are in my opinion no URN (because they are not unique
and also need always a context.
 
It should be recommended that if possible always the global
format should be used, the translation to a required national format
should be done by the gateway interfacing to the PSTN
 
For signalling non-E.164 numbers some additional investigation
seems to be necessary (examples)

-richard

________________________________

Von: [email-masked] im Auftrag von Jonathan Rosenberg
Gesendet: Do 18.08.2005 17:12
An: Brian Rosen
Cc: [email-masked]; [email-masked]; 'Otmar Lendl'; [email-masked]
Betreff: Re: [Enum] Re: [voipeer] Re: [Geopriv] Re: [Simple] tel URIsin commonpolicy

I agree. There is a two step process, fundamentally:

dial string ----> name -----> address

The translation steps themselves can be done entirely in the UA,
entirely in a proxy, or split. When one step is done in a UA, and the
other in a proxy, there is a need to convey the dial string, the name,
or the address on the wire (proxy to proxy is the same). The formats
here are:

1. dial strings would be represented using Brian's dial string draft, i.e.:

    sip:<dial-string>@domain;user=dialstring

2. names are represented as tel URI, and is obtained by applying the
dial string to the dial plan.

3. addresses are represented as a SIP URI with user=phone, and is
obtained by performing enum, or through any other suitable translation
service that can convert a name to an address. For example, a provider's
databases may definitively say that a particular name is its own, and
thus it can convert tel:number to sip:[email-masked];user=phone

In many cases, once a tel URI/name is determined, a provider can't
obtain a sip URI for it. All it knows is that the number lives on the
PSTN. In that case, it needs to go to a PSTN gateway. How to do this? I
would argue further that the PSTN gateway represents a ROUTE to get to
somewhere (the pstn) that can resolve the name to an address and route
it there (all within the PSTN). In SIP, the way we do routing is via
loose routes. So, to send a call to a pstn gateway:

INVITE tel:+1973952500 SIP/2.0
Route: sip:<whatever-you-want>@gateway.provider.com

The URI in the route header could contain a phone number in the user
part, but the resource being identified for the route is not the phone
number itself, but a piece of routing and gateway logic, and thus it
makes no sense to have user=phone there.

BTW, I had mentioned in the enum session while at the mic that I was
working on a doc that talked about phone numbers in SIP and the
difference between tel and sip URI; that doc basically says the above.

-Jonathan R.

Brian Rosen wrote:

> In step 1, if the phone does not do dialplan interpretation, then what the
> user entered is a dialstring, and not a telephone number.  This could be
> encoded, as you show, as a SIP uri, but might be better encoded as a
> dialstring, per draft-rosen-iptel-dialstring-02.txt.  A tel uri is
> explicitly NOT used to carry a dialstring.
>
> I think it would be better labeled as a dialstring, and not something that
> could be confused as a telephone number.  It remains true that the user-part
> of sip:[email-masked] can only be interpreted by the
> my-voip-provider.at domain, so your flow definitely can work.
>
> Brian
>
> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Otmar Lendl
> Sent: Thursday, August 18, 2005 6:33 AM
> To: [email-masked]; [email-masked]; [email-masked]
> Subject: [Enum] Re: [voipeer] Re: [Geopriv] Re: [Simple] tel URIs in
> commonpolicy
>
> On 2005/08/18 05:08, Jonathan Rosenberg <[email-masked]> wrote:
>
>>My point is that I think it makes sense to consider the tel URI a URN,
>>and that it is merely an accident of history that it wasn't a URN more
>>properly. Now, as you and I both know phone numbers in the PSTN are
>>abused to represent lots of things, but there is no reason to carry
>>forward this confusion into voip. This is why I am proposing that when a
>>phone number is in a tel URI, it represents a name. We don't know where
>>it is on the network (indeed even if its on an IP network). To know
>>that, we translate to an address. That address is a SIP URI. That SIP
>>URI can contain a phone number, i.e.
>>sip:[email-masked];user=phone, however in this format the
>>phone number has been resolved to an address. The act of porting a
>>number is a change in the translation of the phone number as a name (the
>>tel URI) to the phone number as an address (the SIP URI).
>>
>
>
> This is a very sensible notion.
>
> Based on this thinking the dialing of a number on a VoIP-phone
> goes through the following conceptual stages:
>
> 1) User enters a (potentially partial) number on his phone.
>    The phone appends its default domain and sends the invite to its proxy:
>    e.g.       sip:[email-masked]
>
> 2) The SIP proxy applies the local dialplan to translate the
>    SIP address to an E.164 number:
>
>    e.g. customer is in vienna, thus 5056416 maps to +43 1 5056416
>    -> We now have a URN: tel:+4315056416
>
> 3) The SIP proxy now tries to route the call. In this example,
>    user ENUM finds:
>    "E2U+sip" "!^.*$!sip:[email-masked]!"
>
>    or it could map to the local PSTN gateway with an URI like
>    sip:[email-masked]
>
> /ol

--
Jonathan D. Rosenberg, Ph.D.                   600 Lanidex Plaza
Director, Service Provider VoIP Architecture   Parsippany, NJ 07054-2711
Cisco Systems
[email-masked]                              FAX:   (973) 952-5050
http://www.jdrosen.net                         PHONE: (973) 952-5000
http://www.cisco.com

_______________________________________________
Geopriv mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/geopriv

_______________________________________________
enum mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/enum

---

From: Jonathan Rosenberg <[email-masked]>
Date: Thu, 18 Aug 2005 15:57:42 -0400

> a BCP coming out for voipeer:

Well, I think a BCP is needed, yes. But as I have said, it is a general 
SIP problem and not specific to the peering problem.

> a context can be submitted)

I must say I don't understand the value of the phone context in the dial 
string. To me, its completely redundant with the domain in the URI. 
Furthermore, I don't know how an endpoint would set the context, since 
the whole problem in the first place is that the endpoint doesn't know 
how to interpret these digits.

> sip:[email-masked];user=dialstring;phone-context=companyA.com

I'd personally prefer just sip:<dial string>@provider.com.

> either with a tel:+4319793321

Yes.

> The preferred way should be recommended

NO.

How can the client KNOW that this number is owned by the domain on the 
RHS of the @? Firstly, that right hand side is "userA.provider.com", 
which seems to be some kind of user specific thing. That makes no sense 
to me; even if the endpoint could determine who owns the number, it 
wouldn't be "userA.provider.com".

> sip:tel:+1973952500 @gateway.provider.com;user=phone

If the provider can translate the name to a SIP address, the request URI 
would be sip:<number>@provider.com;user=phone and that would be in the 
request URI.

> in RFC3966 defining the tel: URI

Things like 411 are easily handled in this model; there is a dialstring, 
which is what the user enters:

sip:[email-masked];user=dialstring

and this is translated into a URN based on the dial plan:

urn:directory-services

which is then translated to a SIP address if the directory service is 
reachable via a SIP address, else goes to a PSTN gateway as above.

-Jonathan R.