Support for Queues about restcomm-connect

[deruelle]

Please note currently the old Twilio way of doing queues is supported (see https://github.com/caseysoftware/twilio-call-queue-howto) but not the Queue verb itself

[deruelle]

Also add support for RCML verbs https://www.twilio.com/docs/api/twiml/enqueue and https://www.twilio.com/docs/api/twiml/leave

[muhammadbilal19]

@gvagenas @deruelle
I am slowly exploring the application along with working on this issue. Now i think it is good time to start discussing things so that everyone can give suggestions and help me to go on the right path.

First part of this task is to introduced two new
Rest API Queue(/2010-04-01/Accounts/{AccountSid}/Queues/{QueueSid}) and Members(/2010-04-01/Accounts/{AccountSid}/Queues/{QueueSid}/Members/{CallSid})

This task is to create new Queue and Member Endpoint. For the API operation and request/response twilio link has all the details and i think we need to use the same operation and request/response structure as mention on these link unless we feel something else we need in our API, correct me if i am wrong.

i will build a prototype of request/response structure and operations and will share it with you guys for comments. In this task we also need to manage queues which according to comments on this task we are already managing with some old ways. Can you guys let me know how can i test the old way of call queue ?

Queue Management:
This is an important thing in this task as i need to find out whether we have queue functionality which is already available in restcomm, and we will utilise that queue functionality in our new API's. If queue functionality is not there than we need to build queue functionality which will fulfil our requirements. After some let me know the current state of this functionality than we can discuss further about it.

RCML for Enqueue and Leave:

I am looking into the code for rcml to understand how it is working, although look like to me we need to introduce a new parser for that but i am currently understanding the existing functionality which not yet cleared to me so i cannot give much comments on it.

[muhammadbilal19]

@gvagenas @deruelle
I created a branch for this task https://github.com/muhammadbilal19/Restcomm-Connect/tree/Issue1_QueueAPI to update the progress on it. I just created a basic structure of API methods by reading the details from https://www.twilio.com/docs/api/rest/queue and https://www.twilio.com/docs/api/rest/member

I will post the proposed request/response structure of Both API's soon.

Regarding the problem which i discuss in last comment regarding managing queues. I am not sure that whether we already have some mechanism in restcomm to achieve queue functionality, If i suppose that it is not there and i need to implement that than i was thinking about some solutions to resolve it.

• First solution which i think is to use Java Collection framework to create memory data structures and manage it programatically.
• Second solution is to use some in memory NoSQL database which support key/vale pair data structure. One in my mind is http://redis.io/

Still i am investigating to look for some good and possible solution to implement it. What you guys think about it ? might be you guys have some better solution for this problem.

[deruelle]

@muhammadbilal19 great.

We don't have a mechanism in restcomm to achieve queue functionality.

You're right that this has to work flawlessly on multiple Restcomm nodes so that if someone issues a request to add or remove a member of the queue, the change has to be seen by all nodes in terms of consistency. We currently use a RDBMS such as MySQL / MariaDB / Oracle for the DB and don't have a distributed in memory datagrid yet in Restcomm.

I'll let @gvagenas comment as project leads on potential directions

[gvagenas]

Hi @muhammadbilal19 , great progress.

For queue management, keep in mind that we need to support this feature in a cluster of Restcomm nodes as @deruelle so data structure in memory is not an option.

Since we already working with MySQL/MariaDB and MyBatis, I would suggest you to use the same for the queue management and if latter we see that this creates problem we can consider a distributed cache.

Thanks
George

[muhammadbilal19]

Thanks @deruelle and @gvagenas for your comments. @gvagenas you mention maliha in the comment by mistake :)

Going more into the detail of queue issue now i came to know that memory option will not work according to our requirements as we need to persist queue data. I have one solution in my mind for which i am also creating one demo to see how it will work. Solution will be implemented using the existing technologies so we don't need to introduce any new thing in application.

Solution :

We will achieve queue functionality by using database table. Suppose the name of table is queue . Queue table structure will look like this.

