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

From: "David R. Oran" <[email-masked]>
Date: Wed, 27 Aug 2003 08:05:37 -0400

Jumping in late - was on vacation.

--On Monday, August 25, 2003 11:13 AM -0500 Dean Willis 
<[email-masked]> 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.
>
I always thought it was simple, but this discussion obviously indicates 
that other people don't. It's clear that ;user=phone has been overloaded to 
the point that it is being treated as a substitute for much of what tel: 
does, but with a different set of restrictions (I assume because tel: drags 
in the entire worm population of the PSTN numbering can).

*I* thought is was to solve the trivial problem of having a user name which 
just happens to collide with a legal phone number within the numbering plan 
of the organization which operates the <domain> containing the user@domain.

Some people have called this the "compuserve" problem, but I'm not sure 
it's confined to that historical environment. I think the question 
basically boils down to the following:
If you have "[email-masked]" and "[email-masked];user=phone", would 
you EVER want these two uri's to address different things. If not, 
;user=phone is in fact noise, or at best a hint to optimize lookup overhead 
in the example.com proxies.

I am particularly troubled by people treating the user part as a "dial 
string", since it is far from clear if something like
"[email-masked];user=phone" is really an AoR or not when 15 is treated as a 
dial string by example.com.

A bit more below.

> 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.
>
What do you do if there is a registered user 9724735455 but the "phone 
number" or worse "dial string" 9724735455 is supposed to reach somebody 
else? I can imagine declaring this illegal, but is that what we want to do? 
Does anybody care to cater to people with numeric email addresses 
(incidentally, Motorola had pure numeric email userids for many years, if I 
recall correctly so it may not be just historical compuserv ids that exist 
in the real world).

> 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.
>
[snip]

Dave.

------------------------
David R. Oran
Cisco Systems
7 Ladyslipper Lane
Acton, MA 01720
Office: +1 978 264 2048
VoIP: +1 408 571 4576
Email: [email-masked]

_______________________________________________
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: Rohan Mahy <[email-masked]>
Date: Wed, 27 Aug 2003 17:26:01 -0700

On Monday, August 25, 2003, at 09:13 AM, Dean Willis wrote:

> years.
> We do phone-number routing, inbound and outbound from PSTN, and 
> user-name
> routing.
>

Yes, I am quite embarrassed to say that this is a bug in your (Cisco) 
phone.

> 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.
>
> 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.

yes, this works just fine, and I have no objection to this.  However, 
If the dynamicsoft proxy wants to be able to handle some phones for 
users in Europe, they either need:

  a) a dialplan in their phone to convert a European dial plan into a 
the (US-specific) dialplan used by the existing dynamicsoft proxy

b) be lucky enough that the two dial plans don't have any ambiguous 
strings (each dial string can be identified as in exactly one dial 
plan).  I don't think this works with existing real NANP and European 
dial plans

c) expect the proxy to interpret the dial plan in the context of the 
sender of the INVITE.  This is a huge pain and a kludge in my opinion 
considering how easy it is to do d).

or d) use a *convention* called ;user=phone to convey a global-number 
which your proxy or gateway can manipulate appropriately, or if send 
your dial string as a "local-number" and then add a phone-context 
parameter with your own domain or global number.

I think d) is a far easier, better, cleaner solution if your proxy 
handles UAs which use different dial plan conventions.  If your proxy 
never handles conflicting addresses, the method which Dean has been 
using for 3 years also works just fine.

> 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.

Note, that using user=phone as a convention that an e164 global address 
may be forthcoming makes understanding another domain's dialing plan 
much easier.  I think this is *a good thing*.

> 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.

agreed.  ideally the dial plan of a SIP telephone will allow me to 
specify the target domain as well (so I can dial both mci.com and 
iptel.org directly).

thanks,
-rohan

> --
> Dean

---

From: Dean Willis <[email-masked]>
Date: Wed, 27 Aug 2003 23:52:07 -0500

On Wed, 2003-08-27 at 19:26, Rohan Mahy wrote:

> Deas said:

Ask them to please not fix it -- I'd hate to have to throw 200 of these
things away.

> using for 3 years also works just fine.

Ok, I think you are saying that 
IF (there is a user=phone parameter) 
THEN 
	(the user part MUST convey a global (+) number) 
OR 
	(there must be a phone-context parameter specifying a non-global
context)

which seems reasonable. It seems to me that this is better accomplished
with phone-context, where one possible context is "e.164".

Howerver, I don't think this is what Brian is saying at all. Indeed, he
seems to be embeddeding the phone-context into the user-part.

> specify the target domain as well (so I can dial both mci.com and 

I don't think that's a dial-plan issue -- I think it's just a user
interface issue, just as my email client lets me enter addresses
@cisco.com and @ietf.org on this email. The phone, like the email
client, doesn't need to translate anything.

--
Dean

---

From: Rohan Mahy <[email-masked]>
Date: Fri, 29 Aug 2003 08:11:58 -0700

> Ask them to please not fix it -- I'd hate to have to throw 200 of these

The proposed "fix" would make it configurable what to send, and to 
understand what to do if it receives it.  You would lose no 
functionality.

> 	(there must be a phone-context parameter specifying a non-global

yes exactly.

> with phone-context, where one possible context is "e.164".

I'm not sure what you are proposing exactly.  Do you want to deprecate 
user=phone and add a new standard URI parameter called phone-context, 
or just require the phone-contact user parameter when the SIP URI user 
parameter is set to phone, or something else?

> seems to be embeddeding the phone-context into the user-part.

I think he gave an example where he was not.  maybe i just missed 
something.

> client, doesn't need to translate anything.

what I meant is that if I dial 01134934957777 (the Hilton Barcelona), I 
want the resulting INVITE to go to capcom with a URI like 
sip:[email-masked];user=phone , and if I dial 12024561414 
(Whitehouse switchboard), I want to the resulting INVITE to go to MCI 
with a URI like sip:[email-masked];user=phone.

I can trivially accomplish this with a set of regular expression (for 
example the following example perl regular expressions).

/^01134(\d+)$/sip:\+34-\[email-masked];user=phone/
/^1({3}\d)({7}\d)$/sip:\+1-\$1-\[email-masked];user=phone/

I think this is actually a useful feature.

thanks,
-rohan