SIP WG

Tuesday November 19, 1930-2200, Salon I

Notes recorded by Mary Barnes

 

General

• Thanks to Joerg Ott and Brian Rosen for serving as chairs.
• Welcome to Jon Peterson and Rohan Mahy.

 

 

Status and Charter (Rohan)

 

• 11 of 19 charter items complete

 

• New RFCs - 3310, 3311, 3312, 3361

 

Caller Preferences Open Issues
Jonathan Rosenberg
http://www.ietf.org/internet-drafts/draft-ietf-sip-callerprefs-07.txt

 

Briefly reviewed Changes since last rev: with the biggest change being the  Require-Contact .

 

There is now a related scenarios draft (not yet in the repository)

 

Reviewed Open Issues:

Issue#1: Forced Parameter

• If a UA doesn’t say anything about a parm, it still matches a rule with that parm
• This is a problem when used with Require Contact:

o       Only works if UA indicates what they do AND what they don’t do

o       For example, require a call to got to voicemail

o       Puts burden on UA

o       Bad for future parms that we want to Require.

 

Proposal: Add a parm to Require Contact rule that explicitly says whether it MUST match.

 

Issue #2 AND within single feature tag

o       In some cases, you want to specifiy that a UA has to support multiple values for the same feature tag

o       Current mechanism is to use multiple values of the Require-Contact header field

 

Proposal: keep as is

 

Issue #3: Weight q-values based on amount of overlap

 

Proposal: develop q-value algorithm which weighs based on amount of overlap; can be done in RFC 2533 framework.

 

Issue #4: Merge Require, Accept Contacts

• Require and Accept Contact are similar

 

Proposal: Merge back into single Accept-Contact header field

o       Define should-match parm which if contact predicate doesn’t match, causes it to drop.

• Same as open Issue #1.

 

Issue #5: No one cares

o       Little feedback on this draft.

 

Proposal: Rewrite intro to give it a bit more spark, explain better the power of the spec.

It’s truly providing one number service.

 

Issue #6: Priority semantics

 

Proposal:  work through use cases.

 

Issue #7: Implicit compatibility mechanism

Skipped…

 

Issue #8: Escaping

• Sadly, RFC 2533 syntax for feature tags uses characters not permitted in token (slash and colon)
• These characters are in usage

Proposal: Use characters allowed in token, but not in feature tag, to represent those characters; bang gets mapped to colon, single quote gets mapped to slash.

 

Conclusion: Although, there was lots of discussion on alternatives, none were deemed reasonable, so will go forward with proposal.

 

Path Forward:

• One more rev with these issues.
• Ready for WGLC?
• What about use cases?  Should it find a home somewhere?
• There was some discussion on what to do with the use cases, with the general consensus expressed that the use cases are useful; whether they should remain in a separate doc, be put in an appendix of this doc or merged with other call flows is still undecided.

 

Overall Conclusion: 2 week WGLC after proposed changes. 

 

Content Indirection Open Issues
Sean Olson
http://www.ietf.org/internet-drafts/draft-ietf-sip-content-indirect-mech-00.txt

 

Issues:

o       Use of “size” parm in Content-Type:

o       Richer negotiation per MIME type

o       Security

o       Privacy & Integrity protection: SIPS, S/MIME

o       Access Control/Policy

o       Revocation

 

Proposal:

o       Use of standard “size”  parm for message/external-body

o       Discussion of  “size” parameter and whether it should be mandatory.  Conclusion was that it should be a SHOULD, with sufficient wording around the importance of this.

o       Recommend use of S/MIME and/or SIPS

o       Access control is out of scope

o        Don’t add any more negotiation than what is currently available in SIP

 

Conclusion: Propose WGLC after changes.

 

Rohan showed Group the draft tracker page to display status of WG drafts.

 

