AMWA-TV/is-11

We need to capture unique source-sender lifecycle events and give hints to a controller

cristian-recoseanu opened this issue · 4 comments

cristian-recoseanu commented

Identified scenarios:

  1. Sender changes outside media profiles -> updates NMOS resource version numbers (source, flow, sender), updates SDP file and
    stops the stream with Master Enable = false but also returns 205 (ResetContent) for /media-profiles GET request and returns no content in the body

  2. Sender changes within media profiles -> updates NMOS resource resource version numbers (source, flow, sender), updates SDP file and stops the stream with Master Enable = false

cristian-recoseanu commented

Is there a scenario 3 where:
The IS-11 Sender receives new media profiles and changes flow so it then
updates NMOS resource version numbers (source, flow, sender), updates SDP file and
stops the stream with Master Enable = false

Basically should we say whenever the flow changes the Master Enable flag should be set to = false and the stream stopped?

cristian-recoseanu commented

After a very interesting discussion with @garethsb he pointed out that maybe the receivers should actually try to handle changes in the stream and indicate whether they have a problem by:

  • Setting master_enable to false
  • Resetting the receiver subscription to null to indicate it has disconnected

I think this behaviour fits well with changes to the flow in the scenario when the IS-11 sender still operates within the allowed media profiles. It also allows dynamic receivers to continue operating.

However I think still think the IS-11 source/sender operating outside the media profiles range given should be treated as an error on the sender side and the sender should follow the scenario mentioned in the first comment:

  • Device updates NMOS resource version numbers (source, flow, sender), updates SDP file and stops the stream with master_enable set to false but also returns 205 (ResetContent) for /media-profiles GET request and returns no content in the body.

What does everyone think?

prince-chrismc commented

Let's focus on the second scenario in #50 (comment)

the receivers should actually try to handle changes in the stream

What if it can not detect the change? Introspecting the 2110 stream might not be feasible

It's definitely worth considering... If we do one of

  • the controller SHALL update the receiver with the SDP (for those are not able to self correct)
  • Toggle sender off/on (obvious signal) and add an IS-05 ext_sdp_href on the Receiver (so it can get a new copy and reconfigure itself)

It covers a lot of use cases and permits smart devices to differentiate themselves 🤔

Perhaps, this is out of scope until we handle "Hot-Plug Detect" in a future activity and the status quo in NMOS is sufficient?

N-Nagorny commented

Closed because it's all covered by States of Sender/Receiver.