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@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@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@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@lists.openser.org <mailto:Users@lists.openser.org>
>     > http://lists.openser.org/cgi-bin/mailman/listinfo/users
>     >
>
>