Re: [OpenSIPS-Users] OpenSIPS mhomed=yes and shared IP address using corosync

[Bogdan-Andrei Iancu]

Hi Remco,

Perfect, thanks for the update. Anyhow, I already started the work on
the drouting and load-balancing module to allow you to set a certain
interface for interacting with each destination/gateway.

Regards,

Bogdan-Andrei Iancu
OpenSIPS Founder and Developer
http://www.opensips-solutions.com


On 11/08/2013 01:15 PM, Remco . wrote:
> Hi Bogdan,
>
> The proposed solution works. Instead of modifying IPaddr2 is opted to
> go for IPsrcaddr (also included as resource agent with corosync /
> linux HA stack). This agent ensures the correct source IP address is
> used for the default route. For the other subnet / interface, I
> removed the static IP addresses for both nodes and only installed a
> floating IP address. This can be enabled by setting
> /proc/sys//net///ipv4///conf///all///promote_secondaries to 1.
> /
> This allows the kernel to choose the correct IP address for binding
> opensips, and still have a default route. mhomed=yes works like
> expected in this scenario.
>
> Regards,
> Remco.
>
> /
>
> /
>
>
> On Mon, Nov 4, 2013 at 12:28 PM, Bogdan-Andrei Iancu
> mailto:bog...@opensips.org>> wrote:
>
> Hi Remco,
>
> OK, if your approach does not work, keep in mind you can still use
> local_route to change the outbound socket for the probing OPTIONs.
>
> Regards,
>
> Bogdan-Andrei Iancu
> OpenSIPS Founder and Developer
> http://www.opensips-solutions.com
>
>
> On 11/02/2013 02:50 PM, Remco . wrote:
>> Hi Bogdan,
>>
>> Thanks for your reply. The feature of setting the probe interface
>> for DR would be great. In the meantime, I studied the exact
>> behavior of the IPaddr2 resource agent a bit more. It turns out
>> it uses iproute2 to bind the address. The VIP is added as a
>> secondary IP address to the interface - no wonder the kernel
>> picks the primary. I will see if I can modify the resource agent
>> a bit so it will add the VIP as the primary IP (swap the IP
>> addresses round). That way, the mhomed=yes option will work. I
>> will report back my findings.
>>
>> Thanks,
>>
>> Remco.
>>
>>
>> On Fri, Nov 1, 2013 at 12:27 PM, Bogdan-Andrei Iancu
>> mailto:bog...@opensips.org>> wrote:
>>
>> Hello Remco,
>>
>> In mhomed, yes you let the kernel to pick the source IP based
>> on the routing table - so this approach delegate the logic
>> from OpenSIPS to the kernel. And it is up to ho well the
>> network part is set.
>>
>> In the future I would like to add to the DR module the
>> possibility to set the probing interface (as you have now in
>> the dispatcher module). For now, what you can do is to use
>> the local_route to catch the DR pings and use
>> force_send_socket() to change the outgoing interface.
>>
>> Best regards,
>>
>> Bogdan-Andrei Iancu
>> OpenSIPS Founder and Developer
>> http://www.opensips-solutions.com
>>
>>
>> On 11/01/2013 10:39 AM, Remco . wrote:
>>> Hi all,
>>>
>>> I have a clustered OpenSIPS setup (using corosync with a
>>> virtual IP address). This has been working great over the
>>> last couple of years. I now want to add an extra IP address
>>> to the boxes, again floating a VIP over these interfaces.
>>> These interfaces will be used to communicate with PSTN
>>> gateways. I noticed however upon enabling these interfaces,
>>> the drouting module starts to ping the gateways using the
>>> wrong source address, i.e
>>>
>>> 1.1.1.1 = VIP on eth0
>>> 2.2.2.2 = VIP on eth1
>>>
>>> OpenSIPS is configured to listen on the the two VIPs with a
>>> listen directive.
>>>
>>> According to the kernel's routing table, it should use
>>> 2.2.2.2 but it uses 1.1.1.1 which results in failure. As I
>>> understood, mhomed=yes should achieve just this behavior by
>>> asking the kernel for the appropriate source address on
>>> sending out a packet. However, when I enable the mhomed
>>> option, OpenSIPS starts to complain about not having a
>>> socket to send out the packets. I assume this is caused by
>>> the kernel returning the real IP from the interfaces (first)
>>> instead of the VIPs.
>>>
>>> Just because of the dynamic nature of the interface
>>> selection, I won't be able to use force_send_socket().
>>>
>>> I know this question has come up on the list on several
>>> occasions, but nothing recent and I was still wondering if
>>> someone has a workaround or solution for this. I can imagine
>>> when using OpenSIPS as a load-balancer with two interfaces
>>> (in and out) you might encounter this problem as well if you
>>> try to add high availability (in which you often cannot
>>> avoid the Virtual IP scenario).
>>>
>>> Thanks,
>>> Re

