Subject: [AVTCORE] Fwd: I-D Action: draft-westerlund-avtcore-multistream-and-simulcast-00.txt

From: Magnus Westerlund <[email-masked]>
Date: Tue, 5 Jul 2011 12:54:13 +0200

WG,

As an individual Bo Burman and I have written this internet draft that
discusses multistream and simulcast issues and proposes a set of
extensions to resolve the issues. Feedback is much appreciated.

Cheers

Magnus

Subject: I-D Action: draft-westerlund-avtcore-multistream-and-simulcast-00.txt
From: "[email-masked]" <[email-masked]>
To: "[email-masked]" <[email-masked]>
Date: Tue, 5 Jul 2011 00:59:37 +0200
List-Id: Internet Draft Announcements only <i-d-announce.ietf.org>

A New Internet-Draft is available from the on-line Internet-Drafts directories.

	Title           : RTP Multiple Stream Sessions and Simulcast
	Author(s)       : Magnus Westerlund
                          Bo Burman
	Filename        : draft-westerlund-avtcore-multistream-and-simulcast-00.txt
	Pages           : 60
	Date            : 2011-07-04

   RTP has always been a protocol that supports multiple participants
   each sending their own media streams in an RTP session.
   Unfortunately many implementations aimed only at point to point voice
   over IP with a single source in each end-point.  Even client
   implementations aimed at video conferences have often been built with
   the assumption around central mixers that only deliver a single media
   stream per media type.  Thus any application that wants to allow for
   more advance usage where multiple media streams are sent and received
   by an end-point has a problem with legacy.  This issue is analyzed,
   and RTP clarifications and signalling extensions are proposed to
   handle this issue.  A related issue is how to perform simulcast, in
   the meaning of sending multiple encodings or representations of the
   same media source, when using RTP for media transport.  This is
   further analyzed and possible solutions discussed and we arrive at a
   conclusion for session multiplexing of simulcast versions.  We also
   found a number of related issues when having multiple streams and
   simulcast.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-westerlund-avtcore-multistream-and-simulcast-00.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

This Internet-Draft can be retrieved at:
ftp://ftp.ietf.org/internet-drafts/draft-westerlund-avtcore-multistream-and-simulcast-00.txt
_______________________________________________
I-D-Announce mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/i-d-announce
Internet-Draft directories: http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

---

From: Roni Even <[email-masked]>
Date: Mon, 11 Jul 2011 10:56:04 +0300

Hi Magnus,
Read the draft, I liked the analysis on the different multiplexing of RTP
streams (Session, SSRC and payload type).

Some review comments

1. The introduction talks about multistream and simulcast. I noticed that it
only talks about how to define the alternatives in terms of the stream but
is not saying how to understand the semantics of the streams, for example
which camera in Telepresence and in simulcast you assume that all
alternative provide the same view (just resolution change, but can also use
different view of the room). This is fine and is being discussed in CLUE at
the moment and should be out of scope here but it may cause the SDP to be
even larger. 

2. On the SDP syntax it may be better when you have more than one m-line to
have all the descriptions which repeats in all m-line appear st the SDP
session level with local identifier and use the identifier in the m-lines.
Maybe based on grouping.

3. In section 1.1 "Todays SDP signalling support for this is basically the
directionality attribute which indicates an end-point intend to send media
or not.  No indication of how many media streams." My understanding so far
was that the number of PT in the m-line is the maximum number of streams
that can be sent in an RTP session. This  goes also to the discussion on
support of multiple SSRCs. I think that today video conferencing endpoint is
doing a second offer answer to fix the PT it will use based on the first
offer answer exchange. 

4. The above still does not address the multiple SSRC for the same PT and I
already mentioned it in the past that I think that a lot of product today
will not handle it good. I think that this is a rare case today at least in
centralized video conferencing since the MCU (or RTP mixer if exist) will
use its own SSRC to send the mixed/switched media.

5. In section 3.2 second paragraph you talk about the receivers controlling
what the relay will send but this will make the relay something else than
RTP translator.

