CM 6-Party Video Conferencing

1. CM 6-Party Video Conferencing Andrew Lang Alex Beck

2. Overview Description CM 6-Party Video Conferencing • Video conferences work just like audio conferences. • Admin configures video bridges for ad-hoc video conferencing • When video users hit the conference button, CM automatically sets up calls to a video bridge to support the conference. • No IDs; no setup; no redial; nothing to remember. • CM conference features like conf-display, far-end mute work as normal • Target market: anyone who uses video.

3. How It Works • Behind the scenes, CM makes calls to the selected video bridge on behalf of each endpoint. • Once these are up, the endpoints are connected to the bridge (“bridge-moved”) • Audio-only endpoints share a single audio-only bridge connection (mixing done by CM media processor). • New legs are added or removed as people join or leave the conference. • CM will not hijack scheduled conferences for this. • Always get the best CM has available • No hidden workarounds

4. Overview Description Capacity • Up to 40 video bridges per CM • Limited only by video call capacity and licensed video bridge capacity. • S8700 supports 1000 simultaneous video calls. • That’s 333 x 3-person ad-hoc calls, if you have enough bridge ports. • S8300 supports 150 simultaneous video calls. • That’s 50 x 3-person ad-hoc calls, • Supports selected SIP and H.323 video bridges • Polycom RMX, MGC (H.323) • Avaya Meeting Exchange/MX (SIP)

5. Solution View – Network Topology Single CM - Multiple RMX / MGC Network Region 1 Network Region 4 Network Region 2 Network Region 3

6. Solution View – Network Topology Single MX - Multiple CMs Network Region 4 Network Region 3 Network Region 2 Network Region 1

7. Call Topology – Merge vs. Cascade What happens when you conference in a new party? • If CM controls the conference, the new party joins the ad-hoc conference – in video as in audio – a merge. • If you conference together two existing ad-hoc conferences, they become one ad-hoc conference – a merge. • If CM does not control one or both conferences, it cannot add new members to it or move them to the other conference. It creates a link line – a cascade. • Examples of “non-controlled” conferences: • Scheduled conference • Multipoint VSX • Conference on another CM.

8. Cascaded Call Scheduled conference + ad-hoc Scheduled Scheduled Ad-hoc Alice Alice Carol Dave Dave Bob Bob Carol Note: scheduled and ad-hoc conferences may be on the same bridge!

9. Bandwidth Management • Video bridge takes on network region of its signaling groups (only one region allowed). • Normal bandwidth restrictions apply • CM will attempt to find the best-connected MCU for a given conference, but will not move around as participants change (exception: audio is a must) • Some otherwise video-capable endpoints may only get audio due to bandwidth limitations • CM will never use a bridge unless at least three video endpoints can connect to it, but may still use one even if not all the video-capable endpoints get video. • (No bridge usage unless three video endpoints)

10. Resource Management • RMX reports resource usage, allowing CM to dynamically adjust to other uses of bridge and internal processing needs • MX also reports resource usage and can therefore be a resource for several CMs at once • MGC does not - CM attempts to track based on its own configuration, but cannot allow for scheduled conferences • MGC must therefore be dedicated to ad-hoc. • MGC is supported, but not recommended - can demo video conferencing to a customer using their current MGC • No other video bridges are supported!

11. Load Balancing • CM has resource information from all of its bridges (either internal tracking or direct reporting) • Where there are choices, CM will choose least-loaded video bridge

12. User Experience • On starting a new conference (A calls B, holds; calls C, hits conference) • Longer break in audio (~ 2 seconds, because of setup time to MCU) • Video comes up quicker than an existing conference. • Call legs to bridge are shuffled • From existing conference (add party to existing conference, or fourth+ party adds video conferencing permission) • Shorter audio break on MCU connection (<500ms) • Video comes up slower. • No shuffling - so no wideband • Play a tone in each case to indicate that the conference has reached the MCU; allows users to anticipate short break in audio. • Startup time much shorter on RMX vs. MGC

13. Who can use 6-party video conferencing? • User has video if CM administrator gives it to them • New COS entry added to control this • Priority users can get special treatment for ad-hoc

14. Who Decides on Usage • If anyone on the call has video conferencing permitted, it happens • If someone with video conferencing permitted joins or starts a call, it becomes video-conferencing-capable Principle of least surprise: • Does not depend on who is conferenced first • Does not depend on who does the conferencing • Continues even if video-permitted user leaves

