* WGs marked with an * asterisk has had at least one new draft made available during the last 5 days

Sipcore Status Pages

Session Initiation Protocol Core (Active WG)
Art Area: Adam Roach, Alexey Melnikov, Ben Campbell | 2009-Apr-14 —  
Chairs
 
 


2017-05-11 charter

Session Initiation Protocol Core (sipcore)
------------------------------------------

 Charter

 Current Status: Active

 Chairs:
     Brian Rosen <br@brianrosen.net>
     Jean Mahoney <mahoney@nostrum.com>

 Applications and Real-Time Area Directors:
     Ben Campbell <ben@nostrum.com>
     Alexey Melnikov <aamelnikov@fastmail.fm>
     Adam Roach <adam@nostrum.com>

 Applications and Real-Time Area Advisor:
     Ben Campbell <ben@nostrum.com>

 Mailing Lists:
     General Discussion: sipcore@ietf.org
     To Subscribe:       https://www.ietf.org/mailman/listinfo/sipcore
     Archive:            https://mailarchive.ietf.org/arch/browse/sipcore/

Description of Working Group:

  The Session Initiation Protocol Core (SIPCore) working group is
  chartered to maintain and continue the development of the SIP protocol,
  currently defined as proposed standard RFCs 3261, 3262, 3263, 3264, and
  6665.

  The SIPCore working group will concentrate on specifications that update
  or replace the core SIP specifications named above as well as
  specifications pertaining to small, self-contained SIP protocol
  extensions.  The process and requirements for new SIP extensions are
  documented in RFC5727, "Change Process for the Session Initiation
  Protocol".

  Throughout its work, the group will strive to maintain the basic model
  and architecture defined by SIP. In particular:

    1. Services and features are provided end-to-end whenever possible.

    2. Reuse of existing Internet protocols and architectures and
       integrating with other Internet applications is crucial.

    3. Standards-track extensions and new features must be generally
       applicable, and not applicable only to a specific set of session
       types.

    4. Simpler solutions that solve a given problem should be favored
        over more complex solutions.

  The primary source of change requirements to the core SIP specifications
  (enumerated above) will be a) interoperability problems that stem from
  ambiguous, or under-defined specification, and b) requirements from
  other working groups in the ART Area. The primary source of new protocol
  extensions is the DISPATCH working group, which will generally make the
  determination regarding whether new SIP-related work warrants a new
  working group or belongs in an existing one.


Goals and Milestones:
  Done     - INFO package framework to IESG (PS)
  Done     - Termination of early dialog prior to final response to IESG (PS)
  Done     - Invite Transaction Handling Correction to IESG (PS)
  Done     - Extension for use in etags in conditional notification to IESG (PS)
  Done     - SIP Events throttling mechanism to IESG (PS)
  Done     - Presence Scaling Requirements to IESG as Info
  Done     - Mechanism for indicating support for keep-alives (PS)
  Done     - Example security flows to IESG (Informational)
  Done     - Location Conveyance with SIP to IESG (PS)
  Done     - Error corrections and clarifications to RFC3265 to IESG (PS)
  Dropped     - WGLC on requirements for a mechanism to indicate proxy capabilities to both endpoints and other proxies in the path of a REGISTER transaction or a dialog-forming transaction.
  Done     - Delivering request-URI and parameters to UAS via proxy to IESG (PS)
  Done     - Mechanism to indicate proxy capabilities to both endpoints and other intermediaries in the path of a REGISTER transaction or dialog-forming transaction to IESG (PS)
  Done     - WebSockets transport definition for SIP to the IESG (proposed standard)
  Done     - Request publication of DNS look-up procedures for dual-stack client and server handling of SIP URIs
  Done     - Request publication of a SIP response code for unwanted communications
  Apr 2017 - Request publication of a mechanism for labeling the nature of SIP calls
  Done     - Request publication of a clarification of the use of Content-ID as a SIP header field
  May 2017 - Request publication of a clarification of the use of the "name-addr" production in SIP header fields
  Dec 2017 - Request publication of mechanisms for rapid dual-stack protocol selection in SIP


All charter page changes, including changes to draft-list, rfc-list and milestones:



Generated from PyHt script /wg/sipcore/charters.pyht Latest update: 24 Oct 2012 16:51 GMT -