Guess I have to go back to 'park how sipXecs parks' for now...
>From an eZuce perspective we probably won't have this on our plate for a
bit. But, as I said, if somebody would like to contribute a solution that
implements parking in freeswitch, that can have the orbits monitored and
have at a min
one another thing I found is that this schema completely works if we treat
call park extensions as Polycom "normal" BLA not "automata" however this
will result in calls not being pickup with the line key after 60 seconds as
polycom tries to dial the orbit directly instead of sending the *78+orbit
a
The orbit number is know to users because of the blinking BLF on the phone
side car, all they do is press the key next to BLF
Parking completely works as expected
Retrieval also works without a problem if done using *78
The problem is that once you park using Tranfer (Polycom EFK) in Legacy
mode
So, park with your hunt group, pickup with *78 + orbit #
The problem is you don't know what orbit the call went into.
Mike
On Mon, Nov 26, 2012 at 12:27 PM, Ali Ardestani wrote:
> The problem with call orbits with multiple calls is that I can not have
> the BLF status indicating which call is
Sorry, this isn't Asterisk.
I think you are looking for what we call this valet parking and it is not
implemented at this time. The reason why it hasn't been implemented in
freeswitch and our software yet is that there was an issue with monitoring
park orbits with line keys. Check the wiki there
The problem with call orbits with multiple calls is that I can not have the
BLF status indicating which call is parked at which park orbit meaning if
we have multiple calls come in it is easier to park them at one of the
orbits and later pick them up from the side car with the BLF indicating a
park
The main reason for this is that users are used to way aterisk does parking
and retrieval and they are used to parking into one extension and then
retrieve from the side car, the problem with parking and retrieval without
the single extension is that users need to know to which call park orbit to
p
Sorry, to continue...
You can transfer and park to individual orbits... not a hunt group. How
do you know what orbit the calls go into? How would pickup know which one
you are trying to retrieve?
Why don't you just allow multiple calls in a park orbit and be done with it?
Mike
On Mon, Nov 2
I don't this has a prayer of working. You can transfer and park to
individual orbits... not a hunt group.
On Mon, Nov 26, 2012 at 12:04 PM, Ali Ardestani wrote:
> Hi all,
> I have created extension which forwards to 701,702,703,704 - these
> are four single call park orbits
>
> Parking us
I have seen this as well but have not found a solution, but I have had very
little time to look into it. We transfer directly to the Park orbits
though, we don't use a forwarding extension.
-Bryan Anderson
On Mon, Nov 26, 2012 at 9:04 AM, Ali Ardestani wrote:
> Hi all,
> I have created extens
Hi all,
I have created extension which forwards to 701,702,703,704 - these are
four single call park orbits
Parking using Transfer works without a problem
However automatic retrieval using polycom side car keys has problems in
both NATIVE and LEGACY modes.
In Native mode it fails to alert t
11 matches
Mail list logo
