Subject: Re: [MMUSIC] RTP stream multiplexing in the fec framework

From: "Ali C. Begen (abegen)" <[email-masked]>
Date: Fri, 24 Apr 2009 11:13:08 -0700

Copying MMUSIC as this is relevant to:

http://www.ietf.org/internet-drafts/draft-ietf-mmusic-sdp-source-attributes-02.txt
http://www.ietf.org/internet-drafts/draft-ietf-mmusic-rfc4756bis-01.txt 

> -----Original Message-----
> From: Watson, Mark [mailto:[email-masked]] 
> Sent: Friday, April 24, 2009 11:02 AM
> To: Ali C. Begen (abegen); [email-masked]
> Subject: Re: RTP stream multiplexing in the fec framework
> 
> Ali,
> 
> What do you think the Framework should do ?

IMO, we should not restrict FEC to work only for session multiplexing (although I agree with you that doing so has many advantages).

I see a few key reasons why people would use SSRC multiplexing, one being to simplify the port operations on NAT traversal. One session means one hole on NAT for the RTP transport (rtcp port can be the same or different). So, some apps may use ssrc multiplexing.

I am about to finalize the 4756bis draft and so far my assumption has been that we would only do session multiplexing and use "a=group" for associations. This would not work for SSRC multiplexed streams, though. For that, we can use the "a=ssrc-group" attribute from Jonathan's draft.

> SSRC multiplexing of source and repair is possible and the 
> intention was to support this in the Framework, but if it is 
> not required we could simplify by supporting only port 
> multiplexing. Port multiplexing is more straightforwardly 
> backwards-compatible (I'm not sure what an RTP receiver does 
> if it is expecting just one SSRC and it sees two).

If it has a payload that it does not understand, it will discard it. If it understands and knows what the stream is for, it would just use it as if the stream was received from a different port.

Are there any comments/suggestions from MMUSIC?

-acbegen
 
> ...Mark
> 
> 
> On 4/24/09 10:53 AM, "Ali C. Begen (abegen)" <[email-masked]> wrote:
> 
> 
> 
> 	Mark, All,
> 	
> 	I have a question about multiplexing the source and 
> repair streams when they are both RTP. Currently, we have the 
> following text:
> 	
> 	(Start of section 4)
> 	
> 	   The FEC Framework is described in terms of an 
> additional layer
> 	   between the transport layer (e.g.  UDP or DCCP) and 
> protocols running
> 	   over this transport layer.  Examples of such 
> protocols are RTP, RTCP,
> 	   etc.  As such, the data path interface between the 
> FEC Framework and
> 	   both underlying and overlying layers can be thought 
> of as being the
> 	   same as the standard interface to the transport 
> layer - i.e. the data
> 	   exchanged consists of datagram payloads each 
> associated with a single
> 	   transport flow identified (in the case of UDP) by 
> the standard
> 	   5-tuple { Source IP Address, Source Transport Port, 
> Destination IP
> 	   Address, Destination Transport Port, Transport 
> Protocol }.  In the
> 	   case that RTP is used for the repair flows, the 
> source and repair
> 	   data may be multiplexed using RTP onto a single UDP 
> flow and must
> 	   consequently be demultiplexed at the receiver.  
> There are various
> 	   ways in which this multiplexing can be done, for 
> example as described
> 	   in [RFC4588].
> 	
> 	
> 	RFC 4588 mentions two ways of multiplexing RTP streams. 
> One is session multiplexing, where source and repair RTP 
> streams are in different RTP sessions (different dest 
> address/port). In this case, I don't have any issues, this 
> works beautifully with the framework.
> 	
> 	The other one is SSRC multiplexing where the source and 
> repair RTP streams have different SSRCs but are transmitted 
> in the same RTP session (which is a single UDP flow). Is the 
> text above saying that the framework also support this kind 
> of multiplexing? In other words, is using a single UDP flow 
> to carry source + FEC data acceptable when they have separate SSRCs?
> 	
> 	Not that FEC could not be used in this scenario, but as 
> I recall the framework required different UDP flows for 
> source and repair flows...
> 	
> 	BR,
> 	-acbegen
> 	
> 	
> 
>

---

