Digital receptionist question

Discussion in '3CX Phone System - General' started by jlh1, Oct 21, 2011.

Thread Status:
Not open for further replies.
  1. jlh1

    Joined:
    Oct 21, 2011
    Messages:
    8
    Likes Received:
    0
    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
     
  2. SY

    SY Well-Known Member
    3CX Support

    Joined:
    Jan 26, 2007
    Messages:
    1,825
    Likes Received:
    2
    It does not require any additional settings on PBX side.
    DTMF signals are processed by DR at any time (during playback and during pause)
     
    Stop hovering to collapse... Click to collapse... Hover to expand... Click to expand...
  3. jlh1

    Joined:
    Oct 21, 2011
    Messages:
    8
    Likes Received:
    0
    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
     
  4. SY

    SY Well-Known Member
    3CX Support

    Joined:
    Jan 26, 2007
    Messages:
    1,825
    Likes Received:
    2
    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
     
    Stop hovering to collapse... Click to collapse... Hover to expand... Click to expand...
  5. jlh1

    Joined:
    Oct 21, 2011
    Messages:
    8
    Likes Received:
    0
    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
     
  6. jlh1

    Joined:
    Oct 21, 2011
    Messages:
    8
    Likes Received:
    0
    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:1200@192.168.10.48 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:9999@127.0.0.1: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:9999@127.0.0.1:5060]
    08:55:05.448 [CM503002]: Call(1717): Alerting sip:9999@127.0.0.1:40600;rinstance=6b9110f75b6129f9
    08:55:05.345 [CM503003]: Call(1717): Call to sip:1200@192.168.10.48 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:9999@127.0.0.1:40600;rinstance=6b9110f75b6129f9]
    08:55:05.282 [CM503005]: Call(1717): Forwarding: Ext:Ext.9999@[Dev:sip:9999@127.0.0.1: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:1200@192.168.10.48:5060]
    08:54:45.366 [CM503002]: Call(1717): Alerting sip:1200@192.168.10.119:5060
    08:54:45.233 [CM503025]: Call(1717): Calling Ext:Ext.1200@[Dev:sip:1200@192.168.10.119:5060]
    08:54:45.179 [CM503004]: Call(1717): Route 1: Ext:Ext.1200@[Dev:sip:1200@192.168.10.119:5060]
    08:54:45.179 [CM503010]: Making route(s) to <sip:1200@127.0.0.1:5060>
    08:54:45.178 Refer: from=<sip:9001@127.0.0.1:5060>;tag=2a1e282e; to="YYYYYYYYYY:unknown-caller-name"<sip:XXXXXXXXXX@127.0.0.1:5060;nf=e>;tag=507c7244; RefTo=<sip:1200@127.0.0.1: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:9001@127.0.0.1:40600;rinstance=d4de4b9f6e6e11cd
    08:54:26.996 [CM503007]: Call(1717): Device joined: sip:10000@192.168.10.48: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:9001@127.0.0.1:5060]
    08:54:26.992 [CM503002]: Call(1717): Alerting sip:9001@127.0.0.1:40600;rinstance=d4de4b9f6e6e11cd
    08:54:26.843 [CM503025]: Call(1717): Calling Ext:Ext.9001@[Dev:sip:9001@127.0.0.1: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:9001@127.0.0.1:40600;rinstance=d4de4b9f6e6e11cd]
    08:54:26.798 [CM503010]: Making route(s) to <sip:9001@192.168.10.48: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:9001@192.168.10.48: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:10000@192.168.10.48: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:10000@192.168.10.48:5066;transport=udp>
    To: "YYYYYYYYYY"<sip:YYYYYYYYYY@192.168.10.48:5060>
    From: "unknown-caller-name"<sip:XXXXXXXXXX@192.168.10.48: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:10000@192.168.10.48:5060;transport=udp",algorithm=MD5
    Supported: replaces, 100rel
    User-Agent: Netborder Express Gateway/4.1.4
    Content-Length: 0
     
  7. leejor

    leejor Well-Known Member

    Joined:
    Jan 22, 2008
    Messages:
    10,869
    Likes Received:
    304
    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.
     
  8. jlh1

    Joined:
    Oct 21, 2011
    Messages:
    8
    Likes Received:
    0
    That sounds like what may be happening. Is there anything I can do?
     
  9. leejor

    leejor Well-Known Member

    Joined:
    Jan 22, 2008
    Messages:
    10,869
    Likes Received:
    304
    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?
     
  10. SY

    SY Well-Known Member
    3CX Support

    Joined:
    Jan 26, 2007
    Messages:
    1,825
    Likes Received:
    2
    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.
     
    Stop hovering to collapse... Click to collapse... Hover to expand... Click to expand...
  11. jlh1

    Joined:
    Oct 21, 2011
    Messages:
    8
    Likes Received:
    0
    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
     
  12. SY

    SY Well-Known Member
    3CX Support

    Joined:
    Jan 26, 2007
    Messages:
    1,825
    Likes Received:
    2
    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
     
    Stop hovering to collapse... Click to collapse... Hover to expand... Click to expand...
  13. jlh1

    Joined:
    Oct 21, 2011
    Messages:
    8
    Likes Received:
    0
    Will do, thanks for you help.

    John
     
  14. jlh1

    Joined:
    Oct 21, 2011
    Messages:
    8
    Likes Received:
    0
    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
     

    Attached Files:

  15. shenglu

    Joined:
    Nov 2, 2011
    Messages:
    2
    Likes Received:
    0
    I remember there and back, and the DTMF signal is not recognized, the caller tried to enter the numbers and DR is "talking" issue,..
     
    Stop hovering to collapse... Click to collapse... Hover to expand... Click to expand...
Thread Status:
Not open for further replies.