Subject: [AVTCORE] multi session and avtcore-multiplex-architecture

From: "Roni Even" <[email-masked]>
Date: Fri, 23 Mar 2012 12:18:38 +0200

Hi,

After reading draft-westerlund-avtcore-multiplex-architecture-01.txt and
draft-alvestrand-rtp-sess-neutral-00.txt and looking at RFC3550 my view is
that what we can say in terms of RFC3550 is that we have support for two
modes: 

1.	RTP multisession where each session has a unique SSRC space with no
defined support for SSRC multiplexing across RTP sessions. 
2.	RTP single session that can support SSRC multiplexing in the single
session.

RTP session multiplexing is only defined based on transport multiplexing
(UDP ports).

The SDP support is based on the above description defining the transport
address for RTP session and SSRC per RTP media inside the session.

Section 5.2 of RFC 3550 does not forbid SSRC multiplexing of different media
types but lists some problems.

I would like to concentrate on problems 4 and 5.

Problem 4 talks about the difficulty an RTP mixer will have when
encountering multiple media types in the same RTP session. I think that this
problem is also relevant when having same media types in the same session if
they do not have the same usage (for example video of the room and of a
presentation but each can have its own RTP session). 

Problem 5 talks about supporting different QoS or different bandwidth usage
and again I think that this is true also for same media type like different
SVC layers or different video content.

So my understanding of the current state (RFC 3550) is that both SSRC
multiplexing using a single session can be used for different media types
and multisession using the transport layer (UDP) as the multiplex to make it
simpler for mixers and for specific network topologies should be the
recommended solutions. We will need to document all the issues discussed in
the multiplex architecture draft in order to help implementers choose the
right solution and add the required SDP to support it.

As for multiplexing multiple sessions using one transport connection (One
UDP port), I am not sure what is the value with regards to problem 4 and 5
considering the current RTP and network infrastructure that will not benefit
from this mode. I can see some value in having this mode providing a better
RTP layer structure for RTP session and RTP SSRC multiplexing that is not
based on the transport but defined in the RTP level, but I am not sure if
this is a good enough reason unless people have a strong requirement to use
a single port in all cases without considering the whole solution aspects.
For example if you want to supply different SVC layers in different sessions
(MST mode) in order to address bandwidth issues it does not make sense to
multiplex them to a single UDP port considering the current infrastructure
will not handle it per flow or if you want the presentation video and room
video to be handles differently use the transport based session
multiplexing.

Roni Even

---

From: Magnus Westerlund <[email-masked]>
Date: Sat, 24 Mar 2012 08:00:29 +0100

Hi,
(as individual)

No significant disagreement about your first part of the message. The
arguments in RFC 3550 are not really applicable for certain set of
applications. The list of limitations in Section 6.7 of
draft-westerlund-avtcore-multiplex-architecture-01 does not contain a
big smoking gun. They do need to be considered by an application
implementor so they can consider if they matter. We also forgot to list
in 6.7 one of the biggest issues in my mind, namely interworking as
discussed in section 6.3.1.

The issue there is that if one has an RTP session that is common across
multiple end-points using a central node, like an RTP translator, or a
media gateway then connecting an end-point that uses two RTP sessions
for audio and video with one that has a single session for both medias
can force that gateway/translator to perform SSRC translation. Which if
we uses SRTP forces an decrypt and encrypt cycle at that node in
addition to performing that translation. This would for example be the
case for the WebRTC legacy interop.

Thus you need the possibility to fallback to using multiple RTP sessions
to handle such situations. If you can support multiple RTP sessions over
a single flow you can still have a single transport flow and support
multiple RTP sessions.

