Re: [martini] Proposed work split:tackletelephone-numberregistration first

["Richard Shockey" <[e-mail]>]

The latter ... as far as I've able to determine

-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On Behalf
Of DRAGE, Keith (Keith)
Sent: Friday, January 29, 2010 3:16 PM
To: Eric Burger; [e-mail]
Cc: [e-mail]
Subject: Re: [martini] Proposed work
split:tackletelephone-numberregistration first

Is the market today 100% tel URIs or is it 100% telephone numbers
masquerading as SIP URIs?

regards

Keith

> -----Original Message-----
> From: [e-mail]
> [mailto:[e-mail]] On Behalf Of Eric Burger
> Sent: Friday, January 29, 2010 2:41 PM
> To: [e-mail]
> Cc: [e-mail]
> Subject: 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.
> > ********************************
> >
>
> _______________________________________________
> martini mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/martini
>
_______________________________________________
martini mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/martini