Current Meeting Report
Jabber Logs

2.8.19 Session Initiation Protocol (sip)

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
NOTE: This charter is a snapshot of the 55th IETF Meeting in Altanta, Georgia USA. It may now be out-of-date.

Last Modifield: 07/03/2002

J. Ott <>
Brian Rosen <>
Dean Willis <>
Transport Area Director(s):
Scott Bradner <>
A. Mankin <>
Transport Area Advisor:
A. Mankin <>
Technical Advisor(s):
D. Romascanu <>
Mailing Lists:
General Discussion:
To Subscribe:
In Body: subscribe
Description of Working Group:
Note: There is another SIP email list for general information and implementations:

Discussion of existing sip: To Subscribe: In Body: subscribe Archive: =======================================================================

The Session Initiation Protocol (SIP) working group is chartered to continue the development of SIP, currently specified as proposed standard RFC 2543. 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 work of the group involves bringing SIP from proposed to draft standard, in addition to 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.

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. 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 IP protocols and architectures, and integrating with other IP applications, is crucial.

SIP was first developed within the Multiparty Multimedia Session Control (MMUSIC) working group, and the SIP working group will continue to maintain active communications with MMUSIC. This is particularly important since the main MIME type carried in SIP messages, the Session Description Protocol (SDP), specified in RFC 2327, is developed by MMUSIC and because MMUSIC is developing a successor to SDP which SIP will also use.

The group will work very closely with the (proposed) SIPPING WG, which is expected to analyze the requirements for application of SIP to several different tasks, and with the SIMPLE WG, which is using SIP for messaging and presence.

The group will also maintain open dialogues with the IP telephony (IPTEL) WG, whose Call Processing Language (CPL) relates to many features of SIP; will continue to consider the requirements and specifications previously established by the PSTN and Internet Internetworking (PINT) working group;: and will consider input from the Distributed Call Signaling (DCS) Group of the PacketCable Consortium for distributed telephony services, and from 3GPP, 3GPP2, and MWIF for third-generation wireless network requirements.

The specific deliverables of the group are:

1. bis: A draft standard version of SIP.

2. callcontrol: Completion of the SIP call control specifications, which enables multiparty services, such as transfer and bridged sessions.

3. callerpref: Completion of the SIP caller preferences extensions, which enables intelligent call routing services.

4. mib: Define a MIB for SIP nodes.

5. precon: Completion of the SIP extensions needed to assure satisfaction of external preconditions such as QoS establishment.

6. state: Completion of the SIP extensions needed to manage state within signaling, aka SIP "cookies".

7. priv: Completion of SIP extensions for security and privacy.

8. security: Assuring generally adequate security and privacy mechanisms within SIP.

9. provrel: Completion of the SIP extensions needed for reliability of provisional messages.

10. servfeat: Completion of the SIP extensions needed for negotiation ofserver features.

11. sesstimer: Completion of the SIP Session Timer extension.

12. events: Completion of the SIP Events extensions (Subscribe/Notify).

13. security: Requirements for Privacy and Security.

14. natfriend: Extensions for making SIP a NAT-friendly protocol.

Other deliverables may be agreed upon as extensions are proposed. New deliverables must be approved by the Transport Area Directors before inclusion on the agenda.

