[asterisk-dev] SIP reinvite back to asterisk during async_goto

[Steve Davies]

2008/9/18 Tony Mountifield <tony at softins.clara.co.uk>:
> In article <5caa9b870809180837t794ee553h31b9e6b6be6fa832 at mail.gmail.com>,
> Steve Davies <davies147 at gmail.com> wrote:
>>
>> I am trying to put together an app to do essentially the same as the
>> Manager "Action: Redirect" operation, so that 2 channels in a bridged
>> call can be bounced off into the dialplan to do their own thing.
>>
>> It is ALMOST working. The code is not complicated after-all, it runs
>> ast_async_goto(...) on the 2 halves of the bridge once they've been
>> identified. If I set canreinvite=no, or if the call is a SIP<->ZAP
>> call, it works 100%.
>>
>> The problem is if I have a reinvited SIP<->SIP call, then chan_sip/rtp
>> never seems to reinvite the call back to Asterisk, so the audio paths
>> which are subsequently set-up are all over the place. "show channel
>> ..." shows that the channel has been "un-bridged", but the rtp code
>> never seems to be called :( I also tried to send an AST_CONTROL_HOLD
>> to the channel before doing the async_goto, in the hope that this
>> would cause asterisk to grab the call before I do the goto, but it
>> seems to make no difference - Probably because I do not release the
>> channel lock between sending the HOLD, and doing the async_goto.
>>
>> Any suggestions - I am running a Frankenstein version of asterisk, so
>> it is possible this has already been discovered and fixed in a future
>> version.
>
> My first question would be: does Manager "Action: Redirect" do it
> properly on a reinvited SIP<->SIP call?
>
> If so, I guess you just need to compare your logic with its logic
> step by step.
>
> If not, it would be a more fundamental problem in Asterisk.
>
> Apologies if I'm just stating the obvious.
>
> Cheers
> Tony


Good question - I cannot explain why, but I get one of the channels
hanging up when I try to do this using the manager interface... ie. a
completely different and unexpected result.

I am probably doing something wrong.

I have on the onther hand discovered more about what is happening:

Assume chanA is the main channel, and chanB is the bridged channel.
For async_goto to operate on chanA, it simply does a goto_explicit on
the channel, and then sets flags for a "partial-hangup" so that the
dialplan continues on its way. In order to clean-up, this will
generally cause the bridge channel chanB to be destroyed (it created
it, and owns it after all!) so if we are doing async_goto on chanB,
then asterisk ensures that we have "stolen" (masq'ed) chanB out from
under chanA, and starts the PBX code on that masq'ed copy channel.

Nothing unexpected.

The problem is that when the native bridge (redirected SIP) sees the
chanA hangup, it tries to revert the reinvite back to asterisk - Sadly
chanB has been stolen from it, so it can no-longer signal that half of
the native bridge back to asterisk!

What I need is a way of signalling the native bridge to end, then
waiting for it to complete before I do the async_goto calls. Or
perhaps signalling the calls to be in a HOLD state, and waiting for
that to complete (again, how do I know the HOLD command has been
executed?)

Hmmm....
Steve