Subject: Re: [MMUSIC] FW: New Version Notification for draft-ietf-mmusic-rfc4756bis-02

From: "Roni Even" <[email-masked]>
Date: Fri, 1 May 2009 21:18:22 +0300

Ali,
The example you give in section 4.3 does ssrc multiplexing for an audio and
video stream. This is not allowed according to RFC 3550 section 5.2. You can
have the same example with two video streams where only one of them is
protected by the fec stream.

Roni Even

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Ali C. Begen (abegen)
Sent: Thursday, April 30, 2009 8:33 PM
To: [email-masked]
Subject: [MMUSIC] FW: New Version Notification for
draft-ietf-mmusic-rfc4756bis-02

The outcome after the last IETF MMUSIC session was to WGLC this document.
However, since then we also decided to support grouping of SSRC-multiplexed
RTP streams. This document adds support for this. I also updated the
offer/answer model section to deal with 4756-compatible endpoints more
smoothly.
http://www.ietf.org/internet-drafts/draft-ietf-mmusic-rfc4756bis-02.txt

Note that this document intends to obsolete 4756.

Comments are welcome. 

-acbegen

-----Original Message-----
From: IETF I-D Submission Tool [mailto:[email-masked]] 
Sent: Thursday, April 30, 2009 10:20 AM
To: Ali C. Begen (abegen)
Subject: New Version Notification for draft-ietf-mmusic-rfc4756bis-02 

A new version of I-D, draft-ietf-mmusic-rfc4756bis-02.txt has been
successfuly submitted by Ali Begen and posted to the IETF repository.

Filename:	 draft-ietf-mmusic-rfc4756bis
Revision:	 02
Title:		 Forward Error Correction Grouping Semantics in Session
Description Protocol
Creation_date:	 2009-04-30
WG ID:		 mmusic
Number_of_pages: 12

Abstract:
The Session Description Protocol (SDP) supports grouping media lines.
SDP also has semantics defined for grouping the associated source and
Forward Error Correction (FEC)-based repair flows.  However, the
semantics that was defined in RFC 4756 generally fail to provide the
specific grouping relationships between the source and repair flows
when there are more than one source and/or repair flows in the same
group.  Furthermore, the existing semantics does not support
describing additive repair flows.  This document addresses these
issues by introducing new FEC grouping semantics.  SSRC-level
grouping semantics is also introduced in this document for Real-time
Transport Protocol (RTP) streams using SSRC multiplexing.

The IETF Secretariat.

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

---

From: "Ali C. Begen (abegen)" <[email-masked]>
Date: Fri, 1 May 2009 11:48:06 -0700

Yes, I am aware of that. But, there are certain exceptions to the arguments made in section 5.2., thus the language is "should not" not "must not."

I specifically used multicast and different SSRC values in my example. So, I believe only #4 in the 5-item list "may" create a problem. Yet, I don't think #4 will be an issue in an FEC scenario, either.

If the working group thinks this can be indeed an issue, I can certainly change the example to two-video scenario.

-acbegen

> From: Roni Even [mailto:[email-masked]] 
> Sent: Friday, May 01, 2009 11:18 AM
> To: Ali C. Begen (abegen); [email-masked]
> Subject: RE: [MMUSIC] FW: New Version Notification for 
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of
> Ali C. Begen (abegen)

---

From: "Roni Even" <[email-masked]>
Date: Fri, 1 May 2009 22:25:56 +0300

Ali,
I am not sure why in the example you have a case that is not the recommended
work, can you exaplain?
Roni

-----Original Message-----
From: Ali C. Begen (abegen) [mailto:[email-masked]] 
Sent: Friday, May 01, 2009 9:48 PM
To: Roni Even; [email-masked]
Subject: RE: [MMUSIC] FW: New Version Notification for

Yes, I am aware of that. But, there are certain exceptions to the arguments
made in section 5.2., thus the language is "should not" not "must not."

I specifically used multicast and different SSRC values in my example. So, I
believe only #4 in the 5-item list "may" create a problem. Yet, I don't
think #4 will be an issue in an FEC scenario, either.

If the working group thinks this can be indeed an issue, I can certainly
change the example to two-video scenario.

-acbegen

---

From: "Ali C. Begen (abegen)" <[email-masked]>
Date: Fri, 1 May 2009 12:58:30 -0700

I'll admit that I first considered (in my example) two videos multiplexed in the same session with an FEC stream protecting only one of the videos. For example, the video streams could be one base layer and one enhancement layer (SVC video) and protecting the base layer only would make sense sense. But, sending all these streams in a single RTP session does not make much sense.

I also considered multi-camera systems (MVC). But, again I believe session multiplexing fits a lot better to such scenarios than ssrc multiplexing.

So, I decided to provide an example with video and audio, where FEC protects the video stream only. As I mentioned below, IMO only #4 (in section 5.2 of RFC 3550) could be a concern (my example would not be RTP mixer friendly). Yet, to me this is not a strong concern anyway since I don't know if anybody would wanna mix FEC with anything else.

Note that if the RTP session carried only one video + one FEC, the source-repair association will be trivial and we would not need a=ssrc-group line.

Please keep in mind that the FEC framework does not recommend SSRC multiplexing and it should not be used except to reduce the port usage. It works OK when there is one source and one FEC stream. For other cases, it is even difficult to produce a good example :)

Anyhow, if my reasoning is incorrect, please provide a better scenario/example and I will be happy to replace it with mine.

Thanks.
-acbegen

> Sent: Friday, May 01, 2009 12:26 PM