[OpenSIPS-Users] Dialogs not ending on failed reinvites

Brett Nemeroff brett at nemeroff.com
Wed Mar 16 22:33:38 CET 2011


Hello List,
I've got an issue where I'm logging calls with the acc module with the CDR
flag. To do this, I've got some lines in my main route body, something like
this:


if (is_method("INVITE")) {
     setflag(1);
     setflag(4);
}

Where flag 1 is acc'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.

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.

So what happens is if I watch the ACC table when this happens:
1. Call comes in
2. Routes to provider (invite to provider)
3. Call setup successfully, no retransmissions (200 OK + ACK) looks good
4. **NOTHING IN ACC YET** probably because cdr_flag is on and the dialog
still "exists"
5. Provider detects fax tones.. sends a T.38 reinvite..
6. Opensips sends it along to the client.
7. Client rejects it (488)
8. 488 sent to provider
9. STILL nothing in acc table
10. Client sends BYE
11. BYE is forwarded onto provider
12. BYE logged in ACC (first record of the call in acc table)
13. Call is dead.. client doesn't see call, provider doesn't see call.
dlg_list_dlg shows dialog active
14. Dialog persists for almost exactly 12 hours
15. INVITE is finally written into the database. "time" 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.

Yes, so to be clear, the INVITE arrives in the acc table *much later* than
the BYE

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?

Thanks,
-Brett
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/users/attachments/20110316/92814b11/attachment.htm>


More information about the Users mailing list