Subject: [Iptel] draft-rosen-iptel-dialstring-05

From: "Brian Rosen" <[email-masked]>
Date: Fri, 20 Oct 2006 17:23:48 -0400

I have submitted an update to -dialstring.  Until it appears in the
archives, you may pick up a copy from:
http://www.brianrosen.net/internet-drafts/draft-rosen-iptel-dialstring-05.tx
t

an .html is also available.

The changes in this version are:
1. After lengthy discussion, I changed the position of the phone-context
parameter to match what a tel uri with a phone-context parameter looks like
when converted to a sip URI.  This means it goes before the '@'
2. I created an ABNF description of this, defining a new "dialstring"
alternative for 'user-info' in a sip URI.
3. I expanded the definition of the dialstring syntax to include "*" and "#"
(as well as E and F)
4. I added a SHOULD NOT use a dialstring as an AoR in a Register

Hopefully, this resolves all issues, and the draft is ready for the IESG to
progress

Brian

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

---

From: "Stastny Richard" <[email-masked]>
Date: Sat, 21 Oct 2006 16:38:53 +0200

>Hopefully, this resolves all issues, and the draft is ready for the IESG to
 
I hope too ;-)
Congratulations
 
There is only one additional item left:
 
 A proxy server or Back to Back User Agent (B2BUA) [RFC3261] which is
   authoritative for the context may translate the dial string to a
   telephone number or service invocation URI.  If such a translation is
   performed, the proxy server MUST change the URI parameter value from
   "user=dialstring" to "user=phone".  This translation MUST occur prior
   to the call leaving the domain of the context.
 
Considering the explanation of user=phone in
draft-rosenberg-rai-phones-names-numbers-00:
 
"RFC 3261 is clear that user=phone is used when the user part is
   formatted as a phone number.  However, this document argues that when
   used in a SIP URI there is an additional, deeper meaning.  The domain
   part of the SIP URI serves two important purposes.  First, it
   specifies the host to which the request should be delivered.
   However, this is secondary to its more important meaning - it is an
   identifier for the owner of the namespace from which the user part is
   selected.  Consequently, when the user part is a global phone number,
   it is asserting ownership of that global phone number by that domain.
   Thus, the SIP URI form with user=phone MUST only be used when the
   entity constructing the URI has knowledge from an authoritative
   source that the domain in the URI is the owner of the phone number in
   the left hand side.  Such knowledge comes from databases such as ENUM
   or PSTN-based local number portability tables, in additional to
   localized knowledge within the domain that knows definitively that it
   owns the number."
 
Ok, so we have to refomulate the para, e.g.
 
 A proxy server or Back to Back User Agent (B2BUA) [RFC3261] which is
   authoritative for the context may translate the dial string to a
   telephone number or service invocation URI.  The telephone number
  MAY be expressed as a global or local tel: URI or as a sip: or sips: URI.  
  This translation MUST occur prior
   to the call leaving the domain of the context.
 
best regards
Richard

________________________________

Von: Brian Rosen [mailto:[email-masked]]
Gesendet: Fr 20.10.2006 23:23
An: [email-masked]
Betreff: [Iptel] draft-rosen-iptel-dialstring-05

Brian

---

From: "Tom-PT Taylor" <[email-masked]>
Date: Sun, 22 Oct 2006 20:14:19 -0400

That's if you accept Jonathan's argument. I'm not sure I do. As an 
example, consider a 3GPP end point shipping a call to the PSTN to its 
home network, because that it where it has to go to get service.

---

From: "Stastny Richard" <[email-masked]>
Date: Mon, 23 Oct 2006 10:17:01 +0200

Tom wrote: 
> That's if you accept Jonathan's argument. 

Yes, or at least IMO the various formats of sip URIs containing
phone numbers have to be clarified before this para can be finished

> I'm not sure I do. As an

Good point.
3GPP is using ENUM to resolve the translation from E.164 to sip URIs
There has to be a clear definition what kind of URIs you enter in the
different cases:

If the destination network is reachable via IP Interconnect, one
must enter a sip:[email-masked];user=phone and SPEERMINT is
resolving
the routing on IP

If the destination is only reachable via the PSTN, one must
enter a tel: URI (it may enter in addition eventually a sip URI
as above, but without user=phone?)

I do not see any other case

Regards
Richard

> >   MAY be expressed as a global or local tel: URI or as a sip: or
sips:
> URI.
http://www.brianrosen.net/internet-drafts/draft-rosen-iptel-dialstring-
> 05.tx
> > parameter to match what a tel uri with a phone-context parameter
looks
> like
> > 3. I expanded the definition of the dialstring syntax to include "*"
and
> "#"
> > Hopefully, this resolves all issues, and the draft is ready for the
IESG
> to

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 23 Oct 2006 09:25:08 -0400

>    to the call leaving the domain of the context.

I question the last MUST, though I agree with SHOULD here. There are no
rules regarding which domains understand a particular context. (The
context is just a name. Anybody *could* understand it.) Its always
possible that once leaving server that happens to understand the
context, it may eventually reach another domain that also understands
it. Of course this is risky - there is also a very good chance that it
will get to someplace that doesn't understand it, and that must give up
for lack of options.

A case I have in mind for this is a REFER request that contains a
Refer-To containing a user=dialstring URI. (This is probably a bad idea,
but its possible it could arise somehow.) For example:

	REFER sip:[email-masked]
	To: sip:[email-masked]
	From: sip:[email-masked]
	Refer-To: sip:1234;phone-context=[email-masked]
	   ;user=dialstring
	Route: sip:proxy.sp1.com

There are at least three potential times when this dial string could be 
translated:

