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
Amit Sharma writes:
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.
yes, it is not possible. if q values of contacts are the same, then they will be contacted parallel.
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?
the whole idea of q value is to control in which order contacts are contacted. i don't want to add something else on top of if. ask your users to use different q values if they don't want to be contacted simultaneously.
-- juha
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 http://lists.openser.org/cgi-bin/mailman/listinfo/users
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 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 http://lists.openser.org/cgi-bin/mailman/listinfo/users
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 >
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:
- LCR module
- 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 iam
> sending my query. > > I have been looking at the LCR module to do serial forking sincewe
> 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 qvalue.
> 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 >
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 achievablewith the functionality already available in core. Is that correct?
Thanks again for a prompt reply. I will focus on the functionality incore 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:
- LCR module
- 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 forkingfrom
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 soi am
> sending my query. > > I have been looking at the LCR module to do serial forkingsince 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 qvalue.
> 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 >
Amit Sharma writes:
In my opinion, serialize_branches should not look at the q-values (that functionality is available through LCR)
the idea is that we could drop lcr functions load_contacts/next_contacts if the core functions one day do the same thing.
- The UA's do not send any q-value in registration but serial forking is
required.
you can set default q value to be used in cases where register request does not include any.
if you need to force serial forking of equal q value contacts, please write a function that is called before calling load_contacts() and that rewrites q values of contacts whatever way you like.
-- juha
Hi @all,
I have following questions, concerning OpenSER and LCR.
Firstly, is it possible to show active trunks (to any Asterisk GWs) or to check them?
Secondly, I need CDR-Records for the calls. I use OpenSER for LCR between Gateways and I need following information for CDR: Action (answered, busy, etc) - caller_id - duration - src-channel (coming from which gw) - dest_channel (going to which gw?)
Thanks for you help!
Kind regards
Martin
On Mon, Mar 17, 2008 at 1:13 PM, Martin.Gruber1@infineon.com wrote:
Hi @all,
I have following questions, concerning OpenSER and LCR.
Firstly, is it possible to show active trunks (to any Asterisk GWs) or to check them?
use 'openserctl lcr show' to display the gateways and the routes
Secondly, I need CDR-Records for the calls. I use OpenSER for LCR between Gateways and I need following information for CDR: Action (answered, busy, etc) - caller_id - duration - src-channel (coming from which gw) - dest_channel (going to which gw?)
use the acc module to generate EDRs. Combining the EDRs, you can generate CDRs. You may take a look at CDRTool: http://www.ag-projects.com/CDRTool.html
Thanks for you help!
Kind regards
Martin
Users mailing list Users@lists.openser.org http://lists.openser.org/cgi-bin/mailman/listinfo/users
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 > > > >
El Martes, 26 de Febrero de 2008, Amit Sharma escribió:
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?
Hi, I think you are asking for a non RFC behaviour, and something very strange and maybe just useful in your own case. I think it doesn't make sense to implement it.
Regards.
-
Amit Sharma -
Bogdan-Andrei Iancu -
Iñaki Baz Castillo -
jh＠tutpro.com -
Martin.Gruber1＠infineon.com -
Ovidiu Sas