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.8

Q=0.6

Qa=0.8

Qa=0.5

Qa=0.6

Qa=0.9

Contact 3 will be triedBefore 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