On 06/09/2008 2:29 PM, Jeff Muller wrote: > > "Peter Saint-Andre" <[EMAIL PROTECTED]> wrote in message > news:[EMAIL PROTECTED] >> 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. > > OK, I hate to be a pest, but... > If individual <content/> streams are able to be muted, we also need a > way to individually "unmute" them. Now, you could also add a "name" > attribute to <active/>, but then <active/> becomes a little overloaded > (and unwieldy). For example, lets say I mute video, then put the call on > hold, and then want to "unhold". In my opinion, video should still be > muted. In my mind, "mute" and "hold" are different enough concepts, that > they need independent ways of un-doing them (although, from a streaming > perspective, putting a call on "hold" would essentially "mute" all > channels, but from a user's perspective, they're different states).
Naturally, that is quite sensible. I'll update the spec yet again. ;-) Peter -- Peter Saint-Andre https://stpeter.im/
smime.p7s
Description: S/MIME Cryptographic Signature
