RTCWEB                                                        G. Mandyam
Internet-Draft                                Qualcomm Innovation Center
Intended status: Informational                                   M. Luby
Expires: August 2, 2013                       Qualcomm Technologies Inc.
                                                          T. Stockhammer
                                                          Nomor Research
                                                                C. Foisy
                                              Qualcomm Technologies Inc.
                                                        January 29, 2013


          Forward Error Correction for WebRTC using FEC FRAME
                    draft-mandyam-rtcweb-fecframe-00

Abstract

   WebRTC provides a solution for peer-to-peer streaming between web
   applications by leveraging a Real-Time Protocol (RTP) stream between
   two clients.  This RTP stream is expected to be sent over an UDP
   (Universal Datagram Protocol) connection, which by definition has no
   built-in reliability.  Recently the FEC FRAME Working Group of the
   IETF has come up with a framework and technical recommendations for
   applying forward error correction (FEC) to unreliable streams.  This
   framework can be applied to WebRTC with minimal changes to the
   specification.

Status of this Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on August 2, 2013.

Copyright Notice

   Copyright (c) 2013 IETF Trust and the persons identified as the
   document authors.  All rights reserved.




Mandyam, et al.          Expires August 2, 2013                 [Page 1]


Internet-Draft               FECFRAME4WebRTC                January 2013


   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
     1.1.  Block Code Introduction  . . . . . . . . . . . . . . . . .  3
   2.  FEC FRAME Overview . . . . . . . . . . . . . . . . . . . . . .  4
   3.  Latency Mitigation . . . . . . . . . . . . . . . . . . . . . .  6
   4.  Session Description Protocol Impacts . . . . . . . . . . . . .  7
   5.  Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . 10
   6.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 11
   7.  Security Considerations  . . . . . . . . . . . . . . . . . . . 11
   8.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 11
     8.1.  Normative References . . . . . . . . . . . . . . . . . . . 11
     8.2.  Informative References . . . . . . . . . . . . . . . . . . 11
   Appendix A.  Additional Stuff  . . . . . . . . . . . . . . . . . . 12
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12

























Mandyam, et al.          Expires August 2, 2013                 [Page 2]


Internet-Draft               FECFRAME4WebRTC                January 2013


1.  Introduction

   Forward Error Correction (FEC) is a well-known technique for
   improving the reliability of packet transmission over networks that
   do not provide guaranteed packet delivery by adding repair packets to
   the original packets.  The IETF has defined a "building block"
   approach to the specification of FEC to streaming protocols, based on
   RFC 5052 [RFC5052] and RFC 6363 [RFC6363].  Borrowing from the
   terminology of RFC 5052 [RFC5052], the FEC can be applied to any
   payload of a CDP (content delivery protocol).  Since WebRTC defines
   RTP as its target CDP for media streaming, it stands to reason that
   the IETF building block framework is readily applicable to WebRTC.

1.1.  Block Code Introduction

   Detailed understanding of all the different types of FEC is beyond
   the scope of this document.  Note that FEC in its most fundamental
   description involves the encoding of a message derived from an
   alphabet into a representation that is also derived from the same
   alphabet.  Moreover, FEC encoding results in redundancy, i.e. the
   addition of information to the message that can help in retrieving
   the original message in the presence of loss of parts of the
   transmission.  If the message is composed of k individual entries
   from the alphabet and the FEC encoding results in a new collection of
   entries (also referred to as a codeword) of length n, then the FEC
   code is said to be of rate k/n or is sometimes said to be a (k,n)
   code.

   FEC's that operate on individual messages without dependency on other
   messages in a given sequence are sometimes referred to as block
   codes.  As another way of visualizing this, assume that a message to
   be sent over a communications channel is derived from a grouping of
   symbols derived from an alphabet (e.g. a binary alphabet can be
   represented by the set {0,1}), and can be represented as a collection
   of words {m_0, m_1, ..., m_(k-1)}.  Then the resultant codeword
   generated by applying the FEC can be represented as a collection of
   words derived from the same alphabet {c_0, c_1, ..., c_(n-1)}.  If
   all n of the words of this codeword are sent over a communications
   link and at most n-k of the words of the codeword are lost, then
   ideally an FEC code can completely recover the original message.

   The block code can be represented in terms of a generator matrix G
   (of binary entries) acting upon a message vector m.








