[asterisk-dev] Call unhold/topology change indication order

Joshua C. Colp jcolp at sangoma.com
Thu May 12 10:21:04 CDT 2022


On Thu, May 12, 2022 at 12:06 PM Fridrich Maximilian <M.Fridrich at commend.com>
wrote:

> Hi,
>
> I think I have found out why the indication order on hold/unhold matters:
>
> AST_CONTROL_HOLD/UNHOLD only cares about the audio stream and does not
> touch
> the topology of any other streams. So when Asterisk receives an SDP with
> audio
> and video and both are sendonly, chan_pjsip indicates AST_CONTROL_HOLD for
> the audio stream and AST_CONTROL_STREAM_TOPOLOGY_REQUEST_CHANGE for the
> video
> stream.
>
> If AST_CONTROL_HOLD is indicated after
> AST_CONTROL_STREAM_TOPOLOGY_REQUEST_CHANGE, it still has "outdated"
> topology
> information as it only cares about the default audio stream. So after the
> stream topology is changed, it is "overwritten" by the outdated topology
> from
> the hold/unhold indication.
>
> To resolve the issue, the topology request change needs to check if this is
> also a hold/unhold. If it is, there are two option:
>
> 1. Ensure that it executes after the hold/unhold indication
> 2. Ensure that the hold/unhold indication receives the updated topology
>
> I'm stuck on implementing either of those solutions. I think the place we
> need
> to work on is in bridge_channel.c:bridge_handle_trip() before the call to
> stream_topology_changed(). In bridge_handle_trip() we might still have a
> chance
> to interact with the other channel(s) in the bridge.
>
> Does anyone have any idea on how to proceed?
>

Not off the top of my head. I will try to give this some thought but I
don't know if/when I'll really have any thought, it's not something that
can really be answered without digging in deeply and refreshing memory on
the entire view of everything.

-- 
Joshua C. Colp
Asterisk Technical Lead
Sangoma Technologies
Check us out at www.sangoma.com and www.asterisk.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-dev/attachments/20220512/f0ada374/attachment.html>


More information about the asterisk-dev mailing list