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!

Getting "busy" on external forward 7

Status
Not open for further replies.

ivtrook

Technical User
Jun 28, 2006
76
US
Extension 6333 was an existing ext. with a physical phone. i renumbered the ext. to 5333 and made x6333 an adjunct (because the DID needs to forward without a physical phone)
Made the auth code the same as the adj. 6333 and then finally enabled remote forwarding for 6333.

Since i'm not out on site i had the customer input the code from an SA Key..

"#80 (6333) # *33 9 (1-847-xxx-xxxx) #"

Upon testing, dialing either internally or externally the 6333 DID, the caller gets busy tone.

Anyone have any ideas to why i have busy tone???

 
Then there's no excuse for the auth code not working. Can you do a print of the extension after the customer has set the forwarding you? If they were successful, the print will show the forwarding destination. And, if you have Remote Access (since you have DID's) you can set the forwarding yourself.
 
If you have not done so, you need to activate trunk-to-trunk transfer and make sure the lines/trunks have Disconnect Supervision active! Otherwise you will have problems.

....JIM....
 
The reason x6333 is not forwarding is with the dial string you have posted. If you are indeed dialing what you are showing then it will never forward. You should advise your customer to dial:

To forward:
Speaker on and dial.
#806333#...steady dialtone
#3391847NNNNNNN#...will hear confirmation (beep, beep, beep)
Speaker off.

Place test call.

To cancel:
Speaker on and dial.
#806333#...steady dialtone
#336333....confirmation (beep,beep,beep) it is not necessary to dial the # key when forwarding back yourself.

lg

 
Actually, when programming RCF via an authorization code, it is indeed STAR 33, not pound 33....



Creating an Extension for Remote Call Forwarding



Renumber an adjunct to become the desired Extension Number

System Renumber>Single>Adjuncts>Old Adjunct No.>Enter>New Extension No.>Enter



Assign Authorization Code to New Extension

Extensions>More>Auth Code>Ext. No.>Enter>
Code:
>Enter

    (Hint: Make the Authorization Code be the same as the Extension Number)

  

Enable Remote Forwarding

    Remote Fwd>Extension No.>Enter

To Forward the Extension:

    Go to a KEYSET, and press an SA Key
    Dial #80-[Authorization Code]-#-*33-9-[Outside Telephone Number] #



Now, I don't believe that you also need Trunk to Trunk allowed, but it can't hurt. Perhaps even for the extension that is transferring to the RCF'd extension. Certainly you need to have Reliable Disconnect set to Yes.
 
ivtrook...I stand by what I posted. What TTT has posted is EXACTLY right...EXCEPT the *33 part. Even his comment on the bottom of his post is correct. I recommend you try the method I posted before you waste your time.

TTT...the reason you are wrong is the customer is doing this on site not doing this remote. Your notes are for you to do this remote for the customer.

ivtrook...you advise your customer to use the method I posted and post the results. If I am wrong I will give TTT a star.

lg
 
One other thing I forgot to mention is...trunk to trunk transfer has nothing to do with this feature working...

ivtrook....this is something else you can confirm. lg
 
OK, allow me to clarify something.

If an extension, such as a VOICE MAIL extension attempts to transfer an EXTERNAL CALL to an extension that is REMOTE FORWARDED, then.......

Yes, TRUNK TO TRUNK is REQUIRED. - On the Voice Mail Extension required to do such a transfer.

AND/OR any other extension that will be transferring OUTSIDE calls to the REMOTE FORWARDED Extension will need that capability as well.


ANY QUESTIONS?


 
No questions....but I disagree.

I agree when extensions are added to the VMI calling group the trunk to trunk transfer is activated...as is the ARS restictions etc. for the ports. But I don't think this is what allows calls to be transferred to extensions that have the RCF feature activated.

I had to re-read ivtrook's original post. I thought maybe I had missed something about a voice mail problem.

Here is where I disagree. When RCF permissions are given to an extension...like x6333 that ivtrook is trying to program, and that one extension remote forwards to an outside number... it seems really stupid to me that I would have to give everyone in my system trunk to trunk transfer capability because they want to transfer x6333 a call. lg





 
You Sir, or Madam, are wrong.

Allow me once again to provide some clarification:

