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

From: "Christer Holmberg (SE/LMF)" <[email-masked]>
Date: Tue, 26 Aug 2003 16:44:47 +0200

Hi,

>>Also, does that mean that a gateway will have to be able to, using
>>Dean's example, understand both +19735551212 and 0119735551212? Or,
>>can we still have rules defining how dial strings are 
>>represented in SIP-URIs - no matter if we use telephone-subscriber or something
>>else...
>
>pstn gws usually assume to receive the called number in certain format
>that is gw specific.  it is the task of the proxy feeding the 
>gw to know the format and if necessary rewrite the called number.  this 
>has nothing to do with user=phone.

It is true that every gateway (maybe also other SIP nodes), based on "local policy", can define in which format it wants to receive telephone numbers. 

But, from an interop point of view I think it would be good to have a "standard" way of eg sending telephone numbers in a SIP-URI - no matter if we use user=phone or not, and no matter if the syntax is according to telephone-subscriber or not - if we have networks where nodes may be assigned telephone numbers.

Regards,

Christer Holmberg
Ericsson Finland

_______________________________________________
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: Juha Heinanen <[email-masked]>
Date: Tue, 26 Aug 2003 17:29:19 +0300

Christer Holmberg (SE/LMF) writes:

 > can we still have rules defining how dial strings are represented in
 > SIP-URIs - no matter if we use telephone-subscriber or something
 > else...

pstn gws usually assume to receive the called number in certain format
that is gw specific.  it is the task of the proxy feeding the gw to know
the format and if necessary rewrite the called number.  this has nothing
to do with user=phone.

-- juha

---

From: "Christer Holmberg (SE/LMF)" <[email-masked]>
Date: Wed, 27 Aug 2003 07:12:23 +0200

Hi,

I agree (I assume) with Jonathan on the fact that the user parameter should NOT be used to make routing decissions. When I make a call with my SIP phone, I may not even know if the call is going to end up in the PSTN network, so I can't insert user=phone based on that. The proxies will make the routing decissions based on whatever other policies.

I also agree that user=phone should NOT be a part of the userid itself. Ie "sip:[email-masked]" represents exactly the same user as "sip:[email-masked];user=phone". There can not be two users with the same identity, I think, even if one happens to be on the PSTN side of a gateway.

To me user=phone currently only indicates that the userpart syntax is as defined for telephone-subscriber - which some seem to agree on, and others don't. Now, I agree that we may not really need a parameter to indicate that, if we instead have a defined way of putting telephone numbers in a SIP-URI.

Regards,

Christer Holmberg
Ericsson Finland

> -----Original Message-----
> From: Jonathan Rosenberg [mailto:[email-masked]]
> Sent: 25. elokuuta 2003 23:14
> To: Dean Willis
> Cc: [email-masked]
> Subject: Re: [Sip] More on dial plans and user=phones
> 
> 
> 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
> > 
> > 
> -- 
> 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
> 
>