From: Colin Perkins <[email-masked]>
Date: Mon, 27 Apr 2009 18:53:58 +0100

On 24 Apr 2009, at 19:13, Ali C. Begen (abegen) wrote:
> IMO, we should not restrict FEC to work only for session  
> multiplexing (although I agree with you that doing so has many  
> advantages).
>
> I see a few key reasons why people would use SSRC multiplexing, one  
> being to simplify the port operations on NAT traversal. One session  
> means one hole on NAT for the RTP transport (rtcp port can be the  
> same or different). So, some apps may use ssrc multiplexing.

The trend is clearly towards allowing multiplexing by RTP SSRC, to  
ease NAT traversal by reducing the number of UDP ports. By that  
argument, sending FEC data on the same port as the media it's  
protecting doesn't seem problematic. (I wouldn't want to see different  
media types on one port, but this is close enough related that I don't  
see a big issue).

> I am about to finalize the 4756bis draft and so far my assumption  
> has been that we would only do session multiplexing and use  
> "a=group" for associations. This would not work for SSRC multiplexed  
> streams, though. For that, we can use the "a=ssrc-group" attribute  
> from Jonathan's draft.
>
> If it has a payload that it does not understand, it will discard it.  
> If it understands and knows what the stream is for, it would just  
> use it as if the stream was received from a different port.
>
> _______________________________________________
> Fecframe mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/fecframe

-- 
Colin Perkins
http://csperkins.org/

---

From: "Ali C. Begen (abegen)" <[email-masked]>
Date: Mon, 27 Apr 2009 12:00:49 -0700

Is that a "yes" for ssrc-level grouping for FEC?

-acbegen 

> From: Colin Perkins [mailto:[email-masked]] 
> Sent: Monday, April 27, 2009 10:54 AM
> To: Ali C. Begen (abegen)
> Cc: Watson, Mark; [email-masked]; [email-masked]
> Subject: Re: [Fecframe] RTP stream multiplexing in the fec framework
>

---

From: "Rémi Denis-Courmont" <[email-masked]>
Date: Mon, 27 Apr 2009 22:14:46 +0300

Le vendredi 24 avril 2009 21:13:08 Ali C. Begen (abegen), vous avez écrit :
> IMO, we should not restrict FEC to work only for session multiplexing
> (although I agree with you that doing so has many advantages).
>
> I see a few key reasons why people would use SSRC multiplexing, one being
> to simplify the port operations on NAT traversal. One session means one
> hole on NAT for the RTP transport (rtcp port can be the same or different).
> So, some apps may use ssrc multiplexing.

I actually do not see the point of SSRC multiplexing at all. If you want to 
include FEC infos on the same transport tuple as the protected media data, why 
don't you use a separate payload type?

Using a separate SSRC on the same transport tuple will break compatiblity with 
receivers that only accept one session per socket at a time. Worse, it could 
break those pseudo-randomly, which would be hell from customer support 
perspective.

> I am about to finalize the 4756bis draft and so far my assumption has been
> that we would only do session multiplexing and use "a=group" for
> associations. This would not work for SSRC multiplexed streams, though. For
> that, we can use the "a=ssrc-group" attribute from Jonathan's draft.
>
> If it has a payload that it does not understand, it will discard it. If it
> understands and knows what the stream is for, it would just use it as if
> the stream was received from a different port.

That looks like the sanest (most backward compatible and NAT-friendly) option 
to me.

-- 
Rémi Denis-Courmont
http://git.remlab.net/cgi-bin/gitweb.cgi?p=vlc-courmisch.git;a=summary

---

From: "Ali C. Begen (abegen)" <[email-masked]>
Date: Mon, 27 Apr 2009 12:33:35 -0700

> From: Rémi Denis-Courmont [mailto:[email-masked]] 
> Sent: Monday, April 27, 2009 12:15 PM
> To: [email-masked]
> Cc: Ali C. Begen (abegen); Watson, Mark; [email-masked]
> Subject: Re: [MMUSIC] RTP stream multiplexing in the fec framework
> 
> multiplexing

You mean payload-type multiplexing? Then, they will share the same SSRC and seqnum space. The RTCP feedback including receiver reports or NACKS will be shared, too.

I guess section 5.2 of RFC 3550 provides good reasons for not doing this.

