[Jingle] WebRTC + Jingle - Incomplete SDP

Philipp Hancke fippo at goodadvice.pages.de
Tue Jun 25 19:49:18 UTC 2013


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


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 (-:


More information about the Jingle mailing list