Hi Daniel, The above solution you suggested works for me. However, I am observing a behavior after we have started fetching the Session-Expires Header Value from the initial INVITE.
1. If the 200 OK(to the initial INVITE) from the UAS contains a lesser value of Session-Expires, than the one advertised in the initial INVITE, the session termination(by SST/Dialog Module) in case no refresh INVITE is sent, happens at the value sent in the Initial INVITE only. ie. a lower Session-Expires value in 200OK does not seem to be taking effect. 2. If the subsequent in-dialog INVITEs contain a different(lower) Session refresh value, than the one advertised in the initial INVITE, the $avp(..) seems to be getting updated, but the session termination still happens at the end of initial INVITE;s Session Expires value. Is this as per implementation, or should the timeout be updated based on the 200OK response and other in-dialog REINVITEs as well? NOTE: Reposting, as for some reason, this mail didn't show up in the mailer list. Regards, Harneet Singh On Fri, Mar 27, 2020 at 1:19 PM Daniel-Constantin Mierla <[email protected]> wrote: > Hello, > > try to use: > > $(hdr(Session-Expires){s.select,0,;}{s.int}); > > It should work even when there is only the expires value, with no > parameters. > > Cheers, > Daniel > On 27.03.20 04:53, harneet singh 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 > > -- > 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