6. On the bandwidth support. Currently the definition is the b= is a
receiver capability. I am not sure why you need the sender one, you claim
that there is no way to control the actual bw but the receiver can use RTCP
CCM flow control to tell the sender to reduce the rate. As for the syntax,
my preference is for TIAS semantics and not the one you proposed. 

7. In the last sentence of 7.2.1 you say "This enables a simple fallback
solution to exclude a legacy client from all simulcast versions except one,
whichever is most suitable for the application". My view is that currently
when there are several m-lines of the same media type there is no definition
which one to choose if the answerer do not understand the semantics of the
offer and can support only one stream.

Roni Even

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Magnus Westerlund
> Sent: Tuesday, July 05, 2011 1:54 PM
> To: IETF AVTCore WG
> Subject: [AVTCORE] Fwd: I-D Action: draft-westerlund-avtcore-
> multistream-and-simulcast-00.txt
> 
> WG,
>

---

From: Randell Jesup <[email-masked]>
Date: Mon, 11 Jul 2011 11:43:39 -0400

On 7/11/2011 3:56 AM, Roni Even wrote:
> that can be sent in an RTP session.

I've never heard of this (perhaps it's an issue with the meaning of 
stream in "number of streams
that can be sent in an RTP session").  The number of distinct payloads, 
yes.  But in theory
(though not well supported, if at all) you could have a mixer providing 
N "streams", all of the
same payload or different ones (with different SSRCs).

I think it's just a terminology issue (and given the relative positions, 
I'm probably the one who's
wrong).  :-)  But I'll note your comment isn't clear to me, and it 
should be.

> This  goes also to the discussion on

They may be; I mostly work with devices designed for point-to-point - 
but that means that
entire conferences either get locked down to the 
lowest-common-denominator codec, or
it demands the MCU transcode.  I personally prefer to leave multiple 
payloads/codecs
to allow endpoints to switch payloads in order to help adapt to various 
things, like network
conditions.  In theory, an endpoint could even switch between voice 
codecs and
better-at-music-audio-codecs when they detect music, as a random 
non-network example.
I don't know if the non-network use-cases would be compelling, but the 
network adaptation
are compelling, given the time (and possible failures) required to 
re-INVITE.

> use its own SSRC to send the mixed/switched media.

Some devices reuse the same incoming ports for multiple sessions, both 
within a call and
between different calls they're involved in or are acting as a 
conference bridge.  As mentioned
previously, you're right that many endpoints don't deal well (or 
consistently) with multiple
SSRCs in a session.

> my preference is for TIAS semantics and not the one you proposed.

Well, knowing what rate the sender plans to use *could* be useful in 
deciding how many
resources (memory, CPU/DSP horsepower, etc) might be needed and so help 
the other side
plan or (if it's answering) help it decide how to answer (number of 
streams, codecs to accept, etc).

The fact that it could be useful doesn't always mean that it's a good 
idea to complicate the protocol
to support it directly, however.

> offer and can support only one stream.

Agreed - there's no definition; however almost all clients that don't 
support multiple m= lines
of the same type will select the first one, or the first one that they 
can find a matching payload for.

-- 
Randell Jesup
[email-masked]

---

From: Roni Even <[email-masked]>
Date: Mon, 11 Jul 2011 19:55:54 +0300

Inline
Roni

> Sent: Monday, July 11, 2011 6:44 PM
> To: [email-masked]
> Subject: Re: [AVTCORE] Fwd: I-D Action: draft-westerlund-avtcore-
You are if you do ssrc multiplex, I assumed that if you do session multiplex
you do not do ssrc multiplex but of course this is allowed.
> are compelling, given the time (and possible failures) required to

This is the same point that EP will try to keep one PT in a point to point
or MCU that terminates the call leg, and they do not expect SSRC
multiplexing as mentioned in the next point

> Audio/Video Transport Core Maintenance
> [email-masked]
> https://www.ietf.org/mailman/listinfo/avt

---

From: Jonathan Lennox <[email-masked]>
Date: Thu, 14 Jul 2011 18:35:29 -0400

> extensions to resolve the issues. Feedback is much appreciated.

Hi, Magnus.

Thank you for writing this draft; I think multi-stream is a very important area of RTP, one that's hasn't had enough attention paid to it.

