Subject: [martini] MARTINI Virtual Interim III Draft Minutes (please review)

From: "Bernard Aboba" <[email-masked]>
Date: Mon, 15 Feb 2010 16:55:08 -0800

MARTINI WG Virtual Interim Meeting III

Date: Tuesday Feb 9th, 2010
Time: 10:00 AM - 12:30 PM PST

Minute takers:  David Hancock, Brian Lindsay 

Attendees:

Adam Roach

Alan Johnston

Ben Campbell

Bernard Aboba
Brian Lindsay

Christian Schmidt

Cullen Jennings
Dan Romascanu

David Hancock

Dean Willis

David Schmidt

Hadriel Kaplan
James Swan

John Elwell

Keith Drage

Martin Dolly

Mary Barnes

Michael Lunsford
Paul Kyzivat

Rich Shockey 

Robert Sparks

Spencer Dawkins

Tyler Parkin

======================================================================= 

1.  Agenda bashing

No comments.

2.  Requirements and Usage Scenarios

MARTINI Requirement Update (John)

John Elwell: Is requirements doc ready for last call?

Keith Drage: Could problem statements (if we need them) be merged into
requirements document? 

Adam Roach & John Elwell agreed.

Dean Willis: Propose new requirement to allow a DID phone number to move
dynamically among PBXs serving the same enterprise (and connected to the
same SSP). The SSP will route requests to the IP-PBX where the user is
currently located. The current drafts would require the SSP to make changes
to point a DID at a different PBX. Some syntax could be added to the GIN
draft to allow this.

Keith Drage: such a requirement could be supported by the SSP, in which case
MARTINI is not impacted. 

Dean Willis: so maybe the requirement is "martini must not preclude" or
"must support"? 

Dean Willis: this requirement would add the ability to move a person from
one building to another w/o having to take provisioning steps in the SSP to
remove/add the user from one PBX to the other. It eliminates the need to
have the user call the enterprise IT department, enterprise IT call the SSP,
etc. The syntax that is proposed in Adam's draft requires someone in another
channel to move the number from one PBX to the other. 

Keith Drage: does this mean media goes to PBX too? 

Dean Willis: yes. 

Cullen Jennings: Flip side is adding a new number that is available to the
SIP PBX and allowing the PBX to automatically discover the number.

Cable operators want the ability to have the SSP tell the small 10-line PBX
what numbers it is assigned. 

Keith Drage: yes, but this is a provisioning issue, not a sip issue.

Dean Willis: Agree with Cullen that the PBX should have a way to discover
the range of numbers it is authorized to use. The proposed new requirement
is that it can dynamically use a subset of those numbers.  

Martin Dolly: Don't understand requirement - the PBX already knows its
numbers, so why does it need to discover them? 

Richard Shockey: There are two main issues: lack of any "explicit"
indication in the implicit registration models, plus provisioning of SIP
PBXs. The latter should be out of scope of MARTINI.

Spencer Dawkins: Lovely to do, but not in scope. Needs to be dealt with as a
separate problem.

Dean Willis: Agree - but the problem of which PBX the DID is bound to should
be in scope.  A discovery mechanism would help in the case where the
enterprise asks for a new number - it could be used to inform the PBX when
the number is available. 

Martin Dolly: yes, but is this a requirement that MARTINI needs to address?
Or is it feature creep that will make MARTINI overly complex?  

Richard Shockey: we're dealing with 2 issues here - a) explicit indicator of
the special REGISTER, and b) syncing numbers between SSP and PBX. Agree that
b) is out-of-scope. 

Martin Dolly: understand the need for PBX to implicitly register on behalf
of users. But a specific number must be assigned to someone, so let's leave
discovery outside scope of MARTINI. 

Dean Willis: OK, discovery can be out-of-scope, but the "which PBX is this
number on right now" is in-scope?  

Spencer Dawkins: Let's not solve this today, but move this discussion to the
list. 

Martin Dolly: does this have to be solved now or later? 

John Elwell: should we move problems into the requirements draft? 