[OpenSIPS-Users] Problem with Opensips CP

[Vishnu Vardhan]

Hi ,

I installed opensips 1.8 with opensips cp 4.0 in centos 6.4.Opensips is
installed and the service is running perfectly.After the installtion of
opensips CP,i am trying to run that from my browser,the login  page is
coming with username and password after i entered that next blank page is
coming nothing showing in that.Can you please suggest me whats the problem
here,i structed here for a long time,i didn't get the solution to come out
here,pls suggest me to get out of this problem.

Regards,
Vishnu
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

[OpenSIPS-Users] Opensips cannot start with entries in b2b_entities

[Jeff Pyle]

Hello,

I have the topology hiding scenario configured on v1.10.  If there are
records in the b2b_entities table upon startup, it won't start.  debug=6
shows:

...
Nov 12 14:45:58 [10329] DBG:b2b_entities:b2b_entities_restore: loading
information from database 2 records
Nov 12 14:45:58 [10329] DBG:b2b_entities:b2b_parse_key: hash_index = [308]
 - local_index= [392]
Nov 12 14:45:58 [10327] DBG:core:wait_status_code: read code 0 ? rc = 0,
errno=Success
Nov 12 14:45:58 [10327] INFO:core:daemonize: pre-daemon process exiting
with -1

The DB engine in this case is db_text.



- Jeff
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

Re: [OpenSIPS-Users] Problem with Opensips CP

[Sam Montour]

Why not install version 5.0? It is the latest I believe.  I installed it
with opensips 1.8 few weeks back and everything worked just fine. 

 

 

From: users-boun...@lists.opensips.org
[mailto:users-boun...@lists.opensips.org] On Behalf Of Vishnu Vardhan
Sent: Tuesday, November 12, 2013 11:53 AM
To: OpenSIPS users mailling list
Subject: [OpenSIPS-Users] Problem with Opensips CP

 

Hi ,

I installed opensips 1.8 with opensips cp 4.0 in centos 6.4.Opensips is
installed and the service is running perfectly.After the installtion of
opensips CP,i am trying to run that from my browser,the login  page is
coming with username and password after i entered that next blank page is
coming nothing showing in that.Can you please suggest me whats the problem
here,i structed here for a long time,i didn't get the solution to come out
here,pls suggest me to get out of this problem.

Regards,

Vishnu

___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

Re: [OpenSIPS-Users] opensips shutdown leaves some processes

[Jeff Pyle]

 I think I've made some progress.  It has something to do with using
127.0.0.1 as an interface.  This instance talked only to other OS instances
on the same machine, so localhost seemed like a natural and portable
choice.  Unfortunately it causes some problems possibly with the
check_ip_address function, or maybe the find_si function it calls.  More
testing showed it would crash/stop on its own.

Nov 12 15:59:52 [11098] DBG:core:check_ip_address: params 127.0.0.1,
127.0.0.1, 0
Nov 12 15:59:52 [11094] DBG:core:handle_sigs: status = 11
Nov 12 15:59:52 [11094] INFO:core:handle_sigs: child process 11098 exited
by a signal 11
Nov 12 15:59:52 [11094] INFO:core:handle_sigs: core was not generated
Nov 12 15:59:52 [11094] INFO:core:handle_sigs: terminating due to SIGCHLD
Nov 12 15:59:52 [11096] INFO:core:sig_usr: signal 15 received
Nov 12 15:59:52 [11101] INFO:core:sig_usr: signal 15 received
Nov 12 15:59:52 [11100] INFO:core:sig_usr: signal 15 received
Nov 12 15:59:52 [11097] INFO:core:sig_usr: signal 15 received
Nov 12 15:59:52 [11099] INFO:core:sig_usr: signal 15 received
Nov 12 15:59:52 [11095] INFO:core:sig_usr: signal 15 received
Nov 12 15:59:52 [11094] INFO:core:cleanup: cleanup

