Thanks Daniel, Your suggestion was very helpful. I am now able to see the dialog load go down on Dispatcher as expected in case of session expiry. Just an extra error log is what I keep getting per occurrence. I believe the reason for this is that the event_route[tm:local-request] will be called twice per call since BYE is sent to two sides.
The log is : Mar 24 17:23:59 CPaaSVM kamailio: 25(7499) DEBUG: sst [sst_handlers.c:405]: sst_dialog_terminate_CB(): Terminating DID 0x7fd847a50340 session Mar 24 17:23:59 CPaaSVM kamailio: 25(7499) DEBUG: sst [sst_handlers.c:412]: sst_dialog_terminate_CB(): freeing the sst_info_t from dialog 0x7fd847a50340 Mar 24 17:23:59 CPaaSVM kamailio: 25(7499) ALERT: <script>: [tm:local-request] RSYS: BYE Sent. Updating Load... Mar 24 17:23:59 CPaaSVM kamailio: 25(7499) ALERT: <script>: [tm:local-request] RSYS: BYE Sent. Updating Load... *Mar 24 17:23:59 CPaaSVM kamailio: 25(7499) ERROR: dispatcher [dispatch.c:1664]: ds_load_remove(): cannot find load for ([email protected] <[email protected]>)* Is there a way I can avoid calling the ds_load_update from event_route[tm:local-request] by somehow figuring out that it has been accounted for once, for this dialog? I understand that the dialog event end route might be the most appropriate path to call this as that would probably be called once for a dialog, but in case you have any recommendations to circumvent the error code seen above? Thanks & Regards, Harneet On Tue, Mar 24, 2020 at 4:02 PM Daniel-Constantin Mierla <[email protected]> wrote: > 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/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 < > [email protected]> 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 >> [email protected]} 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 >> [email protected]} 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 >> [email protected]} 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 >> [email protected]} 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 >> [email protected]} 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 >> [email protected]} 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 >> [email protected]} 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 >> [email protected]} 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 >> [email protected]} 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 <[email protected]> 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 >>> [email protected]} 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 >>> [email protected]} 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 >>> [email protected]} 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 < >>> [email protected]> 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 < >>>> [email protected]> 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 >>>>> [email protected]https://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 > > -- "Once you eliminate the impossible, whatever remains, no matter how improbable, must be the truth" - Sir Arthur Conan Doyle
_______________________________________________ Kamailio (SER) - Users Mailing List [email protected] https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
