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 bond is that I could
dial a
bond 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:pkyzivat cisco.com]
Sent: Wednesday, March 08, 2006 10:28 PM
To: Yu, James
Cc: Stastny Richard; brbrianrosen.net; iptelietf.org
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
>
> -----Original Message-----
> From: Stastny Richard [mailto:Richard.Stastnyoefeg.at]
> Sent: Wednesday, March 08, 2006 4:33 PM
> To: Paul Kyzivat; brbrianrosen.net
> Cc: iptelietf.org
> Subject: Re: [Iptel] Re: I-D
ACTION:draft-rosen-iptel-dialstring-03.txt
> add-on
>
> 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=atl.example.comsippbx.example.com;user=dialstring
>
> cheers
>
> Richard
>
>
> ________________________________
>
> Von: Paul Kyzivat [mailto:pkyzivatcisco.com]
> Gesendet: Mi 08.03.2006 21:44
> An: brbrianrosen.net
> Cc: iptelietf.org; 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:pkyzivatcisco.com]
>>Sent: Wednesday, March 08, 2006 11:26 AM
>>To: iptelietf.org
>>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=altlanta.example.comsippbx.example.com;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
>
>>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:123sippbx.example.com;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: Internet-Draftsietf.org
[mailto:Internet-Draftsietf.org]
>>>Gesendet: Di 07.03.2006 21:50
>>>An: i-d-announceietf.org
>>>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-r
osen-iptel-dialstring-03.t
x
>
> t
>
>>>To remove yourself from the I-D Announcement
list, send a message to
>>>i-d-announce-requestietf.org with the word
unsubscribe in the body
of
>
> the
>
>>message.
>>
>>
>>>You can also visit
h
ttps://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/s
hadow.html
>>>or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>>>
>>>
>>>Internet-Drafts can also be obtained by e-mail.
>>>
>>>Send a message to:
>>> mailservietf.org.
>>>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
>>>I-D-Announceietf.org
>>>h
ttps://www1.ietf.org/mailman/listinfo/i-d-announce
>>>
>>>
>>>------------------------------------------------
---------------------
-
>
> --
>
>>>_______________________________________________
>>>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
|