At debug=6 I noticed the same check_ip_address message just before it
stopped each time.

Anyway, using different ports on a real LAN IP solves both the crash and
shutdown problems.


- Jeff



On Mon, Nov 11, 2013 at 11:03 PM, Jeff Pyle  wrote:

> Hello,
>
> In one particular configuration on 1.10 a standard Opensips shutdown isn't
> ending all the processes...if calls have passed through the system.  If no
> calls have passed, everything shuts down fine.
>
> At one particular moment in time with everything running I have:
>
> Process::  ID=0 PID=26283 Type=attendant
> Process::  ID=1 PID=26284 Type=MI XMLRPC
> Process::  ID=2 PID=26285 Type=MI FIFO
> Process::  ID=3 PID=26286 Type=RTPP timeout receiver
> Process::  ID=4 PID=26287 Type=SIP receiver udp:127.0.0.1:5002
> Process::  ID=5 PID=26288 Type=SIP receiver udp:127.0.0.1:5002
> Process::  ID=6 PID=26289 Type=time_keeper
> Process::  ID=7 PID=26290 Type=timer
>
> But after /etc/init.d/opensips stop, it's always the attendant (26283) and
> the second SIP receiver (26288) hanging around.  It requires a kill -9 to
> get them to go away.
>
> A full debug isn't showing anything obvious:
>
> Nov 11 22:51:29 [26283] DBG:core:handle_sigs: SIGTERM received, program
> terminates
> Nov 11 22:51:29 [26289] INFO:core:sig_usr: signal 15 received
> Nov 11 22:51:29 [26288] INFO:core:sig_usr: signal 15 received
> Nov 11 22:51:29 [26290] INFO:core:sig_usr: signal 15 received
> Nov 11 22:51:29 [26287] INFO:core:sig_usr: signal 15 received
> Nov 11 22:51:29 [26286] INFO:core:sig_usr: signal 15 received
> Nov 11 22:51:29 [26285] INFO:core:sig_usr: signal 15 received
> Nov 11 22:51:29 [26284] INFO:core:sig_usr: signal 15 received
>
> But not everything has terminated:
>
> # ps ax | grep opensips
> 26283 ?S< 0:00 /usr/sbin/opensips -f
> /etc/opensips/opensips.cfg -P /var/run/opensips/opensips.pid -m 8 -M 1 -u
> opensips -g opensips
> 26288 ?R< 0:21 /usr/sbin/opensips -f
> /etc/opensips/opensips.cfg -P /var/run/opensips/opensips.pid -m 8 -M 1 -u
> opensips -g opensips
>
> Any suggestions on where to continue investigating?
>
>
> - Jeff
>
>
>
>
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

Re: [OpenSIPS-Users] opensips shutdown leaves some processes

[Ovidiu Sas]

Enable core dumps on the machine and get a backtrace:
http://www.opensips.org/Documentation/TroubleShooting-Crash

Regards,
Ovidiu Sas

