[asterisk-bugs] [JIRA] (PRI-180) Incorrect handling of DISCONNECT with Progress Indicator #8

[Alexandr Dranchuk (JIRA)]

    [ https://issues.asterisk.org/jira/browse/PRI-180?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=229372#comment-229372 ] 

Alexandr Dranchuk commented on PRI-180:
---------------------------------------

Hi Richard! We found a bug in PBX we are connected to. Thus to make a right test we are waiting for bugfix from PBX manufacturer. Once we get all in place, I'll immidiatelly report here about.
Also found in Internet that it's a good point to provide 183 Progress message like that:
1. -> SIP/INVITE
2. -> ISDN/SETUP
3. <- ISDN/DISCONNECT with cause 'user busy' and progress indicator
4. <- SIP/183 Session Progress

So the question is: what if we in block 
{code:title=q931.c|borderStyle=solid}
		/* wait for a RELEASE so that sufficient time has passed
		   for the inband audio to be heard */
		if (ctrl->acceptinbanddisconnect && (c->progressmask & PRI_PROG_INBAND_AVAILABLE))
			break;
{code}
Pretend that we get PROGRESS and tell this to Asterisk way like that:
{code:title=q931.c|borderStyle=solid}
		/* wait for a RELEASE so that sufficient time has passed
		   for the inband audio to be heard */
		if (ctrl->acceptinbanddisconnect && (c->progressmask & PRI_PROG_INBAND_AVAILABLE)) {
				/* send PROGRESS event for Bring voice path up */
				ctrl->ev.e = PRI_EVENT_PROGRESS;
				ctrl->ev.proceeding.cause = c->cause;  // --- значение? (AST_CAUSE_USER_BUSY например, для начала оставим как есть 31 код, потом 19)
				ctrl->ev.proceeding.subcmds = &ctrl->subcmds; //can be NULL
				ctrl->ev.proceeding.channel = q931_encode_channel(c);
				ctrl->ev.proceeding.progress = c->progress; //  ---знпчение Q931_PROG_INBAND_AVAILABLE или 0
				ctrl->ev.proceeding.progressmask = c->progressmask;
				ctrl->ev.proceeding.cref = c->cr;
				ctrl->ev.proceeding.call = c->master_call;
				return Q931_RES_HAVEEVENT;
			}
{code}



> Incorrect handling of DISCONNECT with Progress Indicator #8
> -----------------------------------------------------------
>
>                 Key: PRI-180
>                 URL: https://issues.asterisk.org/jira/browse/PRI-180
>             Project: LibPRI
>          Issue Type: Bug
>      Security Level: None
>          Components: General
>    Affects Versions: 1.4.13
>         Environment: Debian 7 / x64
>            Reporter: Alexandr Dranchuk
>            Assignee: Alexandr Dranchuk
>            Severity: Minor
>         Attachments: full_20160116_progress, jira_pri_180_v1.4.15.patch
>
>
> When we make an outgoing call by DAHDI / libpri 1.4.15, sometimes we get a DISCONNECT with Progress Indicator #8. Currently we just start to ignore DISCONNECT message if *inbanddisconnect=yes* are set in chan_dahdi.conf
> But after first DISCONNECT with Progress Indicator #8, we get second DISCONNECT without Progress Indicator, and thus have to release the call, not keep ignoring it.
> Current code not expecting second DISCONNECT message, only RELEASE but according  ETS ISDN standards document, call can be finished by any of this messages.
> For now I've changed the line of q931.c from
> {code:title=q931.c|borderStyle=solid}
> 		UPDATE_OURCALLSTATE(ctrl, c, Q931_CALL_STATE_DISCONNECT_INDICATION);
> 		c->peercallstate = Q931_CALL_STATE_DISCONNECT_REQUEST;
> 		c->sendhangupack = 1;
> 		/* wait for a RELEASE so that sufficient time has passed
> 		   for the inband audio to be heard */
> 		if (ctrl->acceptinbanddisconnect && (c->progressmask & PRI_PROG_INBAND_AVAILABLE))
> 			break;
> {code}
> to
> {code:title=q931.c|borderStyle=solid}
> 		if (ctrl->acceptinbanddisconnect && (c->progressmask & PRI_PROG_INBAND_AVAILABLE)) {
> 			if (c->ourcallstate != Q931_CALL_STATE_DISCONNECT_INDICATION) { 
> 				UPDATE_OURCALLSTATE(ctrl, c, Q931_CALL_STATE_DISCONNECT_INDICATION);
> 				c->peercallstate = Q931_CALL_STATE_DISCONNECT_REQUEST;
> 				c->sendhangupack = 1;
> 				break;
> 			}
> 		}
> 		
> 		UPDATE_OURCALLSTATE(ctrl, c, Q931_CALL_STATE_DISCONNECT_INDICATION);
> 		c->peercallstate = Q931_CALL_STATE_DISCONNECT_REQUEST;
> 		c->sendhangupack = 1;
> {code}
> and tested. All works fine for me. 
> Any help would be appreciated.



--
This message was sent by Atlassian JIRA
(v6.2#6252)