On Wed, May 11, 2022 at 11:50 AM Fridrich Maximilian <m.fridr...@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
-- _____________________________________________________________________ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
