Subject: Re: [Sip] More on dial plans and user=phones

From: Jonathan Rosenberg <[email-masked]>
Date: Mon, 25 Aug 2003 16:14:10 -0400

A few thoughts here, not all directly applicable to Dean's note, but 
better one email with a consolidated reply than many.

Firstly, the motivation for adding the user parameter into the SIP URI 
was only to give a hint on the BNF for the user part. Nothing more. 
Interestingly, you really can't even have two URIs in the domain that 
differ only by the user param. According to rfc3261, a registrar 
doesnt use the user part as an index to look up routing information on 
a subscriber:

          The registrar extracts the address-of-record from the To header
          field of the request.  If the address-of-record is not valid
          for the domain in the Request-URI, the registrar MUST send a
          404 (Not Found) response and skip the remaining steps.  The URI
          MUST then be converted to a canonical form.  To do that, all
          URI parameters MUST be removed (including the user-param),

Secondly, the interpretation of the user part is at the discretion of 
the domain which owns that user part. No one else should be looking at 
it, or care whether user param is there or not.

The combination of these two, to me, imply that the user parameter 
probably is useless, since if the user part is examined ONLY by the 
domain that owns it, there are other syntactic hints that can be used 
by putting things in the user part itself.

The problem we are running into is that these URI are being 
*constructed*. URI are most useful when someone hands them to you, 
either on a business card or in a web page or in a sip request. When 
they are handed to you, there is no need to guess at how to build one, 
or come to agreements on how they are interpreted.

So, if you are constructing a URI within a domain, you have to know, 
ahead of time, what the domain is expecting. Dean is arguing that this 
is something the user has to know about. Others have argued that the 
domain has to transfer a script that informs the phone how to 
construct the URI. The root question here is - who's responsible for 
figuring out how to convert user input into something that the server 
processing that input can understand?

The issue of convering raw user input into something a server can 
understand sounds a lot like the scope of the app-interaction work 
that we have been doing in sipping. Indeed, the scripts that Henning 
were talking about sound a lot like KPML scripts, except that the 
result of some user input would not be a push of some stimulus but the 
transmission of an INVITE message. Either way, the KMPL scripts 
basically encode the dial plans.

-Jonathan R.

Dean Willis wrote:
> It's all either far more complicated or far simpler than we seem to think,
> and I'm confused as to which of the above is true.
> 
> Let's talk about a "real" system -- my office, where we've been running
> everyday telephony using SIP phones and proxies and gateways for > 3 years.
> We do phone-number routing, inbound and outbound from PSTN, and user-name
> routing.
> 
> But I'm not sure I've ever seen a user=phone, and I don't think the system
> would know what to do if it did.
> 
> Assume than an INVITE arrives at my proxy with a request URI looking
> something like [email-masked].
> 
> Is this a phone number or a user? Dunno, yet.
> 
> We look in the proxy's configuration and see if 9724735455 is a defined
> user. If it is, we route the number according to the user's CPL. If not, we
> treat it as a phone number and consult the proxy's dial plan table.
> 
> This works for inbound, outbound, complex forwarding, calls through other
> people's proxies (like iptel.org, which I use from the house), and so on.
> 
> Now: here's the tricky part -- as a user, I have to have some level of
> understanding of the dial plan that the proxy understands. For example, I
> know that if I want to dial Dallas phone number 9725551212, I enter exactly
> those digits, but if I want New Jersey's 9735551212, then I have to add a
> leading 1 (19735551212), and if I want international +19735551212, then I
> dial 0119735551212. Oddly enough, this makes the whole thing work just fine
> without downloading any dial plans or using any tel-URIs or user=phones.
> 
> If I wanted to use iptel.org's routing, I'd set my phone up to send
> [email-masked] instead, and I'd have to understand the dialing plan
> imposed by their proxy.
> 
> This points something out: IF we do download dialing plans, then the dialing
> plan has to stay synched between the phone and its default proxy, applies
> ONLY to calls made through the default proxy, and MUST BE ignored if a
> different target domain is entered by the user.
> 
> --
> Dean
> 
> 
> _______________________________________________
> Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> This list is for NEW development of the core SIP Protocol
> Use [email-masked] for questions on current sip
> Use [email-masked] for new developments on the application of sip
> 

-- 
Jonathan D. Rosenberg, Ph.D.                600 Lanidex Plaza
Chief Technology Officer                    Parsippany, NJ 07054-2711
dynamicsoft
[email-masked]                     FAX:   (973) 952-5050
http://www.jdrosen.net                      PHONE: (973) 952-5000
http://www.dynamicsoft.com

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [email-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip

---

From: "Dean Willis" <[email-masked]>
Date: Mon, 25 Aug 2003 11:13:16 -0500

--
Dean