1 / 12

Caller Prefs and Friends

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?

scruggsa
Télécharger la présentation

Caller Prefs and Friends

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  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

More Related