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

["Elwell, John" <[e-mail]>]

"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)."

Just to remove any ambiguity, please rephrase the second sentence as follows:
"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)."

John


> -----Original Message-----
> From: [e-mail] 
> [mailto:[e-mail]] On Behalf Of David Hancock
> Sent: 23 March 2010 18:03
> To: [e-mail]
> Subject: [martini] Draft MARTINI Minutes from Monday's 
> session at IETF#77
> 
> 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 
> =============================== 
> 
>  
> 
>  
> 
>  
> 
>