Recent Posts

Pages: [1] 2 3 ... 10
I think you could call an IVR from your strategy that is on the Routing Point of the Voice Transfer Destination parameter of your Campaign Group. Then, treat your strategy according to the returned value from the IVR
Looking for experience here, the requirement is to call customer, if answered, play a message, and then ask presee 1 to talk to agent; if amd, then just leave the message without opt to agent. Should this be created as agent campaign or place campaign is other ways to do it? Thanks
Genesys CTI Technical Discussion / Re: Composer with external Tomcat
« Last post by Rutger on Today at 12:09:31 AM »
We don't use embedded Tomcat as well. It takes a little bit more time to do deployments, but you will get used to it.
It's just a matter op Generating the code. Export project to war file and then upload the war file manually to the Tomcat server anywhere in the network.
Genesys CTI Technical Discussion / Re: Dynamic Menu
« Last post by immdhi on Yesterday at 09:32:32 PM »
HI aklinbail

can you post your solution here , what you did in playing the prompt dynamically

Genesys CTI Technical Discussion / Composer with external Tomcat
« Last post by cavagnaro on July 20, 2019, 05:43:30 AM »
Hi guys
Wondering if any you have used Composer without the embedded Tomcat and used a new instance? This is because customer has banned embedded Tomcat due to security failures.
So I tried to use Composer with a clean Tomcat (Deployment) and doesn't work...


Failed to deploy the Composer Project
Got unexpected response: FAIL - Failed to deploy application at context path /Pesquisa_DIGITAL
.  Please make sure the project name does not have the following invalid characters: % & , =

But if I use original Tomcat does work fine...any idea? Maybe some config needed at Tomcat side? Tomcat 8 being tested
Genesys CTI Technical Discussion / Re: ICON / Infomart Database Restore
« Last post by dtorres265 on July 19, 2019, 11:10:44 PM »

I've a problem that Infomart is not taking data from an specific Icon from some previous days so Iv'e been told by Genesys that this cannot be done manually.
do you know where the information of the time-stamp is being stored or why this is happening?



I think you don't need to restore infomart database incase something happens to your ICON db.

If the extract job has successfully transferred the data from ICON to Staging and then GIM, then GIM Extract job will always look for the data which isn't transferred in GIM. I don't really remember but there is a table in GIM named ETL history which contains all the information related to ETL process and it has the time-stamp when the data was transferred last time from ICON.

so you can fix the problem with the ICON db and run extract job again, it will fetch where it left.

Genesys CTI Technical Discussion / Re: Sip server clears nomal calls as idle
« Last post by Kubig on July 19, 2019, 12:43:08 AM »
The timer takes into account the time from last SIP message belongs to SIP session, it has nothing to do with T-Lib messages at all. So, check your SIP signalization what happened there
Genesys CTI Technical Discussion / Sip server clears nomal calls as idle
« Last post by deadmeat on July 18, 2019, 08:44:35 PM »
Hi friends, maybe you can help. We have an issue, when I enable stuck calls clearence in SIP server call cleanup section. It releases normal calls treating them as idle:

Code: [Select]
@15:01:07.1113 Call 008202daccd2c647 idle timeout expired -- initiating call cleanup
15:01:07.111: SIPTS: SipTServer::CheckCall call-id 22843592 - lets call deleting be handled regular way
15:01:07.121: SD: none
15:01:07.121: GetRegistration::Unable to resolve number for DN:994555902585
15:01:07.122 SIPCONN(994555902585): ClrMediaPeer
15:01:07.122 SIPCONN(9900): ClrMediaPeer
15:01:07.122 SIPCONN(9900): CheckUpdateTransferStatus: no original dialog
15:01:07.122: GetRegistration::Unable to resolve number for DN:994555902585
15:01:07.122 SIPCONN(994555902585): set monitor ecd6220, 0
15:01:07.122 SIPCONN(994555902585): state e:1,p:3,s:0,c:11,rc:0,m:0
15:01:07.122: SipDialog: ClearCall(phone=0,state=7)
15:01:07.122: SipDialog::Terminate(state=7,reason=0)
15:01:07.122: SIPDLG[16991899]: register TRN[66342212]
15:01:07.122: Sending  [0,UDP] 451 bytes to >>>>>
BYE sip: SIP/2.0

