Hi Ross. > The additions to the "RTCPInstance" class (to assign a > RTCP "APP" packet handler, and send an "APP" packet) look > reasonable, and I'll probably add them to the library soon.
That's good to know, thanks. > The changes to "OnDemandServerMediaSubsession", however, > don't look quite right, and I'll need to think some more > about exactly what's the right thing to do here. > > In particular, having a "sendRTCPAppPacket()" function > that applies to the whole "OnDemandServerMediaSubsession" > object implies that you want to send a RTCP "APP" packet > to all clients that are currently playing this stream. > That may or may not be what you want to do (however, your > implementation of this - using the "fLastStreamToken" > variable - will work only if your "OnDemandServerMediaSubsession" > subclass set the "reuseFirstSource" parameter to True; > if "reuseFirstSource" is False (its default value), then > your implementation will send an "APP" packet only to the > client that most recently called "SETUP" to request playing > the stream). > It's also possible that you might want to send a RTCP "APP" > packet just to one particular client; not to all of them. I see. Looking at "OnDemandServerMediaSubsession", it would appear that a potential solution would be to add the "streamToken" (StreamState) to the "Destinations" structure. This would allow a lookup in "fDestinationHashTable" to retrieve the "StreamState" for a particular client, gaining access to the "RTCPInstance" to send an APP packet. > More generally speaking, I'm uncomfortable with the idea of > adding RTCP-specific functionality to higher-level > server-related classes (like "OnDemandServerMediaSubsession"). If a public method is then added to expose an iterable collection of Destinations (a type which is already, explicitly exposed to the user), the user can iterate the clients to send an APP packet to whomever they wish. This also removes the need for any RTCP specific code within "OnDemandServerMediaSubsession". What I've been unable to determine so far, is how the "RTCPInstance" is selective about which clients it sends packets to. From what I can see, sent packets are always delivered to all registered clients (addresses in the groupsock). Since there is only a single "StreamState" per subsession, how does "reuseFirstSource" limit the clients to which other RTCP packets are sent? I assume all clients are still sent sender reports, for eaxmaple? > Because "OnDemandServerMediaSubsession" is used only within a > "RTSPServer" object, I'm curious as to specifically when/how you > intend to send RTCP "APP" packets from within the server? Have > you subclassed "RTSPServer" to do this? (Accessing the > "OnDemandServerMediaSubsession" (subclass) object from outside a > "RTSPServer" would be dangerous, because the "ServerMediaSession" > and "ServerMediaSubsession" (subclass) objects end up getting > owned by the "RTSPServer", and get deleted if/when the server > goes away.) Yes, I've subclassed both "RTSPServer" and "OnDemandServerMediaSubsession". APP packets are only ever sent or handled from inside the "RTSPServer" subclass. Thanks for your feedback. -- Nick Ogden ________________________________ The details of this company are as follows: G4S Technology Limited, Registered Office: Challenge House, International Drive, Tewkesbury, Gloucestershire GL20 8UQ, Registered in England No. 2382338. This communication may contain information which is confidential, personal and/or privileged. It is for the exclusive use of the intended recipient(s). If you are not the intended recipient(s), please note that any distribution, forwarding, copying or use of this communication or the information in it is strictly prohibited. Any personal views expressed in this e-mail are those of the individual sender and the company does not endorse or accept responsibility for them. Prior to taking any action based upon this e-mail message, you should seek appropriate confirmation of its authenticity. This e-mail has been scanned for all viruses by MessageLabs.
_______________________________________________ live-devel mailing list live-devel@lists.live555.com http://lists.live555.com/mailman/listinfo/live-devel