NOTE: milestones within the same month are shown in order of planned completion.

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  SIP extensions for media authorization (call-auth) submitted as Informational
Done  The UPDATE Method submitted for Proposed Standard
Done  Preconditions extensions (manyfolks) spec to IESG
Done  SIP Privacy specification to IESG
Done  SIP Privacy and Security Requirements to IESG
JUL 02  The Replaces Header submitted for Proposed Standard
JUL 02  The MESSAGE Method submitted for Proposed Standard
JUL 02  Refer spec to IESG
JUL 02  Caller preferences specification submitted to IESG
JUL 02  Session Timer spec, revised to IESG
AUG 02  Guidelines for Authors of SIP extensions submitted as Informational
AUG 02  SIP NAT extension submitted to IESG
SEP 02  SIP over SCTP specification and applicability statement
OCT 02  MIB spec to IESG
NOV 02  Review WG status (consider closing) and/or submit a future milestones plan to IESG
  • - draft-ietf-sip-session-timer-09.txt
  • - draft-ietf-sip-callerprefs-06.txt
  • - draft-ietf-sip-dhcp-06.txt
  • - draft-ietf-sip-mib-04.txt
  • - draft-ietf-sip-cc-transfer-05.txt
  • - draft-ietf-sip-guidelines-05.txt
  • - draft-ietf-sip-call-auth-06.txt
  • - draft-ietf-sip-manyfolks-resource-07.txt
  • - draft-ietf-sip-sctp-03.txt
  • - draft-ietf-sip-refer-06.txt
  • - draft-ietf-sip-nat-02.txt
  • - draft-sparks-sip-mimetypes-03.txt
  • - draft-ietf-sip-message-06.txt
  • - draft-ietf-sip-replaces-02.txt
  • - draft-willis-sip-path-08.txt
  • - draft-ietf-sip-update-02.txt
  • - draft-ietf-sip-dhcpv6-00.txt
  • - draft-ietf-sip-digest-aka-03.txt
  • - draft-ietf-sip-sec-agree-04.txt
  • - draft-ietf-sip-reason-01.txt
  • - draft-ietf-sip-referredby-00.txt
  • - draft-ietf-sip-asserted-identity-01.txt
  • - draft-ietf-sip-privacy-general-01.txt
  • - draft-ietf-sip-compression-00.txt
  • - draft-ietf-sip-scvrtdisco-00.txt
  • - draft-ietf-sip-congestsafe-00.txt
  • - draft-ietf-sip-content-indirect-mech-00.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
    RFC3265 PS SIP-Specific Event Notification
    RFC3262 PS Reliability of Provisional Responses in SIP
    RFC3263 PS SIP: Locating SIP Servers

    Current Meeting Report

    Minutes, SIP WG, IETF 55
    Edited by Dean Willis
    Notes recorded by Andrew Bender and Mary Barnes and Vijay Gurbani
    Meeting held Tuesday November 19, 1930-2200 in Atlanta, GA, USA
    Agenda Bash
    No objections raised
    Status and Charter, Chairs
    New co-chairs Rohan Mahy and Jon Peterson introduced.  Status of work 
    items reviewed by Rohan Mahy.  11 of 19 charter items reported 
    complete. New RFCs issued include 3310, 3311, 3312, 3361.
    Identity and Privacy and AuthID Open Issues, Jon Peterson
    Draft-peterson-sip-identity-00 split into 2 WG documents, which were 
    discussed seperately.
    Document draft-ietf-sip-authid-body-00.txt
    Status:  A specification of a MIME body that could be used as an 
    authentication token. Now relies on either message/sip or 
    Discussion: There was discussion around whether Call-id should always be a 
    must as there are scenarios (Referred-by and 3pcc) that need a flexible 
    mechanism for correlation. There was a proposal that it  should be 
    Call-id unless you provide another mechanism for replay protection. There 
    was discussion and agreement that it is always deterministic and clear when 
    you don’t want to include call-id.  There was also discussion around the 
    vulnerabilities of NOT sending the Contact header, with the 
    suggestion that if the AIB is intended for use inside a Dialog, then a 
    Contact should be a MUST.
    Conclusion:  Jon will address this in the draft.
    Document draft-ietf-sip-identity-00.txt
    Status:  Now defines status codes and practices for providing an 
    authentication token (which might be auth-id body, or could be 
    something else).  An AuthService authenticates user agents, creates some 
    sort of authentication token (as a MIME body), adds token to messages.  
    Document describes 3 ways that body can be added to requests:  1) 
    (Essentially)  Redirection (push body back to UA), 2) Auth Service acts as 
    B2BUA, and the optimal mechanism 3) Content-Indirection  
    Point 1: Why a header can’t be used for the mime body.  Given the S/MIME 
    direction it really has to be a body.
     Point 2: Long term identity versus short term identity solutions (as 
    described in the past). It was questioned as to how the multiple 
    identities in the “short term” document would be supported.  It was 
    discussed that the support of this has to do  with how the token is 
    structured.  There are 6 headers, 3 musts, 3 shoulds and optionals. It 
    wasn’t believed that it’s necessary to define the Multiple 
    identities explicitly in this draft.  But, this discussion is a 
    reasonable one to have.  The concern expressed was that although there are 
    multiple identity headers, there aren’t clearly defined semantics.   
    Proposal: Discussion of this topic should continue on the list.
     Point 3: Normative support for AIB.  It was agreed that a normative 
    statement is needed for interoperability.  You need to define the scope if 
    it’s negotiable, etc.  This gets into the downgrade attack issues, 
    etc.  There was concern that this might limit extensibility of the 
    mechanism, however, Allison highlighted that the minimum mandatory to 
    implement should be specified and that should not limit SIP’s future. 
    Document draft-peterson-sip-smime-aes-00.txt
    Status:  Recommends changing required encryption for the SIP profile of 
    S/MIME from 3DES to AES.  Why deal with this now? Because S/MIME for SIP has 
    yet to catch on, better to fix now.  Lower footprint of AES might also help 
    foster S/MIME adoption.  Additonal advantage: Same encryption 
    algorithm as TLS (AES).
    Discussion:  There was a proposal to add this as a 3261 bis bug, but it was 
    highlighted that this is of much greater scope than a typical 3261 bug. 
    There was also a concern raised over obsoleting parts of  an RFC, 
    however, Allison highlighted that it’s an accepted practice to update 
    parts of RFCs with another RFC.  It was suggested that occasionally 
    writing a roadmap makes navigating the RFCs easier. 
    Conclusion: Seemed to be general WG agreement for this to be a WG 
    Content Indirection Open Issues, Sean Olson
    Issue: use of size parameter in content-type - this can be used instead of
    content length header richer negotiation of indirection per mime type
    security issues- sips/smime, access control, revocation / 
     * use standard size parameter*
     * recommend s/mime and or tls
     * acl and negotiation are out of scope for this document... should be
       solved for sip in general
     * suggest wglc
    Discussion: why do we need size? Should it be madatory or optional?
    Conclusion: should make optional, as it may not always be possible to know 
    the real size at the time of the indirection. Issue WGLC 2 weeks after 
    changes published if there are no objections on list.
    RFC3261 Open Issues Jonathan Rosenberg
    Group decided not to discuss at this time as the author indicated all open 
    issues had been adeuqately discussed on-list.
    Caller Preferences Open Issues,  Jonathan Rosenberg
    Slides presented on open issues. Briefly reviewed Changes since last 
    revision with the biggest change being the  Require-Contact. A draft on 
    related scenarios should be published shortly.
    Issue#1: Forced Parameter
    If a UA doesn’t say anything about a parameter, it still matches a rule 
    with that parameter.  
    Proposal: Add a parm to Require Contact rule that explicitly says 
    whether it MUST match.  No arguments against proposal raised.
    Issue #2 AND within single feature tag
    In some cases, you want to specifiy that a UA has to support multiple 
    values for the same feature tag. Current mechanism is to use multiple 
    values of the Require-Contact header field
    Proposal: keep as is. No arguments raised against proposal. Some 
    discussion held about differences between multiple occurences of the same 
    value vs. multiple values.
    Issue #3: Weight q-values based on amount of overlap
    Proposal: develop q-value algorithm which weighs based on amount of 
    overlap; can be done in RFC 2533 framework.
    Discussion indicated that we need to develop a metric for the amount of 
    overlap, and that in order to prevent spiral problems where each 
    parameter has a differnet q-value, we must compute q-values 
    automatically based on the amount of overlap. There was also 
    discussion on exact match as a limiting case. The argument was made that 
    whereas RFC2533 implies that partial matching is impractical in a 
    general case, we believe we have enough constraints to be able to solve the 
    problem within the given scenarios.
    Issue #4: Merge Require, Accept Contacts
    Require and Accept Contact are similar
    Proposal: Merge back into single Accept-Contact header field and define 
    should-match parm which if contact predicate doesn’t match, causes it to 
    drop. No arguments raised against proposal.
    Discussion: Similar to Issue #1.
    Issue #5: No one cares
    There has been little feedback on this draft given that it is widely 
    Proposal: Rewrite intro to give it a bit more spark, explain better the 
    power of the spec and that it is truly providing "one number" service.
    Discussion: lack of comments does not equate to lack of interest. It may be 
    that this is just not contentious anymore.
    Issue #6: Priority semantics
    Proposal:  work through use cases and express in draft.
    Discussion:  priority semantics may be out of scope, since this is really a 
    callee rather than caller issue. Proposed that this should handled 
    Issue #7: Implicit compatibility mechanism
    Issue #8: Escaping
    Sadly, RFC 2533 syntax for feature tags uses characters not permitted in 
    token (slash and colon). These characters are in use.
    Proposal: Use characters allowed in token, but not in feature tag, to 
    represent those characters; bang gets mapped to colon, single quote gets 
    mapped to slash.
    Conclusion: Although, there was lots of discussion on 
    alternatives, none were deemed reasonable, so will go forward with 
    Discussion: Could we have only one escaping mechanism? Point: There will be 
    not translation that occurs. we are just renaming feature tags in the 
    token codespace, and there is never a decode.
    Path Forward:
    Proposal: One more rev with these issues.
    Question: Ready for WGLC?  Poll taken, general consensus recorded.
    Question: What about use cases?  Should it find a home somewhere?
    There was some discussion on what to do with the use cases, with the 
    general consensus expressed that the use cases are useful; whether they 
    should remain in a separate doc, be put in an appendix of this doc or 
    merged with other call flows is still undecided.
    Conclusion: 2 week WGLC after proposed changes. 
    SIP Guidelines Open Issues,  Rohan Mahy
    Issues: Notion of CANCELs and provisional responses for non-INVITES 
    currently conflicts with RFC 3261, that you must specify processing in new 
    drafts.  Does this causes more harm than good?
    Discussion: There was discussion around exactly what’s currently in RFC 
    3261, with Rohan suggesting that there’s never a good reason to receive 
    Cancel  for a non-INVITE. However,  Robert S. highlighted that there is 
    one.  If a non-INVITE times out with no responses, the SRV draft is 
    written that the endpoint fails over. Immediate provisionals are BAD for 
    non-INVITE.  Sending a provisional before a transaction times out can 
    prevent some problems.  There are really two different problems here: 
    provisional responses, and CANCELs for non-invite messages. The 
    discussion continued around TCP introducing additional problems and the 
    importance of separating the 100 Trying from the discussion of 
    Conclusion: Robert to start list discussion on this particular topic once 
    draft is available.
    SIP Session Timer -- Jonathan Rosenberg
    Changes from last rev:
    * Rewrote overview of operation
    * 422 response causes you to retry with same call-ID and bumped CSEQ like 
    * Clarified that mid-dialog re-INVITE w/o session timer cancels session 
    * Many complaints and limited interest
    * No defined requirements, not entirely clear the problem that is being 
    Proposition: only useful application is cleanup of state in proxies
    * Is it too complex for that usage?
    * Redefine the scope
    * Keep the scope, but clarify the wording
    * Keep the scope, but pursue a completely a new design
    * For example, just use the dialog package!
    Conclusion: Concensus appears to be option 2 – keep the scope and 
    clarify the wording.
    Discussion: There was some discussion around the lack of 
    requirements, which is likely what leads to many of the problems in 
    understanding the draft and finding issues therewith. 
    Proposal: Draft should have a reasonable statement of requirements in the 
    draft, including some which are not already there.
    Discussion of previously discussed alternatives, including the 
    suggestion that this solution could align with RTSP and use the PING 
    There was also discussion around support of this in other methods, 
    however, it was highlighted that that introduces the need to maintain 
    Question:   Who would support this draft? Medium hum vote support
    Question:   Who would support if it were enhanced (that wouldn’t support 
    otherwise)? Even smaller hum vote.
    Question:   How many people violently object to moving this draft 
    forward as-is? No objections.
    Final Conclusion:  Jonathan will clarify the current version and submit for 
    going forward and WGLC.
    SIPS URIs, Jonathan Rosenberg
    Basic problem (SIPS URI):  Text is a bit confused on whether its e2e or 
    Additional problems: Mixed cases – SIPS URI in Contact 200 ok if it ws 
    nowhere else?
    Solution Need to come to agreement on the high level behavior, from there 
    the detailed behaviors will flow
    Discussion:  There was some discussion around the requirement for using 
    SIPS.  The general problem is with the double Record Routing.
    It was highlighted that there needs to be one place that properly  
    describes record routing that can be re-used by compression, SIPS and 
    transport.  It was highlighted that (for compression) the  double record 
    routing  works okay because there is not currently a scenario that needs to 
    change something in the response. Robert proposed that you can use this 
    abstraction to highlight that the link characteristics on either side are 
    different. And that, SIPS may introduce additional constraints.
    Proposal: Robert will specify this general mechanism for multiple record 
    routing. The  specific cases where the issues have been identified in 
    RFC3261 with different characteristics should reference the general 
    Conclusion: Go forward with Robert’s proposal and update the text in 
    RFC3261 appropriately to make use of this mechanism. 


    Content Indirection Mechanism
    Authenticated Identity