On Tue, Nov 12, 2013 at 7:07 PM, Jeff Pyle  wrote:
> I think I've made some progress.  It has something to do with using
> 127.0.0.1 as an interface.  This instance talked only to other OS instances
> on the same machine, so localhost seemed like a natural and portable choice.
> Unfortunately it causes some problems possibly with the check_ip_address
> function, or maybe the find_si function it calls.  More testing showed it
> would crash/stop on its own.
>
> Nov 12 15:59:52 [11098] DBG:core:check_ip_address: params 127.0.0.1,
> 127.0.0.1, 0
> Nov 12 15:59:52 [11094] DBG:core:handle_sigs: status = 11
> Nov 12 15:59:52 [11094] INFO:core:handle_sigs: child process 11098 exited by
> a signal 11
> Nov 12 15:59:52 [11094] INFO:core:handle_sigs: core was not generated
> Nov 12 15:59:52 [11094] INFO:core:handle_sigs: terminating due to SIGCHLD
> Nov 12 15:59:52 [11096] INFO:core:sig_usr: signal 15 received
> Nov 12 15:59:52 [11101] INFO:core:sig_usr: signal 15 received
> Nov 12 15:59:52 [11100] INFO:core:sig_usr: signal 15 received
> Nov 12 15:59:52 [11097] INFO:core:sig_usr: signal 15 received
> Nov 12 15:59:52 [11099] INFO:core:sig_usr: signal 15 received
> Nov 12 15:59:52 [11095] INFO:core:sig_usr: signal 15 received
> Nov 12 15:59:52 [11094] INFO:core:cleanup: cleanup
>
> At debug=6 I noticed the same check_ip_address message just before it
> stopped each time.
>
> Anyway, using different ports on a real LAN IP solves both the crash and
> shutdown problems.
>
>
> - Jeff
>
>
>
> On Mon, Nov 11, 2013 at 11:03 PM, Jeff Pyle  wrote:
>>
>> Hello,
>>
>> In one particular configuration on 1.10 a standard Opensips shutdown isn't
>> ending all the processes...if calls have passed through the system.  If no
>> calls have passed, everything shuts down fine.
>>
>> At one particular moment in time with everything running I have:
>>
>> Process::  ID=0 PID=26283 Type=attendant
>> Process::  ID=1 PID=26284 Type=MI XMLRPC
>> Process::  ID=2 PID=26285 Type=MI FIFO
>> Process::  ID=3 PID=26286 Type=RTPP timeout receiver
>> Process::  ID=4 PID=26287 Type=SIP receiver udp:127.0.0.1:5002
>> Process::  ID=5 PID=26288 Type=SIP receiver udp:127.0.0.1:5002
>> Process::  ID=6 PID=26289 Type=time_keeper
>> Process::  ID=7 PID=26290 Type=timer
>>
>> But after /etc/init.d/opensips stop, it's always the attendant (26283) and
>> the second SIP receiver (26288) hanging around.  It requires a kill -9 to
>> get them to go away.
>>
>> A full debug isn't showing anything obvious:
>>
>> Nov 11 22:51:29 [26283] DBG:core:handle_sigs: SIGTERM received, program
>> terminates
>> Nov 11 22:51:29 [26289] INFO:core:sig_usr: signal 15 received
>> Nov 11 22:51:29 [26288] INFO:core:sig_usr: signal 15 received
>> Nov 11 22:51:29 [26290] INFO:core:sig_usr: signal 15 received
>> Nov 11 22:51:29 [26287] INFO:core:sig_usr: signal 15 received
>> Nov 11 22:51:29 [26286] INFO:core:sig_usr: signal 15 received
>> Nov 11 22:51:29 [26285] INFO:core:sig_usr: signal 15 received
>> Nov 11 22:51:29 [26284] INFO:core:sig_usr: signal 15 received
>>
>> But not everything has terminated:
>>
>> # ps ax | grep opensips
>> 26283 ?S< 0:00 /usr/sbin/opensips -f
>> /etc/opensips/opensips.cfg -P /var/run/opensips/opensips.pid -m 8 -M 1 -u
>> opensips -g opensips
>> 26288 ?R< 0:21 /usr/sbin/opensips -f
>> /etc/opensips/opensips.cfg -P /var/run/opensips/opensips.pid -m 8 -M 1 -u
>> opensips -g opensips
>>
>> Any suggestions on where to continue investigating?
>>
>>
>> - Jeff
>>
>>
>>
>
>
> ___
> Users mailing list
> Users@lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>



-- 
VoIP Embedded, Inc.
http://www.voipembedded.com

___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

Re: [OpenSIPS-Users] AVP-based uac_auth in b2bua

[Jeff Pyle]

I was about to let this one go when I found "B2B module gets visibility to
credentials defined via AVPs" on the About Version
1.10page.  In my
case it works only if I define the 'credential' modparam for
uac_auth.

The AVPs do work if I use the uac_auth() function in a failure_route
instead of the B2BUA top hiding.

Is there a trick I'm missing?



- Jeff


On Mon, Nov 11, 2013 at 11:09 AM, Jeff Pyle  wrote:

> Hello,
>
> I have uac_auth() working with AVPs in a proxy configuration on v1.10.
>  This is important because I need to choose the authentication username and
> password based on the usr_preferences of the source IP of the call.  Is it
> possible choose the credentials at call-time (like the AVPs allow) in a B2B
> top-hiding scenario?
>
> The scenario authenticates properly if I statically specify a
> "credentials" modparam for uac_auth.  It does not work, however, if I set
> AVPs prior to calling b2b_init_request("top hiding").  Is there another way
> to approach this?
>
>
> Regards,
> Jeff
>
>
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users