25 Mar
2008
25 Mar
'08
12:43 p.m.
Hi Amit,
The q ordering must be there - it is enforced by RFC, so we should not
drop it at all. As already Juha suggested, you can build a separate
function (or pass to serialize_branches() a param) for ignoring the q
values.
Regards,
Bogdan
Amit Sharma wrote:
Hi Bogdan,
I looked at the serialize_branches and next_branches functions in
core and they seem to be doing a similiar thing to the functions
load_contacts and next_contacts in LCR.
In my opinion, serialize_branches should not look at the q-values
(that functionality is available through LCR)
This would allow and ease the use of serial forking in additional
cases where either
1. The UA's do not send any q-value in registration but serial forking
is required.
2. My case where q-value ordering is required but q-values may not be
distinct. (should be possible since userloc orders on q-value by
default, correct?? )
Users who need the behavior (combination of parallel and serial
forking) as described in the common ordering in rfc3261 can use the
LCR module and others who require serial / parallel forking always can
use the core functions.
Thanks,
Amit
On 2/28/08, *Amit Sharma* <amit398(a)gmail.com
<mailto:amit398@gmail.com>> wrote:
Hi Bogdan,
Your understanding of the requirement is absolutely correct.
So what I understand from your reply is that this should be
achievable with the functionality already available in core. Is
that correct?
Thanks again for a prompt reply. I will focus on the
functionality in core to implement the desired behavior.
Regards,
Amit
On 2/28/08, *Bogdan-Andrei Iancu* <bogdan(a)voice-system.ro
<mailto:bogdan@voice-system.ro>> wrote:
Hi Amit,
Actually both parallel2serial forking support available in
openser:
1) LCR module
2) core (see serialize_branches() + next_branches())
have the q-based ordering (parallel versus serial) built in.
Som if I understand correctly, you to do ordering based on q
value, but
you want only serial forking - no parallel forking for the
branches with
the same q, right?
Regards,
Bogdan
Amit Sharma wrote:
Hi Bogdan,
Thanks for the quick reply.
The behavior rfc3261 mentions for using q values is a common
ordering mechanism (Section 16.6) . I guess variants as such
would not
be against rfc3261.
I was suggesting that we could have additional flexibility
added to
what the LCR module is currently doing. Otherwise
i would almost
rework what is already there in the LCR module (to get list
ordered by
qvalues into AVPs)
A use case for the above request is where contacts for an
AOR are
distributed in a system. The UA's come up
with qvalue based
on there
utilization etc. The idea is to send the call to
the contact
who has
been least used. I cannot enforce that the
qvalues generated
by the
UA's are unique unless I use a sequencing
mechanism between
the UA's.
Thanks,
Amit
On 2/27/08, *Bogdan-Andrei Iancu* <bogdan(a)voice-system.ro
<mailto:bogdan@voice-system.ro>
<mailto:bogdan@voice-system.ro
<mailto:bogdan@voice-system.ro>>> wrote:
Hi Amit,
First of all, the behaviour you want to achieve is
against RFC3261
(forking based on q value), but for sure you
know better
what you
try to
get ;)
Now, depending where you take the list of destinations
from,
let's
assume you can get them into AVPs. For how to
do serial
forking from
AVPs, see:
http://www.voice-sistem.ro/docs/avpops/ar01s08.html#ex_serial_forking
Regards,
Bogdan
Amit Sharma wrote:
> Hi All,
>
> I am a newbie to this list so please forgive me if the
question
below
> has been discussed before. I could not find anything
related so i
am
> sending my query.
>
> I have been looking at the LCR module to do serial
forking since
we
> want to prioritize contacts based on q
values. However,
we do
not want
> to fork in parallel to contacts even if they share the
same q
value.
> AFAIK,this is currently not possible
with the LCR module.
>
> Would it be a good idea to have a parameter (e.g
"append-branches")
> in the LCR module which can control the
forking
behavior when q
value
------------------------------------------------------------------------
of contacts is the same?
Thanks,
Amit
>
> _______________________________________________
> Users mailing list
> Users(a)lists.openser.org
<mailto:Users@lists.openser.org>
<mailto:Users@lists.openser.org <mailto:Users@lists.openser.org>>