[SIP] Final Minutes of SIP WG, IETF 48

The following are the final minutes of the SIP WG meetings at IETF 48. A
better-formatted HTML version is available at:
http://www.softarmor.com/sipwg/meets/IETF48/minutes/minutes.htm

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
intent 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.

_______________________________________________
SIP mailing list
SIP@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/sip