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