During this discussion, Allison highlighted than anything can be added as far as the progress of the drafts; chairs make requests for changes to the ADs. Allison also highlighted that compression has been approved.  There is currently a delay in updating the information due to the current meeting being underway. Rohan also highlighted that there are lots of new drafts being enqueued.

 

 

SIP Guidelines Open Issues
Rohan Mahy
http://www.ietf.org/internet-drafts/draft-ietf-sip-guidelines-06.txt

 

Issues:

• Notion of CANCELs and provisional responses for non-INVITES currently conflicts with RFC 3261, that you must specify processing in new drafts.  Rohan believes this causes more harm than good.  Wants WG feedback on this. As a chair, just because you can do something, doesn’t mean you should.

 

Discussion:

There was discussion around exactly what’s currently in RFC 3261, with Rohan suggesting that there’s never a good reason to receive Cancel  for a non-INVITE. However,  Robert S. highlighted that there is one.  If a non-INVITE times out with no responses, the SRV draft is written that the endpoint fails over. Immediate provisionals are BAD for non-INVITE.  Sending a provisional before a transaction times out can prevent some problems.

 

Conclusion: Robert to start list discussion on this particular topic once draft is available.

 

Rohan summarized that there are 2 problems:

• Provisionals
• Cancels for non-INVITES

 

Continued discussion:

The discussion continued around TCP introducing additional problems and the importance of separating the 100 Trying from the  discussion of provisionals.

 

2^nd Conclusion: Take discussions to the list.

 

Identity and Privacy and AuthID Open Issues
Jon Peterson

http://www.ietf.org/internet-drafts/draft-ietf-sip-privacy-general-01.txt

 

No explicit discussion of this draft, which is in the RFC Ed. Q.

 

Draft-peterson-sip-identity-00 split into 2 WG documents:

 

http://www.ietf.org/internet-drafts/draft-ietf-sip-authid-body-00.txt

 

A specification of a MIME body that could be used as an authentication token.

• Now relies on either message/sip or message/sigfrag
• IF sipfrag, which headers need to be included
• From, Call-id, date are MUST
• To, Contact, Cseq are SHOULD

 

Discussion:

• There was discussion around whether Call-id should always be a must as there are scenarios (Referred-by and 3pcc) that need a flexible mechanism for correlation. There was a proposal that it  should be Call-id unless you provide another mechanism for replay protection. There was discussion and agreement that it is always deterministic and clear when you don’t want to include call-id.

o       There was also discussion around the vulnerabilities of NOT sending the Contact header, with the suggestion that if the AIB is intended for use inside a Dialog, then a Contact should be a MUST.

 

Conclusion:  Jon will address this in the draft.

 

 

http://www.ietf.org/internet-drafts/draft-ietf-sip-identity-00.txt

 

o       Defines status codes and practices for providing an authentication token (which might be auth-id body, or could be something else). 

o       AuthService authenticates user agents, creates some sort of authentication token (as a MIME body), adds token to messages

o       Document describes 3 ways that body can be added to requests:

o       (Essentially)  Redirection (push body back to UA)

o       Auth Service acts as B2BUA

o       Content-Indirection

§         This way is optimal for adding bodies to responses

 

Discussion:

o       There was discussion around why a header can’t be used for the mime body.  However, Jon highlighted that given, the S/MIME direction it really has to be a body.

 

o       There was also discussion of the long term identity versus short term identity solutions (as described in the past) and it was questioned as to how the multiple identities in the “short term” document would be supported.  It was discussed that the support of this has to do  with how the token is structured.  There are 6 headers, 3 musts, 3 shoulds and optionals. It wasn’t believed that it’s necessary to define the Multiple identities explicitly in this draft.  But, this discussion is a reasonable one to have.  The concern expressed was that although there are multiple identity headers, there aren’t clearly defined semantics. 

 

             Proposal: Discussion of this topic should continue on the list.

 

