[asterisk-commits] russell: branch 1.6.1 r203118 - in /branches/1.6.1: ./ channels/chan_sip.c
SVN commits to the Asterisk project
asterisk-commits at lists.digium.com
Thu Jun 25 11:07:14 CDT 2009
Author: russell
Date: Thu Jun 25 11:07:10 2009
New Revision: 203118
URL: http://svn.asterisk.org/svn-view/asterisk?view=rev&rev=203118
Log:
Merged revisions 203116 via svnmerge from
https://origsvn.digium.com/svn/asterisk/trunk
................
r203116 | russell | 2009-06-25 11:04:10 -0500 (Thu, 25 Jun 2009) | 18 lines
Merged revisions 203115 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r203115 | russell | 2009-06-25 11:02:16 -0500 (Thu, 25 Jun 2009) | 11 lines
Resolve a crash related to a T.38 reinvite race condition.
This change resolves a crash observed locally during some T.38 testing.
A call was set up using a call file, and when the T.38 reinvite came in,
the channel state was still AST_STATE_DOWN. The reason is explained by
a comment in the code that previously lived in the handling of
AST_STATE_RINGING. This change modifies the logic to handle the same
race condition for any channel state that is not UP.
(closes ABE-1895)
........
................
Modified:
branches/1.6.1/ (props changed)
branches/1.6.1/channels/chan_sip.c
Propchange: branches/1.6.1/
------------------------------------------------------------------------------
Binary property 'trunk-merged' - no diff available.
Modified: branches/1.6.1/channels/chan_sip.c
URL: http://svn.asterisk.org/svn-view/asterisk/branches/1.6.1/channels/chan_sip.c?view=diff&rev=203118&r1=203117&r2=203118
==============================================================================
--- branches/1.6.1/channels/chan_sip.c (original)
+++ branches/1.6.1/channels/chan_sip.c Thu Jun 25 11:07:10 2009
@@ -18635,7 +18635,23 @@
if (c) { /* We have a call -either a new call or an old one (RE-INVITE) */
- switch(c->_state) {
+ enum ast_channel_state c_state = c->_state;
+
+ if (c_state != AST_STATE_UP && reinvite &&
+ (p->invitestate == INV_TERMINATED || p->invitestate == INV_CONFIRMED)) {
+ /* If these conditions are true, and the channel is still in the 'ringing'
+ * state, then this likely means that we have a situation where the initial
+ * INVITE transaction has completed *but* the channel's state has not yet been
+ * changed to UP. The reason this could happen is if the reinvite is received
+ * on the SIP socket prior to an application calling ast_read on this channel
+ * to read the answer frame we earlier queued on it. In this case, the reinvite
+ * is completely legitimate so we need to handle this the same as if the channel
+ * were already UP. Thus we are purposely falling through to the AST_STATE_UP case.
+ */
+ c_state = AST_STATE_UP;
+ }
+
+ switch(c_state) {
case AST_STATE_DOWN:
ast_debug(2, "%s: New call is still down.... Trying... \n", c->name);
transmit_response(p, "100 Trying", req);
@@ -18697,21 +18713,9 @@
p->invitestate = INV_PROCEEDING;
break;
case AST_STATE_RINGING:
- if (reinvite && (p->invitestate == INV_TERMINATED || p->invitestate == INV_CONFIRMED)) {
- /* If these conditions are true, and the channel is still in the 'ringing'
- * state, then this likely means that we have a situation where the initial
- * INVITE transaction has completed *but* the channel's state has not yet been
- * changed to UP. The reason this could happen is if the reinvite is received
- * on the SIP socket prior to an application calling ast_read on this channel
- * to read the answer frame we earlier queued on it. In this case, the reinvite
- * is completely legitimate so we need to handle this the same as if the channel
- * were already UP. Thus we are purposely falling through to the AST_STATE_UP case.
- */
- } else {
- transmit_response(p, "180 Ringing", req);
- p->invitestate = INV_PROCEEDING;
- break;
- }
+ transmit_response(p, "180 Ringing", req);
+ p->invitestate = INV_PROCEEDING;
+ break;
case AST_STATE_UP:
ast_debug(2, "%s: This call is UP.... \n", c->name);
More information about the asterisk-commits
mailing list