NOTE: This charter is a snapshot of the 48th IETF Meeting in Pittsburgh, Pennsylvania. It may now be out-of-date. Last Modified: 17-Jul-00
Jonathan Rosenberg <firstname.lastname@example.org>
Joerg Ott <email@example.com>
Dean Willis <firstname.lastname@example.org>
Transport Area Director(s):
Scott Bradner <email@example.com>
Allison Mankin <firstname.lastname@example.org>
Transport Area Advisor:
Allison Mankin <email@example.com>
To Subscribe: firstname.lastname@example.org
In Body: subscribe
Description of Working Group:
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 developing proposed extensions.
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 general purpose, 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. The group will also maintain open dialogues with the IP telephony (iptel) working group, whose Call Processing Language (CPL) relates to many features of SIP, and the PSTN and Internet Internetworking (pint) working group, whose specification is based on SIP; and will consider input from the Distributed Call Signaling Group (DCS) for distributed telephony services.
The specific deliverables of the group are:
1. A Draft Standard version of SIP.
2. Completion of the SIP call control specification, which enables multiparty services, such as transfer and bridged sessions.
3. Completion of the SIP caller preferences specification, which enables intelligent call routing services.
4. Completion of the SIP INFO method extension, used for carrying SIP session related information.
5. Completion of the "183 response" extension, to enable early session establishment.
6. Define a MIB for SIP nodes
Other deliverables may be agreed upon as extensions are proposed.
Goals and Milestones:
INFO Method extension submitted to IESG
Early session establishment extension submitted to IESG
Caller preferences specification submitted to IESG
Call control specification submitted to IESG
Draft standard version of SIP submitted to IESG
SIP MIB submitted to IESG
No Request For Comments
Minutes of SIP WG at IETF48 (Final)
Edited by Dean Willis, 9/2/2000
Agenda Bashing and Startup
Scott Bradner reviewed IPR notice.
Karen O'Donahue volunteered to take notes.
Proposed agenda review, no discussion.
Status of Working Group Efforts -- led by Jonathan Rosenberg
Guidelines for Authors proceeding as expected. There was consensus to make it a BCP. No milestones set yet. The WG will continue to evolve the document with Jonathan Rosenberg acting as editor, and list suggestions and discussion are welcome.
Caller Preferences proceeding, some discussion on removal, agreement to proceed to last call.
Info draft in IESG review, publication expected (Note: Approved 8/21/2000)
Reliability of Provisional Messages submitted to IESG on July 10.
Supported/Server features in IESG agenda for consideration.
Open List Issues -- Rosenberg
Multiple transport parameters (Transports:). Could be a new parameter, or could be lisetd in the Contact: field with multiple Contact: headers. Discussion ensued, with both SRV (poor for negotiation) and SLP (possible for interdomain) mentioned. Henning summarized consensus that the number of transports is relatively small and the existing mechanism seems to work for now.
How to handle OPTIONS and REGISTERS if max-forwards-0? Suggestion made that OPTIONS return 483, REGISTER be silently discarded. lennox objected to special behaviors for different methods. Henning asserted that max-forwards is really for debugging, and the handling isn't all that critical.
Additional Detail on error Messages (Dave's Error Messages): Sparks suggest use of Refer (to, by) headers. Dave Oran prefers new failure-info header. Olson and others argues against overloading Contact. Henning argued need for explicit header. General consensus resulted on basic Dave mechanism with new explicit header. Dave Oran is expected to submit an Internet Draft on the discussed mechanism.
Mandatory UDP: Some hot debate, no real conclusion. Lawrence Conroy argued need for a simple TCP-only system, and Jonathan Lennox noted that making UDP mandatory has security implications for systems that are trying to use TLS. If an implementation wishes to define policy such that TLS is required for security, but is required to support UDP due to this change in SIP, then we have a requirements conflict that has implications for security DTMF discussion was deferred to Session 2.
Embedded Images: Much discussion on issues of size, direct vs. indirect embedding and relating content to messaging. Henning Schulzzrinne, Adam Roach, Sean Olson, and Scott Petrack made points. General consensus seemed to be to stay with 2543 approach and to prefer indirect reference where feasible. There seemed to be a consensus on use of standard MIME syntax, as this solves many of the discussion points.
Case Sensitivity of URLS: (URI Comparison) general consensus for documented approach. Rohan Mahy suggested some sort of locally extended flexibility be considered, that in some application specific cases it might be necessary to use case-sensitive comparison.
Session-Timer: Several changes reveiwed. Jonathan Lennox asked if it is legitmate for a Require: header to be inserted by a proxy.
Multiple Outstanding Requests:Question: is it valid to have this situation? COMET and PRACK are examples where it is reasonable. Group consensus to allow it. Jonathan added the note that, for INVITE, only the most recent message matters as far as SDP is concerned. Christian Huitema warned that care must be taken in the maintenance of the state machine. Someone commented that in addressing the question, we should decide whether the content is pipelining or asynchrony. General discussion followed, with no consensus recorded. Henning noted that the outcome must be as if requests had been received and processed in CSEQ order.
Context and Architecture for SIP-T -- Aparna Vemuri
Purpose: feature transparency.
SIP MIME type negotiation - standard 415 (Ed: Huh?) Want to be able to tell a UAS to ignore certain MIME types. This clearly works for simple rejection. There are challenges when some of the body is mandatory, rest is optional. Presenter proposed use of content-disposition header.
ISUP repetition problem: not all ISUP parameters are needed; many will contain information from origination side. The cleanup problem appears to be interesting -- Tom Taylor noted that there appears to be no "automatic solution". Discussion of Content-Disposition: Lyndon Ong asked whether usage is mandatory. Jonathan Rosenberg responded that the current consensus is that this is optional, and reminded that SIP-T is in all respects SIP, not a separate protocol.
Changes in DCS -- Bill Marshall
All six drafts now in compliance with rfc2026.
Manyfolks: The draft now includes discussion of case where UAS wants preconditions, but UAC didn't indicate support for it in the original INVITE.
Privacy: 1) Needed to add proxy-require. 2) Removed authentication ?? sip security task force will handle. 3) OSPS removed. 4) Editorial changes to align with Guidelines.
State: 1) Usage of Supported/Require added . 2 )Interaction with Hide. If Via headers hidden, then state headers need to be hidden -> resulting in Proxy-Require. 3) will change syntax to include port number. There appears to be an open issue in the interaction between Route/Record Route and end to end encryption.
Call Authorization: only minor editorial changes Architectural Draft: Much larger in size than original, and now intended for publication on informational rather than standards track.
Proxy-Proxy: 1) DCS Specific extensions tracing of obsence and harassing calls resource coordination for packetcable call transfer and three way calling. 2. OSPS, Billing-Info, Require and Proxy-Require used. 3) Next steps: * design complete, * maybe issues for inter-domain operation, * 4 documents for proposed. Consensus was achieved on adding four proposed drafts as wg items. Informational draft will be on hold until proposed documents are complete. This document will provide the basis for IANA registration of Require: DCS.
Brief discussion of which of the DCS items would be WG work items. Comment that the SDP in draft-manyfolks-... might be an MMUSIC work item. An AD (Scott bradner) agreed to leave it with SIP. There was consenus to accept draft-manyfolks-, privacy, state, and call authorization as WG work items.
Update on rfc2543bis -- Henning Schulzrinne
Nothing that is not almost completely backwards compatible. Not SIP/2.1 -- this is a clarification, is more indicative of the current state of the art than is RFC2543, and implementors are urged by the author to track this draft.
Lots of clarifications:
- ACK Forwarding
- consistencies between tables and texts
- e-e vs. h-h distinction has been deprecated, different table which describes what proxies are allowed to do
- headers tentatively added (Call-Info, Reply-To)
- separate call and transaction state machines
- cancel/invite are separable
(will need to add note on need for timer in cancel, since you may not get a 487)
- clearer distinction between loops and spirals in discussion of loop detection
- There has been discussion of possibly "splitting the spec in half" -- into framework and methods drafts, possibly to help with the IMPP implementations that may not need all of the SIP methods.
- Some features need to be removed as too immature to advance to Draft Standard, notably Via hiding and use of PGP.
MIB Draft -- Dave Walker
Partition of MIB: SIP common, UA, Server (proxy and redirect), Registrar Support modules: Added support for multiple instances in the same system and notification throttling Discussion included whether to have security objects, and questions with respect to the transaction table.
Message Waiting Indicator -- Rohan Mahy
Several issues were raised in discussion: 1) Should compare and contrast with HTTP and poll models such as POP and with SNMP, asnwer "why these are not suitable and SIP-MWI is". 2) A MWI is really just a presence information bit, it might be more appropriate to just use the presence mechanisms, 3) the alerting mechanism should be designed generically rather than specifically as a voice-mail function.
SIP-H.323 requirements -- Radhika Roy
Point made -- this interworking is for basic call, not extra signaling like Q.SIG. Also, IETF work should not address purely operational issues.
Call Flows -- Johnston
Several changes and corrections have been made.Multiproxy and transfer additions needed. Caveat: this is not a complete debug list, we probably need to do some more work in that respect.
OSP Token -- Johnston and Thomas
consensus was to include it as a header
question: can you include a reference to the token instead of the actual token?
Note: Proxies may read or insert but not modify tokens.
question: maybe recommend tcp since the tokens are large
DTMF -- Skip Cave and Bert Culpepper
Skip proposes that there are two problems - dtmf transport, readily covered by RTP, and key input, which is a different problem. This is supported by a historical analysis of the deployment of DTMF applications. Discussion centered on solving the user input problem. Donovan proposed using SUBSCRIBE/NOTIFY mechanisms to establish a signaling relationship for user input. Question: do app servers need access to the RTP stream?
No conclusion, Lawrence Conroy noted some concern with signbal loading in mobile applications, and specif concern with SIP re -INVITES.
Emergency Services -- Henning Schulzrinne
Discussion centered on the applicability of SLP, with some contention..
Brian Rosen's note indicate that there was a consensus indicating that SLP should be usable. Issues, however, extend beyond SIP -- for example, emergency services for Web users?
Appliance Framework -- Stan Moyer
No discussion allowed by chairs due to time constraints.
AAA Requirements -- Calhoun, etc.
Comments:Must take into account discussions in the AAA group. Problem space must include use of services other than Internet Access logon. The authors mentioned that other users of SIP are keen to use the output of the IETF AAA WG, namely DIAMETER or whatever DIAMETER becomes after the AAA WG is done with it. 3GPP and 3GPP2 have selected DIAMETER as their AAA protocol, and that MWIF is leaning in that direction. AAA WG has requested that SIP requirements be brought forth, and absent any such have not included SIP within scope. We need to have discussions of the appropriate requirements on the SIP mailing list.
3rd Party Call Control with SDP preconditions -- Gonzalo Camarillo
No comments, two open issues will be taken to the list.
Composite Capabilities and Preference Profiles (CC/PP) exchange -- Iizuka
Comments: This draft proposes extending CC/PPex, proposed by W3C to allow certain push services to know in advance the capabilities and preferences of certain endpoints. Several participants in the discussion feel that this is similar to or perhaps overlaps the caller preferences problem. (Ed: actually, it's the flip side of the same problem -- one might call it "callED preferences"). Many present felt that SIP may not be the right answer to this question -- or maybe we haven't asked the right question yet. Other possibilites include SLP, CONNEG, and other capability negotiation frameworks. Christian Huitema remarked that this approach raises the question of whether the Guidelines draft should include a direction to authors with respect to the need for atomicity in extensions..
TIPHON work on SIP -- Paul Sijben
No discussion due to time
SIP Firewall Policy mechanisms -- Jon Peterson
No discussion due to time
Call Control and Transfer -- Robert Sparks
Refer is not just for INVITES anymore. The Refer header has apparent utility when used within messages defined by other SIP methods. Also, generalizing method to point to an arbitrary URL has interesting implications, given the parameterization of SIP state information such as Call-ID possible in a URL.
3rd Party Call Control with SDP Preconditions
SIP Telephony Call Flows
User to User Key Signaling Protocols
SIP and DTMF
DTMF & Universal User Key Input
Application-Layer Policy Enforcement at SIP Firewalls
SIP-H.323 Interworking Requirements
SIP and IN
SIP-Enables IN Services: Implementation Experience
ITU-T Activities on SIP-IN
SIP for Light Bulbs: Using SIP to Support Communication with Networked Appliances
SIP ML Open Issues
How can AAA infrastructure support services and applications in roaming architectures?
Message Waiting for SIP
New Drafts in SIP WG
OSP Authorization Token Header for SIP
"manyfolks" and "dcsgroup" drafts
SIP Session Timer
Changes and Status of SIP WG Drafts
SIP-T: Context and Architectures
Message Waiting for SIP