Olivier Crête wrote:
On Wed, 2008-06-04 at 14:06 +0100, Paul Witty wrote:
Peter Saint-Andre wrote:
I was thinking of a direct analogy to the media field saying "audio" or
"video" in your m-line in SDP. So like:
<jingle>
<content name="asdf">
<description xmlns="...rtp" media="audio">
<payload-type>
<payload-type>
</description>
<transport/>
</content>
</jingle>
Then we'd just define some features to explain what media you supported,
like:
urn:...:jingle-rtp#media-audio
urn:...:jingle-rtp#media-video
Works for me.
Add me to the list in favour as well. What values are we planning to
support for media? Clearly 'audio' and 'video', and I'd like to push
for 'content', which would be a second video stream used for things such
as slide-shows. Would we then support multiple channels of the same
type? I can't see a good reason why we would, but others may disagree.
The media attribute should directly match what SIP does and only
describes the "type" of data, not the content, so a second video channel
would be media="video" and the description of the content should be
somewhere else (like in name=""). There are good reasons to have
multiple video channel, slides are one, or stereoscopic chat or just
that SIP allows it.
Can't argue with that. We still need to specify the purpose of each so
that we know which is the main video, and which are the slides, or which
is the left and which the right. The media attribute in the description
tag tells us whether this is audio or video, but we'll need to either
change the name attribute from being one which is "opaque and does not
have semantic meaning" to one which unambiguously identifies the purpose
of this media stream, or introduce another attribute to do so. SIP does
multiple video streams in a horrible, ill-supported and complicated
fashion (according to my friendly local SIP developer), so we probably
don't want to draw too much inspiration from there.
--
Paul