Any ideas ? What could be the reason of such behaivoir ? I was suspecting incorrect configuration of session timer, but as I see in SIP logs it refreshes every minute:
Code: [Select]
15:01:05.552: HA:MESSAGE:TYPE[sipStackSync]: SYNCED
15:01:05.552: SipDialog: event CONNECTED_SEND_ACK, t=66342181, s=7, r=7, m=a089158 port=5060
15:01:05.552: CID:CUUID>00097338-2862-1CB3-8D58-0539DC0AAA77-14202152@
15:01:05.552 SIPCONN(9900): HandleSipDialogEvent(CONNECTED_SEND_ACK) - filtered
15:01:05.552 SIPCONN(9900): TRCLR(66342181)
15:01:05.552: SIPTR(116922359): complete
15:01:05.552: SIPTR(116922358): Step 0 - SipTransactionRefresh(116922359) complete
15:01:05.552: SIPTR(116922358): complete
15:01:05.552: SIPCM: transaction SipScenario(116922358) complete
15:01:05.552: PI: 00 S[CI]D[994555902585]C[*D[994555902585]]P[9900]
15:01:05.552: PI: 00 S[CA]D[9900]C[*D[9900]]P[994555902585]
15:01:05.552: CALLSTATE(a:2,d:0,i:0,e:1,r:0,o:0)
15:01:05.552: -----------------------------------------------------------
15:01:05.552: C[22843592]:CF[D[[0]]:SC[116922358]
15:01:05.552: P[22709348]:D[994555902585[67191443]]:LID[0]:CS[3]D2[9900[67191447]]:
15:01:05.552 SIPCONN(994555902585):  endPoint :CON[16992254]STATE[3]:PEER[16992255]:D[994555902585[67191443]]:DLG[16991899 STATE[7]]:D2[[0]:TD[0[IM[no]]]:LCRC
15:01:05.552: P[22709350]:D[9900[67191447]]:LID[0]:CS[3]D2[994555902585[67191443]]:
15:01:05.552 SIPCONN(9900):  endPoint :CON[16992255]STATE[3]:PEER[16992254]:D[9900[67191447]]:DLG[16991900 STATE[7]]:D2[994555902585[67191443]:TD[0[IM[no]]]:LCRC
15:01:05.552: HA: BEGIN SYNC: CALL[22843592] SYNCTYPE[2]: SECOND CALL[0] SYNCTYPE[-1]
15:01:05.553: HA: END SYNC: CALL[22843592] SYNCTYPE[2]: SECOND CALL[0] SYNCTYPE[-1]
@15:01:05.5533 [BSYNC] Trace: Send to backup (SIP_b) [50]:
message EventUserEvent
attr_#1005 0
attr_#1004 553
attr_#1003 1563447665
attr_#1002 137578007
attr_#1001 1
attr_#1000 131072
attr_#15999 1
attr_#16704 1
attr_#16000 1
attr_#16102 [446] 32 3a 31 7c..
attr_#16101 [408] 32 3a 31 7c..
attr_#16100 [107] 31 3a 31 7c..
AttributeUserEvent [16001]
@15:01:05.5533 [BSYNC] Trace: Sent
15:01:05.553: HA:MESSAGE:TYPE[callSync:]: SYNCED
15:01:05.553: call1 22843592 idle
15:01:05.553: $-NET:SIP::0:0

Any ideas ? Will apreceate any help.
Genesys CTI Technical Discussion / Some fields missing in GIM table GIDB_GC_FIELD
« Last post by G3n35Y5 on July 17, 2019, 03:54:28 PM »
IDB storing configuration data is synchronized with Configuration Server. Total records in GC_FIELD table is matching the number of fields in GAX. However in GIM database, total fields in GIDB_GC_FIELD is way less than the the number of fields in GC_FIELD (of IDB). None of GIM jobs have failed. What could be the probable reason of this issue and how can this be resolved?
Yep you can do it with XPath

Assume the backup application DBID is 417, the below code will give you the primary for that backup.

Code: [Select]
RequestReadObjects2.create(CfgObjectType.CFGApplication.ordinal, "CfgServer[backupServerDBID/DBID=417]")
Pages: [1] 2 3 ... 10