Subject: Re: [Iptel] Re: I-D ACTION:draft-rosen-iptel-dialstring-03.txt add-on

From: "Stastny Richard" <[email-masked]>
Date: Wed, 8 Mar 2006 22:32:31 +0100

Brian, Paul,
 
My first answer was too fast (and incomplete)
 
a dialstring is NOT a tel URI, it is something different
so draft-rosen-iptel-dialstring should not reference RFC 3966
it should define separately how to include a dialstring into a sip, sips URI

with the sip parameter user=dialstring similar user=phone defines
how to include a tel URI in a sip URI
and it needs to define the whole syntax in the way Paul proposed
 
of course it should copy the syntax of RFC 3966 as far as possible,
including the phone-context
 
sip:123;phone-context=[email-masked];user=dialstring
 
cheers

Richard

________________________________

Von: Paul Kyzivat [mailto:[email-masked]]
Gesendet: Mi 08.03.2006 21:44
An: [email-masked]
Cc: [email-masked]; Stastny Richard
Betreff: Re: [Iptel] Re: I-D ACTION:draft-rosen-iptel-dialstring-03.txt

Brian Rosen wrote:
> I think what you propose for the phone number parameters are too ugly, and
> unnecessary.  What I did with the current language is define a new parameter
> as defined in 3966.  This makes the user parameter and the phone-context
> parameter the same type of parameter.  The user= doesn't go before the "@",
> and neither should the phone-context.

It was my feeling that this is pretty similar to user=phone, so I was
expecting the representation to be similar as well. I find it pretty
surprising to reuse the phone-context parameter but in an entirely
different namespace. Even more so if the values for the parameter have a
differing meaning. (If that is to be done it might be better to change
the name.)

Are you proposing that a phone-context *URI parameter* be valid for
user=phone as well?

I would prefer this to deviate as little as possible from the sip form
of the tel uri.

> I do think fixing 3261's ABNF is a good idea.  Having a formal ABNF in this
> draft for the dialstring is a good idea.
>
> I can add the escaped * and #. 

Only # *needs* to be escaped if it is used.

        Paul

