SIP Working Group

1. SIP Working Group Jonathan Rosenberg dynamicsoft

2. Priority changed from token to integer Support for quoted strings, range and inequality operations Proxies don’t need to know tag definitions Conflict resolution between caller prefs and headers (Allow, Accept) Proposed model for using RFC 2533 Removed media tag, add per-media tags (audio, video, message) Implicit media types Implicit language preferences Removed features attribute, added voicemail, attendant Negations apply to elements, not entire disjunction Caller Preferences Changes

3. Discussion of the caller-prefs parameter determination problem Require-Contact support Proxy strength for implementing matching algorithm is SHOULD Return of only=TRUE in subtle form – usage of URI implicit attributes only done in UA Events, methods implicit preferences use Require-Contact RFC 2533 tutorial [Graham Okd] Header usage for proxy changed from amr to r Caller Preferences Changes

4. If a UA doesn’t say anything about a param, it still matches a rule with that param. This is a problem when used with Require Contact Only works if UA indicates what they do AND what they don’t do For example: require a call to go to voicemail Puts burden on UA Bad for future parameters that we want to Require Open Issue #1: Forced Parameter (& (foo=A) (bar=B)) matches (& (foo=A) (bar=B) (baz=C))

5. In some cases you want to specify that a UA has to support multiple values for the same feature tag INVITE method and SUBSCRIBE method English and Spanish Current mechanism is to use multiple values of the Require-Contact header field: Can be tedious for long ANDs Putting & within the quoted string results in feature set multiplication Proposal: keep as is Open Issue #2: AND within single feature tag Require-Contact: *;methods=“INVITE” *;methods=“SUBSCRIBE”

6. Consider UA A: Consider UA B: And the Accept-Contact: Both A and B match the rule In some use cases, would like to preferentially try UA A first, as it is a “better” match Proposal: develop q-value algorithm which weights based on amount of overlap Can be done in RFC 2533 framework Open Issue #3: Weight q-values based on amount of overlap (&(video=TRUE) (audio=TRUE) (message=TRUE)) ((audio=TRUE)) (&(audio=TRUE)(video=TRUE))

7. Require and Accept Contact are similar Require says if it doesn’t match, discard Accept says if it doesn’t match, try it last Require says if it does match, keep it Accept says if it does match, set its q-value to X Proposal: Merge back into a single Accept-Contact header field Define should-match parameter which, if the contact predicate doesn’t match, causes it to drop (sets q=0 otherwise) Dovetails with must-match parameter, which says that it has to match EXPLICITLY even Open Issue #4: Merge Require, Accept-Contacts

8. This draft continues to receive little group input It is one of the most often cited drafts by other specs Presence IM Adaptation work Proposal: Rewrite intro to give it a bit more spark, explain better the power of this spec Its truly providing “one number” service – thats valuable Open Issue #5: No one cares

9. Not sure that the implicit preferences for Priority processing are right Paul K had pointed out some issues on the list Proposal: Work through use cases Define new algorithm Possibly discard implicit preferences for priority -> mostly a callee thing Open Issue #6: Priority Semantics

10. An INVITE may have a feature set in the Contact URI This describes the UAC Might like to try to route it to a “maximally compatible” UAS Can do that by using the Contact URI feature set as an implicit Accept-Contact feature set Proposal: leave it out Open Issue #7: Implicit compatibility preference

11. Sadly, RFC 2533 syntax for feature tags uses characters not permitted in token Slash (/) and colon (:) These characters are in usage (URI based registrations) Proposal Use characters allowed in token, but not in ftag, to represent those characters Bang (!) gets mapped to colon Single quote (‘) gets mapped to slash Open Issue #8: Escaping

12. Add a “must-match” attribute to a Require-Contact rule If the contact predicate does not contain an explicit value for all feature tags in the rule, eliminate the contact Manifests itself as “pre-processing” before the rfc2533 matching process Proposal

13. Path Forward • One more revision with these issues resolved • Then we are ready • Re-issue wglc?? • What do do about use cases? Should it find a home somewhere?

14. Session Timer • Status • -10 draft submitted • 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

15. Open Issue • This draft seems to have problems • Many complaints that it is too complex • Seems to be 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?

16. What are the options • Redefine the scope, removing some of the underlying requirements, develop a simpler solution • Keep the scope, but just clarify the wording • It can be better • Keep the scope, but pursue a completely new design • For example – just use the dialog package!

17. What method to use? • What method to use for the refresh? • Historically, was just INVITE – for “stateless” operation • A few revs ago, we allowed UPDATE, w or w/o SDP • Proposal to use PING to align with RTSP • Still need session timer headers – not clear of benefit over UPDATE technically

18. Path Forward • Consensus appears to be option 2 – keep the scope and clean up the wording, to finish this off • Only issue is the method • Propose to keep UPDATE

19. SIPS URI • Basic problem: • 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 was nowhere else? • Solution • Need to come to agreement on the high level behavior • From there the detailed behaviors will flow