The Session Initiation Protocol Core (sipcore) WG in the Applications and Real-Time Area of the IETF has been rechartered. For additional information, please contact the Area Directors or the WG Chairs. Session Initiation Protocol Core (sipcore) ----------------------------------------------------------------------- Current status: Active WG Chairs: Jean Mahoney <mahoney@nostrum.com> Adam Roach <adam@nostrum.com> Assigned Area Director: Ben Campbell <ben@nostrum.com> Applications and Real-Time Area Directors: Ben Campbell <ben@nostrum.com> Alissa Cooper <alissa@cooperw.in> Alexey Melnikov <aamelnikov@fastmail.fm> Mailing list: Address: sipcore@ietf.org To subscribe: https://www.ietf.org/mailman/listinfo/sipcore Archive: https://mailarchive.ietf.org/arch/browse/sipcore/ Charter: https://datatracker.ietf.org/doc/charter-ietf-sipcore/ 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. 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) Jun 2014 - Request publication of DNS look-up procedures for dual-stack client and server handling of SIP URIs
