[Standards] Jingle: one RTP application type to bind them all?

[Peter Saint-Andre]

Back in April, Olivier Crête questioned whether we really need separate
application types for RTP audio (XEP-0167) and RFC video (XEP-0180):

http://mail.jabber.org/pipermail/standards/2008-April/018554.html

Olivier suggested that we could simply negotiate one RTP "channel" and
use it for anything that RTP can do -- voice, video, real-time text (RFC
4103), etc. I have not seen a lot of enthusiasm for this idea, but I
would like to make sure that we have consensus on keeping things as-is
before moving forward with the Jingle specs. If you have feedback on
this issue, please weigh in on the standards (AT) xmpp (DOT) org list.

Thanks!

Peter

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

[Robert McQueen]

Peter Saint-Andre wrote:
> Back in April, Olivier Crête questioned whether we really need separate
> application types for RTP audio (XEP-0167) and RFC video (XEP-0180):
>
> http://mail.jabber.org/pipermail/standards/2008-April/018554.html
>
> Olivier suggested that we could simply negotiate one RTP "channel" and
> use it for anything that RTP can do -- voice, video, real-time text (RFC
> 4103), etc. I have not seen a lot of enthusiasm for this idea, but I
> would like to make sure that we have consensus on keeping things as-is
> before moving forward with the Jingle specs. If you have feedback on
> this issue, please weigh in on the standards (AT) xmpp (DOT) org list.

I think I'm in favour of this, given the two XEPs seem to be copies of
each other. We could just have one RTP/AVP description XEP, with a media
type field. I discussed this earlier with Peter:

Robert McQueen: so, Olivier seems pretty sure that anything you want to
represent in the audio XEP will also need representation in the video
XEP, and that when implementing (using an RTP media stack) you'll just
end up mangling the data into the same format anyway
Robert McQueen: in fact, in our implementation, we do just have this
kinda thing:
Robert McQueen: if (priv->media_type == MEDIA_TYPE_VIDEO)
Robert McQueen: xmlns = NS_JINGLE_DESCRIPTION_VIDEO;
Robert McQueen: else
Robert McQueen: xmlns = NS_JINGLE_DESCRIPTION_AUDIO;
Robert McQueen: so I can kinda see the point
Robert McQueen: the problem is with video is that you're tempted to add
all of these video-specific attributes like width, height, etc
Robert McQueen: but unless a certain codec already supports those
attributes in SDP a= negotiation, you're unlikely to be able to signal
anything useful there anyway, so there's not a great benefit to
promoting them into the namespace itself
Robert McQueen: the main thing that worries me is having caps discovery
Robert McQueen: but we can define #audio and #video really
Robert McQueen: certainly mangling one jingle offer into an SDP offer
will be easier this way
Peter Saint-Andre: yes, I keep copying and pasting from 167 to 180, and
we can define service discovery features quite easily
Peter Saint-Andre: are there potential problems with coordination
between audio and video, or is it easier to have everything in one RTP
"session"?
Robert McQueen: ah, you'd still negotiate two RTP sessions
Robert McQueen: one for audio and one for video
Robert McQueen: so you still have two contents
Robert McQueen: you can't mix audio and video codecs within one offer
Peter Saint-Andre: aha
Peter Saint-Andre: so they'd simply be differentiated by the name and
content-type
Robert McQueen: yeah, so an SDP m-line has a media type as the first
argument
Robert McQueen: http://tools.ietf.org/html/rfc4566#section-5.14
Peter Saint-Andre: nod
Peter Saint-Andre: I think this is one of my open issues
Robert McQueen: and I /really/ don't think you need a profile thing
Robert McQueen: we definitely imply RTP/AVP - and if we're not doing AVP
we're doing maybe SAVP, in which case we need to signal some keys
Robert McQueen: so we can cross that bridge when we come to it - maybe
throw a sub-namespace in with srtp key negotiation stuff in it
Robert McQueen: so I guess I'm in favour of rolling them into one
Robert McQueen: I might just paste what i said above into a mail
Robert McQueen: :P

> Thanks!
>
> Peter

Regards,
Rob

[Olivier Crête]

