On Wed, May 11, 2022 at 9:54 AM Joshua C. Colp <jc...@sangoma.com> wrote:

> 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

I too would be hesitant in doing a straight revert of the patch. I think at
this point a new patch would be needed that fixes the newly reported bug (
ASTERISK-30051), but also maintains the current behavior of ASTERISK-28783
in some way.
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

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

Reply via email to