The draft discusses a number of different issues: multi-stream, simulcast, RTX, FEC, etc., but seems to assume that these are separate-but-related problems that can be solved independently, possibly with different solutions to the different problems.

I don't believe that this is the case; instead, I believe that in practice you will end up with sessions carrying multiple sources, each of which could be be simulcast, with RTX and FEC being used independently for any or all of the simulcast streams.  Thus we need one solution that can handle all these problems at once, including the interactions among them.  (Vidyo has been doing multi-stream with scalable coding for many years.)

As the draft concludes, the multi-stream scenario is best handled by SSRC-multiplexing, as was originally envisioned by RTP.  Given that this is the case, it's not clear to me that it's a good idea to use a separate (and in my opinion, less flexible) mechanism for the specific special case of simulcast.  Instead, given the pressure from groups such as RTCweb to reduce the port consumption of RTP, I'd recommend SSRC-multiplexing across the board.

Note also that in the case of multiple sources which are each independently simulcast, the simulcast structure of different sources could well be different.   (E.g., source A could be available in two resolutions, while source B has only one and source C has three.)  It'd be extremely difficult to map this in session-multiplexed simulcast, whereas for SSRC-multiplexed simulcast it should be no more complex than the single-simulcast-source scenario. 

--
Jonathan Lennox
[email-masked]

---

From: Qin Wu <[email-masked]>
Date: Fri, 15 Jul 2011 12:11:15 +0800

Hi,
I have read this draft and think it is well written. Several comments below:
Section 1.2.  Simulcast
"
   Simulcast is the act of simultaneously sending multiple different
   versions of a media content.  This can be done in several ways and
   for different purposes.  This document focuses on the case where one
   wants to provide multiple different encodings towards a intermediary
   so that the intermediary can select which version to forward to other
   participants in the session.  More discussion on the different ways
   of doing simulcast, which is the focus of this document in "Simulcast
   Usage and Applicability" (Section 3).
"

   [Qin]:Suppose the multiple different version of the same media content
   is transmitted simultaneously to the receivers, how do you make sure
   these multiple streams can be recieved by the intermediary in between 
   at the same time and processed at the same time?

Section 1.2:

[Qin]: Have you considered the case where multiple streams are sent simultaneously to the same 
RTP receiver and Intermediary does not involve in simulcast processing. In other words,
the intermediary is transparent to simulcasting and the RTP receiver is powerful and intelligent enough to
deal with simucasting multiple streams.

Section 3.2.  Simulcasting to Consuming End-Point
"
   This usage is based on an RTP Transport Translator (Section 3.3:
   Topo-Trn-Translator) [RFC5117]. ........................
"

[Qin] It seems to me translator in the case described in section 3.2 
      also can send same encoding to multiple destinations or send
      different encoding to independent destination, It look like to me
      the case described in section 3.3 and section 3.4 are just two sub-cases
      under the case described in section 3.2.
      Also the mixer case described in section 3.1 has the same issue.
      would you like to clarify a little bit about this?

Section 3.3 Simulcasting to Consuming End-Point
"
  ...................... Thus some
   consideration and mechanism are needed to support such a use case so
   that it doesn't break RTCP reception reporting.

"
    [Qin] Do you have solution to the translator case since the translator is 
    transparent to the RTP receivers?

Section 3.3 Same Encoding to Multiple Destinations
"
  ... As this type of simulcast is analog to ASM usage and RTP has good
   support for ASM sessions, no further consideration for this case is
   done.
"

   [Qin]: Have you considered SSM case or ASM case which are also simucasted in this document?
Is the solution for SSM case different from the case you described in this document?

Regards!
-Qin
----- Original Message ----- 
From: "Magnus Westerlund" <[email-masked]>
To: "IETF AVTCore WG" <[email-masked]>
Sent: Tuesday, July 05, 2011 6:54 PM
Subject: [AVTCORE] Fwd: I-D Action:draft-westerlund-avtcore-multistream-and-simulcast-00.txt

> extensions to resolve the issues. Feedback is much appreciated.

--------------------------------------------------------------------------------

---

From: Magnus Westerlund <[email-masked]>
Date: Tue, 19 Jul 2011 14:31:48 +0200

