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

[Jonathan Rosenberg <jdrosen at cisco.com>]

Stastny Richard wrote:

> Jonathan,
>  
> I think you made a very important point here for
> 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.

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

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.

> 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

I'd personally prefer just sip:<dial string>@provider.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

Yes.

> or with sip:+439793321 at userA.provider.com
> 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".

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

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.

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

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

sip:411 at provider.net;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.
--
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

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