" /> External Routing on v6.5 - Genesys CTI User Forum

Author Topic: External Routing on v6.5  (Read 6500 times)

This topic contains a post which is marked as Best Answer. Press here if you would like to see it.

Rajesh

  • Guest
External Routing on v6.5
« on: January 01, 1970, 12:00:00 AM »
Advertisement
Can somebody help me with the paramters I need to set in the TServer (Aspect & Meridian) to make External Routing work ?? For some reason I am not able to make the 2 TServers to communicate with each other. The connection keeps dropping. One caveat is that both the servers are running on the same Win2000 server. Meridian uses port 3000 and Aspect TServer is using port 3020. Please help !!!

Vic

  • Guest
External Routing on v6.5
« Reply #1 on: January 01, 1970, 12:00:00 AM »
Ok,

it seems like no one answered it yet... Wow!
I think the problem you have is with coffeature not being set to TRUE in TServer section. (By default it is FALSE)

Define it on both TServers and also define serverid to be different for each one of them, and it should work.


Rajesh

  • Guest
External Routing on v6.5
« Reply #2 on: January 01, 1970, 12:00:00 AM »
Thanks. Is there any Genesys documentation for v6.5 that describes all these options and their possible values ?? There is nothing in the product manuals pertaining to ISCC. Also, I separated the TServers on two different servers. Genesys asked me to add ADDP since TServer connections keep dropping with local timeout 30 secs and remotetimeout 60 secs. That didn't work. I'll try your above suggestion and see what happens. Also what role does "reconnect out" play in ISCC???
Thanks.

Vic

  • Guest
External Routing on v6.5
« Reply #3 on: January 01, 1970, 12:00:00 AM »
Rajesh,

how are you? Ok, let's do this

reconnect out is amount of time that TServer waits for a reconnect reply before it cancels its request.

ADDP will probably not solve your problem, because based on what you are saying, I think the problem lies either with:
1. improperly configured TServer connections
2. bug

Chances are it is #1, so why don't we do this:
first of all check that you have the option I mentioned defined.
Also, I assume you have access codes, external routing point, and so on already defined under your switches, right?

Can you please post the portion of the log starting with TServer A attempting to connect to TServer B?

Thanks,
Vic

Marked as best answer by on May 07, 2025, 03:39:03 AM

Rajesh

  • Guest
External Routing on v6.5
« Reply #4 on: January 01, 1970, 12:00:00 AM »
  • Undo Best Answer
  • Vic,
    I did set the parameters you asked me to. I didn't see any difference in performance though. It also seems that ADDP changes for timeouts are NOT reflected dynamically in the tserver logs. I am looking at recycling the TServers tonight. Also the logs show ISCCProtocolVersion = "ISCC protocol 5.1" which I don't understand
    why when the TServers are v6.5.
    I'll post the logs in a few minutes.

    Matt

    • Guest
    External Routing on v6.5
    « Reply #5 on: January 01, 1970, 12:00:00 AM »
    Bring them on!

    Vic

    • Guest
    External Routing on v6.5
    « Reply #6 on: January 01, 1970, 12:00:00 AM »
    I am looking forward to reading them.
    It seems like you are really stuck :)

    Rajesh

    • Guest
    External Routing on v6.5
    « Reply #7 on: January 01, 1970, 12:00:00 AM »
    Vic,
    No, it actually works !!! I don't think there is any point in posting the logs. Here's what I have now:
    1. Both TServers are in each other's CONNECTION tab in CME.
    2. Protocol = addp, local timeout = 30, remote timeout = 60, trace= both
    3. Obviously, I have Access codes setup.
    4. I've 2 or 3 External Routing points defined at each site.
    5. coffeature = false since I am not using Call Overflow
    6. serverid is unique for each tserver.

    I had to restart the tservers because they wouldn't take my changes dynamically for whatever reason. Its working fine now.
    So, bottom line : I was not using addp and the connections betn TServers kept dropping (could be several reasons) and they would go about connecting again based on reconnect out setting. But this went on and on. ADDP seems to have brought some sanity to the connection protocol. I guess I am the 1st one to be a big advocate of ADDP now!!! Thanks for all the help. If anybody ash any questions on EXT Routing or its new name, ISCC, let me know.
    Rajesh.