55th IETF SIP WG Meeting, Nov 19th, 2002 Notes recorded by Vijay Gurbani Brian Rosen and Joerg Ott have been helping the SIP WG since its inception; they are now retired. New co-chairs are Rohan Mahy (Cisco), Jon Peterson (Neustar) and Dean Willis (dynamicSoft). Dean remains the co-chair. 11 of 19 charter items are now complete; more will be added. Tracking: 31 drafts being tracked on supplemental page, 14 on IETF I-D tracker page (IESG is reviewing 4). New RFCs: 3310, 3311 (UPDATE), 3312 (manyfolks) and 3361 (DHCP). Caller Preferences, Jonathan Rosenberg Lot of changes since past revisions; last rev first alignment with rfc2533. Lots of changes; been discussed on the list. Biggest thing was better alignment with rfc2533. Open issues: 1/ Forced parameter: one big problem with this I-D was no use cases. Working with Paul K., Jonathan came up with 20 use cases. I-D on this was published, but did not make it to the deadline. Many apps require this forcing function; (&(foo=A)(bar=B)) will match (&(foo=A)(bar=B)(baz=C)). This is a problem when used with Require Contact. What this means: all UAs that do not support baz=C would have to explicitly say so. Not good; undue burden on UAs. Proposal: add a parameter to the Require Contact rule that says, 'must match'. So, (&(foo=A)(bar=B)) must match only these two features. 2/ AND within single feature tag. In some cases you want to specify that a UA has to support multiple values for the same feature tag; e.g. I want to reach a UA that supports INVITE and SUBSCRIBE; or a user that speaks English and Spanish. 2533 does not support this (you need to look at the 2533 model to understand why). Proposal: keep as is since doing anything else has a multiplicative effect on feature sets. Since none of the use cases had any problems with this, we will leave it as is. 3/ Weight q-values based on amount of overlap. In case where multiple UAs support the same feature sets, how to choose the better UA? Proposal: develop q-value algorithm which weighs based on 'amount' of overlap. Question from Dave. O: what is the metric of 'amount'? Jonathan: not quite sure yet; will have to work on it going along. Maybe better if I can come up with an algo and then present it. If it so happens that we cannot come up with an algo, so be it. We can drop it then. Keith D: why is exact match not a limiting value for this problem? Jonathan: somewhat different, really. 4/ Merge Require, Accept-Contacts: Require and Accept-Contact are similar. Proposal: Merge back into a single Accept-Contact header field. 5/ No one cares about this work, however, many things (IM, Presence, adaptation work) use this. Would benefit from more feedback from folks. 6/ Priority semantics: some rules for handling priority header; how do you match a request which contains a Priority header with Contacts that are defined? Proposal: None; need to work through use cases. 7/ 8/ Escaping: rfc2533 allows slash (/) and colon (:) as feature tags; we use tokens for these, which invalidates them. Proposal: use characters allowed in token, but not in ftag, to represent those characters -- bang (!) gets mapped to colon and single quote (') gets mapped to slash. Path forward: one more rev with these issues resolved and then re- issue WGLC. What to do about use cases? Should it find a home somewhere? Where? Many folks took the mic to say that the use case should find a home. Will be decided in the sipping WG. Content indirection, Sean Olson, Microsoft Remaining open issues: 1/ Use of 'size' parameter in Content-Type (no contention) 2/ Richer negotiations per MIME type (no contention) 3/ Security: privacy and integrity protection: SIPS, S/MIME, access control/policy and revocation of URLs. Proposal: 1/ Use standard 'size' parameter for message/external-body 2/ Recommend use of S/MIME and/or SIPS 3/ Access control is out of scope 4/ Don't add any more negotiation that what is currently provided by SIP 5/ WGLC Authenticated Identity, Jon Peterson Big change between last I-D: split into 2 documents - one I-D on auth-id body format and the other on the authentication service mechanism. AuthID Body I-D No open issue that Jon is aware of. This I-D talks about a format for a generic SIP authentication token: carried as a MIME body within a SIP request or response; can be signed by a UA or an authentication service. Now relies on either message/sip or message/sipfrag. If sipfrag, which headers need to be included to provide reference integrity and replay protection? From, Call-ID and Date are MUST; To, Contact, CSeq are SHOULD. Robert S: Call-ID may be a SHOULD Rohan: during review of 3pcc, the AD would like some content to be secure. If you were to send a page mode message you should still be able to get replay protection without intermediaries being keyed in. Cullen J: In different cases you need multiple sets of different signatures (e.g. passing thru a B2BUA, CSeqs may change). We must not make this list too big. Authentication Service: authenticates UAs, creates some sort of authentication token (as a MIME body), adds token to messages (may be the same entity as a default outbound proxy). 3 ways to do this: 1/ Redirection -- push body back to UA (does not work for responses, but appears best for requests). 2/ AuthService acts as a B2BUA, adds body itself, or 3/ Content-indirection: UA picks indirect URI that is populated by the AuthService (this is good for adding bodies to responses). Do we need to pick just one way? Or narrow the list down? Adam R: Why don't we pick a header? Jon: Given our experience with S/MIME, it has to be in the body. It is difficult to apply security properties to headers. Keith D: confirming that we do need it for responses as well as requests. How do we assert multiple identities? Do we have the capability of doing multiple identities with this draft? Jon P: Maybe; as long as the same authService will add all of these. Cullen J: Do we need to assert multiple identities only or for what purposes (e.g. I am fluffy@cisco.com for billing purposes, but cullen@cisco.com for others). AES and S/MIME Piece of rfc3261 errata. Recommends changing the required encryption for the SIP profile of S/MIME from 3DES to AES (AES has many advantages). Since S/MIME is not widely implemented yet, we can make these changes which we believe will make S/MIME more easy to implement. AES is much lighterweight, uses less memory, and is easier to implement. . Session Timer, Jonathan Rosenberg Status: -10 I-D submitted. Changes: rewrote overview of operations; clarified mid-dialog re-INVITE w/o session timer cancels session timer. Several comments on this was too complicated, lets get rid of it. So what might be the issue for this: no defined reqs, not entirely clear what problem is being solved. Proposition: only useful application is cleanup of state in proxies. Is it too complex for that usage? What are our options? Redefine scope, remove old reqs. Then design a simpler set of reqs. Or, keep the scope but clarify the wordings. Or, keep the scope, but pursue a completely new design (e.g. just use the dialog package). Adam: problem is if the proxy cannot get to that UA. Jonathan: right; the globally reachable URI problem. I am not proposing this, mind you; just bringing it up as a possible option. What methods to use? re-INVITE? A new method called PING? Path forward: consensus: keep the scope and clean up the wording. Only issue is method: UPDATE? PING? Cullen: I am okay with the scope part, just want to make sure that the timer runs on the UA not the proxy. Jonathan: But the timer has to be in the proxy since if it does not see the refresh after a certain time, it knows that the UAs are gone. Keith D: Problems: not generally applicable at the moment for all methods. Another problem: not many people understand what the reqs are. Maybe we should get the reqs out and have people review them. Jonathan: I don't think we should have formal reqs for work that was done when reqs were not needed. Dean: There should be a reasonably adequate set of reqs in the I-D itself; maybe it has mutated to the point where it does not make sense anymore. If so, maybe we can re-state the reqs. Eric B: Applicable to more than proxies; for example a media server and a app server will like to know if the other endpoint failed. Method to use: PING, UPDATE, re-INVITE? re-INVITE was used to preserve the soft state. Now that we are not worried about it, we can use one of UPDATE or PING. What do the chairs want to do? Chair asked for hum on how many people would implement this as it exists today? Hum heard. Chair then asked how many people would implement this if it was simpler? The hum was lower. Jonathan: will clean it up. SIPS URI Basic problem: text is a bit confused on whether it is e2e or hBh? Additional problems: mixed cases -- SIPS URI in Contact 200 OK if it was nowhere else? Basic problem is how to derive a route set from R-R such that it is consistent in both directions. This is a more general problem since it appears in Gonzalo's sigcomp draft, sips, and preserving transport=tcp for subsequent transactions. Maybe there is a general solution that is applicable to all such class of problems. The double R-R trick maybe a general solution. Rober S: Going forward, lets document the general solution and see where it goes from there. Jonathan R: Question is that there are several I-Ds doing that independenlty -- service draft and Gonzalo's. Robert S: Let's do an exploratory draft in one place and if it looks good we can work on it some more. No major topics to be discussed. Meeting adjourned.