Session Initiation Protocol Core (sipcore)

• About
• Documents
• Meetings
• History
• Photos
• Email expansions
• List archive »

WG	Name		Session Initiation Protocol Core
	Acronym		sipcore
	Area		Applications and Real-Time Area (art)
	State		Active
	Charter		charter-ietf-sipcore-04 Approved
	Document dependencies		Show Document dependencies Loading... Pan and zoom the dependency graph after the layout settles. Show legend Loading... Close
	Additional resources		GitHub Wiki, Zulip Stream
Personnel	Chairs		Brian Rosen, Jean Mahoney
	Area Director		Murray Kucherawy
	Liaison Contacts		Adam Roach, Paul Kyzivat
Mailing list	Address		sipcore@ietf.org
	To subscribe		https://www.ietf.org/mailman/listinfo/sipcore
	Archive		https://mailarchive.ietf.org/arch/browse/sipcore/
Chat	Room address		https://zulip.ietf.org/#narrow/stream/sipcore

Charter for 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.

Milestones

Date	Milestone	Associated documents
Jun 2023	Multiple Reasons values per protocol (PS) to the IESG	draft-sparks-sipcore-multiple-reasons
Dec 2017	Request publication of mechanisms for rapid dual-stack protocol selection in SIP

Done milestones

Date	Milestone	Associated documents
Done	Request publication of a clarification of the use of the "name-addr" production in SIP header fields
Done	Request publication of a clarification of the use of Content-ID as a SIP header field
Done	Request publication of a mechanism for labeling the nature of SIP calls
Done	Request publication of a SIP response code for unwanted communications
Done	Request publication of DNS look-up procedures for dual-stack client and server handling of SIP URIs
Done	WebSockets transport definition for SIP to the IESG (proposed standard)
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	Delivering request-URI and parameters to UAS via proxy to IESG (PS)
Done	Error corrections and clarifications to RFC3265 to IESG (PS)
Done	Location Conveyance with SIP to IESG (PS)
Done	Example security flows to IESG (Informational)
Done	Mechanism for indicating support for keep-alives (PS)
Done	Presence Scaling Requirements to IESG as Info
Done	SIP Events throttling mechanism to IESG (PS)
Done	Invite Transaction Handling Correction to IESG (PS)
Done	Extension for use in etags in conditional notification to IESG (PS)
Done	Termination of early dialog prior to final response to IESG (PS)
Done	INFO package framework to IESG (PS)

Dropped milestones

Date	Milestone	Associated documents
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.