VoIP Peering and Interconnect (voipeer) BOF II

THURSDAY, November 10, 2005 0900-1130 (Morning Session I)
=========================================================
CHAIR: David Meyer <dmm@1-4-5.net>
Notes: Spencer Dawkins <spencer@mcsr-labs.org>

AGENDA

 o Administriva                             5 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                                                5 minutes
    Meyer                                           

• Slight rearrangement from what's on the website, but no changes
  

 o Charter Discussion                        60 minutes
    Meyer/all

• What's in scope, what's out, interaction with ENUM
• What's out of scope - properties of "interconnecting links"? "profiling of existing protocols?" "routing sessions that are not signalled using SIP?" "SPIT prevention?"
• SPIT prevention is a key thing to do - what about other working groups in the area?
  
• Cullen - SIPPING is a fine place to do the work.
• Dave Oran - SPIT prevention could suck a lot of time for the group.
• Gonzalo - we are working on this in SIPPING
• Large overlooked topic areas that need to be out of scope?
• What's in scope? call-routing architectures for delay-sensitive "real-time" communications using SIP
• Dave Oran - this is larger than what we need - "between administrative domains"
• Richard - why only "delay-sensitive" - anything using SIP, can't know this in advance
• "Interprovider communications?"
• Henry - avoid carrier AND provider terms, can have enterprises, etc.
• Lane - what about media? SIP and media aren't same IP addresses or same flows, would be helpful to unterstand dependencies
• What is the definition of "call"? 3261, establishing sessions with SIP
• Cablelabs - proposed charter also includes PSTN administrative domains?
• Specifications of various types of packet flows
• Documentation of requirements for feedback of operational conditions, especially for anythign that enables dynamic policy
• Dave Oran - understand requirements for instrumentation, but don't understand how this interacts with policy
• CableLabs - don't understand what should really be in scope on instrumentation - service metrics? Between administrative domains?
  