Queue Table Structure

Column	Data Type	Description
Queue SID	VARCHAR(36)	queue unique id and also primary key
Date Created	DATETIME	queue creation date
Date Updated	DATETIME	queue update date
Account SID	VARCHAR(34)	account with the queue attached
friendlyName	VARCHAR(64)	friendly name of queue
averageWaitTime	DOUBLE	store wait time of this queue
maxSize	INT	store size of this queue
queueJson	CLOB OR any data type which will support all databases used in our application (not decided yet)	store json format of queue string (encoded)

Json with 10 members currently in queue store in queueJson column

[
    "bf138d63e6c8486287c00b0d31d86c49",
    "f7a944c0ac2944ecbfa8a5e3933bd2da",
    "9b8e6bcddff44364b2d017af4fbcf3bd",
    "6c8eda69be614c17b0d79d7e2b52faa2",
    "4c562339ab07424a9c9686a52013e6aa",
    "1f1795c2108247a0b8148ebf70cbdb6c",
    "906e04cb17a043bc96599c1a706229d4",
    "2ca3694fec9849429b2fb9c413b2b8f9",
    "158bb03b86b64caf9a2e59261f383b0c",
    "e68a4b6b9e22443d97fbbffe058ad0b4"
]

Note : This json will represent a queue data structure storing members ids who are currently in this queue. Queue data structure will maintain the order in which members are pushed into the queue. Json string will be encrypted and the encrypted bytes will be stores in the database.

@gvagenas @deruelle share your thoughts about this solution?

[gvagenas]

Hi @muhammadbilal19 , sorry for the mistake i did to your username in the previous comment.

