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* <[EMAIL PROTECTED] > <mailto:[EMAIL PROTECTED]>> 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* <[EMAIL PROTECTED] > <mailto:[EMAIL PROTECTED]>> 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* <[EMAIL PROTECTED] > <mailto:[EMAIL PROTECTED]> > > <mailto:[EMAIL PROTECTED] > <mailto:[EMAIL PROTECTED]>>> 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> > <mailto:Users@lists.openser.org <mailto:Users@lists.openser.org>> > > > http://lists.openser.org/cgi-bin/mailman/listinfo/users > > > > > > > > > > _______________________________________________ Users mailing list Users@lists.openser.org http://lists.openser.org/cgi-bin/mailman/listinfo/users