• Cullen - "dynamic policy" is wiggly and meaningless - can we nail this down a bit?
• Robert - still confused about what's "in scope"
• Khan, Sprint - Two domains with different policies, how do we map between them? Would like this to be in scope
• Jon - I read this more as "monitoring and management", you're describing something difficult and complex, I'd like something achievable
• Alex - is discovery of policy in scope? 
• Jon - seems a lot wider than what I thought the draft charter was about
• Alex - where is discovery of policy in scope?
• Jon - don't think we should do a full investigation, this is a potential rat-hole
• Jonathan - agree with Jon on policy topic - we have ENUM now, and we see more than that being handled by existing protocols
• Dave Meyer - make dynamic policy out of scope?
• Alex - then where does this happen? we have millions of administrative domains, how do we even discover the policies?
• Jon - but we don't have policy discover for e-mail now...
• Steve Silverman - when networks peer, they pass information. Is all that in scope? Accounting information (which is standard in the Voice world, for a long time, which isn't going away)
• Dave Meyer - had call detail, auditing, etc. in original charter
• Avaya - this is VoIP peering, or any SIP application - video, or what?
• Gregory - I thought "dynamic policy" was one side of a peering arrangement enforcing policy based on changes from another peer
• David Meyer - we're not defining policy here
• Richard - VoIP peering is all about policy, if we take this out of scope, what else are we doing?
• David Meyer - we're doing requirements, not a protocol for policy
  
• Tim - including subscription to presence, etc.?
• Jonathan - should be included, very closely tied to traditional calling (callback, etc.) that doesn't interoperate in the PSTN because of the complexity - it would be good to do this better
• Heshem - what about other services, push-to-talk, etc.?
• Lane - use cases are late in the game? (deferred until later in the section)
• David Meyer - include subscribe-notify?
  
• Paul - there was a lot of discussion about policy, can you clarify the scope of policy?
• Jonathan - not in scope to define optimizations for subscribe/notify here - maybe requirements, not protocols
• BCPs on exchange of calls among VoIP administrative domains
• Dave Oran - SIP forum is completing work on how enterprise administrative domain connects to service provider - similar but not the same, should look at the work being done there
• Gregory - explicitly address enterprise-to-carrier here?
• David Meyer - trying to stay away from words like "carrier"
• Gregory - use cases give you different requirements
• Jon - SIP Forum work is pretty narrowly focused
• ??? - include subscriptions between domains, not just calls
• Ted Hardie - need to at least distinguish between ISP-VSP and ISP plus VSP
• Jon - signaling may not be same as media
• Steve - transit between administrative domains?
• David Meyer - whole notion of "VoIP transit provider" is not well-formed
• David Schwartz - need to do what Ted said in use cases
• Henry - "who owns the layer two access to the Internet" - don't want to imply that blocking services is palatable. Also, codec negotiation is between endpoints - we're talking about restrictions, what is being enabled?
• CableLabs - focusing on ISP interaction in GeoPriv, don't need to go beyond this - different providers with different expectations is focus of BCPs
• Richard - don't understand why this stuff makes a difference above layer five peering
• Martin - what is impacts on ordering and billing? have to understand model of relationships at layer 2, 3, 5, may have multiple relationships at different levels
• David Meyer - if we took that on, what could we accomplish in this working group? Layer five gives us the most traction, it's not the only thing that matters
• Jonathan - if we can't we do SIP without looking lower, IP has failed as an architecture. Please remember that most SIP mechanisms work end-to-end, mandating service provider support for them is meaningless
• CableLabs - need recommendations that give us flexibility in implementations. Calls break today. We need to make recommendations to make progress
• Jon - interoperability is a SIP responsibility
• David Meyer - we can feed requirements to appropriate protocol groups
• Sprint - as a service provider, we support lots of applications and lots of different kinds of policies, and need to look at a lot of things at PEPs
• Cisco - useful to separate out layers, but concerned that lower layers aren't benevolent. network operators think about who is paying for polite resources
• ??? - the IP network has policies and peering and service levels in place now, we're trying to make sure policies are applied correctly, not make up new ones. Make sure the Internet is used right
• Ted - we could do everything at layer five (SIP) - not saying that we couldn't do that, but it might be more useful to notice when SIP is tightly tied to lower layers and when it is not. Taking these realities into account will give users a better experience
• Henry - argument presented is broken. Customers connect using many different link layer types, service providers should not restrict their customers to a single type of link layer. You already pay for access to the Internet through that access layer now.
• Ted - should take media into account, but I'm talking about ECRIT - if you know layer two information, you can do ECRIT directly, if you don't, you can't do it directly. Need to take this difference into account.
• Dave Oran - look at this stuff through clean abstractions, not layering violations or state sharing. Can't say "always believe the link layer" - customer may actually be doing something you don't understand, and they're right when they don't agree with the link layer. Having a direct BGP peering allows you to do different things than wehen you don't have it - this is an example of why looking around helps.
• Patrik - lots of different kinds of peering, including mixes - how many different mechanisms, which do exist, do we take into account?
• Jonathan - agree with Ted but believe this is out of scope because ECRIT is intra-domain. BGP peering is interesting, but would like to rule this out of scope for now, just to focus on general case first. If you have BGP you can do fast SIP rerouting, but that's not the only way you can do fast SIP rerouting
• Richard Shockey - agree with Dave Oran, especially if we're talking about congestion of large bandwidth link
• Cablelabs - have discussed this a lot at Cablelabs, and like Diffserv QoS markings, and this is being discussed in TSVWG
• ??? Internet is interesting, but it's not the only interesting thing. If you are willing to hold your nose and look at walled gardens, you can probably do better
• Richard Shockey - don't like world hunger charters, but if we don't look at layer 2-layer 5, why are we here?
• Jon - people have looked at this before, and it isn't going to be solved here (MLPP, for example). BCP document could refer to work like that, but we don't need to do the protocol work here.
• Sense of the room on considering use cases that also include layer 2/3?
  
• Dave Oran - describe layer 5 first, and then recharter? We will rathole on the complicated cases and do nothing on the simple ones. Point to potential rechartering in proposed charter, have a roadmap
• Richard Shockey - "temporarily out of scope, but compelling use case"?
• Sense of the room on considering use cases that also include layer 2/3? consensus of room is to add escape clause
• Is this a MAY or a MUST to do later work? Rechartering is always on the table
• Others? Seem to have already covered this
  
• Division of labor with ENUM - ENUM does E164 mapping to URIs, VoIPPeer is the use of that mapping in signaling and routing real-time sessions? sense of the room is "yes"
• Deliverables - without authors ... or dates ...
  
• Teminology
• Reference architecture
• Call flows
• Use of DNS SRV and NAPTR records as in RFC 3263
• Minimum set of requirements for interconnection
• Addressing forms and provision of strong identities
• Use cases
• ??? - are security and privacy in-scope?
• Cullen - of course we're going to look at security, we have to, in every document
• Chris - get mediation, settlements, etc. in call detail accounting
• David Schwartz - privacy considerations for competing providers
• Steve - billing is to customers, accounting is to peers, be very clear about this
• David Meyer - push accounting to futures?
• Martin - need to look at what information needs to be passed at interconnection points, or no one will interconnect at all
• Sense of the room is that we push accounting to futures? no consensus
• Jonanthan - do the minimum thing, call ID? that's already hard, we have multiple headers to choose from, can we pick one?
• Heshem - service providers will bill each other, not just users. Accounting is important
• Steve Silverman - in much of the world, voice billing is a major source of revenue.
• Jon - we have traditionally said, as a mantra, that billing is out of scope at the IETF. There will be billing on these networks, just not with anything we define here.
• Cablelabs isn't even using its own headers for call-ID. This is not in scope for voippeer.
• Richard - need to have protocol support for accounting, but we don't care how accounting is done
• Jonathan - we have ignored this, there are access-specific mechanisms that don't interconnect now. Let's do requirements here and send them to SIP. All we're doing is defining a call identifier as a hook.
• Cullen - everyone still has to deal with this, there's weird positioning and elephant-ignoring. Admit all this up front.
• David Meyer - do people think requirements for call ID is in scope? Sense of the room is "yes"

 o Terminology                            10 minutes
    draft-meyer-voipeer-terminology-01.txt   
    Meyer/all

• "Carrier" term needs to go away - don't need to understand business models to do what we do
• Lane asked that we don't define everything about the Internet use case and forget other use cases, and pigeon-hole ourselves
  
• David Meyer - but we look at the Internet, right?
• Henry - carrier is a legitimate business, and so are others. We don't have the skillset to think about business models at the IETF - this is out of scope for the IETF
• David Meyer - we'll discuss this on the list (as Lane has been doing)
  

 o What's in a name?                                             5 minutes
    Meyer

• If we get chartered, do we want to change the name?
• Generalize from Voip to "real-time"? RTCSP?
• Steve Silverman - networks peer, they don't voice-peer (but they may not do e-mail peering...)
• ??? IM was presented in SIPPING at IETF 63, and the work was sent here, so...
• "SPEER"? as working group name? Sense of the room is "this would be lovely"

Next steps - AD agreement, start doing work.

• When do we get a new charter? Probably next week
• Jonathan - we have documents, but our structure will probably change. Deliverable for BCPs on what we're talking about, in case we get one document coming out?