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

From: "Stastny Richard" <[email-masked]>
Date: Thu, 9 Mar 2006 10:30:52 +0100

As Henning said, the tel URI defined in
RFC 3966 does not allow dialstrings Period

I fully agree with Henning NOT to re-open this discussion
(I still can remember ;-)

OTOH, as long as (stupid) terminals are out there capable
of only entering digits and forwarding these digits to the next
hop, we need the possibility to enter dialstrings
We also cannot assume that particularly the stupid
terminals in question will be able to translate
dialstrings to Tel URIs.

Most terminals are even so stupid that they are
not able to provide a tel URI, they normally
provide: sip:[email-masked];user=phone

(not even the user=phone is provided in some cases)

This was the reason why I proposed to include
the dialstring (as done anyway in the most cases)
in the sip URI, but to clarify the issue in the
following way:
-if user=phone is used as SIP parm, the digits
are a tel URI as defined in RFC 3966

-if user=dialstring is used, it is a dialstring
(with all funny characters allowed) as defined
in draft-rosen-iptel-dialstring.

Now to the phone-context (or dialplan-context?)
Since the dialplan used may be an agreement between
home network and the terminal (user profile), it is
always required (the homeproxy.com in the sip URI
alone is not sufficient, we need this in addition.

I am also considering here the problem from ECRIT
with visited and home emergency numbers. The context
could be used to provide information if home or visited
country emergency numbers are dialled.

This is also necessary for IMS:

In IMS the P-CSCF is NEVER analyzing the request URI, 
it is always the home S-CSCF.

Question: how does the home S-CSCF of the caller
learn the local emergency numbers?

regards
Richard

> -----Original Message-----
> From: Yu, James [mailto:[email-masked]]
> Sent: Thursday, March 09, 2006 5:25 AM
> To: Henning Schulzrinne; Paul Kyzivat
> Cc: [email-masked]; Stastny Richard
> Subject: RE: [Iptel] Re: I-D
ACTION:draft-rosen-iptel-dialstring-03.txt
> add-on
> 
> 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:
> 
> >
> >
> > 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
[email-masked]
https://www1.ietf.org/mailman/listinfo/iptel

---

From: "Brett Tate" <[email-masked]>
Date: Thu, 9 Mar 2006 10:12:59 -0500

> provide: sip:[email-masked];user=phone

Unfortunately or fortunately depending on ones opinion, the above is valid
per rfc2806 and not valid per rfc3966.  Because "1234" is not "global", a
phone-context is now required per rfc3966.

This rfc3966 requirement was one of the reasons leading to the need for the
iptel-dialstring document.

> (not even the user=phone is provided in some cases)

Per rfc3966, it is now considered invalid if user=phone is provided for your
example (see above).  And as more devices start enforcing this rfc3966
requirement, it breaks interoperability with devices which implemented
rfc2806 and have not implemented (or been upgraded to) the rfc3966
requirement.

And I agree with others that it isn't worth re-debating the rfc3966
phone-context requirement; everyone just gets to enjoy the results of the
decision.