|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| Real-time Applications & Infrastructure (RAI) area |
|
|
|
|
|
|
|
##
##
##
##
##
##
##
##
##
##
##
##
##
##
##
## SPEERMINTwg
##
|
|
|
|
|
|
|
|
|
Last Update: May 9, 2008
-- Color Legend: RFC Editor Queue
/ Processed by IESG
/ ID Exists
/ Recently Expired
-- Each I-D name is a link to an I-D description, which points to a text version, a two-page and fit-in-window PDF version, as well as the IETF Tools' HTML version.
|
|
|
|
|
|
|
|
|
|
|
| Real-time Applications & Infrastructure (RAI) area |
|
|
|
|
|
|
|
##
##
##
##
##
##
##
##
##
##
##
##
##
##
##
## SPEERMINTwg
##
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| Real-time Applications & Infrastructure (RAI) area |
|
|
|
|
|
|
|
##
##
##
##
##
##
##
##
##
##
##
##
##
##
##
## SPEERMINTwg
|
|
|
|
|
|
| The charter of the SPEERMINT working group
is reported below.
|
|
|
|
The term "VoIP Peering" has historically been used to describe
inter-provider network interconnect and the delivery of voice
calls over interconnection points. While voice calls are the
primary motivation for this today, other forms of real-time
communications are and will continue to evolve as natural
additions to such peering. Therefore, the focus of this working
group is best generalized to describe calls as sessions, and to
note that that such communications are inherently real-time in
nature.
The Session PEERing for Multimedia INTerconnect (SPEERMINT) working group
focuses architectures to identify, signal, and route
delay-sensitive (real-time) communication sessions. These sessions
use the SIP signaling protocol to enable peering between two or more
administrative domains over IP networks. Where these domains peer,
or meet, the establishment of trust, security, and a resistance to
abuse and attack are all important considerations.
Note that the term "peering" is used here to refer to
the interconnection between application layer entities such as
SIP servers, as opposed to interconnection at the IP network
layer. However, in order to achieve real-time Session PEERing,
both signaling and media flows must be taken into
consideration. In addition, the working group recognizes that
there will be use cases that require SPEERMINT to focus on the
interaction between the application layer and lower network
layers, or the dependence of specific application layer use
cases on lower layers, so SPEERMINT will have to be prepared to
solve these problems as they arise.
More specifically, SPEERMINT focuses on real-time session
routing architectures and their associated use cases.
Deliverables here include the specification of the various
types of application flows, such as signaling and media flows, in
such networks, and includes both trunking and peer-to-peer
flows. In addition, SPEERMINT considers and documents requirements
for the feedback of operational conditions (e.g., congestion control)
that enables the application of dynamic policy and recognizes
that various mechanisms for achieving this should be studied as
a potential part of any architecture. In future, as its initial
work completes and the requirements become known, SPEERMINT may seek
rechartering to consider various mechanism to support applying
Quality of Service and/or traffic engineering mechanisms in an
architecturally sound way in support of real-time Session
PEERing. A charter discussion would consider how to work with
with mechanisms developed by other working groups, selecting
and integrating those, but as stated, first the initial milestones
must be completed.
The most focused deliverables of SPEERMINT are best current practices
regarding exchange of real-time sessions among VoIP and other
real-time application service providers and, in particular, how
such calls are routed. SPEERMINT will recognize that some of these
providers also control underlying access networks
(facilities-based), while others do not (not facilities-based),
and this fact may present various additional requirements or
use cases for consideration. The working group will develop
one or more use case documents to record the varieties of
the practices, as well as use this recognition as a guide to
maintaining the greatest possible separation of the application
layer from lower layers.
The SPEERMINT work plan is related to and distinct from the work
plans of the ENUM and SIPPING working groups. While the
the ENUM Working Group is primarily concerned
with the structure and lookup of data for the translation of
E.164 numbers into URIs (RFC 3761), SPEERMINT is concerned with
the use of the resulting URI data, as well as non-ENUM-derived
URI data, for use in signaling and routing of real-time
sessions. The SIPPING WG produced the original document in
this area (RFC 3824). The future work in this area will be
produced by SPEERMINT, but RFC 3427, the SIP change process will
be followed as needed.
|
|
|
|
|
|
| Real-time Applications & Infrastructure (RAI) area |
|
|
|
|
|
|
|
##
##
##
##
##
##
##
##
##
##
##
##
##
##
##
## SPEERMINTwg
##
|
|
|
|
|
|
|
|
| -
|
|
|
|
|
|
|
| Real-time Applications & Infrastructure (RAI) area |
|
|
|
|
|
|
|
##
##
##
##
##
##
##
##
##
##
##
##
##
##
##
## SPEERMINTwg
##
|
|
|
|
|
|
|
|
|
|
|
|
| |
| Up List |
Intended Status: | Informational |
|
|
|
|
|
|
|
|
|
|
| |
| Up List |
Intended Status: | Informational |
|
|
|
|
|
|
|
|
|
|
| Real-time Applications & Infrastructure (RAI) area |
|
|
|
|
|
|
|
##
##
##
##
##
##
##
##
##
##
##
##
##
##
##
## SPEERMINTwg
##
|
|
|
|
|
|
|
|
|
|
| | |
speermint-
architecture-06
ID Exists
May 2, 2008
(21 p.)
[pdf(2)]
[html]
|
R. Penno
D. Malas
S. Khan
A. Uzelac
M. Hammer |
|
SPEERMINT Peering Architecture |
|
This document defines the SPEERMINT peering architecture, its
functional components and peering interface functions. It also
describes the steps taken to establish a session between two peering
domains in the context of the functions defined.
|
|
|
| |
| Up List |
Intended Status: | Informational |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
| Up List |
Intended Status: | Informational |
|
|
|
|
|
|
|
|
| | |
speermint-
srv-naptr-use-02
ID Exists
Nov 10, 2007
(11 p.)
[pdf(2)]
[html]
|
T. Creighton
J. Livingood |
|
Use of DNS SRV and NAPTR Records for SPEERMINT |
|
The objective of this document is to specify the Best Current
Practice (BCP) adopted by a service provider providing multimedia
communication services such as Voice over Internet Protocol (VoIP) in
order to locate another service provider to peer with in the context
of Session PEERing for Multimedia INTerconnect.
|
|
|
| |
| Up List |
Intended Status: | Best Current Practice |
|
|
|
|
|
|
|
|
| | |
speermint-
voip-consolidated-
usecases-07
ID Exists
May 8, 2008
(26 p.)
[pdf(2)]
[html]
|
A. Uzelac
Y. Lee |
|
VoIP SIP Peering Use Cases |
|
This document depicts many common VoIP use case for SIP Peering.
These use cases are categorized into static and on-demand, and then
further sub-categorized into direct and indirect. These use cases
are not an exhaustive set, but rather the most common use cases
deployed today. This document captures them to provide a reference.
|
|
|
| |
| Up List |
Intended Status: | Informational |
|
|
|
|
|
|
|
|
|
|
| Real-time Applications & Infrastructure (RAI) area |
|
|
|
|
|
|
|
##
##
##
##
##
##
##
##
##
##
##
##
##
##
##
## SPEERMINTwg
##
|
|
|
|
|
|
|
|
|
|
| | |
lendl-speermint-
background-01
ID Exists
Feb 25, 2008
(15 p.)
[pdf(2)]
[html]
|
O. Lendl |
|
VoIP Peering: Background and Assumptions |
|
This documents provides background for the work on VoIP peering and
tries to provide guidance on what kind of work is needed to
facilitate widespread SIP-based peering of telephony networks. It is
intended to spur discussion on the work about peering and should also
serve as input to the ongoing discussions on reducing Spam for
Internet Telephony (SPIT).
|
|
|
| |
| Up List |
Intended Status: | Informational |
|
|
|
|
|
|
|
|
|
|
| |
| Up List |
Intended Status: | Informational |
|
|
|
|
|
|
|
|
| | |
niccolini-speermint-
voipthreats-03
ID Exists
Feb 21, 2008
(22 p.)
[pdf(2)]
[html]
|
S. Niccolini
E. Chen
J. Seedorf |
|
SPEERMINT Security BCPs |
|
This memo presents the different security threats related to
SPEERMINT classifying them into threats to the Location Function, to
the Signaling Function and to the Media Function. The different
instances of the threats are briefly introduced inside the
classification. Finally the existing security solutions in SIP and
RTP/RTCP are presented to describe the countermeasures currently
available for such threats. The objective of this document is to
identify and enumerate the SPEERMINT-specific threat vectors in order
to specify security-related requirements. Once the requirements are
identified, methods and solutions how to achieve such requirements
can be selected.
|
|
|
| |
| Up List |
Intended Status: | Informational |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
