Edited by Dean Willis, 8/28/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.
Caller Preferences proceeding, some discussion on removal, agreement to proceed to last call.
Info draft
Reliability of Provisional Messages submitted to IESG on July 10.
Supported/Server features on 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.
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.
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.
Case Sensitivity of URLS: (URI Comparison) general consensus for documented approach. Rohan Mahy suggested some sort of locally extended flexibility be considered.
Session-Timer: Several changes reveiwd. Jonathan Lennox asked if it is legitmate for a Require: header to be inserted by a proxy.
Context and Architecture for SIP-T -- Aparna Vemuri
Purpose: feature transparency.
Issues
* SIP MIME type negotiation - standard 415
* Want to be able to tell a UAS to ignore certain MIME types
- ISUP repitition problem: * not all ISUP parameters are needed; many will contain information
from origination side
Changes in DCS -- Bill Marshall
All six drafts now in compliance with rfc2026.
Manyfolks: handling of case where UAS wants preconditions, but UAC didn't
indicate support for itPrivacy: 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.
Call Authorization: only minor editorial changes
Architectural Draft: Much larger in size
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.
Update on rfc2543bis -- Henning Schulzrinne
Nothing thats not backwards compatible. Not SIP/2.1.
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
* 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)
* addition of spirals
* split spec in half - framework and methods draft
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, throttling, some security things in there.
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
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 Framwork -- 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. Get discussion on sip rqmts onto the list
3rd Party Call Control with SDP preconditions -- Gonzalo Camarillo
No comments, two open issues will be taken to the list.
CC/PP exchange -- Iizuka
Comments:
This is similar, perhaps overlapping the caller preferences problem (Ed: actually, it's the flip side of the same problem).
SIP may not be the right answer to this question -- or maybe we haven't asked the right question yet.
This approach raises the question of whether the Guidelines should include a direction for atomicity.
TIPHON work on SIP -- 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. It has utilility in other methods. Also, generalizing method to point to an arbitrary URL has interesting implications.