Reading Variables Set By Ecr With The Client Sdk

[tniercke]

Hi all,

 

I have a small question, which can hopefully be answered in here:

 

Someone wants me to develop an Swyx-Integration to some CRM-System, so the according Contact Pops up.

That is no big deal using the ClientLineManager from the SDK.

 

The big Problem is: The caller has to insert his customer-number within an ECR-Script. That customer-number has also to be transfered to the CRM.

Now here is the question:

Is it possible somwhow to read the Contents of a variable set by an ECR-Script within the CLMgr ?

 

With hope to an answer,

Thomas

[Tom Wellige]

Hello Thomas,

 

if you just the dtmf digits the caller entered just into a GSE variable or a standard VBScript variable, then the answer is no.

 

You have to store them somewhere else, e.g. a file or a database from which you pick them later up again.

 

 

 

Tom.

[tniercke]

Thanks for your answer, Tom.

I already suspected this.

 

It will be a nice thing for a feature-request for future SDK releases.

Call-Attached Data becomes more and more important in szenarios where a CRM or the like is involved.

 

Greetings

Thomas

[Tom Wellige]

Thomas,

 

it has been discussed many times in the passed but until now never made it into the product.

 

When storing user data within the call routing script you somehow have to pass a unique identifier to the client so that your client sdk app can load the data again. The unique call id which can be read within the call routing script (PBXCall.CallID) can't be used for this purpose, because once the call is connected to a client a request of DispCallId on the ClientLineManager will return another id. This is because the transfer of the call from the script to the client generates a new call id. Only after the call these different call ids can be matched together via the call details records again.

 

There is a simple (although somehow dirty) way to do that:

 

Lets assume you stored your user data and need to pass an id "12345" to the client so the data can be grabbed from there again using this id.

 

The trick is, to add the id to the caller name (which is displayed in the client or phone) an can be manipulated upfront within the call routing script.

 

Of course everything you add is displayed, so the idea is to add lots of blank character first, so the id will not be visible in the SwyxIt! or phone display.

PBXCall.CallingPartyName = PBXCall.CallingPartyName & "                           " & "12345"

Within your ClientSDK app you just look into DispPeerNumber of the CClientLine object the call is signaled on, and strip the id and the blanks away again.

 

 

I know, that an ugly way, but currently the only possible way I am aware of.

[tniercke]

Hi Tom,

 

that does indeed look like an easy and useable method, even if it has a touch of "quick-and-dirty".

I think we would use this solution for now.

 

Maybe someone at Swyx can provide some extra member variable for such a tag to the CLMgr (like the "Tag"-Member in many .NET-Classes for Form-Controls).

Such a Tag could be set analogue to the CallingPartyName and equally be read within the CLMgr.

That would Keep the CallingPartyName clean and should only be a simple and easy to implement Extension (private member-variable, Get- and Set-Property)

 

I will mark this thread as "answerd".

 

Thanks again.

 

Greetings

Thomas

[Tom Wellige]

That would Keep the CallingPartyName clean and should only be a simple and easy to implement Extension (private member-variable, Get- and Set-Property)

 

Thomas, it is a little bit more...

 

The server needs to keep this data (database, config data store api, server script api), the data needs to be transferred to the client via SIP, the client needs to handle the data (client line manager, client sdk).

 

This is unfortunately more then a "quick" modification, especially as different development teams are involved, including quality assurance.

 

And that's exactly the reason why it hadn't made it yet into the product, unfortunately. Plus the fact it has been requested only one or two hands full of times within the last 10 years...

[tniercke]

Hi Tom,

 

now I see and understand.

 

Many thanks for your clarification.

 

Thomas

[Tom Wellige]

You're welcome