on demand, remote Que calls

[andercom]

Hi folks, I need some more brains on this. This is hard to test so I want to make sure I start down the right path.

Two sites, both UCX250's . All phones are Nortel. Site 1 has a que with dynamic agents. Site 2 has a receptionist that answers incoming clinic calls. A SIP trunk connects the two sites through their intranet. When Site 2 is slow, they want to be able to take site 1 que calls , but only when they chose to do so. I see the static agent option but that doesn’t provide a choice to log in or out. What would be a good way to allow a remote extension to act like a dynamic agent?

I was thinking of assigning a DN in the static agent que that pointed to a call flow control at site 2. If CFC is off it points to an invalid destination or congestion signal, if CFC is on it rings the desired extension. I’m just not sure if the call will return to the que in the proper order when Site 2’s CFC is off. I guess I could have it return and tag it with a higher priority, but that seems like a circuitous setup for something that wont get used that much.

Another scenario would be to use the softphone in infinityone at site 2 to log in/out and have it 'follow me' to the physical phone at site 2. That seems like it would work, however, it would also mean that the softphone would ring through a second call because it wouldn't be in use when the call is answered on the physical phone. As simple as it sounds, it adds an additional level of complication that some of these end users just can’t handle.

Any thoughts?

 

[ucxguy]

If I understand correctly, you have two systems (A and B) connected via a SIP trunk. You want an extension on system B to be a dynamic queue member on system A. I believe that with a bit of custom configuration, this should be possible.

Let's say for my example that extensions on A are 201 - 250 and extensions on B are 300 to 350. The extension you want to use as the queue member on A is let's say 300. The queue on A is 600.

You would need to do the following:
1. Expose the Queue Member Toggle feature (*45) for the desired queue on system A to the extension 300. To do so, you would need to
a) On system A, create a custom destination that points to "from-internal,*45600,1" (where 600 is the queue number)
b) On system A, create an inbound route for some DID - for example 45600 - and point it to the custom destination
c) On system B, add the digits 45600 to the outbound route that uses the SIP trunk to the system A (include a prefix if you use one to dial extensions on A in the prefix field)
2. On the system A, create a custom extension 300 (type Other / Custom)
a) The extension name should be the desired name of the queue member
b) The "Dial" string should be set to whatever is currently needed to call the extension 300 from system A. Let's say that you must dial the prefix 8 and the extension 300 when you call 300 from a phone on A, then use the Dial string "Local/8300@from-internal"

This setup should work as follows:
1. The user of 300 (on B) can dial the prefix and digits 45600 to toggle the membership in the queue 600 on A (e.g., 845600). After dialing, the user should hear that the extension 300 was added to the queue or removed from the queue.
2. An incoming call to the queue 600 routed to the queue member 300 will dial the destination Local/8300@from-internal (which does the same thing as dialing 8300 from an internal phone on A). The prefix 8 will route the call to system B to the extension 300.

If you want the user of 300 to be able to use the pause/unpause capability, you could expose also the Queue Pause Toggle (*46) feature for the queue 600 (for example using DID 46600).

 

[andercom]

Thanks for your answer, I didn't see this response right away. I did think of that scenario , however I was unsure how the site A UCX could monitor the busy/idle status of the phone at site B in order to determine whether to offer a que call. I definitley would have tried this solution, however, as per usual, the customer changed their needs after researching this so I deployed an IP set to make their new parameters easier to satisfy. The IP set now resides on the site A pbx with a site B route configuration making it mostly transparent to the customer.