Mandyam, et al.          Expires August 2, 2013                 [Page 3]


Internet-Draft               FECFRAME4WebRTC                January 2013


   G = |g_(0,0)   g_(0,1)   ... g_(0,n-1)  |, m =|m_0 m_1 ... m_(k-1)|
       |g_(1,0)   g_(1,1)   ... g_(1,n-1)  |
       |                ...                |
       |g_(k-1,0) g_(k-1,1) ... g_(k-1,n-1)|


                    Generator Matrix and Message Vector

                                 Figure 1

   A codeword c is generated by a matrix-vector multiplication of G with
   m.  Some of the words of the codeword c, each word sent in a separate
   packet together with a word identifier, may be lost and not arrive at
   the receiver.  The receiver can determined which words are received
   in packets from the word identifiers included in the packets.  Based
   on the word identifiers, the FEC decoder can recover the original
   message.

   If the block code in question is systematic, then a subset of the
   generated codeword is the original message itself.  Such codes allow
   for a clean separation of the codeword into source symbols and
   redundancy symbols.  In this case, then generator matrix can be
   represented as


   G = |g_(0,0)   g_(0,1)   ... g_(0,n-k-1)  1 0 0 ... 0|
       |g_(1,0)   g_(1,1)   ... g_(1,n-k-1)  0 1 0 ... 0|
       |                ...                      ...    |
       |g_(k-1,0) g_(k-1,1) ... g_(k-1,n-k-1)0 0 0 ... 1|


                   Generator Matrix for Systematic Code

                                 Figure 2

   A more detailed overview of block codes, their derivation, and
   theoretical analysis can be found in textbooks such as [Wicker].


2.  FEC FRAME Overview

   The building block approach of RFC 6363 [RFC6363] allows for a
   straightforward application of a preferred block code to streaming
   protocols such as RTP.  The chosen block code must satisfy the
   requirements of RFC 5052 [RFC5052].  A valid FEC encoding scheme will
   have an IANA-assigned FEC Encoding ID.  Since the building block
   approach to applying block codes to streaming protocols has been
   standardized by the IETF, it is not necessary to discuss the



Mandyam, et al.          Expires August 2, 2013                 [Page 4]


Internet-Draft               FECFRAME4WebRTC                January 2013


   specified approach in this document.  However, a simple mapping
   between the Framework Architecture of RFC 6363 [RFC6363] is
   reproduced here to provide context.


     + - - - - - - - - - - - - - - - - - - - - - - - -+
     | +--------------------------------------------+ |
       |            Application Layer               |
     | +--------------------------------------------+ |
                              |                |
     | + -- -- -- -- -- -- -- -- -- -- --+     |      |
       |            RTP (Optional)       |     |
     | |                                 |     |- Configuration/
       +- -- -- -- -- -- -- -- -- -- -- -+     |  Coordination
     |                    |                    |      |
                          | ADU flows          |
     |                    |                    v      |
       +--------------------------------------------+     +------------+
     | |      FEC Framework (This document)         |<--->| FEC Scheme |
       +--------------------------------------------+     +------------+
     |                |               |               |
               Source |        Repair |
     |                |               |               |
       +-- -- -- -- --|-- --+ -- -- -- -- -- + -- --+
     | | RTP Layer    |     | RTP Processing |      | |
       | (Optional)   |     +-- -- -- |- -- -+      |
     | |        +-- -- -- -- -- -- -- |--+          | |
       |        |  RTP (De)multiplexing  |          |
     | +-- -- -- --- -- -- -- -- -- -- -- -- -- -- -+ |
                              |
     | +--------------------------------------------+ |
       |          Transport Layer (e.g., UDP)       |
     | +--------------------------------------------+ |
                              |
     | +--------------------------------------------+ |
       |                     IP                     |
     | +--------------------------------------------+ |

     | Content Delivery Protocol                      |
     + - - - - - - - - - - - - - - -  - - - - - - - - +


                        FEC Framework Architecture

                                 Figure 3

   With respect to the above figure, the application layer would
   essentially be a logical collection of the user agent along with the



