Polycom ReadiSeries

[Entropy3XD]

I have been asked check out the Polycom ReadiSeries. Anyone out there have any experience or comments? Thanks in advance.

[Entropy3XD]

OK…..I checked out the press release, which is here: http://www.conferencingnews.com/news/6504

Then I went to Polycom’s site and downloaded all of the datasheets on the ReadiSeries line, which are here:

http://www.polycom.com/products_services/1,1443,pw-8092-10292-10293,00.html





I must say, this seems like a very promising line and has the possibility of making me a Polycom fan in the world of MCUs. I will admit I have never been a fan of the MGC. Not because it is a bad bridge (I highly regard it as rock solid performer), but because I found it difficult to setup and manage. I have touched only a few MGCs, so I do not have as much experience with the product as many here. This is from a first look point of view. Polycom does have management suites to make administration easier, as do many manufacturers, but then it adds additional equipment with additional points of failure. The ReadiSeries looks as if it may be my answer to a self contained unit with most (I’ve given up on everything) of the features I need and an easy to use interface (they say & I hope). At first glance, I thought it was going to be IP only, so I was excited to see support for ISDN and serial.

Unfortunately, the datasheets do not give any specific information, other than the standard protocols and features I would expect from any manufacturer. Abilities of the MCU? Resources and capacity of each of the components? What are the differences in architecture between the ReadiConvene and the MGC?


If there is anyone out there who can give us additional information (without breaking any rules of course), it would be greatly appreciated. http://www.vtctalk.com/images/smilies/classic.gif

[trapehzoid]

what makes you think this new product will make the mgc any easier to manage?

These are simply bundles. the gain is going to be for the sales force to be able to bundle and sell things together without having to think as hard. Plus, it will give the low end customers a pc platform to run on without relying on procuring seperate servers. However, in that same turn, the high end customers will snuff it because its not standard pc hardware they can use to their own specs and policies.

I'm starting to think polycom R&D has a product 'quota' to release each year.. but no one cares what they release as long as its something 'new' :(

To your questions, I see no differences in any of these products compared to previous products except maybe they've stopped crippling readimanager to sub-100 system deployments.

[Entropy3XD]

what makes you think this new product will make the mgc any easier to manage?
With the limited information I have at the moment, I am not thinking anything. The datasheets emphasize ease of management and that is all I have to go by. This is why I started the thread, to get more information.

[Entropy3XD]

These are simply bundles. the gain is going to be for the sales force to be able to bundle and sell things together without having to think as hard. Plus, it will give the low end customers a pc platform to run on without relying on procuring seperate servers. However, in that same turn, the high end customers will snuff it because its not standard pc hardware they can use to their own specs and policies.

I'm starting to think polycom R&D has a product 'quota' to release each year.. but no one cares what they release as long as its something 'new' :(

To your questions, I see no differences in any of these products compared to previous products except maybe they've stopped crippling readimanager to sub-100 system deployments.
So it's basically just an MGC?

[ChuckF]

From what I have found out, the ReadiConvene is a remolded MGC chassis. It is basically an MGC, but with these slight changes. The controller module is half the size. And they have included another slot for a server blade. The server blade, dubbed the IAM - Integrated Application Module, runs the ReadiManager apps - bits and pieces of PCS, GMS, WebCommander, etc with one interface.

The MGC+ chassis only handles the newer "+" blades. Again, nothing really new except in a newer form factor.

IAM blade not scheduled to be released until Q3.

[Entropy3XD]

Cool.....Thanks Chuck.

[Glen Sykes]

The only thing of interest to me here is whether the new box has the same backplane as the old MGC or if it's a new development. As those of you in the know are already aware, the MGC runs a TDM backplane, giving some advantages and disadvantages. The biggest disadvantage of the old MGC going forward was the bandwidth limitation of the backplane, and given Polycoms now stated intention to run HD (complete with disclaimer ;)) will mean that the MGC would soon run out of bandwidth when running high capacities.

The advantage of TDM is that it's synchronous, meaning that all blades can share the same clock source. This allows for clever stuff like using multiple ISDN cards on a single number range for dialling in. Spanning multiple cards / devices with IP as the backplane isn't possible due to the lack of sychronicity between the devices. In practice, using IP as the backplane can be quite wasteful of B-channels is certain circumstances. An important factor when you are a service provider making revenue from those circuits.

If the ReadiConvene does have an improved TDM backplane, that can only be a good thing in my view.

I agree with Trapezhoid on this, it's probably just a bundle, a rebranded MGC to stimulate interest. I Hope it's more though.

[ChuckF]

I would have to agree with trapehzoid. No changes. And I would add that there probably isn't even backplane changes. Since the chassis accepts the new '+' blades, then it probably has the same bp. If you'll notice (if you have ever had to replace an MGC blade), the blue faceplates to the MGC cards can be removed. This means that Polycom can swap them with the ReadiConvene silver face plates without having to manufacture new cards. They have already spent enough recent engineering on developing the + cards, I would only speculate that they are not manufacturing new cards, nor a new backplane. Just different form factor. Again, this is all speculation on my part.

I would also agree with Trap in ref to Polycom R&D having a quota. But this is obvious since every public company is pressured to develop new products - no matter what. This theoretically helps the stock.

[Entropy3XD]

Great....Thanks for the clarification everyone. I am not as familiar with the Polycom MCU line, so I really appreciate it.

[Glen Sykes]

I'm hoping to verify the changes with Polycom but as usual all the engineers in the UK are out of the office at the shindig in San Francisco!

