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

["DRAGE, Keith (Keith)" <[e-mail]>]

Exactly - that is what I understood too - so they all tend to be encumbered by domain names.

And lots of them use things like [e-mail] internally as well if I understand correctly, which are neither fish nor fowl.

So arguing that we need a solution for tel URIs because that is what is currently supported is incorrect.

regards

Keith

> -----Original Message-----
> From: Richard Shockey [mailto:[e-mail]]
> Sent: Friday, January 29, 2010 9:03 PM
> To: DRAGE, Keith (Keith); 'Eric Burger';
> [e-mail]
> Cc: [e-mail]
> Subject: RE: [martini] Proposed work
> split:tackletelephone-numberregistration first
>
> 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
>
>