LCCS recording (RTMFP vs RTMP/S protocols)

[DrAlexGor]

Hey everyone,

So I've read through all of http://learn.adobe.com/wiki/display/lccs/LiveCycle+Collaboration+Service and been reading through the forums (even in the FMS side which maybe relevant http://forums.adobe.com/message/3345179#3345179 and http://forums.adobe.com/thread/736733 ).  Since LCCS recording is in beta it lacks the right docs for now.

Could you guys validate/invalidate my assumptions about LCCS recording:
Note: we are requiring Flash 10.0 and link against LCCS swc (flash 10.0) currently

1) Setting <rtc:AdobeHSAuthenticator id="auth" userName="{ourUserName}" password="{ourPassword}" protocol="RTMFP" /> will do the following:
  a) cause a P2P multicasting ( which in turn uses UDP and no communication to LCCS service ) between client SWFs, which means no A/V steam recording.

2) Setting <rtc:AdobeHSAuthenticator id="auth" userName="{ourUserName}" password="{ourPassword}" protocol="RTMPS" /> will do the following:
   a) cause a TCP through LCCS server which will record the A/V streams just fine.

3) What would I do if we wanted to take advantage of P2P multicasting while recording the LCCS session?  Would we have to do something like: http://forums.adobe.com/message/3345179#3345179 ?

4) According to this: http://learn.adobe.com/wiki/display/lccs/09+Peer-to-Peer+Data+Messaging+and+AV+Multicasting we could do P2P multicasting with Flash 10.1
a) Maybe I'm completely wrong in #1 and #2 and by requiring Flash10.1 for our app, I get recording working while using RTMFP protocol ?

Thanks,
Alex G.

[Former Community Member · Accepted solution]

Hi Alex,

Correct - for right now, when you're doing P2P streaming over RTMFP,

recording doesn't work. In order to work around this, we've recommended

either disabling RTMFP or setting StreamManager.maxP2PStreamPublish to 0. In

the latter case, you'd still be using RTMFP and UDP, and so get most of the

advantages.

Answering each of your questions :

1) Partially correct - RTMFP is required for P2P streaming, but not all

RTMFP streaming is P2P. For example, once there are more than 3 recipients,

we automatically switch to hub-and-spoke, since P2P becomes laborious for

the publisher. You can control this threshold using the

StreamManager.maxP2PStreamPublish.

2) Correct. This is one temporary workaround - I'd prefer the 2nd

workaround, using StreamManager.maxP2PStreamPublish = 0, which still allows

the benefits of RTMFP without using P2P. In the next release, even if you're

using RTMFP, once you turn recording on, it will similarly enforce that

everyone stream over hub-and-spoke (without changing from RTMFP).

3) For now, there won't be any way to do P2P streaming with recording

enabled. In the future (likely quite later), we might have time to enable

this, but it's pretty difficult (maybe not even possible), and it's not high

in priority.

4) It's important to separate these issues - RTMFP doesn't require P2P

streaming. In fact, most of the benefits of RTMFP (primarily the fact that

it's UDP-based) work over hub and spoke. What we've seen is that Multicast

P2P (enabled in 10.1, and as opposed to direct P2P) is often not a great

choice for conversations, since multicast introduces more latency than

simply using hub-and-spoke.

hope this helps,

nigel

[DrAlexGor]

Thanks Nigel, that's exactly what I needed to know.