MARTINI WG Virtual Interim Meeting #2 Date: Tuesday Jan 26th, 2009 Time: 10:00 AM: 12:30 PM PST Minute takers: David Hancock, John Elwell Attendees: Adam Roach Adam Uzelac Alan Johnston Andy Hutton Bernard Aboba Brian Lindsay Rich Shockey Christain Schmidt Cullen Jennings Dan Romascanu Dean Willis Doug Sauders Ernst Horvath Hadriel Kaplan James Swan John Elwell Keith Drage Krisztian Kiss Mary Barnes Paul Kyzivat David Hancock Spencer Dawkins ======================================================================= 1. Agenda bashing No comments. 2. John Elwell’s Requirement List Requirement-1: The mechanism MUST allow the PBX to be responsible for its AORs and to handle requests to those AORs according to its rules. Adam Roach: the term “responsible for domain” is mentioned in RFC3261, and in general it doesn’t allow a non-responsible proxy to retarget. Paul Kyzivat: Agreed. But if the SSP network receives a request addressed to the SSP’s domain and identifying an enterprise user, and the PBX is not reachable, the SSP should be allowed to retarget the request to voice mail. But if incoming request is addressed to the enterprise domain then it shouldn’t be allowed to retarget. Keith Drage: the SSP has a virtual PBX that is (or represents) the physical PBX. As such it (the SSP) is responsible for the enterprise domain. Adam Roach: The aspect of domain responsibility and how it might affect the MARTINI solutions is something new that hasn’t been fully considered yet. Paul Kyzivat: From a SIP perspective it makes a difference whether we’re considering only E.164 numbers, or not. Richard Shockey: emphasizes that we’re really only concerned about telephone numbers. Paul Kyzivat: Things get simplified greatly if we agree this is only about E.164 numbers. But if we make that simplification, then the RFC better explicitly state that the scope is limited to that. Richard Shockey agrees. Dean Willis: this scope issue affects the rest of our discussion. So this has got to be question number 1. Cullen Jennings: we have to solve the phone number problem first, and if we do that it is enough for the consumers of this specification work. Spencer Dawkins: we need to make this decision on the list, but could we decide to limit it to E.164 numbers for this call (at least)? Adam Roach: OK with limiting to E.164 numbers, but you have to be able to tell it is an E.164 number by some standard mechanism. Spencer Dawkins and Richard Shockey agree. Dean Willis: One way to indicate that URI contains an E.164 number is to use Tel URIs. Paul Kyzivat agrees. Tel URIs, solve problems with From: & To: headers as well. Richard Shockey: what about SIP URI with “user=phone”? Keith Drage: Disagrees with limiting scope to E.164 number, since it excludes private numbers that may not be E.164 numbers. Paul Kyzivat: the problem with using a SIP URI with “user=phone” is that if you don’t own the URI domain then you can’t look at the user part. Dean Willis: RFC3261 doesn’t allow registration of TEL URI. But since we’re changing REGISTER: we can change that too. Richard Shockey: Let’s narrow the scope to something solvable. However, using TEL URIs is neither necessary nor helpful. Service providers won’t deploy that. Hadriel Kaplan: if the SSP receives an E.164 at SSP domain then there’s no problem. It’s when the request arrives with the PBX domain that there is an issue. Adam Roach: Richard Shockey (SIPconnect1.1) has a tight time requirement to solve specific problem, namely to standardize procedures for support of E.164 numbers. Others in the group have a less time critical and more general requirement to standardize procedures for any type of AOR. Requirements 2,3,4: no comments. Requirement-5: The mechanism MUST observe SIP backwards compatibility principles. Keith Drage: This sounds like a good requirement, but unfortunately these principles aren’t written down anywhere. Requirement-6: The mechanism MUST work in the presence of intermediate "proxies" on the SSP side of the interface (between the PBX and the SSP's domain proxy), where those intermediate "proxies" need to be on the path of inbound requests to the PBX. Someone: If we keep this requirement we need to nail down the term “proxies”. Keith Drage: what is the use-case that requires proxies in enterprise? Paul Kyzivat: There are cases where an enterprise might want to put an SBC between the PBX and the SP network. Dean Willis: there could be things (like proxies) between PBX and SP network, and things between enterprise UA and the PBX. Many responded: the 2nd case is definitely out-of-scope. Keith Drage: the PBX registration with the PS network is independent and separate from the enterprise users registering with the PBX. Dean Willis: there may be some issues with Outbound. Requirement-8: The mechanism MUST work without requiring the PBX to publish reachability information through the DNS. Cullen Jennings: who is the PBX in this case? This doesn’t sound like a real requirement, it limits solutions. Bernard Aboba: I agree with Cullen. Dynamic DNS is widely available and inexpensive. There are some cases (such as putting an FQDN in a Contact URI) that require DNS resource records to be put in place. Hadriel Kaplan: the real issue here is that the PBX may not have a domain name. Bernard Aboba: That’s a different requirement. Requirement-9: The mechanism MUST work over any existing transport specified for SIP, including UDP Someone: SIPconnect 1.1 requires TCP. Spencer Dawkins: Just to clarify, SIPconnect 1.1 does allow UDP. It just recommends TCP. Keith Drage: Why is SIPconnect 1.1 content and timelines driving the solution? Requirement-10: Do we need any requirement concerning ability to check the two sides have matching set of AORs? Brian Lindsay: No, this should be out-of-scope. Adam Roach: Do we have a requirement that provisioning mismatches can detected? Spencer Dawkins: Question is that should this be in-scope for MARTINI, or can we use some other SIP mechanism like reg-event? Brian Lindsay: Maybe there are non-SIP mechanisms that would be better suited to provide this capability. Keith Drage: This is nice to have, but not necessarily a must-have MARTINI requirement. Adam Roach: There are really two separate problems here... a) how do the SSP and PBX know they have the same set of enterprise AORs? b) how do intermediaries know which AORs are valid for the enterprise (say an SP network edge proxy needs to assert identity on incoming requests). These two could be solved by the same solution, but they are not the same problem. Question: are there any requirements missing? Richard Shockey: Should there be a requirement for Proxy-Require? i.e. do we require intermediate proxies to understand this extension? Someone: Pure proxies are somewhat involved in registration transactions, so we may need to have them understand this. Keith Drage: Proxies in the path should not be impacted by the mechanism. Hadriel Kaplan: Can’t we decide this later? Once we’ve settled on the mechanism, do the right thing so as not to break things. Desirables: all accepted except for the following… Desirable-2. The mechanism SHOULD scale to PBXs of several thousand AORs. General comment: there is some ambiguity about how large a MARTINI-compliant IP-PBX should scale. Desirable-4. The mechanism SHOULD allow handling of inbound requests and outbound requests between SSP and PBX to be as common as possible as with a normal peering arrangement (RFC 3263 based), as far as the PBX is concerned. General comment: this last “desirable” is questionable. 3. Adam Roach’s Presentation Slide-2: Contact Routing vs. Domain Routing Paul Kyzivat: if Jonathan’s loose-routing proposal had been accepted, we wouldn’t be worried about overloading REGISTER with domain routing now. Hadriel Kaplan/Adam Roach/Paul Kyzivat: Does the reason for rejecting Jonathan’s loose-routing proposal apply to this MARTINI “shaken-implicit” draft proposal as well? Hadriel Kaplan: no, Jonathan’s loose route proposal was rejected in favor of the History-Info solution. Paul Kyzivat: if we’re going to resurrect the loose-route solution in MARTINI, then we should consider those issues raised against Jonathan’s L-R proposal again now. Someone: If scope is limited to E.164 numbers then the usual case is that an incoming request to SSP will contain the SSP domain. Does this avoid some of the concerns described here? Hadriel Kaplan: there is still the case where a remote user uses initiates a call to the enterprise user using the From: header or Refer-To: header which contains enterprise domain. Slide-3: Domain Responsibility Paul Kyzivat: The term “responsible for AOR” is not well defined. Adam Roach: Keith Drage is saying that this responsibility can span across networks. Anything you can let the PBX do, you should be able to let the SSP do as well. Hadriel Kaplan: this is no different than email: sometimes your email provider is your service provider. Paul Kyzivat: this could get complicated if you have multi service providers and one domain name. Hadriel Kaplan/Paul Kyzivat: agree that maybe this “multi service provider one domain name” case probably doesn’t make sense. Slide-4: AORs: To Enumerate or Not to Enumerate Someone: Does reg-event have a way to represent all the registered AORs? For example, reg-event has no way to say “all AORs in this domain”. The syntax only supports enumerating each AOR. Keith Drage thought this case was either supported, or possible to add.Bottom line: if we choose reg-event as a solution, then we have to include the updates required to reg-event to make it work. Brian Lindsay: do intermediaries really need to know the list of AORs? P-CSCFs need to know: but they have a way. If all intermediaries are on the SSP side, then whatever mechanism is used doesn’t appear on the interface and is therefore out-of-scope w.r.t. MARTINI. Keith Drage: agrees. John Elwell: The concept that the P-CSCF knows the list of AORs assigned to the IP-PBX, and uses this information to assert the identity of the calling enterprise user is flawed anyway; e.g., consider the case where a call from a user outside the enterprise arrives at the IP-PBX via a “tie-line” trunk? Slide-5: Multiple AORs : Implicit or Explicit? Someone: The issue around having the SIP-PBX sending the regular-expression up to the SSP, -- isn’t it too complex to expect to work? i.e. it’s sufficiently complex that there’s a good chance the PBX vendor will not implement it well. Hadriel Kaplan: point of there would only be one John.Elwell@sp.com Slide-6: Contacts: To Map or Not To Map? Slide-7: REGISTER Applied to Multiple Humans No comments recorded. Slide-8: Transport: Is UDP a requirement? This topic already covered during review of John Elwell’s requirement list. Cullen Jennings: once we figure out the solution: thinks UDP won’t be an issue. 4. Keith Drage’s Presentation Slide-3: Relationship of identities Someone: What do the different boxes represent? Keith Drage: A Private User Identity is specific to your phone/CPE, while a Public User Identity your AOR. Slide-5: Business trunking (release 8) Cullen Jennings: Is it true, as some people have asserted, that there is a violation of SIP RFCs (e.g., wildcard Public User Identity breaks URI syntax)? Keith Drage: there may be an issue, but haven’t looked. 5. Dean Willis’s Presentation This presentation problem identifies a problem with connection re-use where there are multiple domains using a single route. Slide-3: Alternate Topology Paul Kyzivat: is this really a problem? Couldn’t this be accomplished simply by establishing two flows? Hadriel Kaplan: wasn’t the problem with connection reuse that the SSP had no way to authenticate the PBX (connection-reuse was actually for proxy-to-proxy)? But we don’t have that problem because the SSP can authenticate the PBX using SIP Digest. Cullen Jennings: what is the shared secret? Is it something for a single user, or for a whole domain? What exactly is authenticated by that shared-secret? Hadriel Kaplan: it would authenticate all the PBX AORs. Cullen Jennings: traditionally it would only authenticating the AOR being registered. Hadriel Kaplan: if the SP network receives a request addressed to the target enterprise domain, then the SP network simply loose-routes the request and it should arrive at the correct enterprise user. If the SP network receives a request addressed to the SAP domain but destined for an enterprise user, then the SP network must make a decision as to which enterprise domain to retarget to. Paul Kyzivat: this could all be driven by provisioning, where if one thing happens then provisioning says this other thing happens, etc. So on the one hand there should be no problem, but on the other hand, it’s not clear. Dean Willis: we just need to satisfy ourselves that the connection-reuse issues identified in section 9.3 of the re-use draft don’t apply to this MARTINI case as well. 6. Hums Bernard Aboba: should initial focus be to solve the E.164 problem first? I.e., agree to deliver on a milestone to limit to E.164? Should we describe the HUM as restricting to tel URIs, which would also support private URIs. Brian Lindsay: should we limit scope to phone numbers? Adam Roach: no, since telephone numbers have are digit strings. For this to work the user part has to be a unique key. Paul Kyzivat: one of the contexts for local tel URIs is domain name: and so if we allow local Tel URIs we still have the domain issue. Do we do a point solution for E.164, and then tackle the more general problem? Paul Kyzivat: there are some common non-E.164 numbers like 911: would these be precluded if we limited the scope to “E.164-only”? Cullen Jennings: No, it wouldn’t. The E.164-limitration applies to enterprise AORs, and “911” would never be assigned to an IP-PBX. Cullen Jennings: should the hum be reworded to say that the PBX should only register E.164 public user IDs? Reason being: call xfer, which requires support of some non-E.164 GRUU-like URI, still needs to work. Bernard Aboba: what are next-steps, to be completed by the next meeting? Action Item to Dean Willis & Adam Roach to bring the E.164 scope issue to the list.