[Home]

Summary:ASTERISK-07185: [patch] On Busy or Congestion after Answer we send wrong SIP messages - we act like the call isn't answered
Reporter:Steve Davies . (stevedavies)Labels:
Date Opened:2006-06-16 04:05:14Date Closed:2006-06-18 16:06:44
Priority:MajorRegression?No
Status:Closed/CompleteComponents:Channels/chan_sip/Interoperability
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:( 0) busyprob.log
( 1) dontstatebusy.patch
Description:Reproduce using the following test dialplan:

   exten => 123,1,Wait(1)
   exten => 123,2,Answer
   exten => 123,3,Wait(2)
   exten => 123,4,Busy(10)

I've attached a full log included sip debug for this test.

You'll see that at the start of the Busy(10) we send a "Session Progress" before the inband busy tone.  That shouldn't be there because the call is already answered.  Then at the end of the Busy tone we send "Declined".  (Should have been Bye).

My phone ignores the Declined.  Eventually Asterisk gives up resending it and clears of the channel, logging a "Maximum retries exceeded on transmission ...  (Critical Response)"  But the phone still thinks it has the call established.

Same thing happens if you use Congestion(n).

The problem is caused by the fact that chan_sip uses the channel's _state to "remember" if the call is up (AST_STATE_UP) or not.  But the Busy and Congestion apps reset the _state to AST_STATE_BUSY before the generator gets a chance to run.  When the generator runs, sip_write gets called which checks the _state and sends the misplaced Session Progress".

Similarly, later when sip_hangup gets called it behaves as though the call is not up.

The bug affects ordinary calls to Busy or Congestion due to the Session Progress that is sent.  That's not too serious I guess.  But calls to Busy(n) get badly affected because the hangup after the timeout doesn't work.

I've attached a patch that simply changes apps Busy and Congestion to not change the AST_STATE.  It really doesn't seem useful to change the state like that.  This was Olle's opinion also.  The alternative fix is trickier: chan_sip can't depend on chan->_state to know if the call is answered and must remember for itself.  Probably can be (yet another) bit flag in the pvt structure.

Regards,
Steve


****** ADDITIONAL INFORMATION ******

This bug is present in trunk and also in branch-1.2
Note that the widely used AMP/FreePBX/Trixbox uses the Busy(n) construct.
Disclaimer is on file.
Comments:By: Olle Johansson (oej) 2006-06-16 06:54:35

Already fixed in svn trunk :-)
By: Olle Johansson (oej) 2006-06-16 06:55:22

Your patch is wrong by the way, we do need to set state to busy if the call is not UP already.
By: Steve Davies . (stevedavies) 2006-06-17 10:39:54

hey olle - you owe me karma points ;-)
By: Russell Bryant (russell) 2006-06-18 16:06:44

fixed in 1.2 in rev 34655