o       There was discussion around Normative support for AIB.  It was agreed that a normative statement is needed for interoperability.  You need to define the scope if it’s negotiable, etc.  This gets into the downgrade attack issues, etc.  There was concern that this might limit extensibility of the mechanism, however, Allison highlighted that the minimum mandatory to implement should be specified and that should not limit SIP’s future. 

 

 

http://www.ietf.org/internet-drafts/draft-peterson-sip-smime-aes-00.txt

 

• Recommends changing required encryption for the SIP profile of S/MIME from 3DES to AES. 

 

• Why deal with this now? Because S/MIME for SIP has yet to catch on, better to fix now.  Lower footprint of AES might also help foster S/MIME adoption.

 

• Additonal advantage: Same encryption algorithm as TLS (AES).

 

Discussion:  There was a proposal to add this as a 3261 bis bug, but it was highlighted that this is of much greater scope than a typical 3261 bug. There was also a concern raised over obsoleting parts of  an RFC, however, Allison highlighted that it’s an accepted practice to update parts of RFCs with another RFC.  It was suggested that occasionally writing a roadmap makes navigating the RFCs easier. 

 

Conclusion: Seemed to be general WG agreement for this to be a WG document.

 

Session Timer (Jonathan) – draft-ietf-sip-session-timer-10

 

Changes:

• Rewrote overview of operation
• 422 response causes you to retry with same call-ID and bumped CSEQ like 401
• Clarified that mid-dialog re-INVITE w/o session timer cancels session timer

 

Issues:

• Many complaints and limited interest
• What might be the issue?
• No defined requirements, not entirely clear the problem that is being solved.
• Proposition: only useful application is cleanup of state in proxies
• Is it too complex for that usage?
• Proposals:

1. Redefine the scope
2. Keep the scope, but clarify the wording
3. Keep the scope, but pursue a completely a new design

• For example, just use the dialog package!

 

Conclusion:

• Concensus appears to be option 2 – keep the scope and clarify the wording.

 

Discussion:

• There was some discussion around the lack of requirements, which is likely what leads to many of the problems in understanding the draft and finding issues therewith.  Proposal: Draft should have a reasonable statement of requirements in the draft, including some which are not already there.

 

• There was some discussion of previously discussed alternatives, including the suggestion that this solution could align with RTSP and use the PING method. 

 

• There was also discussion around support of this in other methods, however, it was highlighted that that introduces the need to maintain state.

 

Hum vote (Not sure if ”ve captured the posed questions accurately, but the order of the hum votes are accurate):

o       Who would support this draft? Medium hum vote support

o       Who would support if it were enhanced (that wouldn’t support otherwise)? Even smaller hum vote.

o         

Final Conclusion:  Jonathan will clarify the current version and submit for going forward and WGLC.

 

 

RFC3261 Open Issues - SIPS URI
Jonathan Rosenberg
http://www.ietf.org/rfc/rfc3261.txt?number=3261

 

Basic problem (SIPS URI):

• Text is a bit confused on whether its e2e or hop-by-hop

Additional problems:

• Mixed cases – SIPS URI in Contact 200 ok if it ws nowhere else?

Solution

• Need to come to agreement on the high level behavior
• From there the detailed behaviors will flow

 

Discussion:

• There was some discussion around the requirement for using SIPS.  The general problem is with the double Record Routing.
• It was highlighted that there needs to be one place that properly  describes record routing that can be re-used by compression, SIPS and transport.  It was highlighted that (for compression) the  double record routing  works okay because there is not currently a scenario that needs to change something in the response. Robert proposed that you can use this abstraction to highlight that the link characteristics on either side are different. And that, SIPS may introduce additional constraints.

 

Proposal: Robert will specify this general mechanism for multiple record routing. The  specific cases where the issues have been identified in RFC3261 with different characteristics should reference the general mechanism.

 

Conclusion: Go forward with Robert’s proposal and update the text in RFC3261 appropriately to make use of this mechanism.