[asterisk-dev] chan_sip and early media
Valter Nogueira
valter at fastway.com.br
Tue May 2 18:59:22 CDT 2017
I am using AMI to originate
Action: Originate
Channel: SIP/5511996175361 at UPVOX
Context: FD_106_010_INICIO
Earlymedia: 1
ActionID: CALL_42240
Exten: s
Priority: 1
Async: 1
Timeout: 55000
Context FD_106_010_INICIO starts an FASTAGI program which starts an app
that just waits for* f->subclass.integer == AST_CONTROL_ANSWER*
if (f->frametype == AST_FRAME_CONTROL) {
if (f->subclass.integer == AST_CONTROL_ANSWER) {
ast_frfree(f);
break;
}
}
If I issue a *hangup request* on that channel, follow is *true*!
if (!(f = ast_read(chan))) {
break;
}
But looking at SNGREP the call is in SETUP.
I changed sip_hangup to inspect values
ast_verb(3, "************** HANGUP 14.1 %d < % d - %d != %d \n",
p->invitestate,INV_COMPLETED,ast_channel_state(p->owner),AST_STATE_UP);
and *ast_channel_state(p->owner) was equal to AST_STATE_UP*
This avoids *needcancel = TRUE* and therefore SIP doesn't send a CANCEL to
SIP PROVIDER
For tests only, I removed the check over channel state and CANCEL have been
sent to SIP PROVIDER.
Atenciosamente,
2017-05-02 18:52 GMT-03:00 Joshua Colp <jcolp at digium.com>:
> On Tue, May 2, 2017, at 06:47 PM, Valter Nogueira wrote:
> > I am originating call using early media option.
> >
> > Whe I issue a hangup (like in hangup request sip/...) before the b-leg
> > answer, it don't send a SIP CANCEL and the call keeps going on.
> >
> > I figured out that it is happening due to sip_hangup() checks:
> >
> > * if (p->invitestate < INV_COMPLETED && ast_channel_state(p->owner) !=
> > AST_STATE_UP) {*
> >
> > * needcancel = TRUE;*
> > * ast_debug(4, "Hanging up channel in state %s (not UP)\n",
> > ast_state2str(ast_channel_state(ast)));*
> > * }*
> >
> > And *ast_channel_state(p->owner) == AST_STATE_UP*
> >
> > I guess that early media option puts channel state in AST_STATE_UP
> >
> > So, is there a way to not set up channel state to *AST_STATE_UP* in early
> > media? Or the state check could be removed?
>
> Early media doesn't change the channel state to AST_STATE_UP. This only
> occurs if the channel is actually answered. I'd suggest providing more
> details about the precise scenario including any dialplan.
>
> --
> Joshua Colp
> Digium, Inc. | Senior Software Developer
> 445 Jan Davis Drive NW - Huntsville, AL 35806 - US
> Check us out at: www.digium.com & www.asterisk.org
>
> --
> _____________________________________________________________________
> -- Bandwidth and Colocation Provided by http://www.api-digital.com --
>
> asterisk-dev mailing list
> To UNSUBSCRIBE or update options visit:
> http://lists.digium.com/mailman/listinfo/asterisk-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-dev/attachments/20170502/04c5e370/attachment-0001.html>
More information about the asterisk-dev
mailing list