[OpenSIPS-Users] uac_replace_from
Hello. How can I pass a pseudo-variable as a parameter to the uac_replace_from function? Code: $var(t) = x; uac_replace_from($var(t)); raises an error opensips: CRITICAL:core:yyerror: parse error in config file, line 723, column 39-40: bad arguments for command uac_replace_from $avp raises that error too. WBR, Anton Zagorskiy VoIP Developer, Oyster Telecom Phone.: +7 812 601-0666 Fax: +7 812 601-0593 a.zagors...@oyster-telecom.ru www.oyster-telecom.ru ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] uac_replace_from
Hi Anton, Correctly is : $var(t) = x; uac_replace_from($var(t)); Regards, Bogdan Anton Zagorskiy wrote: Hello. How can I pass a pseudo-variable as a parameter to the uac_replace_from function? Code: $var(t) = x; uac_replace_from($var(t)); raises an error opensips: CRITICAL:core:yyerror: parse error in config file, line 723, column 39-40: bad arguments for command uac_replace_from $avp raises that error too. WBR, Anton Zagorskiy VoIP Developer, Oyster Telecom Phone.: +7 812 601-0666 Fax: +7 812 601-0593 a.zagors...@oyster-telecom.ru www.oyster-telecom.ru ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users -- Bogdan-Andrei Iancu OpenSIPS Bootcamp 15 - 19 November 2010, Edison, New Jersey, USA www.voice-system.ro ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] Load balancer probing from incorrect interface
Hi Bill, I was strictly speaking about the mhomed=1 case. Opensips doing detection (based on default IP routing rules from kernel) sees that it should use first available interface (as returned by kernel)..it cannot simply pick up all possible and see which one is also listening on. in your case, if 10.0.10.2 and 10.0.10.3 doing the same, but 10.0.10.3 is used by default by kernel for reaching 10.0.10.xx network, simply use 10.0.10.3 for opensips also. Regards, Bogdan Bill W wrote: Hey Bogdan, I think we're confusing two issues. The first issue was when mhomed=0, it was trying to options ping the internal interface with an external IP, which clearly won't work, as you described below. The second issue is when I set mhomed=1, opensips is cannot options ping anything at all because it's trying to bind to an IP that doesn't belong to opensips. For example: DBG:tm:t_uac: next_hop=sip:10.0.10.1 DBG:core:mk_proxy: doing DNS lookup... ERROR:core:get_out_socket: -- detected IP 10.0.10.2,proto=1 ERROR:tm:uri2sock: no corresponding socket for af 2 ERROR:tm:t_uac: no socket found ERROR:load_balancer:lb_do_probing: probing failed 10.0.10.1 is on another machine 10.0.10.2 is on this machine 10.0.10.3 is on this machine, and allocated to opensips via listen= Opensips should be binding to 10.0.1.3 which is specified in the listen= directive, not 10.0.10.2, which is another IP on the box but is not allocated to opensips. Summary: With mhomed=1 opensips is detecting the correct interface to ping from, but it is selecting an IP on that interface that is not specified in the listen= directives. Hopefully I explained the behavior clearly. Thanks, Bill. On 11/11/2010 11:39 AM, Bogdan-Andrei Iancu wrote: It looks to me more like a misconfiguration on network level for the machine ...Opensips tries to detect the interface with the default route to the destination IP (the info id provided by kernel)..So if the kernel sees 66.180.205.11 as default interface for reaching a private IP.does look sane to me :) Regards, Bogdan Bill W wrote: Ahhh, I see what's going on. Opensips is trying to probe from a different IP on that interface instead of the IP alias opensips bound to. For example, on the public interface I have IP 66.180.205.11 Then I have an IP alias of 66.180.205.3 on that same interface: eth0 66.180.205.11 freeswitch:5060 eth0:0 66.180.205.3 opensips:5060 DBG:tm:t_uac: next_hop=sip:66.180.205.11 DBG:core:mk_proxy: doing DNS lookup... ERROR:core:get_out_socket: -- detected IP 66.180.205.11,proto=1 ERROR:core:get_out_socket: no socket found ERROR:tm:uri2sock: no corresponding socket for af 2 ERROR:tm:t_uac: no socket found ERROR:load_balancer:lb_do_probing: probing failed It's not getting the IP from the listen= directive but from an interface probe, which is getting the wrong IP. On 11/11/2010 6:29 AM, Bogdan-Andrei Iancu wrote: Hi Bill, could you try the attached patch along mhomed option? the patch will simply print what is the IP opensips is trying to use for the outgoing probes Regards, Bogdan Bill W wrote: Hey Bogdan, Yes, I have 3 listen= lines; two with public IPs and one with a private IP. When I remove the mhomed=1 then things work as intended except for the probing. I can proxy traffic correctly on all interfaces. When I enable mhomed=1, then I get the errors below. Thanks, Bill On 11/10/2010 5:38 AM, Bogdan-Andrei Iancu wrote: Hi Bill, is your opensips actually listening (configured as listener in .cfg) on a interface in the private network (where the probing needs to be done) ?? Regards, Bogdan Bill W wrote: Hey Bogdan, I enabled the mhomed=1 parameter, and now I'm getting a bunch of errors in the logs. ERROR:tm:t_uac: no socket found ERROR:load_balancer:lb_do_probing: probing failed ERROR:core:get_out_socket: no socket found ERROR:tm:uri2sock: no corresponding socket for af 2 Thoughts? Bill On 11/8/2010 6:05 AM, Bogdan-Andrei Iancu wrote: Hi Bill, as you have a multi interface system, have you tried to enable the mhomed global parameter? http://www.opensips.org/Resources/DocsCoreFcn16#toc60 Regards, Bogdan Bill W. wrote: As an update, the load balancer probe appears to use the ip address specified by the first listen= directive. If I list the public IP first, then the probe tries to talk to the internal IP from the external interface IP. On 11/7/10 6:18 PM, Bill W. wrote: Hello everyone, I've got an opensips-1.6.3-tls installation using multiple interfaces and load balancing. My internal interface is rfc1918 space and my external interface has public IPs. listen=udp:10.0.10.3:5060 listen=udp:66.180.205.3:5060 I have the following load_balancer configuration: id | group_id | dst_uri | probe_mode +--+---+ 1 | 1 | sip:66.180.205.11 | 2 2 | 1 | sip:66.180.205.12 | 2 3 | 2 | sip:10.0.10.1 | 2 4 | 2 | sip:10.0.10.2 | 2 What's happening is that the load balancer is trying to
Re: [OpenSIPS-Users] Dispatcher radius messages are not valid
I see... unfortunately I cannot help you with media-dispatchernever used it :-/ Regards, Bogdan Maciej Bylica wrote: Ups sorry for not being so precise. I am talking about media-dispacher (not dispacher module) which is installed on the same server using radiusclient-ng Additionally there is media-relay running different ip. Thx, Maciej. 2010/11/11 Bogdan-Andrei Iancu bog...@voice-system.ro: lost meif dispatcher is not opensips acting as dispatcher, what is this dispatcher ??? Regards, Bogdan Maciej Bylica wrote: Hi Bogdan, From my point of view it is not so clear, because opensips and dispatcher use the same secret (the same radiusclient.conf file) and are located on the same server. There are only one entry provided in radius server clients file describing ip address (the same for opensips and dispatcher) and secret (the same for opensips and dispatcher). So if opensips had permission to sent messages then in the same way dispatcher should be able to massage radius server. Thx, Maciej Hi Maciej, Sounds quite clear (from the err message) that the secrets on radius server and radius client are not the sameIt is not an opensips issue, it is a matter of configuring the radius server and radius client library. Regards, Bogdan Maciej Bylica wrote: Hello, I am working on opensips 1.6.3 $Revision: 4448 together with media-dispatcher 2.4.3, media-relay 2.4.3, python 2.5.2-3, freeradius 2.1.8, radiusclient-ng 0.5.6 Freeradius should gather radius messages directly from opensips and dispatcher. Both are installed on the same server and use the same radiusclient.conf file. The problem is that radius messages generated from dispatcher are not taken into account while i have no problem with opensips radius messages (secred for dispatcher and opensips is the same) Here is an output from radius server Waking up in 0.10 seconds. Thread 9 got semaphore Thread 9 handling request 121, (13 handled so far) [thread] Received Accounting-Request packet from client 10.1.1.229 with invalid signature! (Shared secret is incorrect.) Dropping packet without response. I've already tested freeradius-xs from debian pkg with same effect. I am running 32bit os linux debian lenny. Has anybody similiar problem. Could you guys pls point me what should i check? Thx in advance, Maciej ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users -- Bogdan-Andrei Iancu OpenSIPS Bootcamp 15 - 19 November 2010, Edison, New Jersey, USA www.voice-system.ro ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users -- Bogdan-Andrei Iancu OpenSIPS Bootcamp 15 - 19 November 2010, Edison, New Jersey, USA www.voice-system.ro ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users -- Bogdan-Andrei Iancu OpenSIPS Bootcamp 15 - 19 November 2010, Edison, New Jersey, USA www.voice-system.ro ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] uac_replace_from
Thanks. WBR, Anton Zagorskiy VoIP Developer, Oyster Telecom Phone.: +7 812 601-0666 Fax: +7 812 601-0593 a.zagors...@oyster-telecom.ru www.oyster-telecom.ru -Original Message- From: users-boun...@lists.opensips.org [mailto:users- boun...@lists.opensips.org] On Behalf Of Bogdan-Andrei Iancu Sent: Friday, November 12, 2010 1:38 PM To: OpenSIPS users mailling list Subject: Re: [OpenSIPS-Users] uac_replace_from Hi Anton, Correctly is : $var(t) = x; uac_replace_from($var(t)); Regards, Bogdan Anton Zagorskiy wrote: Hello. How can I pass a pseudo-variable as a parameter to the uac_replace_from function? Code: $var(t) = x; uac_replace_from($var(t)); raises an error opensips: CRITICAL:core:yyerror: parse error in config file, line 723, column 39-40: bad arguments for command uac_replace_from $avp raises that error too. WBR, Anton Zagorskiy VoIP Developer, Oyster Telecom Phone.: +7 812 601-0666 Fax: +7 812 601-0593 a.zagors...@oyster-telecom.ru www.oyster-telecom.ru ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users -- Bogdan-Andrei Iancu OpenSIPS Bootcamp 15 - 19 November 2010, Edison, New Jersey, USA www.voice-system.ro ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] SIPTRACE sequence issue
I would rather say: 1) make opensips to insert in the time_stamp col the time when the message was received and not the time when the insertion in done (this will preserve the order of the packages) 2) probably a time stamp (sec only) is not eough and some microsecs needs to be added..(to order packages in the same sec). What do you thing? Regards, Bogdan MohammedShehzad wrote: I added a field microsec in database and a little change in the CDRTool - instead of ordering siptrace by id, it order by time_stamp and microsec. Though the trick did not worked. This changes were done in siptrace module. May be it could have worked if the time_stamp and microsec is being picked up from original location where function of the siptrace module is being called. As It requires modification in one level up (may be include multiple other db and sip messages related modules) I thought it would leave the code unstable. So currently not looking into code more yet. Would like to check if get more insight. Regards, MohammedShehzad What is the idea you are trying to hack ? maybe to brains are better than one ;) Regards, Bogdan MohammedShehzad wrote: On Thu, Nov 11, 2010 at 10:53 AM, MohammedShehzad pmh...@gmail.com wrote: Hi Bogdan, Thanks for your prompt response. I was hacking into the code of siptrace module but no success yet. Anyway something is better than nothing. Regards, MohammedShehzad Hi Mohammed, This is more or less a limitation ; as opensips is doing parallel processing , you may have concurrent DB access (like inserting the siptrace record for 200OK and the one for ACK)...Also the DB ops (requiring locks) may change the sequence of the ops ( the order of the queries and the order of the actual db ops). There is no way to guarantee the order of the package in DB. Regards, Bogdan MohammedShehzad wrote: Hello everybody, I am facing an issue in sip message sequence while I log the siptrace using siptrace module. The issue is random, means, generally it is fine, but sometimes the SIP messages are out of sequence i.e. ACK get logged before 200OK, even sometimes INVITE comes after 100 Trying or 180 ringing. I found that, when CDRTool list siptrace of call, the SIP messages are ordered by ID, which is auto increment field. So it seems that the siptraces are not being inserted properly in sequence from siptrace module itself. My Opensips Version : opensips-1.5.3-notls MySQL database is used, and is on remote system. Is there anything I should try to resolve this issue? Or is this bug/limitation of siptrace module itself? Regards, MohammedShehzad ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users -- Bogdan-Andrei Iancu OpenSIPS Bootcamp 15 - 19 November 2010, Edison, New Jersey, USA www.voice-system.ro ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] Dispatcher radius messages are not valid
Nevertheless, thank You Bogdan. Has Anybody more less similiar problem like me? Thx, Maciej. 2010/11/12 Bogdan-Andrei Iancu bog...@voice-system.ro: I see... unfortunately I cannot help you with media-dispatchernever used it :-/ Regards, Bogdan Maciej Bylica wrote: Ups sorry for not being so precise. I am talking about media-dispacher (not dispacher module) which is installed on the same server using radiusclient-ng Additionally there is media-relay running different ip. Thx, Maciej. 2010/11/11 Bogdan-Andrei Iancu bog...@voice-system.ro: lost meif dispatcher is not opensips acting as dispatcher, what is this dispatcher ??? Regards, Bogdan Maciej Bylica wrote: Hi Bogdan, From my point of view it is not so clear, because opensips and dispatcher use the same secret (the same radiusclient.conf file) and are located on the same server. There are only one entry provided in radius server clients file describing ip address (the same for opensips and dispatcher) and secret (the same for opensips and dispatcher). So if opensips had permission to sent messages then in the same way dispatcher should be able to massage radius server. Thx, Maciej Hi Maciej, Sounds quite clear (from the err message) that the secrets on radius server and radius client are not the sameIt is not an opensips issue, it is a matter of configuring the radius server and radius client library. Regards, Bogdan Maciej Bylica wrote: Hello, I am working on opensips 1.6.3 $Revision: 4448 together with media-dispatcher 2.4.3, media-relay 2.4.3, python 2.5.2-3, freeradius 2.1.8, radiusclient-ng 0.5.6 Freeradius should gather radius messages directly from opensips and dispatcher. Both are installed on the same server and use the same radiusclient.conf file. The problem is that radius messages generated from dispatcher are not taken into account while i have no problem with opensips radius messages (secred for dispatcher and opensips is the same) Here is an output from radius server Waking up in 0.10 seconds. Thread 9 got semaphore Thread 9 handling request 121, (13 handled so far) [thread] Received Accounting-Request packet from client 10.1.1.229 with invalid signature! (Shared secret is incorrect.) Dropping packet without response. I've already tested freeradius-xs from debian pkg with same effect. I am running 32bit os linux debian lenny. Has anybody similiar problem. Could you guys pls point me what should i check? Thx in advance, Maciej ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users -- Bogdan-Andrei Iancu OpenSIPS Bootcamp 15 - 19 November 2010, Edison, New Jersey, USA www.voice-system.ro ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users -- Bogdan-Andrei Iancu OpenSIPS Bootcamp 15 - 19 November 2010, Edison, New Jersey, USA www.voice-system.ro ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users -- Bogdan-Andrei Iancu OpenSIPS Bootcamp 15 - 19 November 2010, Edison, New Jersey, USA www.voice-system.ro ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] Load balancer probing from incorrect interface
Hi Bogdan, Thanks so much for explaining how interface selection works. Unfortunately the other interfaces all have daemons listening on port 5060 and are in production and I can't simply reallocate IPs. So for the error messages below, is the problem that opensips is trying to send out a packet on the automatically selected IP but since port 5060 is occupied on that address, the socket is failing? If so, is it possible to specify a different source port so the packet will go out? Thanks, Bill On 11/12/2010 5:43 AM, Bogdan-Andrei Iancu wrote: Hi Bill, I was strictly speaking about the mhomed=1 case. Opensips doing detection (based on default IP routing rules from kernel) sees that it should use first available interface (as returned by kernel)..it cannot simply pick up all possible and see which one is also listening on. in your case, if 10.0.10.2 and 10.0.10.3 doing the same, but 10.0.10.3 is used by default by kernel for reaching 10.0.10.xx network, simply use 10.0.10.3 for opensips also. Regards, Bogdan Bill W wrote: Hey Bogdan, I think we're confusing two issues. The first issue was when mhomed=0, it was trying to options ping the internal interface with an external IP, which clearly won't work, as you described below. The second issue is when I set mhomed=1, opensips is cannot options ping anything at all because it's trying to bind to an IP that doesn't belong to opensips. For example: DBG:tm:t_uac: next_hop=sip:10.0.10.1 DBG:core:mk_proxy: doing DNS lookup... ERROR:core:get_out_socket: -- detected IP 10.0.10.2,proto=1 ERROR:tm:uri2sock: no corresponding socket for af 2 ERROR:tm:t_uac: no socket found ERROR:load_balancer:lb_do_probing: probing failed 10.0.10.1 is on another machine 10.0.10.2 is on this machine 10.0.10.3 is on this machine, and allocated to opensips via listen= Opensips should be binding to 10.0.1.3 which is specified in the listen= directive, not 10.0.10.2, which is another IP on the box but is not allocated to opensips. Summary: With mhomed=1 opensips is detecting the correct interface to ping from, but it is selecting an IP on that interface that is not specified in the listen= directives. Hopefully I explained the behavior clearly. Thanks, Bill. On 11/11/2010 11:39 AM, Bogdan-Andrei Iancu wrote: It looks to me more like a misconfiguration on network level for the machine ...Opensips tries to detect the interface with the default route to the destination IP (the info id provided by kernel)..So if the kernel sees 66.180.205.11 as default interface for reaching a private IP.does look sane to me :) Regards, Bogdan Bill W wrote: Ahhh, I see what's going on. Opensips is trying to probe from a different IP on that interface instead of the IP alias opensips bound to. For example, on the public interface I have IP 66.180.205.11 Then I have an IP alias of 66.180.205.3 on that same interface: eth0 66.180.205.11 freeswitch:5060 eth0:0 66.180.205.3 opensips:5060 DBG:tm:t_uac: next_hop=sip:66.180.205.11 DBG:core:mk_proxy: doing DNS lookup... ERROR:core:get_out_socket: -- detected IP 66.180.205.11,proto=1 ERROR:core:get_out_socket: no socket found ERROR:tm:uri2sock: no corresponding socket for af 2 ERROR:tm:t_uac: no socket found ERROR:load_balancer:lb_do_probing: probing failed It's not getting the IP from the listen= directive but from an interface probe, which is getting the wrong IP. On 11/11/2010 6:29 AM, Bogdan-Andrei Iancu wrote: Hi Bill, could you try the attached patch along mhomed option? the patch will simply print what is the IP opensips is trying to use for the outgoing probes Regards, Bogdan Bill W wrote: Hey Bogdan, Yes, I have 3 listen= lines; two with public IPs and one with a private IP. When I remove the mhomed=1 then things work as intended except for the probing. I can proxy traffic correctly on all interfaces. When I enable mhomed=1, then I get the errors below. Thanks, Bill On 11/10/2010 5:38 AM, Bogdan-Andrei Iancu wrote: Hi Bill, is your opensips actually listening (configured as listener in .cfg) on a interface in the private network (where the probing needs to be done) ?? Regards, Bogdan Bill W wrote: Hey Bogdan, I enabled the mhomed=1 parameter, and now I'm getting a bunch of errors in the logs. ERROR:tm:t_uac: no socket found ERROR:load_balancer:lb_do_probing: probing failed ERROR:core:get_out_socket: no socket found ERROR:tm:uri2sock: no corresponding socket for af 2 Thoughts? Bill On 11/8/2010 6:05 AM, Bogdan-Andrei Iancu wrote: Hi Bill, as you have a multi interface system, have you tried to enable the mhomed global parameter? http://www.opensips.org/Resources/DocsCoreFcn16#toc60 Regards, Bogdan Bill W. wrote: As an update, the load balancer probe appears to use the ip address specified by the first listen= directive. If I list the public IP first, then the probe tries to talk to the internal IP from the external interface IP. On 11/7/10 6:18 PM, Bill W. wrote: Hello everyone,
