Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations strongm on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

Camp on weirdness.... 1

Status
Not open for further replies.

wireman50

Technical User
Jan 8, 2011
1,023
GB
Have 3300 that was upgraded to MCD7.0 a couple of months ago and now we have a weird problem with the camp on.

Auto campon timer has been blanked for a busy when busy scenario. Phones that have been on a while all seem to be working correctley (but see later) and respond with busy when busy on internal external outgoing and external incoming.

A group of phones that have been added recentley but before the upgrade are responding quite differently. There is a page group set up but all the phones that are acting oddly are not in this and auto camp on is still active on them for all scenarios; internal external in and out.

If I add the phone to the page group then you get busy on internal and outgoing trunk calls but campon is still active if they are on a received external call.

Does auto camp on function with the COS of the phone or the COS of the line? Do I need to blank the timer in the COS of the trunks?
 
It works with the calling device, in this case, the Trunks.

**********************************************
What's most important is that you realise ... There is no spoon.
 
So I need to set the autocampon timer on the trunk COS to blank as well then?
 
If you want to disable Campon from trunks then yes

**********************************************
What's most important is that you realise ... There is no spoon.
 
Ah, wait, the calling device is an internal phone to another that is receiving and external call in. Does this still apply?
 
I've been having what I believe is a CAMP ON problem with a release 7.0 running vMCD along with MiCollab. Although CAMPON timer in all COS has been disabled (blanked) phones are receiving a burst of "noise" that isn't heard by the other party; internal or external.
Immediately after the "noise" the ip phones reset. We were getting an ASSERTION ERROR until Mitel patched that out. Now its just the "noise" then a reset.

Anyone else?

I suppose you're entitled to your opinion, I'm just not to suppose very hard.
 
@Wireman50 -
the calling device is an internal phone to another that is receiving and external call in. Does this still apply?

So, my understanding is a phone X is on an established call with a trunk and an internal station Y calls. The internal station Y is camped on and the tones are heard by Station X.

Is station Y calling the prime line of Station X
Is station Y invoking camp-on by pressing any keys or is camp-on automatic
Does Station X have multicall keys in the system anywhere (making the station not busy)


**********************************************
What's most important is that you realise ... There is no spoon.
 
phone x is on a incoming trunk call that is established; this is a multicall key. station y makes an internal to station x and is auto camped on to station x and station x gets one burts of ringing and cam op tone is heard.

As above the incoming call is on a multicall key. Station X is not a multicall anywhere in the system. He is however on a number of dss/blf keys.

We have tried the COS option of making the station busy when engaged on any line but that makes no difference but introduces another weird thing when a station has voicemail. When a station has voicemail and is called internally when on an incoming trunk it goes direct to the users voicemail instead of giving busy and if nothing happens at the end of the voicemail it then goes through to AA....(that is a s reported by the tech savvy customer.


 
Wireman50 said:
this is a multicall key
burst of ringing and campon tone is heard

So there's your problem. We're not talking about campon at all. Yes the client may think it is campon but no.

Campon is only available when dialing a device that is Busy. If the prime line of the phone is available or any appearance of the prime line is available then the key is not busy in the system.

The DSS key MAY be lit based upon the status of the system option to show busy based on station busy (any key) but it is very important to note that the specifically dialed DN (Prime) is not busy.

As such, the Prime key of the phone will emit a burst of ringing (unless set to Ring continuous in which case it will ring normally). The key will then flash indicating an active call and will follow the no answer routing if not answered.

THIS IS NOT CAMPON. The statement that camp on tones is heard is a red herring. I will give you four nines probability that that tone does not exist in this scenario. The Burst ring is not camp on. It is busy set call notification (my term, might not reflect Mitel's nomenclature)

To be 100% positive I would require that you test the scenario with the active call being on speakerphone. No tones will be heard if my theory is correct. Tones will be heard if this is truly camp on.

**********************************************
What's most important is that you realise ... There is no spoon.
 
Ok, I will get them to test in the morning but I am in the process of upgrading to 7.1.

Is there any way to overcome this then; customer is adamant that it wasn't like this in MCD 5.0 stating that when ringing a busy station they got busy regardless of call being made....i.e. they got busy when a station was in use regardless of how the station was being used...now that could of course be a red herring as well knowing what customers are like. Is there a setting for busy being returned on a non prime line I guess is the question?
 
If they were running on a 3300, then this is the way is has functioned since the 2K days. If the key is idle, it will ring regardless of the status of the set.

I would be more inclined to think something has changed in the environment that isn't being factored into account for the discrepancy is viewpoints. For example previously DID's were programmed to ring the Prime and that was changed to fix some problem of request and now we have this "Problem".

The user can activate DND while on a call if they don't want their prime line to ring.

**********************************************
What's most important is that you realise ... There is no spoon.
 
DID has been programmed to ring a multicall since day one when I installed it. The only person to make config changes is me and the only person who does upgrades is me; I have changed nothing except to take it to MCD 7 from MCD 5. As far as I know when they lift the reciever to answer an incoming call the prime line led lights green as well; have asked for a check but surely that means its not idle? i would doubt they will take kindly to having to manually set DND on every incoming call....

have asked them to check using a speaker phone call as well.

This is the COS option I would have thought would work....

Force Device Busy If Any Line In Use
Select Yes to prevent phones from receiving calls when they are already engaged in a call. The incoming calls are immediately forwarded to an alternate destination such as voice mail. If an alternate destination is not available, the system returns busy tone.

but it doesn't seem to work in MCD 7 hence upgrade to 7.1 when its supposed to be fixed.


We can maybe overcome the VM issue as VM is not widely used on the system.
 
Yes that is a new option that I haven't played with and I suspect it is designed for your exact scenario.

**********************************************
What's most important is that you realise ... There is no spoon.
 
Further to this it looks like 7.1 has proved to be the answer to the problem as the COS option now works EXCEPT for station 1000. When this phone is given the option and is busy ALL calls in go straight to AA; so it seems that for some reason its not respecting the multicall flag on the key but is turning it to a keyline (or so it appears) ....(very wierd and I must check its actually a multicall and not a keyline....nope deffo a multicall). So somewhere there is a setting that is tell the Mitel that when 1000 is busy and force device busy is set it sends any external and all incoming call direct to AA (i.e. it is making all the lines busy rather than just the device which is what drew me to the keyline theory)
 
Check Forwarding Status on Ext 1000

**********************************************
What's most important is that you realise ... There is no spoon.
 
Hi, checked that and there is no rerouting in place. There was a call forward set but it was disabled. Removed it to check but made no difference. The odd thing is that it makes all the incoming circuits busy not just one (4 BRI's in service).
 
I don't work with BRI much. It may be some setting in the BRI that is redirecting the call.

Sounds suspiciously like a bug Feature

**********************************************
What's most important is that you realise ... There is no spoon.
 
Indeed, I think that is the conclusion we have reached but are waiting for Mitel to confirm.

If it were the BRI I would expect it to occour on all handsets but they are all (30 odd) working as designed; just 1000 9which we think was the first connected handset when installed some years ago) that has the problem.
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top