Subject: RE: [Sipping] Do Phones Have Dial Plans, or do Proxies map? was RE: [Sipping] Re: draft-schulzrinne-sipping-sos-04.txt

From: "Peterson, Jon" <[email-masked]>
Date: Thu, 9 Jan 2003 19:01:40 -0500

I feel pretty strongly that phone numbers should be converted into
fully-qualified E.164 numbers at the originating user agent. It is very
problematic, outside of an architecture that is constrained in a way that we
are unlikely to standardize, for a proxy server to figure out the context in
which a set of arbitrary digits were dialed. Of course, if you're dialing a
number that cannot be converted to E.164, then it needs to be sent as-is. 

This design decision has come up previously in the SIP-T work and in the tel
URL work.

Jon Peterson
NeuStar, Inc.

> -----Original Message-----
> From: Rosen, Brian [mailto:[email-masked]]
> Sent: Thursday, January 09, 2003 10:45 AM
> To: 'Paul Kyzivat'
> Cc: 'Henning Schulzrinne'; [email-masked]'
> Subject: RE: [Sipping] Do Phones Have Dial Plans, or do 
> Proxies map? was
> RE: [Sipping] Re: draft-schulzrinne-sipping-sos-04.txt
> 
> 
> I think this response just restates the question.  
> I think we either say that phones essentially always put out 
> global numbers, or they put out dialing strings and a proxy 
> expands it.  We can probably agree on the tel uri prefix for
> either.  If a proxy expands dialing strings to phone numbers,
> then we probably do need some kind of context, as you point out.
> 
> First we should decide if we put the dialing plan in the phone.
> 
> BTW, I currently favor NOT putting the dialing plan in the UA,
> but I don't feel strongly about it.  I do feel strongly about
> standardizing this bit, because I surely want all sipphones to
> "play" in my system, and I don't want a boat-load of vendor specific
> code to make that work.
> 
> Our sip based enterprise system has a classical enterprise dialing 
> plan, although we interpret 7 or more digits as national or 
> international numbers, rather than requiring the "9" prefix.  
> That works because all internal numbers are less than 7 digits.  
> Proxies do the expansion.  There is vendor specific code in this 
> proxy because no two gateways we support work the same.  
> Hence this entire effort :)
> 
> Brian
> 
> > -----Original Message-----
> > From: Paul Kyzivat [mailto:[email-masked]]
> > Sent: Thursday, January 09, 2003 1:13 PM
> > To: Rosen, Brian
> > Cc: 'Henning Schulzrinne'; [email-masked]'
> > Subject: Re: [Sipping] Do Phones Have Dial Plans, or do 
> > Proxies map? was
> > RE: [Sipping] Re: draft-schulzrinne-sipping-sos-04.txt
> > 
> > 
> > Unless we are going to require users to enter full URIs into 
> > the phone 
> > (including "tel:"), the phone MUST have some sort of dial 
> > plan. We only 
> > need to discuss how complex it is.
> > 
> > At one extreme it could simply be to prefix the entered digits with 
> > "tel:" and let a proxy do the rest.
> > 
> > At the other extreme it could do all sorts of complex 
> > transformations to 
> > turn short sequences into global tel: uris, or even sip uris, 
> > possibly 
> > even chosing different gateways based on dialed number.
> > 
> > As I mentioned in an earlier reply, simply slapping "tel:" on the 
> > entered digits doesn't create syntactically correct tel: uris 
> > according 
> > to the latest definition. To go that way, the tel: syntax 
> needs to be 
> > altered. Also, the tel: definition currently says that a 
> tel: address 
> > SHOULD always use global syntax unless there is no valid 
> > global address. 
> > Encoding dialed digits as a local tel: uri and defering 
> > conversion to a 
> > global address to a proxy would violate that rule.
> > 
> > One possibility is to define the minimal dial plan for a phone as: 
> > prefix the dialed digits with "tel:" and suffix the dialed 
> > digits with 
> > ";phone-context=XXX", where XXX needs to be learned or provisioned 
> > somewhere. The XXX is then effectively a name for the dial 
> plan to be 
> > used to expand the number. This gets around the syntax problem with 
> > using the tel: uri, though it still violates the semantic rule.
> > 
> > 	Paul
> > 
> > Rosen, Brian wrote:
> > > The systems I'm aware of use regexps in one form or another
> > > to mangle a string into a dialed number.  I don't have
> > > a problem making this a UA function, but if we do, I want
> > > to standardize the regexp and "Publish" it to the UA.
> > > 
> > > A lot of enterprise gateways have dial string to dialed 
> > number mapping.
> > > Some sipphones do.
> > > 
> > > Brian
> > > 
> > > 
> > > 
> > > 
> > >>-----Original Message-----
> > >>From: Henning Schulzrinne [mailto:[email-masked]]
> > >>Sent: Thursday, January 09, 2003 10:32 AM
> > >>To: Rosen, Brian
> > >>Cc: 'Paul Kyzivat'; [email-masked]'
> > >>Subject: Re: [Sipping] Do Phones Have Dial Plans, or do 
> > >>Proxies map? was
> > >>RE: [Sipping] Re: draft-schulzrinne-sipping-sos-04.txt
> > >>
> > >>
> > >>I would find it instructive how non-SIP systems have 
> solved similar 
> > >>problems. In web browsers and email, we have auto-completion 
> > >>functions 
> > >>and nick names, for examples.
> > >>
> > >>There's also the analogy with 'real names' (not the defunct 
> > >>company, the 
> > >>concept) which translates strings-nice-for-humans into URLs. 
> > >>See the CRN 
> > >>work, including the go: URL. (I'm not aware of 
> > implemenentations, but 
> > >>the concept may be relevant, in particular keeping the 
> > identifier and 
> > >>various 'nicknames' clearly distinct.)
> > >>
> > >>There are probably two sub-problems here:
> > >>
> > >>- Recognizing patterns so that one can keep the old 
> > >>"no-need-to-hit-dial" user interface.
> > >>
> > >>- Translating abbreviations such as extensions and local-area 
> > >>numbers to 
> > >>fully-expanded, globally unique identifiers.
> > >>
> > >>The former will always require downloading a pattern to an 
> > >>end system, 
> > >>the latter is a (local) translation service. The only 
> question then 
> > >>becomes if the translation is done in one or two steps, 
> > i.e., before 
> > >>issuing a SIP request or as part of a SIP request.
> > >>
> > >>Aside: There are clearly examles of widely-deployed systems 
> > where the 
> > >>phone has a dial-plan, downloaded via tftp.
> > >>
> > >>Rosen, Brian wrote:
> > >>
> > >>>This comes up a lot.  I think we should decide.
> > >>>
> > >>>Who translates a dial string into a tel uri?
> > >>>
> > >>>tel uris, as of now, explicitly don't handle dialing strings,
> > >>>only dialed numbers.  In essentially all existing systems,
> > >>>phones don't have dialing plans in them; central elements
> > >>>map dialing strings to dialed numbers.  What's our story?
> > >>>Does every UA that has a dial pad have to have a dialing plan 
> > >>>loaded in it that maps dialing strings to dialed numbers, 
> > >>>or does a proxy server do it?
> > >>>
> > >>>If it's the former, then how do we standardize the mapping?
> > >>>If it's the latter, then how does a UA send a dialing string?
> > >>>
> > >>>Brian
> > >>>
> > >>>
> > >>>
> > >>>>-----Original Message-----
> > >>>>From: Paul Kyzivat [mailto:[email-masked]]
> > >>>>Sent: Thursday, January 09, 2003 9:53 AM
> > >>>>To: [email-masked]'
> > >>>>Subject: [Sipping] Re: draft-schulzrinne-sipping-sos-04.txt
> > >>>>
> > >>>>
> > >>>>I have a few comments about 
> draft-schulzrinne-sipping-sos-04.txt.
> > >>>>(I haven't been following this work very closely, so 
> > >>>
> > >>perhaps some of 
> > >>
> > >>>>these pertain to things that were in earlier drafts.)
> > >>>>
> > >>>>I must say, these are really messy problems, so I am 
> glad you are 
> > >>>>working on them.
> > >>>>
> > >>>>Section 3.2 says:
> > >>>>
> > >>>>   ... a UAC MAY use a "tel" URI [3,4] without 
> > >>>
> > >>phone-context, such as
> > >>
> > >>>>   tel:911
> > >>>>   tel:112
> > >>>>
> > >>>>The latest and greatest definition of the tel: uri that I 
> > >>>
> > >>can find is 
> > >>
> > >>>>draft-antti-rfc2806bis-07.txt. According to that, the above 
> > >>>
> > >>tel: uris 
> > >>
> > >>>>are syntactically incorrect. Either the number must be global 
> > >>>>or else it 
> > >>>>must contain a phone-context parameter.
> > >>>>
> > >>>>Are there plans to change the definition of the tel uri, 
> > or is this 
> > >>>>language going to change?
> > >>>>
> > >>>>In the case of a UAC that is using a local outbound 
> proxy, is it 
> > >>>>required that the UAC specifically recognize these strings 
> > >>>>and deliver 
> > >>>>them to the proxy, or is it sufficient for it to deliver 
> > >>>
> > >>any and all 
> > >>
> > >>>>dialed digit strings to the proxy as tel uris without 
> > attempting to 
> > >>>>recognize them itself? Is it sufficient to determine that 
> > >>>
> > >>the dialed 
> > >>
> > >>>>number is complete by timeout on the input rather than by 
> > >>>
> > >>recognition?
> > >>
> > >>>>Section 5 specifies that the UAC should insert location 
> > >>>>information into 
> > >>>>emergency calls. However, presumably location information 
> > should in 
> > >>>>general not be placed in non-emergency calls, so it is 
> > >>>
> > >>important that 
> > >>
> > >>>>the UAC realize it is making an emergency call. In the case 
> > >>>
> > >>of dialed 
> > >>
> > >>>>digit strings, it may only be the outbound proxy that can 
> > >>>>determine if 
> > >>>>the call is an emergency call. One way to handle this would 
> > >>>>be for the 
> > >>>>local outbound proxy to redirect requests to tel: emergency 
> > >>>>numbers to 
> > >>>>the corresponding sip:sos number. Then the UAC would be able to 
> > >>>>positively determine this is an emergency call and include 
> > >>>>the location 
> > >>>>information.
> > >>>>
> > >>>>Section 9 says:
> > >>>>
> > >>>>   We propose a new DHCP option that enumerates the valid local
> > >>>>   emergency identifiers, as a list of "tel", "sip" or 
> > "sips" URIs.
> > >>>>
> > >>>>This doesn't seem sufficient. Most phone-like devices have 
> > >>>>provision for 
> > >>>>entering primarily sequences of digits, not tel: uris. It is 
> > >>>>up to the 
> > >>>>phone to translate a digit sequence into a valid uri. In 
> > >>>
> > >>general this 
> > >>
> > >>>>requires some sort of dial plan. Without the dial plan, the 
> > >>>
> > >>phone may 
> > >>
> > >>>>well not be able to generate anything that matches one of the 
> > >>>>specified 
> > >>>>tel uris.
> > >>>>
> > >>>>	Paul
> > >>>>
> > >>>>_______________________________________________
> > >>>>Sipping mailing list  
> https://www1.ietf.org/mailman/listinfo/sipping
> >>>>This list is for NEW development of the application of SIP
> >>>>Use [email-masked] for questions on current sip
> >>>>Use [email-masked] for new developments of core SIP
> >>>>
> >>>
> >>>_______________________________________________
> >>>Sipping mailing list  
https://www1.ietf.org/mailman/listinfo/sipping
>>>This list is for NEW development of the application of SIP
>>>Use [email-masked] for questions on current sip
>>>Use [email-masked] for new developments of core SIP
>>
> 
_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [email-masked] for questions on current sip
Use [email-masked] for new developments of core SIP
_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [email-masked] for questions on current sip
Use [email-masked] for new developments of core SIP

