Retrieving IP and agent email from strategy

[Gef Buneri]

Hello all, hope everyhing's fine around there.

Assuming URS 8.1.4, there's a way I can retrieve the IP of the Place where the agent receiving the call is logged in, or his email address?


Best,
Gef

[cavagnaro]

No. IP address is part of SIP server and it is a media information, not part of TLib. Why would you like to?

Enviado de meu SM-S918B usando o Tapatalk

[Gef Buneri]

Hi Cav. I'm integrating Dynamics within Engage, but no way to obtain GPlus for Dynamics at this moment. I already developed a workaround that works with a little agent operation (one click), but I'm trying to understand if it would be possible to invoke an API from router, pointing directly to agent client via IP.

[cavagnaro]

No, again, urs has no clue about IP details. That is PBX and tserver job

Enviado de meu SM-S918B usando o Tapatalk

[Gef Buneri]

Any chance to custom export that info to make it available realtime to URS when routing using any matching parameter to join Agent (or place) and its IP? an API or so.

[cavagnaro]

Just think on how routing works Gef, URS select a target from a group of agents based on some metrics, like most available time for example, right?
Then selects target (ID) and instructs Tserver to route to that ID, TServer then receives this ID and says... Ohh this guy is a local ID, because could be external too, right? When says it is local, it sends the command to the PBX, and the PBX handles this, could be digital, analog or IP device.
In case of SIP Server, own sip server handles this and then yes, you have an IP which is then just known by that layer.
So propagating this information to up URS level is impossible.
What about the scenario route command fails? Network issues for example? What then?
That is why all CRM integrations are usually done at agent endpoint. EventRinging and you trigger the integration.

What I have done in the past is for example to send the information of which agent was targeted after Target object, to fill a DB with this information. Then "something" is reading this DB every 5 seconds to see new interactions and agents, this app knows the agent vs IP address and sends the command to the IP address for a pop-up. But again, here the problems began with network issues. So if you network is good, it works. If not... Prepare for issues.



Enviado de meu SM-S918B usando o Tapatalk

[Gef Buneri]

Totally agree. I'm curious about trying to expose an API that tries to ping the place assuming it is basically the hostname of the workstation where the agent logs in.

[hsujdik]

I have a suggestion that might work but I'm not entirely sure since I do not have anything prepared to test it. It will depend a lot on your architecture though.

1. The agents SIP Endpoints would need to be directly registered to Genesys SIP Server (and not through a Session Border Controller);
2. You would need the option "internal-registrar-persistent" set to True on your SIP Server. And also, for this to work, the account that SIP Server is starting as (usually "SYSTEM") would need to have change permissions on the extensions DNs. This way, whenever a SIP Endpoint registers to an Extension, SIP Server would update its "Annex" tab / "contact" option with the SIP URI to reach the Endpoint (e.g. TServer\contact = sip:10.10.10.10:5090)
3. Instead of a regular "Select Target" block on your strategy, you use the "expanded" version: SelectDN, SuspendForDN, TRoute... This way you are able to get the DN that has been targeted (another approach would be to use the "Custom Routing" on the General tab of the "Select Target" block);
4. Once you have the DN that has been selected using the step 3 above, use URS function "GetObjectProperty" to retrieve the option TServer\contact of that given DN;
5. Parse the retrieved result form step 4 by removing the "sip:" prefix and the port number suffix (if applicable).

Again, I'm not sure if this will work since I cannot test it, and also depends if your environment falls on condition "1" above and your SIP Server is configured as "2" above.

[Gef Buneri]

Thank you Hsujdik. Love your theory and I'll try this method for sure; internal-registrar-persistent is set as true already. Permissions are ok too.


I'll let you know asap.

[Kubig]

I definitely agree with hsujdik - just note that the IP address in contact option on DN level is related to the registered SIP endpoint, which could be different from IP address where agent app (ie WDE) is registered via TLib

[hsujdik]

[quote author=Gef Buneri link=topic=12486.msg55500#msg55500 date=1702558513]
Thank you Hsujdik. Love your theory and I'll try this method for sure; internal-registrar-persistent is set as true already. Permissions are ok too.


I'll let you know asap.
[/quote]
Let me know if you do it... I'm curious if that works

[Danielpoope]

Is it possible to leverage unconventional programming languages or frameworks, such as Rust or Go, to enhance the performance and scalability of Genesys CTI integrations beyond what traditional techniques offer? Has anyone explored such alternatives and achieved significant improvements in terms of speed and resource utilization?

[Gef Buneri]

[quote author=Gef Buneri link=topic=12486.msg55500#msg55500 date=1702558513]
Thank you Hsujdik. Love your theory and I'll try this method for sure; internal-registrar-persistent is set as true already. Permissions are ok too.


I'll let you know asap.
[/quote]

Hello guys, hope everything's fine out there. Sorry for the delay but I was totaly caught in a project, but confirmed, the method suggested by Hsujdik works perfectly to retrieve the SIP contact of the DN containing the IP address, and depending on the system configuration that IP can be used to identiify the extension DN the interaction is routed to. It is mandatory that the DN (or any object excluding transaction and agents) have got an alias, because the name must be the alias. Another little stone to my experience, thank you very much.

[victor]

Brilliant!

[quote author=hsujdik link=topic=12486.msg55486#msg55486 date=1701866391]
I have a suggestion that might work but I'm not entirely sure since I do not have anything prepared to test it. It will depend a lot on your architecture though.

1. The agents SIP Endpoints would need to be directly registered to Genesys SIP Server (and not through a Session Border Controller);
2. You would need the option "internal-registrar-persistent" set to True on your SIP Server. And also, for this to work, the account that SIP Server is starting as (usually "SYSTEM") would need to have change permissions on the extensions DNs. This way, whenever a SIP Endpoint registers to an Extension, SIP Server would update its "Annex" tab / "contact" option with the SIP URI to reach the Endpoint (e.g. TServer\contact = sip:10.10.10.10:5090)
3. Instead of a regular "Select Target" block on your strategy, you use the "expanded" version: SelectDN, SuspendForDN, TRoute... This way you are able to get the DN that has been targeted (another approach would be to use the "Custom Routing" on the General tab of the "Select Target" block);
4. Once you have the DN that has been selected using the step 3 above, use URS function "GetObjectProperty" to retrieve the option TServer\contact of that given DN;
5. Parse the retrieved result form step 4 by removing the "sip:" prefix and the port number suffix (if applicable).

Again, I'm not sure if this will work since I cannot test it, and also depends if your environment falls on condition "1" above and your SIP Server is configured as "2" above.
[/quote]