[OpenSIPS-Devel] SF.net SVN: opensips:[6096] trunk/modules/dialog/dlg_hash.c
Revision: 6096 http://opensips.svn.sourceforge.net/opensips/?rev=6096view=rev Author: bogdan_iancu Date: 2009-09-09 09:59:49 + (Wed, 09 Sep 2009) Log Message: --- - fixed compile warning when EXTRA_DEBUG compile option is enabled. Reported by Ovidiu Sas Modified Paths: -- trunk/modules/dialog/dlg_hash.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:[6098] branches/1.5/modules/usrloc
Revision: 6098 http://opensips.svn.sourceforge.net/opensips/?rev=6098view=rev Author: bogdan_iancu Date: 2009-09-09 10:29:39 + (Wed, 09 Sep 2009) Log Message: --- backport from trunk (rev #6097): - fixed mem leak in DB ONLY mode Revision Links: -- http://opensips.svn.sourceforge.net/opensips/?rev=6097view=rev Modified Paths: -- branches/1.5/modules/usrloc/udomain.c branches/1.5/modules/usrloc/urecord.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-2851051 ] db_does_uri_exist should respect use_uri_table
Bugs item #2851051, was opened at 2009-09-04 13:57 Message generated for change (Comment added) made by ironmissy You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=1086410aid=2851051group_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: Thomas Gelf (thomas_gelf) Assigned to: Irina-Maria Stanescu (ironmissy) Summary: db_does_uri_exist should respect use_uri_table Initial Comment: As I reduced OpenSIPS DB structure and DB permissions to an absolute minimum, I noticed that db_does_uri_exist() throws the following error: ERROR:db_mysql:get_new_stmt_ctx: driver error: SELECT command denied to user 'opensips'@'proxy.domain.tld' for table 'uri' ERROR:db_mysql:get_new_stmt_ctx: failed while mysql_stmt_prepare() ERROR:db_mysql:db_mysql_do_prepared_query: failed to create new context ERROR:uri:does_uri_exist: Error while querying database However, my config says: modparam(uri, use_uri_table, 0) IMO queries against uri-table shall not be issued in this case. I'm running OpenSIPS from current trunk, r6069. Best regards, Thomas Gelf -- Comment By: Irina-Maria Stanescu (ironmissy) Date: 2009-09-09 13:33 Message: I still cannot reproduce the error. I tried to delete uri table, as you've said and it does nothing. It behaves as it's supposed to, no matter what configuration changes i make. Please provide some additional information. Regards, Irina Stanescu -- Comment By: Thomas Gelf (thomas_gelf) Date: 2009-09-08 13:49 Message: Try to delete your uri-table - that should help to reproduce the error. In my case OpenSIPS has been granted a very restricted set of permissions, therefore I got aware of this problem. I'm not saying the function isn't working, but I guess it is issueing the SQL query against the uri-table even with use_uri_table=0 - and probably later it decides to take results from subscriber table. The error itself is pretty clear, it says SELECT command denied to user 'opensips'@'proxy.domain.tld' for table 'uri' - this should never happen with use_uri_table=0, even if the result may be as expected. If you need additional information please let me know! Best regards, Thomas Gelf -- Comment By: Irina-Maria Stanescu (ironmissy) Date: 2009-09-04 15:48 Message: I need more information (maybe the entire log and the configuration file) because i cannot reproduce this behavior. I tried db_does_uri_exist and it works just fine using the default table (subscriber, not uri). The only parameter needed is db_url. Regards, Irina Stanescu -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=1086410aid=2851051group_id=232389 ___ Devel mailing list Devel@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
[OpenSIPS-Devel] SF.net SVN: opensips:[6101] branches/1.5/modules/cpl-c/cpl.c
Revision: 6101 http://opensips.svn.sourceforge.net/opensips/?rev=6101view=rev Author: bogdan_iancu Date: 2009-09-09 12:27:50 + (Wed, 09 Sep 2009) Log Message: --- backport from trunk (rev #6100): - fixed memory leak on CPL interpreted setup when direction is OUTGOING: if not duplicated, the location values are not freed, so you must do it by hand. Revision Links: -- http://opensips.svn.sourceforge.net/opensips/?rev=6100view=rev Modified Paths: -- branches/1.5/modules/cpl-c/cpl.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:[6102] trunk
Revision: 6102
http://opensips.svn.sourceforge.net/opensips/?rev=6102view=rev
Author: anca_vamanu
Date: 2009-09-09 14:03:55 + (Wed, 09 Sep 2009)
Log Message:
---
- added 2 new routes:
- startup_route : called only once when the server is started (usage
example: load some data in cache)
- timer_route : a route that will be called at a configured interval of
time; there can be more timer_routes defined;
ex: timer_route[minute_route, 60] {
.. actions..
} - will be called every 60 seconds
Modified Paths:
--
trunk/cfg.lex
trunk/cfg.y
trunk/config.h
trunk/main.c
trunk/route.c
trunk/route.h
trunk/timer.c
trunk/timer.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
Re: [OpenSIPS-Devel] Limitations of dialog module
On 8 Sep 2009, at 16:34, Bogdan-Andrei Iancu wrote: Iñaki Baz Castillo wrote: IMHO, and according to a draft updating RFC 3261, the second 200 could be absorbed by the proxy instead of forwarded upstream. For this, the transaction should not be terminated upon receipt of the first 200, but remain in memory for a while (as the draft states). This is what the TM does right now - it keeps the transaction in mem, but also it allow all to received 200 OK to be sent to the UAC. This would simplify all this stuf a lot. Also, who in the world wants to receive two 200 for an INVITE? XDDD I agree but what should happen in the following scenario: 1) UAC sends INVITE 2) proxy forks the call to UAS1 and UAS2 3) both UAS1 and UAS2 send 200 OK in the same time 4) right now proxy will send both 200 OK to UAC 5) UAC will ACK both, keep one and BYE the other So, if we simply discard the second 200OK, what will happen with UAC2? it will think it is in a call... waiting for ACK.. I agree. The proxy should not discard anything. From UAC2's perspective the call is there, it only misses an ACK. It will keep retransmitting the 200 OK, until it decides to give up, unless is an UAC that was configured to ignore the missing ACK in which case it will consider that it has the call anyway and will act accordingly. At a moment I had in mind the option for the dialog module to ACK and BYE all the sequential 200 OK replies without sending anything to UAC Is this easier to do than to simply forward and make clones of the dialog? Regards, Bogdan ___ Devel mailing list Devel@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/devel -- Dan ___ Devel mailing list Devel@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
Re: [OpenSIPS-Devel] Limitations of dialog module
2009/9/9 Dan Pascu d...@ag-projects.com: So, if we simply discard the second 200OK, what will happen with UAC2? it will think it is in a call... waiting for ACK.. I agree. The proxy should not discard anything. From UAC2's perspective the call is there, it only misses an ACK. It will keep retransmitting the 200 OK, until it decides to give up, unless is an UAC that was configured to ignore the missing ACK in which case it will consider that it has the call anyway and will act accordingly. Yes, right. I must re-read the draft to know how it handles this case. And I've read it right now and I was wrong, what this draft states is: http://tools.ietf.org/html/draft-sparks-sip-invfix-03 -- 4. Summary of Change This correction document updates [RFC3261], adding a state and changing the transitions in the INVITE client state machine such that the INVITE client transaction remains in place to receive multiple 200 OK responses. It adds a state to the INVITE server state machine to absorb retransmissions of the INVITE after a 200 OK response has been sent. It modifies state transitions in the INVITE server state machine to absorb retransmissions of the INVITE request after encountering a unrecoverable transport error when sending a response. It also forbids forwarding stray responses to INVITE requests (not just 200 OK responses), which RFC3261 requires. -- So, each 200 is forwarded upstream to the UAC, but the INVITE transaction remains in the proxy (so a retransmittion of the INVITE from the UAC is not treated as a new request). -- Iñaki Baz Castillo i...@aliax.net ___ Devel mailing list Devel@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
[OpenSIPS-Devel] [ opensips-Bugs-2846849 ] CANCEL processing in b2bua
Bugs item #2846849, was opened at 2009-08-29 17:08 Message generated for change (Comment added) made by anca_vamanu You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=1086410aid=2846849group_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: Sergey Okhapkin (sokhapkin) Assigned to: Anca Vamanu (anca_vamanu) Summary: CANCEL processing in b2bua Initial Comment: When CANCEL request comes from UAC during early media stage, b2bua forwards the request to the uplink server, gets 200 OK from the server, but doesn't forward 200 OK back to UAC. -- Comment By: Anca Vamanu (anca_vamanu) Date: 2009-09-09 19:24 Message: Hi Sergey, You were right, I did not noticed it. I have fixed this also. Please update and test. regards, Anca -- Comment By: Sergey Okhapkin (sokhapkin) Date: 2009-09-08 05:17 Message: Now 200 OK is passed to UAC, but 487 Request terminated is not passed. -- Comment By: Anca Vamanu (anca_vamanu) Date: 2009-09-07 17:15 Message: Hi, I know fixed the proper bug :). Please update. I will wait for your confirmation before closing the bug report. Thanks and regards, Anca -- Comment By: Sergey Okhapkin (sokhapkin) Date: 2009-09-05 16:29 Message: Doesn't work to me. Server replies with 200 OK and then 487 Request Terminated. B2bua doesn't forward 200 OK to UAC (but forwards 487). -- Comment By: Anca Vamanu (anca_vamanu) Date: 2009-08-31 13:26 Message: Hi Sergey, I have looked through the code and found an error of the record in b2b_logic module being deleted too early(when 487 reply was received) and therefore not sending the final 200OK for CANCEL on the other side. Can you please update and test again? Thanks and regards, Anca -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=1086410aid=2846849group_id=232389 ___ Devel mailing list Devel@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
[OpenSIPS-Devel] New MediaProxy release 2.3.8
Hello, There is a new release of MediaProxy available, it contains several bug fixes. To upgrade your Debian unstable installation (it works now for both x86 and amd64 architectures): sudo apt-get update sudo apt-get install mediaproxy-dispatcher mediaproxy-relay mediaproxy- web-sessions Or download the tar file from: http://download.ag-projects.com/MediaProxy/ The changelog follows: mediaproxy (2.3.8) unstable; urgency=low . * Removed wrong quotes around option in config.ini.sample * Improved error message to make it easier to spot problems * Fixed handling of old remote stream address when undefined * Fixed building debian architecture dependent packages only Kind regards, Adrian Georgescu ___ Devel mailing list Devel@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
[OpenSIPS-Devel] new CDRTool release 6.9.3
Changelog: cdrtool (6.9.3) unstable; urgency=low * Fixed insert into prepaid table * Fixed url in PSTN gateways * Fixed column name in sip_trace table when purging * Fixed encoding of html links to sip and media trace * Fixed building statistics with online devices in OpenSIPS datasource cdrtool (6.9.2) unstable; urgency=low * Added labbels for all SIP Thor network entities cdrtool (6.9.1) unstable; urgency=low * Added labbels for SIP Thor nodes * Updated freeradius patches from Norman Brandinger * Export X509 certificate associated with the SIP account The software can be downloaded from: http://download.ag-projects.com/CDRTool/ For those running Debian unstable there is an official public repository. To use it, add these lines in /etc/apt/sources.list # AG Projects software deb http://ag-projects.com/debian unstable main deb-src http://ag-projects.com/debian unstable main Install the AG Projects debian software signing key: wget http://download.ag-projects.com/agp-debian-gpg.key apt-key add agp-debian-gpg.key After that, run: sudo apt-get update sudo apt-get install cdrtool Regards, Adrian ___ Devel mailing list Devel@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
[OpenSIPS-Devel] [ opensips-Bugs-2846849 ] CANCEL processing in b2bua
Bugs item #2846849, was opened at 2009-08-29 10:08 Message generated for change (Comment added) made by sokhapkin You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=1086410aid=2846849group_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: Sergey Okhapkin (sokhapkin) Assigned to: Anca Vamanu (anca_vamanu) Summary: CANCEL processing in b2bua Initial Comment: When CANCEL request comes from UAC during early media stage, b2bua forwards the request to the uplink server, gets 200 OK from the server, but doesn't forward 200 OK back to UAC. -- Comment By: Sergey Okhapkin (sokhapkin) Date: 2009-09-09 16:00 Message: Looks good now, thanks! -- Comment By: Anca Vamanu (anca_vamanu) Date: 2009-09-09 12:24 Message: Hi Sergey, You were right, I did not noticed it. I have fixed this also. Please update and test. regards, Anca -- Comment By: Sergey Okhapkin (sokhapkin) Date: 2009-09-07 22:17 Message: Now 200 OK is passed to UAC, but 487 Request terminated is not passed. -- Comment By: Anca Vamanu (anca_vamanu) Date: 2009-09-07 10:15 Message: Hi, I know fixed the proper bug :). Please update. I will wait for your confirmation before closing the bug report. Thanks and regards, Anca -- Comment By: Sergey Okhapkin (sokhapkin) Date: 2009-09-05 09:29 Message: Doesn't work to me. Server replies with 200 OK and then 487 Request Terminated. B2bua doesn't forward 200 OK to UAC (but forwards 487). -- Comment By: Anca Vamanu (anca_vamanu) Date: 2009-08-31 06:26 Message: Hi Sergey, I have looked through the code and found an error of the record in b2b_logic module being deleted too early(when 487 reply was received) and therefore not sending the final 200OK for CANCEL on the other side. Can you please update and test again? Thanks and regards, Anca -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=1086410aid=2846849group_id=232389 ___ Devel mailing list Devel@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
