[martini] Draft IETF 77 minutes (cleaned up)

["Bernard Aboba" <[e-mail]>]

MARTINI WG Minutes

IETF 77

Anaheim, California USA

 

Working Group Home Page <http://tools.ietf.org/wg/martini/> 

Jabber room:  martini at jabber.ietf.org

Chairs
        Bernard Aboba <[e-mail]> 
        Spencer Dawkins <[e-mail]>

Minute taker:  David Hancock [e-mail]

 Meeting Slot I

Monday, March 22, 2010

1 PM - 3 PM Pacific Time

Palos Verdes Room


1.    Preliminaries (Bernard & Spencer)


Topic

Draft

Time

Discussion Leader


Preliminaries

     Blue Sheets

     Note Takers

     Note Well

     Agenda bash

     Document Status 

none

10  min

chairs

 

Chair Slides <http://www.ietf.org/proceedings/10mar/slides/martini-4.ppt> 

 

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: In the WG last call and Call for Adoption notices, comments
were solicited on the mailing list as well as in the issue tracker.  So we
don't require that comments be submitted via the Issue tracker.  With
respect to milestones, we're actually behind with respect to the milestones
in the Charter by at least two months. 

 

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

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


2.    Requirements (John Elwell & Hadriel Kaplan)


Requirements

http://tools.ietf.org/html/draft-elwell-martini-reqs 

40 min

John Elwell

 

Requirements Slides

 

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 Aboba: What does extensibility mean - does it mean a new version of
GIN (e.g. a different option tag)? 

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

Gonzalo Camarillo: 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. 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).

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 bypassing 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): Let's take this to the 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


 


3.1           Adam Roach - GIN draft presentation


MARTINI with Globally Identifiable Numbers

http://tools.ietf.org/html/draft-roach-martini-gin 

30  min

Adam Roach

 

GIN Slides

 

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

 

Adam Roach introduces new open issue - Is there a need to signal the 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 as 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 the response-size
problem? Instead of sending the registered AORs in the response, send a
pointer to them. 

Christer Holmberg: Once a 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
with respect to GIN. 

 

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

Bernard Aboba: How many 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?

Cullen:  Ask Francois Audet to review the document relating to Outbound.
Will contact Francois on this, and will work offline to get volunteers to
look at 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.

 

MARTINI WG Meeting Slot II

Friday, March 26, 2010

1415 - 1515 Pacific Time

California D


4.    Preliminaries


 


Topic

Draft

Time

Discussion Leader


Preliminaries

     Blue Sheets

     Note Takers

     Note Well

     Agenda bash

     Document Status 

none

10  min

Chairs 

 

 

Chair Slides <http://www.ietf.org/proceedings/10mar/slides/martini-7.ppt>
(Friday Session)


5.    GIN Update


GIN Update

 http://tools.ietf.org/html/draft-roach-martini-gin 

10 min

Adam Roach

 

Adam Roach's presentation of new version of GIN draft:

 

GIN Update Slides

 

-          Provided summary of updates.  TRAC Issue #7-10 addressed in the
-02 update. Need (external?) security analysis of interaction between Path,
Outbound and Service Route with multiple AORs in a single REGISTER. Issue
#14 requires fixes to examples. 

-          No comments received so far relating to the -02 update (submitted
yesterday). 


6.    Path and Service-Route


Path and Service Route

 http://tools.ietf.org/html/draft-roach-martini-gin 

10 min

Dean Willis

 

 

Dean Willis' presentation on security considerations on Path and
Service-Route

 

Path and <http://www.ietf.org/proceedings/10mar/slides/martini-6.pdf>
Service Route

 

 

1. GIN effectively registers multiple AORs.

2. All AORs will have same path, Service-Route.

3. If Service-Route invokes registrar-side services, all users on PBX will
get the same services invoked. 

 

Otherwise, it should "just work". 

 

There may be an issue between Service Route and Outbound

 

Keith Drage: Service Route works for IMS implicit registration, which is
different than the registration procedure proposed by GIN.

Hadriel Kaplan: Although IMS and GIN registration procedures differ, they
are the same with respect to Service Route; i.e., they are both registering
multiple AORs with a single REGISER transaction.


7.    Requirements Analysis


Analysis of GIN against Requirements

http://tools.ietf.org/html/draft-ietf-martini-reqs 

http://tools.ietf.org/html/draft-roach-martini-gin 

30  min

Adam Roach

John Elwell

 

John Elwell's presentation on evaluation of GIN according to requirements in
MARTINI requirements draft

 

Requirements Analysis Slides

 

John Elwell: Requirement 17 duplicates Requirement 5 and will be removed
from the requirements document. DES4 is difficult to quantify and a proposal
has been made to remove it.  Otherwise, GIN appears to satisfy all the
requirements. 

Christer Holmberg: Has a problem with REQ16 - the GRUU requirement.

Dale Worley: Clarified this requirement.  It doesn't require support for
GRUU, only that the solution should not constrain the PBX from assigning
GRUUs to its UAs in the usual way.

Paul Kyzivat: This requirement is also about addressing the fact that the
SIP-PBX may not itself have a globally unique address, and therefore must
get some help from the SSP network to provide a globally unique address.

Dale Worley: must allow the SIP-PBX to provide the UAs with GRUUs as defined
in the GRUU RFC.

John Elwell: Please post clarifying updates to the list.

 


8.    Discussion and Wrapup


Wrapup - Hums and Next Steps

None

10 min

Chairs and ADs

 

Adam Roach:  What are the next steps on GIN?

Bernard Aboba:  We had a Call for Adoption on the GIN document, which ended
on March 19, 2010. 

Adam Roach:  We did?  (looks at laptop).  Oh yes! I forget about that.  I
even replied to the thread. 

Bernard Aboba:  We will go over the replies to the Call for Adoption and
will summarize the o