On 2012-03-23 11:18, Roni Even wrote:
> 
> As for multiplexing multiple sessions using one transport connection
> (One UDP port), I am not sure what is the value with regards to problem
> 4 and 5 considering the current RTP and network infrastructure that will
> not benefit from this mode. I can see some value in having this mode
> providing a better RTP layer structure for RTP session and RTP SSRC
> multiplexing that is not based on the transport but defined in the RTP
> level, but I am not sure if this is a good enough reason unless people
> have a strong requirement to use a single port in all cases without
> considering the whole solution aspects. For example if you want to
> supply different SVC layers in different sessions (MST mode) in order to
> address bandwidth issues it does not make sense to multiplex them to a
> single UDP port considering the current infrastructure will not handle
> it per flow or if you want the presentation video and room video to be
> handles differently use the transport based session multiplexing.

I agree that one needs to understand what ones limitations are. But
there are reasons for using multiple RTP sessions that aren't connected
to the need for transport level separation. For example our proposal for
how to simulcast with RTP and utilizing existing signaling we put
different quality tiers in different RTP sessions. Also as discussed
above if one want to avoid a forklift upgrade of clients in a
multi-party applications that already uses multiple RTP session like for
audio and video then implementing a multiplexing shim based solution in
the new version of the client and the central node lets you use only a
single transport flow for all upgraded clients without changing any of
the logic and processing in clients and central node.

What I think is important to remember in this discussion is to not only
think about the applications oneself has. RTP is widely used and just
because oneself doesn't need a feature, there can be others that do need
it.

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: "Charles Eckel (eckelcu)" <[email-masked]>
Date: Sat, 24 Mar 2012 02:21:22 -0700

Hi Magnus,

Please see question inline.

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Magnus Westerlund
> Sent: Saturday, March 24, 2012 8:00 AM
> To: Roni Even
> Cc: 'IETF AVTCore WG'
> Subject: Re: [AVTCORE] multi session and avtcore-multiplex-architecture
> 
> Hi,
> (as individual)
> 

Instead, could you not have the RTP translator indicate that there is an SSRC collision toward the endpoint that is using two RTP sessions? Perhaps the problem is that the endpoint might be implemented such that it always wants to use the same SSRC across both RTP sessions, and thus it handles the "collision" by changing the SSRC for both RTP sessions to be a new problematically shared value.

Cheers,
Charles

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

---

From: "Roni Even" <[email-masked]>
Date: Sat, 24 Mar 2012 22:37:18 +0200

Hi Magnus,
I agree that for a signaling + media gateway it will be simpler to handle
the data for the Shim if it is out of the security context.
You need the signaling gateway to translate the SDP if multiple RTP session
using multiple source to multiple RTP sessions using one port. 

Roni

> From: Magnus Westerlund [mailto:[email-masked]]
> Sent: Saturday, March 24, 2012 9:00 AM
> To: Roni Even
> Cc: 'IETF AVTCore WG'
> Thus you need the possibility to fallback to using multiple RTP
> sessions to handle such situations. If you can support multiple RTP
> sessions over a single flow you can still have a single transport flow
> and support multiple RTP sessions.
> 
> > 4 and 5 considering the current RTP and network infrastructure that
> > will not benefit from this mode. I can see some value in having this
> > mode providing a better RTP layer structure for RTP session and RTP
> > SSRC multiplexing that is not based on the transport but defined in
> > the RTP level, but I am not sure if this is a good enough reason
> > unless people have a strong requirement to use a single port in all
> > cases without considering the whole solution aspects. For example if
> > you want to supply different SVC layers in different sessions (MST
> > mode) in order to address bandwidth issues it does not make sense to
> > multiplex them to a single UDP port considering the current
> > infrastructure will not handle it per flow or if you want the
> > presentation video and room video to be handles differently use the
> transport based session multiplexing.
> 
> to the need for transport level separation. For example our proposal
> for how to simulcast with RTP and utilizing existing signaling we put
> above if one want to avoid a forklift upgrade of clients in a multi-
> party applications that already uses multiple RTP session like for
> because oneself doesn't need a feature, there can be others that do
> need it.
> 
> Cheers
> 
> Magnus Westerlund
>