Caller Prefs and Friends Jonathan Rosenberg dynamicsoft

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

Callee Caps Issue: Uri-user and uri-domain 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

Proposed Solutions 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

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

Caller Prefs Changes 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 Contact 1 Contact 2 Contact 3 Contact 4 Q=1.0 Q=0.8 Q=0.6 Qa=0.8 Qa=0.5 Qa=0.6 Qa=0.9 Contact 3 will be tried Before contact 2

Caller Prefs Changes 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

Open Issue #1 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 #2: Lost Cases 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

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

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

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