[Jingle] WebRTC + Jingle - Incomplete SDP

[Peter Thatcher]

On Tue, Jun 25, 2013 at 12:49 PM, Philipp Hancke
<fippo at goodadvice.pages.de>wrote:

> Am 25.06.2013 20:21, schrieb Peter Thatcher:
>
>  FYI, It's also possible to have multiple streams within a <content> and
>> then demux by ssrc, which gives multiple audio or video streams over a
>> single transport without using BUNDLE.  You can see an implementation of
>> such here in libjingle:
>>
>> https://code.google.com/p/**libjingle/source/browse/trunk/**
>> talk/session/media/**mediamessages.cc#264<https://code.google.com/p/libjingle/source/browse/trunk/talk/session/media/mediamessages.cc#264>
>>
>> It's never been standardized, but we've found it to work well in practice,
>> and it looks kind of like this:
>>
>> <jingle>
>>    <content>
>>      <description>
>>        <!-- ... codecs and stuff -->
>>        <streams>
>>          <stream name="stream1">
>>            <ssrc>11111</ssrc>
>>          </stream>
>>          <stream name="stream2">
>>            <ssrc>22222</ssrc>
>>          </stream>
>>        </streams>
>>      </description>
>>    </content>
>> </jingle>
>>
>
> I still remember the link to the doc ;-)
> What puzzled me was the example on page three where you had
> <stream name='webcam'>
>   <ssrc>11111</ssrc>
>   <ssrc>22222</ssrc>
>   <ssrc>33333</ssrc>
>   [ssrc-group omitted]
> </stream>
> Now this means it is quite hard to extend a ssrc with specific sdp
> attributes (like cname, msid, mslabel, etc...). So i'd go for <ssrc
> id='11111>extension-elements-**here</ssrc> to avoid mixed content. Each
> extension element could be properly namespaced then.
>

Since we never proposed it as a standard, it doesn't really matter to this
forum, but if you're curious, we use the <stream> for attributes like that
rather than <ssrc>, since we don't really use any per-ssrc attributes, only
per-stream attributes.  Of course, then you have to decided what "stream"
means :).

Same rationale applies to the JS no-plan of yours... I'd say ssrc is an
> object with an id (equal to the rtp ssrc of the stream associated with
> that) and a bag of properties instead of a simple int
>
>
If you'd like to comment on RTCWEB things, please do so on the RTCWEB
mailing list.  If you'd like to ask a question about the propsed NoPlan JS
API, please reply to the thread where I proposed it.

The other problem I had with that is that a <content/> describes a single
> media type and therefore you can't easily express things like BUNDLE or a
> WMS mediastreamtrack where the ssrc-group spans more than one media type.
> Basically jingle lacks the equivalent of an extensible session part here.
>
>
BUNDLE should not be part of <description/> anyway (same argument applies
> to rtcp-mux; both are transport-related and for early transport warmup you
> want them in the transport-info from the peer before session-accept).
>
>
>  PS: This is like the RTCWEB "Plan A vs Plan B" all over again :).
>>
>
> Mind you, THEY are many, they have no plan and are listening here, too (-:
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.jabber.org/pipermail/jingle/attachments/20130625/eabdefdb/attachment-0001.html>