Hello, probably you can use an htable to store that the ds_load_remove() was called for a specific call id, but we can make that error log message to debug level, there can be cross BYEs at the end of a call resulting in same situation.
Cheers, Daniel On 24.03.20 13:55, harneet singh wrote: > 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] <mailto:[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] <mailto:[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 <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 >> <[email protected] <mailto:[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] <mailto:[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] <mailto:[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] <mailto:[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] <mailto:[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] <mailto:[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] <mailto:[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 <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 [email protected] <mailto:[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] <mailto:[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] <mailto:[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] <mailto:[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] >>> <mailto:[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] >>> <mailto:[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] >>> <mailto:[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] <mailto:[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] >>>>> <mailto:[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 List >>>>>> [email protected] >>>>>> <mailto:[email protected]> >>>>>> >>>>>> 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 <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 [email protected] https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
