2.7.19 VoIP Peering and Interconnect (voipeer)

NOTE: This charter is a snapshot of the 63rd IETF Meeting in Paris, France. It may now be out-of-date.

Last Modified: 2005-07-22

Chair(s):

Dave Meyer <dmm@1-4-5.net>

Transport Area Director(s):

Allison Mankin <mankin@psg.com>
Jon Peterson <jon.peterson@neustar.biz>

Transport Area Advisor:

Allison Mankin <mankin@psg.com>

Mailing Lists:

General Discussion:
To Subscribe:
Archive:

Description of Working Group:

No description available

Goals and Milestones:

No Current Internet-Drafts

No Request For Comments

Current Meeting Report

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 Faltstrom):

          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

Slides

Agenda
Probem Statement
Session Border Controllers
Issues in Numbering, Naming and Addressing
ENUM Update
PCH's Operational Experience with VoIP Peering
Service Provider Perspectives on voipeer
A Broadband Service Provider's Perspective on VoIP Peering
Peering Architecture
SIP Forum Tech WG: IP PBX to Service Provider Interoperability Task Group
Input on Inter-domain SIP Requirements for VoIP Peering