Transferring a call to park slot?

[Brent Nesbit]

Hey all,

I was wondering if a call can be dynamically transferred to a park slot using the API in the same way that it can be done using *** as described here: https://help.netsapiens.com/hc/en-us/articles/202951794-Dynamic-Call-Park-with-Optional-Park-Appearance-BLF-and-Ringback

Not only would I like to build it in to some code that I'm working on, but we are still on the hunt for a way to be able to dynamically park a call without the user hearing the DTMF beeps. 

Thanks.

[Chris Aaker]

Brent, 

interesting topic as we just added similar feature to our new "Receptionist panel" that is in the works for 1227. Kevin i think is showing it off at a mid 1227 webinar in a few weeks. The logic we used is a simple blind transfer to the queue and the "dynamic" part is simply done by a quick read of queued calls and finding the first available one. Since this this is all visual then can notify the receptionist where the call went. if you can't do it visually then you would need to ringback to the agent after the transfer to let them know where it went. 

Chris

--
You received this message because you are subscribed to the Google Groups "NetSapiens Developer Forum" group.
To unsubscribe from this group and stop receiving emails from it, send an email to netsapiens-develope...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

Chris Aaker

Vice President of Engineering | NetSapiens Inc.

P.O. Box 8588 La Jolla, CA 92038

(P) 858.764.5226 (F) 858.208.4424

(E) caa...@netsapiens.com (T) @NetSapiensChris

Website | News | Events | Facebook | Twitter | Linkedin

[Brent Nesbit]

Hey Chris,

Thanks for the reply. I had planned on doing that as my backup option (looking for an open park slot and then transferring there). My main apprehension on that is this is being done via the XML browser directly on the Yealink phone. So I was afraid that the delay between Phone XML Browser > PHP on web server > API calls could lead to an issue where a large environment might park a call twice. I have seen in SIP flows that the NMS uses some kind of action to "hold" that park slot before it sends the actual call there, in order to prevent that.

I will go ahead and proceed with just having my program do the hunting and call placement. I am going to have to figure out how to even make that work though. I have read all 105 pages of the Yealink XML browser developer guide, and I don't see any way to automatically pass a parameter in the URL that is pulled from the phone automatically. Something like $active_user or anything along those lines. Meaning I don't think I can make the phone itself tell the server which call it is needing to park. So if I can't figure that out then there would be even more logic where I would have to have my script pull all active calls on that domain and make the user pick which one it is. 

Back to the drawing board for that portion of it.

With that said, I do have a visual park script that is working beautifully on Yealink. It will allow you to see who is parked and easily retrieve the call. It's just the act of actually putting a call on park that I need to figure out.

[Chris Aaker]

Brent, 

Does is the browser able to "parse" as response? The API could easily fine the queue and respond back with where the call went to cut down on that transaction time. Ill need to review that piece as its new still, but i think that is how we were planning on doing it is pushing more of the logic to the API and our new app is 90% all JavaScript. 

--

You received this message because you are subscribed to the Google Groups "NetSapiens Developer Forum" group.
To unsubscribe from this group and stop receiving emails from it, send an email to netsapiens-develope...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Brent Nesbit]

Chris,

It can receive SIP notify messages that can be used to do anything their XML browser can do (like display a message on the screen indicating what park slot it went to) but I couldn't think of any way to make that function properly. For the visual call park it's using HTTP GET initiated by the phone, which is easy enough to respond to. But SIP notify would be HTTP POST which I couldn't figure out how to get that response to actually get back to the phone without having a local server at every location.

If I can get it working to where I can park the call via the XML browser on the phone then I can get a response back to the phone. The hurdle there is the same as before: figuring out how to get the phone to tell the server who it is, and what call it wants parked.

[Chris Aaker]

Brent, 

the API doesn't do any "sip" now so hard to link the two now. ill keep this use case in mind as we continue our work. 

Chris

--

You received this message because you are subscribed to the Google Groups "NetSapiens Developer Forum" group.
To unsubscribe from this group and stop receiving emails from it, send an email to netsapiens-develope...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Brent Nesbit]

Sounds good, thanks Chris.

I sent an email to our Yealink engineer and he said he'll research getting variables working in their XML browser.

In the mean time, I was able to figure out something that mostly works. I don't have it working 100% yet, but my proof of concept works at least. I am able to control the buttons on the phone using their XML browser, so now going back to what was mentioned earlier, I make the script do the work. I have the phone reach out via the XML browser saying it wants to park a call. The script then finds a park slot and respond back to the phone with the commands necessary to control the phone itself. So I basically just have my script telling the phone to press transfer, dial the open park slot, and then transfer again. There is still the possibility of 2 people getting the same park slot since the whole process takes about 2 seconds, but this should work for the most part.

I still have a lot more work to do to get it 100%, but I'm really happy so far.