Connection Theory

[uncle pauly]

Howdy,

I was wondering if anybody out there has heard of this situation.
I was once told by a network engineer that the PRC (Peoples Republic of China) has the ability to stop/limit the flow of bandwidth coming and going from their networks at any time. For example, a VTC site with 384K capability can only be connected at 128K at certain times of the day if the end site is out of the PRC. No matter what you try, you can’t connect higher than 128K, but if at the same time the site dials out to another VTC site in the PRC, they connect at 384K with no problems. Any thoughts?
Thanks

[Sean Lessman]

Howdy,

I was wondering if anybody out there has heard of this situation.
I was once told by a network engineer that the PRC (Peoples Republic of China) has the ability to stop/limit the flow of bandwidth coming and going from their networks at any time. For example, a VTC site with 384K capability can only be connected at 128K at certain times of the day if the end site is out of the PRC. No matter what you try, you can’t connect higher than 128K, but if at the same time the site dials out to another VTC site in the PRC, they connect at 384K with no problems. Any thoughts?
Thanks

Sounds fishy.

They could certainly have the ability to restrict bandwidth which means you would get severe packet loss when dialing higher speeds. But whether or not they can alter ARQ and ACF gatekeeper messages to make endpoints dial lower speeds -- doubt it. I mean it could be done, but thats going through a lot of trouble just to alter a video call...and not sure if that 'hack' would scale nicely (after all they have 1 Billion+ people).

Sean

[smatthews]

We ran into the same thing. We couldn't dial out to China and the highest they could dial to the US was 128k. I'm looking to try ip but I need to find someone with and IP address I can test to.

[robertk]

Sounds more like they use a system that use h.221 and don't support BONDING.

Maybe they use older Sony systems?

//Robert

[Sean Lessman]

Sounds more like they use a system that use h.221 and don't support BONDING.

Maybe they use older Sony systems?

//Robert

Haha...I haven't thought about ISDN in such a long time, you have a great point, it could be ISDN :)

In the case of ISDN, if you have congestion on an ISDN trunk you may actually not get all of the channels you request thereby dropping down to lower bandwidth. Absolutely possible.

Sean

[Sean Lessman]

Maybe they use older Sony systems?

//Robert

The really old Sony's used to support 6xh221 for 384kbps calls...and you had to dial all 6 numbers individually :ermm:

Sean

[robertk]

The really old Sony's used to support 6xh221 for 384kbps calls...and you had to dial all 6 numbers individually :ermm:

Sean

Yes, but I belive Picturetel was brave enough to drop >2 channel support for H.221 in favour of BONDING... and the rest of the industry (except sony) followeed the leader at that time :^)

Even today when the IMUX functionality is incorporated in a codecs SW and the HW limitations that was the cause to drop support for >2 channels of H.221 is long gone, the systems still only support 2 channels of H.221 calling :^)

//Robert

[Sean Lessman]

Yes, but I belive Picturetel was brave enough to drop >2 channel support for H.221 in favour of BONDING... and the rest of the industry (except sony) followeed the leader at that time :^)

Not sure who was the first as that was just slightly before my time. But I do remember they were using Ascend Imuxes to do the Bonding. But I do remember when everyone else still had mini-fridge sized codecs, TANDBERG introduced a 1 RU codec in 1995 that had the first built in software codec that began the demise of the Ascend imux in the VTC industry.

Even today when the IMUX functionality is incorporated in a codecs SW and the HW limitations that was the cause to drop support for >2 channels of H.221 is long gone, the systems still only support 2 channels of H.221 calling :^)

You can still quite easily support 6xh221 aggregation in the codec if you wanted to through software - as long as you don't need 6 V.35 ports for CSU/DSUs :). We did at some point in the past, but I am sure its gone in the current codecs due to lack of use.

H.221 aggregation had the ability to lose and gain channels on the fly, more resilient than Bonding Mode 1. We improved on Bonding Mode 1 by developing downspeeding which helps deal with Bonding Mode 1's lack of flexibility to ISDN errors and delays.

Sean

[robertk]

Not sure who was the first as that was just slightly before my time. But I do remember they were using Ascend Imuxes to do the Bonding. But I do remember when everyone else still had mini-fridge sized codecs, TANDBERG introduced a 1 RU codec in 1995 that had the first built in software codec that began the demise of the Ascend imux in the VTC industry.


But it wasn't until much later the builtin IMUX was activated :) The first years TANDBERG used the ASCEND IMUX connected to the codec :)

And even later TANDBERG had the Ascend IMUX for countrys where the ISDN protocol was not 100%. Maybe still?



You can still quite easily support 6xh221 aggregation in the codec if you wanted to through software - as long as you don't need 6 V.35 ports for CSU/DSUs :). We did at some point in the past, but I am sure its gone in the current codecs due to lack of use.



The H.221 aggregation is missed by no one :)


H.221 aggregation had the ability to lose and gain channels on the fly, more resilient than Bonding Mode 1. We improved on Bonding Mode 1 by developing downspeeding which helps deal with Bonding Mode 1's lack of flexibility to ISDN errors and delays.

Sean

