On Mon, 2008-06-09 at 16:17 -0400, Jeff Muller wrote: > > On 06/06/2008 1:23 PM, Jeff Muller wrote: > >> I didn't quite glean this from the spec and am not sure if it's been > >> discussed in this forum, but is there a way to associate two streams (or > >> two <content /> entities)? Typically, for a video "call", there are two > >> streams, audio and video. You want these two streams associated in the > >> client a) so that they can be presented in an associated way (camera and > >> speaker controls near each other), and b) so that they can be associated > >> for lip sync. Especially if there are two video streams (for example, > >> there's a document camera), you want to know which is the "main" stream > >> that goes (by default) in the main window with the audio controls. Or > >> for that matter, if you only want to allow one video stream, you know > >> which one to do a content-remove on. > > > > Wouldn't the associated media simply be part of the same RTP session? Or > > do you want the ability to associate media across RTP sessions? > > I'm definitely not an RTP expert here. But from a quick web search... Isn't > each multimedia type limited to a separate RTP session? From what I read, a > session really just consists of the port pairs for the (single) RTP and > (single) RTCP streams. Maybe?
You definitely want to be able to associate multiple RTP sessions to synchronize them. We should define that all the sessions within the same Jingle negotiation should be synchronized. All the RTP sessions (call media aka m= lines) inside the same SDP are supposed to be synchronized too. > >> Or, is it to be inferred that for a single session, there can be at most > >> one entry for each content type, and that any others would be yet > >> another session (not sure I like that). I have no idea which approach > >> maps better to SIP. > > > > No, I think you can have multiple entries per media type -- for example, > > a room pan and a podium view for video from a conference. > > That's what I would have hoped/expected. Although that poses another > interesting situation. In your example, either of those streams could be > associated with the audio, as opposed to a completely separate video stream. > So, lets say we combine your example, with also sending a auxiliary > audio/video stream (let's say, we're streaming a local multimedia file > that's a training video). How would we associate the speaker's voice stream > with the two in-room video views, and the training video's audio with the > video? I realize the is quite an elaborate scenario, but at least in terms > of protocol, we should be able to express it. Imho, if you have multiple audio/video inputs, they should all be synchronized. If you want to have "semantic" associations, then you should probably put something meaningful in the "name" attribute and have the application do the magic. -- Olivier Crête [EMAIL PROTECTED] Collabora Ltd
signature.asc
Description: This is a digitally signed message part
