VoIPPeer BOF Notes
VoIP Peering and Interconnect (voipeer) BOF II|
THURSDAY, November 10, 2005 0900-1130 (Morning Session I)
CHAIR: David Meyer <firstname.lastname@example.org>
Notes: Spencer Dawkins <email@example.com>
- Mailing list: firstname.lastname@example.org
- Blue Sheets
o Charter Discussion
- Slight rearrangement from what's on the website, but no changes
- 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
- 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
- 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,
- 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
- Cablelabs - proposed charter also includes PSTN administrative
- 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
- Alex - is discovery of policy in scope?
- Jon - seems a lot wider than what I thought the draft charter was
- Alex - where is discovery of policy in scope?
- Jon - don't think we should do a full investigation, this is a
- 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
- 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
- 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
- Jon - signaling may not be same as media
- Steve - transit between administrative domains?
- David Meyer - whole notion of "VoIP transit provider" is not
- 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
- CableLabs - need recommendations that give us flexibility in
implementations. Calls break today. We need to make recommendations to
- Jon - interoperability is a SIP responsibility
- David Meyer - we can feed requirements to appropriate protocol
- 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
- 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
- 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
- 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
- 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 ...
- 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
- 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
- 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 What's in a
- "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
Next steps - AD agreement, start doing work.
- 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
- "SPEER"? as working group name? Sense of the room is "this would
- 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?