Re: (ASCEND) 7.0b6 images

[Mike Jackson <mhjack@tscnet.com>]

On Wed, 2 Dec 1998, Mark E. Dunlap wrote:

> Well, I lost this feed for the last few days, but I get the jist that
> other people are also having problems with the 2nd Channel on an MP
> call.  I found that it does not work for any load after 7.0b6.  MPP calls
> from Pipelines work fine, but 3rd part MP TAs do not.
> 
> The problem is that 7.0b6 was far more stable that 6.anything, but the
> last version I could get ahold of is 7.0b7.  Does anyone have 7.0b6
> for fbik.m18, ftik.m20 and ftim.m40?  I really need it the max1800 load.
> My 4000s are all running fti.m40 except for my 4004 which all I have is
> a broken 7.0b7.

Ok, I just upgraded to 7.0.0, and that's exactly what happened.  MP
callers were not able to bind the second channel, but MPP callers were
find.

Here is the problem (and a workaround):

	There are three attributes in a connection profile that could
possibly affect MP and MPP calls:

	base-channel-count, minimum-channels, and maximum-channels.

	For a connection that is allowed to connect with 1 or 2 channels,
I had always set:

	base-channel-count = 1
	minimum-channels = 1
	maximum-channels = 2

	Under 7.0.0, this works for MPP callers, but not for MP callers.

	Appearantly, MP isn't reading 'maximum-channels', instead, it's
reading 'base-channel-count' when checking if the additional channel is
authorized.

	The solution is to use this instead:

	base-channel-count = 2
	minimum-channels = 1
	maximum-channels = 2

	This works for MP and MPP callers.

	In RADIUS, the attributes of concern are:

        Ascend-Base-Channel-Count=2,
        Ascend-Maximum-Channels=2,

	Which also works for MP and MPP callers.  Ascend customer service
agrees that this is broken, but this is a workaround that (at least for
now) works.

					Mike Jackson
					TSCNet


++ Ascend Users Mailing List ++
To unsubscribe:	send unsubscribe to ascend-users-request@bungi.com
To get FAQ'd:	<http://www.nealis.net/ascend/faq>