Expand my Community achievements bar.

Dive into Adobe Summit 2024! Explore curated list of AEM sessions & labs, register, connect with experts, ask questions, engage, and share insights. Don't miss the excitement.

Preventing fallback to relay mode

Avatar

Level 2

Hi-

Is there a way to prevent LCCS (I guess the SDK) from falling back to relaying video traffic through the Adobe servers if rtmfp fails?

Thanks

David

7 Replies

Avatar

Former Community Member

Hi,

You need to have rtmfp connection to do P2P of audio/video streams. So, currently our SDK falls back on server on failing to establish rtmfp connection.

Thanks

Hironmay Basu

Avatar

Level 2

Hi Hironmay-

Thanks for your reply.

That's a real shame as I need to be certain of my costs. I want to be sure all connections are P2P so I don't incur the costs of relaying A/V traffic. I'm happy to tell my users to configure their firewalls so P2P works.

Regards-

David

Avatar

Former Community Member

Hi David,

We'll be adding more controls in the future that include (1) defining the threshold (# connections) at which we switch to hub and spoke, and (2) deny fall back to hub and spoke.

Thanks,
Fang

Avatar

Level 2

Hi-

Regarding these extra controls: did they make it in yet?

Many thanks

David

Avatar

Former Community Member

Hi David,

You can change the streaming threshold with

StreamManager.maxP2PStreamPublish = . This will

prevent users from going hub and spoke.

If RTMFP fails, there's no choice but to go hub and spoke, unless you kick

out the user in question. You can always check userDescriptor.isRTMFP or

userDescriptor.isPeer on ConnectSession.synchronizationChange to determine

this.

nigel

Avatar

Level 2

Hi Nigel-

Let me check I understand clearly:

- RTMFP can do peer-to-peer or hub-and-spoke

- requireRTMFP=true just says don't use RTMPS

- StreamManager.maxP2PStreamPublish controls after how many P2P connections the client switches to using hub-and-spoke. So setting this higher prevents the switch (although other things may cause the switch). However, setting it too high may mean problems (uplink saturation, Flash player internals can't handle it)

- userDescriptor.isPeer on ConnectSession.synchronizationChange can be caught and if false, the app can disconnect. This is the only way to prevent an app from using hub-and-spoke

Did I get all these things right?

Thanks

David

Avatar

Level 2

also...

- I can check streamManager.isP2P instead of checking it on every user?

- If the user is an OWNER, I can ask for multicast (supports many streams but may increase latency for conversations)?

Thanks