Cullen Jennings: we need to see what is moved before agreeing to additional
text. 

Keith Drage: how do we do it - does John get pre-approval of what to add, or
does he make his best-guess include it in draft that we review? 

The group agreed on the former. 

Cullen Jennings: less is more. Plus the WG-chairs should be clear on
identifying the individual authors of the requirements draft.

[discussion returned to next steps on the requirement I-D]

John Elwell: Proposal: 

a.  Produce -00 Requirements I-D

b.  Propose on the mailing list which portions of the problem statement I-D
should be included

c.  Produce -01 Requirements I-D based on discussion of the above

Keith Drage: assume that we're not going to add new requirements without
onlist discussion/consensus.

John Elwell: Right, any new requirements need to be handled separately.

[ no objections to John's proposal ]

Service Provider Perspective (Martin Dolly) 

Martin Dolly: Many of todays PBXs don't register at all. Instead, Acme
Packet does a surrogate registration on behalf of the PBX. So having a
registration that is implicit is good, and sufficient. 

Dean Willis: what about the case where the E.164 number is located on two
PBXs at the same time? 

Paul Kyzivat: PBXs are probably geo-close to each other. If you provision
the set of implicitly registered E.164 numbers to each PBX, and the sets
across multiple PBXs overlap, then the SSP can fork calls to the overlapping
numbers to those multiple PBXs. 

Martin Dolly: Dean is describing a nomadic behavior. Current models are
static. Haven't seen any requirements for a nomadic model. Most carriers
don't do forking.

Hadriel Kaplan: This is a provisioned phone # model.

David Hancock: In internal discussions with Cable operators a nomadic model
has been viewed as out of scope and could be supported within a PBX campus
model that hides the nomadicity from the service provider. 

Cullen Jennings: what is timeliness of this action? If the move needs to
happen quickly then it needs to be supported via SIP, whereas if there isn't
a tight time constraint, then a conventional provisioning solution would
suffice. 

Dean Willis: Could be supported with slight modification to current
proposals

David Hancock: Would like to see discussion on list. Worried about feature
creep.

Spencer Dawkins: If Dean has a simple tweak to Adam's mechanism, then put it
on the list

Keith Drage: First we should agree on whether or not this is a requirement.
If we don't follow this process rigorously we'll end up with feature creep. 

Usage Scenarios (Adam Roach)

Slide-2:

Keith Drage: why limit to INVITEs? This would also apply to other requests
such as OPTIONS/SUBSCRIBE/REFER/etc. 

Adam Roach: agree, this applies any out-of-dialog request that can be sent
to the PBX.  If we get it right for INVITE, then everything else should
work.

Slide-7 (Use-Case 4): 

Adam Roach: In this case SP receives incoming request from Internet
addressed to pbx.com. 

Paul Kyzivat: if SSP is OK with this, then it is not a problem.

Spencer Dawkins: RFC 3263 routing would be used between the Internet and the
SSP.  

Adam Roach: considering the entire flow, when the black phone dials 10
digits, who adds the "pbx.com" domain? 

Paul Kyzivat: the question is - can this be supported. Not how does it
occur, but can it occur, and if yes, will it be supported? 

Spencer Dawkins: I think UC-4 is OK from a "don't preclude" standpoint. 

Adam Roach: Use-case should be ok as a "don't preclude"

Dean Willis: yes, this case could occur when someone uses a SIP URI from a
business card. 

[brief group discussion on whether anyone would really list a phone number
with a domain on their business cards ]

Paul Kyzivat: this SIP URI could also leak out for some features like
callback, where the originating user initiates a call to the URI contained
in a previously received From: header. 

Cullen Jennings: my address book has SIP URIs. So SIP URIs are definitely
out there. 

Spencer Dawkins: don't need to make decision on call, take this to the list.

Paul Kyzivat: my current position on this is "don't preclude". 

Slide-8: (Use-Case 5: use Tel URIs on the wire) 

Brian Lindsay: does this really require registering a Tel URI? 

Adam Roach: Agreed this is using Tel URIs on the wire, doesn't actually
require Tel URI registration.

Dean Willis: Whether tel URI is implict (doesn't appear in REGISTER request)
or explicit (does appear in REGISTER request) is open to debate. But I think
we're in agreement that this case is not supported.

Slide-9: (Use-Case 6)

Adam Roach:  This slide is not correct.  It should show ssp.com as the
domain name for both invites, per the original mailing list posting.  

Slide-10: (Use-Case 7)

Adam Roach: Problem is this requires History-Info update and that may be a
long time. 

Mary Barnes: History-Info is moving quickly. New 4244bis draft will be out
in the next day or so, don't think there is a time issue.

Martin Dolly: expresses doubt on History-Info.  

Slide-11: (Use-Case 8) 

Adam Roach: This is the same as UC-6 except that the PBX registers with its
own domain, instead of IP address. So this requires 3263 procedures, and
since we've said that PBX doesn't support DNS update, it seems like this
should be out-of-scope. 

Keith Drage: could someone describe on-list the specific problem this case
causes? 

Paul Kyzivat: independent of violating RFC3263, this violates domain
responsibility. So this is as bad as UC-6.

Slide-12: (Use-Case 9)

Adam Roach: This case is relatively clean. 

Keith Drage: how does this differ from UC6?  

Adam Roach: diagram for UC-6 is wrong. Both legs should have ssp.com, not
pbx.com. Adam will update the slides on the archive
(http://www.drizzle.com/~aboba/MARTINI/Jan-Interim-III/  ). See mailing list
Feb 1st - use-case 6 is correct in that email. 

Hadriel Kaplan: UC-6 is 3GPP. 

Keith Drage: why is UC-3 different than normal location routing behavior?

Adam Roach: it is the same, but the registration has to work as described in
the GIN draft. 

Keith Drage: need to go back and look at why IMS did the loose-routing
mechanism vs. the location-routing UC-3 solution. 

Brian Lindsay: did IMS do it to align subscription and peering models? 

Keith Drage: yes, maybe that's the reason, but in addition the Route header
may have been needed by the P-CSCF. 

Spencer Dawkins: put question on-list asking whether we should support UC-3
or UC-9. Meanwhile, Keith and others can study the use-cases. Request to
Adam - add to GIN draft the example that is chosen. 

Adam Roach: GIN already has example for UC-3, and could add UC-9, if that is
required. 

Brian Lindsay: UC-9 aligns with MARTINI-Shaken, should keep on table

Spencer: hold off on adding additional use-cases -- the goal is to pick one
mechanism.

Hadriel Kaplan: [General comment] These are "scenarios" rather than use
cases.

Spencer Dawkins: Likes the structure these have provided.

3.  Solution Updates 

MARTINI with Globally Identifiable Numbers (GIN) Draft (Adam Roach)

Slide-3: 

Adam Roach: Regarding bullet-2, you don't have to actually add 100 rows in
the location database. Since it is algorithmic, it could be optimized.

Slide-4: 

Adam Roach: "bnc" URI parameter says this is a special Contact URI that must
be expanded before it is used.

Slide-5: 

Adam Roach: the '*' character indicates where PBX can add its own unique
material. 

Spencer Dawkins: can this GRUU enhancement be done within MARTINI, or does
it require work outside of MARTINI? 

Adam Roach: need to put to one of the AD's.  Thinks MARTINI owns it.

Hadriel Kaplan: we may in fact not need to make changes to GRUU. 

Slide-6: Public GRUU

Brian Lindsay: wouldn't there be SP hairpinning issues if these GRUU's were
exchanged between clients within SIP PBX

Adam Roach: PBX could know AoRs it's responsible for to avoid hairpinning,
could recognize its own GRUUs with the ssp.example.com domain. 

Martin Dolly: why do we need GRUUs? 

Paul Kyzivat: need a globally routable URI. 

Keith Drage: it's just that the PBX might want to use its own GRUUs, in
which case it needs to be able to create a GRUU that actually works. 

Martin Dolly: not arguing against the GRUU RFC. Within 3GPP GRUU it is a
MUST, so it's well-defined and therefore not an interoperability issue. 

Keith Drage: the only requirement is that the PBX should be able to coin
GRUUs, and therefore they should work. 

Paul Kyzivat: GRUU is optionally supported for a registrar. In this case
there are 2-layers of registration; one from enterprise UA to PBX, and one
from PBX to SSP network. Therefore if either PBX or SSP does not support
GRUU, then the endpoint cannot support GRUU. So, this is the case where both
PBX and SSP do support GRUU, and we need to make sure that in that this case
works.

Adam Roach: The draft is not mandating GRUU support - just explaining how
the mechanism interworks with GRUU

Slide-8: Reg-Event Package

Adam Roach: SIP reg event package. Need to proxy the SIP reg-event SUBSCRIBE
to the PBX, since it knows the actual registration status of GRUU. 

Slide-9: Contact Syntax

Paul Kyzivat: This implies a constraint on the PBX. It has to manage the
user portion - make sure that its own internal URIs don't collide with
internally used AORs.  

Adam Roach: the fact that we're using E.164 numbers with '+' sign should
avoid any collisions.  Something about this restriction probably needs to be
stated in the Requirements draft. If transformation, beyond simple replace
is needed, we need the requirements.

Paul Kyzivat : proposal in slides seems workable. Do we need rules about
whether separators are removed?  We should at least decide whether Tel URI
separator/formatting chars are allowed on the interface.  

Adam Roach: Whatever is decided should be made explicit in the draft. 

Conclusion: get rid of parentheses.

Slide-11: (Simplify GRUU operation by getting rid of '*' character)

Agree with simplification -- always append local data to the received 'gr'
parameter, instead of allowing local data to be anywhere.

Slide-12 & 13: (Temp GRUU issues)

Paul Kyzivat: my solution only requires action by the PBX, and is therefore
out-of-scope on the SIP-Trunk interface. Therefore, GIN maybe only needs a
Note to explain what the PBX needs to do here. 

Cullen Jennings: Temp-GRUUs are required. 

Paul Kyzivat: The most common use-case is a PBX user includes a Temp-GRUU in
a request to a remote user, and the remote user addresses a out-of-dialog
request to that received temp-GRUU. If the temp-GRUU is associated with a
non-DID user, then the call should be routed to the attendant. 

Dean Willis: Approach won't work with outbound.

Adam Roach: would there be a critical mass of PBXs that would be able to do
this or is it a non-starter?

Adam Roach: Could replace mechanism in draft with Paul's alternate approach

Hadriel Kaplan: Like Paul's approach.

Adam Roach: Leaning towards Paul's approach.

Paul Kyzivat: Need to do no more in the draft than outline there is no
normative impact

Adam Roach: Hope to be able to limit to an explanation of how it would work,
although may need extensions for Public GRUUs. Any objections limiting to
some implementation notes?

Rich Shockey: Less is more.

Slide-14: (signaling enterprise phone numbers during registration)

Someone: leaving this out paints ourselves into a corner. 

Richard Shockey: short answer is, no, we should not do this. First of all,
numbers may not be in a range. 

Paul Kyzivat: Counting on ranges to reduce size is going to be a problem.

Dean Willis: need to be able to express multi ranges. Spencer: original
discussions removed this capability because of UDP message size limitations.

 

Keith Drage: Can't the reg-event be used for this? There is a need to use
reg-event to sync reg-state between SSP and PBX. E.g. 3GPP/IMS procedures
allow the SSP network to remove a registration (e.g., due to prepay money
running out) - the reg-event is the mechanism used for this. 

Spencer Dawkins: want to use reg event to manage state question.

Dean Willis: there is a need for the SSP to reject a registration to tell
PBX that some of the numbers it thinks it is registering aren't in fact
registered by the SSP. 

Paul Kyzivat: what if there is no numbers configured in the SSP for a
registering PBX? 

Hadriel Kaplan: use the registration transaction to register the pbx, and
then use reg-event to tell the PBX exactly what was registered. 

Dean Willis: will take phone-number issue to the list.

Slide-15: (Proxy-Require)

Adam Roach: It's not the kiss of death if we don't define a new
Proxy-Require tag, since the proxies that need to understand and participate
in this registration are all within one domain, and spread across multiple
domains. 

Slide-16: (Security)

Adam Roach: There may be some security issues with these other SIP
extensions. They may not "just work".  We need some experts well versed in
SIP and security to look into multiple AoR registration.

Spencer Dawkins: who should be involved? Need a SIP/Security subject matter
expert (e.g., Jon Peterson) 

Keith Drage: why do we think we need a security analysis? 

Adam Roach: just a gut feeling that there may be security issues. Of course
we also need to make sure they work at all. This should be easy in the
straightforward case. 

Bernard Aboba: chairs will try to roundup experts.

MARTINI Shaken Update draft (Hadriel Kaplan)

Hadriel Kaplan: No updates to the draft. "shaken" is essentially Adam's
use-case 9. It makes the routing of requests look more like the peering
model than contact routing. Shaken currently doesn't talk about GRUUs, but
that could be added.

Bernard Aboba: Should we have a hum on "GIN" vs "Shaken"?

Keith Drage: not ready to go there yet.

Hadriel Kaplan: At end of day we just need to pick a mechanism. The
advantage of shaken is that it supports email style, in addition to E.164
numbers.

4.  Wrap-up

Richard Shockey: Do we want to discuss merging GIN & shaken? 

Bernard Aboba: if there are suggestions for changes to GIN, they can be
posted on the list. 

Cullen Jennings: there is already some consensus on simplification the GIN
syntax. 

Bernard Aboba: New doodle pool is out on possible dates for next call, may
be difficult to find an appropriate date due to conflicts with 3GPP and
IETF/3GPP IPv6 transition meeting.

Adam Roach:  Not enthusiastic about a fourth virtual interim.  Potential
dates are too close to IETF 77, and would interfere with preparation.  There
is also the exhaustion factor. 

Action items

*	Dean Willis: take phone-number mobility issue to the list.
*	Chairs: round up security experts for GIN security review

---

From: Adam Roach <[email-masked]>
Date: Tue, 16 Feb 2010 12:31:59 -0600

On 2/15/10 18:55, Feb 15, Bernard Aboba wrote:
>
> *Slide-15:* (Proxy-Require)
>
> Proxy-Require tag, since the proxies that need to understand and 
> participate in this registration are all within one domain, and spread 
> across multiple domains.
>

That's backwards from what I said.

We've generally been hesitant to define Proxy-Require feature tags, 
since the chance that they'll get all the way through the network is 
vanishingly small. Without some kind of network-wide coordination -- 
which isn't possible on the general Internet -- there's no way to get 
the entire body of deployed proxies upgraded to support the new feature tag.

However, during registration, only one domain is involved. This makes 
upgrading the entire proxy network that might be involved far more 
tractable.

/a

---

From: "Bernard Aboba" <[email-masked]>
Date: Tue, 16 Feb 2010 10:58:08 -0800

Thanks for the correction.  An updated version of the minutes is available
here:

http://aboba.drizzlehosting.com/MARTINI/Jan-Interim-III/Feb-9th-MARTINI-Note
s-dch-bl-merger.doc

From: Adam Roach [mailto:[email-masked]] 
Sent: Tuesday, February 16, 2010 10:32 AM
To: Bernard Aboba
Cc: [email-masked]
Subject: Re: [martini] MARTINI Virtual Interim III Draft Minutes (please
review)

We've generally been hesitant to define Proxy-Require feature tags, since
the chance that they'll get all the way through the network is vanishingly
small. Without some kind of network-wide coordination -- which isn't
possible on the general Internet -- there's no way to get the entire body of
deployed proxies upgraded to support the new feature tag.

/a