Hello Brett,
The behavior you describe, that dlg_list_dlg still shows the dialog
active after the BYE was received by the proxy, could generally have two
reasons.
1) OpenSIPS did not match the BYE to a specific dialog
2) One endpoint did not send the 200 OK for the BYE terminating
the dialog. OpenSIPS will keep the dialog in memory, as it doesn't
consider that the dialog has officially ended until the BYE transaction
ends.
Either way, after 12 hours, which is the default dialog timeout value,
the dialog module forcefully closes the dialog, which triggers the
INVITE CDR logging in the DB.
Still, I cannot understand why the BYE is logged first into the DB. Both
the CDR type of accounting and the regular type of accounting are
triggered when the proxy receives the BYE, only that the CDR accounting
is triggered internally if you set the cdr_flag on the initial invite,
so by all means the CDR accounting should be first in the database.
There could be a problem in matching the re-invite to a known dialog,
but I am not sure if this is the case for you.
Could you please post a SIP traffic capture of the call that gets the
T.38 re-invite ?
And, if not asking for too much, maybe a high level debug log.
Regards,
--
Vlad Paiu
OpenSIPS Developer
On 03/16/2011 11:33 PM, Brett Nemeroff wrote:
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
_______________________________________________
Users mailing list
[email protected]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
_______________________________________________
Users mailing list
[email protected]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
