Caller Prefs and Friends

1. Caller Prefs and Friends Jonathan Rosenberg dynamicsoft

2. Status • Split caller preferences in half • Draft-ietf-sip-callerprefs-09 • Draft-ietf-sip-callee-caps-00 • And the use cases document went to sipping • Draft-ietf-sipping-callerprefs-usecases-00 • Why split? • Many drafts blocked on caller prefs • Still needs some work • Capabilities stuff is more stable, and that’s what most of the other specs need

3. The spec recommends that a UA register the uri-user and uri-domain attributes These attributes are the same as the user and domain part of the contact URI Why? Assisted transfer – force a call to go to a specific UA instace Problems Really ugly Repeats contact information Callee Caps Issue: Uri-user and uri-domain

4. Remove it altogether GRUU mechanism is a better solution But – that will be a while Caller prefs may still be a while too Use a new “device-id” attribute Just an opaque, unique ID representing the device Can be used for assisted transfer Same issues as uri-user and uri-domain Also can be used to uniquely identify the source of a registration We have had requests for this Proposal: device ID Proposed Solutions

5. Callee Caps Plan • Issue a brief 2 week comment period • Issue a revision including the previous change and any other comments • Already gotten some privately

6. New Algorithm Avoids q-value arithmetic Caller preference Qa = AVG of scores Not a qvalue – is a cardinal metric Any callee contact with the same q-values are reordered based on Qa Caller Prefs Changes Q=1.0 Qa=0.8 Contact 1 Q=0.8 Qa=0.5 Contact 2 Q=0.8 Qa=0.6 Contact 3 Qa=0.9 Q=0.6 Contact 4 Contact 3 will be tried Before contact 2

7. Removal of q-values from Accept-Contact rules They were not used in any use cases Clarified purpose of Proxy-Require Decide how to structure callerprefs on fallback More discussion on usage of require and explicit tags Still confusing though When a proxy redirects, q-values in redirect are arbitrary – order has to be the same as caller prefs algorithm Caller Prefs Changes

8. Redirection is a problem Problem is that RFC3261 has proxies merging q-values from redirects We now understand that this is broken So, if a redirect server uses arbitrary q-values in redirect, might be useless Might be useless anyway Proposal Include text in caller prefs calling out that rfc3261 is wrong Encourage right behavior There is already a bugzilla bug against this Open Issue #1

9. The new algorithm means we can’t do certain things anymore We cannot override a callee q-value ordering Can still eliminate ones you don’t want Example use case that was affected: Y has audio and videophone, prefers audio X wants to reach videphone, but will fall back to audio if not available Proposal: accept the loss and move on Open Issue #2: Lost Cases

10. Plan for Caller Prefs • The new algorithm seems a LOT better • Need to get buy-in from Ted Hardie • If he thinks its reasonable, submit revision with fixes and other changes, and then wglc • Not a trivial rev – still need much better text on explicit/require • If he has more guidance, continue working it

11. Changes in Use Cases • Aligned with –09 caller prefs • To check which cases now fail • Added a hearing impaired use case • Though I want to remove it • Added example registrations for different types of devices • Added some material to motivate caller prefs

12. Open Issues • Use case in 3.14 (Speak to Executive) is better done with CPL/servlets – should we remove case? • Yes • Do we advise devices to register what they can’t do in addition to what they can? • Though caller prefs works better – no • Do we want to include text that describes how to implement the rfc2533 algorithm easily? • Yes – otherwise it will be done wrong