# # David Meyer # dmm@1-4-5.net # Mon Aug 15 09:12:43 2005 # # $Header: /home/dmm/public_html/IETF/IETF63/VOIPEER/slides/RCS/voipeer.minutes,v 1.3 2005/08/15 16:12:56 dmm Exp $ # Voipeer Working Group Meeting Minutes Wednesday, 3 Aug 2005 Chair: David Meyer, dmm@1-4-5.net Scribe: Ed Guy, edguy@pulver.com Materials: http://www.1-4-5.net/~dmm/IETF/IETF63/VOIPEER/slides Agenda ====== VoIP Peering and Interconnect BOF (voipeer) THURSDAY, August 4, 1400-1630 (Afternoon Session I) --------------------------------------------------- CHAIR: David Meyer AGENDA o Administriva 0 minutes - Mailing list: majordomo@lists.uoregon.edu subscribe voipeer or visit http://darkwing.uoregon.edu/~llynch/voipeer.html - Scribe(s)? - Blue Sheets o Agenda Bashing 0 minutes Meyer o Purpose and Objectives + Overview 10 minutes Meyer o SIPPING update/overview 10 minutes Camarillo o ENUM Update/Overview 5 minutes Shockey o Issues in Numbering, Naming and Addressing 10 minutes Stastny o Service Provider Perspectives 60 minutes Bill Woodcock (PCH) Alan Duric (Telio) Martin Dolly (ATT) Jason Livingood (Comcast) Joao Damas (ISC) Sohel Khan (Sprint) o SIP Forum Tech WG IP PBX to SP Interconnect Update 5 minutes Mahy o CableLabs - Experiences with the SIP CMSS spec 10 minutes Mule o Discussion 30 minutes Meyer/All o Next Steps 10 minutes Meyer Decisions ========= * There is clear interest in continuing work in this area. However, the scope needs to be refined. * Focus on Layer 5 VoIP Peering (not Layer 3). That is, "VoIP Peering" is an overloaded term (to be changed in future version of this BOF/WG), and in particular, "VoIP Peering" occurs above layer 3. A perhaps more suitable definition of VoIP Peering is (given later by Patrik Fältström ): Given you have two VoIP providers that each have customers. What is the best current practice regarding exchange of calls between these two VoIP providers. Action Items ============ * Group to develop Terminology, Scenarios and Use cases * Hold another BOF at the Vancouver IETF with the goal of producing a tighter charter, as well as a terminology document (and possibility a few use case documents) * Write to the Mailing List! Detailed Meeting Notes ====================== * David Meyer -- presented: * Introduction * Agenda bashing. 0 minutes *Jon Peterson -- presented: * Voip Peering & Interconnect issues are happening in many groups * Charged group to identify pieces, problems * Please focus on the VoIP peering requirements *David Meyer -- Presented Overview: What's the problem? * Routing * Identify * Security * Law Enforcement Access & intercept Goals: * Provide forum for long term discussion among VoIP operations * Understand current and future requirements holistically * Focus on requirements: * Gonzalo Camarillo -- Sipping/SBCs * Operators use SBC to hide topology of their network. * SBCs perform Protocol repair, TLS * Load Balancing * v4/v6 inter-working * But, SBCs may cause Problems: o may break e2e confidentiality, negotiations, *Richard Shockey* - ENUM Update (presented from slides) * Gave quick overview of ENUM * Listed active delegations of e164.arpa * Discussed Apricot 205 - using enum * North American ENUM delegations will be active this year! * Wireless carriers have been using ENUM for MMS * Carrier ENUM can be used for o IP transition o replacing tcap/ss7 o separate number holder from number carriers o move to "Transit/Peering model" from current PSTN transport model. *Richard Stastny* (presented from slides) * Internet is end-to-end over a "stupid"network. * Cost/qos/improved functionality lost when there is no e2e IP * Types of voip o free/open o ...something in between o carriers * How to route VoIP calls? * "how public is public?" -- builds case for e.164, and/or Address of Record URI * [group] must produce scenarios and develop requirements for VoIP peering. *Topic **Service Provider Perspectives* * Bill Woodcock (14:30) (PCH) o Operates Global Hot line System - about 1800 organizations + ASNs are used for dialplan o Participants provide own gateways o ENUM is good from carrier point of view o voip peering is not an IP exchange although many think so, o Observations + ITU dealt out by being "obstructionists" + All significant VoIP peering is non-e164.arpa + many "clubs" have formed. -- they must be unified. + VoIP is L5/ IP. Traditional peering is Layer 3. Note: Peering is a loaded term and traditional peering is layer 3, ie IP packet peering. VoIP peering involves session establishment, and VoIP traffic exchanges and protocol interworkings above layer 3. o 'news' businesses followed similar path (of mixing levels) o other extreme - special boxes are needed - wrong approach! * Alan Duric (telio.no) (From Slides) o Telio overview o Perspective + Peering is needed. But must be free. + Bilateral agreements are not effective + Motives: # Primarily rich content # Financial o Needs + no SPIT + Security and encryption (SRTP, TLS) + Privacy and anonymisation + Service transparency of new services + Seamless + no new boxes. * Martin Dolly, ATT Labs o uses VoIP (internally, form a long time) o needs + VoIP call routing # example Call Vantage to Vonage + "carrier ENUM" + interoperability + certification and compliance testing + profiles/interface specs ala cable labs + 911/Emergency Service + Note: QoS may impact more than just voip-peers. + Priority on packets wrt 911 + American Idol causes 20 Million BHCA [perhaps "Idle" is not the right term"] + S/BC (session Border Controllers) + Timely delivery of new features - needed. + Identity assurance + Service provider interconnect specs Clarifying question: which are the interconnect issues? how prioritize? Richard Stastny: How many interconnect hierarchies are there? A: ATT operates on many business levels. examples given. No level distinction. Q: Is RFC insufficiently specified? A: sip interop problems exist. A: Is ATT deploying Internet-Drafts? A: yes. * Jason Livingood (Comcast) o Comcast overview 7-8 Million subs o Context: + codec conversions degrades QoS, feature, + regulations on VoIP are lighter + services not limited by narrow band width + have many VoIP islands -- Using ENUM to integrate o Working with cable labs on ENUM, both private and public. o Private enum doesn't scale. Public ENUM is goal o asks "is user enum business model broken?" o Peering + Best effort + Public Peering points - IP exchange points + Private Peering Points QoS/Capacity o Challenges: + provisioning/security of public tree + normalization of SIP profiles + trust at edge + Law intercept + Route Selection + PSTN fail-over + SBCs longterm goals? o VoIP is about much more than saving money! * J Dumas, ISC (not present due to BOF scheduling changes) * Sohel Khan, Sprint, TR&D o We are a Wireless company doing VoIP peering internationally o introduced terms, to be explained. + Access Peering - + Network Peering - o Need voice and multimedia VoIP peering (at layer 5) o Model divides peering into 4 layers: + Signaling layer + Media Layer + Routing Layer + Admin layer (mediation, ENUM, CALEA) o Issues: + minimize cost + scalability + complexity + multimedia o Gave IMS architecture comparisons Richard Stastny: will this "1000 box" approach minimize the cost? A: this is just a model. Troy Dixler (Motorola): Q: Is IMS Architecture appropriate for this discussion? A: we need to focus on Requirements. * Rohan Mahy, Sip Forum Tech WG chair * New sip forum WG group formed * Charter is to produce document specs on how to interconnect that compliment IETF specs * Task Groups o IPPBX to SP task group. + www.sipconnect.info update/replacement o IP Phones/IPPBX * Please Get Involved!! See http://www.sipforum.org/content/view/28/139 for additional information Richard Stastny: Q: what about pbx-to-pbx? A: members need and ready on pbx-to-SP Q: What about QoS A: unsolvable at L5 An informal poll of attendees was taken: TLS is not implemented in production. * Jean-Francois Mule, Cablelabs * Gave PacketCable CMSS overview * Sip RFCs are not enough - must provide additional specs That is, SIP RFCs provide technical solution to specific requirements; additional specs are required to "assemble" SIP RFCs to meet various interconnect requirements based on interconnect use cases. * Use cases: o Intra domain o SIP to PSTN o Inter-SIP carrier (trusted) o Inter-SIP carrier (untrusted) * problem is likely to get worse o Cable labs is considered "industry specific" o some have implemented draft versions * discussed guidelines for diffserv profiles The point here was to react to the many comments that QoS cannot be solved for VoIP interconnects or VoIP peering. See statement in the notes about "Unsolvable at L5". The following draft makes configuration guidelines for VoIP bearer and signaling streams: http://www.ietf.org/internet-drafts/draft-ietf-tsvwg-diffserv-service-classes-01.txt are those followed by VoIP providers or end-users? when exchanging VoIP traffic between 2 domains, what happens to this diffserv marking? While it is going to be difficult to come up with 1 answer, it may just help to make sure folks know this soon-to-be RFC in the VoIP world and design their VoIP networks in ways that facilitate keeping some of that DSCP marking across boundaries (should the administrative policies or interconnection agreement allow it). * implementors need guidance on how to operate in multi-sip extensions environment Various discussions/Conclusions ================================ * A Common language is needed. * Use cases must be defined and scoped. * Then develop requirements Penn Pfautz, AT&T Provided definition: "Exchange of VoIP Traffic Between Carriers" he discussed "Bill and Keep model" vs "transit service" and vs enterprise interconnect. Spencer Dawkins: Compliance has been a real problem! He saw the first conforming RTP stream two months ago Concerned that SBCs will mask problems, but increase complexity. Rohan Mahy: Concerned scope is too broad. Need scope and terminology document. Sohen Khan, Sprint. Video peering is needed. Jonathan Rosenberg/group proposal: * define VoIP Peering o bilateral o open access * document Best Current Practices * e.g., SPAM is problem, Use TLS, (Really!!) Tom Taylor: * goal: industry wide consensus Ken Cartright, Versign VoIP Peering Fabric Q: Is Provisioning side of VoIP Peering in scope? He is Creating Provisioning protocol for Versign peering. Troy Dixler: Transitive [calls] are even more complex then peer to peer. Robert Sparks (Sip Forum) * Discussed Sip Forum working group that runs sipit. * "if a vendor participates in SIPIT, it is an indication they take interoperability seriously." (??? No Name given or captured) * IETF should not define NGN architecture * It should define networks that NGNs can run on. Spencer Dawkins * Agreed with SIPIt observation, but, SBCs do "protocol repair" -- this is a concern - it is a temporary solution and introduces more complexity. Eli Katz [etg - from slides?] Xconnect currently connects 25-30 International Carriers * Need RFC to support Carrier ENUM * Provisioning System * Interoperability * see www.SPITprevention.net Group discussion ================= Need to define usage scenarios * E.g.. OSP token in SIP and two or more other mechanisms for accounting are being addressed in different groups The 3 potentially related mechanisms are: - draft-johnston-sip-osp-token-06.txt - RFC3603 and p-dcs-billing - RFC3455 and p-charging* * Interoperability testing - Jonathan Rosenberg: Protocol repair should be out of scope! Discussed how, for instance, security expands to specific system-level requirements, which should reference existing Specs... This is not a new architecture, it is interconnect. Q: would BCPs be useful? Richard Stastny: Is a home user a carrier? Is this in scope? Jiri Kuthan, IPTEL, need scope before determining if BCPs are useful? _It was agreed that the Scope is "layer 5 interconnect" _ Bill W???. BCP are useful as long as we can avoid being hijacked [politically] Richard Shockey: No New Protocols are needed. But, current practices are not best! Dave ???, BT. avoid OFCOM - - avoid regulation issues Cullin Jennings: Need crisp scope. Rohan Mahy makes a concrete proposal: Scope: carrier to carrier VoIP at layer 5 Accounting and QoS out of initial scope. Sake ???, (Japan.) There are many SIP misunderstandings in the implementations. BCP documents are very valuable. Spencer Dawkins: proposes not doing a protocol spec. this should be an operations group. The question was raised by chair: "Is there interest in Continuing Activity on VoIP Peering?" _There is clear interest in continuing this effort._ Plan to write use cases and terminology plan for BOF meeting at Vancouver IETF in November. Jon Peterson adds a footnote to the meeting:. "We want You" to write to the mailing List. Meeting called to an end a few minutes past the scheduled time