Mandyam, et al.          Expires August 2, 2013                 [Page 5]


Internet-Draft               FECFRAME4WebRTC                January 2013


   WebRTC-enabled web application, and the application data unit (ADU)
   flows could be the RTP packets provided by the user agent
   implementation of WebRTC.  Note that it is also allowed in the
   specification to multiplex additional RTP-encapsulated redundancy
   packets onto UDP, which is useful for providing additional resiliency
   for multicast traffic.  After application of block encoding, the
   encoded blocks can be identified by an FEC Source ID which is
   appended to the block of data.  It is not required if there are other
   means to indicate to the receiver a unique identifier for the encoded
   data block.

   It should be noted that the use of FEC does not come without its own
   costs.  For instance, the selection of the block size (ADU size) has
   a direct impact on latency as the transmission of the stream must be
   delayed while the payload is formed for FEC encoding.  This is
   important due to the fact that many block coding schemes tend to be
   more effective with larger block sizes.  Moreover, encoding and
   decoding latency are applicable (although advancement in processor
   speed has made this less of an issue).  Finally, the amount of
   redundancy affects the overall throughput.  The larger the amount of
   redundancy, the less likelihood that random losses will result in the
   receiver being unable to decode data.  However, greater redundancy
   (i.e. a smaller k/n ratio) has a direct impact on the amount of
   application data that can be sent over a fixed time interval.


3.  Latency Mitigation

   While FEC encoding provides resiliency in the face of packet loss, it
   also introduces latency.  Assume a system where the source rate for a
   stream is R bits/second, and the number of bits to be encoded using a
   k/n code is B. In order to encode B bits to produce the necessary
   redundancy, which is in the amount given by B(n-k)/k, it is necessary
   for the sender to buffer a block of B information bits.  Therefore,
   one would assume that the sender would have to delay transmission by
   at least the time it takes to generate one block of information bits
   from the source, i.e.  B/R. However, note that the in most block
   codes, the first part of the codeword sent is the actual source
   information bits.  Therefore it is conceivable that transmission from
   the sender to receiver could commence while the source bits are being
   buffered at the sender-side encoder.

   Assume that the rate of the code is k/n = 1/2, i.e. the number of
   redundancy bits is equal to the number of source bits when encoding a
   block of data.  The sender, as one latency mitigation strategy, could
   delay transmission of the encoded data (source and redundancy bits)
   by half the duration of a source block, B/(2R), and then send at
   twice the source data rate (2R).  After the entire block of



Mandyam, et al.          Expires August 2, 2013                 [Page 6]


Internet-Draft               FECFRAME4WebRTC                January 2013


   information bits B has been buffered at the sender, then the sender
   can transmit the remaining code bits at 2R. This results in an
   overall latency of B(n-k)/(2k), or half of the time it takes for the
   source to generate B bits of data.


  time(s) 0            B/(2R)          B/R          3B/(2R) ...
          +--------------+--------------+--------------+
          |  Delay data  | Send source  |  Send redun- |        Sender
          | transmission |  bits at 2R  |  dancy at 2R |
          +--------------+--------------+--------------+
                                        ^
                                Generate Redundancy


          +--------------+--------------+--------------+
          | Wait for data|  Rcv. source |Rcv. redundan-|        Receiver
          |              |  bits at 2R  |   cy at 2R   |
          +--------------+--------------+--------------+
                                                       ^
                                           Decode and send to renderer


       Latency Mitigation Strategy Timeline for Rate 1/2 Block Code

                                 Figure 4


