14 May
2018
14 May
'18
3:56 p.m.
Being spoiled by Freeswitch profiles and dialplans, the stock 1 piece Kamailio cfg file is
cool @ first to get certain call flows knocked out but quite a maze when you get in
deeper.
Right now, using the 1 piece stock cfg file, I am faced with the fact that my carrier
outbound calls started failing after I enabled VM. Basically WITH_VOICEMAIL in route
LOCATION started sending the carrier calls to TOVOICEMAIL and it basically dies there. I
can see the route(TOVOICEMAIL) line and can condition it out with an if but I really
don't now how to differentiate between a ext to ext call or a outbound call in the cfg
file. However given SQL I could.
Is there a way for me to place custom pseudo variables in the call right @ the start and
use them in the script as needed. For example I could mark the call as ext to ext or
carrier bound right @ the start and dodge VM in the LOCATION route.
KD
14 May
14 May
4 p.m.
I think your best bet is to set those variables as AVPs, so that their
values can persist throughout the lifetime of the INVITE transaction.
That way you can also access them in onreply_route and failure_route,
which would not be the case with user variables ($var(...)).
request_route {
# Initialise AVPs to $null or presumed default value.
$avp(call_type) = $null;
...
# When determination is made as to the call type:
if($dbr(res=>[0,0]) eq 'vm')
$avp(call_type) = 'voicemail';
}
-- Alex
On Mon, May 14, 2018 at 01:56:53PM +0000, KamDev Essa wrote:
Being spoiled by Freeswitch profiles and dialplans,
the stock 1 piece Kamailio cfg file is cool @ first to get certain call flows knocked out
but quite a maze when you get in deeper.
Right now, using the 1 piece stock cfg file, I am faced with the fact that my carrier
outbound calls started failing after I enabled VM. Basically WITH_VOICEMAIL in route
LOCATION started sending the carrier calls to TOVOICEMAIL and it basically dies there. I
can see the route(TOVOICEMAIL) line and can condition it out with an if but I really
don't now how to differentiate between a ext to ext call or a outbound call in the cfg
file. However given SQL I could.
Is there a way for me to place custom pseudo variables in the call right @ the start and
use them in the script as needed. For example I could mark the call as ext to ext or
carrier bound right @ the start and dodge VM in the LOCATION route.
KD
_______________________________________________
Kamailio (SER) - Users Mailing List
sr-users(a)lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
--
Alex Balashov | Principal | Evariste Systems LLC
Tel: +1-706-510-6800 / +1-800-250-5920 (toll-free)
Web: http://www.evaristesys.com/, http://www.csrpswitch.com/
5:52 p.m.
Awesome. Will I take a huge performance hit if I I dip to DB on every call. e.g
request_route {
# Initialize AVPs needed for the call. # call usp that returns calltype and other
items
sql_xquery("ca","call usp_classcall '$fU' ,
'$fd';", "ra");
$avp(call_type) = $xavp(ra=>callType); $avp(goodies1) = $xavp(ra=>
goodies1); $avp( goodies2) = $xavp(ra=> goodies2);
$avp( goodies3) = $xavp(ra=> goodies3);
sql_result_free("ra");
}
Will DB hits on every call hinder performance.
On Monday, May 14, 2018, 10:03:04 AM EDT, Alex Balashov
<abalashov(a)evaristesys.com> wrote:
I think your best bet is to set those variables as AVPs, so that their
values can persist throughout the lifetime of the INVITE transaction.
That way you can also access them in onreply_route and failure_route,
which would not be the case with user variables ($var(...)).
request_route {
# Initialise AVPs to $null or presumed default value.
$avp(call_type) = $null;
...
# When determination is made as to the call type:
if($dbr(res=>[0,0]) eq 'vm')
$avp(call_type) = 'voicemail';
}
-- Alex
On Mon, May 14, 2018 at 01:56:53PM +0000, KamDev Essa wrote:
Being spoiled by Freeswitch profiles and dialplans,
the stock 1 piece Kamailio cfg file is cool @ first to get certain call flows knocked out
but quite a maze when you get in deeper.
Right now, using the 1 piece stock cfg file, I am faced with the fact that my carrier
outbound calls started failing after I enabled VM. Basically WITH_VOICEMAIL in route
LOCATION started sending the carrier calls to TOVOICEMAIL and it basically dies there. I
can see the route(TOVOICEMAIL) line and can condition it out with an if but I really
don't now how to differentiate between a ext to ext call or a outbound call in the cfg
file. However given SQL I could.
Is there a way for me to place custom pseudo variables in the call right @ the start and
use them in the script as needed. For example I could mark the call as ext to ext or
carrier bound right @ the start and dodge VM in the LOCATION route.
KD
_______________________________________________
Kamailio (SER) - Users Mailing List
sr-users(a)lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
--
Alex Balashov | Principal | Evariste Systems LLC
Tel: +1-706-510-6800 / +1-800-250-5920 (toll-free)
Web: http://www.evaristesys.com/, http://www.csrpswitch.com/
_______________________________________________
Kamailio (SER) - Users Mailing List
sr-users(a)lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
6:03 p.m.
Not necessarily. All depends on how performant the query is.
Most real-world call processing involves at least one database touch point on every call.
Our product does about five or six complex stored procedure calls and we can still do
about 1000 CPS on most commodity hardware.
On May 14, 2018 5:52:59 PM GMT+02:00, KamDev Essa <kamdevessa(a)yahoo.com> wrote:
Awesome. Will I take a huge performance hit if I I dip
to DB on every
call. e.g
request_route {
# Initialize AVPs needed for the call. # call usp that returns
calltype and other items
sql_xquery("ca","call usp_classcall '$fU' ,
'$fd';", "ra");
$avp(call_type) = $xavp(ra=>callType); $avp(goodies1) =
$xavp(ra=> goodies1); $avp( goodies2) = $xavp(ra=> goodies2);
$avp( goodies3) = $xavp(ra=> goodies3);
sql_result_free("ra");
}
Will DB hits on every call hinder performance.
On Monday, May 14, 2018, 10:03:04 AM EDT, Alex Balashov
<abalashov(a)evaristesys.com> wrote:
I think your best bet is to set those variables as AVPs, so that their
values can persist throughout the lifetime of the INVITE transaction.
That way you can also access them in onreply_route and failure_route,
which would not be the case with user variables ($var(...)).
request_route {
# Initialise AVPs to $null or presumed default value.
$avp(call_type) = $null;
...
# When determination is made as to the call type:
if($dbr(res=>[0,0]) eq 'vm')
$avp(call_type) = 'voicemail';
}
-- Alex
On Mon, May 14, 2018 at 01:56:53PM +0000, KamDev Essa wrote:
-- Alex
--
Sent via mobile, please forgive typos and brevity.
Being spoiled by Freeswitch profiles and
dialplans, the stock 1 piece
Kamailio cfg file is cool @ first to get certain call
flows knocked out
but quite a maze when you get in deeper.
Right now, using the 1 piece stock cfg file, I am
faced with the fact
that my carrier outbound calls started failing after I enabled
VM.
Basically WITH_VOICEMAIL in route LOCATION started sending the carrier
calls to TOVOICEMAIL and it basically dies there. I can see the
route(TOVOICEMAIL) line and can condition it out with an if but I
really don't now how to differentiate between a ext to ext call or a
outbound call in the cfg file. However given SQL I could.
Is there a way for me to place custom pseudo
variables in the call
right @ the start and use them in the script as needed. For
example I
could mark the call as ext to ext or carrier bound right @ the start
and dodge VM in the LOCATION route.
KD
> _______________________________________________
> Kamailio (SER) - Users Mailing List
> sr-users(a)lists.kamailio.org
> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
6:15 p.m.
Theoretically in the lifespan of an INVITE can request_route be called again? Do I need
to set a flag that says I have already dipped DB?
KD
On Monday, May 14, 2018, 12:04:28 PM EDT, Alex Balashov
<abalashov(a)evaristesys.com> wrote:
Not necessarily. All depends on how performant the query is.
Most real-world call processing involves at least one database touch point on every call.
Our product does about five or six complex stored procedure calls and we can still do
about 1000 CPS on most commodity hardware.
On May 14, 2018 5:52:59 PM GMT+02:00, KamDev Essa <kamdevessa(a)yahoo.com> wrote:
Awesome. Will I take a huge performance hit if I I dip
to DB on every
call. e.g
request_route {
# Initialize AVPs needed for the call. # call usp that returns
calltype and other items
sql_xquery("ca","call usp_classcall '$fU' ,
'$fd';", "ra");
$avp(call_type) = $xavp(ra=>callType); $avp(goodies1) =
$xavp(ra=> goodies1); $avp( goodies2) = $xavp(ra=> goodies2);
$avp( goodies3) = $xavp(ra=> goodies3);
sql_result_free("ra");
}
Will DB hits on every call hinder performance.
On Monday, May 14, 2018, 10:03:04 AM EDT, Alex Balashov
<abalashov(a)evaristesys.com> wrote:
I think your best bet is to set those variables as AVPs, so that their
values can persist throughout the lifetime of the INVITE transaction.
That way you can also access them in onreply_route and failure_route,
which would not be the case with user variables ($var(...)).
request_route {
# Initialise AVPs to $null or presumed default value.
$avp(call_type) = $null;
...
# When determination is made as to the call type:
if($dbr(res=>[0,0]) eq 'vm')
$avp(call_type) = 'voicemail';
}
-- Alex
On Mon, May 14, 2018 at 01:56:53PM +0000, KamDev Essa wrote:
-- Alex
--
Sent via mobile, please forgive typos and brevity.
_______________________________________________
Kamailio (SER) - Users Mailing List
sr-users(a)lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
Being spoiled by Freeswitch profiles and
dialplans, the stock 1 piece
Kamailio cfg file is cool @ first to get certain call
flows knocked out
but quite a maze when you get in deeper.
Right now, using the 1 piece stock cfg file, I am
faced with the fact
that my carrier outbound calls started failing after I enabled
VM.
Basically WITH_VOICEMAIL in route LOCATION started sending the carrier
calls to TOVOICEMAIL and it basically dies there. I can see the
route(TOVOICEMAIL) line and can condition it out with an if but I
really don't now how to differentiate between a ext to ext call or a
outbound call in the cfg file. However given SQL I could.
Is there a way for me to place custom pseudo
variables in the call
right @ the start and use them in the script as needed. For
example I
could mark the call as ext to ext or carrier bound right @ the start
and dodge VM in the LOCATION route.
KD
> _______________________________________________
> Kamailio (SER) - Users Mailing List
> sr-users(a)lists.kamailio.org
> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
6:17 p.m.
Retransmission dampening (t_check_trans()) is meant to prevent this. But of course there
are edge cases. I wouldn't worry about that. They're quite marginal.
On May 14, 2018 6:15:42 PM GMT+02:00, KamDev Essa <kamdevessa(a)yahoo.com> wrote:
Theoretically in the lifespan of an INVITE can
request_route be called
again? Do I need to set a flag that says I have already dipped DB?
KD
On Monday, May 14, 2018, 12:04:28 PM EDT, Alex Balashov
<abalashov(a)evaristesys.com> wrote:
Not necessarily. All depends on how performant the query is.
Most real-world call processing involves at least one database touch
point on every call. Our product does about five or six complex stored
procedure calls and we can still do about 1000 CPS on most commodity
hardware.
On May 14, 2018 5:52:59 PM GMT+02:00, KamDev Essa
<kamdevessa(a)yahoo.com> wrote:
-- Alex
--
Sent via mobile, please forgive typos and brevity.
Awesome. Will I take a huge performance hit if I I
dip to DB on every
call. e.g
request_route {
# Initialize AVPs needed for the call. # call usp that
returns
calltype and other items
sql_xquery("ca","call usp_classcall '$fU' ,
'$fd';", "ra");
$avp(call_type) = $xavp(ra=>callType); $avp(goodies1) =
$xavp(ra=> goodies1); $avp( goodies2) = $xavp(ra=> goodies2);
$avp( goodies3) = $xavp(ra=> goodies3);
sql_result_free("ra");
}
Will DB hits on every call hinder performance.
On Monday, May 14, 2018, 10:03:04 AM EDT, Alex Balashov
<abalashov(a)evaristesys.com> wrote:
I think your best bet is to set those variables as AVPs, so that
their
values can persist throughout the lifetime of the
INVITE transaction.
That way you can also access them in onreply_route and failure_route,
which would not be the case with user variables ($var(...)).
request_route {
# Initialise AVPs to $null or presumed default value.
$avp(call_type) = $null;
...
# When determination is made as to the call type:
if($dbr(res=>[0,0]) eq 'vm')
$avp(call_type) = 'voicemail';
}
-- Alex
On Mon, May 14, 2018 at 01:56:53PM +0000, KamDev Essa wrote:
> Being spoiled by Freeswitch profiles and dialplans, the stock 1
piece
Kamailio cfg file is cool @ first to get certain
call flows knocked
out
but quite a maze when you get in deeper.
> Right now, using the 1 piece stock cfg file, I am faced with the
fact
that my carrier outbound calls started failing
after I enabled VM.
Basically WITH_VOICEMAIL in route LOCATION started sending the carrier
calls to TOVOICEMAIL and it basically dies there. I can see the
route(TOVOICEMAIL) line and can condition it out with an if but I
really don't now how to differentiate between a ext to ext call or a
outbound call in the cfg file. However given SQL I could.
-- Alex
--
Sent via mobile, please forgive typos and brevity.
_______________________________________________
Kamailio (SER) - Users Mailing List
sr-users(a)lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
Is there a way for me to place custom pseudo
variables in the call
right @ the start and use them in the script as needed. For
example I
could mark the call as ext to ext or carrier bound right @ the start
and dodge VM in the LOCATION route.
KD
> _______________________________________________
> Kamailio (SER) - Users Mailing List
> sr-users(a)lists.kamailio.org
> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
2363
days inactive
2363
days old
5 comments
2 participants
participants (2)
-
Alex Balashov -
KamDev Essa