Subject: [martini] FW: Notes from Martini Virtual Interim IV

From: "Bernard Aboba" <[email-masked]>
Date: Fri, 30 Apr 2010 15:30:47 -0700

-----Original Message-----
From: David Hancock [mailto:[email-masked]] 
Sent: Friday, April 30, 2010 1:25 PM
To: Spencer Dawkins
Cc: Bernard Aboba
Subject: RE: Notes from Martini

Spencer -- in the spirit of favoring timeliness over cleanliness, here are
my pretty rough notes...

David

---------------------------------------------------------

Meeting started -- agenda OK.

1. Requirements discussion led by John Elwell

John Elwell - Do we keep issue#39, or does it go in a solutions draft?
Spencer - would prefer to keep it in Req's draft, since we're not sure what
sol'n draft it goes in. Bernard - could it go in Olive Hadriel? Hadriel will
look at.

Slide-4: issues 15 & 16 are addressed (or at least discussed) in Olive.
These requirements are in-line with the MARTINI charter, but they are not
required by the charter (i.e., charter mandates support of AORs  based on
E.164 numbers, but does not preclude support of other forms of AORs) 

Slide-5: Lists 5 options for handling issues 15 & 16
 1. don't adopt at all, and lose phase-2 req's
 2. adopt as requirements, but do them in phase-2
 3. adopt as desirables
 4. restructure req's doc - ph-1 vs. 2

Adam - there is a 6th option - constrain the current doc to phase-1
requirements - with understanding to do a follow-up phase. 

Martin - there was support for option-2 on MARTINI reflector.

Hadriel - I thought these were desirable. At least 16 - the extensibility
one. Dean - we specifically excluded #15 for phase-1 - to limit to E.164
numbers. 

Keith - if we do this - how do we meet/handle these requirement in the
solutions draft? Adam - by demonstrating in another draft (e.g., olive) how
the extension could be supported. 

Spencer - 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 (as chair) would not want to ignore
these. Should address them as required or desirable. So, should the working
group continue advancing Olive? 

Martin - there was a contingent of folks that saw the need to address these
now - as in phase-1. Dean - does that mean stop working on GIN until we
figure out how it can support 15/16. Martin - 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 - what I'm hearing is to reverse the MARTINI-II
meeting agreement to limit phase-1 to E.164 numbers. Dean - no, Martin is
just saying these are requirements, we just need to decide schedule. 

Keith - there is also a desire that these requirements can be supported by
MARTINI GIN extension, and not a whole new solution. Bernard - such a change
would require a MARTINI charter change. Someone - (who?) doesn't agree this
is a charter change. John - adding a requirement that soln should be
extensible is within charter. Dean and Bernard agree. Dean - charter says
must support E.164, may support others. 

John - am hearing that we add req's for 15 & 16, reworded to say soln "must
be extensible".  Spencer, Adam, agree. 

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

Looping back to issue#39: Hadriel - 1st paragraph of issue is actually
wrong. Propose that we remove this issue. John - 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 - 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 - the Olive draft does cover this already, so that's covered [John] 

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

2. Adam - GIN slides

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

Martin - we expect the PBX to support user=phone in the Request-URI of
INVITE. 

Doug - if you do option-1, 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

Adam - I thought there were some implementations that required user=phone.
Hadriel - yes and there are some implementations that require it for E.164
numbers, and other implementations that ignore this parameter. 

Martin - there is a difference between not dropping call, vs. requiring it.
(editor's note -- I may have misquoted Martin here -- looking at it now I'm
not sure what it means, so remove if you see fit)

Hadriel - the problem the 1st option is that it is treating u=p an opaque
parm in the contact. The problem is that it really isn't opaque - it has
meaning in the INVITE. 

Hadriel - A 5th option is to not mention user=phone at all, either in
examples, normative text, etc. Adam - the fact that this has caused so much
confusion - the document should talk about it at least to say something.

John - likes option-2 - let the SSP decide whether or not to put u=p in
request URI (based on what is stored in location db). The u=p 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.

Doug (Sauder?) - propose adding an indicator/parametersomewhere in the
REGISTER indicating that the PBX requires u=p for AORs containing E.164
numbers. Similar to option 1 , but PBX is making it explicit - I need a u=p
for E.164 numbers. 

Adam/Hadriel - this may be a good option.  

Martin - want to emphasize that user=phone is required. Adam - 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 - 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. 

Slide Ticket#36. 

Keith - 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 : case where same AOR is registered to the SSP directly, and to the
PBX, is a corner case. 

Adam: To header in REGISTER represents the PBX. You can subscribe reg-ev 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 - this supports it - you get two separate answers. 

Hadriel - 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 : 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 - suggest taking this to the list. Agreed. 

Final slide - need a volunteer for outbound analysis. Dean suggests Paul
Kyzivat. Spencer & Bernard will follow up with Paul.

3. Hadriel's olive presentation

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

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

Dean - this is still broken for reg-event. Adam - agree. Solving it for GIN
will solve it for olive as well. In fact Hadriel's solution is the GIN draft
extended to none.164 numbers.  

Keith - 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 - but GIN is a compression/decompression rule for explicitly
registrations. So what would an explicit registration of a local number look
like?  

Keith - where is the lack-of-uniqueness problem? Adam - we were trying to
make user-names globally unique to avoid the ambiguity that occurs when two
PBXs have overlapping private numbers. Hadriel solves this problem by adding
context to make local numbers unique. Hadriel - 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. Spencer - next steps

Spencer enumerates agreements for moving (disposition of issues 15,16,39,
Paul K reviews outbound, etc)

Keith - is it possible for Hadriel to submit a draft-01 of Olive? Hadriel -
yes. Keith - therefore we'll hold discussion until we see 01. 

John - req draft - assuming there is no pushback on 15,16,39 from list - are
we going to progress the requirements draft? Bernard/Spencer - yes, progress
the requirements draft?

Meeting adjourned...

> -----Original Message-----
> From: Spencer Dawkins [mailto:[email-masked]]
> Sent: Friday, April 30, 2010 8:48 AM
> To: David Hancock
> Cc: Bernard Aboba
> Subject: Notes from Martini
> 
> Hi, David,
> 
> Just in case you're doing your typically consciencious thing and working
> over your notes from MARTINI yesterday - I also have notes from Dean, and
> my
> own notes, so you don't need to do much cleanup, and I'd like to get draft
> notes out quickly, so that we can get mailing list concurrence with
> directions that (I think) are pretty positive :-)
> 
> Have a great weekend!
> 
> Spencer