Thanks for the comments,

Inline responses.

> the moment and should be out of scope here but it may cause the SDP to be

Exactly, I think the actual meta information about which streams is
captured in relation to another is for the external application to take
care of, or at least another part of the system. As you say, CLUE WG's
work is highly relevant in this.

> session level with local identifier and use the identifier in the m-lines.

I don't quite understand you. Which parts repeats? An example may look
like it repeats a lot, but there is actually not a lot of information
that are redundant, or exactly the same.

CNAMEs are by design the same. However that repetition comes due to us
reusing existing attribute which is actually one of our main points. We
want to reuse the existing signalling attributes rather than redefine
with some alteration.

> doing a second offer answer to fix the PT it will use based on the first

Personally I have seen no binding between the number of streams and the
number of PTs. A m= line with a single PT can have 100 SSRSs sending
media in the RTP session. If you believe such a rule exist, then I would
like to press you for quoting that text that specifies that.

> use its own SSRC to send the mixed/switched media.

Exactly, I think the reasonable assumption with a legacy terminal is
that it handles one stream in and one stream out per RTP session. That
is why we want to introduce these new SDP attributes to indicate
capability of receiving or intention to send multiple streams in the
same RTP session.

> what the relay will send but this will make the relay something else than

Yes, but I think it is a reality that already is in use in some RTP
derivate systems. You want a simple non media processing box, at the
same time you want to limit the bandwidth consume somehow. Thus you need
to do dynamic selection of the streams. At the same time you don't want
the concept of the RTP session with a joint SSRC space and reporting to
break. Thus I think there is need for work towards this model also.

However, this is not something that is Bo's and my intention to focus
on. I just identify that in this usage we have short commings.

> my preference is for TIAS semantics and not the one you proposed. 

If you with TIAS semantics you mean the "media bitrate" without the
header overhead? The draft actually has this an open issue in the
document, if one should include IP level or not.

Page 19-20:
   It is an open
   question exactly what this token bucket is measuring, if it is RTP
   payload only, like TIAS, or if it includes all headers down to the IP
   level as most of the other bandwidth modifiers do.

We need a send direction for various reasons actually. For example in
Send only streams, one like to indicate what the highest bandwidth one
intended to send. The receiver may reduce it further, but he should have
some value of the desired maximum bit-rate the sender invite to use. Or
answering a SDP offer. If the offerer has offered to receive 4 payload
types with various bit-rates it makes sense to declare for the sender
the highest it intends to generate for any of the payload types it
supports. Also, without improved directionality capabilities one can't
express that you can receive 3 mbps, but only intended to send 1.5 mbps.

It is a matter of making the capabilities and the actual configured
usage being known to the parties.

> offer and can support only one stream.

Yes, there might be interoperability issues there, but the most likely
behavior for a client that doesn't know what to do with streams is to
set the port to 0 for anything but the first, or maybe the one with
a=content:main.

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: Magnus Westerlund <[email-masked]>
Date: Tue, 19 Jul 2011 14:52:35 +0200

Jonathan,

Thanks for the comments.

See inline for further comments.

On 2011-07-15 00:35, Jonathan Lennox wrote:
>> As an individual Bo Burman and I have written this internet draft
>> that discusses multistream and simulcast issues and proposes a set
>> of extensions to resolve the issues. Feedback is much appreciated.
> 
> 
> Hi, Magnus.
> 
> Thank you for writing this draft; I think multi-stream is a very
> important area of RTP, one that's hasn't had enough attention paid to
> it.
> 
> The draft discusses a number of different issues: multi-stream,
> simulcast, RTX, FEC, etc., but seems to assume that these are
> separate-but-related problems that can be solved independently,
> possibly with different solutions to the different problems.
> 
> I don't believe that this is the case; instead, I believe that in
> practice you will end up with sessions carrying multiple sources,
> each of which could be be simulcast, with RTX and FEC being used
> independently for any or all of the simulcast streams.  Thus we need
> one solution that can handle all these problems at once, including
> the interactions among them.  (Vidyo has been doing multi-stream with
> scalable coding for many years.)

