Chronic down speeding

[RTFS]

I've searched but I don't see anything that has helped so I figured I'd start a thread.

I have an Aethra Gateway (radvision) directly connected to an MGC50 ISDN port. I'm also using a Cisco GK. I initiate a 384 call from the ip side through the gateway and it brings up all 6 channels. Seconds before capabilities transfer, a downspeed occurs and 2 channels drop. I also have a Tandberg gw set up in parallel to a different isdn port on the mgc and it does the same thing but it only drops 1 channel.

I've tried reconfiguring the protocols on the ISDN side every which way but it doesn't get any better.

A debug on the gk shows the gw is sending a revised BRQ for the lower speed but the console output of the gw isn't detailed enough to reveal why.

Any thoughts?

[RTFS]

anyone ever seen this before? I tried setting the conferences to 261 and disabling transcoding on the gw but it didn't help.

Any guidance would be appreciated.

Thanks!

[cfaasen]

Have you tried bypassing the gateway or gatekeeper?

[RTFS]

I have two gateways from different manufacturers that both drop channels. Since a gateway is (in effect) a h320 to h323 converter how can it be bypassed? The dissimilar protocols won't work together.

I'm all ears (eyes) if you know of a way.

[RTFS]

Polycom tells me that the MGC will not supply ISDN clock so I am under the assumption that the gateway will if it's set for NT master.
Am I incorrect?

[jo3baltes]

Hi,

Yes, if the GW is directly connected to the MGC, it can provide clocking. Go the PRI port tab, physical interface, and set Network Access to NT mode and clock source master.

To increase the debug detail, go to the Advanced button, Commands, and set the NotifyLevel to "6".

Hope that helps
Joe

[cfaasen]

Can your bridge do a H320 call (bypassing the gateway) to see if it is on the NET card, Mux card or your ISDN configuration. This will assume that you have clocking set on your NET card. If you can do this then I would look at your gateway configuration on your MGC 50. I am wondering why you are having problems with the 3 gateways(same issue). Does your MGC have a gateway built on board.

[RTFS]

Hi,

Yes, if the GW is directly connected to the MGC, it can provide clocking. Go the PRI port tab, physical interface, and set Network Access to NT mode and clock source master.

To increase the debug detail, go to the Advanced button, Commands, and set the NotifyLevel to "6".

Hope that helps
Joe

Thanks for the response. That confirms what I suspected and I have it set exactly the way you suggest. Level 6 debug does indeed give out a plethora of information. I can see where the channels disconnect but there is nothing prior to indicate a problem. APP 323 is reporting a Q931 release cause of 16 which is Normal call disconnect so doesn't seem to be telling me much. I'm still pulling out what's left of my hair.

[RTFS]

Can your bridge do a H320 call (bypassing the gateway) to see if it is on the NET card, Mux card or your ISDN configuration. This will assume that you have clocking set on your NET card. If you can do this then I would look at your gateway configuration on your MGC 50. I am wondering why you are having problems with the 3 gateways(same issue). Does your MGC have a gateway built on board.

I appreciate the response but the gateways I'm using are external to the MGC. We are not currently using the gateway feature built into the MGC.

[jo3baltes]

Ahh great. Who needs hair anyway?

You may need open a case with Aethra (or RVSN) support for additional help.

As a suggestion, cable the rolled T1 between the AE/RV GW and the TBG unit, bypassing the MGC - thinking that the MGC is common to both failure scenarios. It would be interesting to see how the call setup works in that scenario and may lead to a case open with PLCM instead of AE/RV...

Joe

[RTFS]

A level 6 log from the gateway shows the following error for channels 1 & 2 of the call:

|LOGGER|MSG|INFO|(w2ltask) LG: <<Bonding>> Timer_TCfa[ch=1]=1501 Expired!!! stat=102

Anybody have any idea what a TCfa timer is? It seems to work fine on all the other bonded channels of the call, just not 1 & 2. If so, I presume it is waiting for something from the MGC?

[jo3baltes]

TCFa timer is part of the bonding process, where the caller side is attempting to establish Frame Alignment on the channels in the bonding.

[cfaasen]

Where is the ISDN being bonded/MUX?

[RTFS]

TCFa timer is part of the bonding process, where the caller side is attempting to establish Frame Alignment on the channels in the bonding.

That narrows things down a bit. I have an analyzer on the ckt and it is showing zero slips - timing or frame.

Any idea how I might adjust that timer? Maybe the MGC is just a little slow...

[RTFS]

Where is the ISDN being bonded/MUX?

I suppose it's either in the aethra p20 gateway or the MGC ISDN/Mux card or both.

[jo3baltes]

In the P20 GW, go to Setting >> Advanced >> Commands, and enter the command BondingDelay, then click "send" with no parameter. It will return the configured delay in milliseconds. Enter the new value in the parameter field and hit send again.

I suspect that this applies to the delay between attempting to bring up channels in the bonding and you may discover that you need to delay this individual T Timer.

Anyway, worth a shot. If tuning this isn't helping, you'll *need* to contact support formally, either AE or RV, depending on how that's supported. Naturally contacting PLCM support couldn't hurt either, but some more of your hair may be required.

[RTFS]

In the interest of closure on this thread, PLCM has a fix for this problem in v8 of their MGC software. Works like a champ now.

Thanks for everyone's helpful input!