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

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

Good point, I agree with this assessment. 

BR,

-acbegen (Bberry crippled)

----- Original Message -----
From: Roni Even <[email-masked]>
To: Ali C. Begen (abegen); 'Colin Perkins' <[email-masked]>
Cc: 'Watson, Mark' <[email-masked]>; [email-masked] <[email-masked]>; [email-masked] <[email-masked]>
Sent: Tue Apr 28 00:05:04 2009
Subject: RE: [MMUSIC] [Fecframe] RTP stream multiplexing in the fec framework

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

> -----Original Message-----
> From: Colin Perkins [mailto:[email-masked]] 
> Sent: Monday, April 27, 2009 2:02 PM
> To: Ali C. Begen (abegen)
> Cc: Watson, Mark; [email-masked]; [email-masked]
> Subject: Re: [MMUSIC] [Fecframe] RTP stream multiplexing in 
> the fec framework
> 
> 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:
> > Is that a "yes" for ssrc-level grouping for FEC?
> >
> > -acbegen
> >
> >> -----Original Message-----
> >> 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
> >>
> >> On 24 Apr 2009, at 19:13, Ali C. Begen (abegen) wrote:
> >>> Copying MMUSIC as this is relevant to:
> >>>
> >>>
> >> http://www.ietf.org/internet-drafts/draft-ietf-mmusic-sdp-sour
> > ce-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.
> >>
> >> 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.
> >>>
> >>>> 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
> >>>> 	
> >>>> 	
> >>>>
> >>>>
> >>> _______________________________________________
> >>> Fecframe mailing list
> >>> [email-masked]
> >>> https://www.ietf.org/mailman/listinfo/fecframe
> >>
> >>
> >>
> >> -- 
> >> Colin Perkins
> >> http://csperkins.org/
> >>
> >>
> >>
> >>
> > _______________________________________________
> > mmusic mailing list
> > [email-masked]
> > https://www.ietf.org/mailman/listinfo/mmusic
> 
> 
> 
> -- 
> Colin Perkins
> http://csperkins.org/
> 
> 
> 
> 
_______________________________________________
mmusic mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mmusic