Summary:	ASTERISK-01808: Problems handling incoming alerting and incoming connected on a pri
Reporter:	petersv (petersv)	Labels:
Date Opened:	2004-06-12 14:37:07	Date Closed:	2004-09-25 02:42:34
Priority:	Major	Regression?	No
Status:	Closed/Complete	Components:	Core/General
Versions:		Frequency of Occurrence
Related Issues:
Environment:		Attachments:	( 0) asterisk-20040612-wf-alerting.diff
Description:	Two different problems really: An ALERTING element received from an outgoing pri is not passed to the originating channel. Possibly it is passed as a PROGRESS, I am not sure since the logs I have (pri intense) of the two channels were taken one at a time and are not correlated in time. The alerting is stopped in chan_zap.c, in zt_indicate() by the test "!p->proceeding". When asterisk is used as an outgoing gateway in the same setup as above (pbx - pri - asterisk - pri - pstn) asterisk does not pass the CONNECTED element unless an ALERTING element is received from the pstn first. By dialing (pbx-pri-asterisk-pstn-asterisk-pri-pbx) these to problems together makes the originating pbx not see a CONNECT element. The connect is supressed in ast_answer() in channel.c. The chan->_state was AST_STATE_RESERVED on the originating channel. ****** STEPS TO REPRODUCE ****** #1: Dial in to the asterisk box on a pri line using an extension that goes out another pri line. The ougoing endpoint sends an ALERTING element that asterisk sees come in. No ALERTING element is sent back to the originator. #2: Dial form a pbx to the asterisk machine and out to the pstn to a machine that behaves like in #1 above. The conenct ****** ADDITIONAL INFORMATION ****** I have attached a patch that worked around these two problems for us. I can not sat that I know enough about pri lines to know that they are correct. There is a log of such a call on http://www.psv.nu/jbl/problemlog.txt.
Comments:	By: Mark Spencer (markster) 2004-06-13 02:08:42 Have you submitted a disclaimer yet, btw?  We'll need one to use any non-trivial patches. By: Mark Spencer (markster) 2004-06-13 02:13:54 The first part of this -- the answer not working -- has to do with zap not getting put into "RING" state when it finally comes through.  That should be fixed now (please confirm in latest CVS head).  Doubt this will fix the second half but let me know By: petersv (petersv) 2004-06-13 02:56:16 I though all the patches I have made so far are either trivial (add a missing state in a switch statement) or definitly not the correct way to fix a problem (hide a race with an usleep(500000)) so I have not sumbitted one yet. I will test a newer cvs in next week and see if any of the patches are still needed. By: petersv (petersv) 2004-06-14 15:15:07 The first part is indeed solved. The second part is harder to try. After the fix of the ALERTING element we no longer get a CONNECTED without an ALERTING so we do not know if there is a problem or not. Are CONNECTED without a prio ALERTING allowed by the spec? Maybe this was related the the premature PROGRESS bug I added a bugnote on tonight? Let me know if you need logs or anything. After the testing of a clean cvs head I reapplied the patch to allow CONNECTS in reserved state just in case. By: Mark Spencer (markster) 2004-06-15 22:31:50 You can definitely go to CONNECTED without ALERTING.  Is there anything left here?