On Thu, 2008-05-29 at 20:38 +0100, Robert McQueen wrote:
> Peter Saint-Andre wrote:
> > Back in April, Olivier Crête questioned whether we really need separate
> > application types for RTP audio (XEP-0167) and RFC video (XEP-0180):
> >
> > http://mail.jabber.org/pipermail/standards/2008-April/018554.html
> >
> > Olivier suggested that we could simply negotiate one RTP "channel" and
> > use it for anything that RTP can do -- voice, video, real-time text (RFC
> > 4103), etc. I have not seen a lot of enthusiasm for this idea, but I
> > would like to make sure that we have consensus on keeping things as-is
> > before moving forward with the Jingle specs. If you have feedback on
> > this issue, please weigh in on the standards (AT) xmpp (DOT) org list.
>
> I think I'm in favour of this, given the two XEPs seem to be copies of
> each other. We could just have one RTP/AVP description XEP, with a media
> type field. I discussed this earlier with Peter:

> Robert McQueen: and I /really/ don't think you need a profile thing
> Robert McQueen: we definitely imply RTP/AVP - and if we're not doing AVP
> we're doing maybe SAVP, in which case we need to signal some keys
> Robert McQueen: so we can cross that bridge when we come to it - maybe
> throw a sub-namespace in with srtp key negotiation stuff in it

Apart from RTP/AVP, there is also RTP/AVPF (and the RTP/SAVPF) defined
in RFC4585, that is basically the same as RTP/AVPF but with more
frequent rtcp feedback. That RFC also defines the extra "a:rtcp-fb"
media attribute... which could be added to the XEP. That said, I don't
know if anyone actually implements this or how useful it is.


--
Olivier Crête
olivier.crete (AT) collabora (DOT) co.uk
Collabora Ltd

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)

iEYEABECAAYFAkg/CjEACgkQHTiOWk7ZortHegCfRQbRAM8NJHdpaMgdC6yOsZGj
Ne4AniVGgu9R2IiGkdKfBZHHeeLlhfcx
=/Pjm
-----END PGP SIGNATURE-----

[Peter Saint-Andre]

On 05/29/2008 1:38 PM, Robert McQueen wrote:
> Peter Saint-Andre wrote:
>> Back in April, Olivier Cr�te questioned whether we really need separate
>> application types for RTP audio (XEP-0167) and RFC video (XEP-0180):
>>
>> http://mail.jabber.org/pipermail/standards/2008-April/018554.html
>>
>> Olivier suggested that we could simply negotiate one RTP "channel" and
>> use it for anything that RTP can do -- voice, video, real-time text (RFC
>> 4103), etc. I have not seen a lot of enthusiasm for this idea, but I
>> would like to make sure that we have consensus on keeping things as-is
>> before moving forward with the Jingle specs. If you have feedback on
>> this issue, please weigh in on the standards (AT) xmpp (DOT) org list.
>
> I think I'm in favour of this, given the two XEPs seem to be copies of
> each other. We could just have one RTP/AVP description XEP, with a media
> type field.

Yes I looked into that a while back. For instance we might have this:

<jingle>
<content type='audio'>
<description xmlns='urn:xmpp:jingle:apps:rtp'>
<payload-type/>
<payload-type/>
<payload-type/>
</description>
<transport xmlns='urn:xmpp:tmp:jingle:transports:ice-udp'/>
</content>
<content type='video'>
<description xmlns='urn:xmpp:jingle:apps:rtp'>
<payload-type/>
<payload-type/>
<payload-type/>
</description>
<transport xmlns='urn:xmpp:tmp:jingle:transports:ice-udp'/>
</content>
</jingle>

Then I thought about extending that model further. For example, let's
say we want to use Jingle to negotiate a shared XHTML editing session
using SXE [1] or direct bytestreams or whatever (I'm not focused on the
transport right now). We might then have this:

<jingle>
<content type='text' subtype='html'>
<description xmlns='urn:xmpp:jingle:apps:xhtml'/>
<transport xmlns='urn:xmpp:tmp:jingle:transports:sxe'>
</content>
</jingle>

