Genesys CTI User Forum

As we don't usually test non supported environments... There is no clear answer to this.

Enviado de meu SM-S918B usando o Tapatalk

I think there are a few different ways that can be done without frequent looping. Some of them:

1. Based on busy treatments
  Setup busy treatments outside of Target selection object - invoke AddBusyTreatment function few times
  for treatments Music1,Announcement1,Announcement2,CallbackOffer, Exit
  Use target selection object without any treatments inside and waiting time big enough to cover all involved treatments.
  Treatment Exit will make the target selection object quit through red port with error "-003 Exit"
  On this red port analyze was call back accepted or not.
  If not then reset busy treatment chain - invoke ResetBusyTreatments[], AddBusyTreatment for Music2,Announcement3,Announcement4,Exit
  and loop back to the target selection object
  If again exit happen on Exit Treatment - reset busy treatments back to the original set of busy treatments and loop back to target
  selection object, and so on.
 
  It is even possible to use single list of busy treatments (without splitting it into 2 sublists)
  But for that you need to check result of CallbackOffer from busy treatments "thread".
  Something like this:
  Use target selection object with busy treatments
      Music1,Announcement1,Announcement2,CallbackOffer,[b]PlayApplicationToCheckCallBack[/b],Music2,Announcement3,Announcement4.
  PlayApplicationToCheckCallBack here is a special busy treatment to verify whether the call back was accepted or not.
  It is PlayApplication treatment with parameters APP_ID set to URS and STRATEGY set to name of URS subroutine which check callback acceptance.
  Running such busy treatment will mean URS executes this subroutine and continues with next busy treatment,
  You must write it - check call back acceptance if yes, then it forces quitting from the target selection object by resetting busy treatments:
  ResetBusyTreatments[] followed with AddBusyTreatment Exit – it results chain of busy treatment will collapsing to single Exit treatment, which
  force quitting from the currently executed target selection object.

 
2  Use generic(combined) waiting function able to wait for different type of events
  Something like the following:
 
  - SelectDN[]
  - if exitting on red red port, then start playing Music1
  - ListRes= SuspendForAll[HowLongToWait, 'treatment,target', '']
      Function SuspendForAll will resume when whatever first happens: waiting time expires, target is found, treatment is over.
      Second paramter set which type of events to wait: here end of treatment and target selection.
      It returns the reason why exactly it happened and data associated with this reason (select target, for example)
  If it is because of treatment end, then start the next treatment and again use SuspendForAll, and so on.

Hello guys,

after a long time creating some routing in IRD, and I cannot seem to remember how to keep the call in routable state while playing treatments. My customer wants to have a queueing annoucement setup where they can set something like this:

Music1
Announcement1
Announcement2
CallbackOffer
Music2
Announcement3
Announcement4

Trying to figure out what's the easiest way to handle going to CallbackOffer because I don't know the length of Announcement1 and Annoucement2. Call needs to be in routable state even during the announcements, so I cannot just queue the call and use Play Announcement blocks. Is there some way I can combine SuspendForDN and SuspendForTreatmentEnd so that I know when to move to next block (EventTreatmentEnd arrives), but keep the call routable while waiting?

Thanks in advance!

Kind regards,

Willian

Have you configured SIP header mapping? You can use Transfer-Type option to override the behavior of the transfer and decide whether use INVITE or REFER

As far as I know there is no other way how to get number of active (connected) trunks