Subject: RE: proxy-based dialing plan problem

From: "Gardell, Steve" <[email-masked]>
Date: Fri, 17 Dec 1999 14:29:07 -0500

> -----Original Message-----
> From: Jonathan Rosenberg [mailto:[email-masked]]
> Sent: Friday, December 17, 1999 9:32 AM
> To: Rick Dean
> Cc: [email-masked]
> Subject: Re: proxy-based dialing plan problem
> 
> 
> 
> 
> Rick Dean wrote:
> > 
> > I hear debate on whether to put a dialing plan inside my
> > SIP phone.  If the phone has a dialing plan, the phone would
> > internationalize numeric entries, making them look like
> > <sip:+18472621415;user=phone> or preferably <tel:+18472621415>.
> > I don't like this.
> 
> I believe there are clearly pros and cons. The function can just as
> easily live within a UA or a proxy. In the end, service providers that
> deploy these things will make the decision about where they want it
> done. My sneaking suspicion is that this is best done in a 
> UA, however,
> so that we consistently pass around numbers in messages which have
> meaning globally. Its a similar argument for domain names. 
> Would your UA
> send an INVITE to its local proxy in the form:
> 

What is the nature of a SIP phone that is not a UA? Pointers
to specific documents that describe this would be great!

> INVITE sip:joe@host SIP/2.0
> 
> from within domain foo.com, and then expect the proxy to fill in the
> foo.com within the request URI? 
> 
> > 
> > The alternative is a proxy-based dialing plan.  The phone
> > has a default-dialing domain (DDD), which is appended
> > to numeric entries.
> > 
> > For example, my DDD could be 1847.x.com, which would allow
> > me to dial 2621415 generating <sip:[email-masked]>, which
> > ultimately means the example above.  Similarly, 8472621415
> > and +18472621415 would also work though my smart
> > proxy.  BTW, for those of  you who have not played with
> > my phone, it has an end-of-dialing (Ok) key.
> 
> I don't like this at all. Domain names are not meant to convey dial
> plans. Rather, the UA should send:
> 
> INVITE tel:2621415 SIP/2.0
> 
> and then the proxy uses its local configuration to determine that this
> number is a local number, and in fully qualified form is
> tel:+18472621415. It may then invoke enum and or TRIP services, and
> forward an INVITE to the next hop proxy, perhaps of the form:
> 
> INVITE tel:+18472621415 SIP/2.0
> 
> or
> 
> INVITE sip:[email-masked]
> 
> I am beginning to lean towards the tel form.
> 
> What is debatable is whether the tel URL from the UA to the proxy
> contains some kind of dialing plan indicator as a URL parameter, or
> whether the dialing plan is known by configuration.
> 
> 
> > In the following example phone1 again has a DDD of 1847.x.com,
> > and is in a call with phone2.  Phone1 attempts a blind transfer to
> > 5551234, (which phone1 means tel:+18475551234, but only the
> > proxy knows it).  The call does not have a route, so the
> > BYE passes end to end without a proxy.
> > 
> > phone1      1847.x.com                      phone2
> >   |             |                              |
> >   | BYE         |                              |
> >   | Also:<sip:[email-masked]>              |
> >   |------------------------------------------->|
> >   |    200 OK                                  |
> >   |<-------------------------------------------|
> >   |             |                              |
> > 
> 
> Your problem is that you should not transfer to the SIP URL. What you
> really want is to transfer to a tel URL. Furthermore, in the case of
> these transfers (and redirects as well), I think it is essential that
> the tel URL be a complete E.164 number. With normal SIP URLs, if a UA
> was in domain foo.com, it would never do a transfer like:
> 
> BYE
> Also: sip:joe@host
> 
> when it really meant:
> 
> BYE
> Also: sip:[email-masked]
> 
> You'll get yourself in all kinds of horrible troubles by 
> passing around
> URLs that don't have complete domain names in them. Same for phone
> numbers. You are only safe in using incomplete numbers in INVITE
> messages passed to *local* proxies. If your UA is already 
> configured to
> know to send calls to 1847.x.com, why can't it rather be configured to
> know that it should BYE/Also to tel:18475551234?
> 
> 
> -Jonathan R.
> 
> -- 
> Jonathan D. Rosenberg                       200 Executive Drive
> Chief Scientist                             Suite 120 
> dynamicsoft                                 West Orange, NJ 07052
> [email-masked]                     FAX:   (732) 741-4778
> http://www.cs.columbia.edu/~jdrosen         PHONE: (732) 741-7244
> http://www.dynamicsoft.com
>

---

From: James Yu <[email-masked]>
Date: Mon, 20 Dec 1999 11:49:52 -0600

I would appreciate if one of you could briefly describe how the user at the
UA makes a call to an E.164 number.  I assume that the user must invoke a
software, provide the called E.164 number, and hit "enter" or click
something to initiate the call.  Is that software generic (can be used to
access any proxy server), or is it tailed for a particular proxy server?
For the latter case, can the proxy-specific software be designed so that the
proxy server understands and can process the information entered/provided by
the user? 

James
> From: [email-masked] [mailto:[email-masked]]
> Sent: Monday, December 20, 1999 11:45 AM
> To: [email-masked]
> Cc: [email-masked]; [email-masked]
> Johnathan & Henning,
> Thankyou for your insights.   
> 
> Have we agreed on a solution to 
> the numbering plan problem?  That is,
> how should a UA globalize a phone number when
> the user does not enter it that way?  
> 
> To recap, my proposal would allow the UA not to know
> about the PSTN numbering plan, but choose
> to send it as a SIP URI to a default proxy/gateway. 
> This makes building the UA 
> much easier, and IMHO the protocol more intuitive.  
> I contend this system will work
> as long as that gateway can redirect to a globalized
> PSTN number in 401 unathorized, while still accepting
> credentials.  I think this is best performed with
> an "also" in the 401 unauthorized, but from looking
> back though HTTP, maybe a "Location:" would do.
> 
> For example dialing in Chicago though my PSTN gateway
> service provider of x.com might produce invites like
>   INVITE [email-masked] SIP/2.0
> When I forward people who use y.com to this number they
> might receive 
>   BYE sip:[email-masked] SIP/2.0
>   Also: <[email-masked]>
> from me and 401 Unauthorized which might look like
>   401 Unauthorized
>   Also: <tel:+18472621415>
> from the PSTN gateway which they could act accordingly with.
> 
> How do we go from here?  I am willing to write
> this up as an Internet Draft if you think that
> is best.  Maybe with a longer explaination
> of how the system works people would implement
> it more consistently, or make a more informed
> decision not to.
> 
> If you are still opposed to this architecture, I 
> am willing to build it such that 1847.x.com always redirects
> everyone to the globalized PSTN number.  The UA
> would receive additional logic which sends numbers beginning
> with a "+" to a different gateway, which my solultion
> requires anyway.  This requires no
> standards changes, but adds an additional transaction
> to the normative case.  Hmmm.  
> 
> My compliments on building a protocol which is general
> enough to handle this unplanned case even without 
> changes.
> 
> --
> Rick
> 
> 
> 
> 
>