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

[Bogdan-Andrei Iancu]

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