"Peter Saint-Andre" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED]
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, in the text for the <active/> element, it says "If no 'name' attribute is included, the recipient MUST assume that all sessions are active". There is also similar text for the other informational messages. Instead of "all sessions", shouldn't it be "all content streams for the session", or some other appropriately worded text?

Jeff

Peter

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




Reply via email to