[martini] GRUU (was RE: Draft minutes of the IETF 78 MARTINI WG meeting)
Brian Lindsay <brian.lindsay@genband.com> Wed, 25 August 2010 18:50 UTC
Return-Path: <brian.lindsay@genband.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 CF8A93A68F3 for <martini@core3.amsl.com>; Wed, 25 Aug 2010 11:50:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.298
X-Spam-Level:
X-Spam-Status: No, score=-5.298 tagged_above=-999 required=5 tests=[AWL=-1.300, BAYES_50=0.001, HTML_MESSAGE=0.001, 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 C1DvG+n+WO6y for <martini@core3.amsl.com>; Wed, 25 Aug 2010 11:50:28 -0700 (PDT)
Received: from exprod7og105.obsmtp.com (exprod7og105.obsmtp.com [64.18.2.163]) by core3.amsl.com (Postfix) with ESMTP id 05F4B3A687F for <martini@ietf.org>; Wed, 25 Aug 2010 11:50:27 -0700 (PDT)
Received: from source ([63.149.188.88]) (using TLSv1) by exprod7ob105.postini.com ([64.18.6.12]) with SMTP ID DSNKTHVmFB+uwNRZxwPVe+xkx9tRK/kQ8i8D@postini.com; Wed, 25 Aug 2010 11:51:01 PDT
Received: from owa.genband.com ([172.16.21.97]) by mail.genband.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Wed, 25 Aug 2010 13:50:19 -0500
Received: from GBPLMAIL01.genband.com ([fe80::70bf:29d1:2cfe:42b5]) by GBEX01.genband.com ([fe80::8d5f:3299:f2:285c%14]) with mapi; Wed, 25 Aug 2010 13:50:18 -0500
From: Brian Lindsay <brian.lindsay@genband.com>
To: Bernard Aboba <bernard_aboba@hotmail.com>, "martini@ietf.org" <martini@ietf.org>
Thread-Topic: GRUU (was RE: [martini] Draft minutes of the IETF 78 MARTINI WG meeting)
Thread-Index: ActDCPrYKc9tR1hISSS68JTSczq8CABdHRUQ
Date: Wed, 25 Aug 2010 18:50:15 +0000
Message-ID: <F1A0ED6425368141998E077AC43334E414EA7CBC@gbplmail01.genband.com>
References: <BLU137-DS1702DB8E15AB61E03417A493820@phx.gbl>
In-Reply-To: <BLU137-DS1702DB8E15AB61E03417A493820@phx.gbl>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Content-Type: multipart/alternative; boundary="_000_F1A0ED6425368141998E077AC43334E414EA7CBCgbplmail01genba_"
MIME-Version: 1.0
X-OriginalArrivalTime: 25 Aug 2010 18:50:19.0235 (UTC) FILETIME=[5D550330:01CB4486]
X-TM-AS-Product-Ver: SMEX-8.0.0.4160-6.500.1024-17596.001
X-TM-AS-Result: No--26.880400-5.000000-31
X-TM-AS-User-Approved-Sender: No
X-TM-AS-User-Blocked-Sender: No
Subject: [martini] GRUU (was RE: Draft minutes of the IETF 78 MARTINI WG meeting)
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: Wed, 25 Aug 2010 18:50:43 -0000
Hi, Regarding GRUU, I was unable to attend the IETF 78 WG Meeting, but I would like to object to the outcome regarding mandating support for GRUU on the SSP. There was discussion of the topic on the list in July, and I believe there was no consensus on mandating GRUU at that time, so I think the topic is one that could be valid for the broader set of list participants to consider. My view is that is that it is appropriate for the GIN draft to define how GRUU interacts with the GIN registration mechanism, but there does not need to be a coupling/dependency such that an implementer of the GIN registration mechanism is also required to implement GRUU. In short - I think what is in the -05 draft is fine. Why? * Most existing SIP Trunking deployments do not use/require GRUU's. The main driver for the martini work has always been about aligning on the semantics of the registration request and request uri population. This can be done without introducing a dependency on GRUU implementation. * The GRUU RFC is still an optional mechanism as far as SIP is concerned * A baseline set of services can be provided without requiring GRUU. For example, the current draft of SIP Connect 1.1 ( http://www.sipforum.org/component/option,com_docman/task,cat_view/gid,84/Itemid,75/ ) has a baseline call transfer capability defined that uses re-invites and doesn't use REFER. REFER-based transfer is optional, as is the usage of out-of-dialog REFER. (The language actually discourages use of REFER due to billing risks/considerations). The discussions on temporary GRUUs for privacy also seem to be exceeding the scope of the original focus of MARTINI and the requirements document. There was never an intent for MARTINI to define a privacy solution for SIP PBXs. Regards Brian ----------------------------------------- Brian Lindsay Sr. Architect, System Architecture GENBAND +1.613.763.3459 brian.lindsay@genband.com From: martini-bounces@ietf.org [mailto:martini-bounces@ietf.org] On Behalf Of Bernard Aboba Sent: Monday, August 23, 2010 5:21 PM To: martini@ietf.org Subject: [martini] Draft minutes of the IETF 78 MARTINI WG meeting MARTINI WG IETF 78 Mintes Chairs: Bernard Aboba <bernard_aboba at hotmail.com> Spencer Dawkins <spencer at wonderhamster.org> Thursday, July 29, 2010 09:00 - 11:30 2.1 Colorado Room 09:00 - 9:10, Preliminaries Note Well Note Takers: Paul Kyzivat and Cullen Jennings Jabber scribe Agenda bash Document Status Solution Updates MARTINI with Globally Identifiable Numbers, Adam Roach (40 minutes) http://tools.ietf.org/html/draft-ietf-martini-gin Went over changes and open issues: Ticket 48 changes requirements but no impact on GIN. There was discussion of process. This is about appendix A which is analysis of requirements. Adam proposes to align the appendix A by changing text that quotes the requirements doc to be consistent with the final version of the requirements doc. Proposal by Cullen and Hadriel to just drop appendix A. John and Adam are happy to remove it. Keith would like it to remain. So decision is to keep it. Agreed to change the text in Appendix A so that it matches the text in requirements specification. No objection to Issue 4 and Issue 5. Ticket 49 - nits. Changed. Keith requested consistency on a number of other nits. He was asked to report them on the list. He agreed. Ticket 50: propose to update inline with suggestions in the ticket. Query made if any objections to the above tickets. There were none. Ticket 51: ticket submitter proposed one resolution, Adam proposes to do contrary - reject BNC contact with user part. Discussion of pros/cons of the alternative. Keith and Cullen argued for being strict, and Hadriel agreed. That approach (consistent with the slide) was agreed: incorrect URI will cause rejection. Ticket 54: Keith objected to use of "non-bnc URI" without definition. Adam agrees to fix that, make it clear what is intended. Everywhere we have BNC before another term, it needs to be defined. On this issue in #54 reword to be "URI without a BNC" Ticket 55: regarding prohibition of "bnc" parameter in reg event bodies. Questions/objections of how this prohibition applies to reg event extensions. It was agreed to modify the proposed text - "after "bnc" parameter" add "in an extension". Ticket 56: about security review. Discussion of what the error code should be. Adam proposes using an existing 500 class response to indicate an overload condition. Agreed on Proposal #1 and #2. Will return an existing 500 class response. Ticket 57: Are GRUUs mandatory? Three options offered - completely optional; mandatory to implement & optional to use; mandatory to use martini at all. Hadriel argued at length for optionality. Cullen argued strongly for mandatory to implement for public GRUU. There was clarification that these requirements are on the SSP. There was consensus that it be mandatory for an SSP implementing gin to supply a public gruu when requested by the registering PBX. Then discussion moved to temp GRUU. Debate among Cullen and Hadriel. Cullen argues for support of confidentiality - need to support anonymous calls. He would accept some other mechanism than temp GRUU if someone can propose it for inclusion in this draft. Andrew Allen supports for fear that some other system likely to mangle public GRUUs. Hadriel asserted that he sells boxes that do this without use of temp GRUU. Bernard Aboba noted that GRUU support (both public and temporary) is covered by REQ16 in the requirements document: REQ16 - The mechanism MUST allow the SIP-PBX to provide its UAs with public or temporary Globally Routable UA URIs (GRUUs) [RFC5627]. However, this requirement is phrased as "MUST allow" and only applies to PBXes, not SSPs. John Ewell was concerned that that mandating support by SSPs might raise the bar too high and discourage SSPs from implementing GIN. Keith was concerned that we are having a requirements document in the context of the gin draft - that people who want new requirement should be making a bis version of the requirements document. T here was suggestion to split the ticket, into the part about pub gruu and a separate one about private calls. Request for Cullen to file that ticket. Proposal for interested parties to go off between now and next session at 3 and try to figure this out. Will pick it up then. Individual Submissions (60 minutes) Other Logical Identifier Values (OLIVE), Hadriel Kaplan http://tools.ietf.org/html/draft-kaplan-martini-with-olive Hadriel gave summary. There were a number of clarifying questions. John wanted to know if this is service that SSPs would want to provide. Adam observed that its perfectly reasonable to assume the SSP could host your own domain name and then arbitrary user names within that domain name. Then got on to local numbers. Cullen suggests splitting this into separate drafts for alphanumeric user names and local numbers because. About 10 people in the room thought it was worth solving the "Bob@example.com" problem - alphanumeric user names. This is simply guidance to hadriel about his authoring of private drafts. There was a sughgestion to work on two separate documents: one for email-style addresses (e.g. "bob@example.com') and the other for numeric addresses (but not E.164 numbers): "1234". MARTINI Event Package for Registration (VERMOUTH), Hadriel Kaplan http://tools.ietf.org/html/draft-kaplan-martini-vermouth Hadriel gave an overview. Normal subscription get routed to the PBX. Presented two alternatives - use reg-event with extensions or a new event package. John Elwell questioned if SIP is right for this. Andrew Allen also preferred new event package because semantics are different. Cullen Jennings gave another reason - authorization rules are different. There seemed to be general support for a new event package. Thursday, July 29, 2010 15:10 - 16:10 This session was just to clear up the temp-gruu issue. People had worked in the intervening time and had proposed text which was displayed on a slide. After brief discussion, the room was polled about this new text. Result was 12-0 in favor, which was considered to be consensus. The group then adjourned.
- [martini] Draft minutes of the IETF 78 MARTINI WG… Bernard Aboba
- [martini] GRUU (was RE: Draft minutes of the IETF… Brian Lindsay
- Re: [martini] GRUU (was RE: Draft minutes of the … Bernard Aboba
- Re: [martini] GRUU (was RE: Draft minutes of the … Brian Lindsay
- Re: [martini] GRUU (was RE: Draft minutes of the … Paul Kyzivat
- Re: [martini] GRUU (was RE: Draft minutes of the … Brian Lindsay