LCCS recording (RTMFP vs RTMP/S protocols)

Question

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+Multicastin g 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.

Answer 1

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