Subject: [rtcweb] #15: Section 4.8: SSRC signaling

From: "rtcweb issue tracker" <[email-masked]>
Date: Sat, 20 Apr 2013 01:19:39 -0000

#15: Section 4.8: SSRC signaling

 4.8.  Choice of RTP Synchronisation Source (SSRC)

    Implementations are REQUIRED to support signalled RTP SSRC values,
    using the "a=ssrc:" SDP attribute defined in Sections 4.1 and 5 of
    [RFC5576], and MUST also support the "previous-ssrc" source attribute
    defined in Section 6.2 of [RFC5576].  Other attributes defined in
    [RFC5576] MAY be supported.

    Use of the "a=ssrc:" attribute is OPTIONAL.  Implementations MUST
    support random SSRC assignment, and MUST support SSRC collision
    detection and resolution, both according to [RFC3550].

 [BA] I think you need to be more specific here.  Does this mean that an
 implementation needs to be able to render an SSRC that isn't declared in
 an a=ssrc: attribute?  Personally, I'd suggest that this is useful because
 WebRTC gateways may not know what SSRCs to expect so they can't signal
 them.  Also, it enables operation in RTP topologies (like an RTP
 translator).  However, keep in mind that implicit SSRCs aren't something
 the current WEBRTC API supports.

 Also, if you're going to require support for a=ssrc: attributes, there
 will be other attributes that will come along with that.

-- 
-------------------------------------+-------------------------------------
 Reporter:                           |      Owner:  draft-ietf-rtcweb-rtp-
  [email-masked]          |  [email-masked]
     Type:  defect                   |     Status:  new
 Priority:  major                    |  Milestone:  milestone1
Component:  rtp-usage                |    Version:  1.0
 Severity:  Active WG Document       |   Keywords:
-------------------------------------+-------------------------------------

Ticket URL: <https://tools.ietf.org/wg/rtcweb/trac/ticket/15>
rtcweb <http://tools.ietf.org/rtcweb/>

---

From: Emil Ivov <[email-masked]>
Date: Sun, 21 Apr 2013 15:42:31 +0200

Hey all,

>  the current WEBRTC API supports.

I'd like to second this. Pre-announcing SSRC-s, which seems to be
required by current implementations (e.g. Chrome wouldn't show video for
unknown SSRCs) puts a huge constraint on existing implementations. This
applies to simple clients that may not have the API to retrieve this
information from their RTP components, but even more to gateways and RTP
translators.

Allowing the JS application to provide mappings between media streams
and unknown SSRCs would probably resolve this issue. The application can
then choose whether to do this mapping on local information or through
the use of other signalling methods such as RFC 4575.

Cheers,
Emil

-- 
https://jitsi.org

---

From: Magnus Westerlund <[email-masked]>
Date: Mon, 22 Apr 2013 16:04:19 +0200

> the use of other signalling methods such as RFC 4575.

Yes, we will be more explicit that one MUST be able to handle
unannounced SSRCs, this is the result of having this sentence:
"Use of the "a=ssrc:" attribute is OPTIONAL." If it is optional to use
then a receiver must be capable of dealing when they show up unannounced.

What about:

Use of the "a=ssrc:" attribute is OPTIONAL. The fact that a=ssrc is
optional to use makes it MANDATORY to be able to receive and handle
SSRCs that has not been explicitly signalled ahead of time.
Implementations MUST support random SSRC assignment, and MUST support
SSRC collision detection and resolution, both according to [RFC3550].

My personal cases for them to start showing up are when RTP
retransmission or FEC is used with a separate SSRC. Mandating that these
SSRC are signalled, despite being associated SSRCs, rather than primary
media SSRCs.

I thought there was discussion in W3C of handling primary media source
related SSRCs that was unannounced in the API by defaulting them into
MediaStreamTracks added to some "default" MediaStream, to be able to
deal with a substantial amount of legacy cases where it is difficult or
even impossible to learn the SSRC of the media streams for the peer
prior to receiving the media.

Cheers

Magnus Westerlund

----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM
----------------------------------------------------------------------
Ericsson AB                | Phone  +46 10 7148287
Färögatan 6                | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden| mailto: [email-masked]
----------------------------------------------------------------------

---

From: Martin Thomson <[email-masked]>
Date: Mon, 22 Apr 2013 10:29:14 -0700

> then a receiver must be capable of dealing when they show up unannounced.

That solves half the problem.

I don't recall the discussion on the "default" MediaStream, but it's
very similar to several other suggestions I've heard.  Another one
suggested was to provide unidentified single-track streams when
unknown streams appear.  I'm not sure how either option would migrate
to identified and grouped streams.

The basic problem is that you don't have an answer that provides you
with the necessary information.  Even if you could somehow associate
an incoming packet with an m= line, you don't have any way to
determine what identifier the remote side attached to that stream.
It's also unknown how that stream was grouped prior to being put on
the network.  This is somewhat important because we expect it to
happen in a lot of cases.

