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@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@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

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@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@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@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@gmail.com 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@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 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

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@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@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@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@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@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@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@172.27.44.121 mailto:1-5214@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@172.27.44.121 mailto:1-5214@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@172.27.44.121 mailto:1-5214@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 <hbilling@gmail.com mailto:hbilling@gmail.com> 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@172.27.44.121 <mailto:1-5214@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@172.27.44.121 <mailto:1-5214@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@172.27.44.121 <mailto:1-5214@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@gmail.com <mailto:miconda@gmail.com>> 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@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@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>

    -- 
    Daniel-Constantin Mierla -- www.asipto.com <http://www.asipto.com>
    www.twitter.com/miconda <http://www.twitter.com/miconda> -- www.linkedin.com/in/miconda <http://www.linkedin.com/in/miconda>



-- 
"Once you eliminate the impossible, whatever remains, no matter
how improbable, must be the truth" - Sir Arthur Conan Doyle

-- "Once you eliminate the impossible, whatever remains, no matter how improbable, must be the truth" - Sir Arthur Conan Doyle

Hello,

we have to update the docs for timeout_avp in sst module to reflect this behaviour.

Related to the dispatcher load, try using the event_route[tm:local-request], inside it you can catch the BYE generated by Kamailio.

It could be a good addition to make dispatcher decrease the load also from dialog end event route. I can look into it when I find some spare time, if nobody else wants to do it meanwhile.

Cheers, Daniel

On 24.03.20 10:23, harneet singh wrote:

Hi Daniel,

Your timely response is much appreciated. I was able to fetch the Session-Expires value from the INVITE's SE header, albeit with a minor modification. I guess there were missing "(Double Quotes)" in the argument to is_present_hf. After fixing that, things worked and the Dialog Expiry is triggered at the correct time, and hence the BYE is sent from Kamailio to UAC and UAS as expected.

