Two-Step Transfer using a strategy but without a Genesys desktop?

[chicodobrazil]

Hiya there

I would like to be sure that I can do a consultation call using a strategy to find party C but without using a Genesys desktop and the "TInitiateTransfer" & "TCompleteTransfer" usually used.

Here is the call flow, I think about, using PBX routing points and proACD phones without any Genesys desktop:
- a call from party A is answered by party B with his proACD phone
- party B, using his proACD phone, puts party A on hold
- party B, using his proACD phone, calls a routing point on which a strategy is loaded
- the strategy tries to find a target
- party C answers, using his proACD phone
- party C and party B talks a short time
- completion of the transfer from party B
- party A and party C talks

Is it possible ?

Thanks again for your help

[René]

Hi,

If your switch does support described scenario then you'll be able to do it without using GDesktop.

What switch are we talking about? Alcatel?

R.

[chicodobrazil]

[quote author=René link=topic=3145.msg12841#msg12841 date=1216223331]
Hi,

If your switch does support described scenario then you'll be able to do it without using GDesktop.

What switch are we talking about? Alcatel?

R.
[/quote]

Yes, Alcatel 4400

My point is about the fact that we're not using the "TInitiateTransfer" & "TCompleteTransfer" as usually used.
I'm thinking about the ConnID1 and the ConnID2 and the way Genesys will manage them as usually with GDesktop.

But from your point of view, and with an Alcatel 4400, it's possible !?

Thanks for your help René

[René]

Yes, it's possible. Generally we can say that it's possible do any telephony operation supported by GDesktop with the hardset because that is the primary "interface" between user and the switch (from switch vendor point of view). Genesys is specialized "add-on" for contact centres.

About the ConnIDs - TServer is client of your switch so it will receive information about transfer attempt if the stations (extension/ACD position) involved in the transfer are configured in CME =monitored by TServer. You can image following events flow from switch to TServer:

1. Call from party A is ringing and established on party B hardset (proACD phone) - TServer receives the events (EventRinging, EventEstablished) and generates ConnID1 for this call once the call appears for first time
2. Party B initiates transfer using hardset - TServer receives info from switch (EventHeld - ConnID1)
3. Party B dials party C - TServer receives info from switch (EventDialing) and generates new ConnID2
4. Party C answers the call (EventEstablished - ConnID2)
5. Party B finished the transfer - TServer receives multiple events (EventPartyChanged - ConnID1, EventReleased - ConnID2)

R.

[chicodobrazil]

[quote author=René link=topic=3145.msg12849#msg12849 date=1216228731]
Yes, it's possible. Generally we can say that it's possible do any telephony operation supported by GDesktop with the hardset because that is the primary "interface" between user and the switch (from switch vendor point of view). Genesys is specialized "add-on" for contact centres.

About the ConnIDs - TServer is client of your switch so it will receive information about transfer attempt if the stations (extension/ACD position) involved in the transfer are configured in CME =monitored by TServer. You can image following events flow from switch to TServer:

1. Call from party A is ringing and established on party B hardset (proACD phone) - TServer receives the events (EventRinging, EventEstablished) and generates ConnID1 for this call once the call appears for first time
2. Party B initiates transfer using hardset - TServer receives info from switch (EventHeld - ConnID1)
3. Party B dials party C - TServer receives info from switch (EventDialing) and generates new ConnID2
4. Party C answers the call (EventEstablished - ConnID2)
5. Party B finished the transfer - TServer receives multiple events (EventPartyChanged - ConnID1, EventReleased - ConnID2)

R.

[/quote]

Thanks for this good news

So, in my case with a strategy, I have a step 3a/3b like that :
...
[color=red][font=Verdana]3a. Party B dials a routing point on the PBX B on which an IRD strategy will be launched and will find out a "right competency & ready state" party C on a PBX C
3b. PBX B will call PBX C using ERP to reach party C - TServer receives info from switch (Event ) and generates new ConnID2[/font][/color]
4. Party C answers the call (EventEstablished - ConnID2)
...

Is it correct ?

Thanks again for your help

[cavagnaro]

Are these separate OXE's or just remote media gateways? If first option how are they interconnected? Using ABC? If ABC check the version of your OXE and TServer and check the limits of doing transfers on this scenario to RSI objects from another PBX. On this sceneario I believe you will have several Switching offices right?
Tserver will not receive any event from switch directly, when B calls the RSI B will decide if completes the transfer or waits that C answer (TCompleteTransfer).

But again, be carefull on the RSI with ABC interconnections...

[chicodobrazil]

[quote author=cavagnaro link=topic=3145.msg12857#msg12857 date=1216263409]
Are these separate OXE's or just remote media gateways? If first option how are they interconnected? Using ABC? If ABC check the version of your OXE and TServer and check the limits of doing transfers on this scenario to RSI objects from another PBX. On this sceneario I believe you will have several Switching offices right?
Tserver will not receive any event from switch directly, when B calls the RSI B will decide if completes the transfer or waits that C answer (TCompleteTransfer).

But again, be carefull on the RSI with ABC interconnections...
[/quote]

Yep, separate OXE's interconnected using ABC

As you said, IF at the moment the strategy will catch the call on the RSI B, the call is like completed within Genesys... I'm stuck !

I found out a few parameters for RSI objects, URS & TServer that SHOULD fix it.

What do you think about it ? Possible or not

[color=red]OXE[/color]
'RSI Supervised Transfer'
With value true in the RSI configuration,
the PBX activates the routing dialog for consultation calls and allows
consultation calls to be routed. With value false, the PBX does not
activate the routing dialog until transfer is completed.

[color=red]URS[/color]
'route_consult_call'

[color=red]TServer[/color]
'rsi-report-xfer'
With value true, T-Server reports a normal transfer scenario for calls that are
transferred to an RSI Routing Point. This means that routing strategies must be
written to handle such scenarios.
With value false, T-Server ends and restarts the routing dialog with URS
when a call is transferred to an RSI Routing Point.
The call flow is different with this value set to false, and is as follows:
EventRouteUsed (consult ConnID)
EventPartyChanged (primary ConnID, consult PreviousConnID)
EventRouteRequest (primary ConnID)

'use-rsi-consult'
Defines whether T-Server creates a new call on RSI with type Consult if
private data Supervised transfer is present (value set to true).
Note: The value of this option must be set to false if the Call Overflow
feature is being used and consult calls are being made to RSI.
In order to propagate attached user data

[chicodobrazil]

I really need a confirmation, today to be honest, that is possible or not to do it

Thanks A LOT for your help

[cavagnaro]

Gee ok boss hehe
I wouldn't say, you have to test and again problem with RSI and ABC transfers raises, you will have to check documentations and versions on your side. Asking Genesys directly would be the best way and secure.

[chicodobrazil]

[quote author=cavagnaro link=topic=3145.msg12875#msg12875 date=1216313204]
Gee ok boss hehe
I wouldn't say, you have to test and again problem with RSI and ABC transfers raises, you will have to check documentations and versions on your side. Asking Genesys directly would be the best way and secure.
[/quote]

Thanks mate.
I will try to ask them but it was to avoid that I've posted there.

Cheers