Outbound Contact with Multiple Location Resources on Avaya S87xx

[pspenning]

Good Day Everyone,
I am noticing something very odd with OCS and I was wondering if anyone could help me get an answer to this.

We are placing outbound calls through campaigns at our Covington, Georgia location as well as our Riverside, California location.  Our Home Office is in Atlanta and that is where our Primary Framework Server and OCS Server are.  We have a multi-location Avaya S8710 PBX with local trunking in Covington and Riverside.  Unfortunately the Atlanta location Telco resources are the ones who are actually dialing the calls.  We need Covington and Riverside to use their trunks instead.

According to Tech Support at Genesys, they tell us that the VDN in Avaya (The Voice Transfer Destination in Genesys) is where the call gets made from, so we should program this VDN to use other resources and that will solve the problem.  We have done this through the use of Class of Restriction and I am still seeing calls made over our trunks here at our Home Office.  The rub here is that our Home Office is now using SIP trunks (Through Avaya and Asterisk) to place Long Distance calls and OCS isn’t getting proper call classification for some reason.  I see the calls get placed and they indicate ringing from the SIP server but OCS disconnects the line and returns a “General Error”.

If we could have the OCS calls placed over traditional PRI circuits then we could worry about the SIP classification issue later.  As it stands now, about 90% of our outbound calls are not working.

What I really need to know is, in great detail, how does the Avaya T-Server instruct the Avaya to place a call?  From what DN does it place the call?  How to other organizations accomplish calling from multiple locations using local resources?  I have looked over the T-Server deployment guide with no bright sparks of an idea.  If anyone could offer any suggestions I would be greatful.

Our environment is HA with 7.6 Avaya TServers and 7.5 OCS.
Thanks!
Perry

[cavagnaro]

OCS will instruct TServer to dial using DNs configured as Dialers.
This dialer will work as any extension on your PBX and will dial according to how you configured it, routes, permissions, etc.
About SIP, unless you are using G711 detection tones will be difficult or impossible to achieve, I never recommend to dial using VoIP, delays and decompression tasks will kill your campaign.

[Gulden_NL]