if(is_present_hf("Session-Expires")) {

$avp(...) = $(hdr(Session-Expires){s.int http://s.int/});

}

However, there is still a concern from the earlier email that is unresolved. We are using Call Load Based Dispatching Algorithm(Algorithm 10) and here's teh observation:

1. When a BYE is initiated by either UAC or UAS, the dialog load is

reduced by 1, since we call ds_load_update

# Dispatcher load updation         if (is_method("BYE|CANCEL")){             ds_load_update();         }

2. When however, the BYE is initiated by Kamailio towards UAC and UAS

as a result of session-Expiry, the load is NOT reduced. I am looking at this parameter from the output of "kamcmd dispatcher.list" command.

RUNTIME: {                                                 DLGLOAD: 1                                         }

I did go through the ds_load_update() API at https://github.com/kamailio/kamailio/blob/master/src/modules/dispatcher/disp... 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@gmail.com mailto:miconda@gmail.com> 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@172.27.44.121 <mailto:1-5214@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@172.27.44.121 <mailto:1-5214@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@172.27.44.121 <mailto:1-5214@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@172.27.44.121 <mailto:1-5214@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@172.27.44.121 <mailto:1-5214@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@172.27.44.121 <mailto:1-5214@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 <http://s.int>});

}

Cheers,
Daniel

On 23.03.20 11:29, harneet singh wrote:

...

Hi Daniel,

I have shared the logs at debug=3 level.
Location: https://justpaste.it/6xmum
 I do see the sst and dialog module are loaded at startup and
Even that the sst module sees the Session-Expires value. But
somehow the dialog module doesn't seem to recognize it.

Please see the excerpts from the log below:
Mar 23 15:14:39 CPaaSVM kamailio: 1(4248) DEBUG: {1 1
INVITE 1-5214@172.27.44.121 <mailto:1-5214@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@172.27.44.121 <mailto:1-5214@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@172.27.44.121 <mailto:1-5214@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 <hbilling@gmail.com
<mailto:hbilling@gmail.com>> 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@172.27.44.121 <mailto:1-5214@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@172.27.44.121 <mailto:1-5214@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@172.27.44.121 <mailto:1-5214@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@gmail.com <mailto:miconda@gmail.com>> 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@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@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>

        -- 
        Daniel-Constantin Mierla -- www.asipto.com <http://www.asipto.com>
        www.twitter.com/miconda <http://www.twitter.com/miconda> -- www.linkedin.com/in/miconda <http://www.linkedin.com/in/miconda>



    -- 
    "Once you eliminate the impossible, whatever remains, no
    matter how improbable, must be the truth" - Sir Arthur Conan
    Doyle



-- 
"Once you eliminate the impossible, whatever remains, no matter
how improbable, must be the truth" - Sir Arthur Conan Doyle

-- 
Daniel-Constantin Mierla -- www.asipto.com <http://www.asipto.com>
www.twitter.com/miconda <http://www.twitter.com/miconda> -- www.linkedin.com/in/miconda <http://www.linkedin.com/in/miconda>

-- "Once you eliminate the impossible, whatever remains, no matter how improbable, must be the truth" - Sir Arthur Conan Doyle

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@172.27.44.121 mailto:3-5996@172.27.44.121)*

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@gmail.com mailto:miconda@gmail.com> wrote:

Hello,

we have to update the docs for timeout_avp in sst module to
reflect this behaviour.

Related to the dispatcher load, try using the
event_route[tm:local-request], inside it you can catch the BYE
generated by Kamailio.

It could be a good addition to make dispatcher decrease the load
also from dialog end event route. I can look into it when I find
some spare time, if nobody else wants to do it meanwhile.

Cheers,
Daniel

On 24.03.20 10:23, harneet singh wrote:

...

Hi Daniel,

Your timely response is much appreciated. I was able to fetch the
Session-Expires value from the INVITE's SE header, albeit with a
minor modification. I guess there were missing "(Double Quotes)"
in the argument to is_present_hf. After fixing that, things
worked and the Dialog Expiry is triggered at the correct time,
and hence the BYE is sent from Kamailio to UAC and UAS as expected.

if(is_present_hf("Session-Expires")) {

   $avp(...) = $(hdr(Session-Expires){s.int <http://s.int/>});

}

However, there is still a concern from the earlier email that is
unresolved. We are using Call Load Based Dispatching
Algorithm(Algorithm 10) and here's teh observation:

1. When a BYE is initiated by either UAC or UAS, the dialog load
is reduced by 1, since we call ds_load_update 

 # Dispatcher load updation
        if (is_method("BYE|CANCEL")){
            ds_load_update();
        }

2. When however, the BYE is initiated by Kamailio towards UAC and
UAS as a result of session-Expiry, the load is NOT reduced. I am
looking at this parameter from the output of "kamcmd
dispatcher.list" command. 

                    RUNTIME: {
                                                DLGLOAD: 1
                                        }

I did go through the ds_load_update() API
at https://github.com/kamailio/kamailio/blob/master/src/modules/dispatcher/dispatch.c 
file and seems like the ds_load_remove() which probably reduces
the load gets called only for a BYE or CANCEL that is received.
Since clearing by kamailio in case of Session-Expiry is done by
sending the BYE out of Kamailio, the load might not be getting
removed.

In addition to the above, I also tried adding the below code
where the ds_load_update() gets called when the dialog ends, but
still the dispatcher load is not removed, despite this piece of
code getting called. 

event_route[dialog:end] {
   xlog("L_ALERT", '[DIALOG:END] : Dialog ENDING NOW....' + "\n");
   ds_load_update();
}

What would be your recommend to circumvent/fix the issue?

Regards,

Harneet



On Mon, Mar 23, 2020 at 7:21 PM Daniel-Constantin Mierla
<miconda@gmail.com <mailto:miconda@gmail.com>> 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@172.27.44.121 <mailto:1-5214@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@172.27.44.121 <mailto:1-5214@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@172.27.44.121 <mailto:1-5214@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@172.27.44.121 <mailto:1-5214@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@172.27.44.121 <mailto:1-5214@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@172.27.44.121 <mailto:1-5214@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 <http://s.int>});

    }

    Cheers,
    Daniel

    On 23.03.20 11:29, harneet singh wrote:

...

    Hi Daniel,

    I have shared the logs at debug=3 level.
    Location: https://justpaste.it/6xmum
     I do see the sst and dialog module are loaded at startup
    and Even that the sst module sees the Session-Expires value.
    But somehow the dialog module doesn't seem to recognize it.

    Please see the excerpts from the log below:
    Mar 23 15:14:39 CPaaSVM kamailio: 1(4248) DEBUG: {1 1
    INVITE 1-5214@172.27.44.121 <mailto:1-5214@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@172.27.44.121 <mailto:1-5214@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@172.27.44.121 <mailto:1-5214@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
    <hbilling@gmail.com <mailto:hbilling@gmail.com>> 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@172.27.44.121
        <mailto:1-5214@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@172.27.44.121
        <mailto:1-5214@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@172.27.44.121
        <mailto:1-5214@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@gmail.com <mailto:miconda@gmail.com>> 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@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@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>

            -- 
            Daniel-Constantin Mierla -- www.asipto.com <http://www.asipto.com>
            www.twitter.com/miconda <http://www.twitter.com/miconda> -- www.linkedin.com/in/miconda <http://www.linkedin.com/in/miconda>



        -- 
        "Once you eliminate the impossible, whatever remains, no
        matter how improbable, must be the truth" - Sir Arthur
        Conan Doyle



    -- 
    "Once you eliminate the impossible, whatever remains, no
    matter how improbable, must be the truth" - Sir Arthur Conan
    Doyle

    -- 
    Daniel-Constantin Mierla -- www.asipto.com <http://www.asipto.com>
    www.twitter.com/miconda <http://www.twitter.com/miconda> -- www.linkedin.com/in/miconda <http://www.linkedin.com/in/miconda>



-- 
"Once you eliminate the impossible, whatever remains, no matter
how improbable, must be the truth" - Sir Arthur Conan Doyle

-- 
Daniel-Constantin Mierla -- www.asipto.com <http://www.asipto.com>
www.twitter.com/miconda <http://www.twitter.com/miconda> -- www.linkedin.com/in/miconda <http://www.linkedin.com/in/miconda>

-- "Once you eliminate the impossible, whatever remains, no matter how improbable, must be the truth" - Sir Arthur Conan Doyle

$(hdr(Session-Expires){s.select,0,;}{s.int})

On Fri, Mar 27, 2020, 04:56 harneet singh hbilling@gmail.com 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 < miconda@gmail.com> 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 (3-5996@172.27.44.121 3-5996@172.27.44.121)*

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@gmail.com> 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/disp... 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@gmail.com> 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@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@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@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@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@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@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@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@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@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 hbilling@gmail.com 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@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@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@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@gmail.com> 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@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 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

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

Hi Daniel,

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?

Regards, Harneet Singh

On Fri, Mar 27, 2020 at 10:34 PM harneet singh hbilling@gmail.com wrote:

Thanks Daniel/Bastian.

The change suggested works for me. :)

Regards, Harneet

On Fri, Mar 27, 2020 at 1:28 PM Bastian Triller bastian.triller@gmail.com wrote:

...

$(hdr(Session-Expires){s.select,0,;}{s.int})

On Fri, Mar 27, 2020, 04:56 harneet singh hbilling@gmail.com 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 < miconda@gmail.com> 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 (3-5996@172.27.44.121 3-5996@172.27.44.121)*

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@gmail.com> 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/disp... 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@gmail.com> 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@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@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@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@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@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@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@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@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@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 hbilling@gmail.com 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@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@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@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@gmail.com> 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@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 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

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

---

Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.org 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

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 miconda@gmail.com 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 < miconda@gmail.com> 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 (3-5996@172.27.44.121 3-5996@172.27.44.121)*

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@gmail.com> 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/disp... 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@gmail.com> 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@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@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@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@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@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@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@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@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@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 hbilling@gmail.com 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@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@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@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@gmail.com> 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@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 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

-- "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