Re: [martini] Proposed work split: tackletelephone-numberregistration first
"Brian Lindsay" <blindsay@nortel.com> Thu, 28 January 2010 21:48 UTC
Return-Path: <BLINDSAY@nortel.com>
X-Original-To: martini@core3.amsl.com
Delivered-To: martini@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 911723A68F4 for <martini@core3.amsl.com>; Thu, 28 Jan 2010 13:48:30 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.297
X-Spam-Level:
X-Spam-Status: No, score=-6.297 tagged_above=-999 required=5 tests=[AWL=0.302, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0gynaHgiO3rR for <martini@core3.amsl.com>; Thu, 28 Jan 2010 13:48:28 -0800 (PST)
Received: from zrtps0kp.nortel.com (zrtps0kp.nortel.com [47.140.192.56]) by core3.amsl.com (Postfix) with ESMTP id 6E6573A67FC for <martini@ietf.org>; Thu, 28 Jan 2010 13:48:28 -0800 (PST)
Received: from zcarhxm1.corp.nortel.com (zcarhxm1.corp.nortel.com [47.129.230.97]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id o0SLm7E26292; Thu, 28 Jan 2010 21:48:07 GMT
x-mimeole: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Date: Thu, 28 Jan 2010 16:48:00 -0500
Message-ID: <09B7DBFE70A9E24BBB21689DAD3A06141C49D25F@zcarhxm1.corp.nortel.com>
In-Reply-To: <130895FDE1B4488C82158D051A1D94D9@china.huawei.com>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [martini] Proposed work split: tackletelephone-numberregistration first
Thread-Index: AcqgYnuGTtSIFAYXTVqhNn6p5FaPNgAADcYQ
References: <2118E1E7-735B-4829-B114-D524E5561E0F@softarmor.com><D890DEF3-37DF-462B-955A-94005E1808B5@standardstrack.com> <130895FDE1B4488C82158D051A1D94D9@china.huawei.com>
From: Brian Lindsay <blindsay@nortel.com>
To: Spencer Dawkins <spencer@wonderhamster.org>, Eric Burger <eburger@standardstrack.com>, Dean Willis <dean.willis@softarmor.com>
Cc: martini@ietf.org
Subject: Re: [martini] Proposed work split: tackletelephone-numberregistration first
X-BeenThere: martini@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Discussion of en-mass SIP PBX registration mechanisms <martini.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/martini>, <mailto:martini-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/martini>
List-Post: <mailto:martini@ietf.org>
List-Help: <mailto:martini-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/martini>, <mailto:martini-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 28 Jan 2010 21:48:30 -0000
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: martini-bounces@ietf.org [mailto:martini-bounces@ietf.org] On Behalf Of Spencer Dawkins Sent: Thursday, January 28, 2010 4:39 PM To: Eric Burger; Dean Willis Cc: martini@ietf.org 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:bob@biloxi.com) 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" <eburger@standardstrack.com> To: "Dean Willis" <dean.willis@softarmor.com> Cc: <martini@ietf.org> 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:eburger@neustar.biz" into "sip:5350@pbx.example.net " > 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 >> martini@ietf.org >> https://www.ietf.org/mailman/listinfo/martini > > _______________________________________________ > martini mailing list > martini@ietf.org > https://www.ietf.org/mailman/listinfo/martini _______________________________________________ martini mailing list martini@ietf.org https://www.ietf.org/mailman/listinfo/martini
- Re: [martini] Proposed work split: tackle telepho… Eric Burger
- [martini] Proposed work split: tackle telephone-n… Dean Willis
- Re: [martini] Proposed work split: tackle telepho… Sanjay Sinha (sanjsinh)
- Re: [martini] Proposed work split: tackle telepho… Elwell, John
- Re: [martini] Proposed work split: tackle telepho… Dean Willis
- Re: [martini] Proposed work split: tackle telepho… Doug Sauder
- Re: [martini] Proposed work split: tackle telepho… bruno.chatras
- Re: [martini] Proposed work split: tackle telepho… Hadriel Kaplan
- Re: [martini] Proposed work split: tackle telepho… Hadriel Kaplan
- Re: [martini] Proposed work split: tackle telepho… Hadriel Kaplan
- Re: [martini] Proposed work split: tackle telepho… Hadriel Kaplan
- Re: [martini] Proposed work split: tackle telepho… Paul Kyzivat
- Re: [martini] Proposed work split: tackle telepho… Eric Burger
- Re: [martini] Proposed work split: tackle telepho… Eric Burger
- Re: [martini] Proposed work split: tackle telepho… Doug Sauder
- Re: [martini] Proposed work split: tackle telepho… Spencer Dawkins
- Re: [martini] Proposed work split: tackletelephon… Brian Lindsay
- Re: [martini] Proposed work split: tackletelephon… Spencer Dawkins
- Re: [martini] Proposed work split: tackle telepho… DRAGE, Keith (Keith)
- Re: [martini] Proposed work split: tackle telepho… Adam Roach
- Re: [martini] Proposed work split: tackle telepho… Adam Roach
- Re: [martini] Proposed work split: tackle telepho… eburger
- Re: [martini] Proposed work split: tackle telepho… Elwell, John
- Re: [martini] Proposed work split: tackle telepho… bruno.chatras
- Re: [martini] Proposed work split:tackletelephone… bruno.chatras
- Re: [martini] Proposed work split:tackletelephone… Spencer Dawkins
- Re: [martini] Proposed work split: tackle telepho… Paul Kyzivat
- Re: [martini] Proposed work split: tackle telepho… Paul Kyzivat
- Re: [martini] Proposed work split: tackle telepho… Paul Kyzivat
- Re: [martini] Proposed work split:tackletelephone… Eric Burger
- Re: [martini] Proposed work split: tackle telepho… Spencer Dawkins
- Re: [martini] Proposed work split: tackle telepho… Spencer Dawkins
- Re: [martini] Proposed work split: tackle telepho… Paul Kyzivat
- Re: [martini] Proposed work split:tackle telephon… Spencer Dawkins
- Re: [martini] Proposed work split:tackle telephon… Adam Roach
- Re: [martini] Proposed work split:tackle telephon… Paul Kyzivat
- Re: [martini] Proposed work split: tackle telepho… Adam Roach
- Re: [martini] Proposed work split:tackletelephone… bruno.chatras
- Re: [martini] Proposed work split:tackletelephone… Adam Roach
- Re: [martini] Proposed work split: tackle telepho… Elwell, John
- Re: [martini] Proposed work split: tackle telepho… Elwell, John
- Re: [martini] Proposed worksplit: tackle telephon… Brian Lindsay
- Re: [martini] Proposed work split: tackle telepho… Hadriel Kaplan
- Re: [martini] Proposed worksplit: tackle telephon… Richard Shockey
- Re: [martini] Proposed work split: tackle telepho… Hadriel Kaplan
- Re: [martini] Proposed work split: tackle telepho… Hadriel Kaplan
- Re: [martini] Proposed work split:tackletelephone… DRAGE, Keith (Keith)
- Re: [martini] Proposed work split:tackletelephone… Richard Shockey
- Re: [martini] Proposed work split:tackletelephone… Xavier Marjou
- Re: [martini] Proposed work split:tackletelephone… Christer Holmberg
- Re: [martini] Proposed work split:tackletelephone… DRAGE, Keith (Keith)
- Re: [martini] Proposed work split: tackle telepho… Adam Roach
- Re: [martini] Proposed work split:tackletelephone… Eric Burger
- Re: [martini] Proposed worksplit:tackletelephone-… Spencer Dawkins
- Re: [martini] Proposed worksplit:tackletelephone-… Eric Burger
- Re: [martini] Proposed work split: tackle telepho… Dean Willis
- Re: [martini] the MARTINI conundrum Bernard Aboba
- Re: [martini] Proposed work split: tackle telepho… Dean Willis
- Re: [martini] Proposed work split: tackle telepho… Dean Willis
- Re: [martini] Proposed work split: tackle telepho… Spencer Dawkins
- Re: [martini] Proposed work split: tackle telepho… Paul Kyzivat
- Re: [martini] Proposed work split: tackle telepho… Paul Kyzivat
- Re: [martini] Proposed work split: tackle telepho… Paul Kyzivat
- Re: [martini] Proposed work split: tackle telepho… Bernard Aboba
- Re: [martini] Proposed work split: tackle telepho… Dean Willis
- Re: [martini] Proposed work split: tackle telepho… Dean Willis
- Re: [martini] Proposed work split: tackle telepho… Dean Willis
- Re: [martini] Proposed work split: tackle telepho… Dean Willis
- Re: [martini] Proposed work split: tackle telepho… Hadriel Kaplan
- Re: [martini] Proposed work split: tackle telepho… Dean Willis
- Re: [martini] Proposed work split: tackle telepho… Hadriel Kaplan
- Re: [martini] Proposed work split: tackle telepho… Christer Holmberg
- Re: [martini] Proposed work split: tackle telepho… Paul Kyzivat
- Re: [martini] Proposed work split: tackle telepho… Hadriel Kaplan
- Re: [martini] Proposed work split: tackle telepho… Paul Kyzivat
- Re: [martini] Proposed work split: tackle telepho… Dean Willis
- Re: [martini] Proposed work split: tackle telepho… Dean Willis
- Re: [martini] Proposed work split: tackletelephon… DOLLY, MARTIN C (ATTLABS)
- Re: [martini] Proposed work split: tackletelephon… Dean Willis
- Re: [martini] Proposed work split: tackle telepho… Christer Holmberg
- Re: [martini] Proposed work split: tackle telepho… Christer Holmberg
- Re: [martini] Proposed work split: tackle telepho… Christer Holmberg
- Re: [martini] Proposed work split: tackle telepho… Elwell, John
- Re: [martini] Proposed work split: tackle telepho… Christer Holmberg
- Re: [martini] Proposed work split: tackle telepho… Elwell, John
- Re: [martini] Proposed work split: tackle telepho… Hadriel Kaplan
- Re: [martini] Proposed work split: tackle telepho… Christer Holmberg
- Re: [martini] Culling tel URIs Adam Roach
- Re: [martini] Proposed work split: tackle telepho… Elwell, John
- Re: [martini] Proposed work split: tackle telepho… Richard Shockey
- Re: [martini] Proposed work split: tackle telepho… Paul Kyzivat
- Re: [martini] Proposed work split: tackle telepho… Paul Kyzivat
- [martini] Culling tel URIs (was: Re: Proposed wor… Spencer Dawkins
- Re: [martini] Culling tel URIs Richard Shockey
- Re: [martini] Proposed work split: tackletelephon… Richard Shockey
- Re: [martini] Culling tel URIs Spencer Dawkins
- Re: [martini] Culling tel URIs Paul Kyzivat
- Re: [martini] Culling tel URIs Adam Roach
- Re: [martini] Culling tel URIs Spencer Dawkins
- Re: [martini] Culling tel URIs Paul Kyzivat
- Re: [martini] Proposed work split: tackle telepho… Paul Kyzivat
- Re: [martini] Proposed work split: tackle telepho… Paul Kyzivat
- Re: [martini] Proposed work split: tackle telepho… Christer Holmberg
- Re: [martini] Proposed work split: tackle telepho… Dean Willis
- Re: [martini] Proposed work split: tackle telepho… Dean Willis
- Re: [martini] Culling tel URIs (was: Re: Proposed… Dean Willis
- Re: [martini] Culling tel URIs Dean Willis
- Re: [martini] Proposed work split: tackletelephon… Dean Willis
- Re: [martini] Culling tel URIs Dean Willis
- Re: [martini] Culling tel URIs Dean Willis
- Re: [martini] Proposed work split: tackle telepho… Elwell, John
- Re: [martini] Culling tel URIs (was: Re: Proposed… Spencer Dawkins
- Re: [martini] Proposed work split: tackle telepho… DRAGE, Keith (Keith)
- Re: [martini] Culling tel URIs Paul Kyzivat
- Re: [martini] Culling tel URIs Adam Roach
- Re: [martini] Culling tel URIs Spencer Dawkins
- Re: [martini] Proposed work split: tackletelephon… Richard Shockey
- Re: [martini] Proposed work split: tackle telepho… Elwell, John
- Re: [martini] Proposed work split:tackle telephon… Richard Shockey