Connect a Sender and Receiver of a transport with no parameter list

[lhoward]

Connecting a Sender to a Receiver fails for any transport that makeConnection has no parameter list for. With a manufacturer transport (which IS-05 v1.2 allows), the Connections matrix and the Receiver's Connect tab both show:

TypeError: undefined is not an object (evaluating 't.forEach')

and no PATCH is sent. oneToOneTransportParams[transport] is undefined for such a transport and copyTransportParams iterates it.

Changes

• Copy the shared parameters for a transport with no list. For such a transport, each parameter that the Sender's active transport_params and the Receiver's staged transport_params both have is copied across. RTP, MQTT, WebSocket and MXL keep their lists and behave as before.
• Send the copied values as they are. The Receiver UPDATE turns a string that reads as a number into a number, which suits a value typed into a text input. A value copied from the Sender already has the right type, so makeConnection now marks its request verbatim and the conversion is skipped for it. Without this, a string parameter whose value is "11" is sent as 11, and "05" as 5. Edits made through the forms are converted as before.

Testing

• New unit tests for both changes (makeConnection.test.js, and UPDATE receivers in dataProvider.test.js); yarn test and yarn lint-check pass.
• Tested against two hardware Nodes with a manufacturer audio transport whose Senders and Receivers share two string parameters: connections made from the Connections matrix are activated.

🤖 Generated with Claude Code

https://claude.ai/code/session_01T8cahEd4GfsHQ89sNrmP4p

[garethsb]

With a manufacturer transport

Do tell! 😁

Ah! https://www.linkedin.com/feed/update/urn:li:activity:7511611534075166721/

[lhoward]

With a manufacturer transport

Do tell! 😁

Ah! https://www.linkedin.com/feed/update/urn:li:activity:7511611534075166721/

Indeed :) Milan, too, but not yet tested.

[garethsb]

Hey, @lhoward, thanks for this (and pushing the new IS-05 v1.2 envelope with a vendor transport!).

I agree the failure is real: for a transport with no entry in oneToOneTransportParams, copyTransportParams iterates undefined and nothing is PATCHed. Same-name copy is a good rule, and it is already what ext_ parameters do. Of the four transports makeConnection handles explicitly, it is also already the whole of the WebSocket behaviour (connection_uri, connection_authorization).

It is the wrong fallback for the other three, and any future transport with similar complexity in its parameters:

• RTP copies destination_ip to multicast_ip or interface_ip, and disables a spare leg. source_port is deliberately left alone.
• MQTT copies destination_host and destination_port to source_host and source_port.
• MXL copies mxl_flow_id and sets mxl_domain_id to "auto". Copying the Sender's domain id is the case that block is there to avoid.

So my feeling is that a transport should be opted into this, with a flag on its TRANSPORTS entry, alongside the label. A label by itself would not be sufficient: DASH is already in the register and has no parameter handling. Anything else, makeConnection should refuse before it PATCHes. (Setting sender_id, master_enable and activate_immediate and leaving transport_params as they were would not be sufficient to make a connection.)

The Active and Staged tabs should follow the same flag. They currently render "Unknown Type", so the parameters just written cannot be seen or edited. An opted-in transport should get a generic card per leg, with each key labelled from its name. The explicitly handled transports would keep the cards they have.

I'll open a follow-up from this branch. It will also tidy getSharedParams: it returns key names, and it can use the same merge-and-keys as getExtParams. ext_ parameters stay on their existing path.

Your verbatim on the makeConnection update looks good to me: those values already have the Sender's types, and a string such as "11" must not be sent as a number. Form edits though... hmm... need to think about that.

[lhoward]

As long as I can opt into this behaviour, sounds good :)

FWIW we are using urn:x-nmos:transport:dante and urn:x-nmos:transport:milan (I suspect I am trampling on a reserved namespace here, but this is an internal PoC at this point). For Dante, the transport parameters are device_name and channel_name, both strings; for Milan, entity_id (a string of 16 hex digits) and stream_index (an integer).

[garethsb]

Yeah, I guess as a good citizen you probably want urn:x-padl:transport:xxx for now!

My proposal for opt-in would involve making a one-line addition to the code for each new transport. Not sure whether that's too much friction.

[garethsb]

Deleting comment from my over-eager 🤖 buddy, mostly repeating what I said above!

[garethsb]

The complexity of adding generic client-side support for unknown transports without having access to their schemas is mostly about whether any transport parameter supports null or if non-string parameters support "auto". In that case you really have no way of knowing how to edit the values. This is independent of the ability to connect using a basic one-to-one mapping, but nmos-js would feel incomplete if it supported connect but not edit?

FWIW, we had to handle this rough part of IS-05 v1.2 in nmos-cpp make_constraints_schema. It walks /constraints, then wraps a parameter with "auto" or null only when its name is in a transport-specific set such as rtp_auto_constraints or mxl_null_constraints. Those sets are hard-coded based on the JSON schemas, they can't be derived from /constraints. For RTP, "auto" is allowed on addresses and ports. null is valid for the MXL id parameters. There are several boolean and integer properties that also support the string "auto".

A generic card can show the current JSON value by its runtime type: a string, a boolean, or a number. It cannot tell, in the edit view, when the value is null or when the user clears a field, what type to write back, or whether "auto" or null is legal. That knowledge is not in the parameter name or in /constraints.

[lo-simon]

Thank you, @lhoward and @garethsb, for your contribution. This is now covered by #190.