4.  Session Description Protocol Impacts

   The implications for SDP at the time of the writing of this document
   are not fully known as there is still debate as to the semantics of
   SDP for WebRTC.  A proposal for SDP usage in WebRTC was described in
   [I-D.nandakumar-rtcweb-sdp].  In addition, the SDP elements required
   for FEC are described in RFC 6364 [RFC6364].  Leveraging the example
   of Section 5.1 in [I-D.nandakumar-rtcweb-sdp], a 2-way video and
   audio session offer/answer exchange can be depicted for two sample
   endpoints (Alice and Bob) with the video stream being protected by
   FEC:

   Alice->Bob: Offer(Audio:G.711,AMR-WB Video:H.264 FEC-encoding:Reed-
   Solomon,LDPC Staircase)

   Bob->Alice: Answer(Audio:G.711,AMR-WB Video:H.264 FEC-encoding:Reed-
   Solomon)

   Alice->Bob: Two-way AMR-WB Audio, H.264 Video, Reed-Solomon FEC-
   Encoding



Mandyam, et al.          Expires August 2, 2013                 [Page 7]


Internet-Draft               FECFRAME4WebRTC                January 2013


   +------------------------------------------+------------------------+
   | SDP Contents                             | Notes                  |
   +------------------------------------------+------------------------+
   | v=0                                      | Protocol Version       |
   | o=alice 20518 0 IN IP4 0.0.0.0           | Session Origin         |
   | s=FEC for WebRTC                         | Session Name           |
   | t=0 0                                    | Time session is active |
   | a=ice-ufrag:074c6550                     | Session Level ICE param|
   | a=ice-pwd:a28a397a4c3f31747d1ee3474af08a | Session Level ICE param|
   | 068                                      |                        |
   | a=fingerprint:sha-1                      | Session Level DTLS     |
   | 99:41:49:83:4a:97:0e:1f:ef:6d:f7:c9:c7:7 | Fingerprint for SRTP   |
   | 0:9d:1f:66:79:a8:07                      |                        |
   | a=group:FEC-FR S1 R1                     | FEC group source/repair|
   |                                          |                        |
   | m=audio 54609 RTP/SAVPF 0 109 98         |                        |
   | c= IN IP4 24.23.204.141                  | Connection Data        |
   | a=rtpmap:0 PCMU/8000                     | G.711 8kbps            |
   | a=rtpmap:109 AMR-WB/16000/2              |  2-chan AMR-WB 16 kbps |
   | a=fmtp:99 interleaving=30                |                        |
   | a=maxptime:100                           |                        |
   | a=sendrecv                               | Can send/rcv audio     |
   | a=mid:S0                                 |                        |
   | a=rtcp-mux                               | Can mux RTP/RTCP       |
   | b=AS:256                                 | Bandwidth              |
   | b=RS:0                                   | RTCP Bandwdith         |
   | b=RR:0                                   | RTCP Bandwidth         |
   |                                          |                        |
   | a=candidate:0 1 UDP 2113667327           | Host ICE Candidate     |
   | 192.168.1.4 54609 typ host               |  for audio             |
   | a=candidate:1 1 UDP 694302207            | Server Reflexive ICE   |
   | 24.23.204.141 54609 typ srflx raddr      |  Candidate for the     |
   | 192.168.1.4 rport 54609                  |  above host candidate  |
   | a=rtcp-fb:109 nack                       | NACK RTCP feedback     |
   |                                          |                        |
   | m=video 62537 RTP/SAVPF 99 120           |                        |
   | c= IN IP4 24.23.204.141                  | Connection data-source |
   | a=rtpmap:99 H264/90000                   |                        |
   | a=fmtp:99                                |                        |
   | profile-level-id=4d0028;packetization-mo |                        |
   | de=1                                     |                        |
   | a=fec-source-flow: id=0                  | Source flow for FEC    |
   | a=mid:S1                                 |                        |
   | a=sendrecv                               | Can send/rcv video     |
   | a=rtcp-mux                               | Can mux RTP/RTCP       |
   | m=application 30000 UDP/FEC              |                        |
   | c= IN IP4 24.23.204.141                  | Connection data-repair |
   | a=fec-repair-flow: encoding-id=2;        | Reed-Solomon code      |



Mandyam, et al.          Expires August 2, 2013                 [Page 8]


