Hi Dani,
As Ovidiu said - b2b doesn't work with nat_traversal. The main
limitation comes from the fact that nat_traversal uses dialog module and
b2b does not work with dialog module yet. The reason is that dialog
module was designed to store proxied dialog, not the ones where opensips
is an
ok,
Thanks,
Dani
On 04/21/11 11:10, Anca Vamanu wrote:
Hi Dani,
As Ovidiu said - b2b doesn't work with nat_traversal. The main
limitation comes from the fact that nat_traversal uses dialog module
and b2b does not work with dialog module yet. The reason is that
dialog module was designed to
Il 19/04/11 23.30, Brett Nemeroff:
Simon,
I think it's about a 100% bet that the 1.6 and 2.0 configs will not be
compatible due to some pretty significant architectural changes.
However, I wouldn't expect that the coming 2.0 release is going to
obsolete 1.6 configurations. I suspect that it
Hi,
Thanks for the report, I was able to reproduce this on a Squeeze system.
We need to adapt to changes in latest libnetfilter-conntrack.
Did you try to install the Debian package from our repository?
Regards,
--
Saúl Ibarra Corretgé
AG Projects
Hi,
yes, i was able to install it and run it, but i have some issues. I dont
have stream statistics: caller_bytes,callee_bytes,caller_packets and
callee_packets. Also, if i'm not sure if media timeout is working,
because i tried to simulate a hang call (in the middle of call, i
restart my
On 04/21/2011 12:44 PM, Dani Popa wrote:
Hi,
yes, i was able to install it and run it, but i have some issues. I dont
have stream statistics: caller_bytes,callee_bytes,caller_packets and
callee_packets. Also, if i'm not sure if media timeout is working,
because i tried to simulate a hang call
sure,
Apr 21 06:06:41 test media-relay[4903]:
mediaproxy.mediacontrol.StreamListenerProtocol starting on 50012
Apr 21 06:06:41 test media-relay[4903]:
mediaproxy.mediacontrol.StreamListenerProtocol starting on 50013
Apr 21 06:06:41 test media-relay[4903]:
On 04/21/2011 01:06 PM, Dani Popa wrote:
sure,
Apr 21 06:06:41 test media-relay[4903]:
mediaproxy.mediacontrol.StreamListenerProtocol starting on 50012
Apr 21 06:06:41 test media-relay[4903]:
mediaproxy.mediacontrol.StreamListenerProtocol starting on 50013
Apr 21 06:06:41 test
On 04/21/11 14:13, Saúl Ibarra Corretgé wrote:
On 04/21/2011 01:06 PM, Dani Popa wrote:
sure,
Apr 21 06:06:41 test media-relay[4903]:
mediaproxy.mediacontrol.StreamListenerProtocol starting on 50012
Apr 21 06:06:41 test media-relay[4903]:
mediaproxy.mediacontrol.StreamListenerProtocol
I'm not talking abut binding ports for streams, i'm talking about stream
packets and bytes info on telnet localhost 25060.
I meant the statisticas that get printed in syslog after the call is closed.
[{from_tag: 4fc7812b, start_time: 1303386789.09, call_id:
OK,
Thanks,
Dani
On 04/21/11 15:14, Saúl Ibarra Corretgé wrote:
I'm not talking abut binding ports for streams, i'm talking about stream
packets and bytes info on telnet localhost 25060.
I meant the statisticas that get printed in syslog after the call is
closed.
[{from_tag: 4fc7812b,
Hi,
A few things that you can check :
1. if BYE received on right interface and port
2. if opensips is blocked:
- check in top the processor usage
- check the received queue in netstat( Recv-Q) for OpenSIPS - to
see if it has difficulties processing traffic
- look in the logs for
Hi John,
yes.. it is something in libxml library ( this is what presence uses). I
will try to find it.
Thanks,
--
Anca Vamanu
OpenSIPS Developer
On 04/20/2011 06:51 PM, John Khvatov wrote:
Hi Anca,
On 20.04.2011, at 13:24, Anca Vamanu wrote:
Hi John,
Thanks for the logs.
Do you get
I'm trying to track down the source of the following errors in syslog:
/usr/local/sbin/opensips[25490]: WARNING:core:fm_malloc: Not enough free
memory, will atempt defragmenation
/usr/local/sbin/opensips[25490]: ERROR:core:db_allocate_rows: no memory
left
/usr/local/sbin/opensips[25490]:
Hello,
The new CDRs type of accounting in OpenSIPS 1.6.4 only produces one
entry per call for every type of backend, whether it's a DB, Radius or
Syslog. So it's natural to only have a single STOP entry per call, and
not two, a start and stop entry as in the old type of accounting.
The STOP
Hi list,
I ended up with a very strange connection IP in the SDP after using
use_media_proxy():
c=IN IP4 65.64.63.365.64.63.2
where 65.64.63.2 and 65.64.63.3 are my obfuscated media relay IP addresses.
Could this have been caused by calling use_media_proxy() twice in the same
request? Or
I have called Mediaproxy more than once by config error in my setup and have
seen it put the mediaproxy IP twice. Looks like you might have the same
issue.
On Thu, Apr 21, 2011 at 3:00 PM, Jeff Pyle jp...@fidelityvoice.com wrote:
Hi list,
I ended up with a very strange connection IP in the
I went over my config and I think the logic is sound. I'll verify it on a dev
box tonight once traffic is low.
The call flow is serial forking from one carrier gateway to another when the
first sends a 503.
* load prefs for first gateway
* use_media_proxy()
* t_relay() INVITE to
I can't reproduce this error now. What a kick in the teeth.
I'm using dialog flags , not scripting flags, to indicate whether media proxy
is in use. Would there be any delay involved here that might cause the flag to
be missed further in the script? I feel like I'm grasping at straws here.
19 matches
Mail list logo