> And Richard, of course you are correct; sloppy editing on my part, and I'll
> fix the examples.
>
> Brian
> -----Original Message-----
> From: Paul Kyzivat [mailto:[email-masked]]
> Sent: Wednesday, March 08, 2006 11:26 AM
> To: [email-masked]
> Cc: Stastny Richard
> Subject: Re: [Iptel] Re: I-D ACTION:draft-rosen-iptel-dialstring-03.txt
>
> I agree with Richard that I support the concept of this draft, but have
> a few nits. I have a different spin on the one Richard pointed out:
>
> All the parameters defined in 3966 are part of the phone number. When
> the definitions in 3966 are applied to sip with the user=phone uri
> parameter, the parameters defined in 3966 all go before the "@" sign.
> The user=dialstring is just a variant on this, so I expect the
> phone-context parameter ought to go before the "@" sign in that case
> too. For example:
>
> ; what a SIP Phone might emit when a user dials extension 123
> sip:123;phone-context=[email-masked];user=dialstrin
> g
>
> Next, this draft permits the dialled digits A-F, but it doesn't permit *
> and #. 3966 does permit * and # as well as E and F - apparently they are
> synonymous. (When used in conjunction with sip uris, the # has to be
> escaped as %23.)
>
> We are slightly in limbo here, because 3261 references 2805 rather than
> 3966. Need to deal with that somehow. I think it would be helpful to
> introduce in this draft a formal syntax for the user part. The following
> is a suggested start at a syntax. This could just be for
> user=dialstring, but this might be a convenient place to revise 3261 so
> it references 3966 for user=phone as well. The following is a start at
> the changes. I've included some stuff from 3261 and 3966 for reference
> that probably don't need to be included in the draft.
>
> ;;; UNCHANGED RULES FROM 3261:
> ;SIP-URI          =  "sip:" [ userinfo ] hostport
> ;                    uri-parameters [ headers ]
> ;SIPS-URI         =  "sips:" [ userinfo ] hostport
> ;                    uri-parameters [ headers ]
> ;user             =  1*( unreserved / escaped / user-unreserved )
> ;user-unreserved  =  "&" / "=" / "+" / "$" / "," / ";" / "?" / "/"
> ;
> ;uri-parameters    =  *( ";" uri-parameter)
> ;
> ;uri-parameter     =  transport-param / user-param / method-param
> ;                     / ttl-param / maddr-param / lr-param
>
> ;                     / other-param
>
> ;;; UNCHANGED RULES FROM 3966
> ;   local-number         = local-number-digits *par context *par
> ;   local-number-digits  =
> ;      *phonedigit-hex (HEXDIG / "*" / "#")*phonedigit-hex
> ;   phonedigit-hex       = HEXDIG / "*" / "#" / [ visual-separator ]
> ;   visual-separator     = "-" / "." / "(" / ")"
>
>
> ;;; REVISED RULES FROM 3261
> userinfo         =  ( user / telephone-subscriber / dial-string )
>                      [ ":" password ] "@"
> user-param        =  "user="
>                          ( "phone" / "ip" / "dialstring" / other-user)
>
>     The BNF for 'telephone-subscriber', 'par', and 'context' can be
>     found in RFC 3966 [?].  Note, however, that any characters allowed
>     there that are not allowed in the 'user' part of the SIP URI MUST
>     be escaped.
>
>
>
> ;;; NEW RULES
> dial-string = dial-string-number *par context *par
> dial-string-number = 1* ( [ "X" ] 1*dial-string-segment )
> dial-string-segment = ( * "P" ) dial-string-digit
> dial-string-digit = HEXDIG / "*" / "#"
>
>
> This needs to be accompanied by text explaining that the dial-string
> syntax applies when the user=dialstring parameter is present.
>
>       Thanks,
>       Paul
>
> Stastny Richard wrote:
>
>>Brian,
>>
>>in principle I support and welcome this draft
>>
>>A minor comment to the phone-context examples:
>>
>>"When the "user=dialstring" is used, a context parameter as defined in
>>   [RFC3966] MUST be specified."
>>
>>Ok
>>
>>but in your examples you use
>>(Examples of dialstring use include)
>>   ; what a SIP Phone might emit when a user dials extension 123
>>   sip:[email-masked];user=dialstring;
>>      phone-context='AtlantaDialPlan'
>>
>>but phone-context is defined in RFC3966 as:
>>context = ";phone-context=" descriptor
>>descriptor = domainname / global-number-digits
>>
>>this is because the phone-context must globally unique
>>
>>so you should use in your examples either
>>
>>phone-context=altlanta.example.com
>>
>>or
>>
>>phone-context=+1234
>>
>>(without "")
>>
>>regards
>>
>>Richard
>>
>>
>>________________________________
>>
>>Von: [email-masked] [mailto:[email-masked]]
>>Gesendet: Di 07.03.2006 21:50
>>An: [email-masked]
>>Betreff: I-D ACTION:draft-rosen-iptel-dialstring-03.txt
>>
>>
>>
>>A New Internet-Draft is available from the on-line Internet-Drafts
>
> directories.
>
>>
>>        Title           : Dialstring parameter for the Session Initiation
>
> Protocol URI
>
>>        Author(s)       : B. Rosen
>>        Filename        : draft-rosen-iptel-dialstring-03.txt
>>        Pages           : 8
>>        Date            : 2006-3-7
>>      
>>RFC3966 explicitly states that TEL URIs may not represent a dial
>>string.  That leaves no way specify a dialstring in a standardized
>>way.  Great confusion exists with the SIP URI parameter "user=phone",
>>and specifically, if it can represent a dial string.  This memo
>>creates a new value for the user parameter "dialstring", so that one
>>may specify "user=dialstring" to encode a dialstring as a SIP or SIPS
>>URI.
>>
>>A URL for this Internet-Draft is:
>>http://www.ietf.org/internet-drafts/draft-rosen-iptel-dialstring-03.txt
>>
>>To remove yourself from the I-D Announcement list, send a message to
>>[email-masked] with the word unsubscribe in the body of the
>
> message.
>
>>You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce
>>to change your subscription settings.
>>
>>
>>Internet-Drafts are also available by anonymous FTP. Login with the
>
> username
>
>>"anonymous" and a password of your e-mail address. After logging in,
>>type "cd internet-drafts" and then
>>        "get draft-rosen-iptel-dialstring-03.txt".
>>
>>A list of Internet-Drafts directories can be found in
>>http://www.ietf.org/shadow.html
>>or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>>
>>
>>Internet-Drafts can also be obtained by e-mail.
>>
>>Send a message to:
>>        [email-masked].
>>In the body type:
>>        "FILE /internet-drafts/draft-rosen-iptel-dialstring-03.txt".
>>      
>>NOTE:   The mail server at ietf.org can return the document in
>>        MIME-encoded form by using the "mpack" utility.  To use this
>>        feature, insert the command "ENCODING mime" before the "FILE"
>>        command.  To decode the response(s), you will need "munpack" or
>>        a MIME-compliant mail reader.  Different MIME-compliant mail
>
> readers
>
>>        exhibit different behavior, especially when dealing with
>>        "multipart" MIME messages (i.e. documents which have been split
>>        up into multiple messages), so check your local documentation on
>>        how to manipulate these messages.
>>              
>>              
>>Below is the data which will enable a MIME compliant mail reader
>>implementation to automatically retrieve the ASCII version of the
>>Internet-Draft.
>>
>>
>>
>>
>>------------------------------------------------------------------------
>>
>>_______________________________________________
>>I-D-Announce mailing list
>>[email-masked]
>>https://www1.ietf.org/mailman/listinfo/i-d-announce
>>
>>
>>------------------------------------------------------------------------
>>
>>_______________________________________________
>>Iptel mailing list
>>[email-masked]
>>https://www1.ietf.org/mailman/listinfo/iptel
>
>
> _______________________________________________
> Iptel mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/iptel
>

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

