17 Mar
2008
17 Mar
'08
3:59 p.m.
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> 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> 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:
value.
------------------------------------------------------------------------
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>> 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:
i am
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 > 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
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>
http://lists.openser.org/cgi-bin/mailman/listinfo/users