Each and every extension that needs to transfer an EXTERNAL call to that extension MUST HAVE Trunk-to-Trunk transfer capabilities. (Now, that doesn't mean EACH AND EVERY EXTENSION in the System, ONLY those with a NEED TO DO SUCH TRANSFERS)

In fact, if that D-I-D Extension is going to receive calls from the OUTSIDE (External Calls) then it also MUST HAVE Trunk-to-Trunk transfer allowed as well.

Internal calls, NO PROBLEM, External calls, TOTALLY DIFFERENT.

That leads me to these two rather pertinent questions:

How long sir/madam have you been working on this system?

AND/OR how long have you been in the TELCOM business?




Former Tier 3 Tech Support Engineer with AT&T/Lucent/Avaya with 40 yeas PLUS in the biz.
 
I have been in it a little while....and I have also had to spit feathers from eating crow. And yet I still learn something everyday about the systems. I am old school but then I have said that before on some of my posts.

I can also tell you that I have a Magix 2.0 benched here in my shop...and I have tried with success to do what I have been talking about over the past few hours. lg
 
However, External calls transferred from extension X to our FORWARDED Ext???

D-I-D calls from the outside?

External calls through Voice Mail?

Please let us know the results from those tests.

We all learn something every day, mostly what I learn however, is that I don't know as much today as I thought I did yesterday.....

[thumbsup2]





 
Test results: Merlin Magix R4.0 408 MLX, Intuity Audix
Remote call forward via adjunct extension using Authorization code

Set up: Adjunct 401 with authorization code 7307. RCF = yes Trunk to trunk = no
Set up: Extension 207 authorization code = none, RCF = no, Trunk to trunk = no
Incoming to Analog DID port:
Outgoing 9 = ARS to 70 pool (one analog trunk 801)
From any phone: Dialed #80 7307# *33 9 555-1212 # (received conformation beeps)
DID call to extension 207,answered: blind or supervised transfer to extension 401 (call rang @ 555-1212)
To cancel: from any phone dialed #80 7307 # *33 401 (received conformation beeps)

2nd Setup
Same as above for extensions,
Incoming call to Intuity Audix automated attendant. Subscribers = 207 & 401
Audix ports FRL= 0 Outward restriction = yes Trunk to trunk = no
Activated RCF same as above
Incoming call to AA selected 401 (rang @ 555-1212)
Incoming call to AA selected 207; blind/supervised transfer to 401 (rang @ 555-1212)

Good Luck to all involved

42 years in the business and counting.
 
I believe Merlinman is correct, unless your software is doing something else. The following text is from the Magix Feature Reference guide R3.0:

Trunk-to-Trunk Transfer
Users can transfer inside or outside calls either to inside extensions or to outside numbers. Trunkto-
trunk transfer (an outside call transferred to an outside number) is not allowed when the line/
trunk with the incoming call is a loop-start line that is not programmed for reliable disconnect. (The
Reliable Disconnect setting indicates that a disconnect signal is sent by the local telephone
company to the system shortly after a caller hangs up.)
Trunk-to-trunk transfers can be blocked for an extension, whether or not the lines/trunks involved
are programmed for reliable disconnect. The factory setting restricts all extensions from making
trunk-to-trunk transfers. Extensions that should not be restricted must be individually programmed
to allow trunk-to-trunk transfer.
Transfers to non-local dial plan extensions are actually trunk-to-trunk transfers, although users
initiate them as they do inside transfers. Most extensions, including those equipped with single-line
telephones, can make these calls, regardless of system programming to allow or disallow trunk-totrunk
transfers.
When an Automated Attendant transfers a call to a non-local extension, the transferring MERLIN
MAGIX system monitors the call to ensure that it is answered. If the non-local extension is not
available or the call is not answered within the transfer redirect timeout period (fixed at 32
seconds), the call stops ringing at the non-local destination and is redirected to the extension on
the same system as the Automated Attendant that is programmed to receive redirected calls. This
redirect extension can be a QCC queue, a Calling Group, or an individual extension.
You cannot use a single-line telephone connected to a tip/ring port to make a trunk-to-trunk
transfer.
-----------------------------------------------

The same holds true for the Legend, and I know that from the systems I have worked on, the feature does not work without the T-TO-T feature active for the station forwarding.

....JIM....
 
Well if that is true Memphisribs, it looks like Avaya has a new software bug that probably won't get fixed.

Now we have an illogical Magix!!


....JIM....
 
Clarification: Non-local refers to extensions on networked Merlins, Nothing to do with the application in question.
I see nothing in the above text that says that a station with RCF needs trunk to trunk transfer permissions.
The extension being transfered to is very local.

Just my thoughts

42 years in the business and counting.
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top