---

From: "Yu, James" <[email-masked]>
Date: Wed, 8 Mar 2006 22:57:49 -0500

I probably should have used "dialing prefix" instead of "dialing plan"
to avoid the confusion.

One way to avoid the problem is for the IMS providers to inform their
IMS users to always dial "+TN".   But that would not be "user-friendly".

I'm based in US and my experience in London is that I could dial a
London number with a prefix of "0" to reach that number.   I can
certainly use +TN format but that requires dialing a few more digits.
Since the roaming mobile network process the call, it could figure out
that my dialed string/number contains a dialing prefix of "0".

What I'm trying to indicate is that many mobile users are familiar with
the dialing prefixes of the countries they frequently roam into.   So
the IMS providers may want to allow their IMS users to do things they
are used to do (e.g., dial numbers with dialing prefixes in the roaming
countries).

I don't know if the IMS application/handset is smart enough to know the
country where the IMS user is roaming and knows all the dialing prefixes
in that country to be able to convert a dialed string containing the
dialing prefix to a phone number or adding a country code to a dialed
national number without a dialing prefix.   If it is not done by the IMS
application/handset, the dialed string must be passed to the home IMS
provider in a tel URI instead of sip URI.

The tel URI currently does not have a way to pass the "dial string"
indication and I think this I-D probably is one to address it.  Although
this I-D addresses the sip URI aspect, I'm throwing in a scenario to
show that tel URI probably is a better place to pass that indication.
How that indication is carried in the tel URI is to be addressed by this
I-D.  Phone-Context certainly is a candidate place to carry that
indication (e.g., need to add "dialstring" as a new option).

James

-----Original Message-----
From: Paul Kyzivat [mailto:[email-masked]] 
Sent: Wednesday, March 08, 2006 10:28 PM
To: Yu, James
Cc: Stastny Richard; [email-masked]; [email-masked]
Subject: Re: [Iptel] Re: I-D ACTION:draft-rosen-iptel-dialstring-03.txt
add-on

Yu, James wrote:
> I'd like to discuss the scenario involving IP Multimedia Subsystem
> (IMS).
> 
> When an IMS user originates a call to an international number (e.g.,
> +1-703-622-1234), the IMS application/device uses a tel URI
> (tel:+1-703-622-1234) in the R-URI of the SIP INVITE.
> 
> If the user dials a local/national number with or without the local
> dialing plan,

I don't know how to parse the above. AFAIK it is normally impossible to 
"dial" a dialing plan. Presumably the dialing plan must be implicit. 
Thew question is only what entity is responsible for making the dial 
plan explicit by including it in the uri. As long as the URI formats 
require that local numbers and dialstrings contain a context, it is 
necessary for the UA to insert the context. IMO that is just fine - the 
UA *ought* to know the context.