The Ascend IMUX have it's AIM protocol wich is still far greather then any version of BONDING. You can not just downspeed, but also up-speed + the inband communication channel, so you could reconfigure the remote end easily :)

But I agree fully with you, TANDBERG was the first one to have working downspeed functions in Bonding.

//Robert

[Sean Lessman]

But it wasn't until much later the builtin IMUX was activated :) The first years TANDBERG used the ASCEND IMUX connected to the codec :)

Actually the MasterVision came out in the fall of 1995 (Oct) and the SoftMux was introduced through software in the spring of 1996...so it was more like 9 months, not years before we unhooked the Ascend.

And even later TANDBERG had the Ascend IMUX for countrys where the ISDN protocol was not 100%. Maybe still?

Not doubting this, but I know that I did some work in Central America in the mid 1990's and the Ascend's didn't work in a few instances where the TANDBERG SoftMux did :-)

The H.221 aggregation is missed by no one :)

Dunno, it was quite flexible and didn't require an IMUX since the aggregation was done at the codec level.

The Ascend IMUX have it's AIM protocol wich is still far greather then any version of BONDING.

AIM = Ascend Inverse Multiplexing = proprietary, so both sides had to have Ascends. Also, nobody used it. In those days, everyone had custom made user interfaces with AMX or Crestron because you needed to control a bunch of gear (IMUX, echo canceller, codec etc). The integrators typically hard coded Bonding Mode 1 as the calling protocol of choice.

You can not just downspeed, but also up-speed + the inband communication channel, so you could reconfigure the remote end easily :)

AIM also took extra bandwidth for the signaling to do the up and downspeeding.

But I agree fully with you, TANDBERG was the first one to have working downspeed functions in Bonding.

Of course we were first, we invented downspeeding on ISDN for Bonding and gave it freely to the industry ;)

Sean

[uncle pauly]

Good post's everyone, thanks for the information. The site is ISDN and I am dialing bonding, next time I will try 6x64, see if that works.

[robertk]

Good post's everyone, thanks for the information. The site is ISDN and I am dialing bonding, next time I will try 6x64, see if that works.

It can also be that the site you are dialing has not configured it's ISDN numbers into the Codec/IMUX. For example a TANDBERG unit will try to dial the same number as was dialed 6 times.... this will also sometimes also get you only 128k.

What type of system are you dialing from? And do you know what kind of system that is answering?

Try to find if you can monitor the isdn-numbers dialed, usally it's quite easy to see from your system. The behaviour there can give us a hint of what is going wrong.

//Robert

[uncle pauly]

It can also be that the site you are dialing has not configured it's ISDN numbers into the Codec/IMUX. For example a TANDBERG unit will try to dial the same number as was dialed 6 times.... this will also sometimes also get you only 128k.

What type of system are you dialing from? And do you know what kind of system that is answering?

Try to find if you can monitor the isdn-numbers dialed, usally it's quite easy to see from your system. The behaviour there can give us a hint of what is going wrong.

//Robert

Hi Robert,
Next time I have a call with these sites, I will pay special attention to the ISDN numbers that come up on the bridge and also try to find out what type of system they are using. I'm dialing from a Polycom MGC 100 Bridge. Thanks for the advice.

[Sean Lessman]

Try to find if you can monitor the isdn-numbers dialed, usally it's quite easy to see from your system. The behaviour there can give us a hint of what is going wrong.

If possible it would also help to take an ISDN trace from the endpoint. It will tell you what is going on when you don't get all channels.

Sean

[montgomeryed]

I know this is the ISDN section but he must be talking IP network? If it is ISDN it is a bonding issue as mentioned not someone purposely throttleing the bandwidth. It they do do that someone on ISDN call setup wouldn't know and the call would suck...

[uncle pauly]

I've asked the client to test with me regarding this but they seem to be fine with just a 128K connection. Next time we bridge one of their calls I will do quick tests during pre call with the suggestions on this board, I'll keep you posted. BTW, yeah it's ISDN. :)

[haneyr]

As a matter of fact the Telco can indeed limit ISDN line access during times of high peak activity. Even if you pay for 6 BRI lines they can shut down 4 of them if they feel the need to free up bandwidth for other clients. Remember we are talking about a country who has not fully updated their communications infrastructure and is not civilian customer oriented. It happens even in countries that are more . . . (open?) also.

So you will probably just have to accept what you can get and just suck it up (the noodles that is).

[uncle pauly]

As a matter of fact the Telco can indeed limit ISDN line access during times of high peak activity. Even if you pay for 6 BRI lines they can shut down 4 of them if they feel the need to free up bandwidth for other clients. Remember we are talking about a country who has not fully updated their communications infrastructure and is not civilian customer oriented. It happens even in countries that are more . . . (open?) also.

So you will probably just have to accept what you can get and just suck it up (the noodles that is).

:cool: This backs up my original post on this thread. Good info Haneyr.

[uncle pauly]

Good post's everyone, thanks for the information. The site is ISDN and I am dialing bonding, next time I will try 6x64, see if that works.

I just ran another call with this site, and tried 6x64, all channels came up on the bridge and it would partially negotiate. Had to drop it to 2x64 to finally get a connection and even that took a few tries. I give up. I'll just chalk it up to poor system maintenance. :knockedou