Hello List,<div>I&#39;ve got an issue where I&#39;m logging calls with the acc module with the CDR flag. To do this, I&#39;ve got some lines in my main route body, something like this:</div><div><br></div><div><br></div><div>


if (is_method(&quot;INVITE&quot;)) {</div><div>     setflag(1);</div><div>     setflag(4); </div><div>}</div><div><br></div><div>Where flag 1 is acc&#39;s db_flag, and flag 4 is cdr_flag. This is the only time these flags are set, except I setflag(1) for BYEs in the loose route.</div>


<div><br></div><div>Everything works great except for one call scenario. Call is setup, provider detects it as a T.38 and attempts a re-invite. Client rejects (488) the reinvite. Then the client sends a BYE.</div><div><br>


</div><div>So what happens is if I watch the ACC table when this happens:</div><div>1. Call comes in</div><div>2. Routes to provider (invite to provider)</div><div>3. Call setup successfully, no retransmissions (200 OK + ACK) looks good</div>


<div>4. **NOTHING IN ACC YET** probably because cdr_flag is on and the dialog still &quot;exists&quot;</div><div>5. Provider detects fax tones.. sends a T.38 reinvite.. </div><div>6. Opensips sends it along to the client. </div>


<div>7. Client rejects it (488)</div><div>8. 488 sent to provider</div><div>9. STILL nothing in acc table</div><div>10. Client sends BYE</div><div>11. BYE is forwarded onto provider</div>
<div><meta charset="utf-8"><div>12. BYE logged in ACC (first record of the call in acc table)</div></div><div>13. Call is dead.. client doesn&#39;t see call, provider doesn&#39;t see call. dlg_list_dlg shows dialog active</div>

<div>14. Dialog persists for almost exactly 12 hours</div><div>15. INVITE is finally written into the database. &quot;time&quot; column is correct (ie: From the INVITE to the BYE looking at the time columns you can get the right length of the call, not the 12 hours long) BUT duration field reflects 12 hours in seconds.</div>

<div><br></div><div>Yes, so to be clear, the INVITE arrives in the acc table *much later* than the BYE</div><div><br></div><div>It seems to only happen to rejected t.38 reinvites. Any idea what may be causing the dialogs to not end when a BYE is received?</div>

<div><br></div><div>Thanks,</div><div>-Brett</div><div><br></div><div><br></div>