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:hgs cs.columbia.edu]
Sent: Wednesday, March 08, 2006 10:42 PM
To: Paul Kyzivat
Cc: Yu, James; iptelietf.org; 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:
>
>
> 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
_______________________________________________
Iptel mailing list
Iptelietf.org
https://
www1.ietf.org/mailman/listinfo/iptel
|