Re: [Fecframe] draft-zixuan-fecframe-source-mi ??

["Ali C. Begen (abegen)" <abegen at cisco.com>]

There are multiple things here used as an excuse to depart from the convention used in the framework.

The main goal here seems to provide the non-framework capable RTP applications a way of using the nice features of the framework. In this example, "a nice feature" stands for the protection of multiple RTP streams together. I will let others comment on this, too, but personally, I am not sure whether we should be doing this. On one hand, we want the nice features, but at the same time we don’t wanna support the framework, and the excuse is the backward compatibility in environments with both framework-capable and incapable RTP receivers. In addition, using an additional flow may increase the chances of failure since if source fec payload id’s are lost, receiver will be clueless. This deserves a consensus from the WG, probably from AVT, too.

Furthermore, I believe two RTP streams can be still protected together w/o any additional source fec payload id’s (You asked for an example, and I will try to explain in simple words). If certain features of the RTP streams are known (which is usually the case), by using a systematic approach (not in the sense of systematic FEC), things can probably be worked out. In your example, I believe in each source block you wanna do a different order of the source packets and flows, so things are quite unpredictable. E.g., packet 16 and 17 are before packet 15 of the same flow, packet 19 is before packet 8 of the other flow, and packets belonging to flows 0 and 1 are dispersed, any particular reason?

But, if you follow a systematic approach, your CDP can convey the mapping out of band, and decoding will know what to expect and how to decode. Remember that there will be constraints on which RTP streams you can combine prior to FEC encoding (this was brought up in the last meeting).

If all the RTP streams belong to the same RTP session, their SSRC's will be different, so SSRC+seqnum should uniquely identify each source packet. But, this would not work if the RTP streams would be from different sessions. In that case, they could share same SSRC's, and I can see the complications.

Cheers, acbegen.


From: zouzixuan [mailto:tendyntu at huawei.com] 
Sent: Wednesday, September 23, 2009 4:28 AM
To: Ali C. Begen (abegen); fecframe at ietf.org
Subject: RE: [Fecframe] draft-zixuan-fecframe-source-mi ??

> 
> First question, are you suggesting to apply FEC to the combination of a video
> and audio RTP stream?

> Second question, assuming the above case is true, I am still not sure why you
> need an additional flow carrying the source payload ids. Is it because there are
> two streams? Could you explain?

It's not this case that just result in the need of carrying source play id in additional flow. It is this case to prove the need of source payload id for RTP flow. Because you need a source payload id, you gotta transfer it to the client, either in source packet as current FEC framework specified, or in an additional flow described in our draft. The latter choice for transferring the source payload is for making source packet accessible to non-fecframework clients. 

This table shows an example of multiple flows. The table depicts the structure of a source block, which is filled up with the packets (of length 16, 17 19 15 and 8 bytes) from two sequenced flows. The packets from two flows are identified by flow id 0 and 1, respectively. For FEC decoding, the receiver needs to know the position of each packet in the source block. The sequence number can only tell the order of a packet in the flow it belongs to in the source block. There is no way to tell where a packet exactly is in the source block. Source Payload ID is thus in this case needed. Would you please give a solution which is free of source payload id?

0
16
B0,0
B0,1
B0,2
B0,3
B0,4
B0,5
B0,6
B0,7
B0,8
B0,9
B0,10
B0,11
B0,12
B0,13
B0,14
B0,15
0
0
0
0
17
B1,0
B1,1
B1,2
B1,3
B1,4
B1,5
B1,6
B1,7
B1,8
B1,9
B1,10
B1,11
B1,12
B1,13
B1,14
B1,15
B1,16
0
0
1
19
B2,0
B2,1
B2,2
B2,3
B2,4
B2,5
B2,6
B2,7
B2,8
B2,9
B2,10
B2,11
B2,12
B2,13
B2,14
B2,15
B2,16
B2,17
B2,18
0
15
B3,0
B3,1
B3,2
B3,3
B3,4
B3,5
B3,6
B3,7
B3,8
B3,9
B3,10
B3,11
B3,12
B3,13
B3,14
0
0
0
0
1
8
B4,0
B4,1
B4,2
B4,3
B4,4
B4,5
B4,6
B4,7


Hope this is clear.

Zou ZiXuan, Senior Research Staff
Media & Communication Lab
HUAWEI TECHNOLOGIES CO.,LTD. 

Address: Huawei Industrial Base
Bantian Longgang
Shenzhen 518129, P.R.China
Tel: +86 0755 28789364
Fax: +86 0755 28788317
E-mail: tendyntu at huawei.com
www.huawei.com
-------------------------------------------------------------------------------------------------------------------------------------
This e-mail and its attachments contain confidential information from HUAWEI, which 
is intended only for the person or entity whose address is listed above. Any use of the 
information contained herein in any way (including, but not limited to, total or partial 
disclosure, reproduction, or dissemination) by persons other than the intended 
recipient(s) is prohibited. If you receive this e-mail in error, please notify the sender by 
phone or email immediately and delete it!


> -----Original Message-----
> From: Ali C. Begen (abegen) [mailto:abegen at cisco.com]
> Sent: Wednesday, September 23, 2009 11:29 AM
> To: zouzixuan; fecframe at ietf.org
> Subject: RE: [Fecframe] draft-zixuan-fecframe-source-mi ??
> 
> First question, are you suggesting to apply FEC to the combination of a video
> and audio RTP stream?
> 
> Second question, assuming the above case is true, I am still not sure why you
> need an additional flow carrying the source payload ids. Is it because there are
> two streams? Could you explain?
> 
> Cheers, acbegen.