Last Modified: 2003-01-27
Discussion of existing sip: email@example.com To Subscribe: firstname.lastname@example.org 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.
|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|
|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|
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 draft-sparks-sip-noninvite-00.txt 1330 Referred-By Changes and Open Issues, Robert Sparks draft-ietf-sip-referredby-01.txt 1340 Resource Priority, Henning Schulzrinne draft-polk-sip-resource-02.txt 1355 Caller Preferences, Jonathan Rosenberg draft-ietf-sip-callerprefs-08.txt 1410 Congestion Safety, Dean Willis, Hisham Khartabil draft-ietf-sip-congestsafe-01.txt draft-khartabil-sip-congestionsafe-ci-02.txt 1430 Authenticated ID Bodies, Jon Peterson draft-ietf-sip-authid-body-01.txt 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 requirement. 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.