" /> Communications DN - Genesys CTI User Forum

Author Topic: Communications DN  (Read 12959 times)

jim_1

  • Guest
Communications DN
« on: September 25, 2008, 10:08:50 AM »
Advertisement
Hi,

Hopefully someone can help,
We need to register a communication dn that receives events from tserver or statserver.

I have created a commdn in CME , however, I noticed it only registers against OCS and the Switch.
How can I get the DN to register against tserver or statserver, so I can receive all telephony Events?

This is for our applications team to develp a java app that gets all inbound telephony events for one of our clients.

Are comm dn's only useful for outbound dialing events?

Have a ticket open with tech support, but is not really progressing.

Regards

Jim

Offline Dionysis

  • Sr. Member
  • ****
  • Posts: 408
  • Karma: 8
Re: Communications DN
« Reply #1 on: September 25, 2008, 02:39:43 PM »
  • Best Answer
  • As far as I know COMDN is only for outbound events.

    However you should be able to build an application that does a "register all" when connecting to the TServer.  This is what a stat server does when it connects.

    The app will therefore receive all events for every DN on the TServer.


    jim_1

    • Guest
    Re: Communications DN
    « Reply #2 on: September 25, 2008, 02:49:59 PM »
  • Best Answer
  • Appreciate the reply Dionysis,

    Do you know if there is any Genesys documentation regarding this? Or could you give some details on how to do this.

    Many Thanks

    Jim

    Offline cavagnaro

    • Administrator
    • Hero Member
    • *****
    • Posts: 7641
    • Karma: 56330
    Re: Communications DN
    « Reply #3 on: September 25, 2008, 04:02:54 PM »
  • Best Answer
  • Hi, as already mentioned Communication DN is only used for Outbound solutions. No need to do anything else, just create the DN and OCS will be able to "read" TServer events and therefore send events as well.
    You can refer to OCS Deployment and Development guide for further information about the events you will be able to use under Communication API section.
    StatServer and other DN's doesn't talk with common DN, that is why also, you will not be able to filter outbound statistics with filters as you do on a normal template. For example, if you have a userfield called account_type with values gold and silver and you want to know how many of this calls were dropped, no way with StatServer and CCPulse as the StatServer will not catch the userfield as a KVP.

    jim_1

    • Guest
    Re: Communications DN
    « Reply #4 on: September 25, 2008, 04:27:51 PM »
  • Best Answer
  • Hi,

    If commdn is only useful for outbound solutions, is there a mechanism for the 3rd party apps, to receive say EventEstablished events with  AttributeThisQueue xxxxx telephony events from either tserver or statserver for Inbound calls.

    Offline bcyk

    • Full Member
    • ***
    • Posts: 113
    • Karma: 6
    Re: Communications DN
    « Reply #5 on: September 25, 2008, 06:46:45 PM »
  • Best Answer
  • Communication DN type is for OCS and user-defined messaginng based on T-server UserUserEvent.

    By default, Communcation DN is created for OCS server messages
    When using communication DN as user-defined messaging, the option "outbound_contact_server" should be set to false.
    e.g., properties of "MYCOMDN"
    -> Annex tab
    -> OCServer folder
    -> outbound_contact_server = false


    Communcation DN can be alphabet name or numeric DN that not defined in switch.
    Since communication DN is NOT defined by switch, the [register] option in General tab should be 'false' (or unchecked in older CME version)



    To cater specific requirement, one of feasible methods is to register the set of DNs in inbound calls environment.
    A single T-server connection allows multiple DN registrations; the customized application may read the set of DNs from external source such text file or database table.


    Another easiler way but not available since Geensys 7.0 is to monitor all DNs defined in T-server.
    T-lib functions are TRegisterAll() / TUnregisterAll(); they (and some other functions such as TRoute) were removed from T-server library since 7.0. It is not sure if TRegisterAll() function is included in Java before version 7.0.

    These functions (TRegisterAll(), ....) are "accessible" linking T-lib 5.1 together with T-lib 7.2. However, native T-lib (C-language) was put into end-of-life cycle....

    In short, the first method may be the only choice.


    Offline kowari

    • Jr. Member
    • **
    • Posts: 53
    • Karma: 0
    Re: Communications DN
    « Reply #6 on: September 25, 2008, 10:10:30 PM »
  • Best Answer
  • [quote author=jim_1 link=topic=3356.msg13995#msg13995 date=1222360071]
    Hi,

    If commdn is only useful for outbound solutions, is there a mechanism for the 3rd party apps, to receive say EventEstablished events with  AttributeThisQueue xxxxx telephony events from either tserver or statserver for Inbound calls.
    [/quote]

    Have the appliaction connect via SDK to the tserver and register the DNs you are interested in listening to.  More than one thing can register an interest in a DN... or nothing in genesys would work :)

    Alan F

    • Guest
    Re: Communications DN
    « Reply #7 on: September 26, 2008, 11:11:50 AM »
  • Best Answer
  • Hi,
    I've got a couple of questions about using RegisterAll with Java so I can monitor events. I'm thinking of trying the following in a TServerDispatcherHandler...

    [code]
                final XKVList connectionConfig = new XKVList();
                connectionConfig.addString("host", "XXXtserver_hostnameXXX");
                connectionConfig.addInt("port", 3000);

                //the "OpenServerX" version...
                tserver.OpenServerX(connectionConfig, this, "XXXtserver_nameXXX", null,
                        Genesys.TLib.TServer.OpenMode_Async);

                //POSSIBLY NOT SAFE???
                tserver.RegisterAll(null);
    [/code]

    Firstly, will this work?

    I've been told that it might be unwise to send a null as an argument in the RegisterAll method. Would this mean that absolutely everything would be registered and that the tserver may become overloaded with sending me events?

    If instead, it's been suggested that I specify what I want to register, how do I do this? The argument is a TKVList, but I can't find any documentation telling me what I should put in it.

    Any advice very very much appreciated.

    Offline victor

    • Administrator
    • Hero Member
    • *****
    • Posts: 1419
    • Karma: 18
    Re: Communications DN
    « Reply #8 on: September 29, 2008, 12:17:13 PM »
  • Best Answer
  • There should not be a problem with RegisterAll, because from my experience so far, I have yet to see an application to overload a T-Server. So far, it did not give us any trouble on 3000+ seat call center. Realistically speaking, unless it is something huge and you have lots of applications that do this, I would not worry about it. Plus, since you are probably going to test it in a lab for the load first, you would be able to tell if it is ready or not.

    This brings me to the next point:

    I was pretty sure that Communication DN was exactly for the purpose of allowing third-party applications to talk to each other. I did not know it was only limited to OCS, because the whole concept of OriginAppDBID and TargetAppDBID would allow you to identify who you want to talk to. And of course, the fact that ICS used to use CommDN re-enforces my position.

    It seems to me that OCS protocol is a subset of what is possible with CommunicationDN. Am I wrong?

    Offline Dionysis

    • Sr. Member
    • ****
    • Posts: 408
    • Karma: 8
    Re: Communications DN
    « Reply #9 on: September 29, 2008, 01:24:54 PM »
  • Best Answer
  • No, you are not wrong victor.

    Theoretically anything that registers for the COMDN can send and receive user events for it.  However, once it is created it will not simply start receiving all telephony events.

    To use COMDN in this way you would need to create a TServer client that registers for all DN's, and then relays them back to the TServer as user events on the COMDN.  Which is counter productive really.

    If all you need is for the custom application to receive all events then simply register for all DN's and you're done.

    The TServer will not become overloaded, this operation is exactly what statserver performs and there is usually no problem there unless your TServer is severely under powered.  In my own environment I run a single server that handles URS, 3 production TServers, plus 3 production Stat Servers doing both routing and reporting for 2000+ seats and have no issues with TServer load.  That single box handles upwards of 50k calls per day.

    oh and btw... Victor, what's this "Lab" thing you're talking about?   >:D
    ;D


    Alan F

    • Guest
    Re: Communications DN
    « Reply #10 on: September 29, 2008, 01:43:05 PM »
  • Best Answer
  • I've never heard of a of a lab either. Perhaps someone can enlighten me.  ;D

    Thanks for the info, it is reassuring and I'm keen to try it, but I'm still not sure how to do this. Does just passing the null argument to RegisterAll do this and if not how do I construct my TKVList?


    Alan F

    • Guest
    Re: Communications DN
    « Reply #11 on: October 03, 2008, 01:24:54 PM »
  • Best Answer
  • Just one little bump - hope nobody objects.  :)