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

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}); } 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/dis… 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(a)gmail.com&gt; 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(a)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(a)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(a)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(a)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(a)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(a)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}); > > } > > 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(a)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(a)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(a)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 &lt;hbilling(a)gmail.com&gt; > 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(a)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(a)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(a)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(a)gmail.com&gt; 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(a)gmail.com&gt; 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@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 Listsr-users@lists.kamailio.orghttps://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users >>>> >>>> -- >>>> Daniel-Constantin Mierla -- www.asipto.comwww.twitter.com/miconda -- 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.comwww.twitter.com/miconda -- www.linkedin.com/in/miconda >>> >>> -- >>> Daniel-Constantin Mierla -- www.asipto.comwww.twitter.com/miconda -- 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.comwww.twitter.com/miconda -- 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.comwww.twitter.com/miconda -- www.linkedin.com/in/miconda