Module: sip-router Branch: master Commit: 8bf53ec54beab825794b8345cce7fdb41c783809 URL: http://git.sip-router.org/cgi-bin/gitweb.cgi/sip-router/?a=commit;h=8bf53ec5...
Author: Timo Reimann timo.reimann@1und1.de Committer: Timo Reimann timo.reimann@1und1.de Date: Wed Jun 30 18:25:55 2010 +0200
Do not consider in-early-dialog BYE requests to be bogus.
---
modules_k/dialog/dlg_hash.c | 1 + 1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/modules_k/dialog/dlg_hash.c b/modules_k/dialog/dlg_hash.c index d7a16f1..72b7fec 100644 --- a/modules_k/dialog/dlg_hash.c +++ b/modules_k/dialog/dlg_hash.c @@ -704,6 +704,7 @@ void next_state_dlg(struct dlg_cell *dlg, int event, dlg->state = DLG_STATE_DELETED; *unref = 1; break; + case DLG_STATE_EARLY: case DLG_STATE_DELETED: break; default:
2010/7/1 Timo Reimann timo.reimann@1und1.de:
Do not consider in-early-dialog BYE requests to be bogus.
Good point. But let me a question:
A BYE during early-dialog just ends its specific dialog (and not other parallel early-dialogs). Will it be considered in the new dialog module design?
Regards.
Hey Iñaki,
Iñaki Baz Castillo wrote:
2010/7/1 Timo Reimann timo.reimann@1und1.de:
Do not consider in-early-dialog BYE requests to be bogus.
Good point. But let me a question:
A BYE during early-dialog just ends its specific dialog (and not other parallel early-dialogs). Will it be considered in the new dialog module design?
The proposal wasn't too specific on that issue. Yesterday, I modified the wiki page and made it clear that the improved dialog module must handle such situations properly.
Of course, the current implementation isn't capable of do it. That's why the fix only avoids a warning log message, nothing else.
Cheers,
--Timo
2010/7/1 Timo Reimann timo.reimann@1und1.de:
Hey Iñaki,
Iñaki Baz Castillo wrote:
2010/7/1 Timo Reimann timo.reimann@1und1.de:
Do not consider in-early-dialog BYE requests to be bogus.
Good point. But let me a question:
A BYE during early-dialog just ends its specific dialog (and not other parallel early-dialogs). Will it be considered in the new dialog module design?
The proposal wasn't too specific on that issue. Yesterday, I modified the wiki page and made it clear that the improved dialog module must handle such situations properly.
Of course, the current implementation isn't capable of do it. That's why the fix only avoids a warning log message, nothing else.
Ok, thanks a lot for the response.