Internet-Draft               FECFRAME4WebRTC                January 2013


   |  fssi=E:1400,S:0,m:8                     |  support               |
   | a=fec-repair-flow: encoding-id=3;        | LDPC Staircase support |
   |  fssi=seed:1234,E:1400,S:0,n1m3:0        |                        |
   | a=repair-window:200ms                    | Time duration of source|
   |                                          |  and repair blocks     |
   | a=mid:R1                                 |                        |
   |                                          |                        |
   | a=candidate:0 1 UDP 2113667327           | Host ICE Candidate     |
   | 192.168.1.4 62537 typ host               |  for video             |
   | a=candidate:1 1 UDP 1694302207           | Server Reflexive ICE   |
   | 24.23.204.141 62537 typ srflx raddr      |  Candidate for the     |
   | 192.168.1.4 rport 62537                  |  above host candidate  |
   +------------------------------------------+------------------------+


                         SDP Offer (Alice to Bob)

                                 Figure 5



   +------------------------------------------+------------------------+
   | SDP Contents                             | Notes                  |
   +------------------------------------------+------------------------+
   | v=0                                      | Protocol Version       |
   | o=bob 16833 0 IN IP4 0.0.0.0             | Session Origin         |
   | s=FEC for WebRTC                         | Session Name           |
   | t=0 0                                    | Time session is active |
   | a=ice-ufrag:c300d85b                     | Session Level ICE param|
   | a=ice-pwd:de4e99bd291c325921d5d47efbabd9 | Session Level ICE param|
   | a2                                       |                        |
   | a=fingerprint:sha-1                      | Session Level DTLS     |
   | 99:41:49:83:4a:97:0e:1f:ef:6d:f7:c9:c7:7 | Fingerprint for SRTP   |
   | 0:9d:1f:66:79:a8:07                      |                        |
   | a=group:FEC-FR S1 R1                     | FEC group source/repair|
   |                                          |                        |
   | m=audio 49203 RTP/SAVPF 109              |                        |
   | c= IN IP4 98.248.92.77                   | Connection Data        |
   | a=rtpmap:109 AMR-WB/16000/2              |  2-chan AMR-WB 16 kbps |
   | a=fmtp:99 interleaving=30                |                        |
   | a=maxptime:100                           |                        |
   | a=sendrecv                               | Can send/rcv audio     |
   | a=mid:S0                                 |                        |
   | a=rtcp-mux                               | Can mux RTP/RTCP       |
   | b=AS:256                                 | Bandwidth              |
   | b=RS:0                                   | RTCP Bandwdith         |
   | b=RR:0                                   | RTCP Bandwidth         |
   |                                          |                        |



Mandyam, et al.          Expires August 2, 2013                 [Page 9]


Internet-Draft               FECFRAME4WebRTC                January 2013


   | a=candidate:0 1 UDP 2113667327           | Host ICE Candidate     |
   | 192.168.1.7 49203 typ host               |  for audio             |
   | a=candidate:1 1 UDP 694302207            | Server Reflexive ICE   |
   | 98.248.92.77 49203 typ srflx raddr      |  Candidate for the     |
   | 192.168.1.7 rport 49203                  |  above host candidate  |
   | a=rtcp-fb:109 nack                       | NACK RTCP feedback     |
   |                                          |                        |
   | m=video 63130 RTP/SAVPF 99               |                        |
   | c= IN IP4 98.248.92.771                  | Connection data-source |
   | a=rtpmap:99 H264/90000                   |                        |
   | a=fmtp:99                                |                        |
   | profile-level-id=4d0028;packetization-mo |                        |
   | de=1                                     |                        |
   | a=fec-source-flow: id=0                  | Source flow for FEC    |
   | a=mid:S1                                 |                        |
   | a=sendrecv                               | Can send/rcv video     |
   | a=rtcp-mux                               | Can mux RTP/RTCP       |
   | m=application 30000 UDP/FEC              |                        |
   | c= IN IP4 98.248.92.771                  | Connection data-repair |
   | a=fec-repair-flow: encoding-id=2;        | Reed-Solomon code      |
   |  fssi=E:1400,S:0,m:8                     |  support               |
   | a=repair-window:200ms                    | Time duration of source|
   |                                          |  and repair blocks     |
   | a=mid:R1                                 |                        |
   |                                          |                        |
   | a=candidate:0 1 UDP 2113667327           | Host ICE Candidate     |
   | 192.168.1.7 63130 typ host               |  for video             |
   | a=candidate:1 1 UDP 1694302207           | Server Reflexive ICE   |
   | 98.248.92.77 63130 typ srflx raddr       |  Candidate for the     |
   | 192.168.1.7 rport 63130                  |  above host candidate  |
   +------------------------------------------+------------------------+


                         SDP Answer (Bob to Alice)

                                 Figure 6


