30 May
2006
30 May
'06
9:47 p.m.
hi
I would like to read some opinions to know which method its better to
implement Call Hunting, using serial forking with 'avpops' or 'lcr'
module 'load_contacts()/next_contact()' functions, does someone has an
example of any of these methods?
rafael
31 May
31 May
2:04 a.m.
Hello,
On 05/30/06 19:47, Rafael J. Risco G.V. wrote:
hi
I would like to read some opinions to know which method its better to
implement Call Hunting, using serial forking with 'avpops' or 'lcr'
module 'load_contacts()/next_contact()' functions, does someone has an
example of any of these methods?
if it is a global scope you can use any of them,
Which is better?
Depends on your environment and how you organize your data.
If is per user, then avpops is more suitable. An example of using avpops
you can find at:
http://www.voice-system.ro/docs/avpops/ar01s08.html#ex_serial_forking
Cheers,
Daniel
rafael
_______________________________________________
Users mailing list
Users(a)openser.org
http://openser.org/cgi-bin/mailman/listinfo/users
1 Jun
1 Jun
2:53 p.m.
New subject: [Serusers] Re: [Users] Call Hunting: use Avpop or LCR module ?
On Wed, May 31, 2006 at 12:04:41AM +0300, Daniel-Constantin Mierla wrote:
Hello,
On 05/30/06 19:47, Rafael J. Risco G.V. wrote:
It is suitable, but for some scenarios it require much more complicated
config, which is not easy to understand.
Scenario:
User A (PSTN side) calls user B (SIP). With avpops we select some numbers
for this user, trying original number (returns 486/BUSY), hunting to next
number (creating new transaction on router). Phone B2 starts with
100/Trying 180/Ringing, then user A hangs.
CANCEL message first visits original number, which returns
481/Call leg/transaction does not exists [1], then hunts to second
number and successfully cancel's call. But, at point [1], first transaction
_does not store_ new reply code (modules/tm/t_reply.c, line 762 just logs
message
LOG(L_ERR, "ERROR: t_should_relay_response: status rewrite by UAS: "
"stored: %d, received: %d\n",
Trans->uac[branch].last_received, new_code );
goto discard;
), and again hunts, so, third number of user B starts ringing...
The only solution for this which I found yet is:
#The only way to really check return code is to check it in onreply_route,
#then set flag which will permit failure_route to hunt this call again.
#You can't check status with t_check_status within failure_route,
#because t_check_status in failure_route returns the lowest value
#of all branches..
onreply_route[1] {
if(status=~"40[48]" || status=~"486") {
#not-so-fatal response, should hunt
setflag(2);
};
}
failure_route[1] {
if(isflagset(2)) {
resetflag(2);
if(avp_pushto("$ruri","$serial_fork")) {
#and then everytingh should work as in example.
But, this config is not yet complete - with this configuration
CANCEL's does not hunt after 481 Call leg does not exists, so,
in situation when we need to cancel call on second or third number,
we're not able to do that :(
Just adding another code (481) to our list of not-so-fatal response
does nothing but returns us to initial problem, and the only
solution found is to complicate configuration again to:
#main post-routing code
route[1] {
if(method=="CANCEL") {
t_on_reply("2");
} else {
t_on_reply("1");
};
t_on_failure("1");
t_relay();
};
onreply_route[1] { #onreply for everyting but CANCEL
if(status=~"40[48]" || status=~"486") {
#not-so-fatal response, should hunt
setflag(2);
};
}
onreply_route[2] { #onreply for CANCEL's
if(status=~"481") {
#not-so-fatal response, should hunt
setflag(2);
};
}
failure_route[1] {
if(isflagset(2)) {
resetflag(2);
if(avp_pushto("$ruri","$serial_fork")) {
Please note, that config is in pre-production stage, tested, but
without really massive tests. Also, note that this is not complete
config, just parts to allow serial hunting without noted problem.
If anyone knows more elegant solution for my problem - please, let
me know. Also, if anyone can see a problem with my config - let me
know how to test it...
PS: another problem may arise with maximal number of branches.
With default configuration of ser (config.h, #define MAX_BRANCHES 12)
maximum number of hunts is limited to 11. If you need more hunts than
this - you need to recompile ser.
hi
I would like to read some opinions to know which method its better to
implement Call Hunting, using serial forking with 'avpops' or 'lcr'
module 'load_contacts()/next_contact()' functions, does someone has an
example of any of these methods?
if it is a global scope you can use any of them,
Which is better?
Depends on your environment and how you organize your data.
If is per user, then avpops is more suitable. An example of using avpops
you can find at:
http://www.voice-system.ro/docs/avpops/ar01s08.html#ex_serial_forking
3:20 p.m.
On 06/01/06 12:53, Alexandre Snarskii wrote:
On Wed, May 31, 2006 at 12:04:41AM +0300,
Daniel-Constantin Mierla wrote:
it does not create a new transaction,
just adds a new branch to it.
Hello,
On 05/30/06 19:47, Rafael J. Risco G.V. wrote:
It is suitable, but for some scenarios it require much more complicated
config, which is not easy to understand.
Scenario:
User A (PSTN side) calls user B (SIP). With avpops we select some numbers
for this user, trying original number (returns 486/BUSY), hunting to next
number (creating new transaction on router). hi
I would like to read some opinions to know which method its better to
implement Call Hunting, using serial forking with 'avpops' or 'lcr'
module 'load_contacts()/next_contact()' functions, does someone has an
example of any of these methods?
if it is a global scope you can use any of them, Which is better?
Depends on your environment and how you organize your data.
If is per user, then avpops is more suitable. An example of using avpops
you can find at:
http://www.voice-system.ro/docs/avpops/ar01s08.html#ex_serial_forking
Phone B2 starts with
100/Trying 180/Ringing, then user A hangs.
CANCEL message first visits original number, which returns
481/Call leg/transaction does not exists [1],
you mean that sends CANCEL to B1? I
do not think so, CANCEL is not sent
to completed branches, just to ones that haven't received a final response.
then hunts to second
number and successfully cancel's call. But, at point [1], first transaction
_does not store_ new reply code (modules/tm/t_reply.c, line 762 just logs
message
LOG(L_ERR, "ERROR: t_should_relay_response: status rewrite by UAS: "
"stored: %d, received: %d\n",
Trans->uac[branch].last_received, new_code );
goto discard;
), and again hunts, so, third number of user B starts ringing...
What version of openser do you use?
The only solution for this which I found yet is:
#The only way to really check return code is to check it in onreply_route,
#then set flag which will permit failure_route to hunt this call again.
#You can't check status with t_check_status within failure_route,
#because t_check_status in failure_route returns the lowest value
#of all branches..
onreply_route[1] {
if(status=~"40[48]" || status=~"486") {
#not-so-fatal response, should hunt
setflag(2);
};
}
failure_route[1] {
if(isflagset(2)) {
resetflag(2);
if(avp_pushto("$ruri","$serial_fork")) {
#and then everytingh should work as in example.
You can use t_was_cancelled() in failure route:
http://openser.org/docs/modules/1.1.x/tm.html#AEN479 . It will ensure
that you get the proper status of canceled transactions.
But, this config is not yet complete - with this
configuration
CANCEL's does not hunt after 481 Call leg does not exists, so,
in situation when we need to cancel call on second or third number,
we're not able to do that :(
Just adding another code (481) to our list of not-so-fatal response
does nothing but returns us to initial problem, and the only
solution found is to complicate configuration again to:
#main post-routing code
route[1] {
if(method=="CANCEL") {
t_on_reply("2");
} else {
t_on_reply("1");
};
t_on_failure("1");
t_relay();
};
onreply_route[1] { #onreply for everyting but CANCEL
if(status=~"40[48]" || status=~"486") {
#not-so-fatal response, should hunt
setflag(2);
};
}
onreply_route[2] { #onreply for CANCEL's
if(status=~"481") {
#not-so-fatal response, should hunt
setflag(2);
};
}
failure_route[1] {
if(isflagset(2)) {
resetflag(2);
if(avp_pushto("$ruri","$serial_fork")) {
Please note, that config is in pre-production stage, tested, but
without really massive tests. Also, note that this is not complete
config, just parts to allow serial hunting without noted problem.
If anyone knows more elegant solution for my problem - please, let
me know. Also, if anyone can see a problem with my config - let me
know how to test it...
Could you try the latest version of OpenSER CVS, it is now in
frozen/testing phase, just to be release in a few weeks. Any feedback
will help to fix eventual issues. The part with reply code selections
and CANCEL processing was refurbished and should have fixed some old issues.
Cheers,
Daniel
PS: another problem may arise with maximal number of
branches.
With default configuration of ser (config.h, #define MAX_BRANCHES 12)
maximum number of hunts is limited to 11. If you need more hunts than
this - you need to recompile ser.
4:32 p.m.
On Thu, Jun 01, 2006 at 01:20:28PM +0300, Daniel-Constantin Mierla wrote:
On 06/01/06 12:53, Alexandre Snarskii wrote:
ser 0.9.6, freebsd 6.1, database backend is postgresql.
Did not tried that setup with openser yet.
Initial question was in ser-users mailing list..
On Wed, May 31, 2006 at 12:04:41AM +0300,
Daniel-Constantin Mierla wrote:
it does not create a new transaction,
just adds a new branch to it.
Hello,
On 05/30/06 19:47, Rafael J. Risco G.V. wrote:
It is suitable, but for some scenarios it require much more complicated
config, which is not easy to understand.
Scenario:
User A (PSTN side) calls user B (SIP). With avpops we select some numbers
for this user, trying original number (returns 486/BUSY), hunting to next
number (creating new transaction on router). hi
I would like to read some opinions to know which method its better to
implement Call Hunting, using serial forking with 'avpops' or 'lcr'
module 'load_contacts()/next_contact()' functions, does someone has an
example of any of these methods?
if it is a global scope you can use any of them, Which is better?
Depends on your environment and how you organize your data.
If is per user, then avpops is more suitable. An example of using avpops
you can find at:
http://www.voice-system.ro/docs/avpops/ar01s08.html#ex_serial_forking
Phone B2 starts with
100/Trying 180/Ringing, then user A hangs.
CANCEL message first visits original number, which returns
481/Call leg/transaction does not exists [1],
you mean that sends CANCEL to B1? I
do not think so, CANCEL is not sent
to completed branches, just to ones that haven't received a final response.
then hunts to second
number and successfully cancel's call. But, at point [1], first transaction
_does not store_ new reply code (modules/tm/t_reply.c, line 762 just logs
message
LOG(L_ERR, "ERROR: t_should_relay_response: status rewrite by UAS:
"
"stored: %d, received: %d\n",
Trans->uac[branch].last_received, new_code );
goto discard;
), and again hunts, so, third number of user B starts ringing...
What version of openser do you use? The only
solution for this which I found yet is:
#The only way to really check return code is to check it in onreply_route,
#then set flag which will permit failure_route to hunt this call again.
#You can't check status with t_check_status within failure_route,
#because t_check_status in failure_route returns the lowest value
#of all branches..
onreply_route[1] {
if(status=~"40[48]" || status=~"486") {
#not-so-fatal response, should hunt
setflag(2);
};
}
failure_route[1] {
if(isflagset(2)) {
resetflag(2);
if(avp_pushto("$ruri","$serial_fork")) {
#and then everytingh should work as in example.
You can use t_was_cancelled() in failure route:
http://openser.org/docs/modules/1.1.x/tm.html#AEN479 . It will ensure
that you get the proper status of canceled transactions.
But, this config is not yet complete - with this
configuration
CANCEL's does not hunt after 481 Call leg does not exists, so,
in situation when we need to cancel call on second or third number,
we're not able to do that :(
Just adding another code (481) to our list of not-so-fatal response
does nothing but returns us to initial problem, and the only
solution found is to complicate configuration again to:
#main post-routing code
route[1] {
if(method=="CANCEL") {
t_on_reply("2");
} else {
t_on_reply("1");
};
t_on_failure("1");
t_relay();
};
onreply_route[1] { #onreply for everyting but CANCEL
if(status=~"40[48]" || status=~"486") {
#not-so-fatal response, should hunt
setflag(2);
};
}
onreply_route[2] { #onreply for CANCEL's
if(status=~"481") {
#not-so-fatal response, should hunt
setflag(2);
};
}
failure_route[1] {
if(isflagset(2)) {
resetflag(2);
if(avp_pushto("$ruri","$serial_fork")) {
Please note, that config is in pre-production stage, tested, but
without really massive tests. Also, note that this is not complete
config, just parts to allow serial hunting without noted problem.
If anyone knows more elegant solution for my problem - please, let
me know. Also, if anyone can see a problem with my config - let me
know how to test it...
Could you try the latest version of OpenSER CVS, it is now in
frozen/testing phase, just to be release in a few weeks. Any feedback
will help to fix eventual issues. The part with reply code selections
and CANCEL processing was refurbished and should have fixed some old issues.
Cheers,
Daniel
>PS: another problem may arise with maximal number of branches.
>With default configuration of ser (config.h, #define MAX_BRANCHES 12)
>maximum number of hunts is limited to 11. If you need more hunts than
>this - you need to recompile ser.
>
>
>
4:38 p.m.
On 06/01/06 14:32, Alexandre Snarskii wrote:
On Thu, Jun 01, 2006 at 01:20:28PM +0300,
Daniel-Constantin Mierla wrote:
it seems that was doubled posted, I answered to users(a)openser.org and
overlooked that is for serusers, too.
Cheers,
Daniel
On 06/01/06 12:53, Alexandre Snarskii wrote:
ser 0.9.6, freebsd 6.1, database backend is postgresql.
Did not tried that setup with openser yet.
Initial question was in ser-users mailing list..
On Wed, May 31, 2006 at 12:04:41AM +0300,
Daniel-Constantin Mierla wrote:
it does not create a new transaction, just adds a new branch to it.
Hello,
On 05/30/06 19:47, Rafael J. Risco G.V. wrote:
> hi
> I would like to read some opinions to know which method its better to
> implement Call Hunting, using serial forking with 'avpops' or 'lcr'
> module 'load_contacts()/next_contact()' functions, does someone has an
> example of any of these methods?
>
>
if it is a global scope you can use any of them, Which is better?
Depends on your environment and how you organize your data.
If is per user, then avpops is more suitable. An example of using avpops
you can find at:
http://www.voice-system.ro/docs/avpops/ar01s08.html#ex_serial_forking
It is suitable, but for some scenarios it require much more complicated
config, which is not easy to understand.
Scenario:
User A (PSTN side) calls user B (SIP). With avpops we select some numbers
for this user, trying original number (returns 486/BUSY), hunting to next
number (creating new transaction on router).
Phone B2 starts with
100/Trying 180/Ringing, then user A hangs.
CANCEL message first visits original number, which returns
481/Call leg/transaction does not exists [1],
you mean that sends CANCEL to B1? I do not think so, CANCEL is not sent
to completed branches, just to ones that haven't received a final response.
then hunts to second
number and successfully cancel's call. But, at point [1], first transaction
_does not store_ new reply code (modules/tm/t_reply.c, line 762 just logs
message
LOG(L_ERR, "ERROR: t_should_relay_response: status rewrite by UAS:
"
"stored: %d, received: %d\n",
Trans->uac[branch].last_received, new_code );
goto discard;
), and again hunts, so, third number of user B starts ringing...
What version of openser do you use?
The only
solution for this which I found yet is:
#The only way to really check return code is to check it in onreply_route,
#then set flag which will permit failure_route to hunt this call again.
#You can't check status with t_check_status within failure_route,
#because t_check_status in failure_route returns the lowest value
#of all branches..
onreply_route[1] {
if(status=~"40[48]" || status=~"486") {
#not-so-fatal response, should hunt
setflag(2);
};
}
failure_route[1] {
if(isflagset(2)) {
resetflag(2);
if(avp_pushto("$ruri","$serial_fork")) {
#and then everytingh should work as in example.
You can use t_was_cancelled() in failure route:
http://openser.org/docs/modules/1.1.x/tm.html#AEN479 . It will ensure
that you get the proper status of canceled transactions.
But, this config is not yet complete - with this
configuration
CANCEL's does not hunt after 481 Call leg does not exists, so,
in situation when we need to cancel call on second or third number,
we're not able to do that :(
Just adding another code (481) to our list of not-so-fatal response
does nothing but returns us to initial problem, and the only
solution found is to complicate configuration again to:
#main post-routing code
route[1] {
if(method=="CANCEL") {
t_on_reply("2");
} else {
t_on_reply("1");
};
t_on_failure("1");
t_relay();
};
onreply_route[1] { #onreply for everyting but CANCEL
if(status=~"40[48]" || status=~"486") {
#not-so-fatal response, should hunt
setflag(2);
};
}
onreply_route[2] { #onreply for CANCEL's
if(status=~"481") {
#not-so-fatal response, should hunt
setflag(2);
};
}
failure_route[1] {
if(isflagset(2)) {
resetflag(2);
if(avp_pushto("$ruri","$serial_fork")) {
Please note, that config is in pre-production stage, tested, but
without really massive tests. Also, note that this is not complete
config, just parts to allow serial hunting without noted problem.
If anyone knows more elegant solution for my problem - please, let
me know. Also, if anyone can see a problem with my config - let me
know how to test it...
Could you try the latest version of OpenSER CVS, it is now in
frozen/testing phase, just to be release in a few weeks. Any feedback
will help to fix eventual issues. The part with reply code selections
and CANCEL processing was refurbished and should have fixed some old issues.
Cheers,
Daniel
> PS: another problem may arise with maximal number of branches.
> With default configuration of ser (config.h, #define MAX_BRANCHES 12)
> maximum number of hunts is limited to 11. If you need more hunts than
> this - you need to recompile ser.
>
>
>
> 
2 Jun
2 Jun
6:20 p.m.
New subject: [Users] how to use TCP only with 1.1 devel
Hello,
I am trying to understand how to setup openser to use only TCP for both
incoming and outgoing signaling.
Currently I have set
listen=tcp:xxx.xxx.xxx.xxx:5060
This forces openser to only listen on TCP socket and handles incoming
signaling.
Now using the statefull module I call t_relay() and the signaling goes
out UDP.
I can force the signaling out using tcp by doing the following,
t_relay("tcp:xxx.xxx.xxx.xxx:xxxx")
The problem with this is I don't know what the ip:port is going to be in
all cases.
I would like to do something more akin to
t_relay("tcp") so the relay address is simply the address in the RURI
I realize there was a function t_relay_to_tcp in the previous version
but has been deprecated and would require the ip:port anyway.
Is there a way to pass a variable into t_relay to represent the ip:port
combo?
Something like t_relay("tcp:" + uri:host + uri:port )
I understand the syntax above won't work but this is an example of what
I am looking for.
Is there any simple way to force TCP for outgoing signaling?
What about adding parameter=tcp to the record route?
Thanks
T.R.
7:07 p.m.
New subject: [Users] how to use TCP only with 1.1 devel
Hi,
you may force only the protocol by adding the transport parameter to the
ruri:
add_uri_param("transport=tcp");
see http://openser.org/docs/modules/1.1.x/uri.html#AEN118 ;
but this will change the RURI and the param will be also sent out...
if you do no want to be visible as part of RURI, use the dst_uri to
specify a tcp outbound proxy:
avp_printf("$avp(i:13)","$ru;transport=tcp");
push_to("$du","$avp(i:13)");
regards,
bogdan
T.R. Missner wrote:
Hello,
I am trying to understand how to setup openser to use only TCP for both
incoming and outgoing signaling.
Currently I have set
listen=tcp:xxx.xxx.xxx.xxx:5060
This forces openser to only listen on TCP socket and handles incoming
signaling.
Now using the statefull module I call t_relay() and the signaling goes
out UDP.
I can force the signaling out using tcp by doing the following,
t_relay("tcp:xxx.xxx.xxx.xxx:xxxx")
The problem with this is I don't know what the ip:port is going to be in
all cases.
I would like to do something more akin to
t_relay("tcp") so the relay address is simply the address in the RURI
I realize there was a function t_relay_to_tcp in the previous version
but has been deprecated and would require the ip:port anyway.
Is there a way to pass a variable into t_relay to represent the ip:port
combo?
Something like t_relay("tcp:" + uri:host + uri:port )
I understand the syntax above won't work but this is an example of what
I am looking for.
Is there any simple way to force TCP for outgoing signaling?
What about adding parameter=tcp to the record route?
Thanks
T.R.
_______________________________________________
Users mailing list
Users(a)openser.org
http://openser.org/cgi-bin/mailman/listinfo/users
1 Jun
1 Jun
9:09 p.m.
New subject: [Serusers] Re: [Users] Call Hunting: use Avpop or LCR module ?
On Thu, Jun 01, 2006 at 01:53:17PM +0400, Alexandre Snarskii wrote:
PS: another problem may arise with maximal number of branches.
With default configuration of ser (config.h, #define MAX_BRANCHES 12)
maximum number of hunts is limited to 11. If you need more hunts than
this - you need to recompile ser.
PPS: just tried this advice by myself. Ser recomplies ok (with
#define MAX_BRANCHES 128), but unable to start with next message:
Jun 1 19:16:26 <.> /usr/local/sbin/ser[68250]: Too many max UACs for UAC branch
_bm_t bitmap: 128
Jun 1 19:16:26 <.> /usr/local/sbin/ser[68250]: init_mod(): Error while initiali
zing module tm
I assume that this behavior is just a sanity check, because branches
will be stored in 32-bit bitmap (from modules/tm/t_reply.h:
/* branch bitmap type */
typedef unsigned int branch_bm_t;
)
so, the maximum value you can safely redefine MAX_BRANCHES to is 30.
Question: is it safe enough to redefine branch_bm_t as "unsigned long long
int" and rewrite check code with use sizeof(branch_tm_t) instead of constant 31
(with objective to get 62 branches per transaction, or maximum hunt-group
of 62) or there are hidden troubles ?
6539
days inactive
6542
days old
8 comments
5 participants
participants (5)
-
Alexandre Snarskii -
Bogdan-Andrei Iancu -
Daniel-Constantin Mierla -
Rafael J. Risco G.V. -
T.R. Missner