Subject: [martini] Draft minutes from MARTINI Virtual Interim IV

From: Bernard Aboba <[email-masked]>
Date: Tue, 11 May 2010 15:10:39 -0700

Minutes of Martini Virtual Interim IV
April 29, 2010

Minute takers: David Hancock, Dean Willis

Agenda bash:  No changes to Agenda

1. Requirements discussion led by John Elwell

Issue #39, explanatory text in Section 1.

John Elwell - Do we keep issue #39, or does it go in a solutions draft (such as Olive)?

Spencer prefers it stay in the requirements draft, since we're producing only one of these and it'll be easier to find.

Discussion moved on while Hadriel reviewed text. On review, Hadriel  believes the first paragraph is just wrong (Background on the Issues), and needs to be tailored to unique contacts, not unique AORs. Hadriel proposes removing this text. 

John Elwell: don't mind deleting it, but was asked to add it by Jon Peterson at IETF 77 mtg. Propose taking this to the list - and give reasons and get consensus to remove it. 

Spencer Dawkins: if list decides that it should be somewhere - would that place be the olive draft (or whatever document addresses solution for the 15/16 requirements).

Hadriel Kaplan: the Olive draft does cover this already, so that's covered 

Issue #15, #16 non-E.164 and extensibility to any AOR

5 alternative paths have been proposed. John proposes #1 or #3 (nothing or add as desirable).

Adam suggests 6th option to be phase 1 deliverable, with a plan to do a second phase 2 requirements document for phase 2 deliverables.

Noted that several people from list supported adopting requirements as they stand.

Discussion of 2 phase approach and meaning of requirements followed.

Hadriel Kaplan: I thought these were desirable. At least 16 - the extensibility one. 

Dean Willis: we specifically excluded #15 for phase-1 - to limit to E.164 numbers. 

Keith Drage: if we do this - how do we meet/handle these requirement in the solutions draft? 

Adam Roach: by demonstrating in another draft (e.g., olive) how the extension could be supported. 

Spencer Dawkins: understand that everyone on group supports the requirement for non-e.164 numbers. 

John Elwell: yes, would like 15/16 to be supported eventually, just not in phase-1. 

Spencer Dawkins (as chair): would not want to ignore these. Should address them as required or desirable. So, should the working group continue advancing Olive? 

Martin Dolly: there was a contingent of folks that saw the need to address these now - as in phase-1. 

Dean Willis: does that mean stop working on GIN until we figure out how it can support 15/16. 

Martin Dolly: a requirement is a requirement. There is never a question of phasing requirements. If you choose to defer meeting a requirement, then it is still a requirement, just at a later date. 

Adam Roach: what I'm hearing is to reverse the MARTINI-II meeting agreement to limit phase-1 to E.164 numbers. 

Dean Willis: no, Martin is just saying these are requirements, we just need to decide schedule. 

Keith Drage: there is also a desire that these requirements can be supported by MARTINI GIN extension, and not a whole new solution. 

Bernard Aboba:  The MARTINI charter specifically states that the solution must support E.164 numbers, and may support others. So those insisting that non-E.164 support is a requirement are effectively attempting to change the MARTINI WG charter after it was approved. 

John Elwell: adding a requirement that solution should be extensible is within charter. 

Dean Willis and Bernard Aboba: agree. 

Dean Willis: charter says must support E.164, may support others. 

John Elwell: am hearing that we add req's for 15 & 16, reworded to say soln "must be extensible".  

Spencer Dawkins, Adam Roach: agree. 

** General Agreement - Add requirement(s) that the phase-1 solution must be extensible to support 15 & 16.  

** General agreement -- Will take 15/16 & 39 to the list.

2. Adam - GIN slides

Changes reviewed.

Issue: Ticket 28 user=phone

Proposed at IETF 77 to say that if pbx needs user=phone, it registers user=phone.

