RE: [Enum] Re: [voipeer] Re: [Geopriv] Re: [Simple]telURIsin commonpolicy

["Dolly, Martin C, ALABS" <mdolly at att.com>]

Title: RE: [Enum] Re: [voipeer] Re: [Geopriv] Re: [Simple]telURIsin commonpolicy

The only time I believe where the destination number may need to be restricted is when there is a forwarding/redirection/refer... and the OCN is no longer the destination number. In this case the destination number may be restricted to the calling party.

-----Original Message-----
From: geopriv-bounces at ietf.org [mailto:geopriv-bounces at ietf.org]On Behalf Of Michael Hammer (mhammer)
Sent: Friday, August 19, 2005 11:05 AM
To: Stastny Richard; Jonathan Rosenberg (jdrosen); Brian Rosen
Cc: geopriv at ietf.org; voipeer at lists.uoregon.edu; Otmar Lendl; enum at ietf.org
Subject: RE: [Enum] Re: [voipeer] Re: [Geopriv] Re: [Simple]telURIsin commonpolicy

I don't get the privacy bit. The user dials a number, that is somehow
interpreted as an E.164 number, then it gets omitted from the SIP
address to hide from whom? It is called party, no?

Mike


> -----Original Message-----
> From: enum-bounces at ietf.org [mailto:enum-bounces at ietf.org] On
> Behalf Of Stastny Richard
> Sent: Thursday, August 18, 2005 3:38 PM
> To: Jonathan Rosenberg (jdrosen); Brian Rosen
> Cc: geopriv at ietf.org; voipeer at lists.uoregon.edu; Otmar Lendl;
> enum at ietf.org
> Subject: Re: [Enum] Re: [voipeer] Re: [Geopriv] Re: [Simple]
> telURIsin commonpolicy
>
> Just one add-on before I am getting ahead of myself:
> regarding:
> >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 ...
>
> in this case the ENUM entry will in most cases be
> sip:+439793321 at userA.provider.com;user=phone
> or even
> sip:\1 at userA.provider.com;user=phone
>
> because of privacy reasons
>
> -richard
>
> ________________________________
>
> Von: owner-voipeer at lists.uoregon.edu im Auftrag von Stastny Richard
> Gesendet: Do 18.08.2005 21:05
> An: Jonathan Rosenberg; Brian Rosen
> Cc: geopriv at ietf.org; voipeer at lists.uoregon.edu; Otmar Lendl;
> enum at ietf.org
> Betreff: Re: [Enum] Re: [voipeer] Re: [Geopriv] Re: [Simple]
> tel URIsin commonpolicy
>
>
>
> 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:0114319793321 at userA.provider.com;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:9793321 at userA.provider.com;user=dialstring;phone-context=+431
> or
> sip:4321 at sip.companyA.com;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:+439793321 at userA.provider.com 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: geopriv-bounces at ietf.org im Auftrag von Jonathan Rosenberg
> Gesendet: Do 18.08.2005 17:12
> An: Brian Rosen
> Cc: geopriv at ietf.org; voipeer at lists.uoregon.edu; 'Otmar
> Lendl'; enum at ietf.org
> 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:number at provider.com;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:5056416 at my-voip-provider.at can only be
> > interpreted by the my-voip-provider.at domain, so your flow
> definitely can work.
> >
> > Brian
> >
> > -----Original Message-----
> > From: enum-bounces at ietf.org [mailto:enum-bounces at ietf.org]
> On Behalf
> > Of Otmar Lendl
> > Sent: Thursday, August 18, 2005 6:33 AM
> > To: voipeer at lists.uoregon.edu; geopriv at ietf.org; enum at ietf.org
> > Subject: [Enum] Re: [voipeer] Re: [Geopriv] Re: [Simple]
> tel URIs in
> > commonpolicy
> >
> > On 2005/08/18 05:08, Jonathan Rosenberg <jdrosen at cisco.com> 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:+19739525000@provider.net">19739525000@provider.net;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:5056416 at my-voip-provider.at
> >
> > 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:office at enum.at!"
> >
> > or it could map to the local PSTN gateway with an URI like
> > sip:+4315056416@AS5300.my-voip-provider.at">4315056416@AS5300.my-voip-provider.at
> >
> > /ol
>
> --
> Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza
> Director, Service Provider VoIP Architecture Parsippany, NJ
> 07054-2711
> Cisco Systems
> jdrosen at cisco.com FAX: (973) 952-5050
> http://www.jdrosen.net PHONE: (973) 952-5000
> http://www.cisco.com
>
> _______________________________________________
> Geopriv mailing list
> Geopriv at ietf.org
> https://www1.ietf.org/mailman/listinfo/geopriv
>
>
>
> ______________________________________________________________
> _______________
> List Archive: http://darkwing.uoregon.edu/~llynch/voipeer/
> User Tools: http://darkwing.uoregon.edu/~llynch/voipeer.html
>
>
>
> _______________________________________________
> enum mailing list
> enum at ietf.org
> https://www1.ietf.org/mailman/listinfo/enum
>

_______________________________________________
Geopriv mailing list
Geopriv at ietf.org
https://www1.ietf.org/mailman/listinfo/geopriv

_______________________________________________
enum mailing list
enum at ietf.org
https://www1.ietf.org/mailman/listinfo/enum