[quote author=cavagnaro link=topic=3793.msg16305#msg16305 date=1233349874]
About SIP, unless you are using G711 detection tones will be difficult or impossible to achieve, I never recommend to dial using VoIP, delays and decompression tasks will kill your campaign.
[/quote]

Do you have the HMP module installed for Call Progress Detection?  That's the Dialogic OEM piece that is required for CPD with 7.x outbound with VoIP.

[jbobinsk]

To avoid such situation you can use individual prefixes for campaigns made in both locations which will determind trunk groups you want to use. It can be done by parameter public_network_access_code set on campaign group.

Regards
jbobinsk

[cavagnaro]

It is better to handle those codes per calling list or even better per record in the calling list. Doing it at OCS or campaign level can be too hard to manage later.

[jbobinsk]

It doesn't matter where this parameter will be set - the most important is that problem can be solved in such way. The place of parametrizing depends on needs, but the worst would be to set it in phone field at calling list - because it limits using calling list to right campaign and campaign group.

regards
jbobinsk

[bcyk]

It is assumed there is separate T-server for Avaya in each location, isn't it?
ie.. multilple T-servers


[u]Outbound voice path in Avaya (predictive call)[/u]

1. using Avaya classified board as CPD device
  *** Genesys CPD server is NOT required
  [port Avaya classified board] ---> PSTN ---> called number
                  |
  (positive voice detected and/or connected)
                  |
              [VDN] (one of parameters when initiating outbound call)

  [VDN] ---> (vector script commands, pass to URS using adjunct or simply queue to Avaya skill queue)
            ---> ready agent

2. using Extension with third-party CDP device (e.g., Dialogic card)
  *** Genesys CPD server is required
  [Extension on Dialogic card] ---> PSTN ---> called number
            |
  (positive voice detected and/or connected)
          [VDN] (one of parameters when initiating outbound call)
            |
            +--> same as case 1

3. Genesys ASM dialer configuration
  *** Genesys CPD server is required with CPD device such as Dialogic card
  voice path is not shown for this case


What is the configuration in your environment?


[u]Outbound trunk selection[/u]

public_network_access_code in OCS 7.5 can be configured in different level
    Switch level
    Campaign level
    Calling list level

It does depend on site specific requirement; in general, campaign level should be appropriate because connected outbound calls should be distributed to pre-configured target VDN and agent group.

examples: 511...513 are public_network_access_code
outbound calls ---> [Avaya PABX]
                            TOC = 511 ----> to local PSTN
                            TOC = 512 ----> to tie-trunk
                            TOC = 513 ----> to SIP trunks

As discussed in above replies, network access code can be configured in Geneys option at different levels or simple coded as prefix in the contact number in calling list record.



[u]CPD accuracy[/u]

For fixed-line or land-line (i.e., home or office) number, CPD results are pretty good.
It could be nightmare in mobile phone (also called handheld or cell phone in many areas!) environment.
Color/music-ring tone and operator announcement (voice prompt without answering signal) are some of 'trouble-makers'.

It is not sure how call results in SIP trunks returns to Genesys OCS; some results (SIP response 2xx, 3xx, 4xx, 5xx and 6xx), may be available to or recognized by Genesys OCS.
Or, SIP trunks in this case are simply used as tie-trunks between multiple locations!

[cavagnaro]

[quote author=jbobinsk link=topic=3793.msg16315#msg16315 date=1233436429]
It doesn't matter where this parameter will be set - the most important is that problem can be solved in such way. The place of parametrizing depends on needs, but the worst would be to set it in phone field at calling list - because it limits using calling list to right campaign and campaign group.

regards
jbobinsk


[/quote]

Don't get mad. I believe it is how our enviroment is and how the business rules. Nor one or the other are worst. For my scenario setting at calling list level is the best because I have a very similar scenario to the one described and as the trunk group used may also impact (cellphones goes using a digital conversor, normal numbers will go out using a dedicated PRI and long distance numbers will go out using another PRI), if we use ARS (Automatic Route Selection) such configuration will consume remote resources and will be necesary a IP/TdM conversion adding problems to VAD, so in order to optimize these we add the static prefix to the calling list and the one who is in charge of selecting the right prefix will be the application that feeds the calling lists.
So as you can see in my scenario is the best technical-design option. Maybe for you not or nor for pspenning, but will be his choice.

[jbobinsk]

Hi Cav,

I agree with you.

regard
jbobinsk

P.S. I hope I'm not mad

[pspenning]

WOW!  what a great forum!  I appreciate all of the dialog and spirited debate!  In our case we have one primary and one secondary T-Server.  It would be like pulling teeth from a tiger to get another access code because of a crazy requirement that we maintain a 4 digit DID dial plan.  We are completely out of numbers to dedicate to access codes.  However, I might be able to put the tiger to sleep when I pull teeth.  That's something I will have to engineer.  We shall see since our Non-DID numbers are 5-digit...  I might be able to scrape out an access code.

As for the first reply, I think that is going to work best for us as I already have the Class of Restriction set up and all I need to do is to assign the COR to the proper dialer extension.

But going forward I believe this is only a band-aid and I think a more proper solution would be to use access codes per site.

I appreciate all of the help!  I will let you know how I make out.
Thanks again!
Perry
Sr. Telecom Engineer
Rollins, Inc. / Orkin Pest Control

[cavagnaro]

[quote author=jbobinsk link=topic=3793.msg16320#msg16320 date=1233513042]
P.S. I hope I'm not mad
[/quote]
angry was the word hehe

[pspenning]

[quote author=cavagnaro link=topic=3793.msg16305#msg16305 date=1233349874]
OCS will instruct TServer to dial using DNs configured as Dialers.
[/quote]

I guess I am a little confused.  How exactly do I configure a DN as a Dialer.  I am looking in Config Manager and don't see any DNs of that type.  Is this something in OCS or Config Server?
Thanks,
Perry

[pspenning]

Bump...
Any more thoughts on this one?  I am still stuck on why the OCS is using trunks from a central location when the VDNs belong to other locations in the Avaya switch...  Strange... 

Thanks for any ideas...
Perry

[cavagnaro]

Check your TServer guide, it will tell you how to configure specific DNs in your enviroment in PBX and in CME.