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!

MICS 6.0 external call forwarding 2

Status
Not open for further replies.

kmpp

Vendor
Feb 25, 2012
71
US
Are there any issues with 6.0 sw in regards to external call forwarding?
I have tried to utilize this feature using the info on this site (faq799-2078), but cannot make it work.
I have gotten to the point of being able to input the number to be forwarded to i.e. F4 9-AC&number.
All outside calls are answered by the NAM(4.1) when the caller dials the extension that is forwarded, it just rings at that extension.
Thanks for any help.

 
It sounds as if the KSU is doing what it is supposed to do but the NAM isn't. If the incomming call is pointed to the DID and is forwarded correctly befor having a chance to be re-routed by the NAM's AA to the DN, the conflict is in the NAM programming.

yes, 6.0 is full of holes- thats why 6.1 came out so fast after 6.0

The NAM uses two trunks to re-route the call just like the outbound transfer feature.
 
When you set up the NAM programming, you need to do the following:

Say the external number is 555-1212 your path should be;
9 # 4 2 5 5 5 1 2 1 2

9= outside Line access (unless omitted which should be the case)
#= next digits are special characters to follow
4= recognize dial tone
2= specifies the next numbers in the string to be dialed (don't forget the 2)
5551212 the number to be diald

and with 6.0 use a line pool for outdial- to bypass any outdial code conflict. Also VERY IMPORTANT- make sure the # of VOICE CHANELS are set to at least 4 but no more than 6.



 
It sounds as if the KSU is doing what it is supposed to do but the NAM isn't"

I disagree

The set is supposed to forward all calls regardless of how calls get to the set.

The NAM's job is only to transfer and hand off the call to the set, not get involved in any external forward.

The problem seems that the KSU and NAM are not talking to each other where it allows the KSU to take over the call.
Perhaps the KSU does not understand the transfer from the NAM.

What you guys are now indicating is how to setup a NAM to do out calling be it from AA or mailbox etc and is not really related to the issue since the KSU is then one that transfers outside.

Situations like this I tell the client sorry but no support on outdated software from manufacturer, upgrading will allow for support and possibly fix the issue and mention that it is buggy software.

It is rare to see 6.0 out there....6.1 was a free upgrade to those whom had purchased 6.0 at that time.
Vendors throw them out and/or do not purchase 6.0 knowing all this.






=----(((((((((()----=
curlycord
 
Check the transfer setting in the mailbox. The tranfers setting type out of the mailboxes must be set to "blind" otherwise the NAM is in control not the KSU. The call will not be released by the NAM until it is answered at the phone unless it is blind transfer.

Marv
 
Thanks to all of you.
I am going to suggest the upgrade, this was an account that I took over a few months ago, so don't know to much about history.
Again, Thanks
 
I beleive all mailboxes are set to blind transfers, I will check when I can get to site, no remote.

Thank You
 
All the Blind and Screened is how the call is delivered to a mailbox.
Blind = No announcement of calling party name
Screened = Announcement of calling party name
This should have nothing to do with call forward of the phone.

I know you said that lines are Programmed for supervision on your side but have you chacked the lines themself and tested that Telco is providing Supervision? The NAM needs supervision before it will release the call where a direct call (DID) to the phone does not.
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top