Session PEERing for Multimedia INTerconnect (speermint) MONDAY, March 20, 2006 15:20-17:20 (Afternoon Session II) ==================================================================== CHAIRS: David Meyer Jason Livingood SECRETARY: Alexander Mayrhofer ----- meeting opened: this is the first official speermint wg meeting. starting off with administrivia - scribe, blue sheets agenda bashing ============== AGENDA o Welcome & Introduction to speermint / Administrivia 5 minutes Dave Meyer - Mailing list: speermint-request@ietf.org subscribe - Scribe (jabber) - Blue Sheets o Agenda Bashing 5 minutes Dave Meyer o Review of Milestones 5 minutes Jason Livingood o Review and Status of Open Work Items New Drafts ------------- 1 - speermint Terminology Draft 15 minutes Dave Meyer note: it was suggested to merge requirements into this draft, which dave has done. 2 - Media Session Authorization 15 minutes draft-wing-session-auth-00 Dan Wing 3 - I-D on the minimum set of requirements for 15 minutes SIP-based VoIP interconnection (BCP) draft-natale-sip-voip-requirements-00 Bob Natale 4 - SIP Peering Policy Management draft-lendl-sip-peering-policy-00 20 minutes draft-lendl-domain-policy-ddds-00 Otmar Lendl Alex Mayrhofer 5 - Routing Architectures, Policy, and Message Flows 15 minutes draft-bhatia-sip-peering-00 Medhavi Bhatia 6 - IP Service (Voice and Multimedia) Peering Architecture 15 minutes draft-khan-ip-serv-peer-arch-00 Sohel Khan o Open Discussion 10 minutes agenda is accepted, no changes requested. Milestones ========== (Jason) Jul 2006 - Submit SPEERMINT terminology I-D (Informational) start at low level, and work way up on complexity - get basic things done first, and then work up. terminology - architecture - msg flow Sep 2006 - Submit I-D defining the SPEERMINT routing architecture (Informational) Dec 2006 - Submit I-D defining the message flows associated with the SPEERMINT routing architecture (Informational) Jan 2007 - Submit I-D on the use of DNS SRV and NAPTR records as specified by RFC 3263 (BCP) Mar 2007 - Submit I-D on the minimum set of requirements for SIP-based VoIP interconnection (BCP) then going to security/identity exchange area: Jul 2007 - Submit I-D specifying the use of strong identities in session peering and supporting the establishment and exchange of trust between domains (BCP) Jul 2007 - Submit I-D(s) on use cases (BCP) Jul 2007 - Propose re-chartering for any additional efforts/considerations, or propose conclusion of working group (following approval of last documents) terminology draft ================= Title : SPEERMINT Requirements and Terminology Author(s) : D. Meyer Filename : draft-ietf-speermint-reqs-and-terminology-00.txt Pages : 12 Date : 2006-2-15 This document outlines the solutions space requirements and defines the terminology that is to be used by the Session PEERing for Multimedia INTerconnect Working Group (SPEERMINT). It has as its primary objective to focus the working group during its discussions, and when writing requirements, gap analysis and other solutions oriented documents. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-speermint-reqs-and-terminology-00.txt ---- used to be called "terminology", now is "requirements and terminology". comments from rohan not yet added to document: - number of lookups (section 2) - detailed discussion about federations and carrier clubs. text about layer5 transit networks proposed - from "does not exist" to "is not required" (which admits existance). some comments about terminology carrier/infrastructure ENUM - consistence with i-ENUM requirements desired. however, normative reference means loss of timescale control: penn pfautz: i-ENUM requirements now in last call. Definitions: what is 2119 language here - needs to be discussed tel-URI out of scope: comments? rohan: consensus is to use SIP, right? bar for consensus for other stuff should be high - we could do that later. stastny: SIP means SIP uri, tel uris can be translated to SIP URI jonathan: in some cases not translating tel uris might be legitimate, however, that could be done later. layer5 peering: transit networks out of scope - discussion desired on this. ??: peering vs. interconnect: if you talk "interconnect", "transit" might pop up. eli katz: we have seen transit use cases in services we provide. interopability on signaling level, etc desired. not excluding that would put industry in better position ed guy: seeing lot of requests for l5 peering too, but what is l5 transit? meyer: was taken out of scope, but comes back... schwartz: not concerned about direct traffic vs. transit, but concerned about trust relations. stastny: clarified already on slide 4, which puts federations between originating and terminating? steve norris: could be confusing - peering and transit can't be the same. not just 2 operators, but 3 operators. definitions what we mean is needed. rohan: how much is just terminology mismatch rather than technology? henry sinnreich: we have a business model similar to long distance model here - does the ietf want to promote business models? schwartz: problem probably with word "transit"? a talks to b, whether directly or inderectly does not matter. whats in the middle is less important jean francois: differences from intermediaries in protocols? why is that so different from end to end? so what are the differences division of labour: should we leave requirements out of that doc, and move reqs into bob's document - that we should think about? Session Auth ============ Title : Media Session Authorization Author(s) : D. Wing Filename : draft-wing-session-auth-00.txt Pages : 15 Date : 2006-2-1 In many VoIP networks today, firewalls and session border controllers are used at the edge of an administrative domain to allow authorized UDP media flows to enter or leave the network. This document introduces a new mechanism to authorize a UDP media flow. This mechanism works with encrypted hop-by-hop signaling, end-to-end authenticated signaling, and multihomed networks. The media authorization is performed using an Interactive Connectivity Establishment-capable endpoint and a calling signaling device that authorizes a firewall to permit a flow. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-wing-session-auth-00.txt --- authorize media sessions by ICE username/passwords, authority from call controller ice overview, currently for SIP, but useful for gaming, etc. per flow passwords make sure that a talks to b. (private address clashes. 192.168...) media session auth: firewall and policy server talk together and open pinholes. rohan: alice does not need to have that all? dan: right - works if all that stuff is missing. ??: for more sessions? dan: seperate for each session rohan: interesting, but not relevant to speermint. ??: happens on every call dan: yes - new session. jonathan: if flow problems between domains are in scope, that could be a potential solution. if flow problems not in scope, then doc also out of. dave: we need to do architecture etc first. Requirements for SIP interconnect ================================= Title : Requirements for SIP-based VoIP Interconnection Author(s) : B. Natale Filename : draft-natale-sip-voip-requirements-00.txt Pages : Date : 2006-3-1 This is an initial draft for consideration by the SPEERMINT WG as a candidate for the chartered work item dealing with "the minimum set of requirements for SIP-based VoIP interconnection (BCP)", due in March 2007. In its present form, this draft is intended solely to provide a basis for WG discussion about requirements selection. As such, it is primarily structural and descriptive in nature, leaving prescriptive content to later revisions driven by WG consensus. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-natale-sip-voip-requirements-00.txt ---- dealing with the milestone "minimum requirements". want to generate interest on working together on this. is a BCP, more "squishy" than protocol definition. think that "peering" definition from charter is a subset of what commonly is called "interconnection". penn: concerned about next gen pstn style interconnection. would like to not see those things in draft. natale: does not want to limit scope schwartz: maybe not deal with interconn - l2 and l3 done. bob: looked at a lot of other documents. requirements sorting jason: keep it simple. bob: numberings just for keeping track of important issues. matrix with function vs. reqs, possibly multi-dimensional. rohan: why the categories? bob: because bhatia draft outlined functional categorizing. rosenberg: content needed. influence on deliverables - task over next year. henry: compliance with internet architecture (end to end principle?) inital answer: would be assumed henry: lot of drafts from PSTN world, which assume not end to end openess. meyer: throw reqs content over to natale? penn: one reqs would be good. start from that smaller set of reqs, and build up. jonathon: too early to merge stuff, because we just discuss what the problem is. jason: should reqs extracted from terminology draft? rohan: agree, look at reqs when we have more content, premature? Domain Policy Drafts ==================== Title : The Domain Policy DDDS Application Author(s) : O. Lendl Filename : draft-lendl-domain-policy-ddds-00.txt Pages : 13 Date : 2006-2-27 This documents proposes the use of the DNS to publish a domain's policy regarding incoming communication. The algorithm used is defined as a new application of the Dynamic Delegation Discovery System (DDDS). Such policy announcements can be used to facilitate selective SIP peering. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-lendl-domain-policy-ddds-00.txt Title : Federations for the Domain Policy DDDS Application Author(s) : O. Lendl Filename : draft-lendl-speermint-federations-00.txt Pages : 7 Date : 2006-3-1 This documents defines the policy-type for federations within the Domain Policy DDDS Application. Using this policy-type domain-owners can announce their membership in a federation and thus their willingness to accept incoming communications according to the rules of that federation. Such federations can be used to establish selective peerings e.g. in the Voice over IP and Instant Messaging space. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-lendl-speermint-federations-00.txt jonathan: doesnt solve spam/spit - bogus alex: but policy about spit can be announced ??: federations: definition important - one definition needed. henry: propose to declare this out of scope, because this is not open internet. alex: we don't exclude the private user - federation could be sinnreich.com penn pfautz: mandatory or optional? optional. rohan: people who don't want to peer openly also don't want to announce their federation memberships. and could query that information out of band. think that this is clearly out of scope. privacy not covered. ??: abuse handling highly regulated. need to investigate if that is about peering jonathan: what problem is being solved here? call acceptance is more complex than could ever be published. you can never be sure that calls are being accepted. ??: policy extends to end users as well, probably. this does not extend to a per-user policy. stastny: henry might be right that this is out of scope, but then the whole WG is out of scope of the ietf... haberler: this is fine to be used for not just service providers. policy disclosure: "Bt carrier club" might not be a surprise. no clear hum whether should or should not be WG item. take to list. rohan: what is the milestone we solve? Route Policy and Architecture ============================= Title : Route Policy and Architecture in SIP Peering Environments Author(s) : M. Bhatia Filename : draft-bhatia-sip-peering-00.txt Pages : 12 Date : 2006-3-2 The purpose of this document is to help the IETF community understand the route architectures being used today in SIP based peering environments and to outline a set of requirements based on the same for discussion within the community. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-bhatia-sip-peering-00.txt --- eli: different federations in last presentations. from adhoc to "closed shop" - scope concept of federations? penn: access issue resolved, but why mention "access peering"? routing policy might depend on who the source is. schwartz: volunteers to do use case documents for federations. dary elis: speermint vs. enum? IP Service Peering Architecture ================================ Title : IP Service (Voice and Multimedia) Peering Architecture Author(s) : S. Khan Filename : draft-khan-ip-serv-peer-arch-00.txt Pages : 7 Date : 2006-3-3 This document pictorially depicts IP Service (Voice + Multimedia) provider network functional components, peering interface functions, and an IP Service (VM) providers? peering reference architecture. The draft also calls for developing separate requirements for different types of peering. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-khan-ip-serv-peer-arch-00.txt --- different interfaces have diff. peering requirements stastny: where is the internet? is ietf going to redefine ims? penn: dont see peering at any layer here. daryl elis: would like to see innovative things here, and not repeat other mechanisms. henry: dimension of mobility brought here. mobile users need to be recognized in foreign networks. sohel: intention to include mobile and moving around. jon: language not ietf-like. that space needs to be studied, seen a lot of different perspectives. how can we destill this into extraordinary new things? meeting concludes.