Howto:Ticketing

Summary

Howto Create a simple Ticketing System.

Users of this solution are typically small companies with a very special, but logical request: calls should be recorded and a ticket number assigned to the call.

The calls in most cases goes to a GSM Phone and not to a fix phone; so the ticket number should be transmitted via SMS to the cellular Phone. Of cause there are more mobile phones in use and in a round robin mode if one is not answering all should be called. And the first mobile phone to call is not always the same one; this should be settable by the customer itself. The voice recording should start just for these special calls (and not in case of “regular” phone calls) and the ticket number should be transmitted just to the mobile phone which answered the call or on which the caller gives up (and not to all in the hunting users).

External caller could be in panic, and therefor the system should release when the called user hangs up, even if the caller is not releasing.

The Start ticket number should be settable and a log of all calls should be written. In this log all calls and hops should be visible and the last or answered call distinguished.

Internal phone sets should be receive an instant messaging containing the same data then the SMS.

Because the companies will be, as explained often very small, all that should work “out of the box”, so without the need of external software or PC, and work even on small hardware like an IP302, means on hardware without application processor.

Example: a gas distribution company covers a small area where support must be done. If a customer calls in the out of office hour (or maybe even if in…), he has the option to reach a technician even if the company is closed. First he will hear an advice that this call will be recorded and that this type of call is to use just in case of emergency or similar. If the caller proceeds and confirms (for example dialing a “1”) a support guy will be called, a ticket opened, the conversation recorded and at the end of the call the technical will receive a SMS on his mobile phone indicating the caller number and the ticket number. A log will be written where start and stop date and time, caller, called number and ticket is reported. In this log is also visible if the call has followed a CFNR and the last user. If the called user will not answer the next on in the path will be called.

Applies To

Innovaphone PBX version 9, hotfix 17 or higher

Nor forking license is required, but for each external user must be registrated a PBX user in the PBX (an IP Phone or an analogue port).

More Information

Usage

A caller calls a WQ where all the preliminary information (advice that the call will be recorded etc.) is played and he must press a key to proceed. Then the system looks who is actually in charge and will call him. The call is done to the internal Phone and in parallel if configured to the external destination (call forking). If the first called user will not answer, the call will go to the next one. There is no limit for this type of hunting and the last one can point to the first one.

Example: 3 User, Tech1, Tech2 and Tech3.

Tech2 is in charge and will receive at first the call, if he is not answering the call goes to Tech3, then to Tech1 and then again to Tech2.

It is also possible not jump to the first caller back again; all this is just a question of setup. The selection of the first caller is done by default on a predefined user, but can be modified using the follow me feature (or doing a CFU on a specified phone set). See relative feature description.

Voice Recording starts in the moment when the caller presses a number and the call is transferred from the WQ to the further call processing. In this way just emergency calls will be recorded while normal calls will follow another path. Recording is done in the pcap mode, to convert the audio file in a wave file user the pcap2wave utility (available in the download area). The recording stops when the line is released, so the recording will contain also the ringing period. Therefore a claim about the duration of answer or similar can be easily proven, you have just to listen the call and can so follow exactly the call story.

When a called user releases the call (on the fix phone or on the mobile one) instant messaging (IM) is done on the IP-Phone and a SMS can be send to the mobile phone. The contend is in both cases the same: Start Date+Time , End Date+Time, Ticket Number, Number of caller, Number of called user.

Example of IM/SMS string:

12.10.2012_14.00_12.10.2012_14.05_Ticket_1234_Caller_03472619287_Called_732

Explanation: Call started at 14:00 and goes until 14:05 (call duration 5 minutes), Ticket number 1234, the caller was the number 3472619287 and the called one the extension 732.

Please note that the number of the caller contains prefix of the local trunk line (in the example “0”). In case of IM this number is indicated even as destination, so lifting the receiver will call back.

Please note that in the ticket is not indicated the forking number. But it is simple to retrieve it in the PBX because the association between forking and internal number is there. Means that this call could be answered form extension 732 or associated mobile phone, the result in the ticket is the same (you will see always just the internal number).

On top in the directory “ticket” on the CF of the PBX log files are written, the format of the log file is the same then the one of the IM and SMS. The only difference is that at the end of the file there is a serial number (typically “_1”), this is necessary because it could be that in the same minute the same call is done twice. The file extension is “.txt”, the length is zero so a reasonable number of records can be done.

In the log you will also see if the call is reached to an end or not.

An IM or SMS will be done just to the user witch answered a call or to the last called user. So if for example the call goes first to the extension 731 and after that to the extension 732, just the extension 732 will receive a message. This happened independently if 732 answers the call or the caller gives up during ringing of the 732. The key point is that 731 will not receive any IM/SMS.

