[SR-Users] Problem faced when Using Kamaiio as Session Refresher

Daniel-Constantin Mierla miconda at gmail.com
Tue Mar 24 11:32:40 CET 2020


Hello,

we have to update the docs for timeout_avp in sst module to reflect this
behaviour.

Related to the dispatcher load, try using the
event_route[tm:local-request], inside it you can catch the BYE generated
by Kamailio.

It could be a good addition to make dispatcher decrease the load also
from dialog end event route. I can look into it when I find some spare
time, if nobody else wants to do it meanwhile.

Cheers,
Daniel

On 24.03.20 10:23, harneet singh wrote:
> Hi Daniel,
>
> Your timely response is much appreciated. I was able to fetch the
> Session-Expires value from the INVITE's SE header, albeit with a minor
> modification. I guess there were missing "(Double Quotes)" in the
> argument to is_present_hf. After fixing that, things worked and the
> Dialog Expiry is triggered at the correct time, and hence the BYE is
> sent from Kamailio to UAC and UAS as expected.
>
> if(is_present_hf("Session-Expires")) {
>
>    $avp(...) = $(hdr(Session-Expires){s.int <http://s.int/>});
>
> }
>
> However, there is still a concern from the earlier email that is
> unresolved. We are using Call Load Based Dispatching
> Algorithm(Algorithm 10) and here's teh observation:
>
> 1. When a BYE is initiated by either UAC or UAS, the dialog load is
> reduced by 1, since we call ds_load_update 
>
>  # Dispatcher load updation
>         if (is_method("BYE|CANCEL")){
>             ds_load_update();
>         }
>
> 2. When however, the BYE is initiated by Kamailio towards UAC and UAS
> as a result of session-Expiry, the load is NOT reduced. I am looking
> at this parameter from the output of "kamcmd dispatcher.list" command. 
>
>                     RUNTIME: {
>                                                 DLGLOAD: 1
>                                         }
>
> I did go through the ds_load_update() API
> at https://github.com/kamailio/kamailio/blob/master/src/modules/dispatcher/dispatch.c 
> file and seems like the ds_load_remove() which probably reduces the
> load gets called only for a BYE or CANCEL that is received. Since
> clearing by kamailio in case of Session-Expiry is done by sending the
> BYE out of Kamailio, the load might not be getting removed.
>
> In addition to the above, I also tried adding the below code where the
> ds_load_update() gets called when the dialog ends, but still the
> dispatcher load is not removed, despite this piece of code getting
> called. 
>
> event_route[dialog:end] {
>    xlog("L_ALERT", '[DIALOG:END] : Dialog ENDING NOW....' + "\n");
>    ds_load_update();
> }
>
> What would be your recommend to circumvent/fix the issue?
>
> Regards,
>
> Harneet
>
>
>
> On Mon, Mar 23, 2020 at 7:21 PM Daniel-Constantin Mierla
> <miconda at gmail.com <mailto:miconda at gmail.com>> wrote:
>
>     Hello,
>
>     looking at logs, the callback functions from sst modules are for
>     requests within dialog, not for initial request. It looks like the
>     update is expected to be done when the request refreshing the
>     session is done (the reinvite), therefore for initial INVITE the
>     avp is not set.
>
>
>     Mar 23 15:14:39 CPaaSVM kamailio: 1(4248) DEBUG: {1 1 INVITE
>     1-5214 at 172.27.44.121 <mailto:1-5214 at 172.27.44.121>} sst
>     [sst_handlers.c:988]: setup_dialog_callbacks(): Adding callback
>     DLGCB_FAILED|DLGCB_TERMINATED|DLGCB_EXPIRED
>     Mar 23 15:14:39 CPaaSVM kamailio: 1(4248) DEBUG: {1 1 INVITE
>     1-5214 at 172.27.44.121 <mailto:1-5214 at 172.27.44.121>} sst
>     [sst_handlers.c:992]: setup_dialog_callbacks(): Adding callback
>     DLGCB_REQ_WITHIN
>     Mar 23 15:14:39 CPaaSVM kamailio: 1(4248) DEBUG: {1 1 INVITE
>     1-5214 at 172.27.44.121 <mailto:1-5214 at 172.27.44.121>} sst
>     [sst_handlers.c:1002]: setup_dialog_callbacks(): Adding callback
>     DLGCB_RESPONSE_FWDED
>     Mar 23 15:14:39 CPaaSVM kamailio: 1(4248) DEBUG: {1 1 INVITE
>     1-5214 at 172.27.44.121 <mailto:1-5214 at 172.27.44.121>} sst
>     [sst_handlers.c:1006]: setup_dialog_callbacks(): Adding rpc handler
>
>     There are callbacks for the response as well, and they seem to be
>     executed, avp attempted to be set, but already having the same value:
>
>     Mar 23 15:14:39 CPaaSVM kamailio: 37(4284) DEBUG: {2 1 INVITE
>     1-5214 at 172.27.44.121 <mailto:1-5214 at 172.27.44.121>} sst
>     [sst_handlers.c:520]: sst_dialog_response_fwded_CB(): Dialog seen
>     REPLY 200 OK
>     Mar 23 15:14:39 CPaaSVM kamailio: 37(4284) DEBUG: {2 1 INVITE
>     1-5214 at 172.27.44.121 <mailto:1-5214 at 172.27.44.121>} sst
>     [sst_handlers.c:870]: set_timeout_avp(): Current timeout value
>     already set to 200
>
>     A solution you can try for now would be to set the avp explicitly
>     for the first invite, like:
>
>     if(is_present_hf(Session-Expires)) {
>
>        $avp(...) = $(hdr(Session-Expires){s.int <http://s.int>});
>
>     }
>
>     Cheers,
>     Daniel
>
>     On 23.03.20 11:29, harneet singh wrote:
>>     Hi Daniel,
>>
>>     I have shared the logs at debug=3 level.
>>     Location: https://justpaste.it/6xmum
>>      I do see the sst and dialog module are loaded at startup and
>>     Even that the sst module sees the Session-Expires value. But
>>     somehow the dialog module doesn't seem to recognize it.
>>
>>     Please see the excerpts from the log below:
>>     Mar 23 15:14:39 CPaaSVM kamailio: 1(4248) DEBUG: {1 1
>>     INVITE 1-5214 at 172.27.44.121 <mailto:1-5214 at 172.27.44.121>} sst
>>     [sst_handlers.c:668]: ki_sst_check_min(): Session-Expires: 200;
>>     MIN-SE: 100
>>     Mar 23 15:14:39 CPaaSVM kamailio: 1(4248) DEBUG: {1 1
>>     INVITE 1-5214 at 172.27.44.121 <mailto:1-5214 at 172.27.44.121>} sst
>>     [sst_handlers.c:692]: ki_sst_check_min(): Done returning false (-1)
>>     ............ 
>>     ............. 
>>     Mar 23 15:14:39 CPaaSVM kamailio: 1(4248) DEBUG: {1 1
>>     INVITE 1-5214 at 172.27.44.121 <mailto:1-5214 at 172.27.44.121>} dialog
>>     [dlg_handlers.c:681]: get_dlg_timeout(): invalid AVP value, using
>>     default timeout
>>
>>     Can you please take a look? 
>>
>>     Regards,
>>     Harneet 
>>
>>     On Mon, Mar 23, 2020 at 3:42 PM harneet singh <hbilling at gmail.com
>>     <mailto:hbilling at gmail.com>> wrote:
>>
>>         Hi Daniel,
>>
>>         I have attached here the logs at debug=3 level. I do see the
>>         sst and dialog module are loaded at startup and Even that the
>>         sst module sees the Session-Expires value. But somehow the
>>         dialog module doesn't seem to recognize it.
>>
>>         Please see the excerpts from the log below:
>>         Mar 23 15:14:39 CPaaSVM kamailio: 1(4248) DEBUG: {1 1 INVITE
>>         1-5214 at 172.27.44.121 <mailto:1-5214 at 172.27.44.121>} sst
>>         [sst_handlers.c:668]: ki_sst_check_min(): Session-Expires:
>>         200; MIN-SE: 100
>>         Mar 23 15:14:39 CPaaSVM kamailio: 1(4248) DEBUG: {1 1 INVITE
>>         1-5214 at 172.27.44.121 <mailto:1-5214 at 172.27.44.121>} sst
>>         [sst_handlers.c:692]: ki_sst_check_min(): Done returning
>>         false (-1)
>>         ............ 
>>         ............. 
>>         Mar 23 15:14:39 CPaaSVM kamailio: 1(4248) DEBUG: {1 1 INVITE
>>         1-5214 at 172.27.44.121 <mailto:1-5214 at 172.27.44.121>} dialog
>>         [dlg_handlers.c:681]: get_dlg_timeout(): invalid AVP value,
>>         using default timeout
>>
>>         Can you please take a look?
>>
>>         Regards,
>>         Harneet 
>>
>>         On Mon, Mar 23, 2020 at 3:02 PM Daniel-Constantin Mierla
>>         <miconda at gmail.com <mailto:miconda at gmail.com>> wrote:
>>
>>             Hello,
>>
>>             also check if code from sst module is executing when
>>             processing the dialog. Maybe the callback functions from
>>             sst are not called when dialog is handling the sip
>>             traffic. You should run with debug=3 and look at the
>>             debug messages to see if there are some printed from sst
>>             module. Watch also for other error or warning log
>>             messages, they may indicate that some processing could
>>             not be done.
>>
>>             Eventually you can make the debug messages (from kamailio
>>             start to processing of the dialog) available somewhere
>>             online (e.g., pastebin) so we can look at them and analyze.
>>
>>             Cheers,
>>             Daniel
>>
>>             On 22.03.20 15:23, Daniel-Constantin Mierla wrote:
>>>
>>>             Hello,
>>>
>>>             ah, ok, I misunderstood.
>>>
>>>             Is the INVITE received with the header Session-Expires?
>>>
>>>             And remove the line:
>>>
>>>             #!define DLG_TIMEOUT_AVP "i:1"
>>>
>>>             It does not replaces the token inside strings, like
>>>             inside the last parameter of the line:
>>>
>>>             modparam("dialog", "timeout_avp", "$avp(DLG_TIMEOUT_AVP)")
>>>
>>>             and if you use in config expressions
>>>             $avp(DLG_TIMEOUT_AVP), then its name is replaced. So
>>>             overall it can be two avp names, although when reading
>>>             looks like one.
>>>
>>>             Cheers,
>>>             Daniel
>>>
>>>             On 22.03.20 14:40, harneet singh wrote:
>>>>             Hi Daniel,
>>>>
>>>>             Thanks for the confirmation. Your point confirms the
>>>>             same as I interpreted from the documentation, that
>>>>             Kamailio would not send refresh INVITEs. I am not
>>>>             expecting to achieve that. However, if i understand
>>>>             correctly, Kamailio can look into the "Session-Expires"
>>>>             header from UAC/UAS and set the timeout_avp based on that.
>>>>             In effect, Kamailio should ideally *tear down the call
>>>>             (Send a BYE to UAC and UAS)*, if it doesn't see any
>>>>             signalling(may it be session-refresh INVITE/UPDATE or
>>>>             any other mid-dialog messages). This i believe can be
>>>>             done by using the SST Module in conjunction with the
>>>>             Dialog Module. 
>>>>             I am also using the SST Module and the Dialog Module,
>>>>             however have the following issues.
>>>>
>>>>             1. I am seeing the following message when sending
>>>>             Session-Expires: 200 . 
>>>>                ""dialog [dlg_handlers.c:681]: *get_dlg_timeout():
>>>>             invalid AVP value, using default timeout*"
>>>>
>>>>             Not sure what is causing this. 
>>>>
>>>>             2. If i try to hardcode the session-expires to a
>>>>             certain value, the Kamailio DOES send a BYE to UAC and
>>>>             UAS on the timer expiry if no signaling seen during
>>>>             that time. However, as pointed earlier, the Dialog Load
>>>>             on the Kamailio DOES NOT go down, as shown in the last
>>>>             email.
>>>>
>>>>             FWIW, here's the config snippet from the Kamailio cfg i
>>>>             am using.
>>>>              
>>>>             ==========================================================================  
>>>>             #!define *DLG_TIMEOUT*_AVP "i:1"
>>>>
>>>>             # ----------- dialog params -----------
>>>>             modparam("dialog", "send_bye", 1)
>>>>             *modparam("dialog", "timeout_avp",
>>>>             "$avp(DLG_TIMEOUT_AVP)")*
>>>>             modparam("dialog", "dlg_flag", 5)
>>>>
>>>>             # ----------- sst params -----------
>>>>             modparam("sst", "enable_stats", 1)
>>>>             modparam("sst", "min_se", 150)
>>>>             # Set the sst modules timeout_avp to be the same value
>>>>             *modparam("sst", "timeout_avp", "$avp(DLG_TIMEOUT_AVP)")*
>>>>             #modparam("sst", "reject_to_small", 1)
>>>>             modparam("sst", "sst_flag", 6)
>>>>
>>>>
>>>>             request_route {
>>>>                  ....... 
>>>>                  ....... 
>>>>                 # account only INVITEs
>>>>             if (is_method("INVITE")) {
>>>>                             setflag(FLT_ACC); # do accounting
>>>>                             
>>>>                             setflag(5); # set the dialog flag
>>>>                             setflag(6); # Set the sst flag
>>>>                             $dlg_ctx(timeout_bye)=1;
>>>>
>>>>                             if (sstCheckMin("1")) {
>>>>                                xlog("L_ERR", "422 Session Timer Too
>>>>             Small reply sent.\n");
>>>>                                exit;
>>>>                             }
>>>>
>>>>             }
>>>>              .....
>>>>             ......
>>>>             }
>>>>
>>>>
>>>>             ==========================================================================
>>>>
>>>>             From the SST documentation, it pretty much seems like
>>>>             the only config to do. Am I missing something. If you
>>>>             have a working config for the Kamailio tuned in this
>>>>             manner using the SST and Dialog Module, could you share
>>>>             the same?
>>>>             Any pointers to make it work are most welcome. 
>>>>
>>>>             Regards,
>>>>             Harneet
>>>>
>>>>
>>>>
>>>>             On Sun, Mar 22, 2020 at 3:01 PM Daniel-Constantin
>>>>             Mierla <miconda at gmail.com <mailto:miconda at gmail.com>>
>>>>             wrote:
>>>>
>>>>                 Hello,
>>>>
>>>>                 are you looking for Kamailio to send re-INVITEs? If
>>>>                 yes, that is not available as a feature of dialog
>>>>                 module.
>>>>
>>>>                 Cheers,
>>>>                 Daniel
>>>>
>>>>                 On 21.03.20 10:39, harneet singh wrote:
>>>>>                 Hi,
>>>>>
>>>>>                 I am fairly new to Kamailio and had a question
>>>>>                 regarding how to use Kamailio to enable Session
>>>>>                 refresh functionality when Kamailio is acting as
>>>>>                 Sip Stateful Proxy. 
>>>>>                 Kamailio Version used: *5.3.2* with *Call Load
>>>>>                 based routing* using the *dispatcher *module.
>>>>>
>>>>>
>>>>>                 * From what i understand from the documentation,
>>>>>                 Kamailio will probably not be acting as a session
>>>>>                 refresher, but Kamailio can tear down the call in
>>>>>                 case session refresh is negotiated, between the
>>>>>                 caller and the callee(via Kamailio Sip Proxy), and
>>>>>                 no message exchange happens in the duration set in
>>>>>                 Session-Expires header. *Is my understanding correct?*
>>>>>                 *
>>>>>                 *
>>>>>                 ** *I believe the above functionality is possible
>>>>>                 by using the *sst* and *dialog* module. I have set
>>>>>                 the same according to the documentation but I keep
>>>>>                 getting the following error:
>>>>>                 "dialog [dlg_handlers.c:681]: *get_dlg_timeout():
>>>>>                 invalid AVP value, using default timeout*"
>>>>>                 Can someone share a working example?
>>>>>
>>>>>                 * When i tried hardcoding the timeout value by
>>>>>                 setting the timeout_avp to a specific value,
>>>>>                 Kamailio did sense a timeout and hence sent a BYE
>>>>>                 towards the caller and the Callee side both(which
>>>>>                 is what the requirement is), however, i do see the
>>>>>                 *dialog is still not cleared* in the "kamcmd
>>>>>                 dispatcher.list". Output excerpt below for reference:
>>>>>
>>>>>                 [root at CPaaSVM ~]# kamcmd dispatcher.list
>>>>>                 {
>>>>>                         NRSETS: 1
>>>>>                         RECORDS: {
>>>>>                                 SET: {
>>>>>                                         ID: 1
>>>>>                                         TARGETS: {
>>>>>                                                 DEST: {
>>>>>                                                         URI:
>>>>>                 sip:172.27.44.121:5080;transport=tcp
>>>>>                                                         FLAGS: AP
>>>>>                                                         PRIORITY: 0
>>>>>                                                         ATTRS: {
>>>>>                                                                
>>>>>                 BODY: duid=sample-cas;maxload=1000
>>>>>                                                                
>>>>>                 DUID: sample-cas
>>>>>                                                                
>>>>>                 MAXLOAD: 1000
>>>>>                                                                
>>>>>                 WEIGHT: 0
>>>>>                                                                
>>>>>                 RWEIGHT: 0
>>>>>                                                                
>>>>>                 SOCKET:
>>>>>                                                         }
>>>>>                                                         LATENCY: {
>>>>>                                                                
>>>>>                 AVG: 111.304000
>>>>>                                                                
>>>>>                 STD: 1042.193000
>>>>>                                                                
>>>>>                 EST: 2.385000
>>>>>                                                                
>>>>>                 MAX: 9999
>>>>>                                                                
>>>>>                 TIMEOUT: 1
>>>>>                                                         }
>>>>>                                                         RUNTIME: {
>>>>>                                                                
>>>>>                 DLGLOAD: *1*
>>>>>                                                         }
>>>>>                                                 }
>>>>>                                         }
>>>>>                                 }
>>>>>                         }
>>>>>                 }
>>>>>
>>>>>                 It is noteworthy that in case the BYE is initiated
>>>>>                 by either the caller or the callee, the dialog is
>>>>>                 cleared properly and the DLGLOAD is set to 0 on
>>>>>                 call termination. 
>>>>>
>>>>>                 Any pointers for the above questions would be
>>>>>                 highly appreciated. 
>>>>>
>>>>>                 Regards,
>>>>>                 Harneet
>>>>>
>>>>>                 -- 
>>>>>                 "Once you eliminate the impossible, whatever
>>>>>                 remains, no matter how improbable, must be the
>>>>>                 truth" - Sir Arthur Conan Doyle
>>>>>
>>>>>                 _______________________________________________
>>>>>                 Kamailio (SER) - Users Mailing List
>>>>>                 sr-users at lists.kamailio.org <mailto:sr-users at lists.kamailio.org>
>>>>>                 https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>>>>
>>>>                 -- 
>>>>                 Daniel-Constantin Mierla -- www.asipto.com <http://www.asipto.com>
>>>>                 www.twitter.com/miconda <http://www.twitter.com/miconda> -- www.linkedin.com/in/miconda <http://www.linkedin.com/in/miconda>
>>>>
>>>>
>>>>
>>>>             -- 
>>>>             "Once you eliminate the impossible, whatever remains,
>>>>             no matter how improbable, must be the truth" - Sir
>>>>             Arthur Conan Doyle
>>>             -- 
>>>             Daniel-Constantin Mierla -- www.asipto.com <http://www.asipto.com>
>>>             www.twitter.com/miconda <http://www.twitter.com/miconda> -- www.linkedin.com/in/miconda <http://www.linkedin.com/in/miconda>
>>
>>             -- 
>>             Daniel-Constantin Mierla -- www.asipto.com <http://www.asipto.com>
>>             www.twitter.com/miconda <http://www.twitter.com/miconda> -- www.linkedin.com/in/miconda <http://www.linkedin.com/in/miconda>
>>
>>
>>
>>         -- 
>>         "Once you eliminate the impossible, whatever remains, no
>>         matter how improbable, must be the truth" - Sir Arthur Conan
>>         Doyle
>>
>>
>>
>>     -- 
>>     "Once you eliminate the impossible, whatever remains, no matter
>>     how improbable, must be the truth" - Sir Arthur Conan Doyle
>
>     -- 
>     Daniel-Constantin Mierla -- www.asipto.com <http://www.asipto.com>
>     www.twitter.com/miconda <http://www.twitter.com/miconda> -- www.linkedin.com/in/miconda <http://www.linkedin.com/in/miconda>
>
>
>
> -- 
> "Once you eliminate the impossible, whatever remains, no matter how
> improbable, must be the truth" - Sir Arthur Conan Doyle

-- 
Daniel-Constantin Mierla -- www.asipto.com
www.twitter.com/miconda -- www.linkedin.com/in/miconda

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.kamailio.org/pipermail/sr-users/attachments/20200324/09c969fa/attachment.html>


More information about the sr-users mailing list