Queries related to Uplink spec

[Sriram Bhetanabottla]

1. [Specification Text] Each camera shall use an individual ascending interval strategy to avoid that all cameras connect at the same time.
   • How is this possible unless camera A knows the pattern of camera B?
     • Unless this pattern configurable from client into devices? OR
     • depends on implementation and hence may be out of scope?

2. [Specification Text] If the uplink list contains multiple entries the device shall try to establish all connections in parallel.

   • Isn't this device/implementation dependent behavior to do it parallel or sequential?

3. [Specification Text] Since http/2 streams may be closed by either side when the content-length has been reached clients shall use a value large enough for the connection life time.

   • Unclear about the dependency of content-length over connection life time?
     • The Content-Length header is not used in HTTP/2, as the length of each individual frame is encoded within the frame itself.
     • Streaming data is typically sent continuously in chunks or frames, rather than waiting for the entire content to be available before sending and hence content-length becomes even less prominent?

[Sriram Bhetanabottla]

20240312 Video Enhancement F2F

1. Requirement included NOT to flood the cloud service with uplink requests, Agree to close.
2. Not too convinced with the discussion, further discussion below.
3. Specific requirement included to address Apple clients, Agree to close.

Further discussion on point 2

Here are 2 Possible interpretations of the requirement text for non-native English speaker

1. The device should attempt to create connections to all entries in the uplink list at the same time, without waiting for one connection to be established before trying the next.

2. The device should try to establish connections to each entry in the uplink list one after another, but if there are multiple connections that can be established simultaneously (such as connections to different servers), it should do so.

I understand the use case that device to keep connection simultaneously to say vendor cloud and 3rd party cloud. But that doesn't mean the device needs to set up or initiate those connections exactly at the same time?

If a device is a bit short on resources, It may set those connections one by one and that should not disqualify the device in adhering to the uplink specification.

Ideally, it shouldn't matter how and when the device gets connected to multiple clouds as long as it can keep those parallel connections alive - which keeps up the spirit of the specification.

Proposal

• If the uplink list contains multiple entries the device shall try to maintain all connections in parallel.

[Venki-Honeywell]

device connecting to multiple clouds one bye one or or simultaneously is device implementation specific behavior, ONVIF interface(i.e Uplink spec here) should not mandate it.

[Hans Busch]

The connection to all in parallel has been defined by purpose for allowing multiple cloud services using the same camera. We had a discussion on alternates but dropped that because such things can be solved differently.

[Sriram Bhetanabottla]

@HansBusch Its not about having connections to multiple cloud services - but It is about ONVIF specifying how those connections are made to those services "shall try to establish all connections in parallel."

Here is the updated proposal

• If the uplink list contains multiple entries the device shall try to create all connections from the list and maintain those connections in parallel.
  • This ensures there is enough clarity on creating connections is device behavior (one by one, simultaneously etc.,) but maintaining those connections in parallel is a mandatory requirement.
    • To support use case of multiple clients able to connect to the device in parallel.

[Hans Busch]

Got your point and agree.