In the ticket directory will be recorded all the hops, and therefore for each hop a Ticket number is opened.

This means for the user that Ticket Gaps in the message means no answered calls.

Example of ticket log:

12.10.2012_14.00_12.10.2012_14.00_Ticket_1234_Caller_03472619287_Called_732

12.10.2012_14.00_12.10.2012_14.02_Ticket_1235_Caller_03472619287_Called_731_END

There was first ringing the extension 732, then the system has opened a new Call and new ticket to 731. 731 has answered the call (or the caller has given up), 731 receive an IM and SMS while the record shows “END” at the end of the name. A tracking of calls is therefore easily possible, just observe the listing and anything is clear.

How it works

Of cause it works with an VM object and therefore an XML. It is quite tricky and hopefully you will not know it. Just follow the instruction of the setup, but if you really want to know, well see the XML, it is all written in there….

Installation

Copy the content of the ZIP file to a directory on the CF, in our example we have create a directory “TicketSMS”.

Now create for each extension a directory, in our example we have two extensions, 732 and 731. The directory “Ticket” will be created automatically and contain the Log files.

The xml setup is done writing values in the .txt files, each file has just on value in.

The XMLnumber.txt contain the number of the XML itself, in out PBX it is “799”, so the contend is “799”.

The file TickeNR.TXT contains the ticket number, the XML will increase this number each time a ticket is created. So if blank the first Ticket will be “1”. If you want to start for example with 100 (or reset the numbering after a period) just write in the desired value.

The File “SMSProvider.txt” contain the name of the SMS provider, “CODEMA” as default, see relative feature description for details.

The file “SMSprefix.txt” contain the national prefix, in Italy “39” (without “0” or “+” or “00”), it depend on the provider.

The file “CFU.txt” contains the name (!, not number) of the object handling the CFU feature. In our example we called it “TED_CFU” and therefore this is the value.

To send SMS are necessary additional information, those are stored in the single user directory because thy will depend on the user.

In the example you see the user 731 directory, there are 3 configuration file in:

“SMSNumber.txt” contains the number of the GSM Phone.

“SMSUser.txt” and “SMSPassword.txt” contains the credential data, values given from the Provider.

The rest of the setup is done in the innovaphone PBX setup.

Configuration

First create a VM object pointing on the XML. In our example we give him the number 799, please note the particular extension on the link:

After the usual path follows “?$_divconn=false”

If you want the same CFNR timeout for all object a template would be fine, we create one and called him “TED_CFG_TMPL_01” and associated it to the user.

Here a view of the example, observe the user 731 and 732, those are the targets, as you see both have a fork to an external GSM Phone. Remember that those users have to be “real” users and registred in the PBX but…you can register one IP Phone on more numbers…).

Observe the CFNR, the number is the XML object followed by the next hop. So 731 point to 799732 while 732 points to 799731.

Ops, forget the description for TED_XML_OP03, it was just a test, sorry.

The Object TED_CFU is the one for the routing of the first user. In the example it has a CFU to the user 732, so even if the trunk will point to user 731 as default the call will start on 732. If this CFU is cleared, the 731 will ring first. This object is fully “dummy”, the XML will just read out the status….

The Waiting Queue (so that is the object called by the real ISDN trunk) is called in the example (you are of cause fully free) TED_WQ10 and has the number 720. So for testing just call 720. WQ is hopefully clear (otherwise we offer fine training courses), the following picture shows the mapping, and we mapped “1” to the Trunk object.

The trunk has nothing particularly, a good idea is flagging “Automatic Hangup” in the Trunk section.

Last Item, the routing:

As you see there is a simple route form the trunk up to the XML and the default (first) user.

Note the “*”, so the mapping is not 799731 but 799*731, and don’t forget the “!” (so it will be “!” -> “799*731”)

The gateway for the recording (in our example GW14) is configured like this:

As you see in the example the path for the recording is ….CF0/TED_RECORDING/, in that directory will be stored the voice files.

Testing

To test forget the forking and GSM and test anything first with innovaphone IP-Phones.

Known problems

Calls will be done even on busy user. If the user is on an IP-Phone he will see the second call and can answer. If he is in a conversation on the mobile phone it depends of the GSM setup: nothing happen, busy advice is done and the user can switch to the second call or a SMS from the GSM carrier is received. If the user will not answer the call it will hunt to the next user after the CFNR timeout in the same way than on not response. The caller hears in the meantime call control.

The release of the call in case is the moment of starting to send the IM/SMS. If you call the WQ internally (so not from a trunk line, typically just if you do some test) the release of the call is just done if the caller release.

Download

• http://download.innovaphone.com/ice/wiki-src#ticketing - download the complete file package of scripts and files described in this article.