[FMS] Best practices for real-time collaboration using Flash Media Server

* 이 포스팅은 영문포스팅을 직접 번역한것입니다. 전문가가 아닌만큼 오역이 있을 수 있다는 점 참고하세요. - Kevin

 

Flash Player 10버전에서 Adobe사는 Real-Time Media Flow Protocol(RTMFP)를 소개했었습니다.  실시간 어플리케이션을 사용할 경우, RTMFP는 RTMP와 비교했을 때 많은 이점들을 제공합니다. (특히나 대기시간 감소시킬때와 p2p 연결시)

With the release of Flash Player 10, Adobe introduced Real-Time Media Flow Protocol (RTMFP). When used for real-time collaboration applications, RTMFP provides several advantages when compared to Real-Time Messaging Protocol (RTMP)—most notably, reduced latency and direct peer-to-peer connections.

 

하지만 RTMFP를 사용하기 위해서는 Flash Player는 Flash Media Server4나 코드네임 Cirrus와 같은 실시간 통신서비스에 연결해야 합니다. Adobe에서 호스팅 된 Cirrus서비스는 개발을 목적으로 사용 할 수 있습니다. 불필요한것을 뺀 오직 rendezvous(연결?) 서비스만 제공하는 아주 기본이 되는 버전의 FMS를 볼 수 있습니다. 그 버전은 미디어 중계(media relay), 공유객체(shared obejct), 원격 메소드 호출(remote method invocation), 혹은 FMS4의 다른 버전들의 특징들을 지원하지 않습니다.

