[OpenSER-Users] "always" serial fork with LCR?

Amit Sharma amit398 at gmail.com
Mon Mar 17 14:59:32 CET 2008


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 at 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 at 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 at voice-system.ro
> > > <mailto:bogdan at 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 at lists.openser.org <mailto:Users at lists.openser.org>
> > >     > http://lists.openser.org/cgi-bin/mailman/listinfo/users
> > >     >
> > >
> > >
> >
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.kamailio.org/pipermail/users/attachments/20080317/53f66e4a/attachment.htm 


More information about the Users mailing list