MARTINI WG Minutes IETF 77 Anaheim, California USA Working Group Home Page Jabber room: martini at jabber.ietf.org Chairs Bernard Aboba Spencer Dawkins Minute taker: David Hancock d.hancock@cablelabs.com Meeting Slot I Monday, March 22, 2010 1 PM – 3 PM Pacific Time Palos Verdes Room 1. Preliminaries (Bernard & Spencer) Topic Draft Time Discussion Leader Preliminaries Blue Sheets Note Takers Note Well Agenda bash Document Status none 10 min chairs Chair Slides Bernard Aboba: Encourage people to submit comments regarding GIN to the issue tracker. Keith Drage: • Not only tracker entries are comments -- anything that appears on the mailing list should also be considered a comment. • Group is moving too fast to allow sufficient review time, especially given 3GPP meeting conflicts. Bernard Aboba: In the WG last call and Call for Adoption notices, comments were solicited on the mailing list as well as in the issue tracker. So we don’t require that comments be submitted via the Issue tracker. With respect to milestones, we’re actually behind with respect to the milestones in the Charter by at least two months. Keith Drage: Due to meeting conflicts, etc, did not have an opportunity to contribute due to the schedule. Cullen Jennings: Words of praise for the current MARTINI process/progress. 2. Requirements (John Elwell & Hadriel Kaplan) Requirements http://tools.ietf.org/html/draft-elwell-martini-reqs 40 min John Elwell Requirements Slides John Elwell’s presentation on “Recent Issues” (slides 2 thru 5) … John Elwell: Issue # 16 – requirement for AOR extensibility is still open Keith Drage: Believe there should be a requirement to support private numbers John Elwell: Yes, issue 16 is being re-opened so solution can support extensibility. Bernard Aboba: What does extensibility mean – does it mean a new version of GIN (e.g. a different option tag)? Adam Roach: It means that GIN would not constrain the support of additional AOR forms. Hadriel Kaplan: The requirements doc should only state what is required, and we’ve always said we’re not required to support private numbers. Jon Peterson: It would be useful to explain somewhere why support of private numbers wasn’t included as a requirement. John Elwell: The issue is that if we open it up to support AOR forms beyond E.164 numbers, then we have to support domain routing. And domain routing has issues such as ambiguity of ownership, say when an enterprise user AOR has the domain of the SSP. These issues can be bypassed if we limit AORs to E.164-only, since E.164 numbers are globally unique and therefore routing is unambiguous. Jon Peterson: That information should be explicitly documented then. Bernard Aboba: Where do we add that text? Req’s doc or GIN draft? Jon Peterson: It should be documented in the requirements doc. Add something about domain routing concerns. (Agreed**) Keith Drage: E.164 numbers can be carried either in a Tel URI or a SIP URI containing a Tel URI. In the case of SIP URI there is still a domain name, so how does that avoid the problem you raised? Gonzalo Camarillo: The requirements document needs to be explicit – when referring to E.164 numbers are we talking about Tel or SIP URIs? (Agreed**) John Elwell introduces new issue – should there be a requirement to support Private numbers? John Elwell: Even without an explicit requirement, it may just work. Paul Kyzivat: What is the real requirement? Is it to support service numbers like 911, 411, etc? They aren’t E.164 numbers, and there isn’t general agreement on how they’re encoded as local numbers. John Elwell: This requirement is about support of private numbers for PBX extensions. Adopting this requirement would mean that the SSP network must be able to route a call between PBXs serving a single enterprise based on the private number of the called enterprise user (not the public E.164-based AOR). Keith Drage: Agreed. In addition this requirement includes the case where an enterprise has both PBX and Centrex users that want to call each other via abbreviated dialing. Adam Roach: Can we assume that there is a mechanism to route inter-PBX calls directly, thus bypassing the SSP network? If we require the SSP to route these private calls then it breaks enterprise user mobility. Keith Drage: Unfortunately, the bypass option doesn’t work for the Centrex-to-PBX case. Adam Roach: If we have to support this, then it’ll destroy user mobility. Hadriel Kaplan: We don’t have to support Centrex. Rather, Centrex is an example showing why the SSP has to support private number routing. Hadriel thinks it will actually work, and doesn’t see the problem Adam has with mobility. Also, Hadriel doesn’t think this needs to be a requirement. Spencer Dawkins (as WG chair): Let’s take this to the list. Hadriel Kaplan’s presentation on “Current Problems” (slides 6 thru 8) … Hadriel Kaplan: One of the problems with current mechanisms is there is no explicit indicator that this registration (from the SIP-PBX) is any different than normal RC3261 registration. Keith Drage: Instead of using an indicator, current solutions like the one defined for IMS use configured data in the SSP to indicate that the register is coming from a PBX. Even if we add an option tag, the SSP will still need some configuration data to indicate this is a PBX registration, so it isn’t clear how the addition of the option tag adds any value. Request from Hadriel asking Keith to submit to list why SSP configuration data is still needed when an indicator is used. Richard Shockey: The need for an option tag was the primary driver for bringing this problem to MARTINI. 3. Solution Updates 3.1 Adam Roach – GIN draft presentation MARTINI with Globally Identifiable Numbers http://tools.ietf.org/html/draft-roach-martini-gin 30 min Adam Roach GIN Slides Adam Roach: The risk in adding a Proxy-Require option tag is that proxies in the signaling chain that don’t need to do anything special with this extension but don’t recognize the option-tag will reject the request. The risk is mitigated in this case since a REGISTER request traverses a tightly constrained set of proxies that are owned by and under the control of the serving SSP. Dean Willis: Is the Proxy-Require option tag or the new contact parameter required by intermediaries? Adam Roach: It’s both -- the option tag says I’m using a new parameter in my Contact header, and the ‘bnc’ parameter is that parameter. You could have multiple contacts, only some of which had the ‘bnc’ parameter. Adam Roach: One of the restrictions of using this mechanism is that the PBX can’t put anything in the user portion of the Contact URI. Therefore, the PBX will have to use Contact URI parameters to carry any data that it wants returned in subsequent incoming requests. Adam Roach: There is an open issue regarding use of the user=phone parameter in the REGISTER Contact header. The issue being -- is it valid for the PBX to include a “user=phone” parameter in a contact URI that has no user portion? Here are the resolution options… 1. Keep mechanism as-is (i.e., let PBX choose whether it needs “user=phone”) 2. Forbid “user=phone” on “bnc” URIs, and specify that the SSP must add “user=phone” 3. Forbid “user=phone” altogether Henning Schulzrinne: The solution should be close to what is implemented. Do what is pragmatic and simple, and avoid creating new error conditions; i.e. a vote for option 1. Christer Holmberg: Are you allowed to have “user=phone” without a user part? John Elwell: Didn’t understand that it was OK for the PBX not to include user=phone. Which means there’s a 4th option – which is to require inclusion of user=phone. Hadriel Kaplan: There is talk of using new parameters instead of user=phone, such as user=fax. For example, the originator of a call wants to target the request to a FAX machine. Adam Roach: One solution for this would be to register FAX URIs with a separate REGISTER request. Paul Kyzivat: Has anyone actually proposed defining a user=fax parameter? If not, we could consider it out-of-scope. Hadriel Kaplan: Want to avoid having to open GIN up every time someone adds a new parameter, so we need to think about this. Bernard Aboba: Any other contact URI parameters added by the PBX need to be echoed back in subsequent requests. Jon Peterson: In this case the ‘bnc’ parameter is the most significant parameter carried in the Contact URI, and its presence should remove any confusion over the use and meaning of “user=phone” in the Contact URI (i.e., support for option-1). HUM – does group favor option-1? HUM results: in favor of option of #1. Keith Drage: Object to taking a HUM on something that isn’t adopted as a WG item. Cullen Jennings: Believes the HUM is OK in this case – take the temperature of the room on a specific technical point to provide input to draft author. Keith Drage: Some service providers have voiced their opposition to the GIN solution on the list. Richard Shockey: Agreed, although there has also been support for GIN from cable operators. Adam Roach introduces new open issue – Is there a need to signal the list of enterprise phone numbers between PBX and SSP network? David Schwartz: Would it be possible to propose a mechanism without mandating it? Spencer Dawkins (as WG chair): Haven’t seen people saying that we have to have this. Anyone who feels strongly that this is needed should write their own draft. It’s not worth trying to solve this as part of GIN because of the “size of response” issue. Hadriel Kaplan: People that need this information have other ways to get it. Keith Drage: Need to understand the root requirement, since that may dictate what solution applies. For example, if the requirement is to provide a way for the SSP network to tell the PBX that an enterprise user is no longer registered, then an extension to the reg-event package may be a better solution. Jon Peterson: It may be odious (onerous?) to support this, but we should do it. If we decide to not to, then we need to put a warning in GIN that it isn’t supported. Adam Roach: To be semantically consistent with the way REGISTER works today, the list would be communicated as part of REGISTER transaction. Any solution we come up with can probably be retrofitted on top of the GIN solution. John Elwell: Supports documenting the solution as a separate draft using a mechanism outside of registration (e.g., reg-event package). If we do use REGISTER, then put the list in the REGISTER request. Hadriel Kaplan: With the GIN solution you’re registering a template, not the actual AORs. Martin Thompson: Could we use indirection to solve the response-size problem? Instead of sending the registered AORs in the response, send a pointer to them. Christer Holmberg: Once a PBX is registered can I add/remove AORs from the list? Adam Roach: There is a hole in the current GIN text related to this. Will resolve in the next version Dale Worley: Agree with Hadriel that GIN is registering a template. Therefore, if the SSP assigns a new number to an already-registered PBX, then it is immediately available for use, you don’t have to wait for the next REGISTER. Adam Roach: New topic – Outbound, Service Route & Path need to be looked at with respect to GIN. Adam Roach: The intermediaries originally could assume that REGISTER was for the single AOR in the To: header. Are there any impacts or security concerns due to fact that now we’re registering multiple AORs? Bernard Aboba: How many of these pending issues can we resolve by Friday? Could we spin anther version of the draft this week for review at the Friday meeting? Also, can we get volunteers to review potential impacts to Outbound, Service Route, and Path? Cullen: Ask Francois Audet to review the document relating to Outbound. Will contact Francois on this, and will work offline to get volunteers to look at Service Route and Path. Hadriel Kaplan: Request that MARTINI mandate support of Path. Adam Roach: If SIP-PBX wants to put an FQDN in the domain of the Contact URI, then it needs to support Path to convey PBX IP address. MARTINI WG Meeting Slot II Friday, March 26, 2010 1415 - 1515 Pacific Time California D 4. Preliminaries Topic Draft Time Discussion Leader Preliminaries Blue Sheets Note Takers Note Well Agenda bash Document Status none 10 min Chairs Chair Slides (Friday Session) 5. GIN Update GIN Update http://tools.ietf.org/html/draft-roach-martini-gin 10 min Adam Roach Adam Roach’s presentation of new version of GIN draft: GIN Update Slides - Provided summary of updates. TRAC Issue #7-10 addressed in the -02 update. Need (external?) security analysis of interaction between Path, Outbound and Service Route with multiple AORs in a single REGISTER. Issue #14 requires fixes to examples. - No comments received so far relating to the -02 update (submitted yesterday). 6. Path and Service-Route Path and Service Route http://tools.ietf.org/html/draft-roach-martini-gin 10 min Dean Willis Dean Willis’ presentation on security considerations on Path and Service-Route Path and Service Route 1. GIN effectively registers multiple AORs. 2. All AORs will have same path, Service-Route. 3. If Service-Route invokes registrar-side services, all users on PBX will get the same services invoked. Otherwise, it should “just work”. There may be an issue between Service Route and Outbound Keith Drage: Service Route works for IMS implicit registration, which is different than the registration procedure proposed by GIN. Hadriel Kaplan: Although IMS and GIN registration procedures differ, they are the same with respect to Service Route; i.e., they are both registering multiple AORs with a single REGISER transaction. 7. Requirements Analysis Analysis of GIN against Requirements http://tools.ietf.org/html/draft-ietf-martini-reqs http://tools.ietf.org/html/draft-roach-martini-gin 30 min Adam Roach John Elwell John Elwell’s presentation on evaluation of GIN according to requirements in MARTINI requirements draft Requirements Analysis Slides John Elwell: Requirement 17 duplicates Requirement 5 and will be removed from the requirements document. DES4 is difficult to quantify and a proposal has been made to remove it. Otherwise, GIN appears to satisfy all the requirements. Christer Holmberg: Has a problem with REQ16 – the GRUU requirement. Dale Worley: Clarified this requirement. It doesn’t require support for GRUU, only that the solution should not constrain the PBX from assigning GRUUs to its UAs in the usual way. Paul Kyzivat: This requirement is also about addressing the fact that the SIP-PBX may not itself have a globally unique address, and therefore must get some help from the SSP network to provide a globally unique address. Dale Worley: must allow the SIP-PBX to provide the UAs with GRUUs as defined in the GRUU RFC. John Elwell: Please post clarifying updates to the list. 8. Discussion and Wrapup Wrapup – Hums and Next Steps None 10 min Chairs and ADs Adam Roach: What are the next steps on GIN? Bernard Aboba: We had a Call for Adoption on the GIN document, which ended on March 19, 2010. Adam Roach: We did? (looks at laptop). Oh yes! I forget about that. I even replied to the thread. Bernard Aboba: We will go over the replies to the Call for Adoption and will summarize the outcome on the MARTINI WG mailing list.