Summary:	ASTERISK-16985: [branch] No response is received if we try to subscribe for call completion after we have received a 180 Ringing
Reporter:	George Konopacki (georgekonopacki)	Labels:
Date Opened:	2010-11-19 08:20:42.000-0600	Date Closed:	2011-02-15 10:18:46.000-0600
Priority:	Major	Regression?	No
Status:	Closed/Complete	Components:	Channels/chan_sip/Subscriptions
Versions:		Frequency of Occurrence
Related Issues:
Environment:		Attachments:
Description:	The server does NOT send a response if we try to subscribe for call completion after we have received a 180 Ringing. You can only subscribe for call completion when the call has been cleared. This appears to be a bug is the Asterisk call completion state machine. When we receive the 180 Ringing, for this call, its call-completion state is ‘CC_AVAILABLE’. If we then send a subscribe message to the server, it trys to change the call-completion state to ‘CC_CALLER_REQUESRED’. Because this is an invalid state change, it just ignores the message. The only state the Asterisk server will accept our subscribe message is in the state ‘CC_CALLER_AVAILABLE’. The Asterisk server will go into the ‘CC_CALLER_OFFERED’ when the SIP client clears the call by sending a CANCEL. ****** ADDITIONAL INFORMATION ****** The server should always send a response. Even if it a negative one.
Comments:	By: Mark Michelson (mmichelson) 2010-11-19 10:45:21.000-0600 Asterisk should definitely be sending at least some response to the SUBSCRIBE. Asterisk isn't designed, at least at the moment, to be able to handle a call completion request until a result can be determined for the call at hand. By: Mark Michelson (mmichelson) 2010-12-06 09:26:22.000-0600 There is a new SVN branch located at http://svn.digium.com/svn/asterisk/team/gruop/ccss_failure_response that should address both this issue and ASTERISK-16986. The reason it's in an SVN branch is that it required SIP changes from me as well as ISDN changes from rmudgett. I've made the necessary SIP changes, but I don't believe the ISDN changes are there yet. By: Digium Subversion (svnbot) 2011-02-15 10:13:58.000-0600 Repository: asterisk Revision: 307879 U   branches/1.8/channels/chan_dahdi.c U   branches/1.8/channels/chan_sip.c U   branches/1.8/channels/sig_pri.c U   branches/1.8/channels/sig_pri.h U   branches/1.8/include/asterisk/ccss.h U   branches/1.8/main/ccss.c ------------------------------------------------------------------------ r307879 | rmudgett | 2011-02-15 10:13:57 -0600 (Tue, 15 Feb 2011) | 37 lines No response sent for SIP CC subscribe/resubscribe request. Asterisk does not send a response if we try to subscribe for call completion after we have received a 180 Ringing.  You can only subscribe for call completion when the call has been cleared. When we receive the 180 Ringing, for this call, its call-completion state is 'CC_AVAILABLE'.  If we then send a subscribe message to Asterisk, it trys to change the call-completion state to 'CC_CALLER_REQUESTED'. Because this is an invalid state change, it just ignores the message.  The only state Asterisk will accept our subscribe message is in the 'CC_CALLER_OFFERED' state. Asterisk will go into the 'CC_CALLER_OFFERED' when the SIP client clears the call by sending a CANCEL. Asterisk should always send a response.  Even if its a negative one. The fix is to allow for the CCSS core to notify a CC agent that a failure has occurred when CC is requested.  The "ack" callback is replaced with a "respond" callback.  The "respond" callback has a parameter indicating either a successful response or a specific type of failure that may need to be communicated to the requester. (closes issue ASTERISK-16985) Reported by: GeorgeKonopacki Tested by: mmichelson, rmudgett JIRA SWP-2633 (closes issue ASTERISK-16986) Reported by: GeorgeKonopacki Tested by: mmichelson JIRA SWP-2634 ------------------------------------------------------------------------ http://svn.digium.com/view/asterisk?view=rev&revision=307879 By: Digium Subversion (svnbot) 2011-02-15 10:18:46.000-0600 Repository: asterisk Revision: 307883 _U  trunk/ U   trunk/channels/chan_dahdi.c U   trunk/channels/chan_sip.c U   trunk/channels/sig_pri.c U   trunk/channels/sig_pri.h U   trunk/include/asterisk/ccss.h U   trunk/main/ccss.c ------------------------------------------------------------------------ r307883 | rmudgett | 2011-02-15 10:18:45 -0600 (Tue, 15 Feb 2011) | 44 lines Merged revisions 307879 via svnmerge from https://origsvn.digium.com/svn/asterisk/branches/1.8 ........  r307879 | rmudgett | 2011-02-15 10:13:55 -0600 (Tue, 15 Feb 2011) | 37 lines    No response sent for SIP CC subscribe/resubscribe request.    Asterisk does not send a response if we try to subscribe for call  completion after we have received a 180 Ringing.  You can only subscribe  for call completion when the call has been cleared.    When we receive the 180 Ringing, for this call, its call-completion state  is 'CC_AVAILABLE'.  If we then send a subscribe message to Asterisk, it  trys to change the call-completion state to 'CC_CALLER_REQUESTED'.  Because this is an invalid state change, it just ignores the message.  The  only state Asterisk will accept our subscribe message is in the  'CC_CALLER_OFFERED' state.    Asterisk will go into the 'CC_CALLER_OFFERED' when the SIP client clears  the call by sending a CANCEL.    Asterisk should always send a response.  Even if its a negative one.      The fix is to allow for the CCSS core to notify a CC agent that a failure  has occurred when CC is requested.  The "ack" callback is replaced with a  "respond" callback.  The "respond" callback has a parameter indicating  either a successful response or a specific type of failure that may need  to be communicated to the requester.    (closes issue ASTERISK-16985)  Reported by: GeorgeKonopacki  Tested by: mmichelson, rmudgett    JIRA SWP-2633    (closes issue ASTERISK-16986)  Reported by: GeorgeKonopacki  Tested by: mmichelson    JIRA SWP-2634 ........ ------------------------------------------------------------------------ http://svn.digium.com/view/asterisk?view=rev&revision=307883