makecall.php outboundrules and call log issues (BUG)

Discussion in '3CX Phone System - General' started by silentfun, Jan 10, 2008.

  1. silentfun

    silentfun Member

    Joined:
    Dec 11, 2006
    Messages:
    364
    Likes Received:
    0
    I find this a very nice tool from 3cx and i like to use it for callbackbutton and autodialing on webpages for CRM workflows and for oneclick dial list that manage bussiness wide phonebooks.

    I have tested a bit around with this feature and found some problems.

    1. It don´t use the outboundrules that are defined for the extension if you use forward all to use it as a hotline button to your cellphone.

    2. i can not find the calls in the call log´s. There is only a entry like this:
    # Date Source Destination Call Result Duration
    46 2008-01-10 15:28:12 555 No Answer
    47 2008-01-10 15:29:44 555 No Answer
    48 2008-01-10 15:41:34 555 Failed
    49 2008-01-10 15:47:00 555 No Answer
    50 2008-01-10 15:48:16 555 No Answer
    51 2008-01-10 15:50:15 555 No Answer
    52 2008-01-10 15:53:00 555 No Answer
    53 2008-01-10 15:53:32 555 No Answer
    54 2008-01-10 16:56:11 555 No Answer
    55 2008-01-10 16:57:18 555 No Answer
    56 2008-01-10 16:58:35 555 No Answer (This was connectet)

    but you find not a entry like 555 to 0123456666


    Andy

    PS: If anyone want to test this please give me a call by pressing the link next the callback image and enter you phone number in that form. if you want a call back outside germany please use international format like this ->>> 00442036666 for a number in UK. if you get no call try again later.

    [​IMG]http://www.pc-force.de/call.aspx
     
  2. silentfun

    silentfun Member

    Joined:
    Dec 11, 2006
    Messages:
    364
    Likes Received:
    0
    i have found one more problem

    when my ext 555 is busy and i initiate a new make call try to do something with the forward all number of my ext 298 (look at the bolded part)

    for example http://localhost:5481/make_call.php?extnum=555&vmpin=456&to=0172123456

    Time Function Message

    22:27:19.582 MediaServerReporting::DTMFhandler [MS211000] C:94.1: 87.230.126.104:11956 is delivering DTMF using RTP payload (RFC2833). In-Band DTMF tone detection is disabled for this call segment.
    22:27:12.348 CallLeg::eek:nConfirmed Session 15763 of leg C:94.1 is confirmed
    22:27:12.239 Call::Terminate [CM503008]: Call(95): Call is terminated
    22:27:12.223 Call::Terminate [CM503008]: Call(95): Call is terminated
    22:27:12.208 Call::RouteFailed [CM503014]: Call(95): Attempt to reach [sip:555@99.88.25.24:5060] failed. Reason: Not Registered
    22:27:12.192 Call::RouteFailed [CM503014]: Call(95): Attempt to reach [sip:555@99.88.25.24:5060] failed. Reason: Not Registered
    22:27:12.192 CallCtrl::eek:nRerouteReq [CM503015]: Call(95): Target is not registered: "066207924371"[sip:066207924371@99.88.25.24:5060]
    22:27:12.161 MediaServerReporting::SetRemoteParty [MS210003] C:94.1:Answer provided. Connection(transcoding mode):99.88.25.24:9012(9013)
    22:27:12.161 CallLeg::eek:nFailure [CM503003]: Call(95): Call to sip:555@99.88.25.24 has failed; Cause: 486 Busy; warning: detected NAT type is full cone; from IP:87.230.126.104
    22:27:12.020 MediaServerReporting::SetRemoteParty [MS210002] C:95.2:Offer provided. Connection(transcoding mode): 99.88.25.24:9014(9015)
    22:27:11.833 CallCtrl::eek:nSelectRouteReq [CM503004]: Call(95): Calling: Ext:555@[Dev:sip:555@99.230.126.104:44752;transport=udp;user=phone]
    22:27:11.833 CallCtrl::eek:nSelectRouteReq [CM503010]: Making route(s) to [sip:555@99.88.25.24:5060]
    22:27:11.754 CallCtrl::eek:nIncomingCall [CM503001]: Call(95): Incoming call from Make Call to [sip:555@99.88.25.24:5060]

    so why first >>>Cause: 486 Busy
    and then twice >>>Reason: Not Registered

    and why this warning ? >>>warning: detected NAT type is full cone; from IP:99.230.126.104
     
  3. silentfun

    silentfun Member

    Joined:
    Dec 11, 2006
    Messages:
    364
    Likes Received:
    0
    No one else with this issue ? Perhaps it depends on me.

    Andy
     
  4. SY

    SY Well-Known Member
    3CX Support

    Joined:
    Jan 26, 2007
    Messages:
    1,821
    Likes Received:
    1
    Andy,

    Please specify your VoIP provider and/or equipment you are using. makecall.php should work correctly with destinations that are fully compatible with RFC 3264.
    Sure,I may be wrong :) . So, could you please send me the logs for described situation?

    Thanks
     
  5. silentfun

    silentfun Member

    Joined:
    Dec 11, 2006
    Messages:
    364
    Likes Received:
    0
    Hi

    I use latest V5
    sipgate.de
    Grandstream GXP-2020

    basicly makecall is running but at least to things are buggy

    1. no log if you have a made a call via makecall

    2. if the extension is already in a call by makecall the pbx try to conect to a outside number that have nothing to do with the makecall you have started as 2. proccess.

    the log is already posted for the 2. issue

    and also the calllog for the 1. issue

    3. cann you tell me witch outboundrule use for outbound calls? if i want that he can do a call i have to define a rule that is aplicable to every extension that is bad practice. Or can i define a outboundrule where i can set extension="makecall" ? if that is running it is perfect. but atm i can not set extension ="makecall"

    the thing i realy find usefull is on Grandstream GXP-2020 i can see "makecall" as caller id.

    so if you can help me with this issues i try all to assist you.


    Andy
     
  6. archie

    archie Well-Known Member
    3CX Support

    Joined:
    Aug 18, 2006
    Messages:
    1,309
    Likes Received:
    0
    Re:

    Because your Ext.555 is busy, and, I suspect, it has definedf forwarding rule for Busy case to the number 06620792437. And it seems the outbound rule triggered by this number is not valid, or points to unregistered line.

    It's warning from phone (XLite, yes?) which means you have such settings of NAT that it couldn't work properly for external connection. (Actually, nobody can make reliable external SIP communications being behind full cone NAT)
     
  7. silentfun

    silentfun Member

    Joined:
    Dec 11, 2006
    Messages:
    364
    Likes Received:
    0
    Re: Re:

    thanx for your fast answer

    There is no "Destination Unreachable / Forwarding >>>" rule set for ext. 555
    The only extension that have this rule is 298 - and the magic is if i edit the forwarding target for 298 he will instant use this for 555 if a second incomming for 555 via makecall. i have tested this. if you want i give you the adminname and password for the pbx that you can verify this.

    no i use only GXP-2020 and ML-220 but this log entry was for a GXP-2020

    Andy
     
  8. archie

    archie Well-Known Member
    3CX Support

    Joined:
    Aug 18, 2006
    Messages:
    1,309
    Likes Received:
    0
    Could you please delete settings for Ext.298, try, and than create it again and try again?
     
  9. silentfun

    silentfun Member

    Joined:
    Dec 11, 2006
    Messages:
    364
    Likes Received:
    0
    yes this solved the problem with the issue that the PBX tryed to reach a forward of the other extension.

    but there is still the Call logs that don´t show the calles initiated by makecall.php

    and how can i build a outbound rule for makecall ? it doesn´t use the rule of the extension the call was initiated for.

    hope you can help with this too


    Andy
     

Share This Page