26 Feb
2008
26 Feb
'08
10:19 a.m.
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
27 Feb
27 Feb
8:06 a.m.
New subject: [OpenSER-Users] "always" serial fork with LCR?
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
10:19 a.m.
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(a)lists.openser.org
http://lists.openser.org/cgi-bin/mailman/listinfo/users
10:59 a.m.
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(a)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(a)lists.openser.org
http://lists.openser.org/cgi-bin/mailman/listinfo/users
7:59 p.m.
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(a)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(a)lists.openser.org <mailto:Users@lists.openser.org>
http://lists.openser.org/cgi-bin/mailman/listinfo/users
28 Feb
28 Feb
6:54 a.m.
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(a)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:
value.
------------------------------------------------------------------------
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(a)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:
am
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 > 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
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(a)lists.openser.org <mailto:Users@lists.openser.org>
http://lists.openser.org/cgi-bin/mailman/listinfo/users
17 Mar
17 Mar
2:59 p.m.
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(a)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(a)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:
value.
------------------------------------------------------------------------
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(a)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:
i am
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 > 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
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(a)lists.openser.org <mailto:Users@lists.openser.org>
http://lists.openser.org/cgi-bin/mailman/listinfo/users
4:38 p.m.
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.
1. 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
6:13 p.m.
New subject: [OpenSER-Users] LCR-Feature
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
6:45 p.m.
New subject: [OpenSER-Users] LCR-Feature
On Mon, Mar 17, 2008 at 1:13 PM, <Martin.Gruber1(a)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(a)lists.openser.org
http://lists.openser.org/cgi-bin/mailman/listinfo/users
25 Mar
25 Mar
12:43 p.m.
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(a)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(a)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(a)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(a)lists.openser.org
<mailto:Users@lists.openser.org>
<mailto:Users@lists.openser.org <mailto:Users@lists.openser.org>>
27 Feb
27 Feb
10:52 p.m.
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.
--
Iñaki Baz Castillo
5875
days inactive
5903
days old
11 comments
6 participants
participants (6)
-
Amit Sharma -
Bogdan-Andrei Iancu -
Iñaki Baz Castillo -
jh＠tutpro.com -
Martin.Gruber1＠infineon.com -
Ovidiu Sas