"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).
What does everyone else think?
Thanks for listening,
No, thank you! ;-)
Peter
--
Peter Saint-Andre
https://stpeter.im/