It's not clear to me how helpful the content type and subtype are. For
example you might have the same information for a file transfer:

<jingle>
<content type='text' subtype='html'>
<description xmlns='urn:xmpp:jingle:apps:file-transfer'/>
<transport xmlns='urn:xmpp:tmp:jingle:transports:ibb'>
</content>
</jingle>

Or contrast an SVG whiteboarding session and an SVG image transfer:

<jingle>
<content type='application' subtype='svg+xml'>
<description xmlns='urn:xmpp:jingle:apps:xhtml'/>
<transport xmlns='urn:xmpp:tmp:jingle:transports:sxe'>
</content>
</jingle>

vs.

<jingle>
<content type='application' subtype='svg+xml'>
<description xmlns='urn:xmpp:jingle:apps:file-transfer'/>
<transport xmlns='urn:xmpp:tmp:jingle:transports:ibb'>
</content>
</jingle>

So you can't tell everything from the media type.

And we actively don't want to include the full media type information
for audio or video because that's what you're negotiating via the
payload types:

<jingle>
<content type='audio' subtype='??????'>
<description xmlns='urn:xmpp:jingle:apps:rtp'>
<payload-type id='96' name='speex' clockrate='16000'/>
<payload-type id='97' name='speex' clockrate='8000'/>
<payload-type id='18' name='G729'/>
<payload-type id='103' name='L16' clockrate='16000' channels='2'/>
<payload-type id='98' name='x-ISAC' clockrate='8000'/>
<payload-type id='102' name='iLBC'/>
<payload-type id='4' name='G723'/>
<payload-type id='0' name='PCMU' clockrate='16000'/>
<payload-type id='8' name='PCMA'/>
<payload-type id='13' name='CN'/>
</description>
<transport xmlns='urn:xmpp:tmp:jingle:transports:ice-udp'/>
</content>
</jingle>

So while I think that including the media type as attributes of the
<content/> element is helpful in some instances, it doesn't give you
everything you need in order to determine whether you want to accept the
negotiation or whatever.

/psa

[1] http://www.xmpp.org/extensions/inbox/sxe.html

[Paul Witty]

Peter Saint-Andre wrote:
> Back in April, Olivier Crête questioned whether we really need separate
> application types for RTP audio (XEP-0167) and RFC video (XEP-0180):
>
> http://mail.jabber.org/pipermail/standards/2008-April/018554.html
>
> Olivier suggested that we could simply negotiate one RTP "channel" and
> use it for anything that RTP can do -- voice, video, real-time text (RFC
> 4103), etc. I have not seen a lot of enthusiasm for this idea, but I
> would like to make sure that we have consensus on keeping things as-is
> before moving forward with the Jingle specs. If you have feedback on
> this issue, please weigh in on the standards (AT) xmpp (DOT) org list.
>

I'm in favour of simplifying things down so that there's as much in
common between audio/video channels as possible. Though the use of the
word "one" in the above paragraph seems to suggest a single RTP channel,
implying all media being received on a single UDP port. This would be a
bad idea at least where doing Jingle <-> SIP gateways is concerned, as
SIP uses separate UDP streams for each content type, so the gateway
would have to inspect each packet incoming on the Jingle side to
determine the payload type to send it out on the correct port.

I'll have a read through all the updated specs over the weekend, and try
to comment on them on Monday.

--

Paul

[Zack Sargent]

From: standards-bounces (AT) xmpp (DOT) org [mailto:standards-bounces (AT) xmpp (DOT) org] On Behalf Of Paul Witty
Sent: Friday, May 30, 2008 9:57 AM
To: XMPP Extension Discussion List
Subject: Re: [Standards] Jingle: one RTP application type to bind them all?

Peter Saint-Andre wrote:
> Back in April, Olivier Crête questioned whether we really need separate
> application types for RTP audio (XEP-0167) and RFC video (XEP-0180):
>
> http://mail.jabber.org/pipermail/standards/2008-April/018554.html
>
> Olivier suggested that we could simply negotiate one RTP "channel" and
> use it for anything that RTP can do -- voice, video, real-time text (RFC
> 4103), etc. I have not seen a lot of enthusiasm for this idea, but I
> would like to make sure that we have consensus on keeping things as-is
> before moving forward with the Jingle specs. If you have feedback on
> this issue, please weigh in on the standards (AT) xmpp (DOT) org list.
>

