Problem with Digital Recepcionist

[jlabuelo]

Good morning guys

I just created a Digital Recepcionist for my 3CX PBX. I can tell has been pretty easy and intuitive, but I have a problem.

I have created the rules, groups, extensions, and promt message, so when a client calls my PBX he hears the options and then pick the right one for him. Then the PBX system, redirects the call to the right group, and each extension starts ringing..... The problem comes when you want to pick the call up... I get the call disconnected.

If I dont use a digital recepcionist and I only use direct call routing... the call can be made perfectly...

This is the error message I get.

Time Function Message
13:32:12.665 CallMgr::Stack::thread [CM100002]: *!* Exception detected: Drop invalid 2543 response *!*
13:32:12.571 LineCfg::getInboundTarget [CM503011]: Inbound office hours' rule for LN:10000 forwards to DN:801
13:32:12.571 Call::Terminate [CM503008]: Call(83): Call is terminated
13:32:12.571 Call::Terminate [CM503008]: Call(83): Call is terminated
13:32:12.555 LineCfg::getInboundTarget [CM503011]: Inbound office hours' rule for LN:10000 forwards to DN:801
13:32:12.555 LineCfg::getInboundTarget [CM503011]: Inbound office hours' rule for LN:10000 forwards to DN:801
13:31:30.446 Call::RouteFailed [CM503014]: Call(83): Attempt to reach [sip:[email protected]] failed. Reason: Unsupported Media Type
13:31:30.430 CallLeg:nFailure [CM503003]: Call(83): Call to sip:[email protected] has failed; Cause: 415 Unsupported Media Type; from IP:192.168.2.20:5060
13:31:18.508 CallCtrl:nAnsweredCall [CM503002]: Call(83): Alerting sip:[email protected]:5060
13:31:18.087 CallCtrl:nSelectRouteReq [CM503015]: Call(83): Target is not registered: HuntGrp800:Ext.002
13:31:18.087 CallCtrl:nSelectRouteReq [CM503004]: Call(83): Calling: HuntGrp:800@[Dev:sip:[email protected]:5060]
13:31:18.087 CallCtrl:nSelectRouteReq [CM503010]: Making route(s) to [sip:[email protected]]
13:31:12.743 MediaServerReporting:TMFhandler [MS211000] C:83.1: 86.109.97.3:64408 is delivering DTMF using RTP payload (RFC2833). In-Band DTMF tone detection is disabled for this call segment.
13:31:10.274 CallLeg:nConfirmed Session 9517 of leg C:83.1 is confirmed
13:31:10.133 LineCfg::getInboundTarget [CM503011]: Inbound office hours' rule for LN:10000 forwards to DN:801
13:31:10.118 CallCtrl:nLegConnected [CM503007]: Call(83): Device joined: sip:[email protected]:5060

The error is just for incoming calls, as each extension can make calls perfectly.

Any ideas???

Thanks for your time guys!!

 

[SY]

What the phone are you using as extension 001?

 

[jlabuelo]

Hi

My phone at extension 001, is a isfotphone for my MackBook. As I said works normally if I redirect the incoming calls to extension 001 insteand of redirecting them to the Digital Recepcionist.

I have Parallels installed, and I could use the 3cx client phone, however this phone in my parallels doesnt not work good enough, people in other line hears a lot of echo, and the delay can be of two secs.

Do you think my isoftphone is causing this problem with the digital recepcionist?

Cheers

 

[SY]

Hi

My phone at extension 001, is a isfotphone for my MackBook. As I said works normally if I redirect the incoming calls to extension 001 insteand of redirecting them to the Digital Recepcionist.

I have Parallels installed, and I could use the 3cx client phone, however this phone in my parallels doesnt not work good enough, people in other line hears a lot of echo, and the delay can be of two secs.

Do you think my isoftphone is causing this problem with the digital recepcionist?

Cheers

If you are using 5.1. 4510 version of PBX then configure extension 001 as "PBX delivers audio"=on ("other options" at the bottom of page)
Should start to work.

It looks like there is the problem with the "transfer to 001" call scenario as well. Did you try it?

Thanks

P.S. I think it is better to rename this thread to "Problem with isoftphone" or "Isoftphone cannot receive call from Digital receptionist". It is interoperability issue and not related to DR functionality.

 

[Halea]

Stepen,
I am once again puzzled about your reply above!
This guy is telling you that his soft phone is able to receive a normal call but when it comes from the digital receptionist he cannot answer the call with the soft phone because of a problem somewhere in the food chain. The log shows "13:31:30.446 Call::RouteFailed [CM503014]: Call(83): Attempt to reach [sip:[email protected]] failed. Reason: Unsupported Media Type "
How did you reach the conclusion that it's a soft phone problem and not a PBX problem? Why there is no "Media Type" problem when the call is processed without the digital receptionist's intermediation. Why can't you be a bit more helpful to make him understand what's going on?
You care more about putting the blame on something other than your software, rather than providing useful feedback to your users.
Instead of scolding this user about how wrong he defined his subject matter if you used the same energy, time and gray matter to give two-sentences of real explanation about your point it would have been more convincing and make you look a bit more knowledgeable and less of a zealot.
Halea

 

[archie]

Halea,
you see, it is not question of blame. We have quite an experience with support of our system, and sometimes we can tell at glance where is the source of the problem. Neither me, nor Stepan could properly explain principals of media negotiations and offer/answer model. But all of that is properly explained in RFCs, so if one want to know basics - it's the place where to look. We encourage ppls to read RFCs, though we can not require it. And, in this case Stepan has pointed workaround, he told what to do to fix the problem. If it doesn't work - then let's go further, send us verbose logs, setup information, etc. But if it works - who cares why? We're eager to explain internals to those ppls who're really interested in it. But as a first step we just provide fixes. You should understand us, really. Also, please take into account that english is not our native language.