Re: [OpenSIPS-Users] Problem Contact URI
Lionel Sicilia wrote:
Hi Lionel,
you show here a completely different issue - this new one has nothing to
do with the contact URI, but with the CSEQ number - opensips refuses a
new registration for that AOR as the (since the last registration done)
the callid was reused without increasing the CSEQ number...
Check the logs of your opensips server.
Regards,
Bogdan
I understand, but I think the error sequence produced by the client retry.
In this case opensips show the log and the client in the first request
in this case is not the CSeq error,
but there comes a warning to the ends of the header:
Dec 23 18:00:26 jerif opensips[16840]: DBG:core:parse_msg: SIP Request:
Dec 23 18:00:26 jerif opensips[16840]: DBG:core:parse_msg: method: REGISTER
Dec 23 18:00:26 jerif opensips[16840]: DBG:core:parse_msg: uri:
sip:aplay.com.ar
Dec 23 18:00:26 jerif opensips[16840]: DBG:core:parse_msg: version: SIP/2.0
Dec 23 18:00:26 jerif opensips[16840]: DBG:core:parse_headers: flags=2
Dec 23 18:00:26 jerif opensips[16840]: DBG:core:parse_via_param: found
param type 235, rport = n/a; state=6
Dec 23 18:00:26 jerif opensips[16840]: DBG:core:parse_via_param: found
param type 232, branch =
z9hG4bKPj4bc8a48485044538a2abb7813afe8139; state=16
Dec 23 18:00:26 jerif opensips[16840]: DBG:core:parse_via: end of
header reached, state=5
Dec 23 18:00:26 jerif opensips[16840]: DBG:core:parse_headers: via
found, flags=2
Dec 23 18:00:26 jerif opensips[16840]: DBG:core:parse_headers: this is
the first via
Dec 23 18:00:26 jerif opensips[16840]: DBG:core:receive_msg: After parse_msg...
Dec 23 18:00:26 jerif opensips[16840]: DBG:core:receive_msg: preparing
to run routing scripts...
Dec 23 18:00:26 jerif opensips[16840]: DBG:core:parse_headers: flags=100
Dec 23 18:00:26 jerif opensips[16840]: DBG:maxfwd:is_maxfwd_present: value = 70
Dec 23 18:00:26 jerif opensips[16840]: DBG:core:parse_headers: flags=8
Dec 23 18:00:26 jerif opensips[16840]: DBG:core:parse_to: end of
header reached, state=10
Dec 23 18:00:26 jerif opensips[16840]: DBG:core:parse_to: display={},
ruri={sip:7...@aplay.com.ar}
Dec 23 18:00:26 jerif opensips[16840]: DBG:core:get_hdr_field: To
[25]; uri=[sip:7...@aplay.com.ar]
Dec 23 18:00:26 jerif opensips[16840]: DBG:core:get_hdr_field: to body
[sip:7...@aplay.com.ar^M ]
Dec 23 18:00:26 jerif opensips[16840]: DBG:uri:has_totag: no totag
Dec 23 18:00:26 jerif opensips[16840]: DBG:core:parse_headers: flags=78
Dec 23 18:00:26 jerif opensips[16840]: DBG:core:get_hdr_field: cseq
CSeq: 46090 REGISTER
Dec 23 18:00:26 jerif opensips[16840]: DBG:tm:t_lookup_request: start
searching: hash=54174, isACK=0
Dec 23 18:00:26 jerif opensips[16840]: DBG:tm:matching_3261: RFC3261
transaction matching failed
Dec 23 18:00:26 jerif opensips[16840]: DBG:tm:t_lookup_request: no
transaction found
Dec 23 18:00:26 jerif opensips[16840]: DBG:core:parse_headers: flags=200
Dec 23 18:00:26 jerif opensips[16840]: DBG:core:get_hdr_field: content_length=0
Dec 23 18:00:26 jerif opensips[16840]: DBG:core:get_hdr_field: found
end of header
Dec 23 18:00:26 jerif opensips[16840]: DBG:rr:find_first_route: No
Route headers found
Dec 23 18:00:26 jerif opensips[16840]: DBG:rr:loose_route: There is no Route HF
Dec 23 18:00:26 jerif opensips[16840]: DBG:core:grep_sock_info:
checking if host==us: 12==12 [aplay.com.ar] == [192.168.2.21]
Dec 23 18:00:26 jerif opensips[16840]: DBG:core:grep_sock_info:
checking if port 5060 matches port 5060
Dec 23 18:00:26 jerif opensips[16840]: DBG:core:parse_headers:
flags=
Dec 23 18:00:26 jerif opensips[16840]: DBG:core:parse_headers: flags=800
Dec 23 18:00:26 jerif opensips[16840]: DBG:core:parse_headers:
flags=
Dec 23 18:00:26 jerif opensips[16840]: DBG:registrar:build_contact:
created Contact HF: Contact:
sip:7...@190.178.217.168:18196;expires=209,
sip:7...@190.178.217.168:18209;expires=300^M
Dec 23 18:00:26 jerif opensips[16840]: DBG:core:parse_headers:
flags=
Dec 23 18:00:26 jerif opensips[16840]: DBG:core:check_ip_address:
params 190.178.217.168, 190.178.217.168, 0
Dec 23 18:00:26 jerif opensips[16840]: DBG:core:destroy_avp_list:
destroying list (nil)
Dec 23 18:00:26 jerif opensips[16840]: DBG:core:receive_msg: cleaning up
16:59:20.381 pjsua_core.c TX 383 bytes Request msg
REGISTER/cseq=46090 (tdta0p49d04c0) to UDP 190.50.96.229:5060:
REGISTER sip:aplay.com.ar SIP/2.0
Via: SIP/2.0/UDP
192.168.2.84:11065;rport;branch=z9hG4bKPj4bc8a48485044538a2abb7813afe8139
Max-Forwards: 70
From: sip:7...@aplay.com.ar;tag=93d3bd7d06a44b08a0b63103b9389b4e
To: sip:7...@aplay.com.ar
Call-ID: f4d1ebca868647a8cd3ba2c55b8e
CSeq: 46090 REGISTER
Contact: sip:7...@192.168.2.84:11065
Expires: 300
Content-Length: 0
--end msg--
16:59:20.381pjsua_acc.c Registration sent
16:59:20.509 sip_transport. Error processing 663 bytes packet from
UDP 190.50.96.229:5060 : PJSIP syntax error exception when parsing ''
header on line 7 col 39:
SIP/2.0 200 OK
Via: SIP/2.0/UDP
Re: [OpenSIPS-Users] Virtual_DB issue with NDBClUSTER
I am afraid I don't. Looks like I must have deleted it. On Wed, Dec 22, 2010 at 4:02 AM, Bogdan-Andrei Iancu bog...@voice-system.ro wrote: Hi Duane, Do you still have the core file ? I would be interested in getting some info from there. Regards, Bogdan osiris123d wrote: I am trying to get OpenSIPS Virtual_DB module to work with a MySQL Cluster that I have set up. Instead of the database tables being the usual MyISAM I set them up to be NDBCLUSTER. Within the OpenSIPS config I have # - db_virtual params - modparam(db_virtual, db_urls, define set1 ROUND) modparam(db_virtual, db_urls, mysql://:***...@173.***.***.219/opensips) modparam(db_virtual, db_urls, mysql://:***...@173.***.***.218/opensips) To test I shut down the database on the 173.***.***.218 server and OpenSIPS went down. When I try to restart OpenSIPS I see the following in the syslog Dec 14 11:17:20 Proxy01 /usr/local/sbin/opensips[3843]: ERROR:db_mysql:db_mysql_connect: driver error(2003): Can't connect to MySQL server on '173.***.***.218' (111) Dec 14 11:17:20 Proxy01 /usr/local/sbin/opensips[3843]: ERROR:db_mysql:db_mysql_new_connection: initial connect failed Dec 14 11:17:20 Proxy01 /usr/local/sbin/opensips[3843]: ERROR:core:db_do_init: could not add connection to the pool Dec 14 11:17:20 Proxy01 /usr/local/sbin/opensips[3843]: ERROR:db_virtual:db_virtual_init: cant init db mysql://:**...@173.***.***.218/opensips Dec 14 11:17:20 Proxy01 /usr/local/sbin/opensips[3843]: ERROR:db_mysql:db_mysql_submit_query: driver error: Got error 157 'Unknown error code' from NDBCLUSTER Dec 14 11:17:20 Proxy01 /usr/local/sbin/opensips[3843]: ERROR:core:db_do_query: error while submitting query Dec 14 11:17:20 Proxy01 kernel: [235305.342266] opensips[3843]: segfault at 20 ip 004f4e03 sp 7fffb3965840 error 4 in opensips[40+14d000] Looks like it dumped the core and the core says (gdb) backtrace #0 0x004f4e03 in db_table_version (dbf=0x78d6e470, connection=0x8175e0, table=0x7f3e124e9b40) at db/db.c:359 #1 0x004f51d1 in db_check_table_version (dbf=0x0, dbh=0x0, table=0x7f3e124e9b40, version=7) at db/db.c:398 #2 0x7f3e122e585e in mod_init () at uri_mod.c:265 #3 0x00493514 in init_mod (m=0x798348) at sr_module.c:457 #4 0x004934ac in init_mod (m=0x798418) at sr_module.c:452 #5 0x004934ac in init_mod (m=0x7984e8) at sr_module.c:452 #6 0x004934ac in init_mod (m=0x7985b8) at sr_module.c:452 #7 0x004934ac in init_mod (m=0x798688) at sr_module.c:452 #8 0x004934ac in init_mod (m=0x798758) at sr_module.c:452 #9 0x004934ac in init_mod (m=0x798828) at sr_module.c:452 #10 0x004934ac in init_mod (m=0x7988f8) at sr_module.c:452 #11 0x004934ac in init_mod (m=0x7989c8) at sr_module.c:452 #12 0x004934ac in init_mod (m=0x798a98) at sr_module.c:452 #13 0x004934ac in init_mod (m=0x798b68) at sr_module.c:452 #14 0x004934ac in init_mod (m=0x798c38) at sr_module.c:452 #15 0x004934ac in init_mod (m=0x798d08) at sr_module.c:452 #16 0x004934ac in init_mod (m=0x798dd8) at sr_module.c:452 #17 0x004934ac in init_mod (m=0x798ea8) at sr_module.c:452 #18 0x004934ac in init_mod (m=0x798f78) at sr_module.c:452 #19 0x004934ac in init_mod (m=0x799048) at sr_module.c:452 #20 0x004934ac in init_mod (m=0x799118) at sr_module.c:452 #21 0x004934ac in init_mod (m=0x7991e8) at sr_module.c:452 #22 0x004934ac in init_mod (m=0x799528) at sr_module.c:452 #23 0x004934ac in init_mod (m=0x7996c8) at sr_module.c:452 #24 0x004934ac in init_mod (m=0x799798) at sr_module.c:452 #25 0x004934ac in init_mod (m=0x799868) at sr_module.c:452 #26 0x004934ac in init_mod (m=0x799a70) at sr_module.c:452 #27 0x004934ac in init_mod (m=0x799b40) at sr_module.c:452 #28 0x004934ac in init_mod (m=0x799c10) at sr_module.c:452 #29 0x004934ac in init_mod (m=0x799ce0) at sr_module.c:452 #30 0x004934ac in init_mod (m=0x799db0) at sr_module.c:452 #31 0x004934ac in init_mod (m=0x799e80) at sr_module.c:452 #32 0x004934ac in init_mod (m=0x799f50) at sr_module.c:452 #33 0x004934ac in init_mod (m=0x79a020) at sr_module.c:452 #34 0x0042c4f0 in main (argc=value optimized out, argv=value optimized out) at main.c:1351 Can you not use NDBCluster with OpenSIPS??? -- Bogdan-Andrei Iancu OpenSIPS Event - expo, conf, social, bootcamp 2 - 4 February 2011, ITExpo, Miami, USA www.voice-system.ro ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users -- -- *--*--*--*--*--* Duane *--*--*--*--*--* -- ___ Users mailing list Users@lists.opensips.org
[OpenSIPS-Users] [INFO] mailing list outage
Hi all, In the last 3 days, the mailing lists were not functioning due an exim issue: exim running on opensips.org was the target for an exploit (see http://www.exploit-db.com/exploits/15725/), damaging the setup for mail delivery. Now the issues was fixed, all damages created by the intrusion being removed, especially thanks to elred_ from IRC who help me with this task. For people not being able to post emails in the last days, please re-send your emails - mailing lists are now fully functional. Best regards, Bogdan -- Bogdan-Andrei Iancu OpenSIPS Event - expo, conf, social, bootcamp 2 - 4 February 2011, ITExpo, Miami, USA www.voice-system.ro ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] Using dispatcher and t_replicate()
Hi Jody,
Strange as the ds_select_dst() may fail because of only 2 reasons:
1) internal error (like no more mem, parsing error, etc)
2) no available destinations (if your cfg allows peer disabling by
script or probing) - do you do that in your script ?
Regards,
Bogdan
Jody Rudolph wrote:
Bogdan,
No other errors. I am testing non-production with only one endpoint registering
so theres not a lot of traffic going on.
As of right now all I have found is that this fails constantly:
ds_select_dst(1, 4);
t_replicate($du);
This does not (although it did fail only 4 times when I first made the change)
if ( ds_select_dst(1, 4) ) {
xlog(replicating to $du \n);
t_replicate($du);
} else {
xlog(failure to select);
}
Thanks,
Jody Rudolph
Qx.net
Office: (859) 255-1928
Fax:(859) 255-1798
jrudo...@qx.net
On Dec 23, 2010, at 11:07 AM, Bogdan-Andrei Iancu wrote:
Jody,
when ds_select_dst() fails, don't you get any other previous err logs giving
clues on the failures ?
Regards,
Bogdan
Jody Rudolph wrote:
Bogdan,
This is how I have I have been using it as a workaround. This does work 100% of
the time and $du is being populated by the dispatcher addresses in round-robin.
ds_select_dst(1, 4);
switch($du)
{
case sip:192.168.1.1:
xlog(reg destination address is $du\n);
t_replicate(sip:192.168.1.1);
break;
case sip:192.168.1.2:
xlog(reg destination address is $du\n);
t_replicate(sip:192.168.1.2);
break;
}
I changed it to the if statement you suggested and I also see the expected behavior. The correct IPs are being logged from the xlog(replicating to $du \n); statement.
The strange part is this:
Using the following
if ( ds_select_dst(1, 4) ) {
xlog(replicating to $du \n);
t_replicate($du);
} else {
xlog(failure to select);
}
The first 4 registrations processed triggered a failure to select. After
that, it started working as expected. I have since restarted the service 5 times with no
occurrences of failure.
After this I reverted to the original configuration of
ds_select_dst(1, 4);
t_replicate($du);
Dec 23 10:09:39 [16005] ERROR:core:parse_uri: bad uri, state 0 parsed: nul (4) /
null (6)
Dec 23 10:09:39 [16005] ERROR:tm:uri2proxy: bad_uri: null
Dec 23 10:09:39 [16005] ERROR:tm:t_forward_nonack: failure to add branches
I will run it in the if statement for a while and monitor the results.
Thanks,
Jody
On Dec 23, 2010, at 9:33 AM, Bogdan-Andrei Iancu wrote:
Hi Jody,
in 1.6.4, it seams that $du is NULL (no value) - are you sure the ds_select_dst() was
successful ? put it in an if statement :
if ( ds_select_dst(1, 4) ) {
xlog(replicating to $du \n);
t_replicate($du);
} else {
xlog(failure to select);
}
Regards,
Bogdan
Jody Rudolph wrote:
Bogdan,
I am using SVN latest 1.6 via:
|svn co https://opensips.svn.sourceforge.net/svnroot/opensips/branches/1.6
opensips_1_6|
I tried last week at 1.6.3 and received the errors I posted in the previous
email. After 1.6.4 the error messages have changed slightly but still seems to
be related.
call to function:
ds_select_dst(1, 4);
t_replicate($du);
1.6.3 error:
Dec 20 13:16:02 [12858] ERROR:core:parse_uri: uri too short: $du (3)
Dec 20 13:16:02 [12858] ERROR:tm:uri2proxy: bad_uri: $du
1.6.4 error:
Dec 22 10:18:50 [11874] ERROR:core:parse_uri: bad uri, state 0 parsed: nul (4) /
null (6)
Dec 22 10:18:50 [11874] ERROR:tm:uri2proxy: bad_uri: null
Dec 22 10:18:50 [11874] ERROR:tm:t_forward_nonack: failure to add branches
Thanks,
Jody
On Dec 22, 2010, at 5:18 AM, Bogdan-Andrei Iancu wrote:
Hi Jody,
What version / revsion number are you testing with ?
That add-on in still there (trunk and 1.6) as far I checked.
Regards,
Bogdan
Jody Rudolph wrote:
This was added and working at one time but in the latest SVN it seems to have
reverted back to non-working. Am I missing a setting that has changed?
ds_select_dst(1, 4);
t_replicate($du);
Dec 20 13:16:02 [12858] ERROR:core:parse_uri: uri too short: $du (3)
Dec 20 13:16:02 [12858] ERROR:tm:uri2proxy: bad_uri: $du
Thanks,
Jody Rudolph
On Oct 4, 2010, at 9:57 AM, Razvan Crainea wrote:
/ Hi Jody,
// // I just made a commit with this feature. Now t_replicate can also receive
// a pseudo-variable as argument.
// Please update from svn (it is both in trunk and 1.6).
// // Regards,
// // -- // Razvan Crainea
// www.voice-system.ro http://www.voice-system.ro
http://www.voice-system.ro
// // // // On 10/04/2010 02:17 PM, Bogdan-Andrei Iancu
[OpenSIPS-Users] On Hold Recognition in 1.6.4
I saw a new feature for detecting on hold; Where could I see a small example of this? Thanks ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] several crashes in a row
Hi Juha, The backtrace is corrupted and the only useful info I can see from there is that the crash is related to libxml2 library (used for parsing the XML bodies). The logs shows that the crashed process is the timer (if I'm not wrong) - last messages show the DB cleanup and the DB flush. And there there are no XML parsing ops done That is a bit odd... Regards, Bogdan Juha Heinanen wrote: Bogdan-Andrei Iancu writes: Is there a way to reproduce such crash ? bogdan, a SIP UA vendor did some presence tests when the crashes happened. i asked them to try again today, but so far i have not seen the crashes. one of reasons might have been malformed xml bodies in publish requests. below are some syslog entries preceding the crashes. -- juha Dec 20 10:08:49 lohi /usr/sbin/pres-serv[2447]: INFO: Handling PUBLISH sip:j...@test.fi Dec 20 10:08:49 lohi /usr/sbin/pres-serv[2464]: CRITICAL:core:receive_fd: EOF on 21 Dec 20 10:30:09 lohi /usr/sbin/pres-serv[14005]: INFO: Handling SUBSCRIBE sip:j...@test.fi Dec 20 10:30:09 lohi /usr/sbin/pres-serv[14005]: INFO:db_mysql:re_init_statement: query is select status,reason from watchers where presentity_uri=? AND watcher_username=? AND watcher_domain=? AND event=?, ptr=(nil) Dec 20 10:30:09 lohi /usr/sbin/pres-serv[14005]: INFO:db_mysql:re_init_statement: query is insert into watchers (presentity_uri,watcher_username,watcher_domain,event,status,inserted_time,reason ) values (?,?,?,?,?,?,?), ptr=(nil) Dec 20 10:30:09 lohi /usr/sbin/pres-serv[13990]: INFO:core:handle_sigs: child process 14005 exited by a signal 11 Dec 20 10:33:28 lohi /usr/sbin/pres-serv[14061]: INFO: Handling PUBLISH sip:j...@test.fi Dec 20 10:33:28 lohi /usr/sbin/pres-serv[14077]: CRITICAL:core:receive_fd: EOF on 21 Dec 20 10:48:34 lohi /usr/sbin/pres-serv[14353]: INFO:db_mysql:re_init_statement: query is delete from active_watchers where expires?, ptr=(nil) Dec 20 10:48:34 lohi /usr/sbin/pres-serv[14353]: INFO:db_mysql:re_init_statement: query is insert into active_watchers (presentity_uri,callid,to_tag,from_tag,to_user,to_domain,watcher_username,watcher_domain,event,event_id,local_cseq,remote_cseq,expires,status,reason,record_route,contact,local_contact,socket\ _info,version ) values (?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?), ptr=(nil) Dec 20 10:48:35 lohi /usr/sbin/pres-serv[14339]: INFO:core:handle_sigs: child process 14353 exited by a signal 11 ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users -- Bogdan-Andrei Iancu OpenSIPS Event - expo, conf, social, bootcamp 2 - 4 February 2011, ITExpo, Miami, USA www.voice-system.ro ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] several crashes in a row
Bogdan-Andrei Iancu writes: The backtrace is corrupted and the only useful info I can see from there is that the crash is related to libxml2 library (used for parsing the XML bodies). The logs shows that the crashed process is the timer (if I'm not wrong) - last messages show the DB cleanup and the DB flush. And there there are no XML parsing ops done it has happened only once. could be memory corruption or some other hw related thing. we'll do more test after holidays. -- juha ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] Using SIPP with OpenSIPS Authentication
Hi Duane, how opensips handles the passwords (textplain or pre-calculated HA1) does not affect at all the authentication process from UAC point of view. So as any other UACs, SIPP perfectly works in both cases. Regards, Bogdan duane.lar...@gmail.com wrote: Does anyone have any examples of using SIPP with OpenSIPS + Authentication? I currently have OpenSIPS set to use ha1 passwords. Not sure if I can do something with SIPP to work with ha1 MD5 or if I just need to temporarily configure opensips to use unencrypted passwords during testing. ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users -- Bogdan-Andrei Iancu OpenSIPS Event - expo, conf, social, bootcamp 2 - 4 February 2011, ITExpo, Miami, USA www.voice-system.ro ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] Using dispatcher and t_replicate()
Bogdan,
I am. The following are the dispatcher params.
modparam(dispatcher, db_url, mysql://DB LOCATION/opensips)
modparam(dispatcher, flags,2)
modparam(dispatcher, ds_probing_mode, 0)
modparam(dispatcher, ds_ping_interval, 10)
This does explain the 4 failures when i restarted after changing the script to
include the IF statement.
I am using the IF statement now and running for 4-5 days with no failure. Seems
to only break when the IF statement is not in place. I should have been using
the IF the whole time. That's what I get for being lazy.
Thanks,
Jody
On Dec 27, 2010, at 2:45 PM, Bogdan-Andrei Iancu wrote:
Hi Jody,
Strange as the ds_select_dst() may fail because of only 2 reasons:
1) internal error (like no more mem, parsing error, etc)
2) no available destinations (if your cfg allows peer disabling by script or
probing) - do you do that in your script ?
Regards,
Bogdan
Jody Rudolph wrote:
Bogdan,
No other errors. I am testing non-production with only one endpoint
registering so theres not a lot of traffic going on.
As of right now all I have found is that this fails constantly:
ds_select_dst(1, 4);
t_replicate($du);
This does not (although it did fail only 4 times when I first made the
change)
if ( ds_select_dst(1, 4) ) {
xlog(replicating to $du \n);
t_replicate($du);
} else {
xlog(failure to select);
}
Thanks,
Jody Rudolph
Qx.net
Office: (859) 255-1928
Fax: (859) 255-1798
jrudo...@qx.net
On Dec 23, 2010, at 11:07 AM, Bogdan-Andrei Iancu wrote:
Jody,
when ds_select_dst() fails, don't you get any other previous err logs
giving clues on the failures ?
Regards,
Bogdan
Jody Rudolph wrote:
Bogdan,
This is how I have I have been using it as a workaround. This does work
100% of the time and $du is being populated by the dispatcher addresses in
round-robin.
ds_select_dst(1, 4);
switch($du)
{
case sip:192.168.1.1:
xlog(reg destination address is $du\n);
t_replicate(sip:192.168.1.1);
break;
case sip:192.168.1.2:
xlog(reg destination address is $du\n);
t_replicate(sip:192.168.1.2);
break;
}
I changed it to the if statement you suggested and I also see the expected
behavior. The correct IPs are being logged from the xlog(replicating to
$du \n); statement. The strange part is this:
Using the following
if ( ds_select_dst(1, 4) ) {
xlog(replicating to $du \n);
t_replicate($du);
} else {
xlog(failure to select);
}
The first 4 registrations processed triggered a failure to select. After
that, it started working as expected. I have since restarted the service 5
times with no occurrences of failure.
After this I reverted to the original configuration of
ds_select_dst(1, 4);
t_replicate($du);
Dec 23 10:09:39 [16005] ERROR:core:parse_uri: bad uri, state 0 parsed:
nul (4) / null (6)
Dec 23 10:09:39 [16005] ERROR:tm:uri2proxy: bad_uri: null
Dec 23 10:09:39 [16005] ERROR:tm:t_forward_nonack: failure to add branches
I will run it in the if statement for a while and monitor the results.
Thanks,
Jody
On Dec 23, 2010, at 9:33 AM, Bogdan-Andrei Iancu wrote:
Hi Jody,
in 1.6.4, it seams that $du is NULL (no value) - are you sure the
ds_select_dst() was successful ? put it in an if statement :
if ( ds_select_dst(1, 4) ) {
xlog(replicating to $du \n);
t_replicate($du);
} else {
xlog(failure to select);
}
Regards,
Bogdan
Jody Rudolph wrote:
Bogdan,
I am using SVN latest 1.6 via:
|svn co
https://opensips.svn.sourceforge.net/svnroot/opensips/branches/1.6
opensips_1_6|
I tried last week at 1.6.3 and received the errors I posted in the
previous email. After 1.6.4 the error messages have changed slightly but
still seems to be related.
call to function:
ds_select_dst(1, 4);
t_replicate($du);
1.6.3 error:
Dec 20 13:16:02 [12858] ERROR:core:parse_uri: uri too short: $du (3)
Dec 20 13:16:02 [12858] ERROR:tm:uri2proxy: bad_uri: $du
1.6.4 error:
Dec 22 10:18:50 [11874] ERROR:core:parse_uri: bad uri, state 0 parsed:
nul (4) / null (6)
Dec 22 10:18:50 [11874] ERROR:tm:uri2proxy: bad_uri: null
Dec 22 10:18:50 [11874] ERROR:tm:t_forward_nonack: failure to add
branches
Thanks,
Jody
On Dec 22, 2010, at 5:18 AM, Bogdan-Andrei Iancu wrote:
Hi Jody,
What version / revsion number are you testing with ?
That add-on in still there (trunk and 1.6) as far I checked.
Regards,
Bogdan
Jody Rudolph wrote:
This was added and working at one time but in the latest SVN it seems
to have reverted back
Re: [OpenSIPS-Users] Problem Contact URI
The 'Warning' header does not report an error it just provides debugging
information from inside opensips - you can turn it on/off with the
sip_warning core parameter:
http://www.opensips.org/Resources/DocsCoreFcn16#toc68
Now, about the error in the pjsip stack - it reports line 7 (assuming
from the entire message), which is:
Contact: sip:7...@192.168.2.84:11065:18196;expires=209,
sip:7...@190.178.217.168:18209;expires=300
most probably because of the double port in the first contact entry.
So, you need to look for the part where you are saving contacts in user
location - save(location) - here, do you do any processing of the SIP
contact, before the actual save, like fix_nated_contact() or
fix_nated_register() ?
Regards,
Bogdan
Thank you for your significant responses, sip_warning parameter was
already set with the value yes now changed to 1. But the log still
shows the debug to send in the mail earlier.
debug=9
log_stderror=no
log_facility=LOG_LOCAL0
fork=yes
children=4
sip_warning=1
On the other hand I've tried to fix_nated_register () and others, the
code below just before save location. Unfortunately this did not
fix the problem of generating in the contact uri multiple ports.
if (is_method(REGISTER))
{
fix_nated_register();
fix_nated_contact();
fix_contact();
# authenticate the REGISTER requests (uncomment to enable auth)
##if (!www_authorize(, subscriber))
##{
## www_challenge(, 0);
## exit;
##}
##
##if (!db_check_to())
##{
## sl_send_reply(403,Forbidden auth ID);
## exit;
##}
if (!save(location))
sl_reply_error();
exit;
}
Regards,
--
Lionel Sicilia.
CTO - Aplay S.A.
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
[OpenSIPS-Users] Buggy SDP
I was wondering if it is possible to modify the SDP information a client is sending? I see it sends some invalid chars; If I could somehow look for that line in the SDP and delete it would be great. Thanks. ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] opensips HA resource script (for Heartbeat)
2010/12/22 Alexandr A. Alexandrov shurr...@gmail.com: Does anyone by chance have opensips HA resource script (for using with Heartbeat)? OpenSIPS is not good for init scripts as when running daemonized it returns 0 (ok) even if it fails to start (due to DB wrong connection or whatever module error). So HA would start OpenSIPS. The OpenSIPs init script (or HA LSB / OCF script) returns 0, but the fact is that the daemonized (forked) process has failed to start (i.e. any module error). Later HA monitors OpenSIPS status (by using the LSB script status action or the OCF script monitor action) and realizes that OpenSIPS is not running. Then HA tries to start it again, such action returns 0 again (the script returns 0 as there are not grammar errors in the config script) so HA is happy, but again, OpenSIPS is not running, and so on. This makes OpenSIPS not valid for full HA environment, so be careful. -- Iñaki Baz Castillo i...@aliax.net ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] opensips HA resource script (for Heartbeat)
I am using the following attached resource with OK success. I was having
some weird issues when restarting or moving the resource to another server
and it sounds like those issues might have something to do with what Inaki
was talking about.
So if OpenSIPS always returns 0 how are people making it redundant? Monit
is very good but if you need OpenSIPS to use a Clustered IP address you
really need to use HA.
On Mon, Dec 27, 2010 at 7:55 PM, Iñaki Baz Castillo i...@aliax.net wrote:
2010/12/22 Alexandr A. Alexandrov shurr...@gmail.com:
Does anyone by chance have opensips HA resource script (for using with
Heartbeat)?
OpenSIPS is not good for init scripts as when running daemonized it
returns 0 (ok) even if it fails to start (due to DB wrong connection
or whatever module error).
So HA would start OpenSIPS. The OpenSIPs init script (or HA LSB / OCF
script) returns 0, but the fact is that the daemonized (forked)
process has failed to start (i.e. any module error).
Later HA monitors OpenSIPS status (by using the LSB script status
action or the OCF script monitor action) and realizes that OpenSIPS
is not running. Then HA tries to start it again, such action returns 0
again (the script returns 0 as there are not grammar errors in the
config script) so HA is happy, but again, OpenSIPS is not running, and
so on.
This makes OpenSIPS not valid for full HA environment, so be careful.
--
Iñaki Baz Castillo
i...@aliax.net
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
--
--
*--*--*--*--*--*
Duane
*--*--*--*--*--*
--
#!/bin/sh
# Initialization:
. /usr/lib/ocf/resource.d/heartbeat/.ocf-shellfuncs
usage() {
cat -!
usage: $0 {start|stop|status|monitor|meta-data|validate-all}
!
}
meta_data() {
cat END
?xml version=1.0?
!DOCTYPE resource-agent SYSTEM ra-api-1.dtd
resource-agent name=OpenSIPS
version1.0/version
longdesc lang=en
Resource Agent for the OpenSIPS SIP Proxy.
/longdesc
shortdesc lang=enOpenSIPS resource agent/shortdesc
parameters
parameter name=ip unique=0 required=1
longdesc lang=en
IP Address of the OpenSIPS Instance. This is only used for monitoring.
/longdesc
shortdesc lang=enIP Address/shortdesc
content type=string default= /
/parameter
parameter name=port unique=0 required=1
longdesc lang=en
Port of the OpenSIPS Instance. This is only used for monitoring.
/longdesc
shortdesc lang=enPort/shortdesc
content type=string default=5060 /
/parameter
/parameters
actions
action name=start timeout=60 /
action name=stop timeout=60 /
action name=status depth=0 timeout=30 interval=10 start-delay=60 /
action name=monitor depth=0 timeout=30 interval=10 start-delay=60 /
action name=meta-data timeout=5 /
action name=validate-all timeout=5 /
action name=notify timeout=5 /
action name=promote timeout=5 /
action name=demote timeout=5 /
/actions
/resource-agent
END
}
OpenSIPS_Status() {
/usr/bin/sipsak -s sip:lvsheartbeatch...@$ocf_reskey_ip -H 127.0.0.1
2/dev/null /dev/null
rc=$?
if
[ $rc -ne 0 ]
then
echo -e `date +%b %e %H:%M:%S` OpenSIPS_STATUS(): RC [$rc] is not equal to
0 /var/log/syslog
return $OCF_NOT_RUNNING
else
echo -e `date +%b %e %H:%M:%S` OpenSIPS_STATUS(): RC [$rc] is equal to 0
/var/log/syslog
return $OCF_SUCCESS
fi
}
OpenSIPS_Monitor( ) {
echo -e `date +%b %e %H:%M:%S` OpenSIPS_Monitor(): Called /var/log/syslog
OpenSIPS_Status
}
OpenSIPS_Start( ) {
if
OpenSIPS_Status
then
ocf_log info OpenSIPS already running.
echo -e `date +%b %e %H:%M:%S` OpenSIPS_Start():
OpenSIPS is already running /var/log/syslog
return $OCF_SUCCESS
else
/etc/init.d/opensips start /dev/null
rc=$?
if [ $rc -ne 0 ]
then
echo -e `date +%b %e %H:%M:%S` OpenSIPS_Start(): RC
[$rc] is not equal to 0 and we couldn't start OpenSIPS /var/log/syslog
return $OCF_ERR_PERM
else
echo -e `date +%b %e %H:%M:%S` OpenSIPS_Start(): RC
[$rc] is equal to 0 and we started OpenSIPS /var/log/syslog
return $OCF_SUCCESS
fi
fi
}
OpenSIPS_Stop( ) {
echo -e `date +%b %e %H:%M:%S` OpenSIPS_Stop(): About to stop OpenSIPS
/var/log/syslog
/etc/init.d/opensips stop /dev/null
echo -e `date +%b %e %H:%M:%S` OpenSIPS_Stop(): Just stopped OpenSIPS
/var/log/syslog
return $OCF_SUCCESS
}
OpenSIPS_Validate_All( ) {
return $OCF_SUCCESS
}
if [ $# -ne 1 ]; then
usage
exit $OCF_ERR_ARGS
fi
case $1 in
meta-data) meta_data
exit $OCF_SUCCESS
;;
start) OpenSIPS_Start
;;
stop) OpenSIPS_Stop
;;
monitor) OpenSIPS_Monitor
;;
status) OpenSIPS_Status
;;
validate-all) OpenSIPS_Validate_All
;;
notify) exit $OCF_SUCCESS
;;
promote) exit $OCF_SUCCESS
;;
demote) exit $OCF_SUCCESS
;;
usage)
Re: [OpenSIPS-Users] opensips HA resource script (for Heartbeat)
2010/12/28 Duane Larson duane.lar...@gmail.com: So if OpenSIPS always returns 0 how are people making it redundant? A very dirty hack is invoking the monitor / status action of the script N seconds after the start action, and makes the script to return the exit code of the monitor / status action. But it's really a dirty hack. A daemonized process should not exit with 0 if finally it fails to start. -- Iñaki Baz Castillo i...@aliax.net ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] On Hold Recognition in 1.6.4
See the textops README file: http://www.opensips.org/html/docs/modules/devel/textops.html#id250476 Regards, Ovidiu Sas On Mon, Dec 27, 2010 at 2:47 PM, David J. da...@styleflare.com wrote: I saw a new feature for detecting on hold; Where could I see a small example of this? Thanks ___ 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
[OpenSIPS-Users] RTPProxy timeout notifications
Hello! During tests of new feature in rtpproxy I received such problem: “Dec 27 11:42:42 opensips /usr/local/opensips1.6.4/sbin/opensips[26496]: DBG:nathelper:timeout_listener_process: unknown rtpproxy – ignoring” And log for rtpproxy “Dec 28 07:43:37 opensips rtpproxy[28223]: INFO:handle_command: new session 6fe1-00bf-8e08-8065-0002a405c...@172.31.255.250, tag 6f008e65a4;1 requested, type strong Dec 28 07:43:37 opensips rtpproxy[28223]: INFO:handle_command: new session on a port 64922 created, tag 6f008e65a4;1 Dec 28 07:43:37 opensips rtpproxy[28223]: INFO:handle_command: setting timeout handler Dec 28 07:43:37 opensips rtpproxy[28223]: INFO:handle_command: pre-filling caller's address with 3.3.3.3:23066 Dec 28 07:43:37 opensips /usr/local/opensips1.6.4/sbin/opensips[28196]: ERROR:nathelper:force_rtp_proxy: Unable to parse body Dec 28 07:43:38 opensips rtpproxy[28223]: INFO:handle_command: lookup on ports 64922/4, session timer restarted Dec 28 07:43:38 opensips rtpproxy[28223]: INFO:handle_command: pre-filling callee's address with 2.2.2.2:18408 Dec 28 07:43:39 opensips rtpproxy[28223]: INFO:handle_command: lookup on ports 64922/4, session timer restarted Dec 28 07:44:07 opensips rtpproxy[28223]: INFO:process_rtp: session timeout Dec 28 07:44:07 opensips rtpproxy[28223]: INFO:remove_session: RTP stats: 1449 in from callee, 421 in from caller, 1870 relayed, 0 dropped Dec 28 07:44:07 opensips rtpproxy[28223]: INFO:remove_session: RTCP stats: 7 in from callee, 2 in from caller, 9 relayed, 0 dropped Dec 28 07:44:07 opensips rtpproxy[28223]: INFO:remove_session: session on ports 64922/4 is cleaned up Dec 28 07:44:07 opensips rtpproxy[28223]: ERR:do_timeout_notification: failed to send timeout notification: Broken pipe” Opensips 1.6.4 Latest rtpproxy from git with patch for RTPProxy timeout notifications The start string of rtpproxy: /usr/local/rtpproxy/bin/rtpproxy -l 1.1.1.1 -s unix:/var/run/rtpproxy.sock -F -i -n tcp:1.1.1.1:2 -T 20 -W 60 Opensips.cfg: … … modparam(nathelper, rtpproxy_sock, /var/run/rtpproxy.sock) modparam(nathelper, rtpp_notify_socket, tcp:1.1.1.1:2) … … rtpproxy_offer(con); …. rtpproxy_answer(con); … During voice session everything fine (bidirectional voice flow). Then I emulate LAN problem and after 20 s expire I received such message. Call is still active. Thank you for any help. ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] opensips HA resource script (for Heartbeat)
Hi, All. This is an issue of writing a correct script, nothing more. :-) There are several possibilities, strating from simple process lookup (like pgrep -f opensips), ending using MI from such a script. This makes OpenSIPS not valid for full HA environment, so be careful. I will make my opensips valid, was just wondering if someone already invented that bicycle. :-) 28.12.2010 04:55, Iñaki Baz Castillo: 2010/12/22 Alexandr A. Alexandrovshurr...@gmail.com: Does anyone by chance have opensips HA resource script (for using with Heartbeat)? OpenSIPS is not good for init scripts as when running daemonized it returns 0 (ok) even if it fails to start (due to DB wrong connection or whatever module error). So HA would start OpenSIPS. The OpenSIPs init script (or HA LSB / OCF script) returns 0, but the fact is that the daemonized (forked) process has failed to start (i.e. any module error). Later HA monitors OpenSIPS status (by using the LSB script status action or the OCF script monitor action) and realizes that OpenSIPS is not running. Then HA tries to start it again, such action returns 0 again (the script returns 0 as there are not grammar errors in the config script) so HA is happy, but again, OpenSIPS is not running, and so on. This makes OpenSIPS not valid for full HA environment, so be careful. ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] Buggy SDP
On 28/12/10 1:11 AM, David J. wrote: I was wondering if it is possible to modify the SDP information a client is sending? I see it sends some invalid chars; If I could somehow look for that line in the SDP and delete it would be great. Have a look at the textops module: http://www.opensips.org/html/docs/modules/1.6.x/textops.html -- Saúl Ibarra Corretgé AG Projects ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
