Skip to main content

Concluded WG VoIP Peering and Interconnect (voipeer)

Note: The data for concluded WGs is occasionally incorrect.

WG Name VoIP Peering and Interconnect
Acronym voipeer
Area Transport Area (tsv)
State Concluded
Charter charter-ietf-voipeer-01 Approved
Document dependencies
Personnel Chair David Meyer

Final Charter for Working Group

The term "VoIP Peering" has been used to describe many different
aspects of provider interconnect and the delivery of SIP call
termination over that interconnection. Further, since VoIP peering
focuses on how to identify and route calls at the application level,
it does not (necessarily) involve the exchange of packet routing data.
Given that VoIP peering is about routing calls, it includes (among
other things) the accounting of costs that may be incurred in the use
of any of these routes, the actual transport protocol of those media
streams (or the details of those media streams), the IP network or
criteria for the transport IP network,the signaling protocol that is
used for transporting call-routing information, etc. Thus, given the
broad scope of the topic, this BOF proposes to focus on the following

(i). To initiate long term discussion on VoIP Peering and Interconnect
among the Internet's operational community, with the goal of
understanding the existing and future requirements for VoIP Peering and
Interconnect. In particular, since VoIP peering is really about how to
identify and route calls at the application level, it brings
requirements from both transport providers and application vendors, as
well as many other third parties. One possible outcome of this would
be to charter a VoIP Peering and Interconnect Working Group (area TBD).

(ii). To address the near-term need to document the requirements and
associated use-cases for VoIP interconnect. Such requirements can be
used to inform protocol groups working on relevant protocol mechanisms.

The focus of the proposed work will be on documenting VoIP Peering and
Interconnect use cases, defining their requirements, and describing
what can be done in support of those use-cases and requirements with
the Internet technology (and its dual, namely, what can't be done with
the Internet technology).

Issues for voipeer include (but are not limited to):

(a). Call Routing

That is, how to figure out who to route calls to. Options include SIP,
ENUM (public v. private ENUM, carrier ENUM, etc). Further, several
protocols have been proposed to carry enhanced call routing
information, such as RFC3219 (TRIP). Are these necessary, and if so,
are there complexity concerns?

(b). ENUM

How ENUM is currently being deployed/used, what are the barriers to
deployment, if any, and how can we further facilitate its deployment.
Other related topics include number portability, as well as directory
and other enhanced routing requirements.

(c). Security

Includes topology and provider hiding, DoS prevention, authorization,
and VoIP Spam mitigation (e.g., SPIT).

(d). Accounting

That is, how to track calls made to and from each peer, including TOD,
duration, packets send and received, etc.

(e). Audit

Including how to determine where in the call path a fault lies, per-
call accounting of call quality (most providers are looking for end-to-
end call quality). Accounting of ASRs (and other PSTN call metrics,
for PSTN termination peers only).

(f). PSTN Fallback

Issues here include what to do if the IP network is congested, how to
do PSTN fallback, and interaction with call routing and IP network
congestion measurement and monitoring.=20

(g). Feature Interoperability=20

(h). Lawful Intercept

Will be discussed within the IETF's RAVEN principles.

(i). Interaction of (a)-(h) with current/future Session Border
Controller (SBC) deployments