[OpenSIPS-Devel] [ opensips-Patches-3602478 ] b2b - custom_headers_regexp option
Patches item #3602478, was opened at 2013-01-28 22:52 Message generated for change (Tracker Item Submitted) made by nikbyte You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=1086412&aid=3602478&group_id=232389 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: modules Group: trunk Status: Open Resolution: None Priority: 5 Private: No Submitted By: Nick Altmann (nikbyte) Assigned to: Nobody/Anonymous (nobody) Summary: b2b - custom_headers_regexp option Initial Comment: Regexp to search SIP header by names that should be passed from the dialog of one side to the other side. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=1086412&aid=3602478&group_id=232389 ___ Devel mailing list Devel@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
[OpenSIPS-Devel] [ opensips-Patches-3602413 ] b2b - initial headers support
Patches item #3602413, was opened at 2013-01-28 08:36 Message generated for change (Settings changed) made by nikbyte You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=1086412&aid=3602413&group_id=232389 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: modules Group: trunk >Status: Deleted Resolution: None Priority: 5 Private: No Submitted By: Nick Altmann (nikbyte) Assigned to: Nobody/Anonymous (nobody) Summary: b2b - initial headers support Initial Comment: Adds two parameters: initial_headers (str): A list of SIP header names delimited by ';' that should be copied from the dialog of one side to the other side with another names taking from applying "initial_headers_regexp" regexp on original names. Also you may use "magic" header "X-Original-SRC", containing source uri of initial packet. and initial_headers_regexp(str): Regexp applied to headers from initial_headers parameter. Also it removes old init_callid_hdr parameter. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=1086412&aid=3602413&group_id=232389 ___ Devel mailing list Devel@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
[OpenSIPS-Devel] [ opensips-Patches-3565679 ] [acc] Failure Route Changes
Patches item #3565679, was opened at 2012-09-07 16:39 Message generated for change (Comment added) made by dmsanders You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=1086412&aid=3565679&group_id=232389 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: modules Group: 1.8.x Status: Open Resolution: Invalid Priority: 5 Private: No Submitted By: David Sanders (dmsanders) Assigned to: Bogdan-Andrei Iancu (bogdan_iancu) Summary: [acc] Failure Route Changes Initial Comment: At the moment the ACC module will log a failed call after any set onreply_route, but before a failure_route. The attached patch is a simple change to the TM callback registered for by on_missed so that the callback fires after the failure_route, allowing any changes made in the failure_route to show up in the logged call. Patch has been tested and worked as expected, however, I'm not positive that I haven't overlooked some other side-effect of the change. -- >Comment By: David Sanders (dmsanders) Date: 2013-01-28 13:55 Message: Hi Bogdan, Strange...this patch does look wrong. However, it was long enough ago that I don't remember my thought process. :) Seemed to work at the time, although now I don't know how that's possible. Can you remove TMCB_ON_FAILURE_RO from t_hooks.h/c since it is obsolete? - David -- Comment By: Bogdan-Andrei Iancu (bogdan_iancu) Date: 2013-01-28 05:36 Message: Hi David, There is something weird in the patch : 1) you changed from TMCB_ON_FAILURE to TMCB_ON_FAILURE_RO only in the callback function, but not where callback is registered too. 2) the TMCB_ON_FAILURE_RO callback is obsoleted in TM and never trigger .. Are you sure you attached the right patch ? Regards, Bogdan -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=1086412&aid=3565679&group_id=232389 ___ Devel mailing list Devel@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
[OpenSIPS-Devel] SF.net SVN: opensips:[9679] trunk/modules/sipmsgops
Revision: 9679 http://opensips.svn.sourceforge.net/opensips/?rev=9679&view=rev Author: bogdan_iancu Date: 2013-01-28 18:40:45 + (Mon, 28 Jan 2013) Log Message: --- -stream_exists() and stream_delete() functions added Modified Paths: -- trunk/modules/sipmsgops/README trunk/modules/sipmsgops/codecs.c trunk/modules/sipmsgops/codecs.h trunk/modules/sipmsgops/doc/sipmsgops_admin.xml trunk/modules/sipmsgops/sipmsgops.c This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site. ___ Devel mailing list Devel@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
[OpenSIPS-Devel] SF.net SVN: opensips:[9678] trunk/futex_lock.h
Revision: 9678 http://opensips.svn.sourceforge.net/opensips/?rev=9678&view=rev Author: vladut-paiu Date: 2013-01-28 17:40:58 + (Mon, 28 Jan 2013) Log Message: --- fixed typo Credits to Ryan Bullock Modified Paths: -- trunk/futex_lock.h This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site. ___ Devel mailing list Devel@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
[OpenSIPS-Devel] SF.net SVN: opensips:[9677] trunk/modules/dialog
Revision: 9677 http://opensips.svn.sourceforge.net/opensips/?rev=9677&view=rev Author: vladut-paiu Date: 2013-01-28 17:14:30 + (Mon, 28 Jan 2013) Log Message: --- fixed race condition that would lead to invalid memory access when using dialog pinging Modified Paths: -- trunk/modules/dialog/dlg_handlers.c trunk/modules/dialog/dlg_hash.c trunk/modules/dialog/dlg_req_within.c trunk/modules/dialog/dlg_timer.c This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site. ___ Devel mailing list Devel@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
Re: [OpenSIPS-Devel] Improved socket error messages
Hello Saul and Bogdan, On Mon., Jan. 28, 2013, Bogdan-Andrei Iancu wrote: >On Jan 28, 2013, Michael Schloh von Bennewitz wrote: >>On Mon., Jan. 28, 2013, Saúl Ibarra Corretgé wrote: >>>On Jan 27, 2013, at 8:17 PM, Michael Schloh von Bennewitz wrote: Jan 02 18:18:02 hostname opensips[1234]: ERROR:core:tcp_blocking_connect: addr (1.2.3.4) port (98765), failed to retrieve SO_ERROR (146) Connection refused ...which of course is much more useful. [...] - LM_ERR("failed to retrieve SO_ERROR (%d) %s\n", err, + LM_ERR("addr (%s) port (%d), failed to retrieve SO_ERROR (%d) %s\n", inet_ntoa(((struct sockaddr_in *)servaddr)->sin_addr), ntohs(((struct sockaddr_in *)servaddr)->sin_port), err, strerror(err)); goto error; } >>>Improved logging messages are of course great :-) I have a few unfinished >>>patches in this regard as well, so if you send over partial improvements >>>I'll incorporate them. However, the patch you sent is not correct because it >>>doesn't deal with IPv6 addresses, you need to check the sa_family field of >>>the sockaddr struct before casting it to sockaddr_in or sockaddr_in6. >>> >>Wow, that's quite embarassing considering that I'm running IPv6 >>myself. Here are two equivalent corrected versions of the hack. >>You probably want the second which is easier to read. >> >>diff -Nau tcp_main.c.orig tcp_main.c >>--- tcp_main.c.orig 2013-01-27 19:35:31.898051715 +0100 >>+++ tcp_main.c2013-01-28 18:30:27.516978242 +0100 >>@@ -342,7 +342,8 @@ >> getsockopt(fd, SOL_SOCKET, SO_ERROR, &err, &err_len); >> if ((err==0) && (poll_err==0)) goto end; >> if (err!=EINPROGRESS && err!=EALREADY){ >>- LM_ERR("failed to retrieve SO_ERROR (%d) %s\n", >>err, >>+ char erraddrstr[INET6_ADDRSTRLEN]; >>+ LM_ERR("addr (%s) port (%d), failed to retrieve >>SO_ERROR (%d) %s\n", servaddr->sa_family == AF_INET ? inet_ntoa(((struct >>sockaddr_in *)servaddr)->sin_addr) : inet_ntop(AF_INET6, &((struct >>sockaddr_in6 *)servaddr)->sin6_addr, erraddrstr, sizeof(erraddrstr)), >>servaddr->sa_family == AF_INET ? ntohs(((struct sockaddr_in >>*)servaddr)->sin_port) : ntohs(((struct sockaddr_in6 *)servaddr)->sin6_port), >>err, >> strerror(err)); >> goto error; >> } >> >>diff -Nau tcp_main.c.orig tcp_main.c >>--- tcp_main.c.orig 2013-01-27 19:35:31.898051715 +0100 >>+++ tcp_main.c2013-01-28 18:35:23.761388145 +0100 >>@@ -342,8 +342,11 @@ >> getsockopt(fd, SOL_SOCKET, SO_ERROR, &err, &err_len); >> if ((err==0) && (poll_err==0)) goto end; >> if (err!=EINPROGRESS && err!=EALREADY){ >>- LM_ERR("failed to retrieve SO_ERROR (%d) %s\n", >>err, >>- strerror(err)); >>+ char erraddrstr[INET6_ADDRSTRLEN]; >>+ if (servaddr->sa_family == AF_INET) >>+ LM_ERR("addr (%s) port (%d), failed to >>retrieve SO_ERROR (%d) %s\n", inet_ntoa(((struct sockaddr_in >>*)servaddr)->sin_addr), ntohs(((struct sockaddr_in *)servaddr)->sin_port), >>err, strerror(err)); >> >See an improved version of your patch here on commit #9666 : >http://opensips.svn.sourceforge.net/opensips/?rev=9666&view=rev > >If you consider adding that extra info in other places, please >provide a patch. > Your correction is better than my correction so thanks alot for providing it and making the commit. I'll pull out my POSIX version of the correction [1] once 1.9.0 is out and my specs are updated. I'll keep an eye out for other places as well (surely there are many.) [1] http://scm.europalab.com/opkg/rev/a2c6460cfb16 Regards, Michael ___ Devel mailing list Devel@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
[OpenSIPS-Devel] SF.net SVN: opensips:[9676] trunk/modules/cachedb_sql/
Revision: 9676 http://opensips.svn.sourceforge.net/opensips/?rev=9676&view=rev Author: osas Date: 2013-01-28 16:38:49 + (Mon, 28 Jan 2013) Log Message: --- cachedb_sql: set svn:ignore Property Changed: trunk/modules/cachedb_sql/ This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site. ___ Devel mailing list Devel@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
[OpenSIPS-Devel] [ opensips-Patches-3602413 ] b2b - initial headers support
Patches item #3602413, was opened at 2013-01-28 08:36 Message generated for change (Tracker Item Submitted) made by nikbyte You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=1086412&aid=3602413&group_id=232389 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: modules Group: trunk Status: Open Resolution: None Priority: 5 Private: No Submitted By: Nick Altmann (nikbyte) Assigned to: Nobody/Anonymous (nobody) Summary: b2b - initial headers support Initial Comment: Adds two parameters: initial_headers (str): A list of SIP header names delimited by ';' that should be copied from the dialog of one side to the other side with another names taking from applying "initial_headers_regexp" regexp on original names. Also you may use "magic" header "X-Original-SRC", containing source uri of initial packet. and initial_headers_regexp(str): Regexp applied to headers from initial_headers parameter. Also it removes old init_callid_hdr parameter. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=1086412&aid=3602413&group_id=232389 ___ Devel mailing list Devel@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
[OpenSIPS-Devel] SF.net SVN: opensips:[9675] trunk/Makefile.conf
Revision: 9675 http://opensips.svn.sourceforge.net/opensips/?rev=9675&view=rev Author: osas Date: 2013-01-28 16:35:11 + (Mon, 28 Jan 2013) Log Message: --- cachedb_mongodb: added to the list of excluded modules Modified Paths: -- trunk/Makefile.conf This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site. ___ Devel mailing list Devel@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
[OpenSIPS-Devel] SF.net SVN: opensips:[9674] trunk/modules/cachedb_mongodb/
Revision: 9674 http://opensips.svn.sourceforge.net/opensips/?rev=9674&view=rev Author: osas Date: 2013-01-28 16:31:33 + (Mon, 28 Jan 2013) Log Message: --- cachedb_mongodb: set svn:ignore Property Changed: trunk/modules/cachedb_mongodb/ This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site. ___ Devel mailing list Devel@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
[OpenSIPS-Devel] [ opensips-Bugs-3576351 ] sip_trace module bug
Bugs item #3576351, was opened at 2012-10-11 07:53 Message generated for change (Comment added) made by bogdan_iancu You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=3576351&group_id=232389 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: modules Group: 1.8.x >Status: Closed >Resolution: Invalid Priority: 5 Private: No Submitted By: Dragos Oancea (dragosoancea) Assigned to: Bogdan-Andrei Iancu (bogdan_iancu) Summary: sip_trace module bug Initial Comment: Hi The siptrace module reports a wrong value in the `fromip` field of the sip_trace table. For example , for this INVITE, coming from tls:80.187.x.x:62510 , I would expect the value "tls:80.187.x.x:62510" to be added in the `fromip` field, but it's adding "tls:80.187.x.x:625" instead . It's missing two digits from the port value. Also , sometimes it would put its local port (in my case 5061) instead of the remote port in the `fromip` or `toip` fields. INVITE sips:+49170738x...@sip.domain.com SIP/2.0 Call-Id: c64e6615c79ab23501ad13f2e1a58918@10.77.26.75 CSeq: 1 INVITE Via: SIP/2.0/TLS 10.77.26.75:59076;branch=z9hG4bK127109c14cd3b59c9ef9909b737982ab Max-Forwards: 70 From: "+491713x" ;tag=yRkyOWfbq To: Contact: Allow: ACK,BYE User-Agent: SomeUserAgent Content-Type: application/sdp Content-Length: 138 v=0 o=- 1349965870484 1349965870484 IN IP4 10.77.26.75 s=- c=IN IP4 10.77.26.75 t=0 0 m=audio 37566 RTP/AVP 0 a=rtpmap:0 PCMU/8000 The problem was observed with opensips 1.8.1-tls and opensips-1.7.2-tls . Cheers, Dragos -- >Comment By: Bogdan-Andrei Iancu (bogdan_iancu) Date: 2013-01-28 06:57 Message: The debugging did not reveal anything...If this problem pops up again, please open a new ticket ! Regards, Bogdan -- Comment By: Dragos Oancea (dragosoancea) Date: 2012-11-06 05:40 Message: will do. but funny thing , I did not see the problem again in the last week... I'm running the absolutely same opensips binary and config as when it happened. Regards, Dragos -- Comment By: Razvan Crainea (razvancrainea) Date: 2012-10-31 08:26 Message: Hi! I've attached a patch that disables the Prepared Statements. Please apply it and check if you still find any bogus fields in your db. Regards, Răzvan -- Comment By: David Sanders (dmsanders) Date: 2012-10-22 08:52 Message: I believe it occurs for both requests and replies for me as well. - David -- Comment By: Dragos Oancea (dragosoancea) Date: 2012-10-22 08:17 Message: I see the error for `fromip` , direction `in` for both requests and replies. 22 characters. I never saw a space in that field, but maybe my IPs are longer. Cheers, Dragos -- Comment By: Bogdan-Andrei Iancu (bogdan_iancu) Date: 2012-10-20 01:00 Message: What about the type of SIP requests - do you see the err for requests or for replies (or both ?) ? Regards, Bogdan -- Comment By: David Sanders (dmsanders) Date: 2012-10-19 16:24 Message: I only see it occurring on direction = 'in'. In addition, it only affects the fromip field. It seems to be truncated to 22 characters. If there is a space in the port number it is only if the fromip was less than 22 characters. For example "udp:xx.xxx.x.xx:5060 1" is a pattern I see a lot. 1 seems to be the most common extra character, but I also see 0, 4, 7, 9, etc. -- Comment By: Bogdan-Andrei Iancu (bogdan_iancu) Date: 2012-10-19 09:08 Message: Ok, last question - have you noticed a pattern on what kind of records have bogus port values ? like request, in or out, ? or maybe for replies ? It will help me to dig into the right code. Regards, Bogdan -- Comment By: David Sanders (dmsanders) Date: 2012-10-19 00:31 Message: I've also encountered this issue as described, with opensips 1.8.0-tls. In addition to the described case, I've seen times where the field will look like "sip:80.187.x.x:625 1", with a space present in the port number. This seems to suggest it isn't truncation. -- Comment By: Dragos Oancea (dragosoancea) Date: 2012-10-17 01:35 Message: Hi Bogdan, No , I am not using that feature. Regards, Dragos -- Comment By: Bogdan-Andrei Iancu (bogdan_iancu
[OpenSIPS-Devel] [ opensips-Bugs-3588141 ] 1.8.2 pua_dialoginfo regression
Bugs item #3588141, was opened at 2012-11-17 02:19 Message generated for change (Settings changed) made by bogdan_iancu You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=3588141&group_id=232389 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: modules Group: 1.8.x >Status: Closed >Resolution: Fixed Priority: 7 Private: No Submitted By: Damien Sandras (dsandras) Assigned to: Bogdan-Andrei Iancu (bogdan_iancu) Summary: 1.8.2 pua_dialoginfo regression Initial Comment: Release 1.8.2 with the various dialog patches probably breaks pua_dialog_info. When a call is terminated, OpenSIPS does not send a NOTIFY anymore, even though the presentity table looks correct (the dialog info event document corresponding to the call is correctly removed from the table). We had things working fine with 1.8.1 (except a few ghost dialogs which had been CANCELled), but in 1.8.2, our phones receive a NOTIFY to indicate early/established state, but not terminated state. -- Comment By: https://www.google.com/accounts () Date: 2012-11-22 07:05 Message: BYE (but it could be any other message corresponding to the dialog end) I'm using dialoginfo_set("B"); and dialoginfo_set("A"); I sent you a mail with more details on the infrastructure. -- Comment By: Bogdan-Andrei Iancu (bogdan_iancu) Date: 2012-11-22 06:56 Message: Hi Damien, Trying to reproduce here - the "terminated" state is done via BYE, MI or Expire ? Regards, Bogdan -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=3588141&group_id=232389 ___ Devel mailing list Devel@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
[OpenSIPS-Devel] SF.net SVN: opensips:[9673] branches/1.8/modules/presence/presentity.c
Revision: 9673 http://opensips.svn.sourceforge.net/opensips/?rev=9673&view=rev Author: bogdan_iancu Date: 2013-01-28 14:55:51 + (Mon, 28 Jan 2013) Log Message: --- backport from trunk (rev 9671): - fixed who the NOTIFYs are built when triggered by a PUBLISH with expire 0; This is actually a revert of commit 9351, which seems to have some side-effects. Thanks to Damien Sandras for helping with the the debugging. Closes bug #3588141 Revision Links: -- http://opensips.svn.sourceforge.net/opensips/?rev=9671&view=rev Modified Paths: -- branches/1.8/modules/presence/presentity.c This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site. ___ Devel mailing list Devel@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
[OpenSIPS-Devel] SF.net SVN: opensips:[9672] branches/1.7/modules/presence/presentity.c
Revision: 9672 http://opensips.svn.sourceforge.net/opensips/?rev=9672&view=rev Author: bogdan_iancu Date: 2013-01-28 14:55:43 + (Mon, 28 Jan 2013) Log Message: --- backport from trunk (rev 9671): - fixed who the NOTIFYs are built when triggered by a PUBLISH with expire 0; This is actually a revert of commit 9351, which seems to have some side-effects. Thanks to Damien Sandras for helping with the the debugging. Closes bug #3588141 Revision Links: -- http://opensips.svn.sourceforge.net/opensips/?rev=9671&view=rev Modified Paths: -- branches/1.7/modules/presence/presentity.c This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site. ___ Devel mailing list Devel@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
[OpenSIPS-Devel] SF.net SVN: opensips:[9671] trunk/modules/presence/presentity.c
Revision: 9671 http://opensips.svn.sourceforge.net/opensips/?rev=9671&view=rev Author: bogdan_iancu Date: 2013-01-28 14:54:12 + (Mon, 28 Jan 2013) Log Message: --- - fixed who the NOTIFYs are built when triggered by a PUBLISH with expire 0; This is actually a revert of commit 9351, which seems to have some side-effects. Thanks to Damien Sandras for helping with the the debugging. Closes bug #3588141 Modified Paths: -- trunk/modules/presence/presentity.c This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site. ___ Devel mailing list Devel@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
[OpenSIPS-Devel] SF.net SVN: opensips:[9670] trunk/modules/acc
Revision: 9670 http://opensips.svn.sourceforge.net/opensips/?rev=9670&view=rev Author: razvancrainea Date: 2013-01-28 14:45:48 + (Mon, 28 Jan 2013) Log Message: --- Added a new accounting method to the acc module that triggers events for each accounting message generated (CDR or normal accounting) Modified Paths: -- trunk/modules/acc/README trunk/modules/acc/acc.c trunk/modules/acc/acc.h trunk/modules/acc/acc_logic.c trunk/modules/acc/acc_logic.h trunk/modules/acc/acc_mod.c trunk/modules/acc/acc_mod.h trunk/modules/acc/doc/acc_admin.xml This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site. ___ Devel mailing list Devel@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
[OpenSIPS-Devel] SF.net SVN: opensips:[9669] trunk/modules/dialog/dlg_timer.c
Revision: 9669 http://opensips.svn.sourceforge.net/opensips/?rev=9669&view=rev Author: vladut-paiu Date: 2013-01-28 14:45:07 + (Mon, 28 Jan 2013) Log Message: --- for dialog pings, do not try to open a new TCP connection Modified Paths: -- trunk/modules/dialog/dlg_timer.c This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site. ___ Devel mailing list Devel@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
[OpenSIPS-Devel] SF.net SVN: opensips:[9668] trunk
Revision: 9668 http://opensips.svn.sourceforge.net/opensips/?rev=9668&view=rev Author: razvancrainea Date: 2013-01-28 14:35:50 + (Mon, 28 Jan 2013) Log Message: --- Allow modules to manage events parameters lists by themselves Modified Paths: -- trunk/evi/event_interface.c trunk/evi/evi_params.c trunk/evi/evi_params.h trunk/route.c This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site. ___ Devel mailing list Devel@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
[OpenSIPS-Devel] SF.net SVN: opensips:[9667] trunk/modules/drouting
Revision: 9667 http://opensips.svn.sourceforge.net/opensips/?rev=9667&view=rev Author: vladut-paiu Date: 2013-01-28 14:27:08 + (Mon, 28 Jan 2013) Log Message: --- added a new param, gw_priprefix_avp, for pushing the selected destination's pri prefix to script Modified Paths: -- trunk/modules/drouting/README trunk/modules/drouting/doc/drouting_admin.xml trunk/modules/drouting/drouting.c This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site. ___ Devel mailing list Devel@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
Re: [OpenSIPS-Devel] Improved socket error messages
Hi Michael, See an improved version of your patch here on commit #9666 : http://opensips.svn.sourceforge.net/opensips/?rev=9666&view=rev If you consider adding that extra info in other places, please provide a patch. Thanks and regards, Bogdan-Andrei Iancu OpenSIPS Founder and Developer http://www.opensips-solutions.com On 01/27/2013 09:17 PM, Michael Schloh von Bennewitz wrote: Hello developers, While trying to debug a difficult to find problem (where ntop, tcpdump, and snoop were no help) I finally figured out where OpenSIPS was trying to send misdirected messages by hacking the sources. It might be useful to always accompany log text with network stack information. So instead of: Jan 02 18:18:02 hostname opensips[1234]: ERROR:core:tcp_blocking_connect: failed to retrieve SO_ERROR (146) Connection refused ...we would see: Jan 02 18:18:02 hostname opensips[1234]: ERROR:core:tcp_blocking_connect: addr (1.2.3.4) port (98765), failed to retrieve SO_ERROR (146) Connection refused ...which of course is much more useful. To integrate the improvement above, I hacked tcp_main.c like this: $ sed -e 's;\(LM_ERR("\)\(failed to retrieve SO_ERROR (%d) %s\\n",\);\1addr (%s) port (%d), \2 inet_ntoa(((struct sockaddr_in *)servaddr)->sin_addr), ntohs(((struct sockaddr_in *)servaddr)->sin_port),;' tcp_main.c ...or if you prefer here's a unified diff that does the same thing: diff -Nau tcp_main.c.orig tcp_main.c --- tcp_main.c.orig 2012-10-17 00:09:05.0 +0200 +++ tcp_main.c 2013-01-27 16:44:47.803235857 +0100 @@ -340,7 +340,7 @@ getsockopt(fd, SOL_SOCKET, SO_ERROR,&err,&err_len); if ((err==0)&& (poll_err==0)) goto end; if (err!=EINPROGRESS&& err!=EALREADY){ - LM_ERR("failed to retrieve SO_ERROR (%d) %s\n", err, + LM_ERR("addr (%s) port (%d), failed to retrieve SO_ERROR (%d) %s\n", inet_ntoa(((struct sockaddr_in *)servaddr)->sin_addr), ntohs(((struct sockaddr_in *)servaddr)->sin_port), err, strerror(err)); goto error; } This hack applies cleanly to OpenSIPS 1.7.2 and 1.8.2 although I've tested only on 1.7.2 (because of the database access bugs in 1.8.*.) Unfortunately there are other socket related operations which write unhelpful log text, so this is not a complete solution. Regards, Michael ___ Devel mailing list Devel@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/devel ___ Devel mailing list Devel@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
[OpenSIPS-Devel] SF.net SVN: opensips:[9666] trunk/tcp_main.c
Revision: 9666 http://opensips.svn.sourceforge.net/opensips/?rev=9666&view=rev Author: bogdan_iancu Date: 2013-01-28 14:20:51 + (Mon, 28 Jan 2013) Log Message: --- - added more info on TCP connect failures based on a patch/idea of Michael Schloh von Bennewitz Modified Paths: -- trunk/tcp_main.c This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site. ___ Devel mailing list Devel@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
[OpenSIPS-Devel] [ opensips-Bugs-3592878 ] Meedia keep alive with rtpproxy
Bugs item #3592878, was opened at 2012-12-05 11:14 Message generated for change (Comment added) made by bogdan_iancu You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=3592878&group_id=232389 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: modules Group: 1.8.x Status: Open Resolution: None Priority: 7 Private: No Submitted By: Carlos Eduardo Wagner (kaduww) Assigned to: Razvan Crainea (razvancrainea) Summary: Meedia keep alive with rtpproxy Initial Comment: While using the Meedia keep alive mothod with RTP Proxy, we've noticed that there should be some error with the OpenSIPS and RTP Proxy communication. Due this error, when the RTP traffic stops and the the RTP Proxy send a signal to the SIP Proxy to kill the dialog this error appear on he log and the Media Keep Alive does not work: Dec 5 11:27:33 HOST /sbin/opensips[19666]: ERROR:rtpproxy:timeout_listener_process: Wrong formated message received from rtpproxy - invalid dialog entry [74#0123645] Dec 5 11:27:33 HOST /sbin/opensips[19666]: ERROR:rtpproxy:timeout_listener_process: Wrong formated message received from rtpproxy - invalid dialog entry [1763555126#0123083] Dec 5 11:28:12 HOST /sbin/opensips[19666]: ERROR:rtpproxy:timeout_listener_process: Wrong formated message received from rtpproxy - invalid dialog entry [52365#0123359] Maybe the problem is the # on the dialog string, but its not and common erros, it not happens every time. -- >Comment By: Bogdan-Andrei Iancu (bogdan_iancu) Date: 2013-01-28 06:03 Message: Carlos, any input here ? -- Comment By: Razvan Crainea (razvancrainea) Date: 2013-01-22 03:59 Message: Hi, Carlos! Can you specify the exact version of RTPProxy and OpenSIPS you are using? Best regards, Răzvan -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=3592878&group_id=232389 ___ Devel mailing list Devel@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
[OpenSIPS-Devel] [ opensips-Bugs-3599495 ] SIP Parallel forking and RTPProxy limitation
Bugs item #3599495, was opened at 2013-01-04 08:20 Message generated for change (Comment added) made by bogdan_iancu You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=3599495&group_id=232389 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: modules Group: 1.8.x Status: Open >Resolution: Remind >Priority: 4 Private: No Submitted By: Pierre-Yves (pym67) >Assigned to: Bogdan-Andrei Iancu (bogdan_iancu) Summary: SIP Parallel forking and RTPProxy limitation Initial Comment: Hello, I have found a limitation using opensips and rtpproxy with Parallel forking. Version: opensips (v1.8.2) + rtpproxy. Opensips is used as a SIP proxy (+ NAT traversal). Another component is handling the service logic (Application Server) The call scenario is the following: - 2 UAC are registered using the same identity (using the same opensips SIP Proxy). Those 2 UAC are behind NAT - Incoming call with parallel forking (to those 2 UAC) [forking is not handled on opensips itself] - 2 dialogs are well created (one for each fork) - Upon the first UAC has sent his 200OK, the other fork call is CANCELED. The problem is : - both calls ( fork.0 and fork.1) have the same FromTag, Call-ID). - on each INVITE, rtpproxy provide the same media port for both calls fork . [RTPProxy consider both INVITE as being part of the same call] - on CANCEL on fork.1, unforce_rtpproxy() is closing the call (and as there is only 1 "media" call ), no media can be established on fork.0 In my opinion, there is here a limitation of rtpproxy & rtpproxy module that handle calls based only on From Tag, Call-ID, To Tag information which is not enough in case of forking. Might it be possible to enhance the rtpproxy module in order to provide to "rtpproxy" a dialog ID/hash instead of the real Call-ID of the Call ? (trough a modparam to enable/disable this behavior). Do you think that this could be implemented ? -- >Comment By: Bogdan-Andrei Iancu (bogdan_iancu) Date: 2013-01-28 05:40 Message: Hi Pierre-Yves, This scenario is not supported by RTPproxy itself - as it use as key for the sessions the callid+from_tag+to_tag which are the same for all branches. We will do a brain storming to see how something like this can be solved, but I would say solutions are not handy. I would rather suggest you to move the rtpp stuff before the parallel forking point, if possible. Regards, Bogdan -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=3599495&group_id=232389 ___ Devel mailing list Devel@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
[OpenSIPS-Devel] [ opensips-Patches-3565679 ] [acc] Failure Route Changes
Patches item #3565679, was opened at 2012-09-07 16:39 Message generated for change (Comment added) made by bogdan_iancu You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=1086412&aid=3565679&group_id=232389 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: modules Group: 1.8.x Status: Open >Resolution: Invalid Priority: 5 Private: No Submitted By: David Sanders (dmsanders) Assigned to: Bogdan-Andrei Iancu (bogdan_iancu) Summary: [acc] Failure Route Changes Initial Comment: At the moment the ACC module will log a failed call after any set onreply_route, but before a failure_route. The attached patch is a simple change to the TM callback registered for by on_missed so that the callback fires after the failure_route, allowing any changes made in the failure_route to show up in the logged call. Patch has been tested and worked as expected, however, I'm not positive that I haven't overlooked some other side-effect of the change. -- >Comment By: Bogdan-Andrei Iancu (bogdan_iancu) Date: 2013-01-28 05:36 Message: Hi David, There is something weird in the patch : 1) you changed from TMCB_ON_FAILURE to TMCB_ON_FAILURE_RO only in the callback function, but not where callback is registered too. 2) the TMCB_ON_FAILURE_RO callback is obsoleted in TM and never trigger .. Are you sure you attached the right patch ? Regards, Bogdan -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=1086412&aid=3565679&group_id=232389 ___ Devel mailing list Devel@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
[OpenSIPS-Devel] SF.net SVN: opensips:[9665] trunk/modules/cachedb_mongodb/
Revision: 9665 http://opensips.svn.sourceforge.net/opensips/?rev=9665&view=rev Author: vladut-paiu Date: 2013-01-28 13:16:58 + (Mon, 28 Jan 2013) Log Message: --- added svn:ignore property Property Changed: trunk/modules/cachedb_mongodb/ This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site. ___ Devel mailing list Devel@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
[OpenSIPS-Devel] SF.net SVN: opensips:[9664] trunk/modules
Revision: 9664 http://opensips.svn.sourceforge.net/opensips/?rev=9664&view=rev Author: bogdan_iancu Date: 2013-01-28 12:47:02 + (Mon, 28 Jan 2013) Log Message: --- - added full support for changes in B2B : changes done in script before triggering b2b are now propagated inside B2B; changes done in the b2b request / reply routes are also stored and used. Credits go to Nick Altmann Closes patch #3519778 Modified Paths: -- trunk/modules/b2b_entities/b2b_entities.c trunk/modules/b2b_entities/b2b_entities.h trunk/modules/b2b_entities/dlg.c trunk/modules/b2b_entities/dlg.h trunk/modules/b2b_logic/b2b_logic.c trunk/modules/b2b_logic/logic.c trunk/modules/b2b_logic/records.c This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site. ___ Devel mailing list Devel@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
[OpenSIPS-Devel] [ opensips-Patches-3519778 ] B2B_LOGIC: completely lumps support
Patches item #3519778, was opened at 2012-04-20 03:03 Message generated for change (Settings changed) made by bogdan_iancu You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=1086412&aid=3519778&group_id=232389 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: modules Group: trunk >Status: Closed >Resolution: Accepted Priority: 5 Private: No Submitted By: Nick Altmann (nikbyte) Assigned to: Bogdan-Andrei Iancu (bogdan_iancu) Summary: B2B_LOGIC: completely lumps support Initial Comment: Now you can change all parts of message before b2b_init_request call and in b2b_request/b2b_reply routes. It useful for add additional headers before b2b_init_request to pass through b2b (don't forget custom_headers param) and also for NAT processing in b2b_request/b2b_reply routes. Instead of patch #3515749. Please, ignore/remove old patch. -- Comment By: Nick Altmann (nikbyte) Date: 2012-10-18 11:45 Message: The way we use this patch in our production environment to process NAT via b2b: route { force_rport(); # Here are some checks, deny non-invite requests. # Fix NATed contact and SDP in client requests if (nat_uac_test("19")) fix_nated_contact(); if ( (has_body("application/sdp")) && (nat_uac_test("8")) ) fix_nated_sdp("10"); b2b_init_request("top hiding"); exit; } route[B2B_REQUEST] { force_rport(); # Fix NATed contact and SDP in client requests if (nat_uac_test("19")) fix_nated_contact(); if ( (has_body("application/sdp")) && (nat_uac_test("8")) ) fix_nated_sdp("10"); # Also we can add this our custom headers } route[B2B_REPLY] { # Here we can also add our custom headers } onreply_route { # Fix NATed contact and SDP in client replies if (nat_uac_test("97")) fix_nated_contact(); if ( (has_body("application/sdp")) && (nat_uac_test("8")) ) fix_nated_sdp("10"); } -- Comment By: Nick Altmann (nikbyte) Date: 2012-10-18 04:00 Message: Added v4 patch. Fixed: - b2b_request_route called before tm transaction created. Now we can use force_rport() and change contact header in b2b_request_route. We use it to process NAT on b2b. -- Comment By: Nick Altmann (nikbyte) Date: 2012-09-10 03:09 Message: Added actual v3 patch. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=1086412&aid=3519778&group_id=232389 ___ Devel mailing list Devel@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
[OpenSIPS-Devel] [NEW] MongoDB Database Driver
Hello, A new *CACHEDB_MONGODB* module has been added to OpenSIPS trunk, and it will also be present in the future 1.9 release. The module implements the Key-Value Interface [1] to allow the script writer and also the module writer to connect and do Key-Value type operations ( store,fetch,remove,counter_add,counter_sub ) on a MongoDB database. The module supports both connection to a single MongoDB instance ( true single instance or mongos ) or to a MongoDB Replica Set. Also, the CacheDB interface was enhanced in order to support RAW queries ( [2] ). Due to the Key-Value nature of the CacheDB interface, the developer could not take full advantage of the capabilities of the NoSQL back-end. The raw queries should compensate that gap, allowing to run raw queries in a back-end dependent language. The CACHEDB_MONGODB module implements the newly added RAW query from the interface, thus you can run whatever query that the MongoDB back-end supports, taking full advatange of it. The query syntax is a JSON-based one, very similar to the one that one would use to run commands in the mongo CLI. The query results are also returned as JSON documents, that one can further process in the OpenSIPS script by using the JSON module. For the full description of the raw query capabilities, see the 'Raw Query Syntax' section ( [3] ) in the module documentation. For a full documentation of the module and usage examples, visit [4] . Testing and feedback is very much welcome. [1] http://www.opensips.org/Resources/DocsTutKvinterface [2] http://www.opensips.org/Resources/DocsCoreFcn#toc116 [3] http://www.opensips.org/html/docs/modules/devel/cachedb_mongodb.html#id249157 [4] http://www.opensips.org/html/docs/modules/devel/cachedb_mongodb.html Best Regards, -- Vlad Paiu OpenSIPS Developer http://www.opensips-solutions.com ___ Devel mailing list Devel@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
[OpenSIPS-Devel] SF.net SVN: opensips:[9663] trunk/cachedb
Revision: 9663 http://opensips.svn.sourceforge.net/opensips/?rev=9663&view=rev Author: vladut-paiu Date: 2013-01-28 12:05:32 + (Mon, 28 Jan 2013) Log Message: --- added the RAW query capability check if the module supports the raw query capability before calling raw query func Modified Paths: -- trunk/cachedb/cachedb.c trunk/cachedb/cachedb_cap.h This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site. ___ Devel mailing list Devel@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
[OpenSIPS-Devel] SF.net SVN: opensips:[9662] trunk
Revision: 9662 http://opensips.svn.sourceforge.net/opensips/?rev=9662&view=rev Author: vladut-paiu Date: 2013-01-28 11:33:36 + (Mon, 28 Jan 2013) Log Message: --- Added a MongoDB driver Added support for Raw Queries in the CacheDB interface Implemented the Raw Query support in MongoDB Modified Paths: -- trunk/Makefile.conf trunk/action.c trunk/cachedb/cachedb.c trunk/cachedb/cachedb.h trunk/cfg.lex trunk/cfg.y trunk/route.c trunk/route_struct.h Added Paths: --- trunk/modules/cachedb_mongodb/ trunk/modules/cachedb_mongodb/Makefile trunk/modules/cachedb_mongodb/README trunk/modules/cachedb_mongodb/cachedb_mongodb.c trunk/modules/cachedb_mongodb/cachedb_mongodb_dbase.c trunk/modules/cachedb_mongodb/cachedb_mongodb_dbase.h trunk/modules/cachedb_mongodb/cachedb_mongodb_json.c trunk/modules/cachedb_mongodb/cachedb_mongodb_json.h trunk/modules/cachedb_mongodb/doc/ trunk/modules/cachedb_mongodb/doc/cachedb_mongodb.xml trunk/modules/cachedb_mongodb/doc/cachedb_mongodb_admin.xml This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site. ___ Devel mailing list Devel@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
Re: [OpenSIPS-Devel] Improved socket error messages
On Jan 28, 2013, at 12:10 PM, Bogdan-Andrei Iancu wrote: > Hi, > > Saul, should I fix and upload Michael's patch (to be part of 1.9) or you want > to provide a larger patch (to covert this too, still for 1.9) ? > You may fix and upload that one, since I won't have time to do it this week. It would be nice to have a generic function/macro which would print the given error string + IP (port) + error description with the given error severity , for example :-) Then we can use it in more places later on. Regards, -- Saúl Ibarra Corretgé AG Projects ___ Devel mailing list Devel@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
Re: [OpenSIPS-Devel] Improved socket error messages
Hi, Saul, should I fix and upload Michael's patch (to be part of 1.9) or you want to provide a larger patch (to covert this too, still for 1.9) ? Thanks and regards, Bogdan-Andrei Iancu OpenSIPS Founder and Developer http://www.opensips-solutions.com On 01/28/2013 10:50 AM, Saúl Ibarra Corretgé wrote: Hi, On Jan 27, 2013, at 8:17 PM, Michael Schloh von Bennewitz wrote: Hello developers, While trying to debug a difficult to find problem (where ntop, tcpdump, and snoop were no help) I finally figured out where OpenSIPS was trying to send misdirected messages by hacking the sources. It might be useful to always accompany log text with network stack information. So instead of: Jan 02 18:18:02 hostname opensips[1234]: ERROR:core:tcp_blocking_connect: failed to retrieve SO_ERROR (146) Connection refused ...we would see: Jan 02 18:18:02 hostname opensips[1234]: ERROR:core:tcp_blocking_connect: addr (1.2.3.4) port (98765), failed to retrieve SO_ERROR (146) Connection refused ...which of course is much more useful. To integrate the improvement above, I hacked tcp_main.c like this: $ sed -e 's;\(LM_ERR("\)\(failed to retrieve SO_ERROR (%d) %s\\n",\);\1addr (%s) port (%d), \2 inet_ntoa(((struct sockaddr_in *)servaddr)->sin_addr), ntohs(((struct sockaddr_in *)servaddr)->sin_port),;' tcp_main.c ...or if you prefer here's a unified diff that does the same thing: diff -Nau tcp_main.c.orig tcp_main.c --- tcp_main.c.orig 2012-10-17 00:09:05.0 +0200 +++ tcp_main.c 2013-01-27 16:44:47.803235857 +0100 @@ -340,7 +340,7 @@ getsockopt(fd, SOL_SOCKET, SO_ERROR,&err,&err_len); if ((err==0)&& (poll_err==0)) goto end; if (err!=EINPROGRESS&& err!=EALREADY){ - LM_ERR("failed to retrieve SO_ERROR (%d) %s\n", err, + LM_ERR("addr (%s) port (%d), failed to retrieve SO_ERROR (%d) %s\n", inet_ntoa(((struct sockaddr_in *)servaddr)->sin_addr), ntohs(((struct sockaddr_in *)servaddr)->sin_port), err, strerror(err)); goto error; } This hack applies cleanly to OpenSIPS 1.7.2 and 1.8.2 although I've tested only on 1.7.2 (because of the database access bugs in 1.8.*.) Unfortunately there are other socket related operations which write unhelpful log text, so this is not a complete solution. Improved logging messages are of course great :-) I have a few unfinished patches in this regard as well, so if you send over partial improvements I'll incorporate them. However, the patch you sent is not correct because it doesn't deal with IPv6 addresses, you need to check the sa_family field of the sockaddr struct before casting it to sockaddr_in or sockaddr_in6. Regards, -- Saúl Ibarra Corretgé AG Projects ___ Devel mailing list Devel@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/devel ___ Devel mailing list Devel@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
[OpenSIPS-Devel] [ opensips-Bugs-3585696 ] mi_xmlrpc does not support latest versions of libxmlrpc-c3
Bugs item #3585696, was opened at 2012-11-09 03:39 Message generated for change (Settings changed) made by bogdan_iancu You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=3585696&group_id=232389 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: modules Group: None Status: Open Resolution: None >Priority: 3 Private: No Submitted By: Digipigeon (digipigeon) >Assigned to: Razvan Crainea (razvancrainea) Summary: mi_xmlrpc does not support latest versions of libxmlrpc-c3 Initial Comment: I am getting repeated crashing on my three X 1.8.2 opensips servers, also some crashing on my 1.7.1. The problem appears to be more noticeable when the profile_get_values is called frequently (every few seconds), however I cant confirm isolation of this command causes the crash. Please see attached (gdb) bt full -- Comment By: Bogdan-Andrei Iancu (bogdan_iancu) Date: 2012-12-17 11:34 Message: As an update here, for everyone. The problem seems to be generated by the newest versions of libxmlrpc-c3 library (over 1.06.42) - just vesrion do not properly work against opensips, because the threads usage -> this leads the memory corruption in opensips. We will need to rework the mi_xmlrpc module to support also the new versions, or at least not to compile / link against them. Regards, Bogdan -- Comment By: Digipigeon (digipigeon) Date: 2012-11-09 13:52 Message: Hi Bogdan, The results of your requested commands is as follows: (gdb) f 1 #1 add_mi_node_child (value_len=26, value=, name_len=, name=, flags=2, parent=) at mi/tree.c:219 219 return add_next(parent->kids, name, name_len, value, value_len, flags); (gdb) p parent $1 = (gdb) p *parent value has been optimised out (gdb) f 4 #4 mi_get_stats (cmd=, param=) at statistics.c:535 535 if (mi_add_module_stats( rpl, &collector->amodules[i] )!=0) (gdb) p *rpl $2 = {value = {s = 0x2 , len = 0}, name = {s = 0x0, len = -840856056}, flags = 0, kids = 0x7663723a65726f63, next = 0x7365696c7065725f, last = 0x3730393134203d20, attributes = 0x33} The dump is 2.1GB, I will get this somewhere you can access it. Kind Regards Jonathan -- Comment By: Bogdan-Andrei Iancu (bogdan_iancu) Date: 2012-11-09 13:34 Message: Ok, it seems the "brother" pointer is overwritten - the pointer is not a valid mem addrs, but decoded as hexa is "core:rcv" which is a statistic name. Please try more: f 1 p parent p *parent f 4 p *rpl Also is there any why to get access to the core to speed up the debugging ? Regards, -- Comment By: Digipigeon (digipigeon) Date: 2012-11-09 13:12 Message: Hi Bogdan, Thanks for the explanation. Please see the following output: (gdb) f 0 #0 add_next (flags=2, value_len=26, value=, name_len=, name=, brother=0x7663723a65726f63) at mi/tree.c:184 184 brother->last->next = new; (gdb) p brother $1 = (struct mi_node *) 0x7663723a65726f63 (gdb) p *brother Cannot access memory at address 0x7663723a65726f63 (gdb) p name $2 = (gdb) p value $3 = (gdb) p *brother->name Structure has no component named operator*. Kind Regards Jonathan. -- Comment By: Bogdan-Andrei Iancu (bogdan_iancu) Date: 2012-11-09 12:42 Message: Jonathan, Once you are in gdb, run the commands: f 0 p brother p *brother p name p value p *brother->name Regards, Bogdan -- Comment By: Digipigeon (digipigeon) Date: 2012-11-09 11:40 Message: Hi Bogdan, There was nothing in the log files relevant, it just crashes without any response. I am not sure if I have correctly ran the commands, but I get the following: (gdb) f 0 brother #0 0x7663723a65726f63 in ?? () (gdb) f 0 *brother Cannot access memory at address 0x7663723a65726f63 (gdb) f 0 name value has been optimised out (gdb) f 0 value value has been optimised out (gdb) f 0 *brother->next Cannot access memory at address 0x7663723a65726f93 Sorry if this is not correct. Kind Regards Jonathan -- Comment By: Bogdan-Andrei Iancu (bogdan_iancu) Date: 2012-11-09 09:32 Message: Hi, 1) do you see in the logs any err message before the crash (from the same process) ? 2) in gdb, frame 0, please print : brother, *brother, name, value, *brother->next . Thanks and regards, Bogdan -- Comment By: Digipigeon (digipigeon) Date: 2012-11-09 07:09 Message: The only parameter that I h
[OpenSIPS-Devel] [ opensips-Patches-3545138 ] [tm] fix a race condition cancelling a processed invite
Patches item #3545138, was opened at 2012-07-17 10:23 Message generated for change (Settings changed) made by bogdan_iancu You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=1086412&aid=3545138&group_id=232389 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: modules Group: trunk >Status: Closed Resolution: Fixed Priority: 8 Private: No Submitted By: Christophe Sollet (csollet) Assigned to: Bogdan-Andrei Iancu (bogdan_iancu) Summary: [tm] fix a race condition cancelling a processed invite Initial Comment: Hi, I'm facing a race condition when a CANCEL is received when cancelled INVITE is not yet completely processed: * When t_forward_nonack() start, transaction is still not cancelled. * When cancel_invite() process transaction, not all branches are created yet. Result : cancel_invite() process correctly created branches but not ones created later. This is ending with never cancelled branches. Attached patch flag branch to be cancelled on reply just after sending it. It's more a safeguard : it's may be better, in addition, to not send branch at all if detected before sending. Regards, Christophe. -- Comment By: Bogdan-Andrei Iancu (bogdan_iancu) Date: 2013-01-22 07:24 Message: Hi Christophe, I uploaded your fix on SVN, but changed - your patch was still not covering some races between CANCEL being sent out by the CANCEL req proc and by and INVITE reply proc (as a result of a flag) -> you were ending up with 2 CANCELs :). So, I actually expended the cancelling condition when a reply is received. See #9618 - http://opensips.svn.sourceforge.net/opensips/?rev=9616&view=rev I would love if you could validate the fix. Thanks and regards, Bogdan -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=1086412&aid=3545138&group_id=232389 ___ Devel mailing list Devel@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
[OpenSIPS-Devel] [ opensips-Bugs-3585606 ] TCP Deadlock
Bugs item #3585606, was opened at 2012-11-08 20:47 Message generated for change (Comment added) made by bogdan_iancu You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=3585606&group_id=232389 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: core Group: 1.8.x >Status: Closed Resolution: Fixed Priority: 9 Private: No Submitted By: David Sanders (dmsanders) Assigned to: Bogdan-Andrei Iancu (bogdan_iancu) Summary: TCP Deadlock Initial Comment: There is a serious deadlock issue when using TCP with OpenSIPS (1.8.0-tls). I found this paper which has the same conclusion (but is discussing OpenSER circa 2008): http://www.cs.rice.edu/CS/Architecture/docs/ram-ispass08.pdf I'll quote the relevant part of Section 6: This can lead to deadlock in the following situation. When a worker process requests a connection from the supervisor process, it then blocks waiting to receive that file descriptor. If, at the same time, the supervisor process blocks waiting to send a new connection to the same worker (since the buffer at the receiver is full), the two processes will deadlock. Once the supervisor process deadlocks, no other worker can make progress either, as they will quickly need their own connections from the supervisor process. Similarly, no new connections will be accepted. This clearly illustrates that in an event-driven server, one must be careful to only read from sockets when the event mechanism says there is something to read and only write to sockets when the event mechanism says there is space to write. I can reliably reproduce this deadlock with any number of TCP children. Interestingly it seems to happen faster with a larger number of children. Under constant load, once the main TCP process deadlocks, all the children will as well. It seems to be rate related. Using SIPp to drive TCP traffic to an OpenSIPS server, 50 registers/second do not encounter the deadlock issue. However, if increase the traffic load a deadlock will occur within 30 seconds. My theory is that if the TCP children can't process a message and reply faster than they are coming in (in this case faster than 20ms) then the deadlock will occur. For completeness the GDB backtrace output of the deadlocked processes when running two TCP children are attached. -- >Comment By: Bogdan-Andrei Iancu (bogdan_iancu) Date: 2013-01-28 03:05 Message: Backport done -- Comment By: David Sanders (dmsanders) Date: 2013-01-24 11:53 Message: Hey Bogdan, I'll test out the patch ASAP and get back to you. Regarding the net.unix.max_dgram_qlen, I don't think it's possible to set from code, unfortunately. At least from what I've read about it. Really unfortunate in this case. - David -- Comment By: Bogdan-Andrei Iancu (bogdan_iancu) Date: 2013-01-24 10:11 Message: Hi David, I attached a patch that should solve the deadlock - it detects when TCP main is about to block on sending an accept/read command to the TCP workers and if so, will drop the TCP connmore or less there is nothing more you can do about. Please test and let me know if you still have the blocking. BTW, do you know a way to set net.unix.max_dgram_qlen from code , per socket ?? I haven't found anything :( Thanks and regards, Bogdan -- Comment By: Bogdan-Andrei Iancu (bogdan_iancu) Date: 2012-12-17 11:49 Message: Hi David, Spent some time in debugging this issue and got the conclusion that it is not an actual deadlock, but more an over-load - because all TCP worker process are busy, the main TCP proc is keep assigning task to them until the buffer the the socket used for sending tasks gets full and the write op blocks. As a fix, I see making that write non-blocking and if main TCP proc detects overloading of the the TCP workers to start dropping new connect events and connection with incoming traffic that cannot be assigned for processing. I will work more on this. Regards, Bogdan Regards, Bogdan -- Comment By: David Sanders (dmsanders) Date: 2012-12-03 15:33 Message: Until this can be fixed, I've found that it can be minimized by tweaking "net.unix.max_dgram_qlen" in sysctl. This defaults to 10, and I've seen the issue greatly reduced by increasing it to 100. -- Comment By: David Sanders (dmsanders) Date: 2012-11-23 22:21 Message: Hi Bogdan, Is there any news on this? Could you give some kind of prediction on when this could be fixed by? Before the end of the year, or not until 1.9 or? Any
[OpenSIPS-Devel] SF.net SVN: opensips:[9661] branches/1.7
Revision: 9661 http://opensips.svn.sourceforge.net/opensips/?rev=9661&view=rev Author: bogdan_iancu Date: 2013-01-28 11:05:08 + (Mon, 28 Jan 2013) Log Message: --- Backport from trunk (part of rev #9656) - fixed deadlock in the TCP stack between TCP main process and a TCP worked (under heavy load). Credits for reporting it go to David Sanders Closes bug #3585606 Revision Links: -- http://opensips.svn.sourceforge.net/opensips/?rev=9656&view=rev Modified Paths: -- branches/1.7/pass_fd.c branches/1.7/tcp_main.c This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site. ___ Devel mailing list Devel@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
[OpenSIPS-Devel] SF.net SVN: opensips:[9660] branches/1.8
Revision: 9660 http://opensips.svn.sourceforge.net/opensips/?rev=9660&view=rev Author: bogdan_iancu Date: 2013-01-28 11:04:41 + (Mon, 28 Jan 2013) Log Message: --- Backport from trunk (part of rev #9656) - fixed deadlock in the TCP stack between TCP main process and a TCP worked (under heavy load). Credits for reporting it go to David Sanders Closes bug #3585606 Revision Links: -- http://opensips.svn.sourceforge.net/opensips/?rev=9656&view=rev Modified Paths: -- branches/1.8/pass_fd.c branches/1.8/tcp_main.c This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site. ___ Devel mailing list Devel@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
[OpenSIPS-Devel] [ opensips-Bugs-3597398 ] memory leak when using $T_reply_code in onreply_route
Bugs item #3597398, was opened at 2012-12-18 23:45 Message generated for change (Comment added) made by bogdan_iancu You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=3597398&group_id=232389 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: modules Group: 1.8.x Status: Open >Resolution: Invalid Priority: 3 Private: No Submitted By: https://www.google.com/accounts () Assigned to: Bogdan-Andrei Iancu (bogdan_iancu) Summary: memory leak when using $T_reply_code in onreply_route Initial Comment: Memory leak when using $T_reply_code in base onreply_route ( not named onreply_route, so t_on_reply was not used) Opensips 1.8.2 from source tar. Reproduced consistently on both CentOS 5.8 and CentOS 6.3 pertinent part of script when memory leak: onreply_route { if ( $T_reply_code =~ "^18." ) $var(r_type) = "Ring"; else if ( $T_reply_code == "200" ) $var(r_type) = "Answer"; else $var(r_type) = "Other"; xlog("L_ERR","Reply $var(r_type) $T_reply_code rm $rm si $si cid'$ci'\n"); } Using $rs instead of $T_reply_code made it work. Also, naming the reply route and setting t_on_reply to it also solved the memory leak. onreply_route { if ( $rs == "100" ){ xlog("L_INFO", "Reply $rs rm $rm si $si cid '$ci'\n"); exit; } else if ( $rs =~ "18." ) $var(r_type) = "Ring"; else if ( $rs == "200" ) $var(r_type) = "Answer"; else $var(r_type) = "Other"; xlog("L_ERR","Reply type $var(r_type) $rs $rr rm $rm si $si via $(hdr(Via)[1]{via.host}) cid'$ci'\n"); #route(reply_logging); } -- >Comment By: Bogdan-Andrei Iancu (bogdan_iancu) Date: 2013-01-28 02:46 Message: Any updates here ? -- Comment By: Bogdan-Andrei Iancu (bogdan_iancu) Date: 2013-01-22 02:34 Message: Could you provide a memory dump or so ? I cannot reproduce this. -- Comment By: Bogdan-Andrei Iancu (bogdan_iancu) Date: 2012-12-19 00:28 Message: Hi, How the leak was observed ? was it pkg or shm memory ? do you have mem dumps to show the actual leak ? Regards, Bogdan -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=3597398&group_id=232389 ___ Devel mailing list Devel@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
[OpenSIPS-Devel] [ opensips-Patches-3601891 ] b2b - choose method how to generate To: header
Patches item #3601891, was opened at 2013-01-23 09:19 Message generated for change (Comment added) made by bogdan_iancu You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=1086412&aid=3601891&group_id=232389 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: modules Group: trunk >Status: Closed >Resolution: Accepted Priority: 5 Private: No Submitted By: Nick Altmann (nikbyte) >Assigned to: Bogdan-Andrei Iancu (bogdan_iancu) Summary: b2b - choose method how to generate To: header Initial Comment: Sometimes we need b2b to not overwrite To: header. In #3520528 i wrote solution Anca Vamanu without patch, but this solution don't work for reINVITEs, for example. Very hard to preserver To: header from opensips-script. This patch adds "p" flag to preserve To: header. Based on opensips trunk svn #9638. -- >Comment By: Bogdan-Andrei Iancu (bogdan_iancu) Date: 2013-01-28 02:43 Message: Nick, thanks for the patch, uploaded on the SVN trunk. Regards, Bogdan -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=1086412&aid=3601891&group_id=232389 ___ Devel mailing list Devel@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
[OpenSIPS-Devel] SF.net SVN: opensips:[9659] trunk/modules/b2b_logic
Revision: 9659 http://opensips.svn.sourceforge.net/opensips/?rev=9659&view=rev Author: bogdan_iancu Date: 2013-01-28 10:43:51 + (Mon, 28 Jan 2013) Log Message: --- - added new flag when invoking the b2b logic : 't' - preserve the received TO hdr, instead of generating a new one. Credits go to Nick Altmann Closes patch #3601891 Modified Paths: -- trunk/modules/b2b_logic/README trunk/modules/b2b_logic/b2b_logic.c trunk/modules/b2b_logic/b2b_logic.h trunk/modules/b2b_logic/doc/b2b_logic_admin.xml trunk/modules/b2b_logic/logic.c This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site. ___ Devel mailing list Devel@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
[OpenSIPS-Devel] [ opensips-Patches-3600377 ] Allow avps as a parameters in rtpproxy
Patches item #3600377, was opened at 2013-01-11 03:22 Message generated for change (Settings changed) made by bogdan_iancu You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=1086412&aid=3600377&group_id=232389 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: modules Group: trunk >Status: Closed Resolution: Accepted Priority: 5 Private: No Submitted By: Peter Lemenkov (peter_lemenkov) Assigned to: Bogdan-Andrei Iancu (bogdan_iancu) Summary: Allow avps as a parameters in rtpproxy Initial Comment: This is a copy of an original commit from your nasty twin's Git repository. It allows rtpproxy_offer/rtpproxy_answer to accept variables. I'm using a generic functions - fixup_spve_null, fixup_spve_spve, so please review it. I suppose that no additional fixup_free function is required here, right? -- Comment By: Bogdan-Andrei Iancu (bogdan_iancu) Date: 2013-01-17 07:46 Message: Hi Peter, Thanks for the patch - I had to do some changes as there was an error in your patch ; fixup_get_svalue() returns a STR value, while the params for force_rtp_proxy() are CHAR* . Simply doing str->s is not enough as that string is not null terminated. I made a fix on that, so please test my code and let me know if all cases do work as expected. Regards, Bogdan -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=1086412&aid=3600377&group_id=232389 ___ Devel mailing list Devel@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
[OpenSIPS-Devel] SF.net SVN: opensips:[9658] trunk/tcp_main.c
Revision: 9658 http://opensips.svn.sourceforge.net/opensips/?rev=9658&view=rev Author: bogdan_iancu Date: 2013-01-28 09:43:58 + (Mon, 28 Jan 2013) Log Message: --- - added flushing for the newly added tcp_list_conns MI command Modified Paths: -- trunk/tcp_main.c This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site. ___ Devel mailing list Devel@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
Re: [OpenSIPS-Devel] Improved socket error messages
Hi, On Jan 27, 2013, at 8:17 PM, Michael Schloh von Bennewitz wrote: > > Hello developers, > > While trying to debug a difficult to find problem (where ntop, > tcpdump, and snoop were no help) I finally figured out where > OpenSIPS was trying to send misdirected messages by hacking > the sources. It might be useful to always accompany log text > with network stack information. So instead of: > > Jan 02 18:18:02 hostname opensips[1234]: > ERROR:core:tcp_blocking_connect: failed to retrieve SO_ERROR (146) Connection > refused > > ...we would see: > > Jan 02 18:18:02 hostname opensips[1234]: > ERROR:core:tcp_blocking_connect: addr (1.2.3.4) port (98765), failed to > retrieve SO_ERROR (146) Connection refused > > ...which of course is much more useful. > > To integrate the improvement above, I hacked tcp_main.c like this: > > $ sed -e 's;\(LM_ERR("\)\(failed to retrieve SO_ERROR (%d) %s\\n",\);\1addr > (%s) port (%d), \2 inet_ntoa(((struct sockaddr_in *)servaddr)->sin_addr), > ntohs(((struct sockaddr_in *)servaddr)->sin_port),;' tcp_main.c > > ...or if you prefer here's a unified diff that does the same thing: > > diff -Nau tcp_main.c.orig tcp_main.c > --- tcp_main.c.orig 2012-10-17 00:09:05.0 +0200 > +++ tcp_main.c2013-01-27 16:44:47.803235857 +0100 > @@ -340,7 +340,7 @@ > getsockopt(fd, SOL_SOCKET, SO_ERROR, &err, &err_len); > if ((err==0) && (poll_err==0)) goto end; > if (err!=EINPROGRESS && err!=EALREADY){ > - LM_ERR("failed to retrieve SO_ERROR (%d) %s\n", > err, > + LM_ERR("addr (%s) port (%d), failed to retrieve > SO_ERROR (%d) %s\n", inet_ntoa(((struct sockaddr_in *)servaddr)->sin_addr), > ntohs(((struct sockaddr_in *)servaddr)->sin_port), err, > strerror(err)); > goto error; > } > > This hack applies cleanly to OpenSIPS 1.7.2 and 1.8.2 although I've > tested only on 1.7.2 (because of the database access bugs in 1.8.*.) > > Unfortunately there are other socket related operations which > write unhelpful log text, so this is not a complete solution. > Improved logging messages are of course great :-) I have a few unfinished patches in this regard as well, so if you send over partial improvements I'll incorporate them. However, the patch you sent is not correct because it doesn't deal with IPv6 addresses, you need to check the sa_family field of the sockaddr struct before casting it to sockaddr_in or sockaddr_in6. Regards, -- Saúl Ibarra Corretgé AG Projects ___ Devel mailing list Devel@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/devel