We designed an "unexpected SSRC" event in CU-RTC-Web, which fixes the
problem in a different way.  That is, make it somebody else's problem.

---

From: Emil Ivov <[email-masked]>
Date: Mon, 22 Apr 2013 21:25:21 +0200

> problem in a different way.  That is, make it somebody else's problem.

This would make a lot of sense, and as I already pointed out, exsiting
non-sdp/non-OA mechanisms can be used for this (e.g. RFC4575 or XEP-0298)

That said, even a "default" media stream would be better than simply
ignoring unannounced SSRCs, which is what happens with current
implementations.

Cheers,
Emil

-- 
https://jitsi.org

---

From: [email-masked] (Dale R. Worley)
Date: Mon, 22 Apr 2013 18:15:52 -0400 (EDT)

> From: Martin Thomson <[email-masked]>
> 

> an incoming packet with an m= line, [...]

My understanding is that associating an incoming RTP packet with an m=
line is a solved problem -- the transport association on which the
packet arrives determines the bundle, and (within all of the currently
active bundling proposals) the payload type tells which m= line within
the bundle.

> [...] you don't have any way to

However, I believe you are correct that knowing which m= line contains
the SSRC does not tell the RtcWeb stream identification.

Dale

---

From: Martin Thomson <[email-masked]>
Date: Mon, 22 Apr 2013 15:55:06 -0700

> active bundling proposals) the payload type tells which m= line within

Not so.  If you have five PTs on each m= line, and 30 m= lines, you
just don't have that many PTs available.  At some point you have to
recognize that SSRC is what you have to use.  (Neither number is
extraordinary.)

So, no, demux is a solved problem, but I don't believe that it's as
simple as you describe.

> the SSRC does not tell the RtcWeb stream identification.

Exactly, you need to know how to label, identify and group the
application layer construct that you create to represent the media.

---

From: Magnus Westerlund <[email-masked]>
Date: Tue, 23 Apr 2013 09:05:59 +0200

> active bundling proposals) the payload type tells which m= line within

I think this is one aspect of the bundle that doesn't work. You will
need to be able to use the same PT configuration and number (remember
that they are on RTP session level) to avoid running out of them and I
believe some limitations.

This, is also highly dependent on where on the scale we end up with the
usage of a m= block. If that is per media source, then it is clearly a
no-go to not allow the same. The other end of the spectra is one m=
block per media type being allowed. I think we will end up somewhere in
the middle, with different m= blocks depending on usage of media
streams. But this is really an MMUSIC question.

In this context, I do wonder if it at all matters which m= block the the
SSRC was intended for, as long as a receiver correctly can receive and
process the media. Which the payload type should provide most of the
functionality for.

> the SSRC does not tell the RtcWeb stream identification.

Correct, but for legacy use-cases you might have to accept some
limiations that you can't get the ID's across the PeerConnection and
your JS will have to work with locally generated ids. I think the issue
is really around when the signalling glitches and you get locally
generated IDs that then needs to be changed to the actual signalled ones.

Cheers

Magnus Westerlund

---

From: [email-masked] (Dale R. Worley)
Date: Tue, 23 Apr 2013 14:58:04 -0400 (EDT)

