Internet DRAFT - draft-miniero-rtcweb-http-fallback

draft-miniero-rtcweb-http-fallback






Network Working Group                                         L. Miniero
Internet-Draft                                                  Meetecho
Intended status: Standards Track                          August 7, 2012
Expires: February 8, 2013


                  HTTP Fallback for RTP Media Streams
                 draft-miniero-rtcweb-http-fallback-00

Abstract

   Almost all VoIP endpoints, especially SIP and RTCWEB ones, make use
   of RTP to tranport media frames in real-time and communicate with
   each other.  Since RTP uses UDP, the presence of network elements
   that filter UDP packets and/or only allow some protocols like SMTP or
   HTTP to pass through would make such a communication very hard to
   accomplish, if not impossible.

   This draft describes a way to implement an HTTP Fallback for RTP
   media streams, that is, a way to effectively encapsulate RTP packets
   in HTTP messages in order to traverse proxies and firewalls.

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 February 8, 2013.

Copyright Notice

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

   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



Miniero                 Expires February 8, 2013                [Page 1]

Internet-Draft            HTTP Fallback for RTP              August 2012


   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
   2.  Conventions and Terminology  . . . . . . . . . . . . . . . . .  7
   3.  Encapsulating RTP over HTTP  . . . . . . . . . . . . . . . . .  8
     3.1.  Reserving and managing HTTP fallback channels  . . . . . .  9
     3.2.  MIME Type  . . . . . . . . . . . . . . . . . . . . . . . . 10
     3.3.  Packet header  . . . . . . . . . . . . . . . . . . . . . . 11
     3.4.  Chunked mode . . . . . . . . . . . . . . . . . . . . . . . 11
     3.5.  Non-chunked mode . . . . . . . . . . . . . . . . . . . . . 12
   4.  Negotiation and relation to ICE  . . . . . . . . . . . . . . . 13
     4.1.  HTTP fallback candidates . . . . . . . . . . . . . . . . . 13
   5.  Security Considerations  . . . . . . . . . . . . . . . . . . . 14
   6.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 15
   7.  Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 16
   8.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 17
     8.1.  Normative References . . . . . . . . . . . . . . . . . . . 17
     8.2.  Informative References . . . . . . . . . . . . . . . . . . 18
   Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 19

























Miniero                 Expires February 8, 2013                [Page 2]

Internet-Draft            HTTP Fallback for RTP              August 2012


1.  Introduction

   NAT Traversal for RTP streams has long been a matter of discussion
   and research within the IETF.  This lead through the years to the
   development of several solutions to address the issue, including
   specifications like the Session Traversal Utilities for NAT (STUN)
   [RFC5389], the Traversal Using Relays around NAT (TURN) [RFC5766] and
   Interactive Connectivity Establishment (ICE) [RFC5245].

   The above mentioned specifications have so far managed to enable
   real-time multimedia communication between heterogeneous endpoints
   located behind NATs and firewalls.  They are not effective, though,
   whenever any of the involved endpoints is behind a particularly
   restrictive network component, e.g., a web proxy or firewall that
   only allows HTTP traffic to pass through.

   While not a frequent scenario, this situation can nevertheless happen
   often enough to become a serious impedement to real-time
   communications for users who happen to experience it.  This is
   especially true when envisaging RTCWEB scenarios, where users make
   only use of their browser to place calls to their peers: within uch a
   framework, it is reasonable for a user to assume that such a call
   should be made possible in every possible deployment scenario,
   including the above-mentioned particularly restrictive one.  In fact,
   this very use case is explicitly addressed in the RTCWEB Use-cases
   and Requirements [I-D.ietf-rtcweb-use-cases-and-requirements] draft.

   This problem is not new, and as a matter of fact is not limited to
   Voice over IP alone.  Several different protocol implementations have
   faced the need to traverse such components, and many different
   approaches have been attempted and deployed to make it possible.
   According to the nature of the proxy/firewall in place, some
   implementations have succeeded in traversing such elements by just
   using TCP connections on ports 80 or 443 to reach their peers.  This
   approach is especially needed whenever proxies allow HTTPS traffic to
   go through, since most proxies don't act as MITM elements for HTTPS
   and as such allow traffic on the 443 port to go through untouched.
   While trivial, this approach is indeed effective when the firewall
   simply applies a filter that only allows connections using port 80/
   443 to pass through.  This approach, though, inevitably fails
   whenever the filtering compoment also inspects the incoming packets
   (e.g., a web proxy), since the traffic would immediately be
   recognized as not HTTP.

   An effective way to cope with such a use case is to implement an HTTP
   fallback for RTP media streams: that is, a way to effectively
   encapsulate, when needed, RTP packets in HTTP messages.  Such an
   approach would help those streams traverse restrictive network



