My (admittedly limited) understanding of the setup of incoming calls to a
PRI based PM3 runs something like this:
1. The telco switch determines the destination of the call (based on the
number dialled), and various other attributes (like voice or data).
2. The telco switch contacts the device using the D channel to find
out if they're prepared to accept the connection based on the attributes
determined above. At least some of these attributes turn up in the radius
start record after the call is authenticated, so we know that we're
getting them from the switch at some point.
3. The PM3 signals back to the switch a yes or no, and prepares to
handle the call in a way appropriate to the attributes given to it by
the telco switch (i.e. allocates a digital modem or whatever). If the PM3
can't handle the call based on the attributes given, it says no and the
switch resends the request to the next device in the hunt group (if any)
and repeats the process starting at #2.
4. Assuming the answer in #3 is yes, the telco switch completes the
connection between the caller and the PM3. If the answer is no, and there
are no more devices in the hunt group, the switch returns a busy to the
caller and the process ends.
5. Assuming we get this far, the PM3 completes the connection and prompts
for authentication using the new connection. Once authenticated, the PM3
setup up the routing and other user-specific aspects of the connection,
writes the accounting record, etc.
The part I'm wondering about whether the PM3 could be made to use certain
attributes (in particular the number dialled, which I assume is captured
in step 2 via the D channel) to handle the call a certain way. More
specifically, could the PM3 be made to return a busy based on the number
dialled instead of on the availability of a modem in step #3 above.
My immediate interest in this is to be able to deny/allow access based on
these attributes, and to change the rule quickly. With this ability, we
should be able to re-jig dialup pools on the fly based on actual demand
rather than having sizes pre-determined and almost certainly not
optimally. There may be other uses as well based on other attributes
(like the calling-station-id).
There are other ways of doing this, but all the ones I've though of so far
are done during authentication and are pretty ugly. It strikes me
that the connection setup stage is the right place to do it.
Can this be done? If so, is anyone else interested in being able to do
it?
Cheers
== Brian Finnegan Pangea.CA ==
--------------------------------------------------------------------------