Doug Sauder: The SSP is the one who knows whether this is a phone number or not, so it should be the one to add it. If you do option-1, you will then have trouble reconciling with Olive; for example, PBX specifies user=phone in REGISTER request, and at the same time wants to support non-E.164 numbers that wouldn't have user=phone

Martin Dolly: AT&T expects to see user=phone on the INVITE and requires PBXes to support it.  Since PBXes do not currently register, it is less certain. 

Hadriel Kaplan: noted that surrogate registration currently does NOT include user=phone.

Adam Roach: I thought there were some implementations that required user=phone.

Hadriel Kaplan: yes and there are some implementations that require it for E.164 numbers, and other implementations that ignore this parameter. 

Martin Dolly: there is a difference between not dropping a call, versus requiring it. 

Hadriel Kaplan: the problem the 1st option is that it is treating user=phone an opaque parameter in the contact. The problem is that it really isn't opaque - it has meaning in the INVITE. 

Someone: There is a 4th option, which is to let the SSP decide whether "user=phone" is required. 

Hadriel Kaplan: Noted that there is a 5th option, where user=phone is a feature of the registration. If you register with user=phone, you get only phone numbers; without you get all URIs. Some devices fail with user=phone, some require it.

Extended discussion on contact routing, GRUU, etc, followed.

Question: Is there any text suggesting that user=phone can be used in the current draft?

Proposed that we pull user=phone out of the examples.

Adam Roach: the fact is that this has caused so much confusion - the document should talk about it at least to say something.

John Elwell: likes option-2 - let the SSP decide whether or not to put user=phone in request URI (based on what is stored in location db). The user=phone is really an extension of the user part, and since the user part is the expansion of the template provided in the bulk REGISTER Contact URI, the u=p parm should be
configured in the SSP as part of that expansion. I.E. Whether it is there or not is based on provisioning. It's possible for two diff users to have an AOR - same E.164 - one with u=p and one without.

How does this compare to a normal registration? If there is no user=phone on registered Contact and one comes back in the INVITE, what happens. (it depends...)

Debate continued between Hadriel, Olle, John, and Adam. Then broadened.

Doug Sauder: propose adding an indicator/parameter somewhere in the REGISTER indicating that the PBX requires user=phone for AORs containing E.164 numbers. Similar to option 1 , but PBX is making it explicit - I need a user=phone for E.164 numbers. 

Adam Roach/Hadriel Kaplan: this may be a good option.  

Martin Dolly: want to emphasize that user=phone is required. 

Adam Roach: this means that if you're testing a PBX in your lab that claims compliance with GIN (and we make proposed change), you would expect to see it indicate that it needs the user=phone parameter. 

Keith Drage: solution should state what is mandatory vs, optional for the PBX and SSP to support. Multiple people agree. 

** Agreement -- Adam will propose text for this new user=phone option. 

Issue: Ticket #36 regevent handling

Who serves the regevent subscription -- SSP or PBX?

Question: Is the SSP knowledge ever useful information, or does it just show whether or not the PBX is online. Yes; there may be multiple  registrations for a user at the SSP.

Question: How does this apply to dialog event? 

Keith Drage: is there a use-case we have in mind, where the SSP needs to respond to reg-event when PBX is offline? And would it work any different than other packages such as dialog-event? Hadriel - the reg-event package routing is differently than other packages. The reg-event SUBSCRIBE is routed to the
registrar of the AOR in the Request URI. Therefore, since the enterprise-user AORs belong to the SSP, the reg-event SUBSCRIBE is routed to the SSP. Having it go to the SSP makes sense -- say the target AOR can be registered simultaneously to the PBX and directly to the SSP. 

Adam Roach: case where same AOR is registered to the SSP directly, and to the PBX, is a corner case. 

Adam Roach: To header in REGISTER represents the PBX. You can subscribe reg-event to it to get its registration state. But if you subscribe to the actual
enterprise user AOR, then you want the actual registration state on the PBX of the enterprise user. What if my phone is registered to two PBXs for redundancy? 