- when the REFER is first being processed by proxy.sp1.com for
   the outgoing request from alice. It may well understand the context
   atlanta.sp1.com. But This requires it to look into all sorts of
   headers, not just the R-URI.

- when the resulting INVITE, sent by Bob, reaches a proxy in Bob's
   domain (proxy.sp2.com). At this time the dialstring will be in the
   R-URI. But at this time the domain of the R-URI does not match that
   of the proxy, so it shouldn't take place then.

- when the resulting INVITE reaches some proxy in the sp1.com domain,
   as a result of 3263 processing of the dialstring uri. This may be
   proxy.sp1.com again, or it might be some other proxy serving sp1.
   Ideally, sp1 will have set things up so that all its proxies know
   all its contexts, or else it could potentially have routing rules
   based on the context, that route the request to a proxy that does
   understand those rules and can translate the dialstring.

There are a variety of options here, some better, some worse. I don't 
think it is necessary to get overly normative about when this gets done.

	Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 23 Oct 2006 10:19:33 -0400

A couple of issues with the syntax:

      ;domainname, DIGITS from RFC3261
    dialstring = digits ';phone-context=' domainname
    digits = phone-digit *( phone-digit / visual-separator)
    phone-digit = DIGIT / "A" / "a" / "B" / "b" / "C" / "c" / "D" / "d" /
                          "E" / "e" / "F" / "f" / "P" / "p" / "X" / "x" /
                          "*" / "#"
    visual-separator = "-" / "." / "(" / ")"

1) ABNF is case insensitive regarding rule names, so
    you can't can't separately define "digits" and "DIGITS".

2) in ABNF, quoted strings are case insensitive, so "X" and "x"
    both match x and X. So listing both is unnecessary.

3) 3966 allows a number to begin with a visual separator. The only
    requirement it has is that there must be at least one meaningful
    digit it in. If dialstrings are going to permit visual separators
    then I think it makes sense to use the same rule.

4) 3966 allows the context to be either a domain name or
    "global-number-digits". If that is to be permitted for local numbers,
    I am inclined to think it also ought to be defined for dial strings
    as well, since I think there might be some relationship between the
    contexts for those things.

It also might be clearer to base the syntax on that already defined in 
3966. For example:

    dialstring = dialstring-digits context ; context from RFC3966
    dialstring-digits =
       *dialstring-element dialstring-digit *dialstring-element
    dialstring-digit = HEXDIG / "*" / "#" ; HEXDIG from RFC3966
    dialstring-element =  dialstring-digit  / "P" / "X" /
       visual-separator ; visual-separator from RFC3966

The above syntax assumes its not enough to have just a P or X in a 
dialstring. If that should be OK, then the syntax should be:

    dialstring = dialstring-digits context ; context from RFC3966
    dialstring-digits =
       *dialstring-element dialstring-digit *dialstring-element
    dialstring-digit = HEXDIG / "*" / "#"  / "P" / "X"
                        ; HEXDIG from RFC3966
    dialstring-element =  dialstring-digit / visual-separator
                        ; visual-separator from RFC3966

	Thanks,
	Paul

---

From: "Francois Audet" <[email-masked]>
Date: Wed, 25 Oct 2006 18:19:11 -0500

I agree with Tom. I don't believe I accept Jonathan's argument either.

Inside an Enteprise for example, it is common to route E.164 phone
numbers
using the domain of the Enterprise itself (e.g., example.com) instead of
the
domain of the Telco that "owns" the number (e.g., example.net).

For example, in my Enterprise, I can make a phone call +14085551212.
My phone is configured to use my domain for phone numbers, so INVITE
goes out to sip:[email-masked];user=phone.

My proxy (example.com) examines the phone numbers, and decides how to
route it.
There are 2 main cases:

1 - The phone number points to a destination known to the example.com
network.
    It can be routed there directly. Note that it could be a SIP phone,
a 
    gateway, etc.

2 - The phone number is not known in the example.com domain. My proxy
example.com
    must decide to route it otherwise. Possible alternatives includes:
    a) Do an ENUM query on the phone number to resolve it to another 
       address
    c) Route it to a SIP service provider example.net, retargetting 
       sip:[email-masked];user=phone to
sip:[email-masked];
       user=phone. Note that this is also recursive. It is possible 
       that example.net does NOT own this number and it may have to
resolve it
       again using the same mechanism as in step 2.
    b) Route it to a PSTN Gateway offering PSTN service

The domain part therefore does not have to own the phone number. It just
merely 
has to be able to route it.

> -----Original Message-----
> From: Taylor, Tom-PT (CAR:AR00) 
> Sent: Sunday, October 22, 2006 5:14 PM
> To: Stastny Richard
> Cc: [email-masked]
> Subject: Re: [Iptel] draft-rosen-iptel-dialstring-05
> 
> That's if you accept Jonathan's argument. I'm not sure I do. 
> As an example, consider a 3GPP end point shipping a call to 
> the PSTN to its home network, because that it where it has to 
> go to get service.
> 
> Stastny Richard wrote:
> >> IESG to progress
> > 1. After lengthy discussion, I changed the position of the 
> > phone-context parameter to match what a tel uri with a 
> phone-context 
> > parameter looks like when converted to a sip URI.  This 
> means it goes before the '@'
> > IESG to progress

---

From: "Francois Audet" <[email-masked]>
Date: Wed, 25 Oct 2006 18:20:56 -0500

> enter a tel: URI (it may enter in addition eventually a sip 
> URI as above, but without user=phone?)

This is not accurate. You can use sip if you want to, as long
as the domain in that URI has the means to route the phone number.

This is why the phone-context (explicit, or implicit when talking
about public numbers using the '+' sign) is important. It ensures 
that the phone number in the user part has a unique meaning regardless
of the domain.