-acbegen

---

From: Colin Perkins <[email-masked]>
Date: Mon, 27 Apr 2009 21:52:35 +0100

On 27 Apr 2009, at 20:02, Marshall Eubanks wrote:
> On Apr 27, 2009, at 1:53 PM, Colin Perkins wrote:
...
>>> I see a few key reasons why people would use SSRC multiplexing,  
>>> one being to simplify the port operations on NAT traversal. One  
>>> session means one hole on NAT for the RTP transport (rtcp port can  
>>> be the same or different). So, some apps may use ssrc multiplexing.
>>
>> protecting doesn't seem problematic. (I wouldn't want to see  
>> different media types on one port, but this is close enough related  
>> that I don't see a big issue).
>
> If someone wanted to use SSRC multiplexing in a audio or video  
> conference with multiplexing (audio) or multiple displays (video),  
> and then wanted to apply SSRC multiplexed FEC to that (say for  
> sources on lossy wireless links), isn't there a danger that non-FEC  
> aware receivers would not do the right thing with the FEC ?

I don't think so. Non-FEC aware receivers would see an unknown payload  
type, which they should ignore. What's your specific concern with that  
scenario?

-- 
Colin Perkins
http://csperkins.org/

---

From: Colin Perkins <[email-masked]>
Date: Mon, 27 Apr 2009 22:01:47 +0100

Yes, for the purposes for grouping FEC and the original media, in  
cases where you're trying to reduce port usage.

Colin

On 27 Apr 2009, at 20:00, Ali C. Begen (abegen) wrote:
>> different
> mmusic mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mmusic

-- 
Colin Perkins
http://csperkins.org/

---

From: "Roni Even" <[email-masked]>
Date: Tue, 28 Apr 2009 00:20:46 +0300

Hi,
I support Colin's view and I think this is why you also specify media of
type audio, video and text for the fec stream enabling the multiplexing. I
think that maybe there will be a need for a parameter that defines the
relation between the original stream and the fec stream similar to the
grouping or to the red in RFC 2198
Roni Even

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Colin Perkins
Sent: Tuesday, April 28, 2009 12:02 AM
To: Ali C. Begen (abegen)
Cc: Watson, Mark; [email-masked]; [email-masked]
Subject: Re: [MMUSIC] [Fecframe] RTP stream multiplexing in the fec
framework

Colin

-- 
Colin Perkins
http://csperkins.org/

---

From: Colin Perkins <[email-masked]>
Date: Mon, 27 Apr 2009 23:09:48 +0100

On 27 Apr 2009, at 22:23, Marshall Eubanks wrote:
> On Apr 27, 2009, at 4:52 PM, Colin Perkins wrote:
>>>>> session means one hole on NAT for the RTP transport (rtcp port  
>>>>> can be the same or different). So, some apps may use ssrc  
>>>>> multiplexing.
>>>>
>>>> The trend is clearly towards allowing multiplexing by RTP SSRC,  
>>>> to ease NAT traversal by reducing the number of UDP ports. By  
>>>> that argument, sending FEC data on the same port as the media  
>>>> it's protecting doesn't seem problematic. (I wouldn't want to see  
>>>> different media types on one port, but this is close enough  
>>>> related that I don't see a big issue).
>>>
>>> sources on lossy wireless links), isn't there a danger that non- 
>>> FEC aware receivers would not do the right thing with the FEC ?
>>
>>
>> I don't think so. Non-FEC aware receivers would see an unknown  
>> payload type, which they should ignore. What's your specific  
>> concern with that scenario?
>
> I am trying to understand all of the worries expressed here
>
>
>  Separate audio and video streams SHOULD NOT be carried in a single
>  RTP session and demultiplexed based on the payload type or SSRC
>  fields.  Interleaving packets with different RTP media types but
>  using the same SSRC would introduce several problems:
>
> Using a different SSRC for each medium but sending them in the same  
> RTP session would avoid the first three problems but not the last two
>
>
> So, to be clear, what is proposed is to send the FEC repair stream  
> with one source address and port, but a different SSRC and payload  
> type (from the original stream) ?

