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

Fridrich Maximilian M.Fridrich at commend.com
Thu May 12 00:47:03 CDT 2022


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

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

I think you're right, I might have jumped the gun a bit on this one. Having
reflected streams is what allows us to have one-way video in the first place.
So I'll continue working on ASTERISK-30051.

Thank you for the quick feedback.



More information about the asterisk-dev mailing list