Let me first clarify that the members of a queue will be client registrations and Restcomm queues will work together with Restcomm presence (PR still pending #524) so the queue algorithm will check the available agent and pick the next agent to route a call to the queue.

Keep in mind that the algorithm that will be used to pick the next agent could be pluggable, for example, a user might choose to use round-robin, or serial calling etc. Important here is to provide an API so other users can provide their own implementation for queue algorithm.

Now in terms of the database schema, my comments:

• If a registered client is part of a Queue, his registration record in the DB should reference the Queue SID
• I am not sure if it's good to keep 'averageWaitTime' in the database, this is a calculation that we need to provide for reporting but not sure if it's good to keep it in the database. I believe in the DB table we should have all the fields needed to get the calculations, for example answer time for every call in the queue to get the average answer time or average wait time, talk time to get the average talk time etc. We need to think more about reporting
• Similar the 'maxSize' doesn't need to be there, we can get the number of members (client registrations) by querying the DB for client registration that are memebers of a Queue SID.
• Last 'queueJson', as I told you members will be client registrations so to get the members of a queue we will query the registration table.

Regards
George

[deruelle]

@gvagenas reading https://www.twilio.com/docs/api/rest/member it doesn't seem to require any algorithm, it seems up to the application to decide how to dequeue (ie by CallSid or Front) right ?

Also it seems more related to calls than client registrations see https://www.twilio.com/docs/api/twiml/enqueue

Also maxSize is defined at https://www.twilio.com/docs/api/rest/queue and it seems to me that it is required to put that into DB, right ?

[muhammadbilal19]

Thanks @gvagenas for your response.
We can create queue with QueueSid in the application and we can also update maxSize and FriendlyName that's the reason why i put these fields in DB. AverageWaitTime i cannot see that it can be updated so we can remove that field from DB table.Related to the algorithm i don't see any details about it as i also use twilio-java-sdk its behaviour is same as mentioned of the api reference links. If you have more details about it please share.
I think may be you are talking about this https://www.twilio.com/docs/api/taskrouter/rest-api just guessing:)

@deruelle you are right member api is used to get the details of members who are waiting in the queue. Dequeue has two option front and by CallSid. As we need to keep track of maxSize of each queue so we must need to save that field.

[gvagenas]

@deruelle you are right about the maxSize, I misunderstood, this is the max number of queued calls for a queue. Agree also on the enqueue and the members.

My suggestion was to provide a better and extensible way to handle calls in queue by having an algorithm to dequeue by checking available clients (with Presence) and other rules, but it might be too much for the current phase so lets forget it for now.

@muhammadbilal19 follow the API as is now

[deruelle]

@gvagenas very good idea. Can you please create a follow up issue for managing agents and dequeue algorithms ?

[gvagenas]

@deruelle sure, here it is #1115

[muhammadbilal19]

@gvagenas @deruelle I started working on API development for Queue and Member. Current table structure which i use for queue table

CREATE TABLE "restcomm_queues" (
"sid" VARCHAR(34) NOT NULL PRIMARY KEY,
"date_created" DATETIME NOT NULL,
"date_updated" DATETIME NOT NULL,
"friendly_name" VARCHAR(64) NOT NULL,
"account_sid" VARCHAR(34),
"current_size" INT,
"max_size" INT,
"uri" LONGVARCHAR NOT NULL,
"queue" BLOB
);

Sample request/response which i so far develope

http://127.0.0.1:8080/restcomm/2012-04-24/Accounts/ACae6e420f425248d6a26948c17a9e2acf/Queues

GET /restcomm/2012-04-24/Accounts/ACae6e420f425248d6a26948c17a9e2acf/Queues HTTP/1.1
 HOST: 127.0.0.1:8080
 authorization: Basic YWRtaW5pc3RyYXRvckBjb21wYW55LmNvbTphYWE3ZDdlNzRiMWY5NjVmZmJlNWQ0NTE3OWM4NjdhNA==

<RestcommResponse>
  <Queues page="0" numpages="0" pagesize="50" total="0" start="0" end="4" uri="/restcomm/2012-04-24/Accounts/ACae6e420f425248d6a26948c17a9e2acf/Queues" firstpageuri="/restcomm/2012-04-24/Accounts/ACae6e420f425248d6a26948c17a9e2acf/Queues?Page=0&amp;PageSize=50" previouspageuri="null" nextpageuri="null" lastpageuri="/restcomm/2012-04-24/Accounts/ACae6e420f425248d6a26948c17a9e2acf/Queues?Page=0&amp;PageSize=50">
    <Queue>
      <Sid>QU53133a9b84dc4f82bd6db4a93d07c655</Sid>
      <FriendlyName>first_Queue</FriendlyName>
      <CurrentSize>8</CurrentSize>
      <AverageWaitTime>0</AverageWaitTime>
      <MaxSize>500</MaxSize>
      <DateCreated>Sat, 28 May 2016 19:18:40 +1200</DateCreated>
      <DateUpdated>Tue, 31 May 2016 14:23:55 +1200</DateUpdated>
      <Uri>/restcomm/2012-04-24/Accounts/ACae6e420f425248d6a26948c17a9e2acf/Queues/QU53133a9b84dc4f82bd6db4a93d07c655</Uri>
    </Queue>
    <Queue>
      <Sid>QU688e0491e8424d56b2c3c134677787be</Sid>
      <FriendlyName>fourth_queue</FriendlyName>
      <CurrentSize>0</CurrentSize>
      <AverageWaitTime>0</AverageWaitTime>
      <MaxSize>400</MaxSize>
      <DateCreated>Tue, 31 May 2016 12:33:31 +1200</DateCreated>
      <DateUpdated>Tue, 31 May 2016 12:33:31 +1200</DateUpdated>
      <Uri>/restcomm/2012-04-24/Accounts/ACae6e420f425248d6a26948c17a9e2acf/Queues/QU688e0491e8424d56b2c3c134677787be</Uri>
    </Queue>
    <Queue>
      <Sid>QU6d58d6d2a3cc45e9bfcb6020060a3baf</Sid>
      <FriendlyName>SecondQueue</FriendlyName>
      <CurrentSize>1</CurrentSize>
      <AverageWaitTime>0</AverageWaitTime>
      <MaxSize>300</MaxSize>
      <DateCreated>Sat, 28 May 2016 19:52:01 +1200</DateCreated>
      <DateUpdated>Tue, 31 May 2016 14:25:28 +1200</DateUpdated>
      <Uri>/restcomm/2012-04-24/Accounts/ACae6e420f425248d6a26948c17a9e2acf/Queues/QU6d58d6d2a3cc45e9bfcb6020060a3baf</Uri>
    </Queue>
    <Queue>
      <Sid>QUa6143718bb804013a2af3f6ee74acbf3</Sid>
      <FriendlyName>third_queue</FriendlyName>
      <CurrentSize>0</CurrentSize>
      <AverageWaitTime>0</AverageWaitTime>
      <MaxSize>500</MaxSize>
      <DateCreated>Tue, 31 May 2016 12:32:51 +1200</DateCreated>
      <DateUpdated>Tue, 31 May 2016 12:32:51 +1200</DateUpdated>
      <Uri>/restcomm/2012-04-24/Accounts/ACae6e420f425248d6a26948c17a9e2acf/Queues/QUa6143718bb804013a2af3f6ee74acbf3</Uri>
    </Queue>
  </Queues>
</RestcommResponse>

http://127.0.0.1:8080/restcomm/2012-04-24/Accounts/ACae6e420f425248d6a26948c17a9e2acf/Queues

POST /restcomm/2012-04-24/Accounts/ACae6e420f425248d6a26948c17a9e2acf/Queues HTTP/1.1
 HOST: 127.0.0.1:8080
 authorization: Basic YWRtaW5pc3RyYXRvckBjb21wYW55LmNvbTphYWE3ZDdlNzRiMWY5NjVmZmJlNWQ0NTE3OWM4NjdhNA==
 content-type: application/x-www-form-urlencoded
 content-length: 125

FriendlyName=fifth_queue&MaxSize=100

<RestcommResponse>
  <Queue>
    <Sid>QU71343994b9e64149aa1bd01b74f2f948</Sid>
    <FriendlyName>fifth_queue</FriendlyName>
    <CurrentSize>0</CurrentSize>
    <AverageWaitTime>0</AverageWaitTime>
    <MaxSize>100</MaxSize>
    <DateCreated>Tue, 31 May 2016 14:42:31 +1200</DateCreated>
    <DateUpdated>Tue, 31 May 2016 14:42:31 +1200</DateUpdated>
    <Uri>/restcomm/2012-04-24/Accounts/ACae6e420f425248d6a26948c17a9e2acf/Queues/QU71343994b9e64149aa1bd01b74f2f948</Uri>
  </Queue>
</RestcommResponse>

http://127.0.0.1:8080/restcomm/2012-04-24/Accounts/ACae6e420f425248d6a26948c17a9e2acf/Queues/QU71343994b9e64149aa1bd01b74f2f948

DELETE /restcomm/2012-04-24/Accounts/ACae6e420f425248d6a26948c17a9e2acf/Queues/QU71343994b9e64149aa1bd01b74f2f948 HTTP/1.1
 HOST: 127.0.0.1:8080
 authorization: Basic YWRtaW5pc3RyYXRvckBjb21wYW55LmNvbTphYWE3ZDdlNzRiMWY5NjVmZmJlNWQ0NTE3OWM4NjdhNA==
 content-length: 0

http://127.0.0.1:8080/restcomm/2012-04-24/Accounts/ACae6e420f425248d6a26948c17a9e2acf/Queues/QU688e0491e8424d56b2c3c134677787be

POST /restcomm/2012-04-24/Accounts/ACae6e420f425248d6a26948c17a9e2acf/Queues/QU688e0491e8424d56b2c3c134677787be HTTP/1.1
 HOST: 127.0.0.1:8080
 authorization: Basic YWRtaW5pc3RyYXRvckBjb21wYW55LmNvbTphYWE3ZDdlNzRiMWY5NjVmZmJlNWQ0NTE3OWM4NjdhNA==
 content-type: application/x-www-form-urlencoded
 content-length: 11

 MaxSize=250

<RestcommResponse>
  <Queue>
    <Sid>QU688e0491e8424d56b2c3c134677787be</Sid>
    <FriendlyName>fourth_queue</FriendlyName>
    <CurrentSize>0</CurrentSize>
    <AverageWaitTime>0</AverageWaitTime>
    <MaxSize>250</MaxSize>
    <DateCreated>Tue, 31 May 2016 12:33:31 +1200</DateCreated>
    <DateUpdated>Tue, 31 May 2016 14:53:01 +1200</DateUpdated>
    <Uri>/restcomm/2012-04-24/Accounts/ACae6e420f425248d6a26948c17a9e2acf/Queues/QU688e0491e8424d56b2c3c134677787be</Uri>
  </Queue>
</RestcommResponse>

http://127.0.0.1:8080/restcomm/2012-04-24/Accounts/ACae6e420f425248d6a26948c17a9e2acf/Queues/QU688e0491e8424d56b2c3c134677787be/Members/CA989e0491e8424d56b2c3c134677787be

POST /restcomm/2012-04-24/Accounts/ACae6e420f425248d6a26948c17a9e2acf/Queues/QU688e0491e8424d56b2c3c134677787be/Members/CA989e0491e8424d56b2c3c134677787be HTTP/1.1
 HOST: 127.0.0.1:8080
 authorization: Basic YWRtaW5pc3RyYXRvckBjb21wYW55LmNvbTphYWE3ZDdlNzRiMWY5NjVmZmJlNWQ0NTE3OWM4NjdhNA==
 content-type: application/x-www-form-urlencoded
 content-length: 0

<RestcommResponse>
  <object class="org.mobicents.servlet.restcomm.entities.Member">
    <QueueMember>
      <CallSid>CA989e0491e8424d56b2c3c134677787be</CallSid>
      <DateCreated>Tue, 31 May 2016 15:05:01 +1200</DateCreated>
      <WaitTime>0</WaitTime>
      <position>1</position>
    </QueueMember>
  </object>
</RestcommResponse>

http://127.0.0.1:8080/restcomm/2012-04-24/Accounts/ACae6e420f425248d6a26948c17a9e2acf/Queues/QU53133a9b84dc4f82bd6db4a93d07c655/Members

GET /restcomm/2012-04-24/Accounts/ACae6e420f425248d6a26948c17a9e2acf/Queues/QU53133a9b84dc4f82bd6db4a93d07c655/Members HTTP/1.1
 HOST: 127.0.0.1:8080
 authorization: Basic YWRtaW5pc3RyYXRvckBjb21wYW55LmNvbTphYWE3ZDdlNzRiMWY5NjVmZmJlNWQ0NTE3OWM4NjdhNA==

<RestcommResponse>
  <object class="org.mobicents.servlet.restcomm.entities.MemberList">
    <Members>
      <QueueMember>
        <CallSid>CAae9g420f425248d6a26948c17a9e2acf</CallSid>
        <DateCreated>Mon, 30 May 2016 22:58:32 +1200</DateCreated>
        <WaitTime>0</WaitTime>
        <position>0</position>
      </QueueMember>
      <QueueMember>
        <CallSid>CAae9g421f425248d6a26948c17a9e2acf</CallSid>
        <DateCreated>Mon, 30 May 2016 22:59:58 +1200</DateCreated>
        <WaitTime>0</WaitTime>
        <position>1</position>
      </QueueMember>
      <QueueMember>
        <CallSid>CAae9g423f425248d6a26948c17a9e2acf</CallSid>
        <DateCreated>Mon, 30 May 2016 23:00:13 +1200</DateCreated>
        <WaitTime>0</WaitTime>
        <position>2</position>
      </QueueMember>
      <QueueMember>
        <CallSid>CAae9g424f425248d6a26948c17a9e2acf</CallSid>
        <DateCreated>Mon, 30 May 2016 23:00:19 +1200</DateCreated>
        <WaitTime>0</WaitTime>
        <position>3</position>
      </QueueMember>
      <QueueMember>
        <CallSid>CAae9g425f425248d6a26948c17a9e2acf</CallSid>
        <DateCreated>Mon, 30 May 2016 23:00:27 +1200</DateCreated>
        <WaitTime>0</WaitTime>
        <position>4</position>
      </QueueMember>
      <QueueMember>
        <CallSid>CA54133a9b84dc4f82bd6db4a93d07c655</CallSid>
        <DateCreated>Tue, 31 May 2016 14:08:54 +1200</DateCreated>
        <WaitTime>0</WaitTime>
        <position>5</position>
      </QueueMember>
      <QueueMember>
        <CallSid>CA53166a9b84dc4f82bd6db4a93d07c655</CallSid>
        <DateCreated>Tue, 31 May 2016 14:20:01 +1200</DateCreated>
        <WaitTime>0</WaitTime>
        <position>6</position>
      </QueueMember>
      <QueueMember>
        <CallSid>CA63144a0b84dc4f82bd6db4a93d07c655</CallSid>
        <DateCreated>Tue, 31 May 2016 14:23:55 +1200</DateCreated>
        <WaitTime>0</WaitTime>
        <position>7</position>
      </QueueMember>
    </Members>
  </object>
</RestcommResponse>

http://127.0.0.1:8080/restcomm/2012-04-24/Accounts/ACae6e420f425248d6a26948c17a9e2acf/Queues/QU53133a9b84dc4f82bd6db4a93d07c655/Members/Front

GET /restcomm/2012-04-24/Accounts/ACae6e420f425248d6a26948c17a9e2acf/Queues/QU53133a9b84dc4f82bd6db4a93d07c655/Members/Front HTTP/1.1
 HOST: 127.0.0.1:8080
 authorization: Basic YWRtaW5pc3RyYXRvckBjb21wYW55LmNvbTphYWE3ZDdlNzRiMWY5NjVmZmJlNWQ0NTE3OWM4NjdhNA==

<RestcommResponse>
  <object class="org.mobicents.servlet.restcomm.entities.Member">
    <QueueMember>
      <CallSid>CAae9g420f425248d6a26948c17a9e2acf</CallSid>
      <DateCreated>Mon, 30 May 2016 22:58:32 +1200</DateCreated>
      <WaitTime>0</WaitTime>
      <position>0</position>
    </QueueMember>
  </object>
</RestcommResponse>

http://127.0.0.1:8080/restcomm/2012-04-24/Accounts/ACae6e420f425248d6a26948c17a9e2acf/Queues/QU53133a9b84dc4f82bd6db4a93d07c655/Members/CAae9g424f425248d6a26948c17a9e2acf

GET /restcomm/2012-04-24/Accounts/ACae6e420f425248d6a26948c17a9e2acf/Queues/QU53133a9b84dc4f82bd6db4a93d07c655/Members/CAae9g424f425248d6a26948c17a9e2acf HTTP/1.1
 HOST: 127.0.0.1:8080
 authorization: Basic YWRtaW5pc3RyYXRvckBjb21wYW55LmNvbTphYWE3ZDdlNzRiMWY5NjVmZmJlNWQ0NTE3OWM4NjdhNA==

<RestcommResponse>
  <object class="org.mobicents.servlet.restcomm.entities.Member">
    <QueueMember>
      <CallSid>CAae9g424f425248d6a26948c17a9e2acf</CallSid>
      <DateCreated>Mon, 30 May 2016 23:00:19 +1200</DateCreated>
      <WaitTime>0</WaitTime>
      <position>2</position>
    </QueueMember>
  </object>
</RestcommResponse>

This is so far some work which i did and it is available in my branch https://github.com/muhammadbilal19/Restcomm-Connect/tree/Issue1_QueueAPI. I am currently testing and reviewing the requirements according to twilio documentation of queue and members. Keep reviewing and putting your suggestions so that i can go on the right path.

[muhammadbilal19]

One thing which is not available in Members API is this post method https://www.twilio.com/docs/api/rest/member#instance-post according to the documentation, this method is use to dequeue a member and set the URL and method to begin the call. According to my understanding i don't need to save Url and Method values for members as it needs to execute the rcml only. Although i am currently trying to understand the RCML how it works as i need to implement https://www.twilio.com/docs/api/twiml/enqueue to enqueue members in queue.

I currently add enqueue method in Members API for testing i will move this method to some other place if it is required.

@gvagenas @deruelle Any guidance to quickly understand the rcml implementation/testing will help me.

[gvagenas]

@muhammadbilal19 very good progress, great job!

I don't understand your question for the RCML and the dequeue method. Using the dequeue method we should be able to provide the URL that will return the RCML to be executed for this queue member.
When Restcomm sends a request to the URL, should receive document which contains the RCML verbs for how to handle the member/call.

What is your estimate for completing the API?

George

[muhammadbilal19]

Thanks @gvagenas

My confusion about dequeue Post method is this when user update the URL and method parameter, API method will send request to given URL which will return response like that

<Response>
<Say voice="alice">Thanks for trying our documentation. Enjoy!</Say>
<Play>http://demo.twilio.com/docs/classic.mp3</Play>
</Response> 

Now in this response i need to parse this response and execute each verb accordingly? I am looking into CallsEndpoint.java file currently because i think it has this functionality.

Other than this RCML part (Also add support for RCML verbs https://www.twilio.com/docs/api/twiml/enqueue and https://www.twilio.com/docs/api/twiml/leave) I will try to finish the API part till Monday 6 June 2016.

[muhammadbilal19]

Sorry for not updating the status from last week, i am currently bit busy in some other assignments. Anyways i am creating a pull request for API part which i currently did. I will do some more work on this issue probably this weekend. I am also doing testing of API currently if i see any issue i will commit it in my branch.

[gvagenas]

Hi @muhammadbilal19 what is the progress for the issue?

[gvagenas]

@muhammadbilal19 from what I can see you have implemented the Rest API part only and the VoiceInterpreter implementation for Queue and Enqueue is missing.
What is the progress for the part 2 of this issue?

[muhammadbilal19]

@deruelle @gvagenas i am currently on travel will be back on Sunday than start my work on this issue. Sorry for not giving you update was bit busy. I will start working on this issue when i come back.

[deruelle]

Thanks @muhammadbilal19 looking forward to it.

[muhammadbilal19]

@deruelle @gvagenas i did some changes in VoiceInterpreter can you guys guide me how can i test these changes. For others verbs and nouns we can create a rvd project and test it, is there any way to manually mention some rcml file where i can put my enqueue rcml for testing.

[gvagenas]

@muhammadbilal19 For manual testing you can create xml files and place them to $RESTCOMM_HOME/standalone/deployments/restcomm.war/demos.

For example check the hello-world.xml RCML application.

Then at your number assign a URL /restcomm/demos/hello-world.xml

George

[deruelle]

@muhammadbilal19 were you able to follow @gvagenas comments on testing ?

[deruelle]

@muhammadbilal19 any news on this ?

[deruelle]

@muhammadbilal19 were you able to make progress on this issue ?

[deruelle]

@muhammadbilal19 I see you're back in action. Do you think you would be able to complete this task ?

[deruelle]

@muhammadbilal19 this one is a very good one to get a better understanding of telecom core stuff in Restcomm connect if you want to finalize it as well

[muhammadbilal19]

@deruelle i have plan to complete this issue, i am currently making my understanding of VoiceInterpreter and how communication works with RMS once i have bit of understanding of these stuff i will start working on it.

[ocarriles]

@muhammadbilal19 Please tell me if you need help to push forward. I am now involved in a project targeting ACD management

[gsaslis]

@ocarriles thanks for volunteering! would love your input here based on this experience. Is this a blocker for you in your current project?

@muhammadbilal19 is this something you'll have time to look at, at this point in time, or should we perhaps allow @ocarriles to take over this one?

[ocarriles]

@gsaslis Indeed, A very important feature for intelligent call delivery to an agent group, skill based distributions and so.