and if they are replicated instantly.
2017-02-09 8:06 GMT+01:00 Schneur Rosenberg :
> Only if they are sharing a floating IP, if it's in a different network it
> won't work properly
>
> On Feb 9, 2017 08:45, "Denis via Users" wrote:
>
>> Sorry, but one more time.
>> If both instance: muster and
Only if they are sharing a floating IP, if it's in a different network it
won't work properly
On Feb 9, 2017 08:45, "Denis via Users" wrote:
> Sorry, but one more time.
> If both instance: muster and slave are in active mode (i.e. running), will
> slave properly handle dialogs (for example when
Sorry, but one more time.If both instance: muster and slave are in active mode (i.e. running), will slave properly handle dialogs (for example when BYE has been received) initiated on muster (in case of fail one)?I am using dialog module with db_mode = 1. Thank you. -- С уважением, Денис.Best regar
Jeff,
So, for the REGISTER request, in HEP, you have as both src and dst the
incoming IP of the request ??
Regards,
Bogdan-Andrei Iancu
OpenSIPS Founder and Developer
http://www.opensips-solutions.com
On 02/08/2017 11:12 PM, Jeff Pyle wrote:
Bogdan and team,
This does appear to fix the sou
Bogdan and team,
This does appear to fix the source interface issue ... at least for IPv4.
On IPv6, the errors are gone, but the source address is being reported as
both the source and destination address for a message in siptrace.
I'm using the following:
listen=hep_udp:127.0.0.1:4530 children=
Hello all!
RabbitMQ is a powerful and widely used tool for message queuing
integrations. And the usage of such a tool requires a more flexible
support from OpenSIPS. Let’s see what 2.3 has to offer when comes to
RabbitMQ based integration:
https://blog.opensips.org/2017/02/08/rabbitmq-evoluti
Hi Sasmita,
Thanks for the information.
My main objective will be the same basic scenario that you described. That is,
simple bridging between two end points.
I was concerned that the rtpproxy product includes support for options like
- recording of audio
- payload re-framing
For these option
Hi all,
i'm going crazy with an issue with WiFi VoIP users. Our VoIP server,
Opensips 1.11.9, was inside DMZ with public IP address 193.x.x.110 and
WiFi network is 10.x.x.x. VoIP fixed phone are inside a separated
network 172.20.x.x and firewall allowed traffic in both directions
between those net