---

From: Henning Schulzrinne <[email-masked]>
Date: Thu, 09 Jan 2003 22:45:35 -0500

There are probably three slightly different dial-plan issues to deal with:

(1) Extensions within a domain. The domain is likely defined by the 
outbound proxy server, so translating those into E.164 tel: URIs or SIP 
URIs (with E.164 user part) doesn't seem to cause undue problems.

(2) General local numbers, as in 456-7890 in the US. Again, for a 
corporate network with an outbound proxy server in the same location as 
the person dialing, this is well-defined.

(3) Service numbers, like 911 and 411.

I'm not implying that (1) and (2) should use tel: URIs without 
phone-context. (3) was somewhat more open since the context is a bit 
iffier. If 3GPP, say, designates 911 as a universal emergency number, it 
can't really have a (national prefix) context.

Even if you translate the digit string dialed to a tel: URI at the UA, 
you still need to get the regexp to the user, so that the UI can 
distinguish between things that should be come tel: URIs without 
phone-context and those that should get one or to add any of the missing 
digits. There are only three possible ways:

- from the home domain, using the yet-to-be-finalized SIP configuration 
work;

- via DHCP

- via some kind of "ask the outbound proxy" mechanism.

Since the outbound proxy needs to translate the tel: URIs, the third 
option seems like a good candidate. However, since the idea is to 
translate to global at the UA, even the home domain version would work, 
except that it would always have to generate a global tel: URI, not 
something with a phone-context.

As a side note, one may want to support local SIP 'dialing strings' as 
well, so that I can type 'alice' instead of 'sip:[email-masked]'.

One could return this, directly or via content-indirection, in an 
OPTIONS response addressed to sip:outbound.proxy.net.