Re: [martini] Proposed work split: tackle telephone-numberregistration first

["Spencer Dawkins" <[e-mail]>]

Hi, Paul,

Ah - I was guessing that you'd moved the same topic lower in the note. 
Thanks for clueing me in for certain!

Spencer


> (I sent this out with an incomplete thought I meant to delete. Here is 
> revised version.)
>
> Spencer Dawkins wrote:
>> OK, this discussion continues to be lovely. Thanks again for listening to 
>> the people you're talking to ("plays well with others" is 
>> under-appreciated, once we get out of primary school, but *I* appreciate 
>> it!)
>>
>> After reading this thread down through Eric's note below, I have a few 
>> requests, as co-chair.
>>
>> We're talking about E.164 numbers like we can easily identify them. My
>> understanding from Tuesday's call was that people on the call thought the
>> only way we could unambiguously know that we had an E.164 number was if 
>> we
>> had a tel: URI. If people on this list want to challenge that assertion, 
>> this would
>> be a great time to say so - please push back Real Soon Now.
>
> I don't know that it is the *only* way, but it is an unambiguous way.
>
> Of course sip URIs *can* contain E.164 numbers. The trick is in ensuring
> that everybody concerned agrees that's what they are.
>
>> If that's true, we're talking about using Tel: URIs. Dean has asserted 
>> that this would require an update to 3261. I'm not a genius of 3261, but 
>> some of you guys are - could you point us to what you think needs to be 
>> updated?
>
> That would come up *if* the intent is to *explicitly* register a TEL
> URI. The key issue is from section 10.2:
>
>       To: The To header field contains the address of record whose
>            registration is to be created, queried, or modified.  The To
>            header field and the Request-URI field typically differ, as
>            the former contains a user name.  This address-of-record MUST
>            be a SIP URI or SIPS URI.
>
> But if the goal is to register using a SIP URI, and cause the "implicit
> registration" of a number of TEL URIs, its not so clear that we have the
> same problems with 3261.
>
> The more important issue is "constructing" an R-URI from a registered
> contact address as a part of implicit registration, and ensuring that
> the resulting URIs are unambiguous at the pbx. As long as the implicitly
> registered AORs are all TEL URIs, or sip URIs with a TEL user part, then
> the pbx can know what to expect as R-URIs for incoming requests. And it
> can know that the URI for a given telephone number will be the same
> regardless of what SSP it uses.
>
> (To ensure that, we would want to specify that the E.164 number was
> represented in its canonical form, without any of the optional separator
> characters.)
>
> Thanks,
> Paul
>
>> My quick read turned up this text in Section 4, page 17:
>>
>>   Registration is another common operation in SIP.  Registration is one
>>   way that the biloxi.com server can learn the current location of Bob.
>>   Upon initialization, and at periodic intervals, Bob's SIP phone sends
>>   REGISTER messages to a server in the biloxi.com domain known as a SIP
>>   registrar.  The REGISTER messages associate Bob's SIP or SIPS URI
>>   (sip:[e-mail]) with the machine into which he is currently
>>   logged (conveyed as a SIP or SIPS URI in the Contact header field).
>>
>> Dean, Is this what you were thinking of? Are there other places that also 
>> need to change?
>>
>> As I read http://www.ietf.org/id/draft-peterson-rai-rfc3427bis-04.txt, 
>> Section 2.1, this change would have to go through SIPCORE, because it's 
>> an update to 3261. If you know of obvious land mines that we would be 
>> walking into if we propose this change, please say so Real Soon Now. (One 
>> obvious land mine is that DISPATCH isn't meeting in Anaheim, so the 
>> proposal would have to be DISPATCHed on the mailing list in order to do 
>> something before IETF 78 - are there OTHERS?)
>>
>> Finally, if you believe that embracing tel: URIs is the wrong thing to 
>> do, please say so, Real Soon Now.
>>
>> The milestones that we committed to in 
>> http://tools.ietf.org/wg/martini/charters have us adopting a working 
>> group SOLUTION draft in January. We're not late yet, but it's the 28th of 
>> January in my time zone. If we are late, where late is measured in days, 
>> I can live with that, but if we are late, where late is measured in IETF 
>> meeting cycles, that's going to be a problem.
>>
>> Thanks,
>>
>> Spencer, as co-chair
>>
>> ----- Original Message ----- From: "Eric Burger" 
>> <[e-mail]>
>> To: "Dean Willis" <[e-mail]>
>> Cc: <[e-mail]>
>> Sent: Thursday, January 28, 2010 12:32 PM
>> Subject: Re: [martini] Proposed work split: tackle
>> telephone-numberregistration first
>>
>>
>>> If you ask me (why can't I stay in retirement?), the E.164 situation  is
>>> not only a simplification, but just about the only thing that is 
>>> sensible
>>> for MARTINI to work on.
>>>
>>> The E.164 situation is a clear, present, industry-is-begging-for-a-
>>> solution problem.  It is so pressing, the industry will tell us (the
>>> IETF) to get stuffed and do something stupid if we cannot deliver
>>> something that is not at its core fundamentally broken.
>>>
>>> I do not think anyone can have an issue with mechanisms that translate 
>>> a
>>> string of digits into an AOR that might cross domain boundaries.   This 
>>> is
>>> the E.164 problem statement.
>>>
>>> If think everyone (with a brain) SHOULD have issues with a mechanism 
>>> that
>>> magically mungs "sip:[e-mail]" into "sip:[e-mail] 
>>> "
>>> while at the same time www.neustar.biz is really a neustar.biz  domain.
>>> That really would be creating a parallel DNS, which, as one  of the 
>>> major
>>> DNS operators, would really, really be "less than ideal"  and have a 
>>> whole
>>> host of security and integrity issues.
>>>
>>> THEREFORE, I would propose that we split this work into two phases:
>>>   Phase 1: Deliver an E.164 solution, preferably in the next few 
>>> months,
>>> so the industry does not ignore the IETF.
>>>
>>>   Phase 2: Deliver the generic solution in the normal, 3-5 year IETF
>>> cycle.  This generic solution may or may not encompass E.164 numbers. 
>>> As
>>> Doug Sauder points out, E.164 numbers and their infrastructure are
>>> different.  Thus a different E.164 registration model from generic SIP
>>> URI provisioning models would neither be a burden on industry nor 
>>> create
>>> backwards-compatibility issues for the generic solution.
>>>
>>> Note that if we do not deliver Phase 1 in a very, very timely manner, 
>>> the
>>> less-than-idea industry solution just might blow up the  possibility for
>>> the generic solution, which would be considerably less  than ideal.
>>>
>>> On Jan 27, 2010, at 1:16 AM, Dean Willis wrote:
>>>
>>>>
>>>> We seem to have an urgent need for a near-term solution for dealing 
>>>> with
>>>> the subset of the MARTINI problem that, loosely defined, covers  the
>>>> "telephone number" problem.
>>>>
>>>> The typical scenario here is SIP trunking, wherein a SIP Service
>>>> Provider (SSP) provides an ISDN-PRI like service over IP to a 
>>>> customer's
>>>> PBX (or PBXes). In this model, the SSP maps a whole  bunch  of phone
>>>> numbers to the PBXes. This mapping is somewhat  dynamic, because the
>>>> PBXes usually have DHCP addresses, and don't  have DNS entries that 
>>>> point
>>>> A records at the PBX in any sort of  particularly useful way (maybe
>>>> something like dhcp-10-1-2-3- example.com).
>>>>
>>>> So what we need is a way for a PBX, when it reboots (or perhaps
>>>> periodically) to say to the SSP "Here I Am; You may now send any  calls
>>>> for my assigned phone numbers to my current Contact."
>>>>
>>>> This is indeed a "registration" problem, but it isn't necessarily a
>>>> "domain registration problem". The only reason domains get mixed  into
>>>> this scenario at all is that we sometimes encode telephone  numbers as
>>>> the user parts of SIP URIs, and those SIP URIs have a  domain part
>>>> attached to them.
>>>>
>>>> More interestingly, this problem is a tiny subset of the whole  MARTINI
>>>> dynamic binding problem, and it potentially can be solved  much more
>>>> simply than the general problem.
>>>>
>>>> On today's Interim II call, Richard, Adam and I raised the idea of
>>>> dividing our problem space, and taking on a near-term milestone for
>>>> delivering a MARTINI solution for registering contacts to a proxy, 
>>>> where
>>>> that proxy maps one or more telephone numbers to the contact.
>>>>
>>>> We certainly intend to go on and tackle the more general domain-
>>>> registration problem, but I (and I believe Adam and Richard) believe
>>>> that we get a lot out of tackling the telephone-number subset first.
>>>>
>>>> In particular, we believe that this approach solves many of the  domain
>>>> "responsibility" questions, simplifies the TLS keying/ certification
>>>> model immensely, eliminates the cognitive overload of  using REGISTER 
>>>> to
>>>> bind a "domain" to a Contact, "route  authentication", and a good many
>>>> other open issues that plague our  current drafts.
>>>>
>>>>
>>>> Open questions relating to this approach include:
>>>>
>>>> 1) Do we deal only with E.164 numbers, or do we need to deal with
>>>> private-number "phone contexts"?
>>>>
>>>> 2) D owe need to explicitly encode the telephone numbers being
>>>> registered in the REGISTER request (either directly or through some 
>>>> sort
>>>> of regexp), or is it adequate to rely on provisioning of the  SSP and 
>>>> PBX
>>>> (and any UAs) to statically bind the numbers to the PBX  identity, and
>>>> then dynamically only register the PBX identity to the  PBX contact?
>>>>
>>>> 3) Can we "register" with a tel: URI as the "To" value? (this seems  to
>>>> require extending RFC 3261)? Note that "tel:" can express both E. 164
>>>> numbers and private phone-contexts in one format.
>>>>
>>>> 4) What happens with GRUUs?
>>>>
>>>> I believe all of these issues are quite tractable, if we accept the
>>>> fundamental idea of splitting the phone-number problem off from the 
>>>> more
>>>> general domain-registration, and recognize the possibility that  the
>>>> solutions to the two problem may reasonably be quite different  from 
>>>> each
>>>> other.
>>>>
>>>> So, what do you people think? Is it worth trying to drink the  MARTINI
>>>> elephant one sip at a time, or are we going to treat the  whole thing
>>>> like a tequila shot and just slam it down?
>>>>
>>>> -- 
>>>> Dean
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> martini mailing list
>>>> [e-mail]
>>>> https://www.ietf.org/mailman/listinfo/martini
>>>
>>> _______________________________________________
>>> martini mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/martini
>>
>> _______________________________________________
>> martini mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/martini
>>
> _______________________________________________
> martini mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/martini
>