> Once upon a time Michael Lea shaped the electrons to say...
> >would like to be able to set which ports (if any) accept calls on each
> >directory number.
>
> Sorry, there is no way to do that. You could use RADIUS and the
> Called-Station-Id check item to refuse/allow authentication in association
> with the NAS-Port-Id check item.
Unfortunately the check items can only be tested after the user's been
asked for their authentication info.
> >returning a busy signal. Is set dn broken, or is there some other way of
> >making the PM3 do what I want it to?
>
> The PM3 just doesn't support what you are looking to do. There is no
> logical connection between the 'ports' and the PRI channels. On PRI the
> DN doesn't really do anything.
Well, the DN setting DOES do something, but it's net effect isn't anything
useful because of how it was implemented. As it stands now, an incoming
call will associate itself with the logical 'port' that has a matching DN.
It's the incoming calls that cannot find a 'port' with a matching DN
that's the problem: if there is no ports with a matching (or blank) DN it
would make considerably more sense to return a circuit busy.
Setting it up this way could have two benefits that I can see:
1. PM3 users could create different classes of service (ie. different
users:line ratios) within the same chassis (or groups of chassis)
by having different DNs.
2. This could also serve as the "soft busy" feature everyone wants. By
setting all the DNs to a bogus number on a chassis, incoming calls
would get a circuit busy, and be forwarded to the next PRI in the
hunt. Why have a new setting for soft busy when the existing
DN setting (if fixed) would provide the same functionality, and then
some?
Curtis
Curtis Coleman ---------------------------------------- curtis@pangea.ca
| "I don't want to run a company. I'm not good at managing people. |
| You have a problem with the guy in the next cubicle? I don't care. |
| Shoot him or something." |
| -- Marc Andreessen, founder of Netscape |