Support for only the + cards doesn't rule out a backplane upgrade, it may well be that the + cards were designed with this change in mind, whereas the older cards cannot support it.

I live in hope :)

[Skylark]

Looks to me from the whitepapers that they have put a PC in there somwhere do be the dadabase and webservice, so what I like to know is are they basing there managment on redymanager or webcommander?

[ChuckF]

Let me answer your question and correct my earlier reply. The server blade, dubbed the IAM - Integrated Application Module, will run just the ReadiManager application (not WebCommander). ReadiManager is basically a "partial" version of Polycom Conference Suite - PCS. It will not include the full Network Management portion of PCS, only the Scheduling module (so no need for WebCommander). In addition to PCS, ReadiManager also includes GMS. Having not seen the interface yet, I am not sure to what extent of GMS is supplied - full or partial functionality.

[trapehzoid]

This allows for clever stuff like using multiple ISDN cards on a single number range for dialling in.

Who told you this? Using a single number for dial in has about zero to do with sychronization or interfaces. It purely has to do with identifying incoming calls.. both 'new' calls and bonding additional channels. And then knowing what to do with a site once its accepted (where to route it.. to a conference.. to a IVR.. etc).

And its perfectly reasonable to have ISDN interfaces across multiple seperate cards using an IP 'backplane' without issue. Where a TDM would help would be in clock DISTRIBUTION.. which is relevant in private 'dry' circuits where the MCU is the hub and real clock distribution point (really old methodology) or in certain serial network setups (depending on if the MCU is meant to be the DCE or not).

None of that is relevant when using PRIs from a telco. In fact, a system with an IP 'backplane' could actually be MORE tolerant to PRI interfaces with more clock shift between them as they do NOT require sychronization between network cards and the data flowing between the cards does not have to be sychronous

[trapehzoid]

So it's basically just an MGC?

MGC with a PC server option.. yes.

[Glen Sykes]

Who told you this? Using a single number for dial in has about zero to do with sychronization or interfaces. It purely has to do with identifying incoming calls.. both 'new' calls and bonding additional channels. And then knowing what to do with a site once its accepted (where to route it.. to a conference.. to a IVR.. etc).

And its perfectly reasonable to have ISDN interfaces across multiple seperate cards using an IP 'backplane' without issue. Where a TDM would help would be in clock DISTRIBUTION.. which is relevant in private 'dry' circuits where the MCU is the hub and real clock distribution point (really old methodology) or in certain serial network setups (depending on if the MCU is meant to be the DCE or not).

None of that is relevant when using PRIs from a telco. In fact, a system with an IP 'backplane' could actually be MORE tolerant to PRI interfaces with more clock shift between them as they do NOT require sychronization between network cards and the data flowing between the cards does not have to be sychronous

I said single number RANGE, and I think you've misunderstood me. I've yet to seen any implementation where IP is the backplane where an inbound call spans 2 seperate devices, in order to do this, you need a single clock for both devices. Take for example an inbound 6 channel bonded call, spanning 2 gateways. Frame alignment would be acheived on each gateway, but relative to each other, there would be the potential for losses. Even if both gateways took their clock from the ISDN network, there is still scope for slippage. The devices need a common clock source in order for this to work. This is why you can't configure a Radvision GW with a single number range that spans multiple GW's, even in the ViaIP400 chassis.

Think about 2 streams of video hitting the IP backplane from 2 GW's and clock shift is occurring. How does H.323 know to reassemble the packets in order when the GW timestamps on the packets are not synched? Packets would arrive in no meaningful order at all.

It's about the only advantage a TDM backplane gives you, but it's an advantage nevertheless.

[trapehzoid]

I said single number RANGE, and I think you've misunderstood me. I've yet to seen any implementation where IP is the backplane where an inbound call spans 2 seperate devices, in order to do this, you need a single clock for both devices. Take for example an inbound 6 channel bonded call, spanning 2 gateways. Frame alignment would be acheived on each gateway, but relative to each other, there would be the potential for losses.


The real 'issue' here is you have two seperate gateways (regardless of how they are interconnected) handling the same call. Don't confuse network INTERFACES with seperate gateways. The reason you don't see this is because you would need to achieve bonding sychronization across seperate devices.. something NO one has done to my knowledge. In your example, no.. both gateways would not get 'frame alignment'.. because they could not establish the bonding alignment indepedendantly without all the channels. You're confusing things so much further down the line with the real front-end issue.

The case where this would be 'useful' is when you have multiple gateways and you want 100% usage of all channels. In those cases, if you are really concerned about channel usage (which shouldn't be a biggie unless you are using high bandwidth calls) get a single gateway with lots of network INTERFACES, such as the MGC where you can assign lots of PRI interfaces to the same service.

Regardless of backplane, if you assigned those same PRIs to two different network services, the MGC would fail the same way as other designs if you had the same call try to span network services.

You need all the channels of a bonded call to establish the larger frame alignment that allows you to serialize the stream into a single one. I'd have to break out the ISO docs, but I'm about 95% sure it would be impossible to establish the (I can't remember the term.. MF?) without all the channels. Maybe tonight if bored I'll look into it.

For your 'advantage' scenario to work.. the second gateway would not act like a gateway at all.. just an ISDN terminal that would pass the channels over to the other guy. which would introduce new latencies not included in the bonding 'math'.. so the system would have to account for that in some predictable way. But the gain doesn't seem worth the effort IMO.