[asterisk-bugs] [JIRA] (PRI-180) Incorrect handling of DISCONNECT with Progress Indicator #8
Alexandr Dranchuk (JIRA)
noreply at issues.asterisk.org
Wed Feb 10 00:47:33 CST 2016
[ https://issues.asterisk.org/jira/browse/PRI-180?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=229372#comment-229372 ]
Alexandr Dranchuk edited comment on PRI-180 at 2/10/16 12:46 AM:
-----------------------------------------------------------------
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 in the 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;
ctrl->ev.proceeding.subcmds = &ctrl->subcmds;
ctrl->ev.proceeding.channel = q931_encode_channel(c);
ctrl->ev.proceeding.progress = c->progress;
ctrl->ev.proceeding.progressmask = c->progressmask;
ctrl->ev.proceeding.cref = c->cr;
ctrl->ev.proceeding.call = c->master_call;
return Q931_RES_HAVEEVENT;
}
{code}
was (Author: dav):
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)
More information about the asterisk-bugs
mailing list