Digital receptionist question

[jlh1]

I have an unattended line that is answered by a digital receptionist.
As the greeting is read the caller is given several options to get directed to the extension that they want.

After the option are read there is a pause for the caller to dial. If the caller dials the option they want
During the pause they get directed to that option.

Example “If you know your parties extension dial it now” If they dial the extension during the pause the call get forwarded to the extension.

If the caller has called before and knows what to dial, and does not wait for the pause. They get looped back to the beginning of the message.

Is there a setting that allows the caller to dial the extension at any time even when the message is being read.

Thanks for you help

John

 

[SY]

It does not require any additional settings on PBX side.
DTMF signals are processed by DR at any time (during playback and during pause)

 

[jlh1]

Thank you for your response.

I’m not sure were or what to check then, I do have a problem of the caller looping back to the beginning of the DR message if they do not wait till the pause in the message to enter the extension that they would like to be directed to.

Is there a log that I can check to see what extension was dialed or what dtmf codes were registered?

jlh1

 

[SY]

http://www.3cx.com/forums/forum-rules-read-to-get-answers-93.html

Could you please specify equipment/VoIP provider which delivers DTMFs in your case?

Thanks

 

[jlh1]

We use two PRI lines that are provided by LightPath.

I have called their support line and they tell me that they just provide the pipe used by the caller and do not provide any DTMF signals.

In our 3cx(ver 10 sp3) system we use a Sangoma PRI card.

Thanks
Jlh1

 

[jlh1]

Here is the logfile with the error

I think the line that shows the error.
08:55:05.345 [CM503003]: Call(1717): Call to sip:[email protected] has failed; Cause: 487 Request Terminated; from IP:192.168.10.119:5060

The caller called our unattended line and dialed the ext. 1200 while the prompt was being played and was redirected to the outgoing message again.

It does not happen all the time but we can regularly create the error using an ATT cell phone.
It has been reported that that callers that have COX cable for their phones can also create it.

If these users wait till the pause in the message they can get directed to the correct extension.
I replaced the callers phone number with XXXXXXXXXX
and I replace the number that they were calling wiht YYYYYYYYYY

