On Thu, May 12, 2022 at 12:06 PM Fridrich Maximilian <m.fridr...@commend.com>

> 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
> video
> stream.
> If AST_CONTROL_HOLD is indicated after
> 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
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:

Reply via email to