Call Transfer / Conf Issue...

[ssheldon01]

We're having an odd issue with our 3300, and I thought someone here might have an idea what's happening...  (I'll make this as brief as possible, promise..)

THE ISSUE:

When any phone in our office (we're all using 5330's) RECEIVES an incoming call from outside the office, we are unable to transfer or conference that call with another external number.  When you attempt to do so by pressing the TRNSFR/CONF button,  dial 9, get a dial tone, then dial ###-####, you immediately get another dial tone (which you cannot dial with, and that will turn over to a busy signal within about 10 seconds).. 

Odd thing is though, is that you can press the TRNSFR/CONF button again and transfer that dial tone / busy signal to the original call and link them, so it appears that the call transfer works, it's just that actual CALL is not working when you dial that second number...  Not the transfer / conf function...  That seems to work, but transferring or conferencing in a failed call is sorta pointless you know??

HOWEVER, THIS WORKS:

When any phone in our office RECEIVES an incoming call from outside, it WILL allow you to transfer/conf with an internal extension..  No problem there..

When any phone in our office CALLS an external number and the call ORIGINATES from our system, you can transfer/conf with another external number or internal extension..  No problem there either...

The only time it "messes up", is when that first call comes in from an external caller...

I've gone over COS options like Call Forwarding (External/Internal), etc and everything APPEARS to be set correctly, I'm just not extremely familiar with this system yet (still learning it) so I can't figure out why everything works but this one scenario...

Any ideas???  (and I might add, I can't thank you enough ahead of time if you do....  THANK YOU..)

[ralph]

Talk to your carrier about this.
Here's what I think is happening.
When an external caller rings into you, you answer it and then try to transfer it out, your 3300 is showing the external caller's caller ID as the source of the call.  Since that number isn't authorized to call on your carriers network the carrier blocks it.

There is an option to change that in the ISDN options but there are times you would want to see the external caller ID and this would stop that.  For example, if you transfer a call to a cell phone you may want to see the caller ID of the original caller.

Ralph

[ssheldon01]

Talk to your carrier about this.
Here's what I think is happening.
When an external caller rings into you, you answer it and then try to transfer it out, your 3300 is showing the external caller's caller ID as the source of the call.  Since that number isn't authorized to call on your carriers network the carrier blocks it.

There is an option to change that in the ISDN options but there are times you would want to see the external caller ID and this would stop that.  For example, if you transfer a call to a cell phone you may want to see the caller ID of the original caller.

Ralph

Thank you Ralph... 

Based on the tests I've done and the outcome of each, that makes sense...   It just doesn't seem like an issue with the transfer/conf call features, and your theory is the best I've seen so far...

Question...  This is getting a little deeper than programming phones, etc so I'd rather ask than jump..  In your opinion, (don't worry, I won't hold you responsible if the phone system blows up...) what's the danger in changing the "replace external CLID" to TRUE and verify this is actually the issue??  I can't see any negatives, but as I mentioned previously, I'm more of an experienced newb than an expert..

The main reason this is a problem for us is not the call transfer, but actually the conference call, so seeing the original caller's ID isn't really that important..  In all honesty, I can see people here WANTING the caller ID to read our firm, not the original caller, so it may be a positive thing...

Your thoughts??  (and thank you again for your previous thoughts...)

[x-man]

I have another theory...on the external transfer there is a setting to need a code entered before it will be allowed to trunk to trunk transfer and this is why you are getting the second dial tone. Its a security feature to help stop fraud. I think is called non verified account code.

[x-man]

Or even DISA forced account code...

[ssheldon01]

I have another theory...on the external transfer there is a setting to need a code entered before it will be allowed to trunk to trunk transfer and this is why you are getting the second dial tone. Its a security feature to help stop fraud. I think is called non verified account code.

Thank you for your reply...  I'll take a look at these settings as well and post back if anything worked....  I'm going to try a few things today..

Thanks again everyone...

[ssheldon01]

     It's fixed...  Just wanted to post back and let you know what fixed it in case someone else runs into this....   

We ended up changing the option "Replace External CLID" to TRUE (under the ISDN Protocol section) so any conference/transfers we were trying to place would register our number as the caller ID no matter where the first call originated from.. (since our problem was conferencing, we aren't concerned with the caller ID being wrong during a call transfer)....  Thanks Ralph for that idea...  You got it in 1...

Thanks to everyone that helped as well..  I really appreciate everyone's input on this....

[ralph]

Thanks for letting us know how it got fixed.

Ralph

[ssheldon01]

Thanks for letting us know how it got fixed.

Ralph

No problem at all...  Nothing is worse than finding your issue on a forum and realizing that the person never posted if the ideas worked or not, or if it was fixed...  I won't be part of that.. 

Thanks again for your help....