I try to take as encompassing view of this as possible. Yes, we don't
include RTX or FEC in the discussion currently. I think mostly because
we didn't need to. RTX clearly has two different modes, either SSRC or
Session multiplexing. FEC depends on which type of FEC one intend to use
for what multiplexing that is available.

I think we should try to make clear indications going forward for how
these should be structured in future extensions.

> 
> As the draft concludes, the multi-stream scenario is best handled by
> SSRC-multiplexing, as was originally envisioned by RTP.  Given that
> this is the case, it's not clear to me that it's a good idea to use a
> separate (and in my opinion, less flexible) mechanism for the
> specific special case of simulcast.  Instead, given the pressure from
> groups such as RTCweb to reduce the port consumption of RTP, I'd
> recommend SSRC-multiplexing across the board.

Jonathan lets me ask you a question. Is any hesitation to use several
RTP sessions when most suitable due to the port consumption issue or for
some other reason? And here we can debate what is most suitable.

My view is that multiple SSRCs in an RTP session is a very good
mechanism for streams that one expect to be treated the same way in both
central nodes or in end-points. When it comes to sets of streams that
needs a different treatment, I think it is logical and a powerful
construct to use the RTP session for separating these sets of streams.

Yes, the number of underlying transport flows is an important concern in
some use cases. But, I think we shouldn't use that as a reason for
removing an important concept in RTP. If the issue we have is that one
RTP session results in one UDP flow, then lets do something about that
instead of removing the RTP session concept.

> 
> Note also that in the case of multiple sources which are each
> independently simulcast, the simulcast structure of different sources
> could well be different.   (E.g., source A could be available in two
> resolutions, while source B has only one and source C has three.)
> It'd be extremely difficult to map this in session-multiplexed
> simulcast, whereas for SSRC-multiplexed simulcast it should be no
> more complex than the single-simulcast-source scenario.

This is a valid concern, but which I think we have a reasonable straight
story for. In the direction you have a certain number of simulcast
versions you negotiate that number of session and their individual
configurations.

If one looks at the example in Section 8.5.2.2, you see that we have
there 3 simulcast versions going towards a central mixer. The return
channel from the mixer are only two different sessions, supporting to
receive all the possible payload types we can get from the other
participants. And the difference between these two return sessions are
if they are content:main or content:alternative. In other words what we
do with the streams locally when rendering them.

The two main points we have for choosing Session multiplexing is:
A) RTP sessions provides a context for what purpose the streams in them
have.

B) We don't need to define any new signalling to negotiate the different
simulcast levels. Only a bit of binding together the streams and we are
done. The SCS and SCR grouping semantics and the SRCNAME is really all
we require for getting session multiplexed simulcast to work. The rest
is to provide improvements over todays order when it comes to bandwidth
signalling and media control in centralized conferencing.

cheers

Magnus Westerlund

---

From: Magnus Westerlund <[email-masked]>
Date: Tue, 19 Jul 2011 15:08:20 +0200

Qin,

Thanks for your comments.

See inline for follow-up.

>    at the same time and processed at the same time?

If you have an conference session using a centralized mixer then you
normally negotiate the setup with the conference server, that is the
controling entity of the mixer. Thus, that side ensures that the mixer
and the client really are agreeing on using simulcast.

> deal with simucasting multiple streams.

Yes, that is what Section 3.2, really tries to discuss. We are
considering it, but it is not our main case.

>       would you like to clarify a little bit about this?

To certain degree I think you are correct. Clearly a relay and a full
mesh transport is equivalent from a high level functionality
perspective. Their impact on parts of the system is clearly different.

However, that is not the main difference between 3.2 and 3.3. In 3.3 all
peers receive the same encoding, while the 3.2 client receives multiple
encodings of the same version. That is the more fundamental difference.

When it comes to 3.4 compared to 3.2. In 3.4 party A receives one
version of the encoding, but it is different from what is neighbor,
party B, receives. In addition there is no need in that case for A and B
to be aware of each other. If A and B needs to be aware when receiving
content C then I think that usage maps better onto 3.1.

>     transparent to the RTP receivers?

