On Wed, May 11, 2022 at 11:50 AM Fridrich Maximilian <m.fridr...@commend.com>

> > 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.

What was the behavior before and after in the various cases, that we should
consider reverting it?

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