As I understand it, this is being proposed as one option for sending  
FEC data (with the ability to send the FEC on a separate port as the  
other option). In terms of the last two points in section 5.2 of RFC  
3550, an RTP mixer that understands FEC can make use of the FEC data  
when mixing (and if it doesn't understand the FEC, the quality is  
degraded, but the mixer still works); and the only reason to use SSRC  
multiplexing here is specifically to use the same network path for the  
FEC and media, making the last point moot.

-- 
Colin Perkins
http://csperkins.org/

---

From: "Ali C. Begen (abegen)" <[email-masked]>
Date: Mon, 27 Apr 2009 15:59:48 -0700

Alright, looks like we need to have SSRC multiplexing for FEC, and thus, we need grouping support for it (a=ssrc-group). I'll revise the 4756bis and submit a new version for review.

One more question, though. Should we allow for "a=ssrc-group:FEC-XR" semantics only if SSRC multiplexing is used and mandate "a=group:FEC-XR" semantics for everything else (for non-RTP flows and when session multiplexing is used)? Or, should we also allow "a=ssrc-group:FEC-XR" semantics for session multiplexing as well?

-acbegen

> Sent: Monday, April 27, 2009 2:02 PM
> Subject: Re: [MMUSIC] [Fecframe] RTP stream multiplexing in 
> the fec framework
>

---

From: "Roni Even" <[email-masked]>
Date: Tue, 28 Apr 2009 10:05:04 +0300

Ali,
I think that if you would want to use a=ssrc-group:fec-xr also for session
multiplexing it will be a session level attribute duplicating the a=group
and having problem with SSRC number uniqueness across RTP sessions. I think
it will be best to have the a=ssrc-group as a media level attribute only
Roni

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Ali C. Begen (abegen)
Sent: Tuesday, April 28, 2009 2:00 AM
To: Colin Perkins
Cc: Watson, Mark; [email-masked]; [email-masked]
Subject: Re: [MMUSIC] [Fecframe] RTP stream multiplexing in the fec
framework

Alright, looks like we need to have SSRC multiplexing for FEC, and thus, we
need grouping support for it (a=ssrc-group). I'll revise the 4756bis and
submit a new version for review.

One more question, though. Should we allow for "a=ssrc-group:FEC-XR"
semantics only if SSRC multiplexing is used and mandate "a=group:FEC-XR"
semantics for everything else (for non-RTP flows and when session
multiplexing is used)? Or, should we also allow "a=ssrc-group:FEC-XR"
semantics for session multiplexing as well?

-acbegen

---

From: Marshall Eubanks <[email-masked]>
Date: Tue, 28 Apr 2009 05:13:13 -0400

On Apr 27, 2009, at 6:09 PM, Colin Perkins wrote:

>>>>> it's protecting doesn't seem problematic. (I wouldn't want to  
>>>>> see different media types on one port, but this is close enough  
>>>> conference with multiplexing (audio) or multiple displays  
>>>> (video), and then wanted to apply SSRC multiplexed FEC to that  
>>>> (say for sources on lossy wireless links), isn't there a danger  
>>>> that non-FEC aware receivers would not do the right thing with  
>>>> the FEC ?
>>>
>>>
> degraded, but the mixer still works); and the only reason to use  
> SSRC multiplexing here is specifically to use the same network path  
> for the FEC and media, making the last point moot.
>

OK, this works for me if this aligns with Ali's thinking.

Marshall

---

From: "Jonathan Lennox" <[email-masked]>
Date: Tue, 28 Apr 2009 10:19:35 -0400

In the source-attributes draft, ssrc-group: semantics are only defined
within a given RTP session.  To associate multiple RTP sessions sessions
you need to use group: semantics instead.

So, yes, the former.

-- 
Jonathan Lennox
Vidyo, Inc
[email-masked]

> From: Ali C. Begen (abegen) [mailto:[email-masked]]
> Sent: Monday, April 27, 2009 7:00 PM
> To: Colin Perkins
> Alright, looks like we need to have SSRC multiplexing for FEC, and
> thus, we need grouping support for it (a=ssrc-group). I'll revise the
> 4756bis and submit a new version for review.
> 
> semantics only if SSRC multiplexing is used and mandate "a=group:FEC-
> XR" semantics for everything else (for non-RTP flows and when session
to