On 06/06/2008 1:23 PM, Jeff Muller wrote:
> Just a quick question:
> 
> 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?

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

> Also, it seems to me that, although "ringing" and "hold", would
> typically be associated with a session, I could see how "mute" would be
> associated with individual streams (<content/>). I may be in a
> voice-video session, but temporarily want to mute only video, because I
> need to pick my nose, or scratch an intimate area, or whatever, and then
> un-mute again. Otherwise, how would session-mute be different than
> session-hold? Perhaps <mute /> could include an optional "name" property
> which, if present, specified the name of a particular <content /> entity???

That makes sense, I'll modify XEP-0167 accordingly.

> Thanks for listening,

No, thank you! ;-)

Peter


-- 
Peter Saint-Andre
https://stpeter.im/

Attachment: smime.p7s
Description: S/MIME Cryptographic Signature

Reply via email to