Miniero                 Expires February 8, 2013                [Page 3]

Internet-Draft            HTTP Fallback for RTP              August 2012


   components like web proxies and firewalls that only allow HTTP
   traffic to pass through, even those who directly manage all HTTP
   messages going by.

   Considering the asynchronous nature of RTP, proper approaches need of
   course to be taken to allow a mapping of RTP packets on HTTP
   messages, especially considering the request/response nature of the
   HTTP protocol itself.  As mentioned above, similar problems have been
   addressed in the past, and in fact several different solutions have
   been proposed in the past to implement a bidirectional behaviour in
   HTTP, as documented in [RFC6202] and [RFC6455].  Besides,
   specification of a native server-push behaviour is currently under
   work in the HTTPBIS Working Group.

   Within the context of real-time multimedia communications and
   considering a scenario that involves two peers, whatever the
   signalling protocol and whichever the bidirectional HTTP technology
   being exploited, an HTTP fallback mechanism may fall in basically
   three different network topologies:

   1.  A topology whereas only one of the involved peers needs HTTP
       fallback for RTP.

   2.  A topology whereas both the involved peers need HTTP fallback for
       RTP, using two different intermediaries.

   3.  A topology whereas both the involved peers need HTTP fallback for
       RTP, using the same intermediary.

   Figure 1 describes the first topology: in this scenario, only one of
   the involved peers (namely Alice) needs an HTTP fallback for her
   media streams (e.g., because she's in a hotel where the deployed WiFi
   connectivity makes use of a proxy that only allows web and mail
   connections to pass through), while Bob does not.  In this case, Bob
   is using a publicly reachable address or has likely managed to
   traverse its NAT using one of the existing solutions.  Bob may or may
   not be aware of the fact that he's sending RTP packets to a gateway:
   what's important is that Alice is, and that she's sending her RTP
   media packets using HTTP messages, and receiving the RTP packets Bob
   sends here through HTTP messages as well.











Miniero                 Expires February 8, 2013                [Page 4]

Internet-Draft            HTTP Fallback for RTP              August 2012


                       +----------+
                       | RTP/HTTP |
             +---------+ Gateway  +-----------------------+
             |  HTTP   |          |                        \  RTP
             |         +----------+                         \
             |                                               \
             |                                               |
         +---+---+                                       +---+---+
         | Alice |                                       |  Bob  |
         +-------+                                       +---+---+



          Figure 1: Topology 1.: HTTP fallback for just one peer

   A slightly more complex scenario is described in Figure 2: in this
   scenario, both the involved peers (Alice and Bob) need an HTTP
   fallback for their media streams, meaning that both are sending and
   receiving RTP packets to and from each other using HTTP messages.
   Each one, though, sends HTTP messages to its own gateway, e.g., the
   gateway deployed by their network operator.  The two gateways, who
   most likely are deployed on publicly reachable addresses, send each
   other Alice's and Bob's RTP packets using RTP to minimize the delay
   and jitter.

                   +-----------+           +-----------+
                   | RTP/HTTP  |    RTP    | RTP/HTTP  |
         +---------+ Gateway 1 +-----------+ Gateway 2 +---------+
         |  HTTP   |           |           |           |   HTTP  |
         |         +-----------+           +-----------+         |
         |                                                       |
         |                                                       |
     +---+---+                                              +---+---+
     | Alice |                                              |  Bob  |
     +-------+                                              +---+---+



            Figure 2: Topology 2.: HTTP fallback for both peers

   Figure 3 presents a more specific use case as the one described in
   Figure 3: both the involved peers (Alice and Bob) need an HTTP
   fallback for their media streams as before, but this time they happen
   to send HTTP messages to the same gateway: in this use case, how the
   gateway decides to bridge the two media streams is entirely
   implementation specific.  It is very important, though, that all the
   characteristics of the original streams are preserved: this means,
   for instance, that the gateway must still make sure that STUN