No, we don't have a solution. We identify this solution because I have
heard about conferencing solutions that operates under very similar
premises with end-points or a central control selecting which streams to
deliver and where it sounds much more like a basic transport relay than
an RTP mixer, selecting streams onto the Mixer's own SSRC values.

If there is desire to support this use case, then the proponents for
this should propose something.

> Is the solution for SSM case different from the case you described in this document?

We haven't considered SSM or ASM specifically. It was not our focus.
However, I think Session multiplexed simulcast is a given in any cases
where the sender wants to use simulcast. That as sessions can be mapped
onto different multicast groups, thus allowing a receiver to jump
between the simulcast representations based on each receivers need. That
is not possible for SSRC multiplexed simulcast.

Cheers

Magnus Westerlund

---

From: Roni Even <[email-masked]>
Date: Tue, 19 Jul 2011 21:27:59 +0300

Hi Magnus,

> want to reuse the existing signalling attributes rather than redefine
Three options using your example from 8.5.1.2, the second I am not sure
since it may change the SDP SSRC syntax

1.   v=0
   o=alice 2890844526 2890842807 IN IP4 192.0.2.156
   s=Telepresence Alice Invite
   c=IN IP4 192.0.2.156
   b=AS:8965
   t=0 0
   
   param = 1 cname:[email-masked]
   param = 2 srcname:a3:d3:4b:f1:22:12
   param = 3 srcname:12:3f:ab:d2:ec:32
   param = 4 srcname:7f:12:db:87:2d:52

   m=audio 49200 RTP/AVP 97 96
   b=AS:725
   a=rtpmap:96 G719/48000/2
   a=rtpmap:97 G719/48000
   a=bw:send pt=96 SMT:tb=128800:1500
   a=bw:send pt=97 SMT:tb=64800:1500
   a=bw:recv pt=* AMT:tb=644000:1500
   a=max-recv-ssrc:* 5
   a=max-send-ssrc:97 3
   a=max-send-ssrc:96 1
   a=ssrc:239245219 param:1
   a=ssrc:239245219 param:2
   a=ssrc:986545121 param:1
   a=ssrc:986545121 param:3
   a=ssrc:2199983234 param:1
   a=ssrc:2199983234 param=4
   m=video 49300 RTP/AVP 96
   b=AS:8240
   a=rtpmap:96 H264/90000
   a=fmtp:96 profile-level-id=42c01e
   a=imageattr:* send [x=1280,y=720] recv [x=1280,y=720]
   a=bw:send pt=96 SMT:tb=2500000:8192
   a=bw:recv pt=96 SMT:tb=3000000:8192
   a=bw:send pt=* AMT:tb=8000000:16384
   a=max-recv-ssrc:* 5
   a=max-send-ssrc:* 3
   a=ssrc:245219239 param:1
   a=ssrc:245219239 param:2
   a=ssrc:545121986 param:1
   a=ssrc:545121986 param:3
   a=ssrc:199983234 param:1
   a=ssrc:199983234 param:4
   a=content:main

2.   v=0
   o=alice 2890844526 2890842807 IN IP4 192.0.2.156
   s=Telepresence Alice Invite
   c=IN IP4 192.0.2.156
   b=AS:8965
   t=0 0
   
   param = 1 cname:[email-masked] rcname:a3:d3:4b:f1:22:12
   param = 2 name:[email-masked] srcname:12:3f:ab:d2:ec:32
   param = 3 cname:[email-masked] srcname:7f:12:db:87:2d:52

   m=audio 49200 RTP/AVP 97 96
   b=AS:725
   a=rtpmap:96 G719/48000/2
   a=rtpmap:97 G719/48000
   a=bw:send pt=96 SMT:tb=128800:1500
   a=bw:send pt=97 SMT:tb=64800:1500
   a=bw:recv pt=* AMT:tb=644000:1500
   a=max-recv-ssrc:* 5
   a=max-send-ssrc:97 3
   a=max-send-ssrc:96 1
   a=ssrc:239245219 param:1
   a=ssrc:986545121 param:2
   a=ssrc:2199983234 param:3
   m=video 49300 RTP/AVP 96
   b=AS:8240
   a=rtpmap:96 H264/90000
   a=fmtp:96 profile-level-id=42c01e
   a=imageattr:* send [x=1280,y=720] recv [x=1280,y=720]
   a=bw:send pt=96 SMT:tb=2500000:8192
   a=bw:recv pt=96 SMT:tb=3000000:8192
   a=bw:send pt=* AMT:tb=8000000:16384
   a=max-recv-ssrc:* 5
   a=max-send-ssrc:* 3
   a=ssrc:245219239 param:1
   
   a=ssrc:545121986 param:2
   
   a=ssrc:199983234 param:3
   
   a=content:main

