On Tue, Aug 21, 2012 at 12:59 PM, andrewpitman andrewpit...@comcast.net wrote:
Joegen, George,
I noticed some messages in my sipXproxy log from a hang on a
customer system just today, which may or may not be
pertinent. Besides the parsing errors, I also see messages
such as this
I'm unable to register any endpoints to my sipXecs server. The credentials are
present in the postgres DB, but there is no credentials.xml file in
/var/sipxdata/sipdb. The sipregistrar.log is full of:
i think you missed the yum update step that must be done after install from
ISO...
iso is not kept up to date... hmmm... how many times have i said this?
On Wed, Aug 22, 2012 at 11:49 AM, Matthew Hodgins mhodg...@lifesize.comwrote:
I'm unable to register any endpoints to my sipXecs server.
beyond that, please also explain your environment and what services are
enabled.
One assumes the sipdomain is (not hostname):
sipxecs.sqa.lifesize.com
So they question is what are the tandbergs registering to? IP, hostname or
DNS SRV (meaning sipdomain)? Is this a HA or single server install?
On Wed, Aug 22, 2012 at 11:49 AM, Matthew Hodgins mhodg...@lifesize.com wrote:
I'm unable to register any endpoints to my sipXecs server. The credentials
are present in the postgres DB, but there is no credentials.xml file in
/var/sipxdata/sipdb. The sipregistrar.log is full of:
yum update and
I've run 'yum update' and rebooted, but that didn't resolve my issue. My SIP
domain is sipxecs.sqa.lifesize.com (same as my SIP realm)
The various endpoints are using the SIP domain (DNS) to register.
I'm in a single server environment. The following services are enabled:
* Core Services
On Wed, Aug 22, 2012 at 1:14 PM, Matthew Hodgins mhodg...@lifesize.comwrote:
I've run 'yum update' and rebooted, but that didn't resolve my issue. My
SIP domain is sipxecs.sqa.lifesize.com (same as my SIP realm)
in mongo, does
db.entity.find();
return anything?
Looks like you've done the
Sending profiles worked! I'm now able to register endpoints to the sipXecs and
dial calls using their extension.
I'll send you the snapshot anyway in case there is an actual bug that might
need to be fixed instead of a configuration error.
Thanks for your help guys!
From: Douglas Hubler
I have also seen this on a 4.4 system.
Calls were not being processed and the caller heard dead air. When a call
was researched, I found that sipXproxy was loading the NAT plugin for the
call even though the call was outbound to the PSTN via an AudioCodes
gateway.On this system, NAT
Joegen,
Actually, it looks like we have the keepalive.sessionTimers option turned off
for all our phones anyway. I looked in the pcap we have from a hang just this
morning and I didn't see any messages matching the PUBLISH method. I can send
you these off list if you'd like.
-Andy
-
I know today's sipx 4.4 ACD does not provide this, but will sipx 4.6 with
OpenACD provide the feature that the caller can hear You are number x in
the queue...?
Sven
--
*Sven Evensen, Operations Consultant*
*OnRelay*
Elizabeth House │ 39 York Road, London SE1 7NQ, UK │ +44 (0) 207 902 8123 │
Not at this time. Have you asked if anyone has implemented this on the
openacd mailing list?
On Aug 22, 2012 2:30 PM, Sven Evensen sven.even...@onrelay.com wrote:
I know today's sipx 4.4 ACD does not provide this, but will sipx 4.6 with
OpenACD provide the feature that the caller can hear You
On Wed, Aug 22, 2012 at 1:40 PM, Matthew Hodgins mhodg...@lifesize.com wrote:
Sending profiles worked! I'm now able to register endpoints to the sipXecs
and dial calls using their extension.
Your snapshot was very helpful. Turns out you're one of the few that
*didn't* enable SIP Capture and
Ooops, typo. Its not PUBLISH but UPDATE.
On 08/23/2012 01:58 AM, andrewpit...@comcast.net wrote:
Joegen,
Actually, it looks like we have the keepalive.sessionTimers option
turned off for all our phones anyway. I looked in the pcap we have
from a hang just this morning and I didn't see any
http://download.sipfoundry.org/pub/sipXecs/ChangeLog-4.4.0
Update #18 : Wed, 22, Aug 2012
==
- ** No security updates in this update **
- ISO has *not* been rebuilt as decided in release policy. Yum update
after installation is
Not sure when this stopped working but in #17 and #18 you can call into
a ACD queue with no active agents and the call will go on hold but not
transfer to the overflow. The overflow in this case is an AA.
Everything works fine if you call the ACD via an internal phone to it's
extension. It
From the looks of it, sipxbridge somehow is sending the external IP of
the server that is if 75.144.86.61:5080 is the IP of your firewall. If
so, please send pertinent logs from sipXbridge in debug level. I've
attached the filtered pcap in this mail.
On 08/23/2012 06:56 AM, Gerald
I saw this question first on the openacd mailin list. Anyway, copying my
response here:
With just openacd, you can manually create recordings and set it up as media
announcements in a recipe where the condition is based on the numer of calls
in the queue.
Programatically, it's possible
*TTS
On Thu, Aug 23, 2012 at 9:41 AM, Jan Vincent Liwanag jvliwa...@ezuce.comwrote:
I saw this question first on the openacd mailin list. Anyway, copying my
response here:
With just openacd, you can manually create recordings and set it up as
media announcements in a recipe where the
19 matches
Mail list logo
