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

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

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