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.
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.
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.
Thanks,
Jonathan R.
> -----Original Message-----
> From: James Undery [mailto:[EMAIL PROTECTED]]
> Sent: Wednesday, October 17, 2001 4:52 AM
> To: Paul Kyzivat
> Cc: [EMAIL PROTECTED]
> Subject: RE: [Sip-implementors] Re: Need clarification on callerprefs
>
>
> First off I'll agree this is less than ideal, and then make a vague
> defense of it.
>
> Caller preferences are at best hints, that is you can't guarantee they
> are supported. Implementing complex behaviour with them isn't going to
> be a good idea, caller preferernces are just that preferences. Showing
> it's possible to produce an ugly hack that works, in my mind shows
> caller preferences and SIP do their job but something else is required
> for the functionality you are looking for.
>
> James
---
Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave.
Chief Scientist First Floor
dynamicsoft East Hanover, NJ 07936
[EMAIL PROTECTED] FAX: (973) 952-5050
http://www.jdrosen.net PHONE: (973) 952-5000
http://www.dynamicsoft.com
>
> > -----Original Message-----
> > From: Paul Kyzivat [mailto:[EMAIL PROTECTED]]
>
> > James,
> >
> > Technically the solution you offered seems to work for this
> > particular
> > case. However it does so at the expense of abandoning the primary
> > advantages of callerprefs. It means that there must be a separate
> > address registered (e.g. [EMAIL PROTECTED] and
> > [EMAIL PROTECTED]) and that
> > anyone proposing to support a particular capability must be aware of
> > this address assignment in order to properly offer their
> > services. And
> > this problem becomes combinatorially more difficult as various
> > combinations of capabilities are considered.
> >
> > I did consider another solution of my own:
> >
> > REGISTER sip:[EMAIL PROTECTED] SIP/2.0
> > From: sip:[EMAIL PROTECTED]
> > To: sip:[EMAIL PROTECTED]
> > Contact: sip:[EMAIL PROTECTED]; language="en"; q=1.0,
> > sip:[EMAIL PROTECTED]; language="es"; q=0.2
> >
> > REGISTER sip:acme.com SIP/2.0
> > From: sip:[EMAIL PROTECTED]
> > To: sip:[EMAIL PROTECTED]
> > Contact: sip:[EMAIL PROTECTED]; language="en"; q=0.2,
> > sip:[EMAIL PROTECTED]; language="es"; q=1.0
> >
> > This requires that each UA have enough aliases to cover the
> > number of
> > distinct contact entries it needs to generate. It must also then
> > remember the aliases it has used and for what, so that it can do the
> > right thing in future registrations. This can be made to
> > work, but it is
> > a huge HACK.
> >
> > Paul
> >
> > James Undery wrote:
> > >
> > > Paul,
> > >
> > > Okay this is exactly what I was thinking. This situation
> > can be fixed
> > > fairly easily without changes to any spec.
> > >
> > > REGISTER sip:acme.com SIP/2.0
> > > To: sip:[EMAIL PROTECTED]
> > > From: sip:[EMAIL PROTECTED]
> > > Contact: sip:[EMAIL PROTECTED];
> > expires=4294967295; language="en",
> > > sip:[EMAIL PROTECTED];
> > expires=4294967295; language="es"
> > >
> > > So the system admin sets up the english and spanish
> > aliases (for the
> > > max possible time), Joe then comes in and registers
> > >
> > > REGISTER sip:acme.com SIP/2.0
> > > To: sip:[EMAIL PROTECTED]
> > > From: sip:[EMAIL PROTECTED]
> > > Contact: sip:[EMAIL PROTECTED]; q=1.0
> > >
> > > REGISTER sip:acme.com SIP/2.0
> > > To: sip:[EMAIL PROTECTED]
> > > From: sip:[EMAIL PROTECTED]
> > > Contact: sip:[EMAIL PROTECTED]; q=0.2
> > >
> > > I guess you can see how Jose will register so I'll leave that out.
> > > Anyway, the desired effect is achived, without breaking
> > existing SIP
> > > URI matching and registration rules.
> > >
> > > James
> > >
> > > > -----Original Message-----
> > > > From: Paul Kyzivat [mailto:[EMAIL PROTECTED]]
> > > > Sent: 15 October 2001 23:30
> > > > To: James Undery
> > > > Cc: [EMAIL PROTECTED]
> > > > Subject: Re: [Sip-implementors] Re: Need clarification on
> > > > callerprefs
> > > >
> > > >
> > > > James,
> > > >
> > > > OK, I guess I need to explain further. I agree that on
> > the surface
> > > > Contact: sip:[EMAIL PROTECTED]; language="en"; q=1.0,
> > > > sip:[EMAIL PROTECTED]; language="es"; q=0.2
> > > >
> > > > may seem a little silly. But it isn't if you consider
> > it in a larger
> > > > context:
> > > >
> > > > REGISTER sip:[EMAIL PROTECTED] SIP/2.0
> > > > From: sip:[EMAIL PROTECTED]
> > > > To: sip:[EMAIL PROTECTED]
> > > > Contact: sip:[EMAIL PROTECTED]; language="en"; q=1.0,
> > > > sip:[EMAIL PROTECTED]; language="es"; q=0.2
> > > >
> > > > REGISTER sip:acme.com SIP/2.0
> > > > From: sip:[EMAIL PROTECTED]
> > > > To: sip:[EMAIL PROTECTED]
> > > > Contact: sip:[EMAIL PROTECTED]; language="en"; q=0.2,
> > > > sip:[EMAIL PROTECTED]; language="es"; q=1.0
> > > >
> > > > Calls to [EMAIL PROTECTED] will be sent to the best
> > available registered
> > > > contact address. If both joe and jose are registered, then
> > > > english calls
> > > > will go to joe and spanish calls will go to jose. But
> > if only one of
> > > > them is registered, then both kinds of calls will go to
> > > > whoever it is.
> > > >
> > > > Paul
> > > >
> > > >
> > > > James Undery wrote:
> > > > >
> > > > > Hi,
> > > > > I am a bit behind on this so forgive my
> > > > ignorance, comments inline
> > > > >
> > > > > > -----Original Message-----
> > > > > > From: [EMAIL PROTECTED]
> > > > > > [mailto:[EMAIL PROTECTED]]On Behalf Of
> > > > > > Paul Kyzivat
> > > > > > Sent: 12 October 2001 16:22
> > > > > > To: [EMAIL PROTECTED]
> > > > > > Subject: [Sip-implementors] Re: Need clarification on
> > > > callerprefs
> > > > > >
> > > > > >
> > > > > > I have another question about callerprefs, in addition to
> > > > > > the earlier
> > > > > > messages I have posted on this subject. This is
> > > > primarily a question
> > > > > > about the handling of REGISTER by a registrar, but the
> > > > question only
> > > > > > makes sense in the context of the changes to the Contact
> > > > > > header proposed
> > > > > > in draft-ietf-sip-callerprefs-04.
> > > > > >
> > > > > > Section 5.1 says: "This specification adds the
> > > > following extension
> > > > > > parameters to the Contact header field ... These parameters
> > > > > > apply to a
> > > > > > single URI. When used in a Contact header, they specify
> > > > > > characteristics
> > > > > > of the URI in the header."
> > > > > >
> > > > > > Now, suppose I want to specify that a given URI is
> > > > fully capable in
> > > > > > English and slightly capable in Spanish. This is a
> > > > > > reasonable thing to
> > > > > > want to specify, and there seems to be a way to do it:
> > > > > >
> > > > > > Contact: sip:[EMAIL PROTECTED]; language="en"; q=1.0,
> > > > > > sip:[EMAIL PROTECTED]; language="es"; q=0.2
> > > > >
> > > > > I don't really follow what you are trying to do here,
> > the above
> > > > > registration will route both Spanish and English requests
> > > > to the the
> > > > > same location. Surely a more common registration would be
> > > > >
> > > > > Contact: sip:[EMAIL PROTECTED]; language="en"; q=1.0,
> > > > > sip:[EMAIL PROTECTED]; language="es"; q=0.2
> > > > >
> > > > > all your concerns are based around the fact you want to
> > > > route to the
> > > > > same URI, if joe can handle both English and Spanish
> > at the same
> > > > > location what's the problem.
> > > > >
> > > > > > My question is: is this a legal construction in a
> > > > Contact header?
> > > > > > Normally, if there had been a prior registration of
> > > > > >
> > > > > > Contact: sip:[EMAIL PROTECTED]; language="en"; q=1.0
> > > > > >
> > > > > > and a new registration was received containing
> > > > > >
> > > > > > Contact: sip:[EMAIL PROTECTED]; language="es"; q=0.2
> > > > > >
> > > > > > then the new contact would *replace* the old one. As far as
> > > > > > I can tell,
> > > > > > the bis is silent on what should happen if two contacts
> > > > > > with the same
> > > > > > URI are present in the same register request. I can see
> > > > > > three possible
> > > > > > interpretations:
> > > > > >
> > > > > > 1) upon receipt of the REGISTER request, the registrar
> > > > > > first removes any
> > > > > > previously registered contact entries that match any of
> > > > the contact
> > > > > > entries in this REGISTER request. Then all the contact
> > > > > > entries in this
> > > > > > register request are saved.
> > > > > >
> > > > > > 2) a REGISTER request with multiple contact entries is
> > > > > > processed much
> > > > > > like multiple REGISTER requests each with a single contact
> > > > > > entry. If two
> > > > > > contact entries mention the same URI, each one in turn
> > > > replaces the
> > > > > > previous one. Only the last remains. No error occurs.
> > > > > >
> > > > > > 3) a REGISTER request with multiple contact entries
> > > > > > containing the same
> > > > > > URI is considered erroneous, and results in an error
> > > > such as 400 Bad
> > > > > > Request.
> > > > > >
> > > > > > Of these, (1) is compatible with the example above
> > > > while the others
> > > > > > aren't. (2) is a silly interpretation - it is never useful.
> > > > > > (3) forbids
> > > > > > a useful application and is extra work to detect.
> > > > >
> > > > > I'd go with 2 here and agree it's a silly interpretation,
> > > > but add it
> > > > > was also a silly request and clarify the situation in the
> > > > 200 Okay.
> > > > >
> > > > > James
>
> _______________________________________________
> Sip-implementors mailing list
> [EMAIL PROTECTED]
> http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
>
_______________________________________________
Sip-implementors mailing list
[EMAIL PROTECTED]
http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
