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(a)lists.kamailio.org <mailto:sr-users@lists.kamailio.org> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

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 &lt;miconda(a)gmail.com <mailto:miconda@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(a)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

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 &lt;miconda(a)gmail.com > <mailto:miconda@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(a)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>

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(a)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(a)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(a)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(a)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(a)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(a)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}); } 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(a)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(a)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(a)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 &lt;hbilling(a)gmail.com&gt; 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(a)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(a)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(a)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 < > miconda(a)gmail.com&gt; 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 < >> miconda(a)gmail.com&gt; 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 Listsr-users@lists.kamailio.orghttps://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

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 (3-5996(a)172.27.44.121 &lt;3-5996(a)172.27.44.121&gt;)* 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 < miconda(a)gmail.com&gt; 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/dis… > 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 < > miconda(a)gmail.com&gt; 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(a)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(a)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(a)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(a)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(a)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(a)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}); >> >> } >> >> 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(a)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(a)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(a)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 &lt;hbilling(a)gmail.com&gt; >> 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(a)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(a)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(a)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 < >>> miconda(a)gmail.com&gt; 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 < >>>> miconda(a)gmail.com&gt; 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 Listsr-users@lists.kamailio.orghttps://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

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(a)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(a)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(a)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(a)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(a)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(a)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}); } 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(a)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(a)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(a)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 &lt;hbilling(a)gmail.com&gt; 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(a)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(a)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(a)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 < > miconda(a)gmail.com&gt; 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 < >> miconda(a)gmail.com&gt; 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 Listsr-users@lists.kamailio.orghttps://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