Jonathan Rosenberg wrote:
>
> I'm polishing off caller prefs, so I wanted to get some comments in here.
>
> Generally, I agree completely with James. If you want a fancy call center
> application, caller prefs is NOT going to cut it. In these applications, the
> language preferences and skillsets of the operators will all be configured
> and managed, rather than dynamically updated in SIP registration messages.
I am investigating using callerprefs exactly for this.
Sure they will be configured and managed, but with callerprefs they can
be managed and configured in a different place than where they are used
for assignment. This provides a more uniform way for managing the
dynamic capabilities of operators.
Much of the stuff in callerprefs is already overkill unless you are
trying to do something more complex that managing a couple of phones.
E.g. the language stuff isn't needed for a personal phone. (Presumably
you speak the same languages regardless of what phone you use.) Much of
callerprefs seems designed for call center sorts of applications.
> If you do want to make use of caller prefs for more fancy matching rules,
> the "hacks" proposed by James and Paul are reasonable and are the right way
> to go. They will only take you so far, of course.
I don't think the call center sort of requirement should so easily be
written off.
>
> To answer some specific questions raised in this thread:
>
> The behavior of:
>
> Contact: sip:[EMAIL PROTECTED]; language="en"; q=1.0,
> sip:[EMAIL PROTECTED]; language="es"; q=0.2
>
> in a REGISTER would indeed be to cause the second contact to overwrite the
> first. Contacts are keyed in the location service ONLY by the URL. There did
> seem to be consensus in the thread that this was the likely behavior, and I
> want to confirm that it is. However, bis doesn't explicitly say this, I am
> merely describing what the result will be if an implementation follows
> verbatim the process described in 10.3 of bis-05, which is now much more
> explicit in defining registrar behavior. I don't see a strong need to add
> additional text to explicitly point out this case.
I have tried to read the bis carefully and critically, and I don't see
language that I would consider normative one way or the other on this.
Certainly not in bis-04. Before considering this to be the intended
behavior, I think we ought to consider whether another interpretation is
reasonable and valuable. It may not matter if it isn't consistent with
current implementations because this sort of usage is not likely occur
currently.
Isn't the above a perfectly valid example of something that ought to
work? If you can't do something like this, then what is the point of
supporting "language" at all?
Another example that is very reasonable:
Contact: sip:[EMAIL PROTECTED]; media=audio; q=1.0,
sip:[EMAIL PROTECTED]; media="video"; q=1.0,
sip:[EMAIL PROTECTED]; media="audio,video"; q=0.5,
sip:[EMAIL PROTECTED]; media="audio"; q=0.7,
sip:[EMAIL PROTECTED]; media="audio,video"; q=0.2
This is attempting to say that joe's desk phone does audio great, but no
video. His pc does both audio and video, but it isn't great to use as a
phone. (Maybe just not as convenient to use.) He also has one of those
new cellphones that are pretty good at voice, and that do video, but not
very well (small screen, low frame rate). Presumably these contact
headers are coming from a registrar that has accepted independent
registrations from the phone, pc, and cellphone. At the moment all are
present, but at other times various other subsets may be registered.
Caller's looking only for audio should get the desk phone, and callers
looking for both audio and video should get the pc. If the pc is turned
off and unregistered, then audio callers should still get the desk
phone, while a/v callers should get the cell phone.
But doing this requires multiple contact headers for the same endpoint
(or hacks).
Paul
_______________________________________________
Sip-implementors mailing list
[EMAIL PROTECTED]
http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
