Subject: [martini] FW: MARTINI notes

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

-----Original Message-----
From: Dean Willis [mailto:[email-masked]] 
Sent: Thursday, April 29, 2010 1:19 PM
To: Bernard Aboba; Spencer Dawkins
Subject: MARTINI notes

Notes on Martini IV

Notes by Dean WiIlis

Callins include Martin Dolly, David Hancock, David something else, and  
another party. (Several more added later).

Topic: Martini Requirements
Led by John Elwell

Current status reviewed.

Issue #39, explanatory text in Section 1.

Would this be more appropriate elsewhere, such as Olive?

Spencer prefers it stay in the requirements draft, since we're  
producing only one of these and it'll be easier to find.

Discussion moved on while Hadriel reviewed text. On review, Hadriel  
believes the first paragraph is just wrong (Background on the Issues),  
and needs to be tailored to unique contacts, not unique AORs. Hadriel  
proposes removing this text. Noted that this was added in response to  
Jon Peterson's input during IETF 77, so we might need to take such  
changes to the list. John will take this to list.

Issue #15, #16 non-E.164 and extensibility to any AOR

5 alternative paths have been proposed. John proposes #1 or #3  
(nothing or add as desirable).

Adam suggests 6th option to be phase 1 deliverable, with a plan to do  
a second phase 2 requirements document for phase 2 deliverables.

Noted that several people from list supported adopting requirements as  
they stand.

Discussion of 2 phase approach and meaning of requirements followed.

John proposed that we could reword #15 to talk about extensibility to  
non-E.164 numbers, then accept #15 and #16. This approach seemed to  
achieve consensus in the discussion.

Keith asked to clarify the implication of "must be extensible" -- how  
do we handle this in the solutions draft? Adam responded that the  
draft(s) must include discussion of how the extensibility is provided.

John Elwell said that he would like to see #15 and #16 done  
eventually, but that they aren't as urgent as E.164. Discussion  
continued on the question of whether the existence of Olive satisfies  
the requirements.

Does this mean we should stop work on gin until we meet the  
requirements? Proposed by Keith that we need an existence proof that  
phase 2 is achievable based on phase 1 before we lock in phase 1.

Bernard noted that the charter describes what the scope is with  
respect to E.164 numbers, and noted that we may need to modify the  
charter to encompass #15 and #16. Discussion followed, and we believe  
extensibility is within the charter. Solutions MAY be, as well;  
further discussion is indicated.

Poll: Do have have consensus on including #15 and #16 in requirements,  
but adjusting #15 to "must be extensible". No one appeared to be  
opposed to this proposal. John will take this to the list for  
confirmation.

Topic: GIN
led by Adam Roach

Changes reviewed.

Issue: Ticket 28 user=phone

Proposed at Anaheim to say if pbx needs user=phone, it registers  
user=phone.

Question from Doug Sauder: The SSP is the one who knows whether this  
is a phone number or not, so it should be the one to add it.

Martin noted that they expect to see user=phone on the INVITE and  
require PBXes to support it. Since PBXes do not currently register, it  
is less certain. Hadriel noted that surrogate registration currently  
does NOT include user=phone it.

Discussion followed.

Noted that there is a 5th option (proposed by Hadriel), where  
user=phone is a feature of the registration. If you register with you  
get only phone numbers; without you get all URIs. Some devices fail  
with user=phone, some require it.

Extended discussion on contact routing, GRUU, etc, followed.

Question: Is there any text suggesting that user=phone can be used in   
the current draft?

Proposed that we pull user=phone out of the examples.

John Elwell spoke in favor of option 2, which forbids user=phone on  
BNC URIs in REGISTER and requires SSP to add it on INVITE.

How does this compare to a normal registration? If there is no  
user=phone on registered Contact and one comes back in the INVITE,  
what happens. (it depends...)

Debate continued between Hadriel, Olle, John, and Adam. Then broadened.

Doug proposed adding another flag to the REGISTER request that  tells  
the SSP that the PBX expects to have user=phone added for phone number  
URIs, but not for non-phone-number URIs.

Concluded that Adam will work this into the draft.

Issue: Ticket #36 regevent handling

Who serves the regevent subscription -- SSP or PBX?

Question: Is the SSP knowledge ever useful information, or does it  
just show whether or not the PBX is online. Yes; there may be multiple  
registrations for a user at the SSP.

Question: How does this apply to dialog event?

Adam says what he is expecting to work here is when an external user  
wants to use regevent in communication to with a PBX user.

Debate inconclusive and to be taken to the list.

Issue: Other open tickets

Still need expert analysis on interacttion with draft-ietf-sip- 
outbound. Chairs will work on a victim.

Topic: Olive draft
Led by Hadriel Kaplan

Noted by Spencer that he had recently asked list about wether the  
result of bulk registration is the same as the result of multiple  
individual registrations. Is the right place inside Olive? Keith noted  
that this assumption is part of why gin is fundamentally broken; we  
need something that works differently from conventional contact- 
routing.  Debate ensued; inconclusive.

Issue: Parameterized routing for domain aliases, or something.

Too confusing for notetaker.

Issue: Local Numbers ala RFC 3966

Question: Where is the lack of uniqueness problem? In what entity does  
it manifest?  Answer: Systemic, but the SSP proxy is the one that  
needs to be able to differentiate.

Noted that the result is still a URI to URI translation in the SSP  
proxy. Phone-context is an independent issue from domain name, but  
correlation between them can make life easier.

When we say "user parameters", what do we mean? All of them; trunk  
group, etc. They become user parameters when converted to a SIP URI.

Summary: Chairs repeated summary from preceding discussion.

Question: Will we continue on this version of olive, or R&R? Hadriel  
reports that he is about to ship -01, so we should hold off on  
discussion until then.

Process question: The requirements draft has some things to take to  
list, following this, will we try to progress it? The chairs believe  
"yes".