To use RTMFP, however, Flash Player needs to connect to a real-time communications service such as that provided by Adobe Flash Media Server 4 or Codename Cirrus. The Cirrus service (rtmfp://p2p.rtmfp.net), hosted by Adobe, can be used for development purposes. You can view it as a stripped-down version of Flash Media Server (FMS) 4 that exclusively provides a rendezvous service: it does not support media relay, shared objects, remote method invocation, or other features of Flash Media Server 4.

 

RTMFP를 사용해 상용 어플리케이션을 DEPLOY하기 위해서는, Flash Media Server 4 버전을 사용해야 합니다. FMS의 뛰어난 기능들을 사용할 수 있을 뿐만 아니라, 어플리케이션 deployment를 방지 할 수 있는 Cirrus서비스의 제한과 관련된 방화벽을 설정할 수 있습니다. (deploy시킨다는게 먼말이지 ㅜㅜ)

To deploy commercial applications using RTMFP, you must use Flash Media Server 4. Not only can you take advantages of all FMS capabilities, but you can address firewall-related limitations of the Cirrus service that would prevent successful deployment of your application.

 

이 글은, RTMP와 대비되는 RTMFP의 이점을 서술하고 있습니다. 그리고 RTMFP에 의해 직면된 과제들을 서술하고 있습니다.  그다음으로는, FMS를 사용한 직면된 과제들의 해결책을 제공합니다. 마지막으로 비디오미팅 샘플 어플리케이션을 제공합니다. 이 어플리케이션은 여러가지 다른 환경(여러 버전의 Flash Player버전, 여러종류의 네트워크 방화벽)에서 어떻게 균일하게 동작하는지를 보여줍니다.

In this article, I first point out the advantages of RTMFP versus RTMP. I then describe the challenges faced by RTMFP. Next, I provide solutions for these challenges using Flash Media Server. Finally, I present a sample video meeting application demonstrating how to seamlessly work around different versions of Flash Player instances and network firewall devices.

 

이 글은 중고급 Actionscript개발자들을 위한 글입니다.(ㅠㅠ) 기본적인 스트림 어플리케이션을 어떻게 만드는지는 설명하지 않았고, 좀 더 심화된 주제에 중점을 뒀습니다. RTMFP API는 다음 링크를 보세요. http://www.adobe.com/devnet/flashplayer/articles/rtmfp_cirrus_app.html

This article is intended for intermediate and advanced ActionScript developers. It does not explain how to create basic streaming applications, but focuses on more advanced topics. For an introduction and API review of RTMFP, please read Cirrus service for developing end-to-end applications using RTMFP in Flash Player 10.

 

Adobe LiveCycle Collaboration Services(LCCS)는  여기서 논의된 모든 주제를 다루는 high-level SDK 입니다. 이 글은 LCCS에서 제공하는 것보다 많은 콘트롤을 얻고 싶은 개발자들을 위한 글입니다.

Adobe LiveCycle Collaboration Services (LCCS) is a high-level SDK that takes care of all the issues discussed here. This article is intended for developers who would like to get more control than that provided by LCCS.

 

Flash Player 10.1 버전, Flash Media Server 4 환경에서  RTMFP 어플리케이션 레벨과 native IP 멀티캐스팅에 대해 더 많은 기능을 제공합니다. RTMFP의 이 기능들은 이 글에서 다루지 않습니다.

With the release of Flash Player 10.1 and Flash Media Server 4, RTMFP further provides application-level and native IP multicast. These capabilities of RTMFP are out of the scope of the article.

 

real-time collaborations 대한 RTMFP의 이점(Advantages of RTMFP for real-time collaborations)

 

RTMP는 Flash Player 6버전에서 소개된 프로토콜 입니다. 주로 오디오와 비디오 콘텐츠 스트리밍에 초점이 맞춰져 있었습니다. RTMP는 HTTP tunneling과 컨텐츠 보호 등 시간이 지남에 따라 RTMP는 발전했습니다. RTMP는 TCP를 기반으로 두고 있습니다.  TCP를 기반으로 한다는 것은 FMS와 Flash Player사이에 신뢰할 수 있는 데이터 전송을 제공합니다. 이는 무한대기가 발생할 수 있습니다. 하지만 broadcast-type media distribution,live, recored 대해서는 문제가 되지 않습니다.  왜냐하면 Flash Player는 버퍼를 이용해 재생하기 때문에입니다.(버퍼링을 사용으로 무한대기가 발생하지 않기때문에 문제가 되지 않는다는 말인듯...) - 일반적으로 몇초의 버퍼링으로 네트워크 인터럽션을 보상 할 수 이죠. 

  미디어 데이터 온전성을 보호하는 것은 시기적절한 미디어 전송보다 중요합니다. (빠른 미디어 전송보다는 손실되지 않은 미디어 전송이 더 중요하다는 말, 그래서 여기서 제공되는 어플리케이션을 미디어 손실을 최소화 시켯다는 말)   미디어 손실은 예측불허의 오디오/비디오 왜곡을 일으킵니다.

RTMP is an open protocol introduced in Flash Player 6 that mainly targets streaming audio and video content. Over time, several flavors of RTMP were developed, including tunneling over HTTP, providing protected content, and more. RTMP is based on Transmission Control Protocol (TCP). As such, it provides reliable data delivery between Flash Media Server and Flash Player, which is achieved at the price of unbounded delay. This is not a problem for broadcast-type media distribution (either live or recorded) because Flash Player maintains a playback buffer—typically several seconds long—that can compensate for network interruptions. In these applications, ensuring media integrity is of higher importance than timely delivery. Losing media data could also introduce undesirable audio/video distortion.

 

Flash Player 10과 Adobe AIR 1.5에서 RTMFP가 소개되었습니다. RTMP와는 다르게 RTMFP는 User Datagram Protocol(UDP) 기반으로 되어 있습니다. UDP는 빠르고, 최소한의 오버헤드가 발생하는 신뢰적이지 않는 data(빠르지만 그만큼 Data손실이 일어나기 때문에 신뢰적이지 않는 Data라고 표현하는가 보네요~)를 전송합니다. 흐름제어(flow control), 정체제어(congestion control), 안전장치(safeguards)가 없습니다. UDP는 종점(endpoints, end유져) 사이에 딜레이를 최소화 하는것이 최고로 중요한 실시간 통신 어플리케이션에 사용됩니다. 덧붙이면, UDP는 endpoints사이의 미디어 교환을 가능하게 합니다. 이는 endpoints사이의 딜레이 감소 뿐만 아니라 미디어 중계서버들의 필요성을 감소 시킵니다.

Flash Player 10 (and Adobe AIR 1.5) introduced RTMFP. Unlike RTMP, RTMFP is based on User Datagram Protocol (UDP). UDP provides fast and unreliable data delivery with minimal overhead; there is no flow control, congestion control, or other safeguards. UDP is popularly used for real-time communications applications where minimizing delay between communicating endpoints is of utmost importance. In addition, UDP also facilitates direct media exchange between communicating endpoints, which not only further reduces delay between endpoints, but also reduces media relay server requirements.

 

실시간 어플리케이션에서는, 딜레이를 최소화 시키는게 가장 중요한 이슈가 될 것 입니다. 수백밀리초의 딜레이는 원활한 대화를 하는데 있어서 중요한 문제입니다. 믿을만한 전송을 얻는다는 것은 네트워크 전송 에러를 다루도록(에러나면 에러를 은폐할 수 있는 기술이 코덱에 있는가 보네요.) 디자인 되어진 일반적인 오디오,비디오 코덱기술이 필요로 하지 않을 지도 모릅니다.(Flash Player에서 사용 할 수 있는 Speex음성 코덱이나 H264비디오코덱과 같은것)

In real-time collaboration applications, minimizing delay is one of the most important goals; a few hundred milliseconds' worth of delay could render a conversation unusable. Achieving reliable transmission may not be needed since modern audio and video coding technologies (such as the Speex voice codec and the H.264 video codec, both available in Flash Player) are designed to deal with network transmission errors and thus provide error concealment techniques.

 

RTMP와 RTMFP를 비교해 볼 때, RTMFP는 실시간 어플리케이션에 다음과 같은 이점을 제공합니다.

When compared to RTMP, RTMFP provides the following advantages for real-time collaborations applications:

 

짧은 대기: 왜냐하면 UDP기반으로 설계되었기 때문입니다.  짧은 대기시간은 실시간 어플에서 가장 중요한 점입니다. 대기시간은 end-to-end 미디어 전송 메커니즘으로 더욱 줄일 수 있습니다.

Low latency: Because it is built on top of UDP, RTMFP provides minimal latency, which is of paramount importance for real-time collaboration applications. Latency can be further reduced by using an end-to-end media delivery mechanism.

 

부분적 신뢰: 어플리케이션 요구사항에 따라, RTMFP는 신뢰할수 있는전송, 혹은 신뢰할 수 없는 전송을 제공합니다. 물론 신뢰할 수 있는 전송은 무제한 대기상태를 초래합니다.(이는 RTMP와 다를게 없죠)  다시말하면 신뢰할 수 없는 전송을 사용해야 대기를 최소화 시킬 수 있다는 말입니다. RTMFP는 두 endpoints사이의 통신에서 미디어는 unreliably하게, 데이터는 reliably하게 보냅니다.(미디어는 빠르지만 손실이 일어나고, 데이터는 느리지만 손실이 일어나지 않는 전송을 한다는 말인것 같습니다. 어렵네요 ㅜㅜ)  RTMFP는 reliable과 unreliable 전송 모두에 혼잡제어(congestion control)를  수행합니다.

Partial reliability: Depending on your application needs, RTMFP can provide reliable or unreliable transmission. Naturally, reliable transmission results in unbounded delay—the same as with RTMP. On the other hand, you can minimize latency by using unreliable transmission. RTMFP allows for sending media unreliably and data reliably over the same connection between two communicating endpoints. RTMFP performs congestion control over UDP for both reliable and unreliable transmissions.

 

종단간 미디어 전송: Flash Player endpoints 사이에 중계서버 라우팅없이 직접적으로 미디어를 보낼수 있습니다. 반면 RTMP는 모든 미디어가 FMS로 보냅니다. 이것은 응답시간(latency)뿐만 아니라 서버 요구사항?(server requirements)을 줄일 수 있습니다. RTMFP는 각각의 Flash Player endpoint에게 peer id를 부여합니다. 퍼블리싱하는 Flash Player endpoint의 미디어를 받기위해, 섭스크라이빙 endpoint쪽(받는쪽) 입장에서는 원격 peer ID는 명시되어야 합니다. 퍼블리싱하는 peer는 각각의 직접적으로 받는쪽peer를 명확하게 인지해야합니다. 

 

End-to-end media delivery: Media can be directly sent between Flash Player endpoints without routing through a central relay server, whereas RTMP requires all media sent through FMS. This not only reduces latency but also reduces server requirements. RTMFP assigns a peer identifier to each Flash Player endpoint. To receive media from a publishing Flash Player endpoint, a subscribing endpoint must specify the remote peer's ID. The publishing peer must explicitly approve each direct subscribing peer.

 

데이터 우선순위: 오디오, 비디오, 데이터는 제한된 네트워크 자원을 가지는 환경에서 다른 우선순위를 가지고 전송됩니다. 오디오는 비디오보다 우선순위가 높습니다. 즉, data보다 더 높은 우선순위로 보내어 진다는 말입니다. (단, 그 data는 항상 reliably하게 보내어 진다.)

Data prioritization: Audio, video, and data are transmitted with different priority in case of limited network resources. Audio is sent with higher priority than video, which is sent with higher priority than data (note, however, that data is always sent reliably).

 

암호화: RTMFP를 이용한 통신은 항상 AES 128-bit long keys를 이용해 암호화 된다. 이는 Diffie-Hellman key exchange 메소드를 사용해서 암호화 된다. 여기서 주의해야 점은 RTMFP는 SSL과 RTMPS와 같이 강력한 endpoint 인증메소드를 제공하지 않는다는 것입니다. 그러나 Flash Player는 어플리케이션개발자에게 secure nonces(?) 

를 보여줍니다. non-forgeable nonces는 모든 endpoints통신, 매치시키기 위해 보증되는데 이용된다. (뭔말이지 ㅜㅜ)   이는 man-in-the-middle공격들로부터 부호할 수 있습니다.

Encryption: Communications over RTMFP are always encrypted using AES 128-bit long keys, which are negotiated using the Diffie-Hellman key exchange method. It is important to note that RTMFP does not provide strong endpoint authentication methods such as SSL or RTMPS. However, Flash Player does expose secure nonces to application developers. These non-forgeable nonces are available to all communicating endpoints and are guaranteed to match, which can be used to protect against man-in-the-middle attacks.

 

RTMFP를 사용함에 있어 도전과제 (Challenges of using RTMFP)

 

RTMFP를 사용하기 위해서는 Flahs Player는 서비스에 연결되어야 합니다.(Cirrus service나 FMS와 같은것)   이것은 so-called peer identifier를 얻는것이 필요합니다. 이 id는 256비트 랜덤한 유니크한 숫자로 peers사이의 통신을 하기위해 사용됩니다.

To use Real-Time Media Flow Protocol (RTMFP), Flash Player needs to connect to a service (either the hosted Cirrus service or Flash Media Server). This is required to obtain a so-called peer identifier, a unique 256-bit random number that is used in establishing communications between peers.

 

상업 어플리케이션 개발 시, 개발자들은 다음의 이슈에 알아야 합니다.

When creating commercial applications, developers must address the following issues:

 

UDP 블로킹: 앞서 언급했듯이, RTMFP는 UDP기반입니다. 많은 기업 방화벽들이 전적으로 UDP 트래픽을 차단하고 있습니다. 차선책중 하나로 RTMFP에 대한 proxy우회설정을 하면 되지만, 더 이상적인 해결책은 RTMFP에서 RTMP로, 혹은 RTMFP에서 RTMP Tunneled로 대비(fall back) 하는것 입니다.

UDP blocking: As I mentioned before, RTMFP is based on UDP. Many corporate firewalls block UDP traffic altogether. One of the workarounds is to configure a TURN proxy for RTMFP, but a more desirable solution is to fall back from RTMFP to RTMP or RTMP Tunneled (RTMPT).

 

Convergence of RTMFP and RTMP: RTMFP는 Flash Player 9 버전, 혹은 그 이전 버전, 방화벽이 UDP를 차단하고 있을 경우에서는 사용 할 수 없습니다. Flash Player 클라이언트는 RTMP나 RTMFP를 사용하는것은 서로서로 미디어 교환을 할 수 있게 한다는 것이 중요합니다.

Convergence of RTMFP and RTMP: RTMFP cannot be used if Flash Player 9 or earlier is involved in collaboration, or if firewalls block UDP. It is important that Flash Player clients using either RTMP or RTMFP can exchange media with each other.

 

Failover in case of firewall blocking: 양쪽의 클라이언트가 RTMFP를 이용해서 rendezvous서비스에 성공적으로 연결 되어도, 클라이언트가 서로에게 직접적으로 미디어를 보낸다는 보장이 없습니다.  직접적인 통신이 가능하냐는 것은 클라이언트 단의 방화벽들의 환경상태에 달려 있습니다. 직접적인 연결이 불가능 할 경우, 미디오 중계를 중점적으로 할 수 있는 대안(Failover)이 필요합니다.

Failover in case of firewall blocking: Even if both clients can successfully connect to the rendezvous service using RTMFP, there is no guarantee that clients can directly send media to each other. It really depends on the combination of firewalls located at clients to determine whether direct communication is possible. When a direct connection is not possible, failover to centrally relayed media is required.

 

다중 통신: 다수통신의 경우, 각 클라이언트는 나머지 모든 클라이언트에 미디어를 보내야 합니다. 그러기 위해서는 대칭되는 업링크와 다운링크가 필요합니다.  ADSL이나 회선연결에서는 좋지 못한 매칭입니다. 3명이상의 커뮤니케팅을 할 경우에는 CS구조가 더 좋을 것입니다.

Multiparty communications: In a multiparty scenario, each client must send media to every other client. This requires symmetric uplink and downlink, which is a poor match to consumer ADSL or cable connections. When more than three communicating parties are involved, it is probably more advantageous to use client-server media delivery topology.

 

User lookup: rendezvous 서비스에 연결됐을때, Flash Player는 유일한 peer ID를 만듭니다. 두 endpoints Flash Player사이에 직접적인 통신을 하기위해서는 필히 다른 endpoints의 peer ID를 알아야 합니다. 이 peer ID를 바꿔주는 것은 어플리케이션딴에서 해야합니다.

User lookup: When connected to a rendezvous service, Flash Player creates a unique peer ID. In order to establish direct communications between two Flash Player endpoints, each must know the other's peer ID. It is the application's responsibility to exchange these peer IDs.

 

다음 세션은 FMS를 사용하면서 이러한 도전과제들을 어떻게 다룰지를 좀 더 상세히 설명합니다.

The following section reviews in detail how you can address each of these challenges by using Flash Media Server.

 

 

RTMFP통신을 위한 FMS 사용 (Using Flash Media Server for RTMFP communications)

FMS4는 RTMFP의 모든 이점들을 사용하면서 어플리케이션을 개발 할 때 사용될 수 있습니다. 추가로, 공유객체(shared obejct)나 원격메소드호출(remote method invocation, RMI)과 같은 모든 형태의 기능들을 사용 할 수 있습니다.

Flash Media Server (FMS) 4 can be used to build applications using all the advantages of RTMFP. In addition, one can take advantage of all existing features such as shared objects and remote method invocation (RMI).

 

다음 세부항목은 클라이언트사이드, 서버사이드 양쪽의 ActionScript소스코드 제공하면서, 앞서 언급한 RTMFP의 각각의 과제들을 address하는지 설명하고 있습니다. 

The following subsections describe how to address each of the challenges of RTMFP described in the previous section, providing ActionScript source code for both client and server where applicable.

 

UDP차단 (UDP blocking)

SOHO환경(small office or home office,기업이 아닌 작은회사나 가정집)의 방화벽의 경우가 아니라면, 기업의 방화벽의 경우 전체적으로 UDP 트래픽을 차단하는 것이 일반적입니다. 이것에 대한 한가지 해결책은 프록시 우회(TURN proxy)를 위한 Flash Player를 설정하는 것입니다.(Traversal Using Relays around NAT).  Adobe Flash Player 10.1 Administration Guide에 기술되어 있듯이, Flash Player는 mms.cfg 파일의 다음 옵션을 명시함으로 IETF Internet Draft "draft-ietf-behave-turn-08" 을 지원하기 위해 어떠한 허용 없이도 수정 될 수 있다.

While rarely the case with small office or home office (SOHO) firewalls, it is quite common for corporate firewalls to block UDP traffic altogether. One solution is to configure Flash Player to use a TURN proxy (Traversal Using Relays around NAT). As documented in the Adobe Flash Player 10.1 Administration Guide, Flash Player can be configured to support IETF Internet Draft "draft-ietf-behave-turn-08" without authentication by specifying the following option in mms.cfg:

 

RTMFPTURNProxy = ip_address_or_hostname_of_TURN_proxy

 

이 방법은 개발을 위한 기업의 IT부서와 TURN proxy기반으로 deploy 하는 것이 필요합니다.

This solution requires your corporate IT department to develop and deploy a conforming TURN proxy.

 

더 이상적은 방법은 server로의 RTMFP연결이 실패했을 경우, 균일하게 RTMP연결로 대치 하는 것입니다. 불행히도, RTMFP의 서버로의 연결이 성공적일 것인지를 알 수 있는 방법은 없습니다. 한가지 방법으로... 다시 연결을 시도하거나, NetConnection.Connect.Success 혹은 NetConnection.Connect.Failed 의 응답을 기다리는 것이 유일한 방법입니다.

연결실패했을 때 NetConnection.Connect.Failed 이벤트가 90초 후에 발생됩니다. 한가지 접근방법은 서버로의 RTMP, RTMFP연결 모두 parallel connections을 시도하는 것입니다. RTMFP연결이 성공할 때 마다, RTMP연결을 간단히 닫아줍니다. (RTMFP연결되면 RTMP연결을 닫아주는걸 parallel connections 라고 표현하네요.)

A more desirable solution is to seamlessly fail over to an RTMP connection when an RTMFP connection to the server cannot be established. Unfortunately, there is no way to probe whether an RTMFP connection to the server will be successful. The only way is to attempt the connection and wait for a NetConnection.Connect.Success or NetConnection.Connect.Failed response. A failed connection will provide a NetConnection.Connect.Failed event after a 90-second timeout. One approach would be to try parallel connections of both RTMP and RTMFP to the server. Whenever RTMFP succeeds, the RTMP connection can simply be closed.

 

또다른 방법은  타임아웃을 두어 우선순위에 따라 연속적으로 프로토콜 하는 것입니다. 아래 간단한 클라이언트사이드 ActionScript코드는 연속적 연결을 하는 것을 보여줍니다.

Another strategy is to try protocols sequentially in preference order (for instance, RTMFP, RTMP, RTMPT) with a given timeout. This sample client-side ActionScript code demonstrates sequential connection establishment:

                  private var rtmfpTimer:Timer = null;

                    private var netConnection:NetConnection = null;

                    private const ConnectionTimeout:int = 5000;

                   

                    public function register(rtmp:Boolean):void

                    {

                           netConnection = new NetConnection();

                           netConnection.addEventListener(NetStatusEvent.NET_STATUS, connectionHandler);

                           netConnection.connect(rtmp ? "rtmp:" : "rtmfp:" + "//server.domain/application");

                          

                           if (!rtmp)

                           {

                                 rtmfpTimer = new Timer(ConnectionTimeout, 1);

                                 rtmfpTimer.addEventListener(TimerEvent.TIMER_COMPLETE, rtmfpTimeoutHandler);

                                 rtmfpTimer.start();

                           }

                    }

                   

                    private function rtmfpTimeoutHandler(e:TimerEvent):void

                    {

                           netConnection.close();

                           netConnection = null;

                          

                           register(true);

                    }

                   

                    private function connectionHandler(e:NetStatusEvent):void

                    {

                           if (rtmfpTimer)

                           {

                                 rtmfpTimer.stop();

                                 rtmfpTimer = null;

                           }

                          

                           if ("NetConnection.Connect.Success" == e.info.code)

                           {

                                 // RTMFP or RTMP connection succeeded

                           }

                           else if ("NetConnection.Connect.Failed" == e.info.code)

                           {

                                 // RTMFP or RTMP connection failed

                           }

                    }

 

Convergence of RTMP and RTMFP

Flash Player endpoints가 모두 RTMFP를 사용 할 수 있는것은 아닙니다. 예를들면:

It is quite possible that not all Flash Player endpoints can use RTMFP. For instance:

• Flash Player 9 버전, 혹은 그 이전버전 (Flash Player 9 or an earlier version is used, and thus RTMFP is not available)
• 방화벽이 UDP를 막았을 경우 (A firewall blocks UDP, and thus RTMFP is not possible)

위의 두 경우의 해결책은 FMS를 통해 미디어를 보내는 것입니다. FMS는 RTMPx와 RTMFP 스트림 모두 바인딩 합니다.: 어떤 서버나 클라이언트 동작이 필요치 않습니다.

In both of these cases, the only solution is to send media through Flash Media Server. FMS will transparently bind RTMPx and RTMFP streams together: no server or client work is needed.

 

RTMP는 오직 CS 구조에서 동작한 이후, 직접통신과 CS통신 사이에 conference topology를 바꿔주어야 합니다.(무슨말이지...)  가령 A,B 라고 하는 두 클라이언트가 RTMFP를 이용한 직접통신방식의 비디오 미팅에 있다고 해봅시다. 클라이언트 C가 들어왔을 경우, 미팅 토폴로지는 C-S구조로 바뀌어야 합니다. 그것은 모든 미디어는 중앙FMS서버를 거쳐야 한다는 것입니다. 참석자C가 방을 나가면, 미팅은 직접연결방식으로 바뀔 수 있습니다. 클라이언트 A, B는 RTMFP에서 RTMP로 프로토콜을 바꿀 필요가 없다는 것을 주의하십시오; FMS는 두 프로토콜을 유기적인 연결합니다.

Since RTMP only works in a client-server scenario, your application is responsible for switching its conference topology between direct communications and client-server communications. Assume that there are two participants (say, A and B) in a video meeting using direct communications over RTMFP. When client C (using RTMP) joins, the meeting topology must be converted to client-server; that is, all media must go through the central FMS. When client C leaves, the meeting can be converted back to a direct connection. Note that clients A and B do not need to change protocol from RTMFP to RTMP; FMS will perform seamless bridging of the two protocols.

 

방화벽차단의 경우 Failover (Failover in case of firewall blocking)

두개의 Flash Player endpoints가  RTMFP서비에서 성공적으로 연결이 된다 하더라도, 두 클라이언트가 서로서로 직통으로 통신할 수 있다는 보장은 없습니다. 왜냐하면 방화벽과 같은 중간 매개체가 두 클라이언트 사이를 차단 할 수 있기 때문입니다. RFC 3489, NAT를 통하는 UDP의 STUN-SImple Traversal - NAT는 다음의 4가지형태로 분류된다.

1. Full cone

2. Restricted cone

3. Port Restricted cone

4. Symmetric.

* Full cone가 가장 관대하고, symmetric가 가장 제한적임.

다음 예제는 방화명은 위 4가지 형태로 분류될 수 없음을 나타내어 줍니다. 예를들면 방화벽이 있으면 들어오는 트래픽과 나가는 트래픽의 다른 양상을 보입니다.

Even if both Flash Player endpoints successfully connect to the RTMFP service, there is no guarantee that two clients can communicate directly with each other because intermediaries such as firewalls can block communications between two endpoints. RFC 3489, STUN—Simple Traversal of User Datagram Protocol (UDP) Through Network Address Translators—classified network address translators (NATs) into the following four categories: full cone, restricted cone, port restricted cone, and symmetric. (Full cone is the most permissive and symmetric is the most restrictive.) Later experimentation has found that firewalls cannot be clearly classified to the above categories; for instance, certain firewalls exhibit different behavior for incoming and outgoing traffic.

 

endpoints사이의 직접통신이 방화벽타입을 앎으로 성공적일지 혹은 성공적이지 않을지라도, 어떤 보증도 할 수 없습니다. (방화벽 타입을 안다고 해서, 연결을 확신 할 수 있는게 아니다.)두 endpoints 사이에 직접통신이 가능한지를 확인하는 가장좋은 방법은 간단하게 시도해보는 것입니다. 이 방법은 RFC 5245에 채택된 접근 방법입니다.

A Protocol for Network Address Translator (NAT) Traversal for Offer/Answer Protocols. 첫번째, 다양한 통신주소가 수집됩니다. 이 주소들은 로컬주소(local address), 외부주소(external address), 중계주소(relayed address) 입니다. 통신은 성공확률이 가장높은 주소들을 가지고 연결됩니다.(cheapest solution은 아님) 그리고 그후 cheapest possible solution(local address)으로 바꿉니다.

Although you can predict whether direct communications between two endpoints will be successful by knowing the firewall types, no guarantees can be given. The best way to see whether direct communication between two endpoints is possible is simply to try. This is the approach adopted by RFC 5245, Interactive Connectivity Establishment (ICE): A Protocol for Network Address Translator (NAT) Traversal for Offer/Answer Protocols. First, a series of communication addresses are collected. These addresses include local addresses, external addresses, or relayed addresses. Communications starts with the address with the highest probability of success (which may not be the cheapest solution) and later changing to the cheapest possible solution (local address).

 

 

이 예제에서 비슷한 솔루션을 사용하였습니다. 먼저 미디어를 서버를 통해 보내는 방법과,  peers들에게 직접 보내는 방법 두가지 모두 사용합니다. FMS를 거쳐 보내는 것은 항상 성공적입니다.  두 클라이언트가 직접통신이 가능한지를 보기위해서는 data messages 사용하면  간단히 알 수 있습니다. 이 방법에는 두가지가 있습니다.

In this example, I've adopted a similar solution. To start, the application sends media both through the server and directly to peers. Sending media through FMS always succeeds. An alternative approach would be to simply probe using data messages to see whether direct connection between two clients is available. There are two ways to detect whether a direct connection was successful:

 

• 직접적으로 연결된 스트림이 들어오는 것에 대한 NetStream.Play.Start의 수신 (Reception of NetStream.Play.Start on an incoming directly connected stream)
• 직접적으로 연결된  스트림이 나오는 것에 대한 NetStream 클라이언트 객체에 대한 onPeerConnect() callback메소드의 수신 (Reception of an onPeerConnect() callback on the NetStream client object on an outgoing directly connected stream)

 

이 예제는 위의 것들을 보여줍니다. 클라이언트를 퍼블리싱하는 코드입니다.

This following sample code demonstrates the idea. Here's the code for the publishing client:

 

                 private var outgoingStreamDirect:NetStream = null;

                    private var outgoingStreamFms:NetStream = null;

                   

                    private function multiPublish():void

                    {

                           outgoingStreamDirect = new NetStream(netConnection, NetStream.DIRECT_CONNECTIONS);

                           outgoingStreamFms = new NetStream(netConnection);

                          

                           outgoingStreamDirect.publish("streamDirect");

                          

                           var c:Object = new Object();

                           c.onPeerConnect = function(peer:NetStream):Boolean

                           {

                                 // if we receive onPeerConnect, it means that direct connection succeeded

                                 if (outgoingStreamFms)

                                 {

                                        outgoingStreamFms.close();

                                        outgoingStreamFms = null;

                                 }

                                 return true;

                           }

                           outgoingStreamDirect.client = c;

                          

                           outgoingStreamFms.publish("streamFms")

                    }

 

클라이언트를 수집하면서, 퍼블리싱하는 peer ID는 이미 알 수 있다고 생각합니다.

In the subscribing client, it is assumed that the publishing peer ID is already known:

 

                   private var incomingStreamDirect:NetStream = null;

                    private var incomingStreamFms:NetStream = null;

                   

                    private function multiSubscribe():void

                    {

                           incomingStreamFms = new NetStream(netConnection);

                           incomingStreamDirect = new NetStream(netConnection, id_of_publishing_client);

                           incomingStreamDirect.addEventListener(NetStatusEvent.NET_STATUS, streamHandler);

                          

                           incomingStreamFms.play("streamFms");

                           incomingStreamDirect.play("streamDirect");

                    }

                   

                    private function streamHandler(e:NetStatusEvent):void

                    {

                           // if Play.Start event received on direct connection, it means that direct communications is possible

                           if ("NetStream.Play.Start" == e.info.code)

                           {

                                 if (incomingStreamFms)

                                 {

                                        incomingStreamFms.close();

                                        incomingStreamFms = null;

                                 }

                           }

                    }

 

미디어를 보내고 받기를 시작할 때, 여러가지 방법을 선택 할 수 있습니다. C-S 스트림을 사용하면서 미디어를 즉시 보내고/받기를 원할 것 입니다. 이경우 모든 케이스가 가능합니다. 하지만 C-S 에서 직접연결로 바꾸때 아주 작은 문제가 있습니다.  그 대신, 직접연결로, 타임아웃 이후 C-S 시작하기를 원할지도 모릅니다.

You have several strategies to choose from for when to start sending and receiving media. You may want to start sending and receiving media right away using the client-server stream, since that will succeed in every case. There may be a small glitch, however, when switching over from client-server to direct connections. Alternatively, you may want to wait to start with a direct connection and failover to client-server after a given timeout.

 

 

Multiparty communications

직접통신은 응답대기를 최소화 시키기 위해 클라이언트와 통신하는 것과, 서버비용을 줄이는 것이기 때문에 선호되는 방법입니다. multiparty session에서  참석한 클라이언트는 각각은 다른 모든 참석한 클라이언트에게 미디어를 보내야 합니다. 따라서  각 클라이언트는 똑같은 uplink, downlink 대역폭을 사용합니다. 각 미디어 스트림은 b bandwidth가 필요하다고 하면, 접속된 클라이언트 수를 n 이라 할때 uplink, downlink 비트율은 b (n–1) 이 됩니다. 이것은 ADSL모뎀 케이블을 쓰는 유저에게는 좋지 않습니다.  500 Kbps 비디오 스트림을 상상해 보십시오. 몇 참석자가 uplink를 쉽게 다 써버릴 것입니다. 그것은 성능저하를 일으킵니다. 반면에 C-S 토폴로지는 비대칭 네트워크 연결에 완벽히 매칭됩니다. b uplink 대역폭과 b (n–1) downlink대역폭이 필요합니다.

Direct connections are preferred between communicating clients to minimize latency and reduce server costs. In a multiparty session, each participating client must send media to all participating clients (see Figure 1). Thus, each client uses the same uplink and downlink bandwidth. Assuming each media stream requires b bandwidth, the required uplink or downlink bitrate is b (n–1), where n is the number of participating clients. This is a poor match for home users' cable or ADSL modems. Imagine a 500 Kbps video stream, even a few participants may easily overwhelm one's uplink, causing performance degradation. On the other hand, client-server topology is a perfect match for asymmetric network connections. It requires b uplink bandwidth and b (n–1) downlink.

 

 

Figure 1. Media transmission in direct connection (left) and client-server (right) topologies. Thin lines denote control connection and thick lines denote media data

 

User lookup

RTMFP는 각 참석자에게 peer ID를 배정합니다. peer ID는 256bits로 되어있고, 강제로 만들 수가 없습니다.  직접적으로 스트림을 보내고 싶을 때, 발신자의 peer ID를 명시해야 합니다.

RTMFP assigns a peer ID to each participant. These peer IDs are 256 bits long and are non-forgeable. When you want to subscribe to a directly published stream, you must specify the publisher's peer ID:

       var receiveStream:NetStream = new NetStream(netConnection, id_of_publishing_client);

       receiveStream.play("media");

 

그러므로 peer ID를 교환하는 일종의 서비스 제공이 필요합니다. XMPP를 이용하거나, peer ID를 교환하는 웹서비스를 이용할 수 도 있습니다. 이 작업을 하기위해 FMS는 원격함수호출(Remote Procedure Call, RPC)와  원격공유객체(Remote Shared Object)를 제공합니다. 다음 예제는 원격함수호출을 이용해 peer ID를 교환하는 방법을 보여줍니다.

Therefore, your application needs to provide some kind of service to exchange peer IDs. You can use XMPP or a web service to exchange peer IDs. FMS offers remote procedure calls or remote shared objects to perform this task. The following example demonstrates how to exchange peer IDs using remote method invocation.

 

Here is the FMS Server-Side ActionScript (SSAS):

 

application.onConnect = function(client, userName)

{

  client.userName = userName;

 

  // server-side functions

  client.getRemoteId = getRemoteId;

 

  application.acceptConnection(client);

 

  return true;

}

 

function findUser(userName)

{

  for (var i = 0; i <= application.clients.length; i++)

  {

    if (application.clients[i].userName == userName)

    {

      return i;

    }

  }

  return -1;

}

 

function getRemoteId(userName)

{

  var result = new Object;

  result.userName = userName;

  result.id = "";

  result.protocol = "";

 

  var index = findUser(userName);

  if (-1 != index)

  {

    result.id = application.clients[index].farID;

    result.protocol = application.clients[index].protocol;

  }

  return result;

}

 

Here is the Flash Player code to register and look up the peer ID:

 

                    private var netConnection:NetConection = null;

                   

                    private function connect():void

                    {

                           netConnection = new NetConnection();

                           netConnection.connect("rtmfp://example.com/app", "user");

                    }

                   

                    private function lookup(remoteUser:String):void

                    {

                           var responder:Responder = new Responder(userResult);

                           netConnection.call("getRemoteId", responder, remoteUser);

                    }

                   

                    private function userResult(result:Object):void

                    {

                           // process respons

                           // result.id;

                           // result.userName;

                           // result.protocol;

                    } 

 

 

 

Sample video meeting application

rtmfp_app_assets.zip

 

이 글에 논의된 사항들을 나타낸 샘플App을 개발했습니다.

I have developed a sample application demonstrating the following items discussed in this article:

 

• 서버로의 최선의 연결사용. RTMFP가 선호됐습니다.(RTMFP 접속불가시 RTMP 사용) (Use the best connection method to the server. RTMFP is preferred, with fall-back to RTMP if RTMFP is not possible)
• 서버에 유저 등록, 유져 lookup에 대한 원격메소드호출 사용 (Register users at the server, using remote method invocation for user lookup)
• 3명 혹은 더 적은 참석인원일때 직접연결을 시도함. 직접연결 실패시 C-S구조로 Data를 보냄. (Try to establish direct communications when there are three or fewer participants. If direct connection fails, use client-server data delivery)
• 참석자가 3명이상일 경우, C-S구조로 토폴로지를 바꿈. 참석자가 나가면 다시 직접통신으로 바꿈. (If there are more than three participants, switch topology to client-server. When a participant leaves, switch back to direct media delivery)
• 예를들어 UDP가 차단되어 RTMP만 사용가능 할 때 C-S 토폴로지를 사용 (If a communicating endpoint can only use RTMP for example, when UDP is blocked, use client-server conferencing topology)

 

이 어플리케이션은 Flash Builder 4로 개발되엇습니다. 최소한 Flash Player 10버전이 필요합니다. Flash Player9버전에는 완벽하게 동작하지 않습니다. FMS4버진이 필요합니다. 응답시간을 최소화 하기 위해서는, Aggregate Messages and Queuing (by disabling AggregateMessages in Vhost.xml, Queue and AggregateMessages in Application.xml); see also Send aggregate messages in the Flash Media Server online documentation.

The application was developed using Flash Builder 4. The minimum requirement is Flash Player 10; it does not handle Flash Player 9 gracefully (an update is required using Express Install). The application requires Flash Media Server 4. In order to minimize latency for real-time collaboration applications, disable Aggregate Messages and Queuing (by disabling AggregateMessages in Vhost.xml, Queue and AggregateMessages in Application.xml); see also Send aggregate messages in the Flash Media Server online documentation.

 

예제파일은 다음 파일들을 포함합니다.

The following files are included:

 

• main.asc: Server-side code to manage meetings and send notifications and participant list when a user joins or leaves a meeting.
• VideoMeeting.mxml: Main application component, including user interface.
• ConnectionManager.as: Component handling the connection to FMS, with failover.
• SessionManager.as: Component handling participants and media; uses direct connection when possible with failover to client-server topology. Also includes outgoing NetStream object.
• LoginWindow.mxml: Login window component to provide FMS service information.
• Participant.as: Participant properties, including incoming NetStream object and corresponding Video display object.
• ParticipantListRenderer.mxml: Rendition of each participant in the main window user list.
• ParticipantEvent.as: Notification event when a participant joins or leaves the meeting.
• MessageEvent.as: Notification of incoming text messages.
• Settings.as: Application configuration properties (such as selected devices).
• Logger.as: Miscellaneous logging component.

 

*source : http://www.adobe.com/devnet/adobe-media-server/articles/real-time-collaboration.html

*참고가 되는 글 :  Adobe Labs - http://labs.adobe.com/technologies/cirrus/

                         포풍초보님의 글 (서버없는 통신 Cirrus) - http://cafe.naver.com/shiftouch/464052