[OpenSIPS-Users] Dialogs not ending on failed reinvites

[Vlad Paiu]

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
> Users at lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>    

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/users/attachments/20110318/622ec34f/attachment.htm>