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

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
>