Caller Preferences Jonathan Rosenberg dynamicsoft

What is going on here? Significant work occurred on the draft since IETF 55 Using the use cases draft as a requirements draft –Never before had a set of uses for caller prefs Proved non-trivial to design a mechanism that –Met the use cases requirements –Was easy to implement –Did the right thing across all use cases After submitting, I felt that current draft did not meet all use cases –I now believe it does, but needs some clarifications to make it work! –Proposal is to add clarification, and then anything that doesn’t work is out of scope –Several specs have a dependency on this – CPL, presence –Not sure what caller prefs will really be used for

New Rule Matching Proxy rule matching now much more explicit –Was neccesary to drive use cases Basic algorithm –For each rule, compute “score” against each contact Score is from 0 to 1, based on how explicit the match is –Overall caller preference is the weighted q-values across all rules, weighted by the score

Changes since -07 Added Paul Kyzivat as co- author New caller prefs params prefixed with “+” to avoid misinterpretation Merged Require-Contact into Accept-Contact –Semantic conveyed with a require parameter Aligned media types with SDP –Audio, video, application, data, control –Discuss how extensibility will work Addition of “explicit” contact parameter –“score” is either 1 or zero –With require, provides a means to insist on explicit match Changed voic tag to msgserver Q-value can appear anywhere

Changes Allow feature tags w/ no value to mean =“TRUE” –Contact:*;audio;video Value of a parameter can be a comma separated list of numerics and booleans Can negate numerics and booleans –Needed for numerics Fixed syntax bug that had all quoted strings having double brackets Range syntax uses a colon, not “..”. Allow generic-param in Accept and Reject Contact for extensibility Syntax of feature tag aligns with rfc2445 –Uses escaping for characters not allowed in token

Changes Proxies can insert preferences parameters Explicit preferences for non-standard schemes and methods is forbidden OPTIONS processing for UAS specified Added isfocus parameters –Conferencing team If caller prefs eliminates all contacts because of implicit prefs, re-run without any caller prefs A UA registering multiple contacts with differing caller prefs params has to use different user part –So it can figure out which prefs to apply Usage of sips for registering preferences is recommended

More Changes Uri-user and uri-domain parameters are used now –Accept-Contact; *;uri- domain=example.com Contacts without caller prefs params are “immune” to caller pref processing –Protects URIs where there are different capabilities at downstream UA –Example: forward to home proxy –Generalizes “only=true” mechanism Implicit prefs used only if there are NO explicit preferences –Combining the two is dependent on the usage Lots of clarifications

Open Issues Current draft cannot obviously support a few use cases –Ones where you wish to preferentially route to a UA which has the most explicit match –Example: A-C:*;audio;video;message Contact 1: Contact 2: –Will NOT preferentially route to contact 1 –But: A-C:*;audio;video;message;q=1.0,*;q=0.0 will! Adding support for this is a matter of clarifying the meaning of empty values