> what would the IMS application/device put in the R-URI?

The obvious thing is to put the e.164 number corresponding to the dial 
string. If you know the context it is no big deal to turn the number 
into an e.164 number too.

The time I have found when that isn't the solution is when the dial 
string conveys extra information that needs to be processed in the 
network - such as a star-code, or a leading zero to request operator 
services. While there are many ways to handle those things, passing the 
dialstring seems to be a useful way.

> I'd guess that it would be a tel URI but with the "dial-string"
> indication. 

Well, you are the author of the tel uri, so I'm not going to try to tell

you anything about it. I didn't know it had a way to carry a dial 
string, or a dial-string-indicator.

One of the reasons that user=dialstring was proposed (quite some time 
ago) was because tel couldn't do it.

>  So I think that we need to indicate "dial-string" in the
> tel URI.  If that is the case, we probably don't need anything in the
> sip URI.  "user=phone" in the sip URI would indicate that the user
part
> contains the tel URI information that may include the "dial-string"
> indication.

If that existed, it would be fine with me. But we have been going down 
this other path for some time.

> Roaming mobile users' outbound calls are handled by the visited
networks
> and they can easily determine if the callers/roamers dial
local/national
> numbers with or without dialing prefixes.  IMS creates a challenge
> because the outbound calls are analyzed and handled by the roamers'
home
> IMS providers.  So even if the dialed string can be passed in a tel
URI
> to the home IMS provider, the home IMS provider would need to
understand
> the dialing prefixes of the countries where the IMS users are
currently
> roaming to convert the dialed string to a global/local phone number.

You think it is desirable that a roaming user dial using the dialling 
conventions of the location he has roamed to, rather than his home 
location? (I consider that to be grossly user-unfriendly.)

	Paul

> But this is an issue for the IMS to solve.
> 
> James
> 
> From: Stastny Richard [mailto:[email-masked]] 
> Sent: Wednesday, March 08, 2006 4:33 PM
> To: Paul Kyzivat; [email-masked]
> Cc: [email-masked]
> Subject: Re: [Iptel] Re: I-D
ACTION:draft-rosen-iptel-dialstring-03.txt
> add-on
> it should define separately how to include a dialstring into a sip,
sips
> URI
> Betreff: Re: [Iptel] Re: I-D
ACTION:draft-rosen-iptel-dialstring-03.txt
> 
> 
> 
> 
> 
> Brian Rosen wrote:
> 
>>I think what you propose for the phone number parameters are too ugly,
> 
> and
> 
>>unnecessary.  What I did with the current language is define a new
> 
> parameter
> 
>>as defined in 3966.  This makes the user parameter and the
> 
> phone-context
> 
>>parameter the same type of parameter.  The user= doesn't go before the
> 
> "@",
> 
>>I do think fixing 3261's ABNF is a good idea.  Having a formal ABNF in
> 
> this
> 
>>And Richard, of course you are correct; sloppy editing on my part, and
> 
> I'll
> 
>>fix the examples.
>>
>>Brian
>>Subject: Re: [Iptel] Re: I-D
> 
> ACTION:draft-rosen-iptel-dialstring-03.txt
> 
>>I agree with Richard that I support the concept of this draft, but
> 
> have
> 
sip:123;phone-context=[email-masked];user=dials
> trin
> 
>>g
>>
>>Next, this draft permits the dialled digits A-F, but it doesn't permit
> 
> *
> 
>>and #. 3966 does permit * and # as well as E and F - apparently they
> 
> are
> 
>>We are slightly in limbo here, because 3261 references 2805 rather
> 
> than
> 
>>introduce in this draft a formal syntax for the user part. The
> 
> following
> 
>>user=dialstring, but this might be a convenient place to revise 3261
> 
> so
> 
>>>       Title           : Dialstring parameter for the Session
> 
> Initiation
> 
>>Protocol URI
>>
>>
>>>       Author(s)       : B. Rosen
>>>http://www.ietf.org/internet-drafts/draft-rosen-iptel-dialstring-03.t
x
> t
>>>[email-masked] with the word unsubscribe in the body
of
> the
>>>You can also visit
https://www1.ietf.org/mailman/listinfo/I-D-announce
>>>       command.  To decode the response(s), you will need "munpack"
> 
> or
> 
>>>       "multipart" MIME messages (i.e. documents which have been
> 
> split
> 
>>>       up into multiple messages), so check your local documentation
> 
> on
> 
>>>---------------------------------------------------------------------
-
> --
>>>---------------------------------------------------------------------
-
> --

