[asterisk-commits] rmudgett: branch rmudgett/bch_shift_v1.8 r311665 - /team/rmudgett/bch_shift_v...

[SVN commits to the Asterisk project]

Author: rmudgett
Date: Thu Mar 24 14:41:56 2011
New Revision: 311665

URL: http://svnview.digium.com/svn/asterisk?view=rev&rev=311665
Log:
Invalid PRI call ptr message associated with force channel RESTART.

When Asterisk receives a cause PRI_CAUSE_REQUESTED_CHAN_UNAVAIL(44), it
forces a RESTART on that B channel.  Due to timing, another SETUP
requesting the same B channel could come in right after the
RELEASE_COMPLETE with cause 44.  That call SETUP would get shifted to
another channel and two messages sent immediately (SETUP_ACKNOWLEDGE,
PROCEEDING, ALERTING, or CONNECT).  The peer Asterisk box on receiving the
RESTART, immediately hangs up and destroys the new call associated with the B channel.
When the peer then processes the two messages for the destroyed call, it
responds with PRI_CAUSE_INVALID_CALL_REFERENCE(81) to both.

--> SETUP(call-1)
<-- RELEASE_COMPLETE(call-1, PRI_CAUSE_REQUESTED_CHAN_UNAVAIL)
<-- SETUP(call-2, same B channel)
--> RESTART
--> SETUP_ACKNOWLEDGE(call-2, New B channel)
--> CONNECT(call-2)
<-- RESTART_ACKNOWLEDGE (Destroys call-2 because associated with B channel)
<-- RELEASE_COMPLETE(call-2, PRI_CAUSE_INVALID_CALL_REFERENCE)
<-- RELEASE_COMPLETE(call-2, PRI_CAUSE_INVALID_CALL_REFERENCE)

If both RELEASE_COMPLETE responses are processed by libpri before the
Asterisk core hangs up the call, then the invalid call ptr message is
generated.  Libpri has already destroyed the call structure when it
processed the second RELEASE_COMPLETE.

Fixed by making sure that the call is hung up and forgotten immediately if
the hangup cause is PRI_CAUSE_INVALID_CALL_REFERENCE.

Modified:
    team/rmudgett/bch_shift_v1.8/channels/sig_pri.c

Modified: team/rmudgett/bch_shift_v1.8/channels/sig_pri.c
URL: http://svnview.digium.com/svn/asterisk/team/rmudgett/bch_shift_v1.8/channels/sig_pri.c?view=diff&rev=311665&r1=311664&r2=311665
==============================================================================
--- team/rmudgett/bch_shift_v1.8/channels/sig_pri.c (original)
+++ team/rmudgett/bch_shift_v1.8/channels/sig_pri.c Thu Mar 24 14:41:56 2011
@@ -5649,6 +5649,18 @@
 				sig_pri_lock_private(pri->pvts[chanpos]);
 				sig_pri_handle_subcmds(pri, chanpos, e->e, e->hangup.channel,
 					e->hangup.subcmds, e->hangup.call);
+				switch (e->hangup.cause) {
+				case PRI_CAUSE_INVALID_CALL_REFERENCE:
+					/*
+					 * The peer denies the existence of this call so we must
+					 * continue hanging it up and forget about it.
+					 */
+					pri_hangup(pri->pri, e->hangup.call, e->hangup.cause);
+					pri->pvts[chanpos]->call = NULL;
+					break;
+				default:
+					break;
+				}
 				if (!pri->pvts[chanpos]->alreadyhungup) {
 					/* we're calling here dahdi_hangup so once we get there we need to clear p->call after calling pri_hangup */
 					pri->pvts[chanpos]->alreadyhungup = 1;
@@ -5662,6 +5674,7 @@
 					}
 					if (pri->pvts[chanpos]->owner) {
 						int do_hangup = 0;
+
 						/* Queue a BUSY instead of a hangup if our cause is appropriate */
 						pri->pvts[chanpos]->owner->hangupcause = e->hangup.cause;
 						switch (pri->pvts[chanpos]->owner->_state) {
@@ -5794,6 +5807,16 @@
 				case PRI_CAUSE_USER_BUSY:
 				case PRI_CAUSE_NORMAL_CIRCUIT_CONGESTION:
 					sig_pri_cc_generic_check(pri, chanpos, AST_CC_CCBS);
+					break;
+				case PRI_CAUSE_INVALID_CALL_REFERENCE:
+					/*
+					 * The peer denies the existence of this call so we must
+					 * continue hanging it up and forget about it.  We should not
+					 * get this cause here, but for completeness we will handle it
+					 * anyway.
+					 */
+					pri_hangup(pri->pri, e->hangup.call, e->hangup.cause);
+					pri->pvts[chanpos]->call = NULL;
 					break;
 				default:
 					break;