Thanks Daniel/Bastian. The change suggested works for me. :)
Regards, Harneet On Fri, Mar 27, 2020 at 1:28 PM Bastian Triller <[email protected]> wrote: > $(hdr(Session-Expires){s.select,0,;}{s.int}) > > On Fri, Mar 27, 2020, 04:56 harneet singh <[email protected]> wrote: > >> Hi Daniel, >> The following code works if the Session-Expires comes WITHOUTa refresher >> parameter. >> >> if(is_present_hf("Session-Expires")) { >> >> $avp(...) = $(hdr(Session-Expires){s.int}); >> >> } >> >> If however, The session expires comes like below, there is an error in >> parsing >> Session-Expires: 200;refresher=uac >> >> Is there a way we can fetch just the value, ignoring the refresher >> parameter? I believe the refresher parameter is not required to be picked >> up from the INVITE by Kamailio for the working of SST Module. >> >> Regards, >> Harneet Singh >> >> On Tue, Mar 24, 2020 at 7:11 PM Daniel-Constantin Mierla < >> [email protected]> wrote: >> >>> 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] <[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 >>> >>> -- >>> 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 >> > _______________________________________________ > Kamailio (SER) - Users Mailing List > [email protected] > https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users > -- "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
