[SR-Users] dialog table entry not deleted after call if in-dialog requests are challenged

[Daniel-Constantin Mierla]

Hello,

I could not spot how dialog traffic is handled, via flag or 
dlg_manage()? The dialog entry should be deleted after the BYE is 
processed. Can you dump the dialog attributes via mi (with kamctl) and 
see what is the state of the dialog after processing the BYE? Also, you 
can try to do dlg_manage() when BYE is received.

Cheers,
Daniel

On 11/30/11 3:36 PM, Yufei Tao wrote:
> Hi
>
> I am using dialog module in Kamailio 3.1.5, and find that the dialog
> table entry does not get deleted after call if in-dialog requests (e.g.
> session timer refresh re-INVITEs in my case) are challenged. The entry
> will stay there and get deleted after a long time (some time out? I
> didn't set any dialog timeouts myself). If I remove the challenge for
> in-dialog requests, then the dialog entry is deleted right after the call.
>
> I use the example config script with a bit of modification for my
> in-dialog route:
>
> route[WITHINDLG] {
>    xlog("L_DBG","WITHINDLG: method=$rm, callid=$ci, cseq=$cs\n");
>
>    if (has_totag() ) {
>      # sequential request withing a dialog should
>      # take the path determined by record-routing
>      if (loose_route()) {
>        # Filter out bad/faked up in-dialog requests.
>        if ( !is_known_dlg() )
>        {
>          xlog("L_WARN","WITHINDLG: NOT known dlg!! method=$rm,
> callid=$ci, cseq=$cs, $fu->$tu\n");
>          exit;
>        }
>
>        if (is_method("BYE")) {
>          xlog("L_DBG","WITHINDLG: BYE found within Dialog \n");
>
>          setflag(FLT_ACC); # do accounting ...
>          setflag(FLT_ACCFAILED); # ... even if the transaction fails
>        }
> ##########################################################
>        # challenge: if not CANCEL/ACK
>        else if ( !is_method("CANCEL")&&  !is_method("ACK") )
>        {
>          route(AUTH);
>        }
> ##########################################################
>        xlog("L_DBG","WITHINDLG: Entering RELAY route from WITHINDLG
> route. \n");
>
>          route(RELAY);
>      } else {
>        if (is_method("SUBSCRIBE")&&  uri == myself) {
>          # in-dialog subscribe requests
>          route(PRESENCE);
>          exit;
>          }
>          if ( is_method("ACK") ) {
>          xlog("L_DBG","WITHINDLG: ACK callid=$ci, cseq=$cs\n");
>
>          if ( t_check_trans() ) {
>            # no loose-route, but stateful ACK;
>            # must be an ACK after a 487
>            # or e.g. 404 from upstream server
>
>            xlog("L_DBG","ACK being relayed\n");
>
>            t_relay();
>            exit;
>          } else {
>            # ACK without matching transaction ... ignore and discard
>            xlog("L_DBG","ACK without matching transaction-ignore and
> discard\n");
>            exit;
>          }
>        }
>        sl_send_reply("404","Not here");
>      }
>      exit;
>    }
> }
>
> The part that calls route(AUTH) that I added was the cause for the
> dialog entry not being deleted after call.
>
> Here are my dialog related settings:
>
> modparam("dialog", "enable_stats", 1)
> modparam("dialog", "dlg_flag", 4)
> modparam("dialog", "db_url", DBURL)
> modparam("dialog", "db_update_period", 20) # use short one to catch
> short dlgs (default:60)
> modparam("dialog", "db_mode", 1)
> # don't use did, so to cope with clients that don't preserve parameters
> # and mode 1 (fallback to 3261 matching) didn't work??
> modparam("dialog", "dlg_match_mode", 2)
>
> modparam("dialog", "profiles_no_value", "inbound ; outbound")
> modparam("dialog", "dlg_extra_hdrs", "Hint: dialog expired\r\n")
>
> # default timeout set to max int 0x07FFFF FFFF
> modparam("dialog", "default_timeout", 2147483647)
>
>
>
> And I set the dialog flag (4) when receiving the initial INVITE.
>
> Any idea why? Am I using the dialog module correctly?
>
> Thanks very much!
>
> Yufei
>
> --
> Yufei Tao
> Red Embedded
>
> This E-mail and any attachments hereto are strictly confidential and intended solely for the addressee. If you are not the intended addressee please notify the sender by return and delete the message.
>
> You must not disclose, forward or copy this E-mail or attachments to any third party without the prior consent of the sender.
>
> Red Embedded Design, Company Number 06688253 Registered in England: The Waterfront, Salts Mill Rd, Saltaire, BD17 7EZ
>
> _______________________________________________
> SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
> sr-users at lists.sip-router.org
> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users

-- 
Daniel-Constantin Mierla -- http://www.asipto.com
Kamailio Advanced Training, Dec 5-8, Berlin: http://asipto.com/u/kat
http://linkedin.com/in/miconda -- http://twitter.com/miconda