Tandberg Edge 85/75MXP + Bandwidth

[Travis Geseron]

Good day,

I have noticed that our Edge85 MXP is using more bandwidth than should be available.... here is the output from the unit's web GUI:

Total bandwidth 1552 kbps of 1152 kbps

This is in a multi-site call with 4 locations (including itself). I am also being bombarded with emails from the TMS server regarding call downspeeding (endpoints in this particular call).

Has anyone experienced this?

Thanks,

Travis

Edit: Should have mentioned, the 85 and 2 of the 75's are running F6.0, the other 75 is running 6.3

[Sean Lessman]

Total bandwidth 1552 kbps of 1152 kbps

This is in a multi-site call...

The 1152kbps limit is for point to point calls. The product is able to go higher for multipoint calls to ensure each individual site can connect at a reasonable speed.

Sean

[Travis Geseron]

The 1152kbps limit is for point to point calls. The product is able to go higher for multipoint calls to ensure each individual site can connect at a reasonable speed.

Sean

You sir have just shaken my entire world :)

I am not a VC guru by any means, and take a lot of what people have told me to heart. I was always told that the 1152 was the max total for any call, and that the best a multi-site call could connect at was 1152/sites.

Obviously you are correct here, or else I would not see the higher numbers on the Tandbergs. I am concerned as I informed the users that upgrading the 85's to 95's would increase the BW for multi-site calls to 2Mbps, but that would be the point-to-point number correct?

Also, any idea why the downspeeding emails would keep getting sent out? You would think the devices would lower the speed to correct any problems, and then be ok. Bad network conditions during the call perhaps?

Thanks a lot,

Travis

Edit: I should also mention that the host site for this call only has a aDSL connection with 1Mbps upload. So why the calls would connect at such a high rate is also beyond me.

[robertk]

Edit: I should also mention that the host site for this call only has a aDSL connection with 1Mbps upload. So why the calls would connect at such a high rate is also beyond me.

Your endpoint is not aware of the 1Mbps limit, so if you are trying to call at 2Mbps you will get a lot of problem.

I would say using a 1Mbps DSL connection (I hope it atleast is Symmetrical so you have 1Mbps Download AND Upload?! ) will get you in to problem when calling at say default 768Kbps.

Downspeeding will be one of the way a system handle problems like this.

Maybe you could try to connect at a LOWER bandwidth to test. 384Kbps as an example!

Lots of people see bad video caused by network congestion and think it will be solved by calling at a higher bandwidth from the system, instead of trying a call using a bandwidth that the network can actually handle.

I would say that a call at 384Kbps without errors will look better then a call at 1Mbps with 10% packet loss.

//Robert

[Travis Geseron]

Your endpoint is not aware of the 1Mbps limit, so if you are trying to call at 2Mbps you will get a lot of problem.

I would say using a 1Mbps DSL connection (I hope it atleast is Symmetrical so you have 1Mbps Download AND Upload?! ) will get you in to problem when calling at say default 768Kbps.

Downspeeding will be one of the way a system handle problems like this.

Maybe you could try to connect at a LOWER bandwidth to test. 384Kbps as an example!

Lots of people see bad video caused by network congestion and think it will be solved by calling at a higher bandwidth from the system, instead of trying a call using a bandwidth that the network can actually handle.

I would say that a call at 384Kbps without errors will look better then a call at 1Mbps with 10% packet loss.

//Robert

I agree with everything that you say, but isn't that what the "auto" setting is for. If I set the calls to only connect at 384, which is what it should be for the above call, when they call in a point-to-point it will still only connect at 384 (instead of say 768).

Right now all calls are set to "auto" for the connect at option.

-Travis

[Sean Lessman]

I was always told that the 1152 was the max total for any call, and that the best a multi-site call could connect at was 1152/sites.

This may indeed be the case, I checked into some internal specs and it looks like 1152 is the limit for both point to point and multisite :)
The 95 allows you to go above the point to point for multisite.

Any chance you can send me your serial number and optionkey (telnet to the codec and issue the command optionkey). Would like to see if you somehow got the wrong key or if this may be a bug.

Also, while in telnet, issue the command ati6 and then ati7 and send that to me too.

Thanks,

Sean

[robertk]

Also, while in telnet, issue the command ati6 and then ati7 and send that to me too.



Ooo I love it!! AT commands... pitty the "modern" TANDBERGs don't support more of the AT command set, as they used to :)

I loved to dial from my tandberg using: "atd 1234 5678 " or answer wit "ata". How cool wasn't that !!??

I remember even using the modem and contacts function in some old outlook to dial customers on video :)

//Robert

[robertk]

I agree with everything that you say, but isn't that what the "auto" setting is for. If I set the calls to only connect at 384, which is what it should be for the above call, when they call in a point-to-point it will still only connect at 384 (instead of say 768).

Right now all calls are set to "auto" for the connect at option.

-Travis

I belive AUTO is default hardcoded to 384K for a ISDN calls and 768K for IP calls. This can be changed if you wish, to have a custom default call-setting while dialing.

//Robert

[Sean Lessman]

Looks like we have a few things going on here:

1. If you use Auto/Max, the bandwidths the units connect at are not consistent (I got 2 systems connected at 576 and 1 at 384) -- this is not correct. They should all be at 384kbps. The Web GUI reported 1536 of 1152 -- this is just a reporting error.

2. If you dial 384kbps each manually (forced) everything connects fine.

3. The optionkey you gave me doesn't match the one I calculated for your system. Not sure what is going on there, but it doesn't seem to be the source of the issue as I can duplicate your problem here.

We are going to do a few more tests and report any issues we see to R&D.

In the meantime, if you set your default calls to 384kbps (as Robert instructed), it should work fine for you and report the correct bandwidths in the Web GUI.

Sean

[Travis Geseron]

Thanks for all the help guys, it is much appreciated.

Sean, about the option key, should I provide the serial/key for each of our systems to yourself or Tandberg directly to see if maybe our reseller(s) are doing something wrong?

Also, a special thanks for the testing of this to let me know that at least I am not insane!

-Travis

[Sean Lessman]

about the option key, should I provide the serial/key for each of our systems to yourself or Tandberg directly to see if maybe our reseller(s) are doing something wrong?

The keys are unique to each serial number and feature, so there is really nothing the partner could have done wrong. I also do not think it is related to the issues you are seeing.

Sean