MARTINI WG Virtual Interim Meeting #1 – pre-IETF 77 Chairs: Bernard Aboba Spencer Dawkins The chairs thank David Hancock and John Elwell, our note-takers for this session. Date: Tuesday Jan 7th, 2009 Time: 11:00 AM – 1:30 PM PST Attendees: Bernard Aboba, Mary Barnes, Ben Campbell, Spencer Dawkins, Keith Drage, John Elwell, David Hancock, Ernst Horvath, Andy Hutton, Cullen Jennings, Alan Johnston, Hadriel Kaplan, Krisztian Kiss, Paul Kyzivat, Matt Lepinski, Brian Lindsay, Michael Lunsford, David Middleton, Jon Peterson, Michael Procter, Adam Roach, Dan Romascanu, Christian Schmdit, Richard Shockey, Rifaat Shekh-Yusef, Darryl Sladden, Robert Sparks, James Swan, Adam Uzelac, Dean Willis. Slide Presentations: http://www.drizzle.com/~aboba/MARTINI/Jan-Interim/ Jabber room: martini at jabber.ietf.org (Please join) Dial in Audioconference and WebEx details: http://www.ietf.org/mail-archive/web/martini/current/msg00029.html Agenda bashing No comments. Problem Statement & Existing Deployed Solutions How We Got Here (Spencer Dawkins) Keith Drage pointed out that the problem Spencer described is not a problem just for >>small<< PBXs, and that what 3GPP/TISPAN did was to ensure as much commonality as possible between subscription-based and peering models. Darryl Sladden: Not all implementations use REGISTER, some use static IP addresses to establish reachability. PBX Registration Problems (Hadriel Kaplan) http://www.ietf.org/internet-drafts/draft-kaplan-martini-mixing-problems-00.txt Hadriel pointed out that his problem statement draft was focused specifically on problems associated with current practice of REGISTER usage, and asked that other participants also send information about problems they’ve encountered (the draft is documenting Hadriel’s own experience, and Hadriel hasn’t seen input from other participants yet). Keith Drage: regarding issues related to PAU header (response growth, config-mismatch recovery, etc), is there a requirement to signal the registered enterprise AORs across the PBX<->SP-network interface? Also, IMS uses the reg-event package to convey these identities from SP network to IP-PBX, not the PAU. Hadriel said that the PAU mismatch problem doesn’t affect interoperability, but does affect the ability to troubleshoot AORs that the SIP-PBX thinks are registered, but which aren’t registered at the service provider. Keith Drage: PAU just says these AORs are associated with that particular REGISTER request - not a list of what is actually registered. Keith Drage: owenership problem surely applies to peering-based too? (Hadriel agrees) Keith Drage: so why is it a MARTINI problem rather than SPEERMINT? Adam Roach: it is a problem arising from bulk registrations – multiple normal REGISTERs each give you a token that you can use to disambiguate users, but bulk registration doesn’t give you a per-user token. Keith Drage: but if you don't replace the Request-URI? Paul Kyzivat said that we may just have to retarget and use Route headers. Spencer Dawkins: reminds people that charter only requires a solution for E.164-based URIs, although it doesn't preclude a solution that works for other forms of URI. Adam Roach: problem anyway. Hadriel isn’t seeing PAU size as a problem for small and medium-sized businesses in the field today. Paul Kyzivat, Hadriel Kaplan, Keith Drage, & Adam Roach discussed the routing issues associated with using loose-routing on the registration-based mechanism. (Diagram provided by David Hancock) The issue boils down to this: Some network SP Network IP-PBX ------------ ---------- ------ [1]INVITE sip:usr1@sp.com -> [2]INVITE sip:usr1@sp.com -> Route: sip: [3] <- INVITE sip:usr@sp.com On receiving [1], SP network leaves Request-URI intact, adds Route header containing registered contact address for IP-PBX, and sends [2]. On receiving [2], IP-PBX pops pops Route header and routes on Request-URI. IP-PBX assumes sp.com domain belongs to SP network, so routes request back to SP Network at [3]. To resolve routing loop issue issue, SP Network needs to retarget Request-URI for [2] to URI containing domain of IP-PBX, like this: Some network SP Network IP-PBX ------------ ---------- ------ [1]INVITE sip:usr1@sp.com -> [2]INVITE sip:usr1@pbx1sp.com -> Route: sip: Adam Roach: This issue is avoided with the PUBLISH mechanism since the SP Network always overwrites the Request-URI with the unique PBX contact address associated with the target enterprise user AOR. Keith Drage: IMS elected to use “loose routing” for the subscription model so it would align with the peering model (which uses RFC3263-based routing). So, if there’s an issue with this routing mechanism, wouldn’t it exist for both subscription and peering models (and therefore more appropriately dealt with in SPEERMINT than MARTINI). Hadriel Kaplan: For peering mode this retargeting requirement does not need to be stated since if RFC3263 procedures are followed, then the Request-URI of incoming requests to the IP-PBX would always contain the domain belonging to the IP-PBX. However, since the subscription mode does not follow RFC3263, this retargeting issue probably should be addressed by MARTINI. Keith Drage: Don’t understand why option tag or indicator is needed to indicate that this registration is different than the RFC3261 registration. If it really is needed, that implies IMS has got it wrong since way back Dean Willis: this is fundamentally different from an IMS bulk registration. Keith Drage: it isn't different. Hadriel Kaplan: with IMS it is all provisioned on a per subscription basis. Cullen Jenning: works on IMS only because it is closed garden Adam Uzelac: with IMS the registrar expects it, in other environments not necessarily so. Hadriel Kaplan: big drivers are to address mismatch, trouble shooting and middlebox issues. Keith Drage: IETF already acknowledged implicit registrations when it approved the 3GPP requirements document way back. Keith Drage: If middlebox needs to know about individual contact addresses, something is wrong. Dean Willis: This indicator is not implying “implicit registration”, rather bulk-AOR registration. Paul Kyzivat & Adam Roach: There’s nothing in the IMS REGISTER method that says it is handled in any way special. But that’s OK because IMS is a closed garden Brian Lindsay: But doesn’t the way this is handled in IMS apply more generally? In IMS, the IP-PBX knows it is using implicit registration to bind the enterprise AORs to a single IP-PBX contact address. And it knows that incoming requests will identify the target enterprise user in the Request-URI. Likewise, the SP network contains configuration data associated with the registering IP-PBX AOR to indicate that this same behavior applies. Paul Kyzivat: Yes, we can continue using that if we sanction the mechanism where the PBX and SP network need a side-agreement in order to achieve interworking. Hadriel Kaplan: It’s more than that though – you can have a flag at the home proxy to say “this is special – do loose routing”, but mid-boxes in the signalling path wouldn’t know. Brian Lindsay: why do mid boxes need to know? Hadriel: because there are other reasons for having the indicator, such as to aid in troubleshooting miss-configuration issues. Keith Drage: IETF did acknowledge that the implicit registration existed based on the implicit-reg RFC (an implicit sanction that implicit registration without an indicator is OK), as long ago as 2002. Also, mid-boxes should not be doing anything special with-respect-to enterprise users, since these users are the sole responsibility of the PBX. John Elwell: Don’t see why mid-boxes need the explicit indicator. Disagree with number 4 on the summary slide-6 . Keith: We need to be clear whether we’re talking about enterprise or Service Provider middle boxes. RFC3261 does allow location server entries to be added by mechanisms other than registration. Adam: yes, but the entries are used differently than stated in RFC3261. Keith: agree, but that is outside of registration, so why does it justify the need of an indicator in the REGISTER request? Registration should work per RFC3261. Paul Kyzivat: Has GRUU been considered for these solutions? John Elwell has been asking about GRUU for some time. Paul Kyzivat: not saying there IS a problem with GRUU, saying that we need to look carefully at this. Not saying GRUUs are great, but that’s what we have today. Keith Drage: Public GRUUs assigned by the IP-PBX will probably work OK. There may be an issue with temporary GRUUs coined by the IP-PBX, since they may be treated as invalid by the SP network. John Elwell: Temp GRUUs should work with domain registration. Richard Shockey: In the SIPconnect1.1 work we agreed to put GRUU out-of-scope due to these issues. Hadriel Kaplan: The basic problem is that GRUUs were not designed to go through someone else’s domain to reach the GRUU’s domain. Question: is the GRUU problem in-scope for MARTINI? Cullen Jennings: Well, we need some mechanism for global routability to support features like call-transfer. If not GRUU, then what? Spencer Dawkins: Let’s continue the GRUU conversation on-list. Solution Proposals Recipes using PUBLISH draft-roach-martini-up-00 (Adam Roach) Adam submitted this draft only a couple of days before the meeting – he’s not asking that it be adopted unchanged, only that people consider the characteristics of this proposal. Why not use a new method? Adam said this wasn’t worth the expense of a new method (and Ben Campbell agreed). Adam is concerned that there’s no way to detect AOR mismatches between the SIP-PBX and Service Provider using the bulk REGISTER approaches, and (more problematic) no way to recover from these mismatches using the SIP protocol itself. In addition to what is on slides, Adam mentioned that this proposal could accommodate GRUU. Adam was showing examples with regex pattern matching on phone numbers – Rich Shockley challenged this (“all interesting blocks of phone numbers have holes due to number portability and similar causes”). Keith Drage: Is this standard POSIX regex? That’s what IMS uses now. Adam Roach: Problem doing it with full standard regex (think that’s too complex), so limited the syntax to make it very fast. Hadriel Kaplan: Can you really do this with just a BCP? Adam Roach: What is on the slide could be done with a BCP. Other mechanisms actually in the draft -- such as the new reg event body -- are protocol extensions. Hadriel Kaplan: could argue that what 3GPP has done is technically legal w.r.t. RFC 3261. Adam Roach: Yes, but falls down with some of the things in the problem document. Hadriel Kaplan: No reason not to update REGISTER to register multiple AORs. Keith Drage: If we come up with something completely different from REGISTER, rather than the simple fixes that SSPs need, why not just make provisioning of the peering-based approach more flexible, and encourage everyone to do peering? Hadriel Kaplan: Path is important. We can do peering-based, but there is a market for a subscription-based approach, especially if you’re not in DNS anyway. Spencer Dawkins: Let's defer that discussion to the mailing list. Adam Roach: Is there a 3rd registration-based option, where the REGISTER request contains a reg-event body? Someone asked if REGISTER was allowed to carry a body, and the consensus was yes. So we could do something using bodies along the lines described for PUBLISH instead of using PAU. Keith Drage: Defeats purpose - need to know continuous status, not just the snapshot at time of REGISTER. IMS provides a capability that enables the SP network to remove a registration – say your pre-pay account runs out. Adam Roach: Agreed, that could be useful. The IP-PBX could subscribe to Reg-event to support this. Robert Sparks: If we have a hybrid model, I would like to explore what happens when you refresh, and PUBLISH seems to solve this problem well. Could the PUBLISH mechanism provide the ability to refresh or update the list, similar to that provided by REGISTER using etags? Adam Roach: Yes, this could be supported, since the body/document contains an internal version number. Robert Sparks: How would the PUBLISH mechanism handle partial failures (say some of the AORs are deemed invalid by SP network)? Adam Roach: should be all or nothing. If the request fails, the IP-PBX receives a list of valid AORs, so it could try again with a modified list. Recipes for registration draft-martini-shaken-implicit-registrations-00 draft-martini-stirred-domain-registration-00 (Hadriel) Hadriel pointed out that we’ve been talking about using PAU, but we don’t actually have to do that – it’s legal for REGISTERs to have a body; we’d just need to define an appropriate body that describes what’s been bulk-registered. Keith reiterated that anybody who needs to know about what’s registered also needs to know what STAYS registered, so that you need to subscribe to reg-events anyway. Paul Kyzivat (to Hadriel Kaplan): Which of your drafts do you prefer? Hadriel Kaplan: the implicit registration mechanism, since it’s closer to what is currently deployed, and therefore more likely to be adopted – it’s less work. Spencer Dawkins: domain registration looked like a quick ride to nowhere in the DNS directorate. Cullen Jennings: Why not ask them - I could do so if needed. Jon Peterson: I raised the issue, but I also said the concern would largely go away if they are real domains. Hadriel Kaplan: Stirred draft currently says must be sub-domain of SSP domain. Spencer Dawkins: Are we saying that it needs to exist in DNS, but no other details (beyond existence) matter? Paul Kyzivat: OK as long as SP is happy to have PBX domain point to SP. Hadriel Kaplan: One of the problems with the domain-reg option is that it might receive opposition from the IESG (e.g., due to issues such as the domain being registered is also in DNS). Cullen Jennings: If the only concern was what the IESG would think, then we could certainly ask them. Paul Kyzivat: is there a rule that if you own the domain then you own the sub-domain? Bernard Aboba: No, because the sub-domain could be delegated to someone else. Spencer Dawkins: For example, lots of delegated sub-domains are under .com, .co.uk, etc…. Paul Kyzivat: A potential advantage of the domain registration mechanism is that it avoids the GRUU problem. Adam Roach: For the PUBLISH mechanism, there should be a way to convey the GRUUs in the response. Paul Kyzivat: This might work for public GRUUs, but not temp-GRUUS, since temp-GRUU values are random and therefore can’t be conveyed in short-form. Also, you get a new set of temp-GRUUs on each registration refresh – the logic related to which temp-GRUUs are valid and when they become stale is complex. Adam Roach: Maybe we could devise a mechanism that enables an enterprise phone to ask for a temp-GRUU when it needs one, instead of coining temp-GRUUs en-mass at registration time (and never using them). Paul Kyzivat: needs a lot of investigation. Would save a lot of grief if we used the domain registration model. Would also offload work from the SP. John Elwell: if the SIP-PBX were to use a SP-minted GRUU for an enterprise user, then would PBX route intra enterprise requests to that GRUU via the SP network (tromboning)? Adam Roach: Not necessarily – the PBX could track which GRUUs are for local users and which are for external users. Keith Drage: IMS has solved this GRUU issue for public GRUUs, but not for temporary GRUUs. Spencer Dawkins: Topic clearly needs more investigation. Wrapup 1st Hum - Should MARTINI discontinue consideration of Domain Registration as described in Hadriel's "stirred" draft? Results: 10 "No", 5 "Yes", 3 "abstain" No consensus to drop it yet. Hadriel Kaplan: but what more is required before we can drop domain registration? Paul Kyzivat: Would like to see a solution for GRUU. Paul thinks domain registration may be required for some applications. 2nd Hum: Do we need requirements to be written down? Result: 15 “yes”, 1 “no”. John Elwell volunteers to lead requirements discussion on the mailing list. Dean: Could we have multiple solutions – implicit registration and PUBLISH? 3rd Hum: Which is your preferred mechanism: Publish, Domain Registration or Implicit? Result: 7 for "publish", 1 "abstain", 12 for “implicit”, 1 for “dreg” (with a couple of people stressing they are unclear between implicit and domain). Next steps: 1. We need to push down one more level on all three solution mechanisms. 2. Requirements – follow up on thread started by John Elwell today. 3. Virtual Interims II & III: Bernard Aboba will put out doodle poll for week of Jan 25th and Feb 8th. (update – announcements for next virtual interims are available on mailing list now) 1:30 PM PT: MEETING ADJOURNED