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 > <mico...@gmail.com <mailto:mico...@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@172.27.44.121 <mailto:1-5214@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@172.27.44.121 <mailto:1-5214@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@172.27.44.121 <mailto:1-5214@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@172.27.44.121 <mailto:1-5214@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@172.27.44.121 <mailto:1-5214@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@172.27.44.121 <mailto:1-5214@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@172.27.44.121 <mailto:1-5214@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@172.27.44.121 <mailto:1-5214@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@172.27.44.121 <mailto:1-5214@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 <hbill...@gmail.com >> <mailto:hbill...@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@172.27.44.121 <mailto:1-5214@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@172.27.44.121 <mailto:1-5214@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@172.27.44.121 <mailto:1-5214@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 >> <mico...@gmail.com <mailto:mico...@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 <mico...@gmail.com <mailto:mico...@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@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@lists.kamailio.org >>>>> <mailto:sr-users@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
_______________________________________________ Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users