I'm in favour of simplifying things down so that there's as much in
common between audio/video channels as possible. Though the use of the
word "one" in the above paragraph seems to suggest a single RTP channel,
implying all media being received on a single UDP port. This would be a
bad idea at least where doing Jingle <-> SIP gateways is concerned, as
SIP uses separate UDP streams for each content type, so the gateway
would have to inspect each packet incoming on the Jingle side to
determine the payload type to send it out on the correct port.

I'll have a read through all the updated specs over the weekend, and try
to comment on them on Monday.

--

Paul

------

To throw another comment into this idea, providing separate channels for audio and video such that a network can provide separate QoS for each channel is also desirable. I.e., less communication is lost if a frame of video is dropped than if a few words are dropped from the audio. Therefore, separate streams across the network for each part are desirable as part of the same session initiation (though no present VOIP/Video implementations support this, yet).

[Robert McQueen]

Paul Witty wrote:
> I'm in favour of simplifying things down so that there's as much in
> common between audio/video channels as possible. Though the use of the
> word "one" in the above paragraph seems to suggest a single RTP channel,
> implying all media being received on a single UDP port. This would be a
> bad idea at least where doing Jingle <-> SIP gateways is concerned, as
> SIP uses separate UDP streams for each content type, so the gateway
> would have to inspect each packet incoming on the Jingle side to
> determine the payload type to send it out on the correct port.

Yeah, I don't think Peter meant to say the same channel... :P The idea
is just using the same negotiation namespaces and XEP to describe all
RTP media content, be it audio or video. We'd lose in so many ways by
doing anything other than staying compatible with SDP here. It's just
not a correct use of RTP to pretend that switching payload type is
switching media type too.

Regards,
Rob

[Olivier Crête]

On Fri, 2008-05-30 at 15:57 +0100, Paul Witty wrote:
> Peter Saint-Andre wrote:
> > Back in April, Olivier Crête questioned whether we really need separate
> > application types for RTP audio (XEP-0167) and RFC video (XEP-0180):
> >
> > http://mail.jabber.org/pipermail/standards/2008-April/018554.html
> >
> > Olivier suggested that we could simply negotiate one RTP "channel" and
> > use it for anything that RTP can do -- voice, video, real-time text (RFC
> > 4103), etc. I have not seen a lot of enthusiasm for this idea, but I
> > would like to make sure that we have consensus on keeping things as-is
> > before moving forward with the Jingle specs. If you have feedback on
> > this issue, please weigh in on the standards (AT) xmpp (DOT) org list.
> >
>
> I'm in favour of simplifying things down so that there's as much in
> common between audio/video channels as possible. Though the use of the
> word "one" in the above paragraph seems to suggest a single RTP channel,
> implying all media being received on a single UDP port. This would be a
> bad idea at least where doing Jingle <-> SIP gateways is concerned, as
> SIP uses separate UDP streams for each content type, so the gateway
> would have to inspect each packet incoming on the Jingle side to
> determine the payload type to send it out on the correct port.

What I suggested is to have one "type" of channel (ie one namespace).
Not to mix audio and video on the same port, that would be crazy (and I
hope I'm not). My goal is only to make jingle as close to SIP as
possible so as to make interoperability and future extensions easy.

--
Olivier Crête
olivier.crete (AT) collabora (DOT) co.uk
Collabora Ltd

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)

iEYEABECAAYFAkhAVYsACgkQHTiOWk7Zort+EgCfQRfl6FDp9t m/90j/QKFe3Ydo
kJ0An0KXG6qxCEAhcFXUzAZOnMNxTHWy
=cztD
-----END PGP SIGNATURE-----

[Robert McQueen]

Peter Saint-Andre wrote:
> On 05/29/2008 1:38 PM, Robert McQueen wrote:
>> Peter Saint-Andre wrote:
>> I think I'm in favour of this, given the two XEPs seem to be copies of
>> each other. We could just have one RTP/AVP description XEP, with a media
>> type field.
>
> Yes I looked into that a while back. For instance we might have this:

