[Enum] [voipeer] Revised VOIPEER Charter (note name change...)

	Folks, 

	Please find enclosed the most recent rev of the
	charter. Note also that the name has changed to
	speermint; there were various problems with the name
	SPEER (which  came to light over various email
	discussions). Credit Jason with name speermint :-) 

	Finally, we're working on getting speermint@lists.ietf.org 
	going; I will let you know when that is complete. 

	Dave

---

Session PEERing for Multimedia INTerconnect (speermint)

Last Modified: 2005-12-06

Chair(s):
  Jason Livingood     <jason_livingood@cable.comcast.com>
  David 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: speermint@ietf.org
  To Subscribe:       speermint-request@ietf.org
  In Body:            (un)subscribe
  Archive:            http://www.ietf.org/mail-archive/web/speermint/index.html

Description of Working Group:

  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.

  SPEERMINT focuses architectures to identify, signal, and route
  delay-sensitive (real-time) communication sessions at the
  application level ("layer 5"). 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 "Layer 5 network" 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 for layer 5 networks and their associated
  use cases. This includes 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 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. SPEERMINT may also
  consider various mechanisms to support the application of
  Quality of Service (QoS) in some manner. In particular,
  SPEERMINT specifies mechanisms for layer 2 and/or layer 3
  peering in support of real-time Session PEERing. It is
  important to note that these mechanisms may be developed in
  other working groups.

  In addition, SPEERMINT develops 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 recognizes 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, as well as guides SPEERMINT to
  maintain the greatest possible separation of the application
  layer from lower layers.

  The SPEERMINT work plan is also intimately related to the work
  plans being pursued by the ENUM and SIPPING working groups. In
  particular, while the ENUM Working Group is primarily concerned
  with the structure and lookup of data for the translation of
  E.164 numbers into URIs (RFC3761), 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.

  Further issues that are out of scope for SPEERMINT include: 

  o Interoperability, and NITS/profiling of existing protocols
    such as SIP, RTP, and SRTP,

  o SPIT prevention. Note, however, that other working groups
    may release relevant specifications that become required or
    are referenced by various SPEERMINT uses cases and BCPs,

  o Routing of sessions which are not signaled using SIP. In
    particular, SPEERMINT is constrained to consider only those
    scenarios in which call routing is signaled using the SIP
    protocol and addressed by SIP or SIPS URIs. E.164 numbers and
    other national or private formats may only be used as defined
    within the SIP protocols, and 

  o H.323

---
Goals and Milestones:
  Mar 2006      Submit SPEERMINT terminology I-D.

  Mar 2006      Submit I-D defining the SPEERMINT routing
                architecture (Informational).

  Dec 2006      Submit I-D defining the message flows associated 
                with the SPEERMINT routing architecture
		(Informational).  

  Jan 2007      Submit I-D on the use of DNS SRV and NAPTR
                records as specified by RFC 3263 (BCP).  

  Jan 2007      Submit I-D on the minimum set of requirements for
                SIP-based VoIP interconnection (BCP).  

  Mar 2007      Submit I-D specifying the use of addressing forms
                and provides strong identities (BCP).  

  Jun 2007      Submit I-D(s) on use cases (BCP).

  Jun 2006      Submit SPEERMINT terminology document to IESG
                (Informational). 

  Mar 2007      Submit document to the IESG on the minimum set of
                requirements for SIP-based VoIP interconnection.  

  Mar 2007      Submit document defining the call flows
                associated with the SPEERMINT routing architecture to
                the IESG (Proposed Standard). 

  Jul 2006      Submit document defining the SPEERMINT routing
                architecture to the IESG (Informational).  

  Mar 2007      Submit document to IESG specifying the use of
                addressing forms and provides strong identities (BCP).

  Jun 2007      Submit document to IESG on the use of DNS SRV and
                NAPTR records as specified by RFC 3263 (BCP).  

  Jun 2007      Submit document(s) to IESG on use cases (BCP)
                (ongoing).

Internet-Drafts:
  draft-meyer-voipeer-terminology-01.txt

Request For Comments:
  None