Blind transfers from callers using area code going to VM

[Mike-2Gen]

Hello gurus,

We stumbled across a strange issue that I was hoping we could get some feedback about (searched the forums but couldn't find anything similar):

We've migrated to v18 recently (but issue was present while still using v16).

If a caller dials our number without the area code, we can answer the call and do a blind xfer to the end recipient, but if they dial our number WITH the area code, blind xfers get sent directly to VM of the end recipient. Attended transfers work for either / or. Only blind transfers give this issue.

Anyone encounter anything like this? Any feedback would be appreciated.

Thanks in advance,

Mike

 

[VasilisV_3CX]

Hi @Mike-2Gen,

If a caller dials our number without the area code, we can answer the call and do a blind xfer to the end recipient, but if they dial our number WITH the area code, blind xfers get sent directly to VM of the end recipient.

In your tests, who is the end recipient? Is it an internal extension?

 

[leejor]

I'm assuming that the local provider allows both 7 and 10 digit dialing.

Are you using a SIP provider, or a gateway?

Are you able to replicate the issue from a landline?

Are these numbers DIDs?

Look at the 3CX Activity Log (may require setting to Verbose), to see what is different for each type (working and non working) of call. that may also give a clue as to what might be causing the call to go to VM.

There should only be two variables on the incoming calls ...the caller ID, and the DID number.

 

[Mike-2Gen]

Hi V & L,

Thanks for the replies.

Tests were performed from various outside lines; both landlines and mobiles from inside our area code and outside our area code. From inside our area code, tested using with and without the area code, and (obviously) from outside our area code, using our area code and for the most part any calls coming in where the caller had to dial the area code, the blind xfer directs it to VM. (to be more specific, when the blind xfer happens, it rings the end recipient for a 1/4 -1/2 ring then goes to VM) Again, Att Xfer, no issue. And yes, the end recipient would be an internal extension.

Our calls flow from DID line to internal RG which contain our staff extensions. We use SIP and yes, calls are going to DID lines specified in SIP trunk. I have NOT tested some of our other DID's yet, as our clients only call the main number, which is where we noticed this issue. I would assume the other DID's will act similarly but I will test those as well.

Yeah, I looked though our Activity log and nothing related to this issue in log BUT verbose logging wasn't set (yet), I starting looking into it yesterday as a "pet" project when I had free time, didn't realise until yesterday the extent of the issue (just thought it was my co-worker needing a little bit more training. LOL) I'll test later today with verbose logging on an see what I can find.

I'll test later today after I get back from client's site, I'll test a couple other DID's with verbose logging and post any results I can find. My biggest weakness with 3CX is trying to make sense of what the logs are actually telling me. ;-)

Thanks again and will update as soon as possible... again, any feedback is most welcome.

 

[VasilisV_3CX]

I'll test later today with verbose logging on an see what I can find.

@Mike-2Gen Do let me know what you find, if you need us to go over the logs feel free to let me know.

Also, can you let me know how you've setup your DIDs in the SIP Trunk DIDs section?