....

> So while I think that including the media type as attributes of the
> <content/> element is helpful in some instances, it doesn't give you
> everything you need in order to determine whether you want to accept the
> negotiation or whatever.

Aiee! This seems like crazy over-generalisation to me. Every different
content description markup will have its own way of describing what it
wants to do (if necessary), especially when we do stuff like re-using
existing namespaces like file transfer.

Why would you you want to say in two places you're doing audio, or say
in one place you're doing audio, and somewhere else say you're doing it
over RTP? Not to mention it would invoke yet another registry of
namespaces/values/attributes we have to take care of.

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

> /psa

Regards,
Rob

[Peter Saint-Andre]

On 05/30/2008 1:24 PM, Robert McQueen wrote:
> Paul Witty wrote:
> > I'm in favour of simplifying things down so that there's as much in
>> common between audio/video channels as possible. Though the use of the
>> word "one" in the above paragraph seems to suggest a single RTP channel,
>> implying all media being received on a single UDP port. This would be a
>> bad idea at least where doing Jingle <-> SIP gateways is concerned, as
>> SIP uses separate UDP streams for each content type, so the gateway
>> would have to inspect each packet incoming on the Jingle side to
>> determine the payload type to send it out on the correct port.
>
> Yeah, I don't think Peter meant to say the same channel... :P

Right, I used that term off-the-cuff.

> The idea
> is just using the same negotiation namespaces and XEP to describe all
> RTP media content, be it audio or video.

Correct.

> We'd lose in so many ways by
> doing anything other than staying compatible with SDP here. It's just
> not a correct use of RTP to pretend that switching payload type is
> switching media type too.

Shall I take that as a vote for consolidating XEP-0167 and XEP-0180 into
one "Jingle-RTP" spec?

Peter

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

[Peter Saint-Andre]

On 05/30/2008 1:45 PM, Robert McQueen wrote:
> Peter Saint-Andre wrote:
>> On 05/29/2008 1:38 PM, Robert McQueen wrote:
>>> Peter Saint-Andre wrote:
>>> I think I'm in favour of this, given the two XEPs seem to be copies of
>>> each other. We could just have one RTP/AVP description XEP, with a media
>>> type field.
>> Yes I looked into that a while back. For instance we might have this:
>
> ...
>
>> So while I think that including the media type as attributes of the
>> <content/> element is helpful in some instances, it doesn't give you
>> everything you need in order to determine whether you want to accept the
>> negotiation or whatever.
>
> Aiee! This seems like crazy over-generalisation to me. Every different
> content description markup will have its own way of describing what it
> wants to do (if necessary), especially when we do stuff like re-using
> existing namespaces like file transfer.
>
> Why would you you want to say in two places you're doing audio, or say
> in one place you're doing audio, and somewhere else say you're doing it
> over RTP? Not to mention it would invoke yet another registry of
> namespaces/values/attributes we have to take care of.

Yeah ignore that ramble I sent.

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

Peter

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

[Paul Witty]

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.

I also wonder at the purpose of the 'name' attribute of the content. If
we have multiple streams of one type, then it is needed to identify each
stream, but otherwise there would be no need for another unique
identifier when peer & content type already uniquely identifies a
stream. Although in this case, the media type would need to be in the
'content' tag rather than 'description', for use in identifying the
stream when sending things like candidates.

--

Paul

[Olivier Crête]

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.


--
Olivier Crête
olivier.crete (AT) collabora (DOT) co.uk
Collabora Ltd

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.9 (GNU/Linux)

iEYEABECAAYFAkhGm1kACgkQHTiOWk7ZoruRPgCdHNDG1RNUvx S93M864dS4Cslz
2jgAn3SD//SvpeGmdxmPvOZBDyEfhpla
=GCw1
-----END PGP SIGNATURE-----

[Paul Witty]

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

[Peter Saint-Andre]

On 06/04/2008 8:25 AM, Paul Witty wrote:
> 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.

I'm not opposed to using the 'name' for that. We've got it, we might as
well use it.

Peter

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