08:55:46.382 Currently active calls - 1: [1714]
08:55:25.969 [CM503008]: Call(1717): Call is terminated
08:55:16.380 Currently active calls - 2: [1714,1717]
08:55:05.556 [MS210005] C:1717.4:Answer provided. Connection(proxy mode):127.0.0.1:7026(7027)
08:55:05.555 [MS210001] C:1717.1:Answer received. RTP connection[unsecure]: 192.168.10.48:16748(16749)
08:55:05.554 Remote SDP is set for legC:1717.1
08:55:05.453 [CM503007]: Call(1717): Device joined: sip:[email protected]:40600;rinstance=6b9110f75b6129f9
08:55:05.451 [MS210004] C:1717.1:Offer provided. Connection(proxy mode): 192.168.10.48:7020(7021)
08:55:05.450 [MS210000] C:1717.4:Offer received. RTP connection: 127.0.0.1:40662(40663)
08:55:05.449 Remote SDP is set for legC:1717.4
08:55:05.448 [CM505001]: Ext.9999: Device info: Device Identified: [Man: 3CX Ltd.;Mod: Voice Mail Menu;Rev: General] Capabilities:[reinvite, replaces, able-no-sdp, recvonly] UserAgent: [3CX Voice Mail Menu] PBX contact: [sip:[email protected]:5060]
08:55:05.448 [CM503002]: Call(1717): Alerting sip:[email protected]:40600;rinstance=6b9110f75b6129f9
08:55:05.345 [CM503003]: Call(1717): Call to sip:[email protected] has failed; Cause: 487 Request Terminated; from IP:192.168.10.119:5060
08:55:05.336 [CM503025]: Call(1717): Calling Ext:Ext.9999@[Dev:sip:[email protected]:40600;rinstance=6b9110f75b6129f9]
08:55:05.282 [CM503005]: Call(1717): Forwarding: Ext:Ext.9999@[Dev:sip:[email protected]:40600;rinstance=6b9110f75b6129f9]
08:54:45.367 [CM505001]: Ext.1200: Device info: Device Identified: [Man: Linksys;Mod: SPA Series;Rev: General] Capabilities:[reinvite, no-replaces, able-no-sdp, recvonly] UserAgent: [Linksys/SPA942-6.1.5(a)] PBX contact: [sip:[email protected]:5060]
08:54:45.366 [CM503002]: Call(1717): Alerting sip:[email protected]:5060
08:54:45.233 [CM503025]: Call(1717): Calling Ext:Ext.1200@[Dev:sip:[email protected]:5060]
08:54:45.179 [CM503004]: Call(1717): Route 1: Ext:Ext.1200@[Dev:sip:[email protected]:5060]
08:54:45.179 [CM503010]: Making route(s) to <sip:[email protected]:5060>
08:54:45.178 Refer: from=<sip:[email protected]:5060>;tag=2a1e282e; to="YYYYYYYYYY:unknown-caller-name"<sip:[email protected]:5060;nf=e>;tag=507c7244; RefTo=<sip:[email protected]:5060>
08:54:44.998 [MS210003] C:1717.2:Answer provided. Connection(transcoding mode[unsecure]):127.0.0.1:7022(7023)
08:54:44.998 [MS210001] C:1717.1:Answer received. RTP connection[unsecure]: 192.168.10.48:16748(16749)
08:54:44.997 Remote SDP is set for legC:1717.1
08:54:44.894 [MS210002] C:1717.1:Offer provided. Connection(transcoding mode): 192.168.10.48:7020(7021)
08:54:44.894 [MS210000] C:1717.2:Offer received. RTP connection: 127.0.0.1:40660(40661)
08:54:44.893 Remote SDP is set for legC:1717.2
08:54:44.378 Currently active calls - 2: [1714,1717]
08:54:27.109 Session 474503 of leg C:1717.1 is confirmed
08:54:26.997 [CM503007]: Call(1717): Device joined: sip:[email protected]:40600;rinstance=d4de4b9f6e6e11cd
08:54:26.996 [CM503007]: Call(1717): Device joined: sip:[email protected]:5066
08:54:26.995 [MS210005] C:1717.1:Answer provided. Connection(proxy mode):192.168.10.48:7020(7021)
08:54:26.994 [MS210001] C:1717.2:Answer received. RTP connection[unsecure]: 127.0.0.1:40660(40661)
08:54:26.993 Remote SDP is set for legC:1717.2
08:54:26.992 [CM505001]: Ext.9001: Device info: Device Identified: [Man: 3CX Ltd.;Mod: 3CX IVR;Rev: General] Capabilities:[reinvite, replaces, able-no-sdp, recvonly] UserAgent: [3CX IVR] PBX contact: [sip:[email protected]:5060]
08:54:26.992 [CM503002]: Call(1717): Alerting sip:[email protected]:40600;rinstance=d4de4b9f6e6e11cd
08:54:26.843 [CM503025]: Call(1717): Calling Ext:Ext.9001@[Dev:sip:[email protected]:40600;rinstance=d4de4b9f6e6e11cd]
08:54:26.843 [MS210004] C:1717.2:Offer provided. Connection(proxy mode): 127.0.0.1:7022(7023)
08:54:26.798 [CM503004]: Call(1717): Route 1: Ext:Ext.9001@[Dev:sip:[email protected]:40600;rinstance=d4de4b9f6e6e11cd]
08:54:26.798 [CM503010]: Making route(s) to <sip:[email protected]:5060>
08:54:26.797 [MS210000] C:1717.1:Offer received. RTP connection: 192.168.10.48:16748(16749)
08:54:26.797 Remote SDP is set for legC:1717.1
08:54:26.795 [CM503001]: Call(1717): Incoming call from XXXXXXXXXX@(Ln.10000@Lightpath) to <sip:[email protected]:5060>
08:54:26.790 [CM503012]: Inbound any hours rule (YYYYYYYYYY) for 10000 forwards to DN:9001
08:54:26.789 Looking for inbound target: called=YYYYYYYYYY; caller=XXXXXXXXXX
08:54:26.788 [CM500002]: Info on incoming INVITE:
INVITE sip:[email protected]:5060;transport=udp SIP/2.0
Via: SIP/2.0/UDP 192.168.10.48:5066;branch=z9hG4bK78843af6-ff08-11e0-8c21-b5182f91bcef;rport=5066
Max-Forwards: 70
Contact: <sip:[email protected]:5066;transport=udp>
To: "YYYYYYYYYY"<sip:[email protected]:5060>
From: "unknown-caller-name"<sip:[email protected]:5066>;tag=pxip-callid-1319547266-735786-11600-2967ds-6ee7-529faccb
Call-ID: 787f7ff2-ff08-11e0-9e30-8fc24c0a9d68@APT3CX
CSeq: 4986 INVITE
Expires: 179
Allow: INVITE, ACK, BYE, CANCEL, NOTIFY, INFO, OPTIONS, REFER
Date: Tue, 25 Oct 2011 12:54:26 GMT
Proxy-Authorization: Digest username="10000",realm="3CXPhoneSystem",nonce="414d535c04b7428293:012fd3b3363ebb543e0604846574e485",response="d26a6b891e3c96eb48a51716891d26c8",uri="sip:[email protected]:5060;transport=udp",algorithm=MD5
Supported: replaces, 100rel
User-Agent: Netborder Express Gateway/4.1.4
Content-Length: 0

 

