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:

       http://www.softarmor.com/sipwg/ -- Additional SIP Page
NOTE: This charter is a snapshot of the 56th IETF Meeting in San Francisco, California USA. It may now be out-of-date.

Last Modified: 2003-01-27

Dean Willis <dean.willis@softarmor.com>
Rohan Mahy <rohan@cisco.com>
Jon Peterson <jon.peterson@neustar.biz>
Transport Area Director(s):
Scott Bradner <sob@harvard.edu>
Allison Mankin <mankin@psg.com>
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: www.ietf.org/mail-archive/working-groups/sip/current/maillist.html
Description of Working Group:
Note: There is another SIP email list for general information and implementations:

Discussion of existing sip: sip-implementors@cs.columbia.edu To Subscribe: sip-implementors-request@cs.columbia.edu In Body: subscribe Archive: http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors =======================================================================

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. compression: SIP mechanisms for negotiating and guidelines for using signaling compression as defined in ROHC.

15. content indirection: a Proposed Standard Mechanism to reference SIP content indirectly (by reference, for example using an external URI).

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  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
JAN 03  Guidelines for Authors of SIP extensions submitted as Informational
JAN 03  Mechanism for Content Indirection in SIP submitted to IESG for Proposed Standard
JAN 03  The SIP Referred-By Header submitted to IESG for Proposed Standard
FEB 03  Session Timer spec, revised to IESG
FEB 03  Caller preferences specification submitted to IESG
APR 03  The SIP Join Header submitted to IESG for Proposed Standard
JUL 03  MIB spec to IESG
JUL 03  Review WG status (consider closing) and/or submit a future milestones plan to IESG
  • - draft-ietf-sip-session-timer-10.txt
  • - draft-ietf-sip-callerprefs-08.txt
  • - draft-ietf-sip-mib-05.txt
  • - draft-ietf-sip-cc-transfer-05.txt
  • - draft-ietf-sip-guidelines-06.txt
  • - draft-ietf-sip-sctp-03.txt
  • - draft-ietf-sip-refer-07.txt
  • - draft-sparks-sip-mimetypes-03.txt
  • - draft-ietf-sip-replaces-03.txt
  • - draft-ietf-sip-dhcpv6-01.txt
  • - draft-peterson-sip-identity-01.txt
  • - draft-ietf-sip-referredby-01.txt
  • - draft-ietf-sip-compression-02.txt
  • - draft-ietf-sip-scvrtdisco-03.txt
  • - draft-ietf-sip-congestsafe-01.txt
  • - draft-ietf-sip-content-indirect-mech-02.txt
  • - draft-ietf-sip-symmetric-response-00.txt
  • - draft-ietf-sip-join-01.txt
  • - draft-ietf-sip-identity-01.txt
  • - draft-ietf-sip-authid-body-01.txt
  • - draft-ietf-sip-smime-aes-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
    RFC3262 PS Reliability of Provisional Responses in SIP
    RFC3263 PS SIP: Locating SIP Servers
    RFC3265 PS SIP-Specific Event Notification
    RFC3361 PS DHCP Option for SIP Servers
    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
    RFC3420 PS Internet Media Type message/sipfrag
    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
    RFC3428 PS Session Initiation Protocol Extension for Instant Messaging
    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
    RFC3313 I Private Session Initiation Protocol (SIP)Extensions for Media Authorization

    Current Meeting Report

    The SIP Working Group met at IETF 56 on Monday, March 17, 1300-1500,  in 
    room Continental 6.
    The posted agenda:
    1300 Agenda Bash
    1305 Status -- Chairs
    1315 Non-Invite Transaction Issues, Robert Sparks
    1330 Referred-By Changes and Open Issues, Robert Sparks
    1340 Resource Priority, Henning Schulzrinne
    1355 Caller Preferences, Jonathan Rosenberg
    1410 Congestion Safety, Dean Willis, Hisham Khartabil
    1430 Authenticated ID Bodies, Jon Peterson
    1445 SIPit report on S/MIME and TLS, Rohan Mahy
    1455 General Discussion
    1500 Break
    Scribe: Ramu (notes not receivedby chairs)
    Chat Room Coordinator: Not recorded
    Topic: Non-invite transactions, Robert Sparks.
    Poll == who has read and understands the draft, app. 20%. 
    Discusssion: Principle problem is the race condition of 64*T1 built into the 
    protocol.  Given non-zero latency, the UAS side has an offset on this 
    time, so the client may time out before the server completes. Now we just 
    try and "complete as soon as possible" giving response codes like 408 that 
    make no sense -- by the time it gets back to the UAC, the UAC is assured of 
    having timed out, creating a 408 storm. Other problems exist with 
    intermediary timeouts and with forking convergence.
    Two solutions offered: A and B. Rohan argues against proposal B, 
    preferring the subscribe/notify style of seperate transactions. Point: What 
    if values of T1 are different? Discussion: If UAS and UAC have 
    different values of T1, it's all broken anyhow. Extended discussion 
    follows. Two problems: the infrequent 1 in 10,000 events, and the 
    problem that the 200 has to be emitted soon enough to have a high 
    probability to make it back to the UAC before the 408s. Most troubling is 
    when the UAS thinks the situation is 200ok, but the UAC has a 
    different view (which can happen with non-invite forking). Point that we 
    should lift the constraint on interoperability with existing proxies. 
    Suggestion we adhoc during this meeting for consensus -- group to email 
    Robert for gathering. Note:  a detailed adhoc on this topic was held later 
    and the minutes seperately included in the proceeedings.
    Topic: Referred-by, Robert Sparks
    Complaint: nobody is giving feedback. Are people mostly happy and just 
    waiting on some of the blocking work to complete? A chairs asks for 
    volunteers to provide feedback: Brian Rosen, Mary Barnes, Alan 
    Johnston, Pekka Pessi all volunteer.
    Issue: Use of Call-ID seems to be required in auth-ID-body. Is it a leak?  
    Should we put garbage in, change the AID body format, or what? Jon 
    Peterson reports that the newest AIB draft relieves this 
    Issue: Referred identity binding between REFER and INVITE. Can a referee 
    assert a different identity on the generated INVITE than was 
    referenced in the REFER? Can humans make the distinction? No 
    resolution of this issue in this meeting, but it seems to relate to the URI 
    Leasing work ongoing in SIPPING.
    Topic: Resource-Priority, Henning Schulzrinne
    Goal: Higher priority of emergency call completion during service 
    disruption of civil emergency, especially in interworking with PSTN. 
    Requirements are establised in RFC3487.  List discussion reviewd, best 
    option a new header.  Discussion about whether it is "good" to have 
    proxies understand this.  Consensus: Work on this problem, starting from 
    this draft as a baseline, but address additional opinions and 
    requirements as raised in the WG process.
    Topic: Caller Preferences, Jonathan Rosenberg
    Issue: Needs a thorough review of the current draft, which seems pretty 
    much "done".
    Volunteers to review -- Robert Sparks,  Mary Barnes, Pekka Pessi, Bob 
    Penfield,  Cullen Jennings. The plan is to review, feed back, revise, go to 2 
    week WGLC.
    Topic: Congestion Safety, Dean Willis and Hisham Khartabil
    Presentation by Dean Willis.
    General poll indicates that after reading the draft, nobody 
    understands how it works. People seem to have the vague feeling that the 
    topic is important but are not cognizant of the implications. 
    Suggestion made that "congestion safe" is a misnomer, as nothing is 
    "safe".  No consensus reported.
    Presentation by Hisham Khartabil.
    One point made from audience is that implementors do not see immediate 
    value. Proposed by one speaker that we should consider response-CI as a 
    possible alternate mechanism in primary work. No consensus reported.
    Topic: Auth-ID Issues, Jon Peterson
    The only new "SIP" function is the new 400-response code. Other 
    functions are non-normative.   No poll for consensus recorded. Drafts are 
    nearly ready for last call.
    Rohan Mahy then discussed security implementations demonstrated at SIPit.  
    Some questions about S/MIME specification in RFC3261 reflected in the 
    implementations were raised.


    Authenticated Identity
    Congestion Safety Changes and Issues
    Non-INVITE Transaction Issues
    Caller Preferences
    Resource Priority