> recognize that SSRC is what you have to use.  (Neither number is

But why would you use 30 m= lines?  You'd only have 30 streams in a
videoconference-type situation, where the streams don't have distinct
roles and so don't need to be given role labels.  As far as I know,
current videoconference systems don't put each video stream in a
separate m= line.

Dale

---

From: Bernard Aboba <[email-masked]>
Date: Tue, 23 Apr 2013 12:17:18 -0700

If you have several devices per host (e.g. Multiple cameras) each using simulcast or layered coding, are supporting screen sharing/data channel/audio+video and also have a single m= line for each RTP stream, then this isn't so outlandish.

---

From: "Mo Zanaty (mzanaty)" <[email-masked]>
Date: Tue, 23 Apr 2013 21:03:59 +0000

You can easily exhaust the dynamic payload type number space (96-127) with only a few media lines, not 30. Keep in mind the primary purpose of payload type is to negotiate codecs, not demux different streams. An offer from a highly interoperable product will contain many payload types for each stream. It is not uncommon to support 8+ payload types and 4+ streams, which quickly exhausts the dynamic space. Also keep in mind that many codecs have different configurations that are expressed as different payload types, so even supporting a single audio and video codec can yield many payload types if those codecs are highly configurable.

Consider a very simple product (smartphone) in a very simple use case (3-way video chat). It supports several audio codecs (OPUS, AAC-LD, AMR-WB, AMR-NB, G.711) and several video codecs (VP8, VP9, H.264, H.265). It supports several H.264 profiles (BP, HP, SBP, SHP) and packetization modes (0, 1). This already exhausts all 32 dynamic payload types, before we even consider things like FEC, scalable or simulcast layers sent via MST, screen sharing, multiple cameras, etc.

So I would strongly discourage folks from assuming payload type demux is viable in most use cases. It may be viable when there is a single audio and video stream, each using a single codec and configuration. But it quickly becomes impractical or impossible when the product gets more capable or the use case gets more interesting.

Mo

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Dale R. Worley
Sent: Tuesday, April 23, 2013 2:58 PM
To: [email-masked]
Subject: Re: [rtcweb] #15: Section 4.8: SSRC signaling

Dale
_______________________________________________
rtcweb mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/rtcweb

---

From: Magnus Westerlund <[email-masked]>
Date: Wed, 24 Apr 2013 09:50:57 +0200

Thanks,

I fully support this argument, why you can't start using the PT as an
identifier to which purpose or specific negotiated set of constraints
within a common RTP session this SSRC relates to.

I would however note that this discussion would be better to hold on the
MMUSIC list, especially as it does apply to a statement in BUNDLE which
I believe must be changed:

Se Section 7.2 of draft-ietf-mmusic-sdp-bundle-negotiation-03

 o  - The dynamic payload type values used in the "m=" lines MUST NOT
      overlap.

This restriction I think must be changed. I will now forward this email
to MMUSIC as comment on BUNDLE.

Cheers

Magnus

On 2013-04-23 23:03, Mo Zanaty (mzanaty) wrote:
> You can easily exhaust the dynamic payload type number space (96-127)
> with only a few media lines, not 30. Keep in mind the primary purpose
> of payload type is to negotiate codecs, not demux different streams.
> An offer from a highly interoperable product will contain many
> payload types for each stream. It is not uncommon to support 8+
> payload types and 4+ streams, which quickly exhausts the dynamic
> space. Also keep in mind that many codecs have different
> configurations that are expressed as different payload types, so even
> supporting a single audio and video codec can yield many payload
> types if those codecs are highly configurable.
> 
> Consider a very simple product (smartphone) in a very simple use case
> (3-way video chat). It supports several audio codecs (OPUS, AAC-LD,
> AMR-WB, AMR-NB, G.711) and several video codecs (VP8, VP9, H.264,
> H.265). It supports several H.264 profiles (BP, HP, SBP, SHP) and
> packetization modes (0, 1). This already exhausts all 32 dynamic
> payload types, before we even consider things like FEC, scalable or
> simulcast layers sent via MST, screen sharing, multiple cameras,
> etc.
> 
> So I would strongly discourage folks from assuming payload type demux
> is viable in most use cases. It may be viable when there is a single
> audio and video stream, each using a single codec and configuration.
> But it quickly becomes impractical or impossible when the product
> gets more capable or the use case gets more interesting.
> 
> Mo
> 
> 
> -----Original Message----- From: [email-masked]
> [mailto:[email-masked]] On Behalf Of Dale R. Worley Sent:
> Tuesday, April 23, 2013 2:58 PM To: [email-masked] Subject: Re:
> [rtcweb] #15: Section 4.8: SSRC signaling
> 
>>> My understanding is that associating an incoming RTP packet with
>>> an m= line is a solved problem -- the transport association on
>>> which the packet arrives determines the bundle, and (within all
>>> of the currently active bundling proposals) the payload type
>>> tells which m= line within the bundle.
>> 
>> Not so.  If you have five PTs on each m= line, and 30 m= lines,
>> you just don't have that many PTs available.  At some point you
>> have to recognize that SSRC is what you have to use.  (Neither
>> number is extraordinary.)
> 
> videoconference-type situation, where the streams don't have
> distinct roles and so don't need to be given role labels.  As far as
> I know, current videoconference systems don't put each video stream
> in a separate m= line.
> 
> Dale _______________________________________________ rtcweb mailing
> list [email-masked] https://www.ietf.org/mailman/listinfo/rtcweb 
> _______________________________________________ rtcweb mailing list 
> [email-masked] https://www.ietf.org/mailman/listinfo/rtcweb
> 
> 

-- 

Magnus Westerlund

---

From: [email-masked] (Dale R. Worley)
Date: Thu, 25 Apr 2013 18:20:30 -0400 (EDT)

> From: Bernard Aboba <[email-masked]>
> 
> If you have several devices per host (e.g. Multiple cameras) each
> using simulcast or layered coding, are supporting screen
> sharing/data channel/audio+video and also have a single m= line for
> each RTP stream, then this isn't so outlandish.

I was working on an essay based on the assumption that a single video
capture is carried over a single m= line (with the various component
streams (simulcast, FEC, layered encoding, etc.) sent using different
SSRCs)...  But that isn't how existing systems work, and it may not be
workable at all.  It would be nice to correct that, but that probably
isn't the quick way to get products to market.  ;-)

If multiplexing based on payload type is unworkable, how about the
following technique.  (Forgive me if someone else has already proposed
it.)

    Each SSRC is demultiplexed based on an RTCP SDES item that gives
    the mapping between the SSRC and the m= line via which it is
    presented to the application layer (that is, the constituent m=
    line sequence number).

When a media stream with new SSRC is sent, the sender inserts an RTCP
SDES item with a special multiplexing "item type".  The SDES item
contains the SSRC value and the sequence number of the m= line via
which that SSRC is obtained from the application layer.  The sender
resends this SDES item occasionally.

The receiver keeps a table which maps the SSRCs to the m= lines via
which each SSRC is to be presented to the application.  Entries in the
table are added/updated when the multiplexing SDES items are received.

Since SDES items are meant to describe the "source" of the media
stream, using an SDES item to identify how the media is supplied by
the application is close to its intention.  (If one doesn't like that,
we could define another RTCP packet type.)

This mechanism only adds one 8 byte SDES item periodically in the RTCP
(given that RTCP packets often contain SDES packets, so the SDES
packet header isn't charged to multiplexing).  The overhead is reduced
to 4 bytes if the RTCP periodically contains SDES items for the SSRC
anyway.

        0                   1                   2                   3
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
header |V=2|P|    SC   |  PT=SDES=202  |             length            |
       +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
chunk  |                          SSRC                                 |
  1    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |     MUX=11    |     length=1  |0|m= line seq. |  NULL=0       |
       +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
chunk  |                          ...                                  |
  2

With dexterous use of pseudo-UTF-8 encoding to encode sequence
numbers, an 8 byte item suffices for the typical case, but we still
support multiplexing an unlimited number of m= lines, and even support
multiplexing m= lines that specify multiple addresses or ports.

This method allows multiplexing to support whatever use of m= lines
the overlying application supports/requires, since it places no
restrictions on the SDP or RTP usage.

In addition, demultiplexing is stable even while the bundling is
changing due to a new offer/answer exchange, because the SSRC on the
incoming RTP packets will be stable, even while the media stream is
redirected from one transport endpoint (for the old bundle) to another
transport endpoint (for the new bundle).

Dale

---

From: Martin Thomson <[email-masked]>
Date: Thu, 25 Apr 2013 16:06:47 -0700

> isn't the quick way to get products to market.  ;-)

Unless you count Lync.  It uses one m= line for a
capture/source/hobbit, including layering and FEC.

It's totally workable.  The signaling that Lync uses might cause mild
discomfort or bleeding from the ears for some implementations, but it
can work.

>     presented to the application layer (that is, the constituent m=

It's been proposed.  I don't know exactly why it wasn't considered
worth pursuing.

Maybe you can ask Peter Thatcher to share his document on demux.  It's
a reasonable taxonomy of the available options. Better than what I'm
able to write up in a short time.

---

From: [email-masked] (Dale R. Worley)
Date: Mon, 29 Apr 2013 17:59:42 -0400 (EDT)

> able to write up in a short time.

What I can find is draft-pthatcher-mmusic-many-sources-00, but it
doesn't seem to describe demultiplexing.

That draft does contain a small error:

   o  With BUNDLE, use of RFC5576 a=ssrc attributes is required in order
      for the recipient to be able to properly demultiplex incoming RTP.
      Payload type isn't sufficient as a demux point, since RTCP packets
      don't contain RTP payload types.  Therefore, this approach
      requires both sides to understand RFC5576, just like the single-m-
      section approach.

a=ssrc attributes are not strictly needed, because RTCP packets
contain SSRC identifiers, and RTP packets contain both SSRC and PT.
So caching the SSRC/PT correspondence seen in the RTP packets allows
the RTCP packets to be assigned to the proper m= lines.

This matters because a=ssrc attributes are problematic; we want to
add, remove, and adjust video flows without additional offer/answer
cycles, which precludes adding or changing a=ssrc attributes in the
SDP to handle the new flow.  (This is requirement 3 in
http://www.ietf.org/proceedings/interim/2013/02/05/rtcweb/slides/slides-interim-2013-rtcweb-1-10.pdf,
"Add/remove one way video flows with minimal chance of glare on
non-legacy apps" and DES F11 in draft-worley-sdp-bundle.)

Dale

---

From: Bernard Aboba <[email-masked]>
Date: Mon, 29 Apr 2013 15:22:57 -0700

On Apr 29, 2013, at 2:59 PM, "Dale R. Worley" <[email-masked]> wrote:

> SDP to handle the new flow.  

[BA] The PT/SSRC mapping only works if each PT maps to only one m= line (and you don't run out of PTs). Also, without a parameter in an SDES report you might get a receiver report from an SSRC without corresponding RTP packets to allow mapping the SSRC to an m= line.