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

[Joshua C. Colp]

On Wed, May 11, 2022 at 11:50 AM Fridrich Maximilian <M.Fridrich at commend.com>
wrote:

> > You're in off-nominal untested un thought of territory, so the code
> behavior
> > probably reflects that. Specifically having both audio and video, and
> doing
> > hold/unhold. Audio hold is special and separate from stream negotiation,
> > while video isn't, so things probably don't handle that.
>
> Considering that, I would like to have a discussion about considering
> reverting
> ASTERISK-28783 [1]. This change showed that the handling of non-default
> streams
> is not mature enough yet to be used in production environments.
> Specifically,
> one-way streams and hold/unhold are not handled correctly. In order to keep
> Asterisk reliably usable for many different use-cases (Swiss Army Knife), I
> would suggest reverting this change for now until the handling of
> non-default
> streams is mature enough to handle more than just the most basic use-cases.
>
> Please let me know what you think about this suggestion.
>

Oh, that's my change from long ago. That change has existed in the code
base for quite a long time. It's not something that can likely just be
reverted, and I'd be hesitant in doing so. It would also require disabling
the test coverage for it too I think. It could also cause ripples
elsewhere. I'd be against it.

Thoughts from others?

-- 
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/20220511/148968f5/attachment.html>