15. When is video conferencing triggered? • Every time someone joins, CM checks to see if they can now have ad-hoc video conferencing • If the sixth person to join has permissions, we will bridge-move the whole conference • Previously the conference may have been video-conferencing-capable, but there may have been no bridge free – if a new check shows an available bridge, it will be used. • Hold-unhold will also result in a check on video bridge resources • When someone leaves and there are only two video endpoints left, CM will release the bridge and connect directly • Waits 30 seconds in case a new person joins

16. Preservation of audio • If the bridge runs out of resources (e.g. when a scheduled conference starts), it will throw out the ad-hoc users • CM will revert to audio conferencing automatically. • CM insists on everyone getting audio (via bridge or CM resources), even if that means no video. • Will generate denial events when forced to revert • Video conferencing will never result in worse connectivity - e.g. IGAR-connected endpoints will still get audio

17. Video Bridge Admin • Ad-hoc conferencing ports controlled by system-parameters

18. Video Bridge Admin • Max ports – total across all the ad-hoc conferences this bridge hosts (e.g. 18 ports supports 3 6-party conferences) • When you fill in a trunk, more fields appear based on the trunk type • Not possible to mix trunk types. • We use the outgoing trunks to make calls; the incoming trunks allow us to tell when the bridge is in service. • Two-way trunks do both.

19. Video Bridge Admin • Resource info specifies whether far end will provide updates and track port usage • Must be supported by bridge (RMX, MX, not MGC) • Changes fields displayed below it

20. Video Bridge Admin • To create a conference, CM sends a factory number over the trunk, and supplies or requests a conference ID • Factories and IDs only meaningful to bridge • Need not be in dial plan • Need not be unique across bridges. • Must configure enough IDs to support expected conferences

21. Video Bridge Admin (Polycom RMX: H.323) • Factory is an entry queue number on the RMX which dynamically creates a conference • IDs must be configured to allow ad-hoc conference creation on bridge (but CM chooses which to use) • Priority number used when a priority user starts call • Standard number used otherwise

22. Video Bridge Admin (Avaya MX: SIP) • Factory numbers only, conference IDs set by bridge • SIP factory can be letters or digits • Resource Info address must be agreed with bridge

23. Video Bridge Admin – No Resource Info • Turn off “Far End Resource Info” field • CM stops expecting resource updates from far end • Makes simple assumptions about resources – management is not as effective • Doesn’t use factory, just calls direct to conference ID – each must be configured as an open conference (meet-me).

24. Status Screen • When video conferencing not triggered, first place to look. • Is my bridge in service? Is it full? Is it failing? • Find out if resource updates have not been sent.

25. Status Screen Status codes: • out-of-service: no signaling groups in service • in-service: OK • low-resources: bridge reports it is nearly full • call-rejected: bridge has rejected a call • no-resources: bridge has not yet sent resource info • trunks-busy: all trunks to bridge are busied-out.

26. Troubleshooting • Look at the status screen (previous slide) • Check permissions on COS screen • Check the trunks and signaling groups with “status trunk” and “status signaling-group” • Denial events • 2377: Video bridge rejected call leg (check bridge app) • 2386: No suitable MCU available (check setup, bandwidth) • 2389: Not enough trunk members to connect to bridge • 2392: Video bridge dropped call leg (check bridge app) • Others in this range (2377-2392) as well.

27. Troubleshooting • Check that your bridge is working (using bridge-specific management app such as RMX web interface) • Check that your bridge is configured properly (factory numbers, resource subscription, conference IDs etc) • Configure direct dial on the trunk, test it. • If you are not also using your bridge for scheduled conferences, temporarily set up as if you were • For H.323, check signaling group for incoming trunk – must have channel selection trunk configured.

28. Troubleshooting • Expected output from “list trace station” as video conferencing activates list trace station 71224 Page 1 LIST TRACE time data 18:49:56 Ad-hoc video orig trunk-group 51 cid 0x80 18:49:56 seize trunk-group 51 member 2 cid 0x80 18:49:56 Calling Number & Name NO-CPNumber NO-CPName 18:49:56 Calling Number & Name 71224 Lou D’Ambrosio 18:49:56 Ad-hoc video term trunk-group 51 mbr 2 cid 0x80 VOIP data from: 135.27.67.31:2062 18:49:56 Jitter:0 0 0 0 0 0 0 0 0 0: Buff:20 WC:0 Avg:0 18:49:56 Pkloss:0 0 0 0 0 0 0 0 0 0: Oofo:0 WC:0 Avg:0 18:49:57 Alert trunk-group 51 member 2 cid 0x80 18:49:57 active trunk-group 51 member 2 cid 0x80

29. Help • Video Telephony Solution R4.0 Quick Setup • ACM documentation – search for “ad-hoc video”