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 *
> -----Original Message-----
> From: Frank Heinzius [SMTP:frimp@mms.de]
> Sent: Monday, November 03, 1997 11:39 AM
> To: portmaster-users@livingston.com
> Subject: Re: (PM) D Channel Callback Feature and PM3 (fwd)
>
> Hi all,
>
> first my humble apologies for my previous, harsh statements about
> Livingston.
> Now let me try to get constructive...
>
>
> On 1 Nov 97 at 11:28, Heiko Schlittermann wrote:
>
> > On Oct 31, Phil Taylor wrote
> > : I'm not really sure what the fuss about D-Channel Call back is
> anyway,
> > : as long as the client supports it just disable call answering,
> this has
> > : the same effect as the PM3 not completing the call except it is
> client
> > : driven.
> >
> > There may be a situation the other way round. The client want's to
> be
> > called back by you, the ISP. And the client expects to get it's
> call
> > rejected and instantly called back. Impossible if you're using a
> PM3.
> >
>
> D-channel dialback means, that the call originator just "knocks" on
> the door of the other
> side. This is, due to the D-channel protocol definition, free of
> charge.
> The caller and called IDs are both submitted. Now the called router
> can use the
> originatorīs number to lookup a callback number or use this number for
> callback (the
> latter is surely dangerous for security reasons).
> The solution would be, as Heiko suggested before, to use the
> Calling-Station-Id as
> username and do a normal RADIUS or usertable loookup.
>
> Now, where do we need this D-channel callback? There are two
> possibilities
>
> (1) An ISP-customer has an ISDN dialup account to the ISP. The ISP
> does no charged
> dialout. So if an Email arrives for the client, the ISP router just
> "knocks" the
> customerīs machine which then dials to the ISP. There is indeed no
> charge for the ISP.
> What to do if you donīt have D-channel dialback:
> - no dialout from the ISP (bad for the customer!)
> - Email to customer handled by UUCP or modified SMTP-queuing
> - charged dial-out. Then the ISP needs Advice-Of-Charge to
> distinguish between local and
> long-distance calls (and, in Germany the charging structure of the
> Telekom is very
> complicated, so a mere lookup table isnīt accurate, you really need
> the advice-of-charge
> tick provided by the Telco in the D-channel).
> If the router manufacturer is able to implement advice-of-charge, he
> has a sophisticated
> understanding of D-channel features and is therefore able to implement
> D-channel-dialback
> as well.
>
> (2) In corporate business, Teleworkers donīt have to pay for their
> dialup calls to the
> company. It is very difficult to distinguish between private calls and
> corporate calls in
> the monthly charge bills. Normally, the Telekom doesnīt provide an
> accurate call list.
> This is an additional feature, which costs additional fees to the
> Telekom for each
> printed call.
> Therefore, the companies are *forced* to do dialback to the remote
> teleworker. They need
> the D-channel dialback, because otherwise the originated call charges
> canīt be precisely
> determinded.
>
> Ok, just to clarify: all these features are part of the ISDN protocol.
> Why not *use*
> these protocol features?
> In Germany, the ISDN knowledge is really superior. We have ISDN hard-
> and software with
> all this D-channel stuff included from the beginning. But most of
> these products lack in
> case of remote access, routing and so on.
> Therefore, I prefer companies with good reputation in remote access
> business implementing
> ISDN features rather than vice versa.
> Therefore I want to see Livingston doing that. I love these products,
> I love to sell
> them, I love to do business with Livingston, but I donīt love the
> ignorance of European
> needs. Btw., donīt you also promote ISDN in North-America? So wouldnīt
> you also like
> these features too?
>
> Ok, these were my two Euros (whatīs that cents? ;-)
>
> best regards,
>
> Frank
>
> --
> Frank M. Heinzius MMS Communication GmbH
> mailto:frimp@mms.de Eiffestrasse 598
> http://www.mms.de 20537 Hamburg, Germany
> Phone: +49 40 211105-0 Fax: +49 40 210 32 210
> -
> To unsubscribe, email 'majordomo@livingston.com' with
> 'unsubscribe portmaster-users' in the body of the message.
-
To unsubscribe, email 'majordomo@livingston.com' with
'unsubscribe portmaster-users' in the body of the message.