Minutes of SIP WG at IETF48 (Final) Edited by Dean Willis, 9/2/2000 Monday Session _____________ 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. Issues include: 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. Wednesday Session _______________ 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.