3. the shortest will be the ssrc-id=id:ssrc-value, the id will identify the
id to use in the media level with all the parameters except the other
ssrc-id's in the multi line. We can probably give a better syntax but it is
shorter.

   v=0
   o=alice 2890844526 2890842807 IN IP4 192.0.2.156
   s=Telepresence Alice Invite
   c=IN IP4 192.0.2.156
   b=AS:8965
   t=0 0

multi = cname:[email-masked] srcname:a3:d3:4b:f1:22:12
ssrc-id=1:239245219 ssrc-id=2: 245219239

multi= cname:[email-masked] srcname:12:3f:ab:d2:ec:32
ssrc-id=3:986545121 ssrc-id=4:545121986

 multi= cname:[email-masked] srcname:7f:12:db:87:2d:52
ssrc-id=5:2199983234 ssrc-id=6:199983234  

m=audio 49200 RTP/AVP 97 96
   b=AS:725
   a=rtpmap:96 G719/48000/2
   a=rtpmap:97 G719/48000
   a=bw:send pt=96 SMT:tb=128800:1500
   a=bw:send pt=97 SMT:tb=64800:1500
   a=bw:recv pt=* AMT:tb=644000:1500
   a=max-recv-ssrc:* 5
   a=max-send-ssrc:97 3
   a=max-send-ssrc:96 1
   a=multi:1
   a= multi:3
   a= multi:5
   
   m=video 49300 RTP/AVP 96
   b=AS:8240
   a=rtpmap:96 H264/90000
   a=fmtp:96 profile-level-id=42c01e
   a=imageattr:* send [x=1280,y=720] recv [x=1280,y=720]
   a=bw:send pt=96 SMT:tb=2500000:8192
   a=bw:recv pt=96 SMT:tb=3000000:8192
   a=bw:send pt=* AMT:tb=8000000:16384
   a=max-recv-ssrc:* 5
   a=max-send-ssrc:* 3
   a= multi:2 
   a= multi:4 
   a= multi:6
   a=content:main

Roni

---

From: Magnus Westerlund <[email-masked]>
Date: Wed, 20 Jul 2011 11:52:29 +0200

Hi Roni,

I understand what you are after. But, this looks very much like a
general change to the a=ssrc attribute, than something specific to our
proposed extension. That we propose a new SDES item seems to make it
clearer that the current structure isn't optimized for size. But the
question does it really matter. It is not like these SDP anyway results
in SIP packets that are below 1500 bytes.

It also creates a level of indirection, which isn't that problematic for
the machine interpretations but for humans.

Lets get back to it when we have agreed on the high level issues and
actually are doing the extension.

Cheers

Magnus

-- 

Magnus Westerlund

---

From: Jonathan Lennox <[email-masked]>
Date: Wed, 20 Jul 2011 13:44:43 -0400

Hi, Magnus -- thanks for the reply.

> some other reason? And here we can debate what is most suitable.

Part of it is port consumption, but more importantly, architecturally, is the problem that architectures that are designed around the "one source (in each direction) per session" assumption break badly in a whole lot of scenarios that are more complicated than the simple point-to-point one-source-per-media-type model.

> construct to use the RTP session for separating these sets of streams.

This is valid so long as you can make the simplifying assumption that you *can* treat every source in a session identically, blindly, with no further information about the content of each one.  But there are plenty of scenarios in which

> versions you negotiate that number of session and their individual

I'm not thinking about asymmetric sources in each direction -- I'm thinking about multiple, heterogeneous simulcast sources in the *same* direction.  In this case, it's really unclear how one would map the simulcast channels to multiple sessions. 

--
Jonathan Lennox
[email-masked]

---

