Thanks Mike…SBCs/ITSPs are a wide area and the freeswitch variant is an
interesting new variant. Just wanted to encourage that from my point of
view it would make sense to officially support some SBC(s) that are
certified on the OpenUC side (standard SIP functions like call, transfer,
pickup)
well I've rewritten the patch against 4.6 this one should apply clearly
thanks
Domenico Chierico
On Mon, Nov 26, 2012 at 8:11 AM, Joegen Baclor jbac...@ezuce.com wrote:
Domenico,
I've reviewed your patch and I am accepting it for commit. However:
[joegen@sipdevel sipxecs-master]$ git apply
Domenico,
I committed to 4.6. Would you mind sending a patch for release-4.4 as well?
On 11/26/2012 05:25 PM, Domenico Chierico wrote:
well I've rewritten the patch against 4.6 this one should apply clearly
thanks
Domenico Chierico
On Mon, Nov 26, 2012 at 8:11 AM, Joegen Baclor
yes it is mainly the same
On Mon, Nov 26, 2012 at 11:28 AM, Joegen Baclor jbac...@ezuce.com wrote:
Domenico,
I committed to 4.6. Would you mind sending a patch for release-4.4 as well?
On 11/26/2012 05:25 PM, Domenico Chierico wrote:
well I've rewritten the patch against 4.6 this one
Josh has been working on just such a thing but is starting with phones...
http://wiki.sipfoundry.org/display/sipXecs/eZuce+Vendor+Certification+Program
Check out the phone section as it's coming along nicely with captures as
how the phones should work.
https://github.com/dhubler/sipxecs/commit/9b2ea254b15a6ade18a80a6790c6ba9ee6af6bb7
https://github.com/dhubler/sipxecs/commit/f8c70a8158cf24dbe10b04dd5ecb3dc7bde9bbd3
Thanks for the patch!
On 11/26/2012 07:19 PM, Domenico Chierico wrote:
yes it is mainly the same
On Mon, Nov 26, 2012 at
thanks :)
On Mon, Nov 26, 2012 at 12:49 PM, Joegen Baclor jbac...@ezuce.com wrote:
https://github.com/dhubler/sipxecs/commit/9b2ea254b15a6ade18a80a6790c6ba9ee6af6bb7
https://github.com/dhubler/sipxecs/commit/f8c70a8158cf24dbe10b04dd5ecb3dc7bde9bbd3
Thanks for the patch!
On 11/26/2012
Hi all,
Is there a estimated date when this update will be released, since it is now in
stage dir?
Our client, where we have an issue with this bug, only wants to update when the
patch is released and stable.
Perhaps anyone can shed some light on this?
Regards,
Henry
-Original
Sorry, I don't think we have estimated dates on this. Depends on how many
people test it and report errors. Of course we have no idea how many
people are actually testing. So sometimes no news is not good news.
If we have no people testing and no reports of if it does / doesn't work we
really
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
Hi Michael,
Thanks of your clear and well explained answer.
Off course we explained this to out customer but he insists :)
We have this patch in testing, and are happy with the results so far, in a few
days we will install this at another customer who is not that explicit about a
released
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 ali.ardest...@pnmac.comwrote:
Hi all,
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 ali.ardest...@pnmac.comwrote:
Hi all,
I have created extension which forwards to 701,702,703,704 - these
are four single call park
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
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
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
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
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 ali.ardest...@pnmac.comwrote:
The problem with call orbits with multiple calls is that I can not have
the BLF status
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
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
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
right, we can never predict, but statistically, this has been in stage
longer than normal. We actually had to revert part of what was in the
last stage because realized we couldn't finish full support of
diversion header and it will be safer to pull it out.
I just, just pushed new set of rpms to
Hello,
On a 4.6 system, I discovered that the service Contact Center (openacd)
was listed as shut down. Checking the box and selecting restart did
not bring it up. Trying a service openacd start from command line
fails with: erlexec: HOME must be set
I found this thread that refers to a bug
I believe you hitted this:
https://list.sipfoundry.org/archive/sipx-dev/msg28473.html
-
MM
On Mon, Nov 26, 2012 at 5:39 PM, Alan Worstell aworst...@a-1networks.comwrote:
Hello,
On a 4.6 system, I discovered that the service Contact Center (openacd)
was listed as shut down. Checking the box
On Mon, Nov 26, 2012 at 9:46 PM, Melcon Moraes mel...@gmail.com wrote:
I believe you hitted this:
https://list.sipfoundry.org/archive/sipx-dev/msg28473.html
Is this still reproducible with RPMs from today?
George
___
sipx-users mailing list
Hello,
This happened with version:
openacd-0.9.5-649.g3370.x86_64
and after I ran updates (today, right before my first post),
openacd-0.9.5-740.ga82e.x86_64
and sipxopenacd packages:
sipxopenacd.x86_64 0:4.6.0-669.gbc73a7 (before update)
and sipxopenacd.x86_64 0:4.6.0-890.ge4ca9 (after update)
George,I see this issue intermittently in previous build..Will check in
the latest build
Regards,
Kumaran T
On 11/27/2012 1:20 AM, George Niculae wrote:
On Mon, Nov 26, 2012 at 9:46 PM, Melcon Moraes mel...@gmail.com
mailto:mel...@gmail.com wrote:
I believe you hitted this:
27 matches
Mail list logo
