draft-rosen-iptel-dialstring-05

>Hopefully, this resolves all issues, and the draft is
ready for the IESG to
>progress
 
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:brbrianrosen.net]
Gesendet: Fr 20.10.2006 23:23
An: iptelietf.org
Betreff: [Iptel] draft-rosen-iptel-dialstring-05



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-d
rafts/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
Iptelietf.org
https://
www1.ietf.org/mailman/listinfo/iptel



_______________________________________________
Iptel mailing list
Iptelietf.org
https://
www1.ietf.org/mailman/listinfo/iptel

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:
>> Hopefully, this resolves all issues, and the draft
is ready for the IESG to
>> progress
>  
> 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:brbrianrosen.net]
> Gesendet: Fr 20.10.2006 23:23
> An: iptelietf.org
> Betreff: [Iptel] draft-rosen-iptel-dialstring-05
> 
> 
> 
> 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-d
rafts/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
> Iptelietf.org
> https://
www1.ietf.org/mailman/listinfo/iptel
> 
> 
> 
> _______________________________________________
> Iptel mailing list
> Iptelietf.org
> https://
www1.ietf.org/mailman/listinfo/iptel
> 


_______________________________________________
Iptel mailing list
Iptelietf.org
https://
www1.ietf.org/mailman/listinfo/iptel

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

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:+xxxhomenetwork.com;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

> 
> Stastny Richard wrote:
> >> Hopefully, this resolves all issues, and the
draft is ready for the
> IESG to
> >> progress
> >
> > 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:brbrianrosen.net]
> > Gesendet: Fr 20.10.2006 23:23
> > An: iptelietf.org
> > Betreff: [Iptel] draft-rosen-iptel-dialstring-05
> >
> >
> >
> > 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
> > Iptelietf.org
> > https://
www1.ietf.org/mailman/listinfo/iptel
> >
> >
> >
> > _______________________________________________
> > Iptel mailing list
> > Iptelietf.org
> > https://
www1.ietf.org/mailman/listinfo/iptel
> >


_______________________________________________
Iptel mailing list
Iptelietf.org
https://
www1.ietf.org/mailman/listinfo/iptel

Stastny Richard wrote:

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

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:bobsp2.com
	To: sip:bobsp2.com
	From: sip:alicesp1.com
	Refer-To: sip:1234;phone-context=atlanta.sp1.comsp1.com
	   ;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

_______________________________________________
Iptel mailing list
Iptelietf.org
https://
www1.ietf.org/mailman/listinfo/iptel

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


_______________________________________________
Iptel mailing list
Iptelietf.org
https://
www1.ietf.org/mailman/listinfo/iptel

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

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.

_______________________________________________
Iptel mailing list
Iptelietf.org
https://
www1.ietf.org/mailman/listinfo/iptel

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:+14085551212example.com;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:+14055551212example.com;user=phone to
sip:+14085551212example.net;
       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: iptelietf.org
> 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:
> >> Hopefully, this resolves all issues, and the
draft is 
> ready for the 
> >> IESG to progress
> >  
> > 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:brbrianrosen.net]
> > Gesendet: Fr 20.10.2006 23:23
> > An: iptelietf.org
> > Betreff: [Iptel] draft-rosen-iptel-dialstring-05
> > 
> > 
> > 
> > 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
> > Iptelietf.org
> > https://
www1.ietf.org/mailman/listinfo/iptel
> > 
> > 
> > 
> > _______________________________________________
> > Iptel mailing list
> > Iptelietf.org
> > https://
www1.ietf.org/mailman/listinfo/iptel
> > 
> 
> 
> _______________________________________________
> Iptel mailing list
> Iptelietf.org
> https://
www1.ietf.org/mailman/listinfo/iptel
> 

_______________________________________________
Iptel mailing list
Iptelietf.org
https://
www1.ietf.org/mailman/listinfo/iptel