Adam Roach: this supports it - you get two separate answers. 

Hadriel Kaplan: reg-event SUBSCRIBE request URI is owned by the SSP - therefore the SSP should respond. It shouldn't goto the PBX. In fact there may be no registration at the PBX; e.g., the PBX supports non-SIP endpoints. 

Adam Roach: But sending the SWUBSCRIBE to the SSP doesn't provide any valuable information, since the it only reflects whether the PBX is registered or not, and 99.99% of the time it will be registered.  

Spencer Dawkins: suggest taking this to the list. Agreed. 

Issue: Other open tickets

Final slide - need a volunteer for outbound analysis. Dean Willis suggests Paul Kyzivat.  

Spencer Dawkins & Bernard Aboba: will follow up with Paul and Cullen Jennings.

3. Hadriel Kaplan: Olive presentation

Spencer Dawkins: had recently asked list about whether the  result of bulk registration is the same as the result of multiple  
individual regitrations. Is the right place inside Olive? 

Keith Drage:   this assumption is part of why gin is fundamentally broken; we need something that works differently from conventional contact-routing.  Debate ensued; inconclusive.

Keith Drage: we would have avoided the whole subscribe to reg-event if we had followed the IMS implicit registration model. 

Adam Roach, Dean Willis: no - the problem would still be there, basically because RFC 3261 does not have a good model for transitive registration, which is
what both IMS and GIN bulk registration are.

Dean Willis: this is still broken for reg-event. 

Adam Roach: agree. Solving it for GIN will solve it for olive as well. In fact Hadriel's solution is the GIN draft extended to non-164 numbers.  

Keith Drage: not sure if you would ever explicitly register a local number. In IMS it would only be implicitly registered. Register global explicitly, and register local implicitly. 

Hadriel Kaplan:  but GIN is a compression/decompression rule for explicitly registrations. So what would an explicit registration of a local number look like?  

Keith Drage:  where is the lack-of-uniqueness problem? 

Adam Roach: we were trying to make user-names globally unique to avoid the ambiguity that occurs when two PBXs have overlapping private numbers. 

Hadriel Kaplan: solves this problem by adding context to make local numbers unique. Problem is a PBX could have both a public and private numbers. There are two ways to handle this - either two separate logical trunks, or something in the actual URI portion that makes local numbers unique. 

4. WG Chairs: next steps

Spencer Dawkins: enumerates agreements for moving (disposition of issues 15,16,39, Paul Kyzivat and Cullen Jennings solicited for review of outbound, etc.)

Keith Drage: is it possible for Hadriel to submit a draft-01 of Olive? 

Hadriel Kaplan: yes. 

Keith Drage: therefore we'll hold discussion until we see -01. 

John Elwell: reqs draft - assuming there is no pushback on 15,16,39 from list - are we going to progress the requirements draft? 

Bernard/Spencer: yes.  Once we hafve no issues on the requirements document, we will progress it. 

Meeting adjourned...

---

From: Cullen Jennings <[email-masked]>
Date: Tue, 18 May 2010 19:33:25 -0600

Uh, these notes don't really make much sense to someone who was not there. Sorting out if I agree with proposal #1 or #3 for issue #15 is just not something I'm willing to go do. I'm not asking anyone to redo the minutes, I probably could figure it all out if I spent enough time but I'll just wait to comment on the drafts as that seems a better use of time.  Just don't take my silence as agreement with anything that happened at the interim. 

On May 11, 2010, at 4:10 PM, Bernard Aboba wrote:

> _______________________________________________
> martini mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/martini

Cullen Jennings
For corporate legal information go to:
http://www.cisco.com/web/about/doing_business/legal/cri/index.html

---

From: Dean Willis <[email-masked]>
Date: Wed, 19 May 2010 01:57:59 -0500

Well, if you also looked at the slides that are part if the proceedings. I think the discussion will make more sense.
-- 
Dean Willis