Daniel-Constantin Mierla writes:<br>
<br>
> As I wrote on the mailing list, flags should not be migrated to the<br>
> transaction after t_newtran() unless one uses t_flush_flags() -- that<br>
> was the desired functionality, otherwise t_flush_flags() has no<br>
> purpose.<br>
<br>
I have used flags for many years and for me it has been desirable that<br>
they are available after t_newtrans() in failure and onreply routes<br>
without a need to call t_flush_flags().  If someone wants to change that<br>
behavior and make t_flush_flags() purposeful, then a tm variable can be<br>
introduced to achieve that new behavior.<br>
<br>
> You opened another item on this tracker related to this unexpected<br>
> behaviour (#1490), and I think it is better to sort this out there,<br>
> because that is the unexpected behaviour. xflags behave as<br>
> expected. Whatever will be the conclusion of #1490 will be applied to<br>
> both flags and xflags, but makes no sense to track an issue with two<br>
> separate items.<br>
<br>
I opened this issue, because I needed more that 32 flags, i.e., flags<br>
that work the same way as before, but more of them.  It is OK to replace<br>
flags with xflags if my current configuration file keeps on working when<br>
I textually change current flag function calls with xflag function<br>
calls, but it is not OK if I need to start adding t_flush_xflags() calls<br>
to it.<br>
<br>
Issue "Is t_flush_flags() really needed? #1490" asks about the purpose<br>
of t_flush_flags() function.  I have not been able to figure out one,<br>
but perhaps there is some.  If there is no purpose, then the function<br>
should be removed.<br>
<br>
-- Juha<br>


<p style="font-size:small;-webkit-text-size-adjust:none;color:#666;">—<br />You are receiving this because you are subscribed to this thread.<br />Reply to this email directly, <a href="https://github.com/kamailio/kamailio/issues/1288#issuecomment-378838094">view it on GitHub</a>, or <a href="https://github.com/notifications/unsubscribe-auth/AF36ZVqrAoY_DIXFlqgGJjHdzmQ1dHqyks5tlb_RgaJpZM4QKR-M">mute the thread</a>.<img src="https://github.com/notifications/beacon/AF36ZWISyuIpchMoVZESVr7nRVr-pWnKks5tlb_RgaJpZM4QKR-M.gif" height="1" width="1" alt="" /></p>
<div itemscope itemtype="http://schema.org/EmailMessage">
<div itemprop="action" itemscope itemtype="http://schema.org/ViewAction">
  <link itemprop="url" href="https://github.com/kamailio/kamailio/issues/1288#issuecomment-378838094"></link>
  <meta itemprop="name" content="View Issue"></meta>
</div>
<meta itemprop="description" content="View this Issue on GitHub"></meta>
</div>

<script type="application/json" data-scope="inboxmarkup">{"api_version":"1.0","publisher":{"api_key":"05dde50f1d1a384dd78767c55493e4bb","name":"GitHub"},"entity":{"external_key":"github/kamailio/kamailio","title":"kamailio/kamailio","subtitle":"GitHub repository","main_image_url":"https://cloud.githubusercontent.com/assets/143418/17495839/a5054eac-5d88-11e6-95fc-7290892c7bb5.png","avatar_image_url":"https://cloud.githubusercontent.com/assets/143418/15842166/7c72db34-2c0b-11e6-9aed-b52498112777.png","action":{"name":"Open in GitHub","url":"https://github.com/kamailio/kamailio"}},"updates":{"snippets":[{"icon":"PERSON","message":"@juha-h in #1288: Daniel-Constantin Mierla writes:\n\n\u003e As I wrote on the mailing list, flags should not be migrated to the\n\u003e transaction after t_newtran() unless one uses t_flush_flags() -- that\n\u003e was the desired functionality, otherwise t_flush_flags() has no\n\u003e purpose.\n\nI have used flags for many years and for me it has been desirable that\nthey are available after t_newtrans() in failure and onreply routes\nwithout a need to call t_flush_flags().  If someone wants to change that\nbehavior and make t_flush_flags() purposeful, then a tm variable can be\nintroduced to achieve that new behavior.\n\n\u003e You opened another item on this tracker related to this unexpected\n\u003e behaviour (#1490), and I think it is better to sort this out there,\n\u003e because that is the unexpected behaviour. xflags behave as\n\u003e expected. Whatever will be the conclusion of #1490 will be applied to\n\u003e both flags and xflags, but makes no sense to track an issue with two\n\u003e separate items.\n\nI opened this issue, because I needed more that 32 flags, i.e., flags\nthat work the same way as before, but more of them.  It is OK to replace\nflags with xflags if my current configuration file keeps on working when\nI textually change current flag function calls with xflag function\ncalls, but it is not OK if I need to start adding t_flush_xflags() calls\nto it.\n\nIssue \"Is t_flush_flags() really needed? #1490\" asks about the purpose\nof t_flush_flags() function.  I have not been able to figure out one,\nbut perhaps there is some.  If there is no purpose, then the function\nshould be removed.\n\n-- Juha\n"}],"action":{"name":"View Issue","url":"https://github.com/kamailio/kamailio/issues/1288#issuecomment-378838094"}}}</script>