[martini] Draft MARTINI Minutes from Monday's session at IETF#77

[David Hancock <[e-mail]>]

Here are draft minutes from Monday's MARTINI meeting for your review.

Comments welcome.

Thanks
David

==================== Begin Draft MARTINI Minutes============================

1. Preliminaries (Bernard & Spencer)

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: We're actually behind w.r.t. the schedule agreed in MARTINI.

Keith Drage: Due to meeting conflicts, etc, did not have an opportunity to contribute to the schedule.

Cullen Jennings: Words of praise for the current MARTINI process/progress.

2. Requirements (John Elwell & Hadriel Kaplan)

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 Abobe: What does extensibility mean - does it mean a new version to GIN?

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 Abobe: 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?

Gonzalez: 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. 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 bypasses 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) asks people to make comments on 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

Adam Roach - GIN draft presentation

Adam Roach: The risk in adding 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 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 on 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 Abobe: 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 - 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: Agreed, although there has also been support for GIN from cable operators.

Adam Roach introduces new open issue - Is there a need to signal 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 is 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 response-size problem?

Christer Holmberg: Once 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 w.r.t. GIN.

Adam Roach: The intermediaries originally could assume that REGISTER was for the single AOR in To header. Are here any impacts or security concerns due to fact hat now we're registering multiple AORs?

Bernard Abobe: How much 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?

Someone (Cullen?) volunteered Francois Audet for Outbound. Cullen agreed to contact Francois on this, and will work offline to get volunteers for 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.

================================== End Draft MARTINI Minutes ===============================