Transfers to outside number fails if phone unregistered v5.1

[future-data.biz]

Dear All,

I have an issue in v5.1 which is strange. I can't get to transfer to outside numbers to work. The transfers are done after a DR has transfered the call to this ext. If I change this ext (511 in this case) to point to the voicemail it works. If it points to the outside number, it fails.

Here is an extract from the server status console:

12:49:15.187 Call::RouteFailed [CM503014]: Call(74): Attempt to reach [sip:[email protected]] failed. Reason: Not Found
12:49:15.187 CallCtrl:nSelectRouteReq [CM503013]: Call(74): No known route to target: [sip:[email protected]]

Any suggestions?

Kind regards

Rob

 

[archie]

Does your PBX runs on default SIP port 5060?

 

[future-data.biz]

Sure is....

5060 is the default SIP port on the 3CX server.

It only fails if the phone call is transferred from a Digital receptionist to the phone that is unregistered. The phone that is unregistered has its calls forwarding to the outside line.

The outbound rules for the voip provder are working (including to the number in the forward all calls).

Regards

Rob

 

[Ralph]

I am having the exact same problem.

I am set up as follows:
Caller dials an extension. If the extension doesnt pick up the caller is transferred to a digital receptionist which gives them the option to press 4 to reach a cell phone. When the caller presses 4 they are transferred to an unregistered extension that is set up to forward all calls to an outside number.

This worked fine in 3.0 and 3.1 but fails every time in 5.1. The caller hears "Call Transfer Failed" and then hears the DR prompts again.

Couple log entries:
22:33:50.517 Call::RouteFailed :[CM503014]: Call(15): Attempt to reach [sip:[email protected]] failed. Reason: Not Found
22:33:50.517 CallCtrl:nSelectRouteReq :[CM503013]: Call(15): No known route to target: [sip:[email protected]]

Please advise as soon as possible

Thank you

 

[Philco]

Seems to work fine here !!! V5.1 4128

For information, I have one line on a test set up which when called goes to a DR, if an extension is called from DR which is not registered and has forwarding to an outside number set, its works ok, this is whether I use a provider that supports invite or not..

Called the number from my mobile, at DR keyed in the extension number which is not registered and forwards to an outside PSTN number, the call established with two way audio no problems.

Phil

 

[Ralph]

Good morning,

The firewall test passes with no errors or warnings for all lines on the 3CX server.

1. Calling with an internal extension results in a successful transfer to an outside number when dialing the unregistered extension directly and when using the DR.

2. Calling the outside number directly from 3CX works.

3. When I call in from an outside line to the DR and I dial the unregistered extension directly the transfer to the outside number fails.

4. When I call in from an outside number to the DR and I dial an extension which is unavailable I am transferred to another DR where I choose to transfer to the unregistered extension the transfer to the outside number fails.

5. I have tried a variety of combinations of checkboxes under other options for the unregistered extension with no success as well.

Thanks again

 

[zyonee]

Hi!

You may want to take a look at this thread. It could have something to do with how the outgoing VoIP provider handles the call transfer and setup.

 

[Philco]

Just as a matter of interest Ralph, is your outside number a VOIP number on your LAN?? I have known this to fail in our tests, but to a real outside number VOIP or otherwise it seems to work.

Phil

 

[Ralph]

Good morning,

I have tried transfers to cell phones, and regular land lines from traditional phone providers with the same results.

Thanks again

 

[Ralph]

Thanks for the link.

The VoIP provider we are using is BroadVoice. Is there a problem with BrodVoice? They are one of the reccomended providers for 3CX aren't they?

Take care,

 

[Philco]

This is going to sound obvious, but looking at your posts I am guessing it could be an outbound rule the outside number is 'route not found'

In your log example, I can see the call to the extension fail, which is correct, but the route not found may suggest that the alternative has no route.


Shoot me down if you've alreday looked at his Ralph. Version 5 has outbound rules much different to 3 or 3.1

Phil

 

[Ralph]

Good morning,

Outbound rules seem to work fine because the transfer works fine when the call is from an internal extension?

Thanks again

 

[future-data.biz]

Hi All,

Just to confirm:

1. All outbound call rules on my config work (any outside numbers dialled works !!!)
2. When the outside call is transferred to DR and the user selects the option to transfer to the mobile, it fails. On all tests, it only fails when calls are transferred from a digital receptionist.

Tried with different providers and fails. I also spoke with my provider (http://www.voiceflex.com) and they support DTMF rfc 2833 only for DTMF support.

Any suggestions. (This is version 5.1 4128.)

Regards,

Rob

 

[Philco]

Well I dont know, I guess you've tried the backup then reinstall 3cx routine. Its the no known route that seems odd, but if your outbounds work on calling the extension and calling out then they are obviously ok.

This may also be accademic, but can you actually transfer the call from a extension to the unregistered extension, I guess so as your saying his only happens when transfering from DR.


Phil

 

[Philco]

Just a thought. Is the extension being called from the DR list, i.e. press one for so and so etc, What happens if you actually key in the full extension number while DR is anouncing. Does that work?


Phil

 

[Ralph]

Btw this also is the same for a registered extension that is set to forward all calls to an outside number.

 

[Philco]

We are all trying to build a picture of what you have here Ralph.

So transfer doesnt work even outside the DR either.

This sounding more and more like an outbound rule as I think here wold be more users having trouble.

Not knowing your outbound rules and how many you have, the order of them is important if you have some specifically for extensions and of course as its not a specific extension thats placing the outbound call , its the forward in the extension config which I dont think abides by the rules for that extension unless you use a prefix character to identify which outbound line to use in the outside number. Hope the latter bit wasnt confusing.

Phil

 

[future-data.biz]

The transfers fail when being transferred from a DR to an unregistered phone with all calls being forwarded to the outside number. They also fail if the phone is registered and has call forwarding to an outside number.

Regards

Rob

 

[future-data.biz]

Dear All,

The previous post by Phil actually helped me identify this issue. Here is how I did it.

1. The customer does not dial a prefix for outbound calls. All they do is dial a number and it must just connect. So, by following the outbound rules, I placed the call forwarding number in the field as per the outbound rule (IE - no prefix was used as none were configured in the outbound rules).

2. after testing loads of ways of doing things, I tried adding a 2nd outbound rule with a prefix. I used 9 as my prefix

3. In the unregistered extension number, I entered the call forarding number with a prefix and Hey Ho...It worked. It matched the outbound rule and dialled out...

I hope this helps anyone else who does not use prefix's for outbound calls (98% of people do, but it only takes one customer not to....)

Regards,

Rob

 

[Philco]

Sorry about the spooling mistooks in my last post, I'll blame my laptop and me not reading before posting.

Pleased it helped Rob, so I suspect it will help Ralph too.

In my test set up, I actually have extensions numbers that are used as speed dials (you probably do too) by using the unregistered or forward all, and these are to voip numbrs on varying voip providers, and to differentiate between them I use the prefix provision. To be honest, I'd hit your problem before as I configured a forward number and forgot to add the prefix, however, as I noticed it didnt work the first time I tried the unregistered extension, I immediately looked at the number I had entered and noticed I had not added the prefix, so didnt have the trouble you had.

Phew!!


Phil