[SR-Users] Tagging a call with custom pseudo variables - cfg 101

[Alex Balashov]

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 at 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 at 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 at 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 at 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 at lists.kamailio.org
>>> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>
>
>-- Alex
>
>--
>Sent via mobile, please forgive typos and brevity. 
>
>_______________________________________________
>Kamailio (SER) - Users Mailing List
>sr-users at lists.kamailio.org
>https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>  


-- Alex

--
Sent via mobile, please forgive typos and brevity.