dtorresb Report post Posted 11/04/2013 11:09 PM Please your help. I'm trying to make a call transfer. The Client (7732) calls the VoiceGuide (7731) and wish to transfer the call to the agent (7730). I have two PC's outside the normal network a PC with a virtual PBX and Agent (7730) and the other PC where the client (7732). I have installed and VoiceAgent 7.3.3_130807 VoiceGuide 7.3.3. and VoiceAgent with version 7.3.3 Deputy PrintScreen file configuration to transfer the call, also VoiceGuide configuration file (Config.xml), log and vg.ini, Agent configuration vgAgent.ini The IP´s Customer: 192.168.0.30 VoiceGuide 192.168.0.10 Agent: 192.168.0.20 Dialogic extensions (7731 and 7733) The extention of the client (7732) The agent exension (7730) VoiceGuide_informe.zip Share this post Link to post
SupportTeam Report post Posted 11/04/2013 11:28 PM Attached .ZIP cannot be opened. Can you please try zipping up the files again? or use RAR or some other compression. Please also provide the vgEngine traces as well that capture agent login into ACD system as well as the call itself. Share this post Link to post
SupportTeam Report post Posted 11/04/2013 11:45 PM Also the ktTel trace capturing VoiceGuide service startup as well as the call. The vgEngine trace also must include the VoiceGuide service startup. Share this post Link to post
dtorresb Report post Posted 11/05/2013 04:36 PM I have a problem, I can not attach the archivo.rar I get the following message Share this post Link to post
SupportTeam Report post Posted 11/05/2013 07:11 PM Please email archivo.rar direct to support@voiceguide.com Share this post Link to post
SupportTeam Report post Posted 11/05/2013 08:16 PM File containing traces supplied by customer VoiceGuide_informe.rar Share this post Link to post
SupportTeam Report post Posted 11/05/2013 11:00 PM The ACD system of routing calls is working here, and call is sent to agent and agents popup 'pops up'- but the actual SIP call could not connect to your destination. You should run WireShark to see what SIP messages are exchanged between the two systems and why the call to 7730@192.168.0.10:5060 was disconnected immediately after dialing it. See below: Agent trace shows agent logged on at 15:57:42 and at 15:58:05 agent changed status to "Ready", and a call was immediately sent to the agent. The popup showed the specified web page, and caller ID was passed to the popup along with all other Result Variables for the call: 155742.541 1 wcfc AgentLogOn 7730,Terry Brown,,7730@192.168.0.10:5060 ... 155805.624 1 wcfc AgentStatusSet call Ready 155805.627 1 AgentStatusSet => ok 155805.628 1 ThisAgentStatusSet 5 155805.657 1 ev popup , title=sales, link=http://www.google.com.ec/, opt=someoptions 155805.657 1 rv: [CIDNUMBER]{7732@192.168.0.10:5060}[CIDNAME]{}[PathSysVoice]{C:\VoiceGuide\system\voice\}[PathApp]{C:\VoiceGuide\}[PathDataVm]{C:\VoiceGuide\data\}[PathVgSys]{C:\VoiceGuide\system\}[PathVoiceGuide]{C:\VoiceGuide}[ScriptPath]{C:\script sales\}[ScriptsPath]{C:\script sales\}[PathScript]{C:\script sales}[$RV_STARTTIME]{2013-08-16 15:57:49}[$RV_DEVICEID]{3}[DlgcVoice]{dxxxB1C1}[DlgcNetwork]{iptB1T1}[$RV_CIDNAME]{}[DNIS]{7731@192.168.0.10:5060}[PathApp]{C:\VoiceGuide}[PathVoiceGuide]{C:\VoiceGuide}[ScriptPath]{C:\script sales\}[ScriptsPath]{C:\script sales\}[PathScript]{C:\script sales}[$RV_CIDNUMBER]{7732@192.168.0.10:5060}[Evaluate 1_Input]{"http://www.google.com.ec/"}[Evaluate 1]{http://www.google.com.ec/}[AcdAgentPopup_DisplayLink]{http://www.google.com.ec/} 155805.657 1 html: 7732@192.168.0.10:5060 155805.659 1 AcdEvent_DoPopup_Show begin sales, http://www.google.com.ec/, 7732@192.168.0.10:5060 , resetTimer=5, someoptions 155805.659 1 rv contains AcdAgentPopup_DisplayLink 155805.661 1 rv replace resulted in sLinkInRv=http://www.google.com.ec/ 155805.661 1 AcdEvent_DoPopup_Show displaying [http://www.google.com.ec/] 155805.661 1 ShowPopUp http://www.google.com.ec/, 5 155805.661 1 ShowPopUp - popup already visible 155805.662 1 cEXWB1.Navigate http://www.google.com.ec/ 155805.665 1 AcdEvent_DoPopup_Show completed 155916.259 1 ev state 0, Disconnect_Pending, 155916.280 1 ev state 0, Idle_NotYetReleased, 155916.280 1 ThisAgentStatusSet Work, sCalledFrom=LegToAgent_CallState 155916.280 1 wcfc AgentStatusSet call Work 155916.281 1 AgentStatusSet => ok 155916.282 1 ThisAgentStatusSet 5 155916.286 1 ev state 0, Null_InGuardTimeAfterEndOfCall, 155916.554 1 ev state 0, Null, The vgEngine trace shows that call arrived into VoiceGuide at 15:57:49 as was placed in ACD queue. At 15:58:05 agent 7730 changed status to "Ready", and the call was immediately sent out to that agent. But looks like that outgoing call was never answered - and the original call disconnected at 15:59:16 155749.486 6 3 1 state <offered> : cid=7732@192.168.0.10:5060 , dnis=7731@192.168.0.10:5060 155749.706 18 3 1 ev CallState GCEV_ANSWERED, crn=8000001, iEvent=2 ,256,1,4, s1:, s2:, s3:]. build_date: 2013-08-07 21:16:20.28 155749.764 6 3 1 state ACD queue : sales 155805.625 20 wcf acd AgentStatusSet 7730 Ready 155805.647 6 7 2 state [Transfer Call 2] out_leg 1 <=> 2 7730@192.168.0.10:5060 155916.178 18 3 1 ev CallState GCEV_DISCONNECTED, crn=8000001, iEvent=2 ,16384,0,64, s1:, s2:, s3:]. build_date: 2013-08-07 21:16:20.28 ktTel trace shows that outgoing call to 7730@192.168.0.10:5060 was disconnected immediately after dialing it. 447 155805.652 4136 7 fn LineMakeCall(iLineId=7, iCallRequestId=0 (ignored), strNumberToCall=[7730@192.168.0.10:5060], callprog=CONNECT_IMMEDIATELY, timeout=60, params:0,3,cidtosend=[],opt=[<calltype>DialAndConf</calltype>]) 448 155805.654 4136 7 makecall protocol is: non-ISDN 449 155805.654 4136 ResetVoiceBackToItsNetwork dxxxB1C2->iptB1T2 450 155805.654 4136 7 Reset_voice_to_ipt begin. dxxxB1C2:6 to iptB1T2:7 (hli->ct_devinfo_dx.ct_devfamily=0) 451 155805.654 4136 hli->linedev=7 hli->voicedev=6 452 155805.655 4136 CleanDialString [7730@192.168.0.10:5060]=>[7730@192.168.0.10:5060] 453 155805.655 4136 7 TelDriver_LineMakeCall hli->Dial_zsOtherCallProgressSettings=[<calltype>DialAndConf</calltype>] 454 155805.655 4136 7 Set_DX_CAP_ca_intflg zDial_DxCap.ca_intflg=DX_OPTDIS (CONNECT_IMMEDIATELY case) 455 155805.655 4136 7 CallProgressOption=[CONNECT_IMMEDIATELY] ca_intflg=209005584 456 155805.655 4136 MakeCall select driver. strDti=[iptB1T2] 457 155805.655 4136 MakeCall driver HMP version used, strDti=[iptB1T2] 458 155805.655 4136 gc_MakeCall initialisation (HMP) - new version 459 155805.655 4136 7 gcMakeCallBlk.gclib->destination.address=[7730@192.168.0.10:5060] GCADDRTYPE_TRANSPARENT 460 155805.655 4136 7 set From header using gcMakeCallBlk.gclib->origination.address [] (Dial_zsCallerIDToSend does not contain 'From:') 461 155805.656 4136 7 InitGC_PARM_BLK_ForOutgoingHmpCall : outgoing call protocol is: SIP 462 155805.656 4136 7 G729 and G711 used in GCSET_CHAN_CAPABILITY IP_CAP_DIR_LCLTRANSMIT as iLicCount_EnhancedRTP=2, frames_per_pkt=1 463 155805.656 4136 7 G729 and G711 used in GCSET_CHAN_CAPABILITY IP_CAP_DIR_LCLRECEIVE as iLicCount_EnhancedRTP=2, frames_per_pkt=1 464 155805.656 4136 gc_util_insert_parm_ref_ex IPSET_CALLINFO, IPPARM_DISPLAY [] not called 465 155805.656 4136 7 gc_MakeCall [7730@192.168.0.10:5060] call (HMP) 466 155805.656 4136 7 gc_MakeCall ok. crn=8000002 467 155805.656 4136 7 call progress detection not enabled as ca_intflg == DX_OPTDIS (2) 468 155805.656 4136 7 TelDriver_LineMakeCall returned 0, hli_Returned=0C73FB98 469 155805.656 4136 7 TelDriver_LineMakeCall returned hli_Returned->crn_lastMakeCall=08000002 470 155805.656 4136 7 r generic ktTel_Completion|10000 Completion_MakeCall|0 134217730 (134217730|0|0|7730@192.168.0.10:5060||<result>ok</result><crn>134217730</crn><crnx>8000002</crnx>) 471 155805.656 4136 7 LineMakeCall TelDriver_LineMakeCall zsResult=[<result>ok</result><crn>134217730</crn><crnx>8000002</crnx>] 472 155805.659 3760 CtEventProcess call: lTaskSrlEventStore_CurrentReadIdx=19, iEventsWaitingInQueue=0 473 155805.659 3760 CtEventProcess begin lEvtHandle=0, lSrlEventStoreIdx=19, pTelClientEvents=0x3c6e820, iEventsWaitingInQueue=0x0 474 155805.659 3760 7 ev idx=19 : evttype=2145(2145), crn=8000002, data=03C71280(08741AD0), len=8(8) q: 0/3 475 155805.659 3760 7 ev GCEV_DIALING crn=8000002 crn_lastMakeCall=8000002 476 155805.659 3760 7 Event_CallState GCEV_DIALING iLineCallState=16, hCall=8000002|134217730 m_pktTelProxyClient=002116D0 477 155805.659 3760 7 r CallState GCEV_DIALING 478 155805.664 3760 CtEventProcess call: lTaskSrlEventStore_CurrentReadIdx=20, iEventsWaitingInQueue=1 479 155805.664 3760 CtEventProcess begin lEvtHandle=0, lSrlEventStoreIdx=20, pTelClientEvents=0x3c6e820, iEventsWaitingInQueue=0x1 480 155805.664 3760 7 ev idx=20 : evttype=2087(2087), crn=8000002, data=03C712B0(08741AD0), len=8(8) q: 1/3 481 155805.664 3760 7 ev GCEV_PROCEEDING crn=8000002 lastMakeCall=8000002, hli->crn=0 482 155805.664 3760 7 t_info: gcValue=0(0x0) gcMsg=[Success] ccLibId=8 ccLibName=[GC_H3R_LIB] ccValue=[0x0] ccMsg=[IPERR_OK] additionalinfo=[] 483 155805.664 3760 CtEventProcess call: lTaskSrlEventStore_CurrentReadIdx=21, iEventsWaitingInQueue=0 484 155805.664 3760 CtEventProcess begin lEvtHandle=0, lSrlEventStoreIdx=21, pTelClientEvents=0x3c6e820, iEventsWaitingInQueue=0x0 485 155805.664 3760 7 ev idx=21 : evttype=2086(2086), crn=8000002, data=03C712E0(08741AD0), len=8(8) q: 0/3 486 155805.664 3760 7 ev GCEV_DISCONNECTED crn=8000002 So looks like the ACD system of routing calls is working here, and call is sent to agent and agents popup 'pops up'- but the actual SIP call could not connect to your destination. You should run WireShark to see what SIP messages are exchanged between the two systems and why the call to 7730@192.168.0.10:5060 was disconnected immediately after dialing it. Share this post Link to post
SupportTeam Report post Posted 11/05/2013 11:04 PM Also: Please update VoiceGuide to v7.4.0 Please post WireShark traces as advised above to show what SIP level messages are exchanged between VoiceGuide system and 192.168.0.10 - and post these SIP traces along with the ktTel trace from v7.4.0 What PBX software is running at 192.168.0.10 ? Best to also run WireShark to capture SIP traffic between 192.168.0.10 and the device that registers itself as extension 7730 - this way you'll see if the PBX at 192.168.0.10 presents call to device that registers itself as extension 7730. Share this post Link to post
SupportTeam Report post Posted 11/11/2013 11:41 PM Customer replied: I upgraded to 7.4.0 and VoiceGuide used WireShark, new.zip Share this post Link to post
SupportTeam Report post Posted 11/12/2013 12:46 AM From WireShark trace shows exchange of messages between 192.168.0.10 and 192.168.0.30 It looks like the VoiceGuide system is at IP 192.168.0.30 System at 192.168.0.10 is: "OmniPCX Enterprise R10.1.1 j2.603.25.a" The WireShark trace has not captured the VoiceGuide service start up and hence the SIP Registration by VoiceGuide - which the ktTel trace shows was successful: 263 160621.783 3732 fn VoIPProvider_Register(protocol=SIP, reg_server=192.168.0.10, reg_client=7731@192.168.0.10:5060, local_alias=7731@192.168.0.30, 275 160621.785 3732 fn VoIPProvider_Register(protocol=SIP, reg_server=192.168.0.10, reg_client=7733@192.168.0.10:5060, local_alias=7733@192.168.0.30, 414 seconds into trace WireShark trace captures attempted outgoing call from VoiceGuide at 192.168.0.30 to OmniPCX at 192.168.0.10 : 205 414.825411 192.168.0.30 192.168.0.10 SIP/SDP 810 Request: INVITE sip:7730@192.168.0.10:5060 (INVITE specifies G729 and G711 ULaw and ALaw codecs) but OmniPCX at 192.168.0.10 responds with: 207 414.829341 192.168.0.10 192.168.0.30 SIP 522 Status: 403 Forbidden | The above call was made by the AutoDialer. You should ask OmniPCX administrator why the OmniPCX is responding with "Forbidden" to the SIP INVITE. Possible thing to look at is whether the OmniPCX xpects that CallerID should be set on outgoing auto dialer calls. From: http://www.voiceguide.com/vghelp/source/html/dial_voip.htm : For example, to place a call through a FreeSWITCH PBX which is installed on a server with IP of 10.1.1.11, and with which the user/extension 1010 has been registered by VoiceGuide, the following entry would need to be placed in the Options field: <CallerID>1010@10.1.1.11</CallerID> Sometimes just user ID (or the registered telephone number) is sufficient, eg: <CallerID>5625551234</CallerID> So you could trey adding this to the Options field when loading the outgoing call using the VoiceGuide Outbound Call Loader app: <CallerID>7731@192.168.0.30</CallerID> Also, it looks like another SIP application (X-lite) other then VoiceGuide is installed on 192.168.0.30 system. No other VoIP applications should be installed on same system as VoiceGuide. They may affect VoiceGuide operation and operation of systems that interact with VoiceGuide. Share this post Link to post
dtorresb Report post Posted 11/14/2013 03:35 PM Dear Please your help again.Changed architecture. The PBX is a virtual machine and has the IP (192.168.0.10=, that is on the machine with IP (192.168.0.20) PBX-virtual 192.168.0.10 PC-phisical 192.168.0.20 VoiceGuide 192.168.0.30 X-lite-(Client) 192.168.0.40 X-lite (Agent) 192.168.0.60 The problem persists, they go back to eviar information, WireShark trace The transfer to the direct number works, ie if I transfer to 7730@192.168.0.10: 5060 no problem making the transfer when using the ACD: the transferring Salesno 7730@192.168.0.60 Agent: 5060 Attached documentation. Hope your answer.Thank you. Thank you. VoiceGuide_informe.zip Share this post Link to post
SupportTeam Report post Posted 11/14/2013 10:55 PM Exactly the same thing happens as before. 192.168.0.30 sends INVITE message to 7730@192.168.0.10, but 192.168.0.10 responds with Forbidden. The INVITE message has the FROM field set to IP address 192.168.66.1 What is IP address 192.168.66.1? Perhaps this difference between the IP in 'From:' field and the IP address from where INVITE was sent is the reason why the system at 192.168.0.10 responds with 'Forbidden'. You need to ask supplier of system used at 192.168.0.10 as to why their system responds with 'Forbidden'. Is Dialogic HMP+VocieGuide installed on its own machine with no other virtual machines or other sip applications on that same physical machine? Do you want the calls from VoiceGuide to Agents to go through the SIP PBX, or go direct to IP address of agents machine? If you want the call to agent to be made direct to agents phone then agent contact address should be defined as 192.168.0.60 - not as 7730@192.168.0.10 Extract of just SIP packets from WireShark trace: sip.zip Share this post Link to post
SupportTeam Report post Posted 11/14/2013 11:04 PM Also you mention that: if I transfer to 7730@192.168.0.10: 5060 no problem making the transfer can you post a capture of this? (we'd need to see vgEngine+ktTel+WireShark traces) Share this post Link to post
dtorresb Report post Posted 11/15/2013 11:03 PM Attached requested transfer 7730 ok problem is transfer ACD.zip Share this post Link to post
SupportTeam Report post Posted 11/16/2013 06:47 AM Captured trace shows a "REFER" transfer - not a "Dial and Conference" (tromboned) transfer. ACD uses "Dial and Conference" transfer so it can keep track of call, record call, inject sound files to play to caller etc. In ACD VoiceGuide makes an outbound call to agent. This REFER transfer is just a signal back to call sender to send call somewhere else. Try loading simple outbound calls using VoiceGuide Dialer and placing calls to agent that way (try both through PBX and direct to agents IP address). Your setup seems to use a mix of virtual machines. if you can change this so that VoiceGuide is on a separate physical machine by itself - with no other VoIP apps or other virtual machines on that system - and the agent and caller are using VoIP hardphones (or softphones on other two separate machines) then it may be easier to get this working - after all this is what the setup would be like in real-life deployment. Share this post Link to post
dtorresb Report post Posted 11/18/2013 02:19 PM The problem is the outbound call, that is, does not call Dialer not work ACD does not work. Only the caller when transferred. Physical Machines independent.VoiceGuide 192.168.0.30Client 192.168.0.40Agent 192.168.0.60The virtual machine is installed on the physical machine 192.168.0.20Virtual machine.PBX 192.168.0.10 VoiceGuide_informe.zip Share this post Link to post
SupportTeam Report post Posted 11/18/2013 08:15 PM Exactly the same thing happens as in all traces posted before. 192.168.0.30 sends INVITE message to 7730@192.168.0.10, but 192.168.0.10 responds with Forbidden. The INVITE message has the FROM field set to IP address 192.168.66.1 What is at IP address 192.168.66.1? Is the PBX software running on a virtual machine? . 1119.zip Share this post Link to post
dminof Report post Posted 11/19/2013 10:46 PM I disable IP address 192.168.66.1, is vmware, but the problem persists I want to test voiceguide, using dialer, load extension number 7730 voiceguide used for call extension 7731. I attached the documents B,r Dario Share this post Link to post
SupportTeam Report post Posted 11/20/2013 02:00 AM Nothing was attached. Can you attach again? Was VMWare installed on same system where VoiceGuide was installed? Are you able reformat that system and just install Windows+HMP+VoiceGuide on that system and nothing else? Share this post Link to post
dtorresb Report post Posted 11/20/2013 09:21 PM Attachment file.The team already formatted 5 times and continue the problem.PBX, VoiceGuide, Agent, Customer, are on separate machines VG FILES.zip Share this post Link to post
SupportTeam Report post Posted 11/20/2013 10:25 PM (edited) The IP addresses in the SIP messages now look OK. Can you please try using the VoiceGuide Outbound Call Loader to place the outgoing call to 7730@192.168.0.10 but this time include this in the Outbound Call Loader's "Options" field: <CallerID>7731@192.168.0.30</CallerID> (Attached traces show VoiceGuide still registers itself as extension 7731 with the PBX) Please use WireShark to capture the VoiceGuide service start up and the outgoing call - and post the .ZIPed WireShark trace here. Edited 11/21/2013 12:31 AM by SupportTeam Share this post Link to post
SupportTeam Report post Posted 11/21/2013 02:16 AM If the above works then please change your Config.xml to specify that CallerID be set on outgoing calls to agents when calls are made from ACD queues. The CallerID to use is specified in each of the <acd><queues><queue> entries in Config.xml using the <agent_invite_options> field. Please the below example: <queue> <name>sales</name> <paths> on {timeout 600} goto [Voicemail box 0001] on {1} goto [sales self service] </paths> <callrecord_dir>C:\calls\sales\$RV_ACD_AGENTID\$RV_YY$RV_MM$RV_DD</callrecord_dir> <agent_invite_options> <CallerID>7731@192.168.0.30</CallerID> </agent_invite_options> </queue> Please also update the VoiceGuide install to this latest version: [old link removed] to update just stop the VoiceGuide service and close all VoiceGuide applications, and then install the new version over the top of existing install. Share this post Link to post
dminof Report post Posted 11/26/2013 06:22 PM Scenario 1 voiceguide 192.168.0.30 outboun dialer 7730 7730 is in 192.168.0.60 Call Loader to place the outgoing call to 7730@192.168.0.10,include this in the Outbound Call Loader's "Options" field: <CallerID>7731@192.168.0.30</CallerID> Call outbound is OK I Attached traces Also: I Install [old link removed] but did not work on the same machine. Not recognize the dialogic lines Scenario 2 Voice guiode 192.168.0.20 agent 192.168.0.60 client 192.168.0.30 <agent_invite_options> <CallerID>7731@192.168.0.30</CallerID> </agent_invite_options> Install [old link removed] on another machine 192.168.0.20 and allowed install. but does not work I Attached traces,and log Br Dario nov 26 11 vg.zip Share this post Link to post
SupportTeam Report post Posted 11/26/2013 07:09 PM Are you running Windows XP? 131121.exe had a bug that stopped it from loading properly on Windows XP. This version has the WinXP bug fixed: [old link removed] Share this post Link to post
SupportTeam Report post Posted 11/26/2013 07:40 PM The outbound calls that worked seems to have had the CallerID set to: 7730@192.168.0.10 Can you please try using: <agent_invite_options><CallerID>7731@192.168.0.10</CallerID></agent_invite_options> or: <agent_invite_options><CallerID>7730@192.168.0.10</CallerID></agent_invite_options> Share this post Link to post
dminof Report post Posted 11/27/2013 09:07 PM All are windows 2007 pro Works with any SIP extension registered in the central <agent_invite_options> <CallerID> 7731@192.168.0.10 </ CallerID> </ agent_invite_options> <agent_invite_options> <CallerID> 7730@192.168.0.10 </ CallerID> </ agent_invite_options> <agent_invite_options> <CallerID> 7732@192.168.0.10 </ CallerID> </ agent_invite_options> <agent_invite_options> <CallerID> 7733@192.168.0.10 </ CallerID> </ agent_invite_options> But there is a problem: when the call arrives at the agent, the agent is disconnected. The question is: everything worked, from one day to the other stopped working. I never use: <agent_invite_options> </ agent_invite_options> either: CallerID> </ CallerID> before it worked properly. i, attached logs. br Diego 27112013vg.zip Share this post Link to post
SupportTeam Report post Posted 11/27/2013 09:31 PM Please post two WireShark traces: as seen from VoiceGuide and as seen from Agent PC. We can then see the calls being established and which side is ending the call. Share this post Link to post
SupportTeam Report post Posted 11/27/2013 10:23 PM If the making of calls beforehand worked properly without setting of CallerID on the outgoing calls then you should ask OmniPCX administrator why the OmniPCX is now responding with "Forbidden" to the SIP INVITE when the SIP INVITE does not have CallerID set. Share this post Link to post
SupportTeam Report post Posted 11/28/2013 09:27 AM Trace shows that: Call to VoiceGuide was made from 7732. Call was sent to agent (at 7730) when agent set status to Ready - but the CallerID on the outgoing leg of the call was set to 7732 - which could confuse PBX as VoiceGuide registered itself to use 7731 and 7733, not 7732. The CallerID set on the outgoing call was set to 7732 There also seems to be some problems with communication between VoiceGuide and the agent's popup - but lets resolve the call establishment issue first. As per previous post: Please post two WireShark traces: as seen from VoiceGuide and as seen from Agent PC. We can then see the calls being established and which side is ending the call. 154216.589 6 q_tel + cmd_VoIPProvider_Register 0 [0,0,0,0,0][SIP|192.168.0.10|7731@192.168.0.10|sip:7731@192.168.0.20:5060|] 154216.590 6 q_tel + cmd_VoIPProvider_Register 0 [0,0,0,0,0][SIP|192.168.0.10|7733@192.168.0.10|sip:7733@192.168.0.20:5060|] 154321.691 17 3 1 ev CallState GCEV_OFFERED, crn=8000001, iEvent=0 ,2,0,8, s1:7732@192.168.0.10:5060|, s2:7731@192.168.0.10:5060, s3:]. 154321.721 6 3 1 state <offered> : cid=7732@192.168.0.10:5060 , dnis=7731@192.168.0.10:5060 154322.026 6 3 1 state ACD queue : sales 154324.744 23 wcf acd AgentStatusSet 7730 Ready 154324.773 6 7 2 q_tel + cmd_MakeCall 0 [0,3,60,0,0][7732@192.168.0.10|<calltype>DialAndConf</calltype><CallerID>7732@192.168.0.10</CallerID>|7730@192.168.0.10:5060|CONNECT_IMMEDIATELY|] 154325.709 17 ERROR v7.4.5073.23592 (2013-11-21 13:06:24.39) AcdSendMessage_CallState:sink.Dialer_PresentingCallForPreview : No se puede obtener acceso al objeto eliminado. Nombre del objeto: 'System.ServiceModel.Channels.ServiceChannel'. Server stack trace: en System.ServiceModel.Channels.CommunicationObject.ThrowIfDisposedOrNotOpen() en System.ServiceModel.Channels.ServiceChannel.Call(String action, Boolean oneway, ProxyOperationRuntime operation, Object[] ins, Object[] outs, TimeSpan timeout) en System.ServiceModel.Channels.ServiceChannel.Call(String action, Boolean oneway, ProxyOperationRuntime operation, Object[] ins, Object[] outs) en System.ServiceModel.Channels.ServiceChannelProxy.InvokeService(IMethodCallMessage methodCall, ProxyOperationRuntime operation) en System.ServiceModel.Channels.ServiceChannelProxy.Invoke(IMessage message) Exception rethrown at [0]: en System.Runtime.Remoting.Proxies.RealProxy.HandleReturnMessage(IMessage reqMsg, IMessage retMsg) en System.Runtime.Remoting.Proxies.RealProxy.PrivateInvoke(MessageData& msgData, Int32 type) en vgServicesInterfaces.IAcdAgentCallback.LegToAgent_CallState(Int32 iAgentID, Int32 iCallID, String sCallState, String sOptions) en ..(Int32 iAgentID, String sCallState, String sOptions) 154325.710 17 NOTE AcdSendMessage_CallState Removed agent [7730] from dictAcdAgentEventSinksSubscribed list. Agent needs to login again to become part of ACD. 154327.676 17 7 2 ev CallState GCEV_CONNECTED, crn=8000002, iEvent=0 ,256,2,4, s1:, s2:, s3:]. build_date: 2013-11-21 13:06:24.39 154327.678 6 acd AcdSendMessage_CallState [7730,Connected,] 154327.678 6 acd dictAcdAgentEventSinksSubscribed does not contain key 7730 154327.678 6 ERROR v7.4.5073.23592 (2013-11-21 13:06:24.39) agent [7730] is not in ACD Agent list. 154327.710 6 3 1 q_tel + cmd_RecTwoLinesStart 0 [3,7,-465926,7,0][dxxxB1C1|iptB1T1|iptB1T2|C:\calls\sales\1127154327_1_.wav|] Share this post Link to post
dminof Report post Posted 11/28/2013 03:42 PM Hello. The call comes as the agent.With settings: <agent_invite_options> <CallerID> 7731@192.168.0.10 </ CallerID> </ Agent_invite_options> or <agent_invite_options> <CallerID> 7733@192.168.0.10 </ CallerID> </ Agent_invite_options> The problem is in the pop-upThe agent is disconnected and get the error. Share this post Link to post
SupportTeam Report post Posted 11/29/2013 11:31 AM The popup communications issue seems to be some sort of a mismatch between WCF interfaces used. Simplest way to resolve would be to update both VoiceGuide and vgAgent to latest releases. VoiceGuide: [old link removed] vgAgent: [old link removed] To update vgAgent just exit vgAgent program and install new version of vgAgent over the top of current install. To update VoiceGuide just exit all VoiceGuide programs and stop VoiceGuide service and install new version of VoiceGuide over the top of current install. Existing configuration files will not be modified/overwritten by the new installs. Share this post Link to post