Subject: [Speermint] FYI -- [[email-masked]: WG Review: Session PEERing for Multimedia INTerconnect (speermint)]

From: David Meyer <[email-masked]>
Date: Fri, 27 Jan 2006 10:42:35 -0800

----- Forwarded message from IESG Secretary <[email-masked]> -----

> From: IESG Secretary <[email-masked]>
> To: [email-masked]
> Cc: 
> Subject: WG Review: Session PEERing for Multimedia INTerconnect (speermint) 
> Date: Fri, 27 Jan 2006 13:39:12 -0500
> 
> A new IETF working group has been proposed in the Real-time Applications and
> Infrastruture Area Directors Area.  The IESG has not made any determination 
> as yet.  The following draft charter was submitted, and is provided for 
> informational purposes only.  Please send your comments to the IESG mailing 
> list ([email-masked]) by February 1st.
> 
> +++
> 
> Session PEERing for Multimedia INTerconnect (speermint) 
> ========================================================
> 
> Current Status: Proposed Working Group
> 
> Chair(s):
>   TBD
> 
> Real-time Applications and Infrastruture Area Directors
>   TBD
> 
> Real-time Applications and Infrastructure Area Advisor:
>   Allison Mankin      <[email-masked]>
> 
> Mailing Lists:
>   General Discussion: [email-masked]
>   To Subscribe:       [email-masked]
>   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.  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 mechanisms, or to invoke layer 2 and layer 3
>   peering in an architecturally sound way in support of real-time
>   Session PEERING.  A charter discussion would consider how to
>   work 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 (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.  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.
> 
>   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
> 
> In the goals and milestones, "submit" means to submit the document to the IESG for publication.
> 
> ---
> 
> Goals and Milestones:
> 
> Jul 2006 Submit SPEERMINT terminology I-D (Informational).
> 
> Sept 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).
> 
> Mar 2007 Submit I-D on the minimum set of requirements for SIP-based
>          VoIP interconnection (BCP).
> 
> Jul 2007 Submit I-D specifying the use of addressing forms and providing
>          strong identities (BCP).
> 
> Jul 2007 Submit I-D(s) on use cases (BCP).
> 
> Jul 2007 Propose re-chartering for any additional efforts/considerations, 
>          or propose conclusion of working group (following approval of
>          last documents)
> 
> 
> Input internet-drafts:
>   draft-meyer-voipeer-terminology-01.txt
> 
> Request For Comments:
>   None

----- End forwarded message -----
_______________________________________________
Speermint mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/speermint