From: Magnus Westerlund <[email-masked]>
Date: Thu, 21 Jul 2011 11:54:52 +0200

Hi Jonathan,

Good points although I am not certain I gotten your point in all the cases.

On 2011-07-20 19:44, Jonathan Lennox wrote:
>>> As the draft concludes, the multi-stream scenario is best handled
>>> by SSRC-multiplexing, as was originally envisioned by RTP.  Given
>>> that this is the case, it's not clear to me that it's a good idea
>>> to use a separate (and in my opinion, less flexible) mechanism
>>> for the specific special case of simulcast.  Instead, given the
>>> pressure from groups such as RTCweb to reduce the port
>>> consumption of RTP, I'd recommend SSRC-multiplexing across the
>>> board.
>> 
>> Jonathan lets me ask you a question. Is any hesitation to use
>> several RTP sessions when most suitable due to the port consumption
>> issue or for some other reason? And here we can debate what is most
>> suitable.
> 
> Part of it is port consumption, but more importantly,
> architecturally, is the problem that architectures that are designed
> around the "one source (in each direction) per session" assumption
> break badly in a whole lot of scenarios that are more complicated
> than the simple point-to-point one-source-per-media-type model.
> 

I fully agree, but fails to understand how multiple streams in each
direction in multiple sessions in one form is different from multiple
streams in multiple session in another way is different.

Session based simulcast will use m RTP sessions per media type with N
streams in them.

SSRC multiplexed simulcast will use 1 RTP session per media type with
m*N streams in them.

In both cases we both have multiple streams and multiple RTP sessions.
It is primarily the number of RTP sessions that is the varying factor.

>> mechanism for streams that one expect to be treated the same way in
>> both central nodes or in end-points. When it comes to sets of
>> streams that needs a different treatment, I think it is logical and
>> a powerful construct to use the RTP session for separating these
>> sets of streams.
> 
> This is valid so long as you can make the simplifying assumption that
> you *can* treat every source in a session identically, blindly, with
> no further information about the content of each one.  But there are
> plenty of scenarios in which

Yes, I agree that there are scenarios where you will need to have
detailed understanding of what exactly each stream is. But
SSRC-multiplexed simulcast needs one to always have this control
independently if one needs it or not just to get it working. Thus
preventing applications that can be done simpler to be simpler.

>>> independently simulcast, the simulcast structure of different
>>> sources could well be different.   (E.g., source A could be
>>> available in two resolutions, while source B has only one and
>>> source C has three.) It'd be extremely difficult to map this in
>>> session-multiplexed simulcast, whereas for SSRC-multiplexed
>>> simulcast it should be no more complex than the
>>> single-simulcast-source scenario.
>> 
>> This is a valid concern, but which I think we have a reasonable
>> straight story for. In the direction you have a certain number of
>> simulcast versions you negotiate that number of session and their
>> individual configurations.
> 
> I'm not thinking about asymmetric sources in each direction -- I'm
> thinking about multiple, heterogeneous simulcast sources in the
> *same* direction.  In this case, it's really unclear how one would
> map the simulcast channels to multiple sessions.

That is exactly one of the case we are tackling, unless I misunderstand
you.

An end-point has 2 cameras in a telepresence room capturing different
parts of the participant table so they are of the same purpose in the
application. Those cameras (sources) we want to simulcast to a mixer in
3 qualities.

Then the upstream RTP Session usage would consist of 3 RTP sessions, one
for each quality tier. Within each of these RTP sessions there will be 2
streams (SSRCs) one for each camera sending media from the end-point to
the mixer.

The usage in the other direction can either be independent RTP sessions
or for example be overlapped with one the quality tiers (as we do in the
advanced examples in the draft).

When you talk about multiple sources, are they from the same end-point
of different end-points? If they are from the same end-point I think we
do have a working solution in this document.

If they are from different end-points I think we also have a solution as
long as we are talking mixer based sessions. Because in that case we can
negotiate each upstream end-point to the central mixer independently.
However, the mixer clearly needs to ensure that these streams match the
downstream capabilities setup to the other participants.

If we are talking relay based based then I think we have issues as we
have identified.

Cheers

Magnus Westerlund