[leejor]

Many issues (especially intermittent) involving DTMF are a result of the short duration tone(s) that many devices now send. That in combination with a low(er) level can result in unintended behaviour. I remember an issue cropping up a while back, with DTMF not being recognised properly when callers were trying to enter numbers while the DR was "talking", it seemed to work fine when "she" was silent.

 

[jlh1]

That sounds like what may be happening. Is there anything I can do?

 

[leejor]

If your PRI card has any Gain settings, you might want to experiment with those, after making a note the original settings. There is nothing (obviously) that can be done about short duration tones. If, as you say, a lot of problems are from coming from one provider (cable company), it may be something to do with their transport or compression methods that are causing just enough distortion of the DTMF tones to be an issue.

Have you checked to be sure that you have the latest firmware in the Sangoma PRI card?

 

[SY]

That sounds like what may be happening. Is there anything I can do?

You can open support ticket if you have support contract. (recommended)
If not then you can post 3CXIvrServer.trace.log which tells about the call. DTMF signals are visible there.

 

[jlh1]

The log is 24 meg is there a way to upload it. I tried the upload feature but it just keeps bring me to this screen.

John

 

[SY]

The log is 24 meg is there a way to upload it. I tried the upload feature but it just keeps bring me to this screen.

John

Sorry, nobody will dig in 24 mbytes.
You can restart "3CX digital receptionist" service and then replicate a problematic call.
The log will be quite short.

Thanks

 

[jlh1]

Will do, thanks for you help.

John

 

[jlh1]

Good Morning.

I have collected the files from the Sangoma network express, and the 3cx system.

I restarted the Digital receptionist on the 3cx system. Then I had the caller reproduce the problem.

She made two calls to the unattended receptionist. Both times the caller dialed extension 1200.

The first time the caller dialed the extension while the digital receptionist was talking this call was looped back to the digital assistant.

The second call the caller waited to the digital receptionist paused then dialed the extension this one was correctly forwarded.

I have attached 3 files the two Sangoma logged calls and the 3cxivrserver.trace log file.

Successful call routed to the correct extension, log file 1319804741-789516-12158-4013
starting at line number 293 shows the DTMF signal received.

Unsuccessful call routed back to the digital receptionist, log files 13119804772-822291-12022-4015 starting at line number 298 shows the DTMF signal received.

Both time the Sangoma cared received the correct extension dialed by the caller 1200.



If I look at the 3cxivrserver.trace log file at the times that were recorded in the Sangoma call log for both the successful and unsuccessful call I can see that the 3CX system the corresponding calls.

On the successful call,3cxivrserver.trace, line number 839 in the log file the DTMF is correct 1200
On the unsuccessful call, 3cxivrserver.trace,Line number 320 in the log file the DTMF is incorrect 1120

When I check the call logs for these calls in the Sangoma logs the Sangoma network express card receives the DTMF correctly.

***A note routing back to the digital receptionist is because the perceived extension does not exist in our phone system, if the perceived extension exist in our phone system the call will be routed to that extension. This will prompt a service call from users saying that the phone system it sending call to the wrong extension


I have replace the caller’s phone number with xxxxxxxxxx, and I have replace our phone number with yyyyyyyyyy in the logs

 

[shenglu]

I remember there and back, and the DTMF signal is not recognized, the caller tried to enter the numbers and DR is "talking" issue,..