Last Modifield: 07/03/2002
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. 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.
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 |
RFC | Status | Title |
---|---|---|
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 |
Minutes, SIP WG, IETF 55 Edited by Dean Willis dean.willis@softarmor.com 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 message/sigfrag 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 dont 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 Discussion: Point 1: Why a header cant 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 wasnt believed that its 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 arent 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 its 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 SIPs 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 its 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 document. 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 / invalidation Proposal(s)- * 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 doesnt 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 doesnt 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 referencec. 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 through CPL. Issue #7: Implicit compatibility mechanism Skipped 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 proposal. 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 whats currently in RFC 3261, with Rohan suggesting that theres 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 provisionals. 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 401 * Clarified that mid-dialog re-INVITE w/o session timer cancels session timer Issues: * Many complaints and limited interest * No defined requirements, not entirely clear the problem that is being solved. Proposition: only useful application is cleanup of state in proxies * Is it too complex for that usage? Proposals: * 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 method. There was also discussion around support of this in other methods, however, it was highlighted that that introduces the need to maintain state. Question: Who would support this draft? Medium hum vote support Question: Who would support if it were enhanced (that wouldnt support otherwise)? Even smaller hum vote. Question: How many people violently object to moving this draft forward as-is? No objections. o 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 hop-by-hop 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 mechanism. Conclusion: Go forward with Roberts proposal and update the text in RFC3261 appropriately to make use of this mechanism. |