Hi,
Need help to configure express talk to work with opensips.
I have installed opensips on rhel5 and it is running. and also added an user
2000.
But when trying to connect using express talk with the same user and
password, it is not working and shows server did not respond.
Please help.
Thanks
Thanks, I'll look into the mysql library and see what I can find.
Mark
On 03/29/11 22:22, Vlad Paiu wrote:
Hi,
Just took a look at the code and it seems to be a problem somehow
related with the mysql library on your machine.
At startup, OpenSIPS tries to fetch all dialog info from DB, and it
Hi,
Yep, that was the problem. This feature is not really well documented.
SOLUTION for the record:
run rtpproxy with : rtpproxy -l internal-ip/external-ip [other relevant params]
When internal sends INVITE through the proxy on that INVITE
use 'rtpproxy_offer(FAIE)' and 'rtpproxy_answer()' on
Hi Vlad,
Thanks again for looking into this issue, you were spot on the mysql
library was different on each server and it came down to the order in
which the packages were installed.
Just in case anyone else has this issue you need to installed
mysql-devel last, due to an issue with error
I just updated python to 2.6 version but still have same error.
I have installed following version of libs:
python26.x86_642.6.5-6.el5
python26-libs.x86_64 2.6.5-6.el5
python26-application.noarch1.1.5-3
python26-cjson.x86_64
Hello All,
I've seen some incompatibilities pop up from time to time that leave dialogs
in the invalid CONFIRMED NO ACK state. In general I'd like to end dialogs
that stay in this state for more than X seconds. The idea is, either become
confirmed, or die.
I can't figure out how to do this.
One thing to do is write a script that will check your dialogs and how long
they have been active. If they are older than X then delete the dialogs.
You can use the opensipsctl fifo dlg_end_dlg to kill the dialogs.
On Mar 30, 2011 11:24am, Brett Nemeroff br...@nemeroff.com wrote:
Hello
Yeah, I'm on the verge of doing that. but seems like I should be able to be
smarter about it. right?
On Wed, Mar 30, 2011 at 11:45 AM, duane.lar...@gmail.com wrote:
One thing to do is write a script that will check your dialogs and how long
they have been active. If they are older than X then
Hopefully someone else can enlighten us.
On Wed, Mar 30, 2011 at 11:50 AM, Brett Nemeroff br...@nemeroff.com wrote:
Yeah, I'm on the verge of doing that. but seems like I should be able to be
smarter about it. right?
On Wed, Mar 30, 2011 at 11:45 AM, duane.lar...@gmail.com wrote:
One
And I confirm that media-relay run well on openvz host (not virtual
environment).
I found interesting thing when media-relay fail in openvz virtual
environment on openvz host in dmesg appear this string:
Mar 30 20:41:46 kernel: ctnetlink v0.90: registering with nfnetlink.
Maybe it helps you
First, it needs to be identified how the dialog arrived in that state:
1. The ACK was not received and in this case the callee should send a BYE:
1a. The BYE was sent and received by opensips (then it's a bug
handling the BYE);
1b. The BYE was not sent (and we deal with a bogus callee);
2.
Ovidiu,
It's been a number of things. The two latest problems causing this are:
1. 200 Ok sent to call originator, originator never sends an ack. BUT then
after about 15 seconds, the originator sends a BYE with a Max-Forwards of 0.
(!!). Believe it or not, this happens a lot. Dialog stays active
On Wed, Mar 30, 2011 at 2:30 PM, Brett Nemeroff br...@nemeroff.com wrote:
Ovidiu,
It's been a number of things. The two latest problems causing this are:
1. 200 Ok sent to call originator, originator never sends an ack. BUT then
after about 15 seconds, the originator sends a BYE with a
forgot to cc the list ...
On Wed, Mar 30, 2011 at 4:15 PM, Ovidiu Sas o...@voipembedded.com wrote:
On Wed, Mar 30, 2011 at 3:09 PM, Brett Nemeroff br...@nemeroff.com wrote:
On Wed, Mar 30, 2011 at 1:47 PM, Ovidiu Sas
This should be done by the dialog itself (nothing to do from the
script).
I know I'm doing something bad here. However, we are having a problem with one
of the SIP phones that we support. When it sends out an INVITE and then
CANCEL, the CANCEL is not being forwarded. We are suspecting that it is caused
by a wrong CSeq value.
INVITE #1 gets challenged.
INVITE #2
Cinthia,
The CSeq needs to be changed before it hits opensips. So you could do
something where if the cancel is not matched, lookup the right cseq
using a memcache lookup (that you stored during the accepted invite)
and send it out to it self with the modified CSeq. I wouldn't be
surprised if
16 matches
Mail list logo
