2.8.14 Session Initiation Protocol (sip)

NOTE: This charter is a snapshot of the 64th IETF Meeting in Vancouver, British Columbia Canada. It may now be out-of-date.
In addition to this official charter maintained by the IETF Secretariat, there is additional information about this working group on the Web at:

       Additional SIP Page

Last Modified: 2005-11-03


Dean Willis <dean.willis@softarmor.com>
Rohan Mahy <rohan@ekabal.com>

Transport Area Director(s):

Allison Mankin <mankin@psg.com>
Jon Peterson <jon.peterson@neustar.biz>

Transport Area Advisor:

Allison Mankin <mankin@psg.com>

Technical Advisor(s):

Dan Romascanu <dromasca@avaya.com>

Mailing Lists:

General Discussion: sip@ietf.org
To Subscribe: sip-request@ietf.org
In Body: subscribe
Archive: http://www.ietf.org/mail-archive/web/sip/index.html

Description of Working Group:

The Session Initiation Protocol (SIP) working group is chartered to
maintain and continue the development of SIP, currently specified as
proposed standard RFC 3261, and its family of extensions.

SIP is a text-based protocol, similar to HTTP and SMTP, for
initiating interactive communication sessions between users.
Such sessions include voice, video, chat, interactive games, and
virtual reality. The main tasks of the group involve bringing SIP
from proposed to draft standard and specifying and developing
proposed extensions that arise out of strong requirements. The SIP
working group will concentrate on the specification of SIP and its
extensions, and will not explore the use of SIP for specific
environments or applications. It will, however respond to general-
purpose requirements for changes to SIP provided by other working
groups, including the SIPPING working group, when those
requirements are within the scope and charter of SIP. The process and
requirements for such extensions are documented in RFC 3427, "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. Standards-track extensions and new features must be generally
applicable, and not applicable only to a specific set of session types.

3. Simplicity is key.

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

The primary source of change requirements to be considered by the SIP
Working Group is the SIPPING working group, which
analyzes the requirements for application of SIP to several different
tasks, including the tasks of standards-development organizations
that are developing systems based on SIP and that may require changes
or extensions thereto. Additional requirements are produced by the
other IETF working groups that are using SIP, including the SIMPLE WG
(which is using SIP for messaging and presence) and the XCON working
group (which is using SIP for centralized conferencing).

In addition to extending SIP as required to address these externally-
derived requirements, the deliverables of the group include assuring
capable security and privacy mechanisms within SIP and increasing
the stability of the SIP specification.

Specific deliverables toward these goals include:

1. Mechanisms for secure expression of identity in requests and

2. Mechanism to securely request services delivery by non-terminal
elements ("end-to-middle").

3. Guidelines for use of existing security mechanisms such as TLS,
IPsec, and certificates.

4. Guidelines for the use of descriptive techniques such as SAML
(Security Association Markup Language) with SIP.

5. Draft standard versions of SIP and critical supporting

Other deliverables may be agreed upon as extensions are understood
to be necessary. Prospective deliverables will be discussed
with the Area Director before inclusion on agendas, and new
proposed work must be approved via a charter update.

Goals and Milestones:

