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

2022-05-12 Thread Joshua C. Colp
On Thu, May 12, 2022 at 12:06 PM Fridrich Maximilian wrote: > Hi, > > I think I have found out why the indication order on hold/unhold matters: > > AST_CONTROL_HOLD/UNHOLD only cares about the audio stream and does not > touch > the topology of any other streams. So when Asterisk receives an SDP

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

2022-05-11 Thread Kevin Harwell
On Wed, May 11, 2022 at 9:54 AM Joshua C. Colp 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

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

2022-05-11 Thread Joshua C. Colp
On Wed, May 11, 2022 at 11:50 AM Fridrich Maximilian 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

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

2022-05-11 Thread Joshua C. Colp
On Wed, May 11, 2022 at 11:50 AM Fridrich Maximilian 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

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

2022-05-11 Thread Joshua C. Colp
On Wed, May 11, 2022 at 8:54 AM Fridrich Maximilian wrote: > Hi, > > I am currently working on fixing [ASTERISK-30051] res_pjsip: No video > after un-hold with moh_passthrough=yes. [1] > > I have debugged the code with DEBUG_THREADS enabled (which resolves the > issue) > and without and compared