Dismiss Notice
We would like to remind you that we’re updating our login process for all 3CX forums whereby you will be able to login with the same credentials you use for the Partner or Customer Portal. Click here to read more.

good news - looks like DR "call failed" has been fixed

Discussion in '3CX Phone System - General' started by Nick Galea, Feb 7, 2008.

Thread Status:
Not open for further replies.
  1. Nick Galea

    Nick Galea Site Admin

    Joined:
    Jun 6, 2006
    Messages:
    1,971
    Likes Received:
    278
    Thanks, good to hear that!

    We have identified another issue with DR - the 'no action' on timeout does not disconnect the call and can be the cause of calls which remain in connected status. We are fixing it today, for upload tomorrow or else monday. This will not be requiring a re install but will be pushing up with the install updates function.
     
    Stop hovering to collapse... Click to collapse... Hover to expand... Click to expand...
  2. Hoover87

    Joined:
    Nov 12, 2007
    Messages:
    20
    Likes Received:
    0
    ok, so how do you get the DR to transfer? My DR fails with transfers to anything, registered or not. I've tried both 5.0 and 5.1. What amI missing?
     
  3. SY

    SY Well-Known Member
    3CX Support

    Joined:
    Jan 26, 2007
    Messages:
    1,825
    Likes Received:
    2
    I have a silly question. What port is configured for SIP?

    Thanks
     
    Stop hovering to collapse... Click to collapse... Hover to expand... Click to expand...
  4. Hoover87

    Joined:
    Nov 12, 2007
    Messages:
    20
    Likes Received:
    0
    Hi SY,

    Not such a silly question, it is set to port 5063.

    I set it to 5060 after reading your question and it worked. Switched it back to 5063 and it stopped working.

    Thoughts?

    Thanks.
     
  5. Hoover87

    Joined:
    Nov 12, 2007
    Messages:
    20
    Likes Received:
    0
    It looks like the DR is trying to transfer the call to 101@127.0.0.1. I would imagine that if it instead transfered to 101@3cx.localdomain.com:5063 the transfer would work.
     
  6. landfiets

    landfiets New Member

    Joined:
    Jul 17, 2007
    Messages:
    243
    Likes Received:
    0
    EXACTLY. That is what I tried to explain before in several postings here.
    The way it transfers looks funny. I think the local "DHCP gotten" IP should be there instead of the real localhost ip.
    Can someone confirm?
     
    Stop hovering to collapse... Click to collapse... Hover to expand... Click to expand...
  7. SY

    SY Well-Known Member
    3CX Support

    Joined:
    Jan 26, 2007
    Messages:
    1,825
    Likes Received:
    2
    It is known (registered) issue. Could you please change port to the 5060 for awhile and try to check how DR works with transfers and transfer related functions.

    Thanks a lot for your information
     
    Stop hovering to collapse... Click to collapse... Hover to expand... Click to expand...
  8. SY

    SY Well-Known Member
    3CX Support

    Joined:
    Jan 26, 2007
    Messages:
    1,825
    Likes Received:
    2
    What looks funny in the way it transfers?

    Thanks
     
    Stop hovering to collapse... Click to collapse... Hover to expand... Click to expand...
  9. Hoover87

    Joined:
    Nov 12, 2007
    Messages:
    20
    Likes Received:
    0
    Sy,

    As I mentioned above, after changing to 5060 call transfer works. This however is not a good solution for me because I have other devices using 5060, hence the reason I changed it to 5063.

    127.0.0.1 shouldn't be used as the SIP domain in call transfers unless it can specify the correct port to use, and I think this is similar to the point that 'landfiets' is getting at. It would make more since to do an internal DNS or DNS SRV lookup so that the DR transfers the call to the correct SIP domain and port. If you look at the trace log this is how the incoming call is handled as it is transfered to the DR, but the DR apparently doesn't know how to do the same.
     
  10. Hoover87

    Joined:
    Nov 12, 2007
    Messages:
    20
    Likes Received:
    0
    Okay, I looked at the trace again, it doesn't work exactly as I said with regards to the DNS lookups, but it might not be a bad idea to go that route anyway.

    In any case, below is a portion of my trace log. The point is that all call transfers are either to localdomain:5063 or 192.168.1.100:5063. The DR however is using 127.0.0.1. This should be either the localdomain or IP address as mentioned earlier, not 127.0.0.1.

    15:47:08.093|.\CallCtrl.cpp(100)|Log2||CallCtrl::eek:nIncomingCall:[CM503001]: Call(2): Incoming call from 3602234758@(Ln.10000@IPTel) to <sip:801@192.168.1.100:5063:5063><br>
    15:47:08.140|.\Line.cpp(326)|Log2||LineCfg::getInboundTarget:[CM503011]: Inbound out-of-office hours' rule for LN:10000 forwards to DN:801<br>
    15:47:08.140|.\CallEvents.cpp(75)|Trace5||FireStatusEvent:Fire event: Calling; DN 10000<br>
    15:47:08.140|.\Line.cpp(945)|Log2||Line::printEndpointInfo:[CM505003]: Provider:[IPTel] Device info: Device Not Identified: User Agent not matched; Capabilities:[reinvite, replaces, able-no-sdp, recvonly] UserAgent: [Asterisk PBX] Transport: [sip:192.168.1.100:5063]<br>
    15:47:08.140|.\CallCtrl.cpp(163)|Trace5||CallCtrl::eek:nOfferSDP:OnOffer from "FERNDALE WA"<sip:3602234758@3cx.ketchumit.local:5063><br>
    15:47:08.140|.\CallLeg.cpp(614)|Log5||CallLeg::setRemoteSdp:Remote SDP is set for legC:2.1<br>
    15:47:08.140|.\Call.cpp(260)|Trace5||Call::Invite:Call::Invite<br>
    15:47:08.140|.\CallCtrl.cpp(210)|Trace5||CallCtrl::eek:nSelectRouteReq:SelectRouteReq<br>
    15:47:08.140|.\CallCtrl.cpp(225)|Log3||CallCtrl::eek:nSelectRouteReq:[CM503010]: Making route(s) to <sip:801@192.168.1.100:5063:5063><br>
    15:47:08.156|.\CallCtrl.cpp(305)|Log2||CallCtrl::eek:nSelectRouteReq:[CM503004]: Call(2): Calling: IVR:801@[Dev]<br>
    15:47:08.156|.\Call.cpp(250)|Trace5||Call::MakeCall:MakeCall from C:2.1 to IVR:801@[Dev]<br>
    15:47:08.156|.\Call.cpp(120)|Trace5||Call::addLeg:Adding leg C:0.0<br>
    15:47:08.156|.\MSInterface.cpp(655)|Trace5||??:MSLogReports<br>
    15:47:08.156|.\SLServer.cpp(374)|Log5|MediaServer|MediaServerReporting::SetRemoteParty:[MS210000] C:2.1:Offer received. RTP connection: 213.192.59.91:53070(53071)<br>
    15:47:08.171|.\Call.cpp(125)|Trace5||Call::addLeg:Legs count: 2<br>
    15:47:08.171|ServerInviteSession.cxx(91)|Trace5|Resip|::ResipLogger:UAS_Offer: provisional(180)<br>
    15:47:08.171|InviteSession.cxx(2046)|Trace5|Resip|::ResipLogger:Transition UAS_Offer -> UAS_EarlyOffer<br>
    15:47:08.171|.\InviteADS.cpp(255)|Trace5||InviteADS::eek:nReadyToSend:SendMsg from <sip:85336@iptel.org>;tag=ae62e05a to "FERNDALE WA"<sip:3602234758@66.54.140.46>;tag=as779fdd1d<br>
    15:47:08.187|.\CallCtrl.cpp(406)|Trace5||CallCtrl::eek:nLegConnected:eek:nLegConnected<br>
    15:47:08.187|.\CallCtrl.cpp(419)|Log2||CallCtrl::eek:nLegConnected:[CM503007]: Call(2): Device joined: sip:<br>
    15:47:08.187|.\CallEvents.cpp(75)|Trace5||FireStatusEvent:Fire event: Connected; DN 801<br>
    15:47:09.031|.\Route.cpp(31)|Trace5||??:~Route=Dev:local<br>
    15:47:09.031|.\Target.cpp(25)|Trace5||??:~Target=IVR:801@[]<br>
    15:47:09.031|ServerInviteSession.cxx(251)|Trace5|Resip|::ResipLogger:UAS_EarlyOffer: provideAnswer<br>
    15:47:09.031|InviteSession.cxx(2046)|Trace5|Resip|::ResipLogger:Transition UAS_EarlyOffer -> UAS_EarlyProvidedAnswer<br>
    15:47:09.031|ServerInviteSession.cxx(443)|Trace5|Resip|::ResipLogger:UAS_EarlyProvidedAnswer: accept(200)<br>
    15:47:09.031|InviteSession.cxx(2046)|Trace5|Resip|::ResipLogger:Transition UAS_EarlyProvidedAnswer -> UAS_Accepted<br>
    15:47:09.031|.\InviteADS.cpp(255)|Trace5||InviteADS::eek:nReadyToSend:SendMsg from <sip:85336@iptel.org>;tag=ae62e05a to "FERNDALE WA"<sip:3602234758@66.54.140.46>;tag=as779fdd1d<br>
    15:47:09.031|.\InviteADS.cpp(175)|Trace5||InviteADS::eek:nConnected:Connected(UAS) from "FERNDALE WA"<sip:3602234758@66.54.140.46>;tag=as779fdd1d to <sip:85336@iptel.org>;tag=ae62e05a<br>
    15:47:09.031|.\CallLeg.cpp(294)|Trace5||CallLeg::eek:nConnected:Session 21 of leg C:2.1 is connected<br>
    15:47:09.031|.\CallCtrl.cpp(406)|Trace5||CallCtrl::eek:nLegConnected:eek:nLegConnected<br>
    15:47:09.031|.\CallCtrl.cpp(419)|Log2||CallCtrl::eek:nLegConnected:[CM503007]: Call(2): Device joined: sip:3602234758@66.54.140.46<br>
    15:47:09.031|.\MSInterface.cpp(655)|Trace5||??:MSLogReports<br>
    15:47:09.031|.\SLServer.cpp(374)|Log5|MediaServer|MediaServerReporting::SetRemoteParty:[MS210003] C:2.1:Answer provided. Connection(transcoding mode):71.231.50.128:9002(9003)<br>
    15:47:09.093|.\Line.cpp(326)|Log2||LineCfg::getInboundTarget:[CM503011]: Inbound out-of-office hours' rule for LN:10000 forwards to DN:801<br>
    15:47:09.093|.\CallEvents.cpp(75)|Trace5||FireStatusEvent:Fire event: Connected; DN 10000<br>
    15:47:09.484|DialogUsageManager.cxx(1190)|Trace5|Resip|::ResipLogger:Got: SipReq: ACK 3602234758@71.231.50.128:5063 tid=e6b187e61708d644f18303146eee7116 cseq=ACK contact=3602234758@66.54.140.46 / 102 from(wire)<br>
    15:47:09.484|DialogUsageManager.cxx(1516)|Trace5|Resip|::ResipLogger:Handling in-dialog request: SipReq: ACK 3602234758@71.231.50.128:5063 tid=e6b187e61708d644f18303146eee7116 cseq=ACK contact=3602234758@66.54.140.46 / 102 from(wire)<br>
    15:47:09.484|ServerInviteSession.cxx(684)|Trace5|Resip|::ResipLogger:dispatchAccepted: SipReq: ACK 3602234758@71.231.50.128:5063 tid=e6b187e61708d644f18303146eee7116 cseq=ACK contact=3602234758@66.54.140.46 / 102 from(wire)<br>
    15:47:09.484|InviteSession.cxx(2046)|Trace5|Resip|::ResipLogger:Transition UAS_Accepted -> InviteSession::Connected<br>
    15:47:09.484|.\InviteADS.cpp(190)|Trace5||InviteADS::eek:nConnectedConfirmed:ConnCfmd from "FERNDALE WA"<sip:3602234758@66.54.140.46>;tag=as779fdd1d to <sip:85336@iptel.org>;tag=ae62e05a<br>
    15:47:09.484|.\CallLeg.cpp(325)|Log5||CallLeg::eek:nConfirmed:Session 21 of leg C:2.1 is confirmed<br>
    15:47:16.656|.\MSInterface.cpp(655)|Trace5||??:MSLogReports<br>
    15:47:16.656|.\SLServer.cpp(381)|Log2|MediaServer|MediaServerReporting::DTMFhandler:[MS211000] C:2.1: 213.192.59.91:53070 is delivering DTMF using RTP payload (RFC2833). In-Band DTMF tone detection is disabled for this call segment.<br>
    15:47:16.656|.\MSInterface.cpp(685)|Trace5||??:DTMFEventHandler<br>
    15:47:16.750|.\MSInterface.cpp(685)|Trace5||??:DTMFEventHandler<br>
    15:47:21.187|.\MSInterface.cpp(666)|Trace5||??:FilePlayEndEventHandler<br>
    15:47:21.187|.\IVRInterface.cpp(210)|Trace5||??:IVRTransferRequestHandler<br>
    15:47:21.187|.\CallCtrl.cpp(210)|Trace5||CallCtrl::eek:nSelectRouteReq:SelectRouteReq<br>
    15:47:21.187|.\CallCtrl.cpp(225)|Log3||CallCtrl::eek:nSelectRouteReq:[CM503010]: Making route(s) to <sip:200@127.0.0.1><br>
    15:47:21.296|.\CM_Stack.cpp(192)|Trace5|SipStack|CallMgr::Stack::isMyExternalIP:Compare IPs: incoming=127.0.0.1; external=71.231.50.128<br>
    15:47:21.296|.\CM_Stack.cpp(202)|Trace5|SipStack|CallMgr::Stack::isMyExternalIP:IPs do not match!<br>
    15:47:21.296|.\CallCtrl.cpp(249)|Trace5||CallCtrl::eek:nSelectRouteReq:Direct SIP call to <sip:200@127.0.0.1><br>
    15:47:21.296|.\CallCtrl.cpp(273)|Log2||CallCtrl::eek:nSelectRouteReq:[CM503013]: Call(2): No known route to target: <sip:200@127.0.0.1><br>
    15:47:21.296|.\Call.cpp(495)|Log2||Call::RouteFailed:[CM503014]: Call(2): Attempt to reach <sip:200@127.0.0.1> failed. Reason: Not Found<br>

    15:47:23.000|.\MSInterface.cpp(666)|Trace5||??:FilePlayEndEventHandler<br>
    15:47:28.796|DialogUsageManager.cxx(1190)|Trace5|Resip|::ResipLogger:Got: SipReq: BYE 3602234758@71.231.50.128:5063 tid=d5.ee441f81.0 cseq=BYE / 103 from(wire)<br>
    15:47:28.796|DialogUsageManager.cxx(1516)|Trace5|Resip|::ResipLogger:Handling in-dialog request: SipReq: BYE 3602234758@71.231.50.128:5063 tid=d5.ee441f81.0 cseq=BYE / 103 from(wire)<br>
    15:47:28.796|InviteSession.cxx(1592)|Trace5|Resip|::ResipLogger:Received SipReq: BYE 3602234758@71.231.50.128:5063 tid=d5.ee441f81.0 cseq=BYE / 103 from(wire)<br>
    15:47:28.796|.\InviteADS.cpp(255)|Trace5||InviteADS::eek:nReadyToSend:SendMsg from <sip:85336@iptel.org>;tag=ae62e05a to "FERNDALE WA"<sip:3602234758@66.54.140.46>;tag=as779fdd1d<br>
    15:47:28.796|InviteSession.cxx(2046)|Trace5|Resip|::ResipLogger:Transition InviteSession::Connected -> InviteSession::Terminated<br>
    15:47:28.796|.\InviteADS.cpp(211)|Trace5||InviteADS::eek:nTerminated:Terminated from "FERNDALE WA"<sip:3602234758@66.54.140.46>;tag=as779fdd1d to <sip:85336@iptel.org>;tag=ae62e05a; reason: PeerEnded<br>
    15:47:28.812|.\Line.cpp(326)|Log2||LineCfg::getInboundTarget:[CM503011]: Inbound out-of-office hours' rule for LN:10000 forwards to DN:801<br>
    15:47:28.812|.\CallEvents.cpp(75)|Trace5||FireStatusEvent:Fire event: OnHook; DN 10000<br>
     
  11. Nick Galea

    Nick Galea Site Admin

    Joined:
    Jun 6, 2006
    Messages:
    1,971
    Likes Received:
    278
    the current DR does not support anything else but 5060 unfortunately. There will be an update (which should not require a reinstall) that will resolve this early next week, along with some other issues in the DR. This will also resolve the call state connected remaining 'stuck' in the pbx. Thanks for your help in troubleshooting this...
     
    Stop hovering to collapse... Click to collapse... Hover to expand... Click to expand...
Thread Status:
Not open for further replies.