nighty@hexanet.fr wrote:
I agree 200% and this is why I asked about it in the first place
Peter A. Sang wrote:
>
> Hi Frank,
>
> do you remember we already discussed this at the phone half a year ago ?
>
> I agree that the PM3 is not a good choice for Teleworking applications
> due to the lack of 'D-channel signaling' or 'charge-free dialback', this
> feature is *essential* for those clients.
>
> But you might recall that it took a very long time even for a company
> like Cisco to implement it. I think that the importance of this feature
> is simply not *understood* by US companies....sometimes Europe is far
> away in their thinking!
>
> We as an ISP have to implement the scenario you described in (1) to
> avoid logging and accounting of dialout charges. We solved it by
> choosing other brands of routers at the customers side, so far we've got
> charge-free dialout working with our PM3 to ELSA Lancom MPR and Zyxel
> Prestige 100/128 routers at the client's side. It should work with Cisco
> 7x0 and BinTec BRICK XS/XM, too (not tested yet).
>
> However, although it works, I'm not happy with it: The 'intelligence' of
> this feature is based on the client router, the PM3 just tries to dial
> out and fails after ~60sec. Caused problems:
> 1. More PM3-lines than necessary are used, we have to reserve a pool of
> several lines for dialout only.
> 2. The 2nd B-channel at the client is also blocked for this period.
> 3. If the clients 2nd B-channel is busy when we try to initiate a
> connection, the activation fails.
> 4. The first arriving data packets get lost before the connection is
> established (maybe they are just stored in the wrong buffer?) I assume
> this will fail completely when more than one PM3 are involved.
>
> I think it would not take LE too much effort to implement some changes
> in their dial-out location handling for ISPs (mainly a
> shorter/adjustable timeout would be an improvement for now).
>
> For teleworking applications, a CLID (ISDN client ID, sent over
> D-channel) identification over Radius is required: before the PM3 'hooks
> up' the line, it has to check the CLID against the Radius (or internal)
> DB and act accordingly if this CLID belongs to a dialback user. (send
> 'busy' and dial back).
> I haven't looked into the depth of PM3s design, but maybe it's just
> *impossible* to implement due to design/concept restrictions?
>
> MAYBE LIVINGSTON CAN CLARIFY THIS? I understand that they don't tell us
> release dates (a policy I like ;) ), but at least an answer like
>
> 'we can do it, it will be in the next major release somewhere in Q2/98'
> or
> 'we could, but we won't' or
> 'we cannot do it in this product'
>
> would be fair to their customers.
> IMO their success in the European Market *depends* on excellent support
> of advanced ISDN features. It would help LE to move their focus from
> simple 'Terminal servers' to real 'Communication servers' (that includes
> Fax support & NetCAPI, btw.) In this field products from companies like
> BinTec are *much* more sophisticated.
>
> Just my 200cents (=2 Euro)...
>
> Mit freundlichem Gruss,
>
> Peter A. Sang
> SANG Computersysteme GmbH * Kruppstr. 82-100 * 45145 Essen * Germany
> T: +49-201-82020-0 * F:-40 * http://sang.net * mailto:pesa@sang.net
> * Microsoft Solution Provider/Internet Specialist * Intel Systems
> Integrator *
-
To unsubscribe, email 'majordomo@livingston.com' with
'unsubscribe portmaster-users' in the body of the message.