Re: [martini] Proposed worksplit:tackletelephone-numberregistration first

[Eric Burger <[e-mail]>]

I know, a bunch of folks jumpped on me for confusing DRINKS and DREGS.  
Too many martinis and, if you follow my tweets, too much wine with  
real dregs in it, clearly...

I would offer a tag that means "this SIP URI is a phone number" is  
equivalent in work to "tel:mumble".  I was hoping to ignore that issue  
whole cloth...

On Jan 29, 2010, at 7:36 PM, Spencer Dawkins wrote:

> Hi, Eric,
>
> A couple of things:
>
> - MARTINI came from DREGS (DRINKS is the OTHER alcohol-related  
> working group
> in RAI) - just in case anyone might be trying to trace the DRINKS- 
> MARTINI link...
>
> - it seems to me that we're leaping from "E.164 numbers" - and I  
> agree that
> DREGS and about a million other conversations keep telling us "E.164  
> numbers
> would be easier, and are the only things that matter, anyway" - to  
> tel:
> URIs, which have only been under serious consideration for a few days.
>
> We're only fascinated with tel: URIs because tel: URIs can be  
> unambiguously
> identified as globally unique, and we haven't come up with any other  
> way of
> doing that.
>
> If we defined a new option tag that meant "globally unique E.164  
> number" for
> SIP URIs, would that give us what we need, without moving to tel:  
> URIs?
>
> Thanks,
>
> Spencer
>
> ----- Original Message ----- From: "Eric Burger" <[e-mail] 
> >
> To: <[e-mail]@orange-ftgroup.com>
> Cc: <[e-mail]>
> Sent: Friday, January 29, 2010 6:13 PM
> Subject: Re: [martini] Proposed worksplit:tackletelephone- 
> numberregistration
> first
>
>
> Sorry, but the AVERAGE time to take something from ID-0 to RFC is 48
> months.
>
> E.164-only has a chance because it has been worked on for over two
> years and there was virtually unanimous buy-in at the DRINKS BOF
> (which became the MARTINI work group) that if the problem domain was
> restricted to E.164 numbers, then the proposed approach would be
> acceptable.
>
> Any generic approach will not have such support and will take the
> normal IETF discussion period of 3-5 years.
>
> Longer if it involves INFO :-)  [Inside joke for old SIP folks]
>
>
> On Jan 29, 2010, at 11:28 AM, <[e-mail]>
> <[e-mail]
> > wrote:
>
>> Of course we do not need a solution in 3-5 years. However I hardly
>> believe that a generic solution would require 3-5 years if the E. 
>> 164- only
>> solutions requires only 2 or 3 months.
>>
>> I also understand that doing the E.164-only solution today does  
>> not  mean
>> we ignore the long-term problem. However I still think that an  E. 
>> 164-only
>> solution has almost no value compared to the current 3GPP/ ETSI  
>> solution,
>> especially if the long-term solution significantly  differs from the
>> E.164-only solution. I'm not convinced that the  issues identified  
>> with
>> the 3GPP/ETSI/IMS solution prevent  implementing it even outside the
>> context of the IMS. I'm aware of a  number of PBX on the market  
>> than can
>> already accept an inbound  INVITE request with a Request-URI  
>> containing
>> either the registered  contact or one of the implictly or explictly
>> registered AoRs.
>>
>> BC
>>
>>> -----Message d'origine-----
>>> De : Eric Burger [mailto:[e-mail]]
>>> Envoyé : vendredi 29 janvier 2010 15:41
>>> À : CHATRAS Bruno RD-CORE-ISS
>>> Cc : [e-mail]
>>> Objet : Re: [martini] Proposed work
>>> split:tackletelephone-numberregistration first
>>>
>>> On the one hand, I agree we have to work on a general
>>> mechanism to enable the SP to provision IP PBXen as well as
>>> an efficient way for IP PBXen to register endpoints to an SP.
>>>
>>> On the other hand, are you willing to wait 3-5 years for the
>>> general mechanism? More especially so given the industry
>>> today is 99.9% E.164 numbers and needs a solution last year?
>>> This is a serious question: if service providers are saying,
>>> "This is going to be important, but we really do not need a
>>> solution in 3-5 years," then that informs our
>>> work: we can relax and engineer the perfect solution.
>>> However, almost all of the service providers I speak with
>>> say, "A solution to this problem is already a year late.  If
>>> we do not see something soon [2-3 months] we are going to
>>> codify and deploy the (admittedly broken) REGISTER method
>>> that we are already using, with or without the IETF.
>>> It would be nice if we could have a not-so-broken mechanism,
>>> but the market has lost its patience."
>>>
>>> Again, doing the E.164-only solution today does not mean we
>>> ignore the long-term problem.
>>>
>>> Does this work for you?
>>>
>>> On Jan 29, 2010, at 8:47 AM, Spencer Dawkins wrote:
>>>
>>>> Hi, Bruno,
>>>>
>>>> My apologies for not snapping when I saw your e-mail address - I'm
>>>> currently chairing three working groups, and things are getting a
>>>> little blurry (MEDIACTRL *really* needs to finish soon!).
>>>>
>>>> Thanks for the input - it's helpful.
>>>>
>>>> Spencer
>>>>
>>>> ----- Original Message ----- From:
>>> <[e-mail]>
>>>> To: <[e-mail]>; <[e-mail]>;
>>>> <[e-mail]
>>>>> ; <[e-mail]>
>>>> Cc: <[e-mail]>
>>>> Sent: Friday, January 29, 2010 7:39 AM
>>>> Subject: RE: [martini] Proposed work split:tackletelephone-
>>>> numberregistration first
>>>>
>>>>
>>>> Hi Spencer,
>>>>
>>>> I have seen you request on the sip-ops list where you noted that
>>>> MARTINI is not getting inputs from other operators (than  
>>>> CableLabs).
>>>> I'm actually representing a fixed and mobile operator
>>> (France Telecom
>>>> - Orange) and as you can guess from my previous posts we support a
>>>> REGISTER-based solution and believe that a solution
>>> restricted to Tel
>>>> URIs would be of limited interest.
>>>>
>>>> /BC
>>>>
>>>>
>>>>
>>>>> -----Message d'origine-----
>>>>> De : [e-mail]
>>>>> [mailto:[e-mail]] De la part de Spencer Dawkins
>>>>> Envoyé : jeudi 28 janvier 2010 22:59
>>>>> À : Brian Lindsay; Eric Burger; Dean Willis
>>>>> Cc : [e-mail]
>>>>> Objet : Re: [martini] Proposed work
>>>>> split:tackletelephone-numberregistration first
>>>>>
>>>>> Hi, Brian,
>>>>>
>>>>> Thanks for the quick feedback. I'm mostly asking if I'm
>>>>> reading where we are going correctly (I GOTTA get the draft
>>>>> minutes out from that call!).
>>>>>
>>>>> This is kind of twisty-little-passages-all-alike/different
>>>>> (for those of you that remember the "adventure" game in the
>>>>> early 1980s), but I'm trying to follow the chain. Where I
>>>>> thought we were, was that we didn't have a coherent story for
>>>>> how we get a call from outside the service provider, to the
>>>>> service provider, to the SIP-PBX, and I've heard a bunch of
>>>>> smart guys talk for a long time on a number of occasions
>>>>> about how that might work/not work, usually ending with "but
>>>>> if this was limited to E.164 numbers, a lot of these problems
>>>>> would go away".
>>>>>
>>>>> So I'm trying to laces comments from the call that I remember
>>>>> together, and see what the resulting tapestry looks like.
>>>>>
>>>>> Tell you what. I'll go work on draft minutes and stop typing
>>>>> e-mail, and we'll see if that works better :D
>>>>>
>>>>> Spencer
>>>>>
>>>>> ----- Original Message -----
>>>>> From: "Brian Lindsay" <[e-mail]>
>>>>> To: "Spencer Dawkins" <[e-mail]>; "Eric Burger"
>>>>> <[e-mail]>; "Dean Willis"
>>>>> <[e-mail]>
>>>>> Cc: <[e-mail]>
>>>>> Sent: Thursday, January 28, 2010 3:48 PM
>>>>> Subject: RE: [martini] Proposed work split:
>>>>> tackletelephone-numberregistration first
>>>>>
>>>>>
>>>>> Hi Spencer,
>>>>>
>>>>> I am not sure if this is going down the path that the
>>>>> actual register
>>>>> request uses a Tel: URI.
>>>>>
>>>>> If so, I don't see why that needs to be the case. The
>>>>> REGISTER itself
>>>>> can still be done per Martini-Shaken with a SIP URI
>>>>> representing the SIP
>>>>> PBX. In fact, I am not sure too much has to change with Martini-
>>>>> Shaken
>>>>> unless you want to enforce use of a Tel URI format for
>>> requests sent
>>>>> towards the SIP PBX.
>>>>>
>>>>> Thanks
>>>>>    Brian
>>>>>
>>>>>
>>>>>
>>>>> -----Original Message-----
>>>>> From: [e-mail] [mailto:[e-mail]]  
>>>>> On
>>>>> Behalf Of Spencer Dawkins
>>>>> Sent: Thursday, January 28, 2010 4:39 PM
>>>>> To: Eric Burger; Dean Willis
>>>>> Cc: [e-mail]
>>>>> Subject: Re: [martini] Proposed work split:
>>>>> tackletelephone-numberregistration first
>>>>>
>>>>> 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.
>>>>>
>>>>> 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?
>>>>>
>>>>> 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
>>>>>
>>>>
>>>> *********************************
>>>> This message and any attachments (the "message") are confidential
>>>> and intended solely for the addressees.
>>>> Any unauthorised use or dissemination is prohibited.
>>>> Messages are susceptible to alteration.
>>>> France Telecom Group shall not be liable for the message if
>>> altered,
>>>> changed or falsified.
>>>> If you are not the intended addressee of this message,
>>> please cancel
>>>> it immediately and inform the sender.
>>>> ********************************
>>>>
>>>
>>>
>>
>> *********************************
>> This message and any attachments (the "message") are confidential   
>> and
>> intended solely for the addressees.
>> Any unauthorised use or dissemination is prohibited.
>> Messages are susceptible to alteration.
>> France Telecom Group shall not be liable for the message if altered,
>> changed or falsified.
>> If you are not the intended addressee of this message, please  
>> cancel  it
>> immediately and inform the sender.
>> ********************************
>>
>
> _______________________________________________
> martini mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/martini
>