Subject: RE: [Sip] SIPIT Interop problem with ;user=phone

From: "Rosen, Brian" <[email-masked]>
Date: Wed, 1 Oct 2003 18:18:07 -0400

> > Are you proposing a BCP convention on the use of "phonenumber" and
> > "noclue"?
> 
> no, but I would absolutely prefer it to adding a "user=dialstring" 
> parameter.
> 
Why?  This whole thing is just weird to me.  Either I've convinced you,
or you already understood that differentiating is useful.

Why is it that you don't see the value to explicitly label what the
userpart is?  Why is a hack better?  There really is only one context,
there really are two representations.  Faking it with two contexts
works, in the sense that you can differentiate, but it just doesn't
seem to be as good a solution.  Both need some work; we have at least
one RFC, maybe two in this.  Why is two contexts a better answer?

Let me be clear that I'll still accept two contexts as a compromise.

Brian

_______________________________________________
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, 1 Oct 2003 16:15:08 -0700

On Wednesday, October 1, 2003, at 03:18 PM, Rosen, Brian wrote:
> there really are two representations.

First off, I consider your overall approach a monstrous hack.  I think 
it is ridiculous that folks allow untranslated digits strings in their 
network at all, but at least the phone-context solution quarantines 
them so they can be handled more safely.  I find this sheer laziness 
and very dangerous.  Even many telephone operators can't get this 
right. For example, I am currently on the phone with AT&T Wireless who 
has just changed something last week in their network so that there is 
no way that I can dial a US number with a 1 in front of it at home, but 
no way I can dial a US number without a 1 in front of it at work  (same 
company, same "network", not roaming in either place).  This would 
never happen if there was a standard way to convey full global numbers. 
  All of my devices in my network exchange full global phone numbers, or 
fully qualified SIP URIs.

In other words, if I were in charge of your dialing plan, all your 
"phone numbers" would be translated into either a global e164, or a SIP 
URI with user=ip in an appropriate domain (an AOR).  If you have a 
device that cannot be configured to process the digit map itself, you 
could have this device send its digits (you call them dial strings, I 
think they are just phone numbers in a particular context*) in a tel 
URI with an appropriate phone-context which is unique to that digit map.

You could have more than one digit map/dial plan for some of these dumb 
phones, in which case you would use multiple phone-contexts to sort 
this out.  Likewise, I don't need a phone-context for any of your 
"phone numbers" if these are real AORs, but if these were not unique in 
the domain of the SIP URI you placed them in (not AORs), then you could 
further disambiguate with phone-context.

Several times in this thread, I have given motivations for 
functionality you can get if you follow my proposal, such as one proxy 
handling multiple digit maps (for example in a multi-tenant situation). 
  You have not addressed these cases.  Nobody has provided any technical 
reason why my proposal doesn't work, and I have given many reasons why 
it works.  I will have an ID out in a few days which describes the 
motivations and detailed scenarios for my approach.  Until then, let's 
please pause this thread.

thanks,
-rohan

*To be clear, I think the definition of "dial string" intended by 
RFC2806 was a string of digits that included post-dial information such 
as pauses, waits, and access codes.  Such a dial string always 
*contains* a "phone number" which is the pre-dial portion.

> Faking it with two contexts