Done  Server Features Negotiation submitted to IESG
Done  Complete IESG requested fixes to provrel and servfeat
Done  Revised proposed standard version of SIP (2543bis) submitted to IESG
Done  SIP Events specification to IESG
Done  The UPDATE Method submitted for Proposed Standard
Done  SIP extensions for media authorization (call-auth) submitted as Informational
Done  Preconditions extensions (manyfolks) spec to IESG
Done  SIP Privacy specification to IESG
Done  SIP Privacy and Security Requirements to IESG
Done  The MESSAGE Method submitted for Proposed Standard
Done  The Replaces Header submitted for Proposed Standard
Done  Refer spec to IESG
Done  SIP NAT extension submitted to IESG
Done  SIP over SCTP specification and applicability statement
Done  Mechanism for Content Indirection in SIP submitted to IESG for Proposed Standard
Done  The SIP Referred-By Header submitted to IESG for Proposed Standard
Done  Session Timer spec, revised to IESG
Done  Caller preferences specification submitted to IESG
Done  Submit SIP Identity documents to IESG for Proposed Standard
Done  The SIP Join Header submitted to IESG for Proposed Standard
Done  Replaces header to IESG (PS)
Done  Upgrade S/MIME requirement for AES in 3261 to IESG (PS)
Done  Application Interaction to IESG (BCP)
Done  Presence Publication to IESG (PS)
Done  Resource Priority signaling mechanism to IESG (PS)
Done  Guidelines for Authors of SIP extensions submitted as Informational
Done  Enhancements for Authenticated Identity Management to IESG (BCP)
Done  MIB spec to IESG
Done  Request History mechanism to IESG (PS)
Oct 2005  Mechanism for obtaining globally routable unique URIs (GRUU) to IESG (PS)
Oct 2005  Mechanism for REFER without implicit SUBSCRIBE to IESG (PS)
Nov 2005  Connection reuse mechanism to IESG (PS)
Dec 2005  Mechanism for Target-Dialog to IESG (PS)
Jan 2006  Mechanism for feature parameters with REFER To IESG (PS)
Feb 2006  Mechanism and guidelines for outbound connections to IESG (PS)
Feb 2006  Guidelines for Using Certificates with SIP to IESG (BCP)
Mar 2006  Location Conveyance with SIP to IESG (PS)
Apr 2006  Mechanism for End-to-Middle Requests to IESG (PS)
Apr 2006  Mechanism for Response Identity to IESG (PS)
Jul 2006  Using SAML for SIP (PS)
Jul 2006  Revise Charter, including developing a task for a roadmap that will identify the "critical supporting specifications" and map out the Draft Standard interoperability report effort


  • draft-ietf-sip-mib-09.txt
  • draft-ietf-sip-guidelines-09.txt
  • draft-ietf-sip-content-indirect-mech-05.txt
  • draft-ietf-sip-identity-06.txt
  • draft-ietf-sip-history-info-06.txt
  • draft-ietf-sip-resource-priority-10.txt
  • draft-ietf-sip-connect-reuse-04.txt
  • draft-ietf-sip-gruu-06.txt
  • draft-sparks-sip-nit-problems-02.txt
  • draft-sparks-sip-nit-actions-03.txt
  • draft-ietf-sip-refer-with-norefersub-03.txt
  • draft-ietf-sip-target-dialog-02.txt
  • draft-ietf-sip-location-conveyance-01.txt
  • draft-ietf-sip-refer-feature-param-00.txt
  • draft-ietf-sip-e2m-sec-01.txt
  • draft-ietf-sip-outbound-01.txt

    Request For Comments:

    RFC2976 PS The SIP INFO Method
    RFC3204 PS MIME media types for ISUP and QSIG Objects
    RFC3261 PS SIP: Session Initiation Protocol
    RFC3262 PS Reliability of Provisional Responses in SIP
    RFC3263 PS SIP: Locating SIP Servers
    RFC3265 PS SIP-Specific Event Notification
    RFC3310 I Hypertext Transfer Protocol (HTTP) Digest Authentication Using Authentication and Key Agreement (AKA)
    RFC3311 PS The Session Initiation Protocol UPDATE Method
    RFC3312 PS Integration of Resource Management and SIP
    RFC3313 I Private Session Initiation Protocol (SIP)Extensions for Media Authorization
    RFC3319 PS Dynamic Host Configuration Protocol (DHCPv6)Options for Session Initiation Protocol (SIP) Servers
    RFC3323 PS A Privacy Mechanism for the Session Initiation Protocol (SIP)
    RFC3325 I Private Extensions to the Session Initiation Protocol (SIP) for Asserted Identity within Trusted Networks
    RFC3326 PS The Reason Header Field for the Session Initiation Protocol (SIP)
    RFC3327 PS Session Initiation Protocol Extension for Registering Non-Adjacent Contacts
    RFC3329 PS Security Mechanism Agreement for the Session Initiation Protocol (SIP) Sessions
    RFC3361 PS DHCP Option for SIP Servers
    RFC3420 PS Internet Media Type message/sipfrag
    RFC3428 PS Session Initiation Protocol Extension for Instant Messaging
    RFC3486 Standard Compressing the Session Initiation Protocol
    RFC3515 PS The Session Initiation Protocol (SIP) Refer Method
    RFC3581 PS An Extension to the Session Initiation Protocol (SIP) for Symmetric Response Routing
    RFC3608 Standard Session Initiation Protocol Extension Header Field for Service Route Discovery During Registration
    RFC3840 Standard Indicating User Agent Capabilities in the Session Initiation Protocol (SIP)
    RFC3841 Standard Caller Preferences for the Session Initiation Protocol (SIP)
    RFC3853 Standard S/MIME AES Requirement for SIP
    RFC3891 Standard The Session Inititation Protocol (SIP) 'Replaces' Header
    RFC3892 Standard The SIP Referred-By Mechanism
    RFC3893 Standard SIP Authenticated Identity Body (AIB) Format
    RFC3903 Standard An Event State Publication Extension to the Session Initiation Protocol (SIP)
    RFC3911 Standard The Session Inititation Protocol (SIP) 'Join' Header
    RFC3968 BCP The Internet Assigned Number Authority (IANA) Header Field Parameter Registry for the Session Initiation Protocol (SIP)
    RFC3969 BCP The Internet Assigned Number Authority (IANA) Universal Resource Identifier (URI) Parameter Registry for the Session Initiation Protocol (SIP)
    RFC4028 Standard Session Timers in the Session Initiation Protocol (SIP)
    RFC4032 Standard Update to the Session Initiation Protocol (SIP) Preconditions Framework
    RFC4092 Standard Usage of the Session Description Protocol (SDP) Alternative Network Address Types (ANAT) Semantics in the Session Initiation Protocol (SIP)
    RFC4168 Standard The Stream Control Transmission Protocol (SCTP) as a Transport for the Session Initiation Protocol (SIP)

    Current Meeting Report

    Minutes, SIP Working Group, IETF 64

    Edited by Dean Willis from notes by:

    • Spencer Dawkins

    • Eric Burger

    • Scott Lawrence

    • Steve Donovan

    Initial Agenda, Session 1: Tuesday, November 8, 1300-1500


    Discussion Leader






    Agenda Bash




    Status, Charter and Schedule



    Chairs (announce)

    Response Identity




    John Elwell

    Connected identity




    Cullen Jennings





    Hannes Tschofenig





    Dean Willis
    Andrew Allen

    Answer and Alert Modes




    Kumiko Ono

    Trust Path Discovery




    David Schwartz

    SAML for SPIT




    Rohan Mahy

    Remote Call Control



    Topic: Agenda

    GRUU will be added to the agenda when possible due to new issues on-list.

    Certs dropped from agenda due to no open issues requiring discussion.

    Topic: Charter and Status

    Discussion led by chairs

    Slides presented and included in proceedings.

    Issue: Charter. The only element of the new charter receiving substantial discussion was the milestone “Draft standard versions of SIP and critical supporting
    specifications”. This was highly controversial as read. The group discussed the meaning of “draft standard” and its requirement for at least two independent interoperable implementations. The general consensus seems to be that it is premature to discuss elevating the standards level of SIP at this time. Two key points were noted:

    • It would be useful to develop a document like the “TCP Roadmap” that explains which RFCs are “part of SIP” and are critical to implementations. Jonathan Rosenberg expressed an interest in this work.

    • Robert Sparks has been tracking the normative requirements (“MUSTs”) of the core specification and will contribute this work to the process.

    Issue: draft-cao-sip-response-auth-00. Few comments received on list. Attendees asked to review.

    Issue: Certs draft. This draft is moving from SIPPING to SIP as a charter deliverable. A poll of the room indicated that at least seven parties plan to implement the specification. All parties are asked to review the draft, but Rohan will pick out at least two of the implementers to assist in a detailed review.

    TODO: Rohan to coordinate review of Certs draft.

    Issue: MIB Document. The review of this document has been delayed by slow responses to MIB doctor requests. The editors report that there is some controversy over method identifiers, which the MIB doctors apparently asked to have deleted from the document, then asked to have added back.

    Topic: Connected Identity

    Discussion led by John Elwell

    Slides presented and included in proceedings.

    Issue: Basic mechanism. Several approaches proposed. Discussion rapidly converged on modification of “From:” header fields to reflect identity as used in the Identity draft. Tieing this change to the Outbound draft seems to provide for most aspects of backward compatibility, but several participants argued strongly that we should go ahead and “really fix” the “From: header without cruft to support backward compatibility. The changing of From: in mid-dialog requests also seemed to have a general consensus, but didn't appear to be generally understood. The discussion concluded with a strong consensus on this general line of work, but a general feeling tht there are probably some lurking issues that won't become clear until the approach is specified in a draft.

    Topic: SAML

    Discussion led by Hannes Tschofenig

    Slides presented and included in proceedings.

    There seems to be a strong general interest in the approach, but the working group seemed to agree that we need a draft with more discussion of practical mechanism and examples in order to really get started here. There was no consensus to adopt the draft at this time as baseline text toward the charter deliverable, but the author was encouraged to proceed with the work and continue the discussion with the working group in hopes of reaching critical mass.

    Topic: Answer and Alert Modes

    Discussion led by Dean Willis and Andrew Allen

    Slides presented and included in proceedings.

    Discussion centered on possible security issues relating to the combination of auto-answer and null alert modes providing a “bug my phone” or “baby monitor” attack. The group reached consensus on revising the draft to eliminate the alert-mode functionality, with a general agreement that the use of Alert-Info with URN behaviors as proposed in SIPPING is a more attractive approach. The revised draft shall also include stronger guidance on the “bug my phone” aspect. Robert Sparks noted that several aspects of the draft would be likely to be misunderstood by implementers and might result in “train wreck” implementations, and agreed to send text to the editor to correct these flaws. The group did agree that completing this work for OMA is critical and consistent with the new charter of the working group.

    TODO: Chairs to coordinate new milestone with AD.

    Topic: Trust Path Discovery

    Discussion led by Kumiko Ono

    Slides presented and included in proceedings.

    Issue: Scaling and “push” vs “pull” model. Noted that push model requires advance calculation of several degrees of connectivity, which can become very large very quickly. It was reported that AOL cannot three degrees of connectivity for the AIM database as the problem space becomes too large.

    Noted that the IAB messaging workshop recommended investigation of a distributed reputation system.

    Noted that there is a problem relationship to DKIM, so there could be a similarity in the solution.

    Suggested that this material is worth holding a BOF on and perhaps chartering a working group.

    The chairs requested the author to keep the working group informed of progress in this area, but the general consensus is that this problem is outside the scope of SIP.

    Topic: SAML for SPIT

    Discussion led by David Schwartz

    Slides presented and included in proceedings.

    Discussion indicated a general interest in the problem and approach if it can be shown to scale to practical problem sets.

    It was noted that the current draft is domain-oriented, but that it could be extended to end-user devices if those devices supported SAML.

    The author was also encouraged to further explore the idea of federated domains.

    Topic: Remote Call Control

    Discussion led by Rohan Mahy

    Slides presented and included in proceedings.

    Question: Would full arbitration of end-point (not just dialog) state be in scope for this draft? The authors don't feel it to be in scope at this time.

    Noted that revisions should explain how this interacts with REFER.

    Noted that this is approaching “full CTI (computer telephony integration)”, which has previously been out of scope in SIP. The room was asked to show hands if they thought this discussion to be in/out of the interest of SIP. About 20 responded positively, with about 2 opposed.

    The meeting session concluded on-schedule.

    Initial Agenda, Session  2: Thursday, November 10, 1300-1500 (Note: conflicts with SAAG)


    Discussion Leader






    Agenda Bash



    Rohan Mahy

    Connection Reuse




    Cullen Jennings





    Orit Levin

    Refer Feature Parameters




    James Polk
    Brian Rosen

    Location Conveyance




    Jonathan Rosenberg

    Route Construction




    Jonathan Rosenberg

    Target Dialog



    Topic: Agenda

    James Polk suggested that there is no need to discuss location conveyance. We agreed to have a minimal discussion.

    GRUU added to agenda.

    Outbound and Refer Feature Parameters reordered due to slide availability issues.

    If time permits, we will discuss Dale Worley's draft on dialog event package implementation guidelines, draft-worley-sipping-dialog-00.txt

    Topic: Connection reuse

    Discussion led by Rohan Mahy

    Rohan reports that there have been conflicting proposals to fix open issues and that the draft has been languishing. He will reopen discussion of the draft on the mailing list.

    No slides presented

    Topic: GRUU

    Discussion led by Jonathan Rosenberg

    Slides presented and included in proceedings

    Issue: Indicating URI is a GRUU. Consensus emerged on not using a URI parameter to indicate that a URI is a GRUU, but to rely on normative behavior that clients supporting GRUU will always use a GRUU. The text will be amended based on text submitted by Dale Worley on the SIP list. The text will also be revised to clarify that one does not make the assumption of GRUUness based on “Supported: gruu”.

    Issue: Difference between retargeting and routing.


    • Retargeting - change in resource to which request is destined

    • Routing - change in request destination to reach the resource to which the request is targeted

    Proposal: 305 implies re-routing, Other 3xx imply re-targeting. Tie to SIP outbound. Put registered contact in Route header instead of request-URI.

    Issue: GRUU usage as proposed breaks Outbound as written. This point was agreed, and led to intense discussion. Suggested by Sean Olson that the GRUU be placed in the route header, not in the contact. Jonathan asked for written clarification on this. Discussion raged interminably, resulting in a decision to have an after-hours discussion.

    Noted that this represents a substantial change, but a huge improvement, in general SIP routing methodology. Should this increment or change the SIP version number? The consensus here was “no”, although we appear to be getting very close to that threshold.

    Topic: Outbound

    Discussion led by Cullen Jennings

    Slides presented and included in proceedings

    Issue: Config framework requires a subscribe before UA has credentials to perform registration.

    Resolution: Use of pin-route option tag in require header agreed to by group.

    Issue : Record-Route and Reliability

    Proposal: Use GRUU and don't record-route in EP

    No discussion of issue – seemed to be general consensus on proposal.

    Issue: Service Route

    Proposal: Start with configured outbound proxy, each registration returns a service route, this service route replaces the outbound just for that registration.

    Discussion finally concluded that this was a not major issue, but that some changes to Service-Route would be needed.

    Issue: Should outbound have a dependency on draft-rosenberg-sip-route-construct?

    Resolution: Take it to the list

    Issue: Terminology

    The flow/flow-id/connection terms are confusing and Cullen asked for suggested new wording.

    Topic: Location Conveyance

    Discussion led by Brian Rosen, supported by James Polk

    Issue: Need people to look at draft

    Issue: Do we need a separate package or should we just use presence package?

    Proposal: State that it works with presence and it can be included in other packages

    Resolution: Discuss on list

    Topic: Refer Feature Parameters

    Discussion led by Orit Levin

    Slides presented and included in proceedings

    Issue: What feature tags should be included in REFER?

    Proposal: Update 3840 and callerprefs use cases, include all feature tags that were listed in the most recent contact header field of the REFER-Target.

    Alternate proposal (Cullen proposal): Need to have a document that gives implementers information on what feature tags to include in what messages.

    Resolution: Consensus as judged by chair: Move forward with proposal for REFER as presented. Deal with Cullen's proposal separately.

    Topic: Target Dialog

    Discussion led by Jonathan Rosenberg

    Slides presented and included in proceedings

    Issue: Proposal to extend target-dialog

    Resolution: Don't do it

    Issue: Handling of request with target-dialog that doesn't exist.

    Proposal on list was to use 481.

    Resolution: Don't use 481, use existing text.

    Noted by Cullen Jennings & Robert Sparks that 3261 already recommends the use of crypto-random tag values, but that existing implementations do not use enough bits to have sufficient randomness. This shows a need for more than rough guidance on this sort of thing.

    Action: Revise and resubmit document.

    Topic: Route Construction

    Discussion led by Jonathan Rosenberg

    Slides presented and included in proceedings

    Discussion was generally favorable and the working group was asked to consider whether this document provides sufficient additional clarity to SIP that it should be considered under the revised charter scope of “increasing the stability of the SIP specification”. The consensus is favorable, and the chairs are directed to work with the AD to establish a milestone.

    TODO: Chairs to work with AD to establish a milestone for Route Construction.

    Topic: Dialog Event Package

    Discussion led by Dale Worley

    Slides presented and included in proceedings

    Implementations do not currently contain the information needed to be useful.

    So, this draft provides guidelines on how to use dialog even package. Need implementers to review this draft and see if it helps.

    Cullen Jennings noted that there is an ambiguity with respect to how to signal state at the end of a call and that it would be useful to address this in future revisions.


    Agenda and Status
    Connected Identity
    SIP with SAML
    Answer and Alert Mode Extension
    Trust Path Discovery
    SAML for Spit Prevention
    Remote Call Control
    REFER Feature Tags
    Route Construction
    Target Dialog
    Dialog Event