Issues for AV Streams RTF mailing list

List of issues (green=resolved, yellow=pending Board vote, red=unresolved)

List options: All ; Open Issues only; or Closed Issues only

Issue 1845: set_dev_params() method in AVStreams IDL Interface
Issue 2048: StreamCtrl
Issue 2049: Change term Multicast to Multipoint
Issue 2052: connect_leaf() operation
Issue 2053: Full profile issue
Issue 2054: The "the_QoS" parameter parameter is not properly explained
Issue 2055: Flow naming issue
Issue 2056: Description of connect() and request_connection(), stop(), start(), and de
Issue 2057: There is a bug in the state transition diagram for SFP
Issue 2058: SFP frameHeader should always be treated implicitly as fragment 0
Issue 2059: UDP Issue
Issue 2061: Description of Behaviour of the modify_QoS() operation
Issue 2062: stream controllers and endpoints in browser-type scenario needed
Issue 2115: Wrong IDL for SFP
Issue 2116: frameID of struct specialFrame in module flowProtocol not defined
Issue 2117: telecom/98-10-05, IDL spec of SFP v1.0
Issue 2556: Case-only difference in SFP IDL for enum MsgType {Credit} and struct credi
Issue 2833: RTCP!
Issue 2969: C&M ofAudio/Video Streams

Issue 1845: set_dev_params() method in AVStreams IDL Interface (avstreams-rtf)

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: 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: In various parts of the spec, the term Multicast is used
 where Mulitpoint is more correct.
 

 received issue

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: 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: 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.
 

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: 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: 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: 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.
 
 

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: 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: 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: 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: 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 definition of struct fragment of module flowProtocol implies
 a waste of 4 bytes
 

 received issue

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 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. 
 

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.