IETF69, Chicago, IL, USA Minutes of the SPEERMINT WG session Session PEERing for Multimedia INTerconnect (speermint) Monday, July 23, 2007, 1300 - 1500 (Afternoon Session I) Room Name: Grand Ballroom ======================================================== CHAIRS: David Meyer Jason Livingood SECRETARY: Alexander Mayrhofer RAI AREA DIRECTORS: Cullen Jennings Jon Peterson RAI AREA ADVISOR: Jon Peterson [Note: audio recordings unfortunately are useless because of very low sound level and noise] ---------------------- Agenda bashing (Dave Meyer): ============================ - Otmar's "SPEERMINT background" added to the agenda - link to terminology draft is incorrect in agenda - the correct link has been sent on the mailing list Review of Milestones and Document Flow (Jason Livingood) ======================================================== - the "Terminology" document is overdue (April 2007), now has a new lead editor. This document ist one of the key issues for today's meeting. - The IM specific use cases document is beyond WGLC, going to IESG - The "VoIP use cases" document is up for discussion today. Target is to go to WGLC within about 4 weeks. Please post comments or go to the mike today. - all other drafts are currently on track - document flowchart from about 9 months ago is shown: * terminology, * then IM and seperate VoIP use cases. * then requirements, architecture & documents implementing it. comment: are the requirements too broad? are they also hitting other IETF areas? jon peterson: at the end of the day: we do want to have recommendations for operators. avshalom: requirements should arise from the actual usage - use cases. SPEERMINT Terminology (Daryll Malas) ==================================== http://www.ietf.org/internet-drafts/draft-ietf-speermint-terminology-09.txt Changes: changed CAD to SED terminology ("Call Addressing Data" -> "Session Establishment Data") Jason: more important to have the definition itself rather than discussing about the acronyms itself. Changes to recent versions: - 08: nits feedback - 09: added section 4.3, updated 4.2.2. 4.2.3. included terminology from VoIP Usecases and architecture draft. clarification of the "Location function". David schwartz: An URI can serve in a double function: gives path to endpoint, but can also be used in a "LCR" way type. Otmar Lendl: there are 3 seperate steps, and it's important to keep them seperate: "lookup", "policy", "location" Jason: terminology should define the terms, and architecture should then define whether they're discrete or collapsed. suggests to add the terms that are needed to cover this... Daryll: tried to define the functions, but not the "role" they can play. Defining all possible options for all the roles could escalate... Rohan: The individual steps in call processing are well excepted, aren't they? jean-francois: Is "Assisting peering" part of "indirect peering" rathern than a distinct kind? jason proposes to agree on the "lookup seperation" text immediately after the session. conclusion: two open issues: "indirect" and "assisted" Peering inclusive? Is there a need to define a seperate "lookup"? Schwartz: "assisted" can sit on top of indirect as well as direct (eg. redirect SIP proxy) Jean francois: not saying it should be collapsed, but then definition is lacking something. Jason: Suggestions: do a -10 version, and then WGLC it. VoIP use cases (Yiu Lee) ======================== http://www.ietf.org/internet-drafts/draft-ietf-speermint-voip-consolidated-usecases-02.txt changes: - referenced and used terminology draft - consolidated those use cases with only small differences - added administrative characteristics for the use cases - consensus needed for folding enterprise use cases into this doc (left prague without concensus on this): Conclusion: Will mention that some of the use cases can be used for enterprise use cases, too. - need concensus for the direct/indirect/assisted cases. David: use cases for adhoc / static? Otmar: Yes, we have use cases - should go into the use case draft. Jason: please send things to list in the next several days. Jean-Francois: Lost a lot of details when consolidating use cases. probably looses information for the requirements. (the remaining thins are only very high level use cases) comment: probably keep those details out of the use case draft, and put them into the requirements draft? David: the call is just SIP, so the process of setting that call up is the part that is really important... SPEERMINT Requirements (Jean-Francois Mule) =========================================== http://www.ietf.org/internet-drafts/draft-ietf-speermint-requirements-02.txt changes since version -02 - aligned with terminology draft in version 07 - added requirements and guidelines from several other drafts [slide on scope details] David: if we require tls, why don't we require a baseline codec? Jason: compromise: use the text "have compatible codecs" in requirements, and then fill in that requirement in "implementing" documents... Sometimes it's difficult to derive reqs from the use cases. Otmar Lendl: main differences between use cases occur way before the actual SIP call - the SIP call in most cases is then very similar. david schwartz: we might require things from the SIP wg. Otmar Lendl: The Result of SPEERMINT scope is "Session Establishment Data". comment: transit is neither originating nor terminating. Problem: other docs contain "hints" on requirements, but those not discussed. What to do with those? eg: - IM address resolution, - dialstring normalization, - SUBSCRIBE/NOTIFY on SBE's. All this is not being discussed on list - means that documents diverge. suggestion: things that don't show up in the use cases should not go into the requirements doc. comment: should make clear to what the requirements apply (to whom) Daryl: PLEASE write real use cases, not "cloud in / cloud out" to have useful requirements Jason: suggestion to gather more security related requirements (establishing trust, etc...) Jean-Francois: Have received zero feedback on the list. Please provide feedback. SPEERMINT background (Otmar Lendl) ================================== http://tools.ietf.org/id/draft-lendl-speermint-background-00.txt SIP is successful, but RFC3263 failed. Why: email model failed, because ingress elements are not being opened up. Discussion why it's that way. Daryl: is not accepted because carriers can charge money for it. Dean: if users find out that they can put calls directly to each other, and carriers only for the PSTN, then this will take up. Meeting concludes.