SX2K COS manipulation?

[Stramec]

Hi Guys,

I have been asked by a client to set up some call restrictions on one of the users handsets.

Basically the reception takes calls via a multicall and needs to be able to forward these calls off switch. But my client doesn't want the receptionist to initiate their own calls.

It sounds like a catch 22 to me, but a colleague says he thinks it is possible by manipulating the COS forms to allow bridging but not to allow the handset to make outgoing calls at any other time.

If anyone can shed any light on how to go about this, I'd be most grateful.

Cheers

Stram

 

[MitelInMyBlood]

Depending on your network design, normally you would disallow public network-to-public network connections (in COS) and in addition place an interconnect restriction on your outgoing trunks to disallow them to be connected together to each other (outgoing to outgoing). Finally you would want to enable interconnect checking for conference calls.

This should allow the attendant to take an incoming call and transfer it to an external destination, but should prevent the attendant from originating two (or more) calls and tying them both together (conferencing them together) - unless - the attendant remains on the line as a 3rd party in the call.

All this is a bit of try it and see, because your success may depend in part on your network and trunking design.

 

[Stramec]

Hi Blood,

Thanks for that, I have put the COS change in place but I'm having a bit of trouble with the INterconnect restrictions.

I've never looked at the interconnect table, it seems to be just full of '.' not entirely sure what I need to change to put the restrictions I need.

Any further help much appreciated.

Our network is very simple as the switch is a standalone with break out straight onto the local PSTN.

Cheers

Stram

 

[MitelTech]

How's this going to solve the problem of having the attendant *not* be able to place calls?
If the attendant needs to be able to transfer externally, the attendant needs to be able to place calls. Simple. It is a catch22 that I don't see a way around.
If someone has a solution, please enlighten me.

 

[Stramec]

I must confess Miteltech that was my first reaction, but I'm by no means a Mitel expert so was hopeful there would be some form of workaround, to do with bridging the call, but the attendant will still have to seize the seize the trunk...hmmmm

 

[MitelInMyBlood]

If I understood what is wanted, the Attendant needs the ability to transfer calls externally and be able to release, allowing the parties to converse, but they do not want the attendant to have the ability to tie calls together that are only originated by the attendant. In other words, incoming to outgoing, fine. Outgoing to outgoing, forbidden.

One potential problem if they're not using T1 PRI trunking is the VNL (Via Net Loss) will make for a very weak sounding call if transferring between analog trunks.

The Interconnect Restriction table is a function of the interconnect number assigned to each trunk and therefore acts as a brute force method of restricting which trunks can be interconnected to one another in a trunk-to-trunk or tandem call. If you don't understand what you're doing then you probably ought not be doing it. The interconnect tables were covered in the ARS training modules of both the I&M school and System Admin school. If you've been to neither, then.....

 

[MitelTech]

If I read it right, here's how I see it.

1. Att. needs to be *able* to transfer externally (tieing the trunks together, and still release herself).
2. Att. needs to be restricted from external access.

It's a catch22, both cannot happen.

 

[MitelInMyBlood]

Well, yes and no.
What I think I would propose to the customer in this situation is to set up some account codes and then require that the attendant use those acct. codes for setting up the inbound to outbound calls. In this way we could restrict the attendant from placing the calls without the use of an account code. No, it won't STOP it, but it should provide some accountability if/when it occurs. A valid call would thus have two SMDR records (in and out) plus an acct. code tied to one of the calls. If the attendant bootlegged a personal call on someone's acct. code it would be evident because you would have only one smdr record against the acct code.

 

[12345kevin]

If the attendant is always going to be dialing the same numbers they could be "allowed" in the ARS with relevant COR. Alternativley completley bar the attendant from outgoing calls and put the required number in as speedcalls with toll overide set to yes