Andre Edmonson (Ross) reviewed his Element Status Code Document with updates since the IBC meeting.
Group Discussion on Document, QC on media etc.
Some suggestions to segment MOS group approved status codes on decimal, or “50” numeric boundaries.
Suggestions to add in some additional sample codes and Status Names before our next call.
Suggestions and discussions by the group to take place in the Slack Workspace, #Proposals Channel.
Johan Nyman (Superfly.TV) gave a brief overview of his pending proposal for message grouping and deferment. Johan will post a more detailed discussion in Slack.
Possibility for a December 15th meeting discussed, otherwise we’ll wait till the February 2020 meeting as scheduled.

December 11th Meeting Notes

A very short meeting, only four attendees total.
Noted AP’s addition/suggestion to the MOS Status Codes from ESPN.
Noted Johan Nyman’s (Superfly.tv) “Defer and Commit Proposal”.
Noted Kai Kaup’s (Scisys) “Experiences & Comments on MOS Profile 7”. This one is certainly a complicated topic, and will need more discussion and thought on possible ways to tackle these issues.

IBC 2019 Meeting

audio link
Audio recording of the MOS Group Meeting at IBC 2019

When: 16 September 2019 (Monday)
Time: 16:30 – 18:30 CEST
10:30 – 12:30 US-EDT
07:30 – 09:30 US-PDT

Where: The RAI Elicium – Room G-109. The RAI Elicium building is in Area 13 which is centrally located within the exhibit halls (between hall 2 and hall 10).

(Click for a larger version)

IBC 2019 Agenda:

Activity since NAB
MOS 4.0 Final Documents Posted
MOS “Float” Proposal
- Float Proposal Document
MOS “Status” Proposal
- Item Air Status Proposal Document
“In-Between” Meetings
NAB 2020 Meeting Date
Any Other Business

IBC 2019 Meeting Notes

MOS Group Workspace now running in Slack
MOS v4.0 Documents Posted, no revisions required at this time
Two “In-Between Meetings” since NAB, will continue them
Significant interest in Profile 7 noted, members will contribute additional comments in the Slack Workspace.
MOS “Float” Proposal Accepted by the group as written, will add into the next version of MOS, as other proposals are also pending additional discussion.
MOS “Status” Proposal. Significant discussion. Needs updates to the proposal documentation and then further discussion before adoption.
NAB MOS Meeting will still be held on Tuesday.
IBC MOS Group Meeting expenses continue to rise, exploring alternatives to reduce cost.
Discussion on rendering engines and codecs for plug-ins. Embedded rendering engines should work the same as major browsers, Chrome, Firefox, Etc.

IBC 2019 Remote Participation:

Screenshare and VoIP:
https://ap.zoom.us/j/696033984?pwd=dUwwUXkwbEluWmtGNi9NK0diUjdodz09
Password: MOSGROUP

Voice bridge only:
+1.408.638.0968 (US)
+1.646 876 9923 (US)
+44 (0) 203.051.2874 (UK)
+31 (0) 20 794 0854 (Netherlands)

Meeting ID: 696 033 984

Additional international numbers available:
https://zoom.us/u/adrnrq4lWq

Post NAB 2019 Meetings

As discussed at the NAB Meeting, we will be starting up Bi-Monthly Discussion Meetings to enable progress on items of interest.

The next meeting is:
Wednesday July 24th, 10am EDT, 4pm CET

Information about the FLOAT and RO Element Status proposals is on the MOS Documentation Additional Documentation page.

See Andre Edmonson’s update to his STATUS proposal here.

July 24, 2019 Call – Remote Participation:

Screenshare and VoIP:

https://ap.zoom.us/j/219732192pwd=ZWJ1K3dDcjlZZ0ZJS2VQL045UWM5UT09
Password: MOSGROUP

Dial by your location
+1 646 876 9923 US (New York)
+1 408 638 0968 US (San Jose)
+44 203 051 2874 United Kingdom
+44 203 481 5237 United Kingdom
+44 203 966 3809 United Kingdom

Meeting ID: 219 732 192

Additional international numbers available:
https://zoom.us/u/adrnrq4lWq

May 22, 2019 Call – Remote Participation:

Screenshare and VoIP:

https://ap.zoom.us/j/528528650?pwd=WGZQQ1BGQUdybktwOEQrbUFURmZ2QT09
Password: MOSGROUP

Voice bridge only:
+1.408.638.0968 (US)
+1.646.876.9923 (US)
+44 (0) 20.3695.0088 (UK)
+31 (0) 20.241.0288 (Netherlands)

Meeting ID: 528 528 650

Additional international numbers available:
https://zoom.us/u/adrnrq4lWq0

NAB 2019 Meeting

When: Tuesday, April 9th, 2019
3:00 – 5:00 PM US-PDT (local time)
6:00 – 8:00 PM US-EDT
23:00 – 01:00 UTC

Where: Westgate Las Vegas Resort – Conference Rooms 7 and 8

NAB 2019 Agenda:

MOS v4.0 Industry Update
Open Source MOS Update
NAB 2020 MOS Meeting Dates

NAB 2019 Meeting Notes:

IBC 2018 Review
Discussion around MOS v4.0’s need for an additional status tag, the group tabled the discussion, no decision was made.
Shawn Snider of Ross reviewed MOS version 4.0 and implementation experiences.
Open Source MOS Development project reviewed.
NAB MOS Meeting for 2020 will remain on Tuesday, though the show will now open on Monday. Date will be Tuesday, April 21st 2020.
Discussion of float vs delete and “float states”. Octopus & Aveco to provide more details for the group.
Discussion of a change to objPaths: currently it must link to a file, vendors want to change this so the path can point to a slash or a non-file path. No decision was made
objDur discussion for items. No decision made.
Discussion around HTML5 plugin best practices: use single page application implementation, CORS (link: https://en.wikipedia.org/wiki/Cross-origin_resource_sharing) should be enabled on the device server. CORS Does Ajax requests with headers.
A second discussion around status: this idea was “status forwarding” via an roStorySend message with an item status tag? Ross will take this discussion and create a proposal for future MOS meetings. The idea here was that the standard defined status messages within the MOS protocol need to be expanded to offer more descripted status messages to modern newsrooms.
The group decided against standardizing status color codes.
Discussion around itemID, should the itemID change or remain consistent during updates. While the MOS protocol does not specifically state, the group believes the itemID should remain constant across updates. There will be additional discussions and a change proposal coming in 2019/2020.
Suggestion by AP to have more frequent MOS meetings between NAB & IBC to help progress items.
Suggestion by AP to move the former MOS Forums to Slack. The MOS group now has a MOS Slack group.

NAB 2019 Remote Participation:

Screenshare and VoIP:
https://ap.zoom.us/j/951834314?pwd=ekZqUlFOQytZRnlnTERWTUVnUGRqZz09
Password: MOSGROUP

Voice bridge only:
+1.408.638.0968 (US)
+1.646.876.9923 (US)
+44 (0) 20.3695.0088 (UK)
+31 (0) 20.241.0288 (Netherlands)

Meeting ID: 951 834 314

Additional international numbers available:
https://zoom.us/u/adrnrq4lWq

IBC 2018 Meeting

When: 17 September 2018 (Monday)
Time: 16:30 – 18:30 CEST
10:30 – 12:30 US-EDT
07:30 – 09:30 US-PDT

Where: The RAI Elicium – Room G-109. The RAI Elicium building is in Area 13 which is centrally located within the exhibit halls (between hall 2 and hall 10).

(Click for a larger version)

IBC 2018 Agenda:

NAB Review
Open Source Development & MOS
MOS MEM Blocks Discussion
MOS Channels Discussion
MOS Secure Communications Proposal – Working Group Updates & Vote to adopt — See the latest update to the working document here: MOS-Security-and-Passive-Mode-via-Web-Sockets-v1.4
Any Other Business
MOS @ 20

IBC 2018 Remote Participation:

Screenshare and VoIP:
https://ap.zoom.us/j/789620246?pwd=eWpSVm5hQkcybGpXRC92MXJyTkhYdz09
Password: MOSGROUP

Voice bridge only:
+1.408.638.0968 (US)
+1.646.558.8656 (US)
+44 (0) 20.3695.0088 (UK)
+31 (0) 20.241.0288 (Netherlands)

Meeting ID: 789 620 246

Additional international numbers available:
https://zoom.us/u/egKZvg6cS

Secure Communications Working Group Meetings:

The purpose of these meeting was for the sub-committee to report out the latest iteration (Version 1.4) of the Proposal for adoption at the MOS Group’s meeting at IBC 2018. See this latest iteration (Version 1.4) here.

Notes from Secure Communications Working Group Meeting Three:

Via Zoom Teleconference

11 July 2018 — 11:00 am/US-Eastern Daylight

Participating:

Shawn Snider (Ross Video)
Phil Avner (AP)

Final Pre-IBC review and discussion of the proposal document from Shawn Snider (Ross Video) “MOS Encryption And Security via Web Sockets & MOS Passive Mode” Revision 1.4

Notes from Secure Communications Working Group Meeting Two:

Via Zoom Teleconference

13 June 2018 — 11:00 am/US-Eastern Daylight

Participating:

Shawn Snider (Ross Video)
Warren Davis (Bitcentral)
Randall Meston (AP)
Phil Avner (AP)
Bryan Girdler (AP)
Sean Cullinan (USV)
Mike Roscoe (BBC)

Review and discussion of the proposal document from Shawn Snider (Ross Video) “MOS Encryption And Security via Web Sockets & MOS Passive Mode” Revision 1.3

Mostly a cleanup of earlier versions, incorporating decisions of the Group from the previous conference call. Includes reworking of workflow diagrams.

Previous decision was that the version of MOS will be designated as MOS 4.

Discussion of whether this version will be called 4.8.x (following the numbering scheme of MOS 2.x) or 4.0 (to reflect a new baseline). Decision was made to designate it as 4.0.

Passive mode will be a required mandate going forward

It can be configured on the NCS or MOS side.

Implementation will be WebSockets over HTTPS.

SSL Certificates will be required.

They may be Self-signed or Untrusted.

A required part of the MOS header is a “Channel” identifier, as a reference to which legacy port the over which message would have moved (10540, 10541 or 10542).

Authentication will be HTTP Authorization headers using the “Basic” schema.

This keeps the authentication information out of the URL.

Every device must define an endpoint that will be used for communication with the device.

The format of the URL is up to the vendor.

The underlying “Two Ports/Four Sockets” topology remains intact.

The “KeepAlive” message (to keep firewall and other security barriers open, once authorized) is added to MOS Profile 0.

The message is maintained at the MOS “message” level.

It does not require an ACK or other reply.>

It does not require a MOS MessageID number.

This is the only change to the message structure from MOS 2.8.5.

There is no end-of-life date being set for MOS 2.x at this time.

About a dozen MOS messages which were deprecated in earlier MOS versions will not be a part of MOS 4.0 and beyond.

For reference only, the MOS Protocol document for version 4.0 will list the messages that are no longer supported as part of MOS 4. Each will be accompanied by an indication of what message has taken over its functionality.

Some vendors just want to write a “message forwarder” to onpass deprecated messages.

Concern (expectation?) that those NCS and MOS vendors will “migrate” to WebSockets for transport, but otherwise leave their MOS messages as-is. This would likely include some of those deprecated message types.

Vendors who are still on MOS 2.6 (after MOS 2.8 has been around for over a decade) may never be inclined to modernize unless customers demand it – Ex: for sending messages across the Internet.

In the MOS Protocol document, we need to make the language very firm.

Something like: “These messages are no longer in the specification. They are not to be used.”

Except for any essential clean-up, MOS 2.8.5 will be the last version of MOS 2.x.

Mike Roscoe: BBC looking at this in great detail

Next steps:

Shawn Snider has prepared one last write-through of the Proposal document. See it here.

We will have one more online call (early-mid July?) to review.

The Proposal document will be distributed and made available to all MOS Group members by early August.

An up-down vote on the Proposal will be conducted at the MOS Group’s meeting at IBC.

Following the anticipated approval at IBC, a full and complete MOS Protocol 4.0 specification will be written, incorporating all aspects of the adopted proposal.

Notes from Secure Communications Working Group Meeting One:

Via Zoom Teleconference

16 May 2018 — 11:00 am/US-Eastern Daylight

Participating:

Shawn Snider (Ross Video)
Mark Gilbert (Gallery)
Jim Stringer (Telescript West)
Mike Palmer (Masstech)
Warren Davis (Bitcentral)
Kai Uwe Kaup (SciSys)
Randall Meston (AP)
Bryan Girdler (AP)
Ryan Berg (AP)
Phil Avner (AP)
Mark Wilson (USV)
Greg Bouzianis (USV)
Sean Cullinan (USV)

Reviewing from MOS Group meeting at NAB 2018:

1. New version will be designated MOS 4.x.

Enables more clarity when deprecating MOS 2.x (no prefixes, suffixes, etc.).

2. Defer deprecation date for MOS 2.x.

Date to be determined after:
Adoption by the group.
Vendors release product that incorporates MOS 4.x.
There is building field deployment.

Passive Mode – Discussion

Recommendation has been made to force “PASSIVE” mode to be the default for MOS 4.x.
To accommodate firewall restrictions.
Both connections would be able to start on one side.
Makes cleaner for networking purposes.

No objections. Subject closed.

SSL Certificates – Discussion

There are valid reasons to support self-signed, as well as from established Certificate Authorities

Downside of CA-issued SSL certificates: The have an expiration date.

Proposal: All MOS devices and NCSes should support self-signed, as well as CA-issued SSL certificates.

There should be an option for an NCS user to disallow self-signed SSL certificates.
Would allow the user to determine how to operate – choose the desired level of security.
Would allow MOS to conform to RFP-style security standards.

Sean Cullinan: Some frameworks do not support self-signed certificates (or don’t support them well).

Problem seen most frequently when dealing with iOS devices.
May not be such an issue with server-to-server connections.
There is no way to be sure that the certificate is correctly identifying.
Shawn Snider (Ross Video): There is generally a way to work around this problem.
iOS device issues should not be important for server-to-server connection applications.
Sean Cullinan: Should devices be required to support “untrusted” certificates?

Buying a “real” CA-issued SSL certificate for every test situation could prove to be a financial hardship.

Mike Palmer (Masstech): There is a project to get free signed certs.
Available at: https://letsencrypt.org
Certificates have short lives, but can be auto-renewed.
There can be problems if auto-validation if if your DNS is behind a firewall
– or if you don’t own the root name of the URL.

Keep-Alive Messages – Discussion

Messages are required to keep a connection available where a firewall or other security barrier times out relatively quickly.

Proposal is for a “Keep-Alive” Layer – This is different from MOS heartbeats.

Shawn Snider: MOS Heartbeats get into the control chain. He has seen problems with them – especially with Heartbeat responses.

Keep-Alive message are especially important in Passive mode.
Proposes a very lightweight Keep-Alive message.
Keep-Alive messages should be constrained to the Transport-level – not command-level.
The Keep-Alive messages should not get into the MOS control stream.

Interval of Keep-Alive messages should be configurable – but generally in the range of 20-30 seconds.

Most networking stacks time out at about one minute.

Use of MOS Heartbeat messages would remain unchanged.

Sean Cullinan: SignalR has built-in Keep-Alive. Doesn’t know if other libraries includes that.

https://docs.microsoft.com/en-us/aspnet/signalr/overview/guide-to-the-api/handling-connection-lifetime-events

https://github.com/SignalR/SignalR/wiki/Configuring-SignalR

Excerpt:

KeepAlive

This setting represents the amount of time to wait before sending a keepalive packet over an idle connection. The default value is 10 seconds. This value must not be more than 1/3 of the DisconnectTimeout value.

If you want to set both DisconnectTimeout and KeepAlive, set KeepAlive after DisconnectTimeout. Otherwise your KeepAlive setting will be overwritten when DisconnectTimeout automatically sets KeepAlive to 1/3 of the timeout value.

If you want to disable keepalive functionality, set KeepAlive to null. Keepalive functionality is automatically disabled for the long polling transport.

KeepAlive – Representing the amount of time to wait before sending a keep alive packet over an idle connection. Set to null to disable keep alive.

This is set to 30 seconds by default. When this is on, the ConnectionTimeout will have no effect.

Shawn Snider: Keep-Alives are not necessarily part of other libraries.

What should be the format of Keep-Alive?

Should it be a simple string or a conforming, legal, XML block?

Shawn Snider: Advantage of simple string (i.e.: NOT XML), is that it force the message to be transport-level, rather than command-level message.

Sean Cullinan: SignalR will send a simple open-clurly-brace and close-curly-brace, unless something else is implemented.

https://blog.3d-logic.com/2015/03/29/signalr-on-the-wire-an-informal-description-of-the-signalr-protocol/

Excerpt:

KeepAlive messages

KeepAlive messages are empty object JSON strings (i.e. {}) and can be used by SignalR clients to detect network problems. SignalR server will send keep alive messages at the configured time interval. If the client has not received any message (including a keep alive message) from the server within a certain period of time it will try to restart the connection. Note that not all the clients currently support restarting connection based on network activity (most notably it is not supported by the SignalR C++ Client). Sending keep alive messages by the server can be turned off by setting the KeepAlive server configuration property to null.

Keep-Alive is only sent by SignalR if no other traffic has moved across the channel – it keeps track.

Sean Cullinan: Does not like just sending the curly braces. The sender is not identified.

Shawn Snider: Should be a well-defined format that prevents Keep-Alives from getting passed to system’s MOS engines – where they need to be handled.

RE: XML: Shawn Snider is concerned that there could be too many variations of how a system would send what-should-be a well-defined Keep-Alive message – that can be trapped at the transport layer.

Example:

Would all be XML-legal ways of saying the same thing.

A proper XML parser would understand any of them to be the same.

However… A simple character string parser would require if/or trapping.

Suggested specifying ONLY ONE of them as correct and legal as a MOS 4 Keep-Alive.

Mark Gilbert: Concern about sending MOS and something-other-than MOS down the same transport stream.

Would the MOS messages need to be wrapped to identify them as MOS to have them forwarded?

Wrap the Keep-alive differently?

Sean Cullinan: Make a keep-alive like a heartbeat, but don’t require a reply.

Mark Gilbert: Suggests making it more generic.

There could eventually be other additional non-MOS communication (ex: authentication or side-channel metadata) that should move in the same transport stream connection.

Build a messaging structure that accommodates MOS and other-than-MOS messages. Something that can carry more than just the single MOS protocol.

Either the MOS Protocol should include the keep-alive, or the transport should be well designed to carry messages of varying protocols.

Shawn Snider will look at the addition of a MOS KeepAlive message, which does not require a reply, as an option.

Authentication – Discussion

Kai Uwe Kaup (SciSys) previously contacted Shawn about Authentication

He commends these two posts:
https://stackoverflow.com/questions/2629222/are-querystring-parameters-secure-in-https-http-ssl
http://blog.httpwatch.com/2009/02/20/how-secure-are-query-strings-over-https/

Shawn Snider: Intentionally did not describe Authentication schemes in his proposal – leave it up to implementing organizations to decide.

Shawn had suggested including authenticating arguments/credentials in the URI.

This is inherently secure – within the scope of how these messages are intended to be used.

Kai raised three issues:

1. URIs with concatenated credentials could be saved in browser history logs.
2. Can be intercepted within HTTP referrers.
3. Can be intercepted in server-side or proxy logs – if a proxy server is unwrapping and re-wrapping the HTTPS call.

Shawn Snider: First two issues are not relevant, because these call will not be used in a browser environment.

Server log vulnerability could be valid.

Credentials could be included in the HTTP header. Use standard HTTP header fields. Would require username and password, or token.

Mike Palmer: Hitting it with a browser would show a log-in prompt with a demand for credentials.

Not that anyone should be doing so, but it would too-easily expose the security strategy.

Sean Cullinan: JavaScript libraries do not support additional headers for WebSockets

https://stackoverflow.com/questions/4361173/http-headers-in-websockets-client-api

Basic Authentication *does* work.

Mark Wilson: Organization for storing/managing credentials?

Concerned about too many different standards for an NCS vendor to support.

Shawn Snider: Would be dictated by each vendor.

Not part of the specification to dictate how NCS or MOS vendors would do so.

Kai: SciSys practice to is never store usernames and passwords in clear text in their systems.

Discussion of what is means of authentication username/password vs. token (ex: Kerberos)

Consensus vote decision to put authentication in HTTP header, rather than concatenated in URI.

Standard Public Library

Mark Gilbert (Gallery) raises subject of one vendor to write a cross-platform library that everyone could use (similar to NewTek and NDI) to expedite adoption in the marketplace. As opposed to SMTPE standards that are very slowly adopted.

Suggests that it could be Shawn Snider and Ross Video.

Shawn says it would not fly, from a business perspective, at Ross.

A properly designed and deployed MOS interface is a competitive business/sales advantage for a vendor.

Mark: Each vendor having to design its own will greatly slow adoption of the new MOS version.

Deprecating MOS Commands

Shawn Snider: Since MOS 4.x is a new version of MOS, should we formally remove support for some deprecated messages?

Sean Cullinan: Making any more changes (beyond transport) would only further delay time to market.

Shawn Snider: Will think about this and perhaps make a proposal.

NAB 2018 Meeting:

When: Tuesday April 10th, 2018, 3:00 – 5:00 PM PDT (local time), 6:00 – 8:00 PM US-EDT, 23:00 – 01:00 UTC

Where: Westgate Las Vegas Resort – Conference Rooms 9 and 10 (Note: These are different rooms from last year but in the same general area.)

NAB 2018 Agenda:

MOS Secure Communications Update & Progress. Shawn Snider’s documentation and test notes are here:
NOTE: Due to scheduling issues, Sean was not able to attend. We are setting up another discussion on this topic for Wednesday May 16th 11:00am EDT. See details on the next MOS meeting page.

NAB 2018 Remote Participation:

For those unable to be part of the MOS Group meeting in person, we have a remote conference session available, details are below.

Screenshare and VoIP:
https://ap.zoom.us/j/766789957?pwd=UyjxpCOLgqQRRcfrEHBiIg
Password: MOSNAB2018

Voice bridge only:
+1.408.638.0968 (US)
+1.646.876.9923 (US)
+44 (0) 20.3695.0088 (UK)

Meeting ID: 766 789 957

Additional international numbers available:
https://ap.zoom.us/zoomconference?m=zG6GouikSOlwbhqmYogx0Wzz3by0jC5x

IBC 2017 Meeting

When: 18 September 2018 (Monday)
Time: 16:30 – 18:30 CEST
10:30 – 12:30 US-EDT
07:30 – 09:30 US-PDT

Where: The RAI Elicium – Room G-109. The RAI Elicium building is in Area 13 which is centrally located within the exhibit halls (between hall 2 and hall 10).

(Click for a larger version)

IBC 2017 Agenda:

NAB Review
MOS Secure Communications Update & Progress — See Shawn Snider’s UPDATED working proposal here.
The Evolution of MOS in File-Based Workflows — See Mike Palmer’s proposal here.
Any Other Business

IBC 2017 Remote Participation:

Screenshare and VoIP:
https://ap.zoom.us/j/695803345?pwd=00DP8eh1D5U
Password: MOS2017

Voice bridge only:
+1.408.638.0968   (US)
+1.646.558.8656   (US)
+44 (0) 20.3695.0088   (UK)
+31 (0) 20.241.0288   (Netherlands)

Meeting ID: 695 803 345

Additional international numbers available:
https://ap.zoom.us/zoomconference?m=QAgXVXozf_B3ziVl434V8sSMstPVc4rG

NAB 2017 Meeting:

When: Tuesday April 25th, 2017, 3:00 – 5:00 PM PDT (local time), 6:00 – 8:00 PM US-EDT, 23:00 – 01:00 UTC

Where: Westgate Las Vegas Resort – Conference Rooms 7 and 8.

NAB 2017 Agenda:

IBC 2016 Review
MOS Emmy® Award
MOS v2.8.5 Documentation
MOS Device Discovery
Encryption & Security
Alternative Transports (Secure Web Socket Tunnel)
MOS Passive Mode

NAB 2017 Meeting Notes:

Digital Rights Management

Mike Palmer (Masstech): Mike presented the proposal to SMPTE, who liked it. SMPTE would like the MOS group to continue work on it. They see the scope of the proposal as being too narrow for the rest of SMPTE.

Mike will provide an updated copy of the proposal for the MOS Group website.

MOS 2.8.5

A draft for the revised specification has been posted on the MOS Group website.

Group members are encouraged to review it and provide comments to Phil Avner (pavner@ap.org).

Emmy Award

Displayed in the center of the meeting table.

Randall Meston (AP) said that NATAS still needs to vet the individual awards.

The group gave a hearty round of applause to the three designated individual award winners.

For others who would like an official NATAS plaque for the award, requests should go to Randall promptly. There is a charge for the plaques, which will be the responsibility of the individual requesting it. There are three offerings for the plaque. Randall recommends the “Executive” one.

New Business:

MOS Device Discovery
Shawn Snider (Ross) proposed a means for a media server to “self register” with a newsroom system. It would configure itself with the newsroom system.

Shawn characterized it as creating a dynamic ecosystem.

As more devices move to a cloud, resources move around frequently. It could become burdensome to have to frequently reconfigure systems.

With the anchor of a persistent ID, the systems should be able to reconfigure itself as needed.

Mark Gilbert (Gallery) suggested looking to the existing NMOS standard (http://nmos.tv/) or Apple’s Bonjour (https://developer.apple.com/bonjour/)

Mike Palmer noted that this had been discussed six-to-eight years ago. It was dropped because there was no business driver at that time. The environment has changed, and he now supports the idea.

There was discussion about the possibility of rogue systems trying to register themselves on users’ systems. There was general agreement that any standard for auto discovery/registration/configuration would be contingent on a human accepting any machine-initiated action.

Encryption and Security
As MOS messages move between sites, and especially to cloud-based systems, companies are more aware of security issues. There is no security in socket communications.

We discussed the idea of moving MOS socket communication inside SSL wrappers

There are several products available that wrap socket messages through a Port 443 encrypted channel.

Warren Davis (Bitcentral) reports that Fox has been requesting two-step authentication.

Concern was raised about the expense and work to use SSL certificates issued by major Certificate Authorities (i.e.: not self-generated certificates).

Could be any port (not tied to 443), though Port 443 is a well-known port for network administrators.

Mark Gilbert suggested looking at Hamachi (https://www.vpn.net/).

Jim Stringer (Telescript West) was concerned about reliance on third-party products that could be pulled from the market at any time.

There was general consensus around the idea that the MOS Group should not create yet another encryption standard. Rather, companies employing the MOS Protocols (media servers and newsroom system vendors) could certify one or more off-the-shelf solutions that users of MOS Protocol systems could reliably utilize themselves.

It was suggested that if a proposal is too complex there would be a low adoption rate.

Passive MOS
This proposal from Shawn Snider would be for something similar to Passive FTP, in that all MOS Protocol “conversations” would originate from the same (secure) side of a connection.

A MOS Protocol communication between two devices would be made up of two Passive MOS connections between the devices.

Mark Gilbert suggests that routing all MOS communication through a VPN tunnel (such as Hamachi) would obviate the need for the security that would be gained through a Passive MOS arrangement.

System Release Certification
Sean Cullinan (ENPS) raised the issue of the time it takes for MOS Protocol participating vendors to certify their products against other systems.

This results in our mutual customers delaying their adoption of new versions of products because of fear of issues arising from updated software.

Jim Martinolich (ChyronHego) says that most issues are around ActiveX plug-ins. Basic Newsroom system server to MOS device is much simpler and straight-forward.

Jim Stringer says that solutions need to work right directly out-of-the box.

Mike Palmer suggests that in self-registration processes, only specifically approved versions of software be allowed to work together.

It was discussed that there should be specific test procedures and regimens (designed to be automatable) that would be the gold standard for certifying compatibility.

Jim Stringer said that, as a MOS device vendor, he sees differences in MOS Protocol implementation among newsroom system vendors. As an example, Jim cited a difference between ENPS and Octopus in use of Story Numbers.

Eira Monstad (Vizrt) says that most problems arise from procedures (or sequences of MOS messages), not from individual malformed messages.

Working groups were suggested for Device Discovery, Encryption & Security and Release Certification topics.

Old Business

Floated Stories
Shawn Snider raised again his earlier proposal for a means to differentiate between when a story/media object is truly removed from a Running Order, and when it is floated.

In the latter case, there is a likelihood that the story/media object will be returned to the active Running Order. Object and status updates for a floated story or object should continue to be handled, in anticipation of its return to active status in the Running Order.

In an earlier meeting, the subject became, in Shawn’s opinion, overly complicated.

Shawn would like to lead a group to reexamine the proposal.

Acknowledgement Messages
The question of the meaning of Ack was raised again.

Should a device sending an Ack message mean that the message to which it is responding has arrived, and (optionally) been vetted for valid formatting?

Or should the Ack message mean that the MOS device receiving the MOS Protocol message has successfully completed handling the incoming message?

In the first case, an Ack message may be sent when there was actually some problem with the information contained in the original message – which would not be discovered until the MOS device has tried to do whatever-it-needs-to-do with the information. This could necessitate that a subsequent message be sent to verify operation – or more importantly, tell the originating system that the requested action could NOT be fully executed.

In the second case, operations are held up and other systems get out of synch because other work has continued while waiting for the Ack message to arrive.

Different vendors have implemented in different ways. This creates a problem for our systems and for our mutual customers.

It is proposed that we come to a definitive meaning for the Ack message.

Heartbeats
Jim Stringer raised the question of what to do when there is no reply to a Heartbeat message. Especially in a communication string where there is intermingling of heartbeat and more-executive messages.

And related to that, since the correct reply to a Heartbeat message is another Heartbeat message, how do we formally state that this loop should not result in race condition of two devices sending and replying to Heartbeat messages with each other.

NAB 2017 Remote Participation:

For those unable to be part of the MOS Group meeting in person, we have a WebEx session available.

Address: http://enps.webex.com

Meeting number: 796 541 465

Meeting password: EMMY2017

Single-click: https://enps.webex.com/enps/j.php?MTID=mfc3aff407907035a385246527d5e8182

Voice Bridge:

US 1-650-3057453

UK 0 2034333870

Other global numbers: https://www.tcconline.com/listNumbersByCode.action?confCode=5662218711

Conference Code: 566 221 8711

IBC 2016:

When: 12 September 2016 (Monday)
Time: 16:30 – 18:30 CEST
10:30 – 12:30 US-EDT
07:30 – 09:30 US-PDT

Where: The RAI Elicium – Room G-109. The RAI Elicium building is in Area 13 which is centrally located within the exhibit halls (between hall 2 and hall 10).

(Click for a larger version)

IBC 2016 Agenda:

IABM Industry Collaborative Group (ICG) Endorsement
NAB 2016 Review
- NATAS – Waiting to hear back after voting
- News Distribution Rights
  - White paper (with no major changes) to be presented at upcoming SMPTE conference in LA
- Story Status Tag
- MOS item representations of IP Video streams
  - Document located at http://sienna.tv/mos
MOS Protocol Documentation Clarifications
- roElementAction
Any other business

IBC 2016 Remote Participation:

For those unable to be part of the MOS Group meeting in person, we will have a WebEx session available with audio bridge.

WebEx Screen Share:
https://enps.webex.com/enps/j.php?MTID=mf5489c972102baffed46806cf82404be

…or…

http://enps.webex.com
Meeting number: 795 557 374
Meeting password: C92DWDQ3

Audio Bridge:
650-3057453 (US)
0 2034333870 (UK)
0 207946543 (Amsterdam)

Access phone numbers elsewhere around the world:
https://www.tcconline.com/offSite/OffSiteController.jpf?cc=7077863143

Conference Code: 707 786 3143 #

Slide deck from the meeting can be seen here.

NAB 2016 Meeting:

When: Tuesday April 19th, 2016, 3:00 – 5:00 PM PDT (local time), 6:00 – 8:00 PM US-EDT, 23:00 – 01:00 UTC

NAB 2016 Agenda:

Review IBC 2015 Meeting
Story Status Tag

In many situations MOS devices would greatly benefit from the knowledge of stories that are “floated”. The proposal of “storyStatus” would no longer have the NRCS ignore these stories, rather it would send them out as part of the standard roConstruction messages with a new flag of “floated”.

See the StoryStatus proposal (PDF)

Proposal for News Distribution Rules

NDR is a proposed model of data representation and rules which allow a distribution point to determine if it is allowed to forward, redistribute or incorporate the described content in derivative works. Modeled on existing methods used for many years to control news distribution, this method adds the benefits of unambiguous rules and machine interpretation.

This is a suggested topic of discussion for the MOS Group because MOS enabled systems carry much of the content to which NDR would be applied. Thus, compatibility and synergy of MOS and NDR would be beneficial.

See the NDR Proposal (PDF)

NAB 2016 Meeting Notes:

1. HTML5

The HTML5 plug-in proposal was brought up for discussion and vote.

Vizrt (Via Ross Video) proposed amending the proposal to include a requirement that both HTTP and HTTPS be supported.

The amended text would be:

The NCS hosting container should allow connections via HTTP, or secure connections via HTTPS from pages in the plug-in browser components to back-end web servers utilizing SSL server certificates.

Any resources incorporated in the HTTPS page of a device plugin also needs to be served out over HTTPS in secure deployments. This includes, but is not limited to:

The full proposal, as amended, was adopted by acclamation.

2. Floating

Kurt Simons proposed changes to the process when “Floating” a story in a Running Order.

In addition to the use case made in Kurt’s proposal, the use case of floating a story because a linked media object is not ready – but a user still wants to be able to see status updates in the Running Order – was cited.

Also, related issues: floating just a media object and implications for redirection.

As this would break some old workflows, a new “full-dot” version number would be assigned to a MOS update with these changes.

Kurt will write up some examples for discussion by the MOS group.

3. Industry issues

Mike Palmer announced that IABM will nominate MOS to be a recognized protocol of the group.

Also that MOS has been nominated for a technical EMMY award.

4. NDR

Mike Palmer presented a proposal for News Distribution Rules – A standardized way to express rights usage rules for distributed media.

It would include breakdown by organization and to the segment level in edited clips.

Because lists of included and excluded users could get long, the proposal says that portions may be expressed in YAML or Base64.

Mike will provide some samples of how a variety of rights situations could be expressed in his proposed format.
After discussion on the MOS Protocol website forum, the hope is that we can hold a vote on this proposal at the MOS Conference at IBC later this year.

5. IP Video

Mark Gilbert raised the issue that the MOS Group should look at IP Video, and determine if/how the MOS Protocol should be updated to work with it.

Where: Westgate Las Vegas Resort – Conference Rooms 7 and 8.

NAB 2016 Remote Participation:

For those unable to attend the MOS Group meeting in person at NAB, remote access will be available live from anywhere in the world via WebEx.

Address:   http://enps.webex.com
Meeting number:        796 234 414
Meeting password:    MOSmeeting

Voice Call-in numbers:

(US) +1 650.305.7453
(UK) +44 203.433.3870
(Germany) +49 21197190097

Other world-wide numbers can be found at: https://www.tcconline.com/listNumbersByCode.action?confCode=7077863143

Conference Code: 707 786 3143

IBC 2015:

When: 14 September 2015 (Monday) Time: 16:30 – 18:30 CEST, 10:30 – 12:30 US-EDT, 07:30 – 09:30 US-PDT

Where: The RAI Elicium – Room G-109. The RAI Elicium building is in Area 13 which is centrally located within the exhibit halls (between hall 2 and hall 10).

(Click for a larger version)

IBC 2015 Agenda:

NAB 2015 Review
See Revision 2 of the proposed HTML5 Protocol document here.
Discussions regarding implementation of the HTML5 Plug In
- Comments from VizRT regarding implementation of the HTML5 plug in here:
- Discussion regarding UCS-2 vs. HTML5 Plug In and encoding
Discussion on mosAbstract being required vs. optional

IBC 2015 Remote Participation:

For those unable to be part of the MOS Group meeting in person, we will have a WebEx session available with audio bridge.

Login for WebEx video:

https://enps.webex.com/enps/j.php?MTID=m82c002723df9945f719432d6df4ddb0f

Alternate:
Address:        http://enps.webex.com
Meeting number:      793 919 863
Meeting password:    IBC2015

Voice Call-in numbers:

+1 6503057453 (US)
+44 2034333870 (UK)
+31 207946543 (Holland)
+49 21197190097 (Germany)

Other world-wide numbers can be found at: https://www.tcconline.com/listNumbersByCode.action?confCode=7077863143

Conference Code: 707 786 3143

NAB 2015 Meeting:

When: Tuesday April 14th, 2015, 3:00 – 5:00 PM PDT (local time), 6:00 – 8:00 PM US-EDT, 23:00 – 01:00 UTC

Where: Westgate Las Vegas Resort – Conference Rooms 7 and 8.

NAB 2015 Agenda:

IBC 2014 Review

HTML 5 supplement to ActiveX, group discussion and vote on adoption. See Revision 2 of the proposal [PDF].

Generic CG Item (Graphics Builder Object) group discussion. See the draft proposal [PDF].

Comments from PixelPower on the generic CG item proposal. See the comments from PixelPower [PDF].

Comments from VizRT on the generic CG item proposal. See the comments from VizRT [PDF].

Download the NAB 2015 MOS Meeting Presentation [PDF].

NAB 2015 Remote Participation:

For those unable to attend the MOS Group meeting in person at NAB, remote access will be available live from anywhere in the world via WebEx.

Address:   http://enps.webex.com
Meeting number:        794 514 747
Meeting password:    MOSCONF
Join by phone:
Call-in toll-free number: 1-866-235-4843 (US)
Call-in number: 1-650-305-7453 (US)
Conference Code: 707 786 3143

Dial-in numbers for other parts of the world.

IBC 2014:

When: 15 September 2014 (Monday) Time: 16:30 – 18:30 CEST, 10:30 – 12:30 US-EDT, 07:30 – 09:30 US-PDT

Where: The RAI Elicium – Room G-109. The RAI Elicium building is in Area 13 which is centrally located within the exhibit halls (between hall 2 and hall 10).

(Click for a larger version)

IBC 2014 Agenda:

Changes to the mosprotocol.com website (forums)
MOS Protocol 2.8.4 XSD corrections
Protocol Documentation corrections (use of quotes)
NAB 2014 review
- Standard vocabulary for objPath/objProxyPath Tech Descriptions (subgroup & discussion forum required?)
- Codifying that paths need to be direct paths to the object – not involve client-side redirection
- Codifying that objPaths and objProxyPaths end in file type extension
- Sub/daughter running orders
- HTML5 supplement to ActiveX discussion (subgroup & discussion forum required?)
New Business
- MOS standard for pushing content into graphics (subgroup & discussion forum required?)
- Can we define a better process to formally approve changes to the protocol?
Any other business

IBC 2014 Remote Participation:

For those unable to be part of the MOS Group meeting in person, we will have a WebEx session available with audio bridge.

——————–

NAB 2014 Meeting:

When:

Tuesday April 8, 2014, 3:00 – 5:00 PM PDT (local time), 6:00 – 8:00 PM US-EDT, 23:00 – 01:00 UTC

Where:

LVH – Conference Rooms 8 and 9.

(Click for a larger version)

NAB 2014 Agenda:

- Changes to the mosprotocol.com website
- IBC & NAB 2013 review
- MOS Protocol 2.8.4 XSD erratum
- Mac OsX paths addition to objPaths
- objPaths media representations discussion
- MOS Profile 7 – Clarification of itemID handling in response to roReqStoryAction
- MOS Profile 7 – Proposal for extension: roCreate from MOS system (discussion)
- Sub running orders
- “single-item” stories (items / objects in RO without story wrapper)
- Declaration of story types
- HTML5 supplement to ActiveX discussion

Download the NAB 2014 MOS Meeting presentation [PDF].

Download MOS Protocol Web Control Proposal Rev 2 [PDF].

NAB 2014 Remote Participation:

For those unable to be part of the MOS Group meeting in person at NAB, access will be available via WebEx.

Address: https://enps.webex.com/ Meeting Number: 798 883 117 Meeting Password: MOSNAB2014

Or you may use the login URL: https://enps.webex.com/enps/j.php?MTID=m4a7efb83638a1e9d5fe8c62cfd76ac2e

To view in other time zones or languages, please see: https://enps.webex.com/enps/j.php?ED=189933442&UID=1357243897&PW=NMThhNGZkNjg0&ORT=MiMxMQ%3D%3D

For audio only, join the telephone bridge: +1-650-305-7453 (US) You may find other global numbers at: https://www.tcconline.com/offSite/OffSiteController.jpf?cc=7077863143 Conference Code: 798 883 117

Assistance for the WebEx connection can be found at: https://enps.webex.com/enps/mc On the left navigation bar, click “Support”.

IBC 2013:

When: 16 September 2013 (Monday) Time: 16:30 – 18:30 CEST 10:30 – 12:30 US-EDT 07:30 – 09:30 US-PDT

Where: The RAI Elicium – Room G111 The RAI Elicium building is in Area 13 which is centrally located

Download the IBC 2013 presentation [PDF]

IBC 2013 Agenda:

- MOS Protocol enhancement: MOS formatting content for Graphics/CGs
- Successor to ActiveX
- Please take the opportunity to read this paper prepared by Shawn Snider of Ross Video prior to our meeting.

IBC 2013 Meeting Notes:

(Coming Soon)

NAB 2013:

When: Tuesday, April 9, 2013 3:00-5:00 local time (15:00-17:00 UTC-0700)

Where: Las Vegas Hotel (LVH) Conference Rooms 8 & 9

Download the NAB 2013 presentation [PDF]

NAB 2013 Agenda:

- roElementStat

Proposal to modify section 3.7.2 roElementStat – Status of a Single Element in a MOS Running Order Proposal is to add bi-directional aspect to roElementStat message. This would allow the NCS to make a MOS aware of status of a specified item or story relative to a particular Running Order.

- A consistent meaning for ACK

There has been discussion about how ACK sometimes means that a MOS message has been accepted and cleanly parsed (without regard for the instruction being successfully executed), and other times where an ACK means that an action has been taken before an ACK is returned. Should ACK have a consistent meaning?

- Rest/JSON

Last fall, following the IBC MOS meeting, there was a series of discussions about the prospect of adding a Rest/JSON version of MOS. This would complement the existing socket and webservices versions of the Protocol.

NAB 2013 Meeting Notes:

- roElementStat bi-directional aspect was formally adopted

- Object and proxy paths:
  1. Decided that the field should be a call that will return the file.
  2. Decided that the character string following the last slash should be the full file name including extension
  3. Discussion of whether to include additional field to designate MIME types
  4. Discussion of permissibility of HTTP client-side redirects was to be put up for discussion on the board

- Rest/JSON version of MOS:
1. 1. Consensus of the group was to table this proposal for now.