5.  Discussion

   The use of FEC in WebRTC should not require a significant standards
   change, as the FEC Framework approved by the IETF already specifies
   the use of FEC for streaming protocols.  There certainly exists
   tradeoffs between the benefits of FEC at smaller block sizes, and the
   latency incurred due to larger block sizes.  However, these tradeoffs
   should be considered by WebRTC implementers and not as part of the
   standardization effort for WebRTC.  An item that can be considered is
   whether a specific FEC scheme should be designated as mandatory-to-



Mandyam, et al.          Expires August 2, 2013                [Page 10]


Internet-Draft               FECFRAME4WebRTC                January 2013


   implement, so as to provide a level of interoperability among WebRTC
   clients.


6.  IANA Considerations

   This memo includes no request to IANA.


7.  Security Considerations

   Security considerations are TBD.


8.  References

8.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC5052]  Watson, M., Luby, M., and L. Vicisano, "Forward Error
              Correction (FEC) Building Block", RFC 5052, August 2007.

   [RFC6363]  Watson, M., Begen, A., and V. Roca, "Forward Error
              Correction (FEC) Framework", RFC 6363, October 2011.

   [RFC6364]  Begen, A., "Session Description Protocol Elements for the
              Forward Error Correction (FEC) Framework", RFC 6364,
              October 2011.

8.2.  Informative References

   [I-D.nandakumar-rtcweb-sdp]
              Nandakumar, S. and C. Jennings, "SDP for the WebRTC",
              draft-nandakumar-rtcweb-sdp-00 (work in progress),
              October 2012.

   [I-D.narten-iana-considerations-rfc2434bis]
              Narten, T. and H. Alvestrand, "Guidelines for Writing an
              IANA Considerations Section in RFCs",
              draft-narten-iana-considerations-rfc2434bis-09 (work in
              progress), March 2008.

   [RFC2629]  Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629,
              June 1999.

   [RFC3552]  Rescorla, E. and B. Korver, "Guidelines for Writing RFC



Mandyam, et al.          Expires August 2, 2013                [Page 11]


Internet-Draft               FECFRAME4WebRTC                January 2013


              Text on Security Considerations", BCP 72, RFC 3552,
              July 2003.

   [Wicker]   Wicker, S., "Error Control Systems", Upper Saddle River,
              NJ: Prentice-Hall Inc., 1995.


Appendix A.  Additional Stuff

   This becomes an Appendix.


Authors' Addresses

   Giridhar Mandyam
   Qualcomm Innovation Center
   5775 Morehouse Drive
   San Diego, California  92121
   USA

   Phone: +1 858 651 7200
   Email: mandyam@quicinc.com


   Mike Luby
   Qualcomm Technologies Inc.
   2030 Addison Street
   Berkeley, California  94704
   USA

   Phone: +1 510 725 3502
   Email: luby@qti.qualcomm.com


   Thomas Stockhammer
   Nomor Research
   Brecherspitzstrasse 8
   Munich  81541
   Germany

   Phone: +49 8997898002
   Email: stockhammer@nomor.de









Mandyam, et al.          Expires August 2, 2013                [Page 12]


Internet-Draft               FECFRAME4WebRTC                January 2013


   Christian Foisy
   Qualcomm Technologies Inc.

   Phone: +1 450 510 3202
   Email: cfoisy@qti.qualcomm.com














































Mandyam, et al.          Expires August 2, 2013                [Page 13]