Summary: The timestamp format used in SFP is not adequate for many applications
particularly non-linear editing and post-production systems. These systems
require a more comprehensive timestamping format. Furthermore, the current
timestamp, expressed in microseconds wraps around too quickly. This needs
to be addressed without loss of precision.

Summary: Probably the most serious problem for the specification is in the
‘full profile’. The model erroneously constrains the FlowProducer
to always perform the transport connect() call while the FlowConsumer
is the party which always calls transport listen(). Tying the
connect()/listen() roles to the producer/consumer roles creates a
problem with firewalls. With a firewall, the connection must always
be accepted on the firewall machine. This is impossible, however
if the FlowProducer is behind the firewall since there is no listen()
operation in the FlowProducer IDL. There is a possible resolution to
this problem which would be backward compatible for implementations
which use the old IDL.

Summary: The connect_leaf() operation throws an exception if it is unable to use
ATM-style multipoint transport connections. Using the current scheme,
this happens, in principle, only when the first B party is bound into
the multiparty stream. It would be very useful if the StreamCtrl could first
test for the use of ATM-style multipoint by passing a nil object
reference for the ‘the_ep’ parameter in the call to connect_leaf().
It also leads to better semantics for binding the A party into the
multiparty stream.

Summary: The StreamCtrl can be used to create a stream between two or more
endpoints by calling the bind_devs() operation with the
MMDevices to be bound as parameters. During the course of the
binding process, each MMDevice acts as a factory creating a VDev and
a StreamEndPoint. The application programmer who called bind_devs()
may want to query the resulting StreamEndPoints or VDevs, however
there is no easy way to obtain a reference to these objects since
they are not returned by the bind_devs() call.

Summary: The set_dev_params() method in the AVStreams IDL interface raises a PropertyService::PropertyException. However, PropertyException which used to be an exception, was recently revised to be a struct in the Property Service. This broke the AVStreams interface since a struct cannot be raised. Can you please fix this.

Summary: In various parts of the spec, the term Multicast is used
where Mulitpoint is more correct.

Summary: n sfp.idl there"s a case-only difference for the Credit MsgType
enumerator and the struct credit.

Also it would be convenient to have an enumerator for the struct fragment
message, so that its easier to switch code based on the MsgType set
depending on the magic_number.

Summary: the definition of struct fragment of module flowProtocol implies
a waste of 4 bytes

Summary: In document number telecom/98-10-05,
IDL spec of SFP v1.0, the type frameID in the definition of struct
specialFrame
is not defined.

Proposed Solution:
add
typedef unsigned long frameID;
to the module flowProtocol.

Summary: The A/V Streams light profile uses strings to name flow endpoints
with respect to their corresponding StreamEndPoint/VDev. In some
systems a flow endpoint in one stream endpoint corresponds to a
differently named flow endpoint in another stream endpoint. When a
stream is set up between these stream endpoints, the request_connection()
and set_format() operations carry enough information
(in terms of directionality and format) to allow the implementation to
map the flow endpoint in the requesting StreamEndPoint/VDev to its
corresponding flow endpoint in the local StreamEndPoint/VDev. This point
and others related to flow naming issues need to be made more explicit in
the text of the specification.

Summary: he ‘the_QoS’ parameter plays a very important role the bind() and
bind_devs() calls however its function is not properly explained by
the text which describes bind() and bind_devs(). In particular, thee
nature of the values following a call which managed to connect some
but not all of the flows with the desired QoS.

I am going to implement OMG Control and Management of Audio/Video Streams
specification. We used IONA's implementation: Orbix MediaStreams but we
are not fully satisfied with it.
I have some questions:
1. StreamCtrl has a 'Status' property which is 'seqflowStatus' - probably
sequence of flowStatus structures. But there is no such typedef in the IDL
specification.
2. StreamCtrl has alse A_parties and B_parties sequences. The same
problem.

Summary: The AVStreams flow specification allows the flows to use RTP
for their transport. The RTP spec requires that all RTP participants
send RTCP information. For eg. without the RTCP CNAME packet other RTP
receivers cannot do synchronization between 2 flows.

RTP and RTCP need 2 different channels ie. 2 different endpoints. The
flow specification provides a means of specifiying the RTP endpoint
but no standard way of specifying the RTCP endpoint.

Summary: In document number telecom/98-10-05,
IDL spec of SFP v1.0,
in module flowProtocol is an enum-value Start and a struct Start
defined. This is not allowed.
Same for enum-value StartReply / struct StartReply.
etc.

Proposed Solution:

Rename enum values of enum MsgType.

Summary: This is related to the need to put stream controllers and
endpoints in a browser-type sceanario. In this scenario the
StreamEndPoint_A in the browser calls request_connection() on
StreamEndPoint_B on the server. Because the StreamEndPoint_B
is behind the firewall it must provide for all of the listen
addresses of flows and must also provide the information about
their direction and format. The StreamEndPoint_A in the browser
can then decide which of the flows it can connect to based on name
or directionality and format.

Summary: Section 2.2.11 describes the behaviour of the modify_QoS() operation.
This behavioural description is flawed and should be replaced with
more sensible semantics. When modify_QoS() is called on the
StreamCtrl for a point-to-point stream it ahould call modify_QoS() on
both A and B stream endpoints and both sides should adjust QoS only for
flows which originate on their own side.

Summary: In order to work reliably over UDP, SFP needs magic numbers to
distinguish Credit and StartReply messages. Also, to work properly
over UDP, the fragment header must have a sequence number field
to associate it with its correct Frame. This is because transports
like UDP could potentially interleave fragments from different frames.

Summary: There is a bug in the state transition diagram for SFP which could
cause potential problems when it is used with UDP/IP.
If we timeout (T1) on receiving a data frame, we should send a
Credit message back to the producer. This prevents a situation where
a whole Frame or Frames have been dropped but the sender times out on
waiting for a credit message that will never arrive. The state transition
diagram needs to be updated to take this into account.

Summary: In the description of the connect() and request_connection(), stop(),
start() and destroy(), for point-to-point streams there is a bias
towards always viewing the StreamEndPoint_A as the ‘initiator’ and
StreamEndPoint_B as the ‘responder’. In fact the B party can equally
be used as an initiator and an A party as the responder. This point
needs to be emphasised by the text.

Summary: It is not mentioned anywhere in the specification that the
SFP frameHeader should always be treated implicitly as fragment 0.
Subsequent values of the frag_number field will be 1, 2, 3, etc.