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

Kevin Harwell kharwell at sangoma.com
Wed May 11 17:55:23 CDT 2022


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

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

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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-dev/attachments/20220511/71410caf/attachment.html>


More information about the asterisk-dev mailing list