Miniero                 Expires February 8, 2013                [Page 5]

Internet-Draft            HTTP Fallback for RTP              August 2012


   connectivity checks that may be in place keep on flowing and act
   accorgingly.

                                +-----------+
                                | RTP/HTTP  |
         +----------------------+ Gateway   +--------------------+
         |  HTTP                | (shared)  |              HTTP  |
         |                      +-----------+                    |
         |                                                       |
         |                                                       |
     +---+---+                                              +---+---+
     | Alice |                                              |  Bob  |
     +-------+                                              +---+---+



     Figure 3: Topology 3.: HTTP fallback for both peers, same gateway


































Miniero                 Expires February 8, 2013                [Page 6]

Internet-Draft            HTTP Fallback for RTP              August 2012


2.  Conventions and Terminology

   In this document, BCP 14/RFC 2119 [RFC2119] defines the key words
   "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD",
   "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
   "OPTIONAL".

   TBD.











































Miniero                 Expires February 8, 2013                [Page 7]

Internet-Draft            HTTP Fallback for RTP              August 2012


3.  Encapsulating RTP over HTTP

   As anticipated in Section 1, several different approaches have
   already been proposed in the past to accomplish a bidirectional
   behaviour in HTTP.  Some kind of approach like that is absolutely
   needed whenever HTTP is used to carry something different than just
   requests to access resources, e.g., encapsulating an asynchronous and
   bidirectional protocol.  RTP makes no exception.  That said, in order
   to minimize as much as possible the overhead caused by HTTP
   encapsulation and thus at least try and limit the delay that
   inevitably such a solution always adds, this specification tries to
   propose a lighter approach than the one proposed in literature.
   Since RTP packets can be either sent or received by an endpoint, this
   specification makes use of two different HTTP kind of messages to
   accomplish both the functionality:

   o  HTTP GET messages to allow endpoints to receive RTP packets from
      the gateway.

   o  HTTP POST messages to allow endpoints to send RTP packets to the
      gateway.

   This means that each RTP media channel can be mapped to one or more
   HTTP connections, whereas all GET messages will be associated with
   the incoming RTP media stream, while all POST messages will be
   associated with the outgoing RTP media stream.  Why more messages
   and/or connections may be involved and not one per request will be
   made clearer in the next sections.

   Figure 4 describes how such a mapping can be achieved.


     +-------+                 [ HTTP GET message(s): <<=== RTP ===<< ]
     | Alice |<<==== RTP ====>>[
     +-------+                 [ HTTP POST message(s): >>=== RTP ===>> ]


            Figure 4: Mapping an RTP stream to HTTP connections

   The next subsections will address all that is required to implement
   such a functionality, that is, how to request/reserve a mapping as
   depicted above, which MIME Type to report in the HTTP messages after
   that, the header to use in the payload to properly frame RTP packets,
   and two different approaches (chunked and not-chunked) to actually
   transport the packets on top of HTTP messages.






Miniero                 Expires February 8, 2013                [Page 8]

Internet-Draft            HTTP Fallback for RTP              August 2012


3.1.  Reserving and managing HTTP fallback channels

   Before HTTP fallback can be used, endpoints must of course reserve or
   request access to one of the available channels to their reference
   gateway.  The same happens, for instance, when creating an allocation
   request in TURN.

   An endpoint can request an HTTP fallback channel by issuing an HTTP
   POST message to the /reserve node on the gateway: if successfull, the
   gateway will return a json object containing a unique identifier to
   address the channel, and the public address the gatewayed RTP stream
   will send from and receive on.  This unique identifier will need to
   be used by the endpoint as the node to send all HTTP messages related
   to that specific RTP media stream to.

   Figure 5 shows an example of a /reserve message:

        POST /reserve HTTP/1.1
        Host: www.example.com
        Cache-Control: max-age=0
        User-Agent: cicciozzo
        Content-Type: application/x-www-form-urlencoded;charset=UTF-8
        Content-Length: 6

        blabla


        HTTP/1.1 200 OK
        Date: Mon, 06 Aug 2012 15:04:40 GMT
        Server: pippozzo
        Content-Type: application/json
        Content-Length: 64

        {
             "id" : "a1b2c3d4e5f6"
             "ip" : "203.0.113.2"
             "port" : "5000"
        }

                  Figure 5: Example of a /reserve message

   In this example, the endpoint successfully requests an HTTP fallback
   channel to its gateway, and the channel identifier is 'a1b2c3d4e5f6':
   this means that all HTTP messages will have to be sent to the
   /a1b2c3d4e5f6 node relatively to the gateway address.  Besides, the
   endpoint now knows that the gateway will be bound to the public
   address 203.0.113.2:5000 when relaying RTP packets: as explained in a
   later section, this information can be used to add ICE candidates to



Miniero                 Expires February 8, 2013                [Page 9]

Internet-Draft            HTTP Fallback for RTP              August 2012


   the endpoint's SDP.

   Before this channel can be used, of course, the address of the RTP
   peer must be specified, or otherwise the endpoint will be stuck with
   an unattached HTTP fallback for its RTP media stream.  Such a mapping
   can be specified sending a POST message to the /<uniqueid>/setpeer
   node on the gateway: the POST message MUST contain a JSON payload
   formatted as the response from the /reserve (id of the channel, ip
   and port of the RTP peer).

   [Editors note: this is obviously just a placeholder mostly: what
   should be in the reserve, setpeer and other messages that may need to
   be added (pause/resume/stop/??) and in the related response needs to
   be specified, e.g., in terms of what we want the channel to do for us
   and how, or even authorization, access control and the like.
   Besides, some kind of callback should be envisaged to inform the
   endpoint whenever the gateway gets rid of a reserved channel for any
   reason.]

   Once an HTTP fallback channel is ready, the endpoint can start using
   it to send and/or receive RTP packets to and from its peer through
   the gateway.  As anticipated, to send RTP packets the endpoint MUST
   issue an HTTP POST to the /<uniqueid> node relatively to the gateway
   address.  Whether the endpoint and the gateway will relay on a
   chunked transfer encoding or not, the query string in each request
   MUST contain a 'p' variable that addresses the sequence of HTTP POST
   messages that have been sent: that is, the first POST message MUST be
   sent to /<uniqueid>?p=1, the second, no matter how delayed (e.g., a
   second chunked message) to /<uniqueid>/?p=2 and so on, to allow the
   receiver to properly order the received payload.  It is important to
   point out that this sequence value has nothing to do with the RTP
   sequence number: in fact, while RTP already envisages a sequence
   number that allows the peer to reorder packets accordingly, this
   sequence number is of no use when a single RTP packet is fragmented
   across different HTTP requests.  The same approach MUST be followed
   by the endpoint when receiving packets by means of GET messages: the
   first POST message MUST be sent to /<uniqueid>?p=1, the second to
   /<uniqueid>/?p=2 and so on.

3.2.  MIME Type

   Whenever an HTTP message carries a payload, a proper MIME type needs
   to be specified in the Content-Type header.

   [Editors Note: what would be the best choice here? a new MIME type
   might be the right choice, especially since it would allow network
   administrators to still have control over the encapsulated flows:
   this solution doesn't need to be sneaky! a new MIME type, though, may



Miniero                 Expires February 8, 2013               [Page 10]

Internet-Draft            HTTP Fallback for RTP              August 2012


   also cause messages to be dropped or refused by intermediaries that
   can't figure a way to deal with it: in this case, an existing MIME
   type may be considered for the purpose.]

3.3.  Packet header

   While RTP headers may have extensions stating how long the header
   will be, they do not contain any information about how long the
   overall packet is.  Considering the streaming nature of TCP, this
   information needs to be made available when RTP packets are
   transported on top of HTTP instead: in fact, packets may be
   fragmented along the way before reaching their destination, and both
   the gateway and the endpoint must be able to univocally and without
   errors extract the original RTP packets as they were sent in the
   first place.  This is especially true when the chunked mode is used
   in HTTP messages: as it will be explained in the next sections, in
   fact, chunked messages may be buffered and/or re-chunked by
   intermediaries, thus fragmenting the original RTP packets along the
   way.

   As such, whenever an RTP packet is encapsulated in an HTTP message,
   before being written to the connection it MUST be prefixed by an
   eight octets header, containing the static signature RTPH and the
   length in bytes of the whole RTP packet (header and payload) in hex
   code.

   Figure 6 presents an example of an RTP packet (in this case, a simple
   GSM frame with no extension headers) encapsulated in HTTP: the four-
   octets header RTPH002D tells the RTP packet that immediately follows
   is exactly 45 bytes long.

         RTPH 002D [ .. 45 bytes follow .. ]


         Figure 6: Header of an encapsulated RTP-over-HTTP packet

3.4.  Chunked mode

   The Chunked Transfer Coding as defined in [RFC2616] allows for a
   payload to be sent in chunks.  Such a Transfer mode is usually
   exploited whenever the size of the payload is not known in advance.
   This is especially useful in streaming, as it allows for a persistent
   connection and continuous transfer of chunks without needing to issue
   further HTTP requests, thus minimizing the overhead imposed by HTTP
   message headers, besides the delay that issuing new HTTP messages may
   add.

   Whenever possible, such a transfer coding mode should be tried and be



Miniero                 Expires February 8, 2013               [Page 11]

Internet-Draft            HTTP Fallback for RTP              August 2012


   exploited by both the endpoint and the gateway.  This means that the
   endpoint MUST set the 'Transfer-Encoding: chunked' and 'Expect: 100-
   continue' headers in the first RTP-related request it sends, be it a
   GET and POST messages.  In case all of the intermediaries up to the
   gateway support chunking, the endpoint MUST send RTP packets as
   chunks.  Any possible buffering/re-chunking that may occur along the
   path MUST be taken care of by the receiver according to the header
   specified in Section 3.3.

3.5.  Non-chunked mode

   Unfortunately, not always the Chunked Transfer Coding can be used to
   send and receive HTTP messages.  Any of the intermediaries may only
   be an HTTP 1.0 compliant endpoint, or may arbitrarily choose to
   reject chunked messages for any reason.  If that's the case, the
   endpoint MUST fallback to the default transfer mechanism, that is,
   issuing different requests for different RTP packets, increasing the
   'p' sequence value accordingly.  Both the endpoint and the gateway
   MAY choose to aggregate more RTP packets in the same message: in that
   case, though, each RTP packet MUST be properly prefixed by the header
   defined in Section 3.3, in order to allow framing.  Besides, the
   endpoint MAY want to issue more HTTP connections in parallel and send
   messages on them in turns.

   Even in this mode, the endpoint SHOULD try to open a persistent
   connection and keeping it alive for as long as possible: in case a
   connection is closed and the endpoint wants to keep on using it, it
   MUST open a new connection and send a new request coherently with the
   related RTP stream direction (e.g., a GET for the incoming stream)
   and the current sequence value.





















Miniero                 Expires February 8, 2013               [Page 12]

Internet-Draft            HTTP Fallback for RTP              August 2012


4.  Negotiation and relation to ICE

   While the previous sections describe how RTP packets can be carried
   on top of HTTP messages, they tell nothing about how support for any
   of those features can be negotiated.  Such a negotiation within the
   context of an offer/answer is absolutely relevant, and can be related
   to the ICE mechanism.  In fact, an HTTP fallback can be basically
   seen as an additional candidate for endpoints to report to their
   peers.

   While it is likely that HTTP fallback will only be used in extreme
   circumstances, that is, scenarios where the gathering of non-local
   ICE candidates failed (e.g., because o UDP filtering), endpoints may
   choose to also report HTTP fallback candidates in their SDP along the
   other existing ones.

4.1.  HTTP fallback candidates

   As explained in Section 3.1, reserving an HTTP fallback channel
   provides the endpoint with the public address the gateway will use to
   send and receive RTP packets on behalf of the endpoint itself.  As
   such, this address can be added to the list of ICE candidates (if
   any) already gathered by the endpoint.  This allows both HTTP
   fallback-aware and -unaware endpoints to interact with the gateway in
   order to indirectly communicate with the endpoint.

   [Editors Note: especially for topology 3, and considering TURN relays
   have something like this, it may have sense to also explicitly report
   an HTTP fallback somehow: how could this be reported as a candidate?
   a new protocol in the list? would this affect backward
   compatibility?]




















Miniero                 Expires February 8, 2013               [Page 13]

Internet-Draft            HTTP Fallback for RTP              August 2012


5.  Security Considerations

   TBD.: many, probably, and even more likely not less than the ones
   TURN already reports.















































Miniero                 Expires February 8, 2013               [Page 14]

Internet-Draft            HTTP Fallback for RTP              August 2012


6.  IANA Considerations

   TBD.
















































Miniero                 Expires February 8, 2013               [Page 15]

Internet-Draft            HTTP Fallback for RTP              August 2012


7.  Acknowledgments

   The authors would like to thank...
















































Miniero                 Expires February 8, 2013               [Page 16]

Internet-Draft            HTTP Fallback for RTP              August 2012


8.  References

8.1.  Normative References

   [I-D.ietf-rtcweb-use-cases-and-requirements]
              Holmberg, C., Hakansson, S., and G. Eriksson, "Web Real-
              Time Communication Use-cases and Requirements",
              draft-ietf-rtcweb-use-cases-and-requirements-09 (work in
              progress), June 2012.

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

   [RFC2616]  Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
              Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
              Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.

   [RFC2818]  Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000.

   [RFC3261]  Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
              A., Peterson, J., Sparks, R., Handley, M., and E.
              Schooler, "SIP: Session Initiation Protocol", RFC 3261,
              June 2002.

   [RFC3264]  Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model
              with Session Description Protocol (SDP)", RFC 3264,
              June 2002.

   [RFC3550]  Schulzrinne, H., Casner, S., Frederick, R., and V.
              Jacobson, "RTP: A Transport Protocol for Real-Time
              Applications", STD 64, RFC 3550, July 2003.

   [RFC5245]  Rosenberg, J., "Interactive Connectivity Establishment
              (ICE): A Protocol for Network Address Translator (NAT)
              Traversal for Offer/Answer Protocols", RFC 5245,
              April 2010.

   [RFC5389]  Rosenberg, J., Mahy, R., Matthews, P., and D. Wing,
              "Session Traversal Utilities for NAT (STUN)", RFC 5389,
              October 2008.

   [RFC5766]  Mahy, R., Matthews, P., and J. Rosenberg, "Traversal Using
              Relays around NAT (TURN): Relay Extensions to Session
              Traversal Utilities for NAT (STUN)", RFC 5766, April 2010.







Miniero                 Expires February 8, 2013               [Page 17]

Internet-Draft            HTTP Fallback for RTP              August 2012


8.2.  Informative References

   [RFC6202]  Loreto, S., Saint-Andre, P., Salsano, S., and G. Wilkins,
              "Known Issues and Best Practices for the Use of Long
              Polling and Streaming in Bidirectional HTTP", RFC 6202,
              April 2011.

   [RFC6455]  Fette, I. and A. Melnikov, "The WebSocket Protocol",
              RFC 6455, December 2011.










































Miniero                 Expires February 8, 2013               [Page 18]

Internet-Draft            HTTP Fallback for RTP              August 2012


Author's Address

   Lorenzo Miniero
   Meetecho
   Via Carlo Poerio 89
   Napoli  80100
   Italy

   Email: lorenzo@meetecho.com










































Miniero                 Expires February 8, 2013               [Page 19]