---

From: "Yu, James" <[email-masked]>
Date: Wed, 8 Mar 2006 23:25:21 -0500

I sent a response to Paul before seeing this message.  I did not know
about the past discussions on this.

IMS is complicate because it may involve "roaming" (not "fixed") and
require the home IMS provider to process the dialed digits/number.   I
do see a need to pass the dialed string (any number that does not have a
leading "+") to the home IMS provider because it may not be
feasible/desirable for the IMS application/handset to convert the dialed
string to a phone number.   It is fine with me if tel URI is not a good
place to carry it.   

If the IMS application/handset needs to use sip URI to pass the dialed
string to the home IMS provider, it needs to put the home S-CSCF's
domain name or a generic IMS provider domain name in the host part of
the sip URI.   This puts a requirement on the home S-CSCF to verify if
the sip URI carries a "dialstring" indication so that it will convert
the dialed string to a phone number and then terminate the call versus
in the case when the caller tries to set up a call to a sip URI
belonging to another IMS user served by the same IMS provider.

James
-----Original Message-----
From: Henning Schulzrinne [mailto:[email-masked]] 
Sent: Wednesday, March 08, 2006 10:42 PM
To: Paul Kyzivat
Cc: Yu, James; [email-masked]; Stastny Richard
Subject: Re: [Iptel] Re: I-D ACTION:draft-rosen-iptel-dialstring-03.txt
add-on

Jumping in probably without having digested the whole message trail:

RFC 3966 (tel) is specifically *not* suited for dial strings; this  
was discussed repeatedly during the development of the draft. It  
says, for example, that dial strings are not directly represented  
(page 13). Or

A SIP UA can use a dial plan to translate dial strings into SIP or
    "tel" URIs.  The dial plan can be manually configured or,  
preferably,
    downloaded as part of a device configuration mechanism.  (At this
    time, there is no standardized mechanism for this.)

The phone-context parameter was meant to represent local numbers that  
don't have a real E.164 identifier representation, but they are not  
dial strings. RFC 3966 also puts a SHOULD NOT warning on the use of  
local numbers. The RFC also points out other differences, such as the  
inclusion of post-dial digits for controlling IVRs, which would be  
wholly inappropriate in an identifier, i.e., a tel URI.

Needless to say, the dial strings in the draft-rosen draft also have  
things like pause and break, which can't be represented in RFC 3966.

I hope we don't have to re-visit this whole discussion from about  
three years ago.

Henning
(author of RFC 3966)

On Mar 8, 2006, at 10:27 PM, Paul Kyzivat wrote:

> I don't know how to parse the above. AFAIK it is normally  
> impossible to "dial" a dialing plan. Presumably the dialing plan  
> must be implicit. Thew question is only what entity is responsible  
> for making the dial plan explicit by including it in the uri. As  
> long as the URI formats require that local numbers and dialstrings  
> contain a context, it is necessary for the UA to insert the  
> context. IMO that is just fine - the UA *ought* to know the context.
>
> The obvious thing is to put the e.164 number corresponding to the  
> dial string. If you know the context it is no big deal to turn the  
> number into an e.164 number too.
>
> network - such as a star-code, or a leading zero to request  
> operator services. While there are many ways to handle those  
> things, passing the dialstring seems to be a useful way.
>
> Well, you are the author of the tel uri, so I'm not going to try to  
> tell you anything about it. I didn't know it had a way to carry a  
> dial string, or a dial-string-indicator.
>
> One of the reasons that user=dialstring was proposed (quite some  
> time ago) was because tel couldn't do it.
>
> If that existed, it would be fine with me. But we have been going  
> down this other path for some time.
>
>> and they can easily determine if the callers/roamers dial local/ 
>> national
>> because the outbound calls are analyzed and handled by the  
>> roamers' home
>> IMS providers.  So even if the dialed string can be passed in a  
>> tel URI
> You think it is desirable that a roaming user dial using the  
> dialling conventions of the location he has roamed to, rather than  
> his home location? (I consider that to be grossly user-unfriendly.)
>
> 	Paul
>