[OpenSER-Devel] [ openser-Bugs-1862988 ] openserctl add fails if serweb tables are installed
Bugs item #1862988, was opened at 2008-01-03 10:18 Message generated for change (Comment added) made by klaus_darilion You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=743020aid=1862988group_id=139143 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: tools Group: ver 1.3.x Status: Closed Resolution: Invalid Priority: 5 Private: No Submitted By: Klaus Darilion (klaus_darilion) Assigned to: Bogdan-Andrei Iancu (bogdan_iancu) Summary: openserctl add fails if serweb tables are installed Initial Comment: I think it is caused by missing phplib_id during INSERT -- Comment By: Klaus Darilion (klaus_darilion) Date: 2008-01-07 12:54 Message: Logged In: YES user_id=1318360 Originator: YES of course NOT ;-) I added a note to the DB create script. -- Comment By: Bogdan-Andrei Iancu (bogdan_iancu) Date: 2008-01-04 16:55 Message: Logged In: YES user_id=1275325 Originator: NO Hi Klaus, Have you enabled the HAS_SERWEB variable in openserctlrc? Regards, Bogdan -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=743020aid=1862988group_id=139143 ___ Devel mailing list Devel@lists.openser.org http://lists.openser.org/cgi-bin/mailman/listinfo/devel
[OpenSER-Devel] SF.net SVN: openser: [3506] trunk
Revision: 3506 http://openser.svn.sourceforge.net/openser/?rev=3506view=rev Author: henningw Date: 2008-01-07 06:26:27 -0800 (Mon, 07 Jan 2008) Log Message: --- further cleanups in core database API - move use_table and close function for SQL DBs to core - move query, raw_query, insert, update, delete functions for SQL DBs to core - all this functions were almost identical implemented in the three DB, this functions uses now a function pointer based interface to do the work - the use_table functions from dbtext and db_berkeley uses also now the core API - move result management function from db_col to db_res to the other result management functions, they are not useful alone - change postgres module to match more the structure of mysql and unixodbc, remove the 'PARANOID' #define, the other modules don't have this and prefix all functions with db_postgres, make this more consistent to mysql module - prefix all functions in unixodbc module with db_unixodbc, make this consistent to the other modules, cleanup the namespace - prefix val2str function in mysql with db_mysql too - move the SQL_BUF_LENGTH to core API, all modules need this - remove the static SQL char buffer from postgres and unixodbc, uses the one provided from the core API - move documentation from db/doc to API files in doxygen format - improve and extend documentation for the whole API - make database API const correct, to guard against implementation errors and allow better compiler optimizations - change interface free_connection function in SQL DBs to connection structure to allow the usage of core API do_close - fix indention for postgres driver and make logging messages consistent - remove now unneeded system header includes for SQL DBs - remove transaction related code from postgres driver, this is not used at all and according to Klaus also brings no performance benefit if used. - probably some other smaller cleanups Tested with the testcases, so basic functionality should work.. Please test! :-) Modified Paths: -- trunk/db/db.c trunk/db/db.h trunk/db/db_cap.h trunk/db/db_con.h trunk/db/db_id.c trunk/db/db_id.h trunk/db/db_key.h trunk/db/db_op.h trunk/db/db_pool.c trunk/db/db_pool.h trunk/db/db_res.c trunk/db/db_res.h trunk/db/db_row.c trunk/db/db_row.h trunk/db/db_ut.c trunk/db/db_ut.h trunk/db/db_val.h trunk/modules/db_berkeley/db_berkeley.c trunk/modules/dbtext/dbt_api.c trunk/modules/mysql/dbase.c trunk/modules/mysql/dbase.h trunk/modules/mysql/my_con.c trunk/modules/mysql/my_con.h trunk/modules/mysql/res.c trunk/modules/mysql/res.h trunk/modules/mysql/row.c trunk/modules/mysql/row.h trunk/modules/mysql/val.c trunk/modules/mysql/val.h trunk/modules/postgres/db_mod.c trunk/modules/postgres/db_res.c trunk/modules/postgres/db_val.c trunk/modules/postgres/dbase.c trunk/modules/postgres/dbase.h trunk/modules/postgres/pg_con.c trunk/modules/postgres/pg_con.h trunk/modules/unixodbc/db_mod.c trunk/modules/unixodbc/dbase.c trunk/modules/unixodbc/dbase.h trunk/modules/unixodbc/my_con.c trunk/modules/unixodbc/my_con.h trunk/modules/unixodbc/res.c trunk/modules/unixodbc/res.h trunk/modules/unixodbc/row.c trunk/modules/unixodbc/row.h trunk/modules/unixodbc/val.c trunk/modules/unixodbc/val.h Added Paths: --- trunk/db/db_query.c trunk/db/db_query.h trunk/modules/postgres/db_res.h trunk/modules/postgres/db_val.h Removed Paths: - trunk/db/db_col.c trunk/db/db_col.h trunk/modules/mysql/db_con.c trunk/modules/postgres/defs.h trunk/modules/unixodbc/db_con.c This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site. ___ Devel mailing list Devel@lists.openser.org http://lists.openser.org/cgi-bin/mailman/listinfo/devel
[OpenSER-Devel] [ openser-Bugs-1864152 ] dialog module causes OpenSER to stop processing requests
Bugs item #1864152, was opened at 2008-01-04 14:42 Message generated for change (Comment added) made by intralanman You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=743020aid=1864152group_id=139143 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: ver 1.3.x Status: Open Resolution: None Priority: 5 Private: No Submitted By: intralanman (intralanman) Assigned to: Bogdan-Andrei Iancu (bogdan_iancu) Summary: dialog module causes OpenSER to stop processing requests Initial Comment: OpenSER sends a packet with a Record-Route as follows: Record-Route: sip:10.15.202.10:6080;lr;ftag=8621dc6d6281aa64o0;nat=yes;did=a16.4d576bc3. The other end sends a Record-Route as follows: Record-Route: sip:10.15.202.10:6080;lr;ftag=8621dc6d6281aa64o0;nat=yes;did=a16.4d576bc3,0 ap.. Upon receiving that packet, I see the following lines in the log file and OpenSER fails to respond to future requests until restarted: Jan 3 09:13:56 p1 oser[18407]: ERROR:core:parse_nameaddr: no found Jan 3 09:13:56 p1 oser[18407]: ERROR:core:do_parse_rr_body: failed to parse name-addr Jan 3 09:13:56 p1 oser[18407]: ERROR:core:print_rr_body: failed to parse RR Jan 3 09:13:56 p1 oser[18407]: ERROR:dialog:populate_leg_info: failed to print route records Jan 3 09:13:56 p1 oser[18407]: ERROR:dialog:dlg_onreply: could not add further info to the dialog Jan 3 09:13:56 p1 oser[18431]: CRITICAL:core:receive_fd: EOF on 11 -- Comment By: intralanman (intralanman) Date: 2008-01-07 09:31 Message: Logged In: YES user_id=1973783 Originator: YES That was the entire RR. I'm guessing that's the parsing problem. The entire INVITE I send is thus: (ip/domain changed) U 2008/01/03 09:13:48.017423 10.15.202.10:6080 - 10.25.48.83:5060 INVITE sip:[EMAIL PROTECTED]:5060;transport=udp SIP/2.0. Record-Route: sip:10.15.202.10:6080;lr;ftag=8621dc6d6281aa64o0;nat=yes;did=a16.4d576bc3. Via: SIP/2.0/UDP 10.15.202.10:6080;branch=z9hG4bK6eeb.ec9b8ef7.0. Via: SIP/2.0/UDP 192.168.1.1:10321;received=10.174.144.114;branch=z9hG4bK-2fdc3e94;rport=10321. From: sip:[EMAIL PROTECTED];tag=8621dc6d6281aa64o0. To: sip:[EMAIL PROTECTED]. Call-ID: [EMAIL PROTECTED] CSeq: 102 INVITE. Max-Forwards: 69. Contact: sip:[EMAIL PROTECTED]:10321. Expires: 240. User-Agent: Linksys/SPA2100-3.3.9. Content-Length: 223. Allow: ACK, BYE, CANCEL, INFO, INVITE, NOTIFY, OPTIONS, REFER. Supported: x-sipura, replaces. Content-Type: application/sdp. . v=0. o=- 323950 323950 IN IP4 192.168.1.1. s=-. c=IN IP4 10.15.202.10. t=0 0. m=audio 38762 RTP/AVP 0 101. a=rtpmap:0 PCMU/8000. a=rtpmap:101 telephone-event/8000. a=fmtp:101 0-15. a=ptime:20. a=sendrecv. a=nortpproxy:yes. The OK that they eventually send in return is: U 2008/01/03 09:13:56.571997 10.25.48.83:5060 - 10.15.202.10:6080 SIP/2.0 200 OK. Via: SIP/2.0/UDP 10.15.202.10:6080;branch=z9hG4bK6eeb.ec9b8ef7.0. Via: SIP/2.0/UDP 192.168.1.1:10321;received=10.174.144.114;branch=z9hG4bK-2fdc3e94;rport=10321. From: sip:[EMAIL PROTECTED];tag=8621dc6d6281aa64o0. To: sip:[EMAIL PROTECTED];tag=cba-74b2-477cfbcc. Call-ID: [EMAIL PROTECTED] CSeq: 102 INVITE. Contact: sip:[EMAIL PROTECTED]. Date: Thu, 03 Jan 2008 15:14:29 GMT. Server: BRSIP v2.0.1.2. Record-Route: sip:10.15.202.10:6080;lr;ftag=8621dc6d6281aa64o0;nat=yes;did=a16.4d576bc3,0 ap.. Allow: INVITE, ACK, CANCEL, BYE, OPTIONS, INFO, SUBSCRIBE, NOTIFY. Allow-Events: keep-alive, message-summary. Supported: timer. Content-Type: application/sdp. Content-Length: 214. . v=0. o=BRSDP 1011421 1011421 IN IP4 10.249.3.164. s=BRSDP Session. c=IN IP4 10.249.3.164. t=0 0. m=audio 25704 RTP/AVP 0 101. a=ptime:20. a=rtpmap:0 PCMU/8000. a=rtpmap:101 telephone-event/8000. a=fmtp:101 0-15. Obviously the BRSIP device has a problem with sending malformed packets but I think we can agree that OpenSER should just tell the remote end. u. have a nice day -- Comment By: Bogdan-Andrei Iancu (bogdan_iancu) Date: 2008-01-05 04:38 Message: Logged In: YES user_id=1275325 Originator: NO Hi, please post the complete RR header (multi body) returned in the reply. It looks like openser reports some syntax error on this RR hdr. Thanks and regards, Bogdan -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=743020aid=1864152group_id=139143 ___ Devel mailing list Devel@lists.openser.org http://lists.openser.org/cgi-bin/mailman/listinfo/devel
Re: [OpenSER-Devel] SF.net SVN: openser: [3506] trunk
On Monday 07 January 2008, Henning Westerholt wrote: Revision: 3506 http://openser.svn.sourceforge.net/openser/?rev=3506view=rev Author: henningw Date: 2008-01-07 06:26:27 -0800 (Mon, 07 Jan 2008) Hi Norman, this commit removes your change to the postgres driver in rev 1220: * 2006-11-01 Updated pg_insert(), pg_delete(), pg_update() and * pg_get_result() to handle failed queries. Detailed warnings along with the * text of the failed query is now displayed in the log. * Callers of these routines can now assume that a non-zero rc indicates * the query failed and that remedial action may need to be taken. (norm) Should we implement this also for the other drivers? Also you changed the postgres implementation to returns a positive value in this case, are there any modules that evaluates this return code at all? What do you think? Cheers, Henning ___ Devel mailing list Devel@lists.openser.org http://lists.openser.org/cgi-bin/mailman/listinfo/devel
[OpenSER-Devel] SF.net SVN: openser: [3508] branches/1.3/modules/carrierroute
Revision: 3508 http://openser.svn.sourceforge.net/openser/?rev=3508view=rev Author: henningw Date: 2008-01-07 07:59:00 -0800 (Mon, 07 Jan 2008) Log Message: --- - backport from trunk, rev 3507, improve documentation Revision Links: -- http://openser.svn.sourceforge.net/openser/?rev=3507view=rev Modified Paths: -- branches/1.3/modules/carrierroute/README branches/1.3/modules/carrierroute/doc/carrierroute_user.sgml This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site. ___ Devel mailing list Devel@lists.openser.org http://lists.openser.org/cgi-bin/mailman/listinfo/devel
Re: [OpenSER-Devel] ERROR:core:pv_printf: buffer overflow (doing a long SQL query)
On Monday 07 January 2008 16:45:24 Iñaki Baz Castillo wrote: --- Jan 7 16:42:30 [4101] ERROR:core:pv_printf: no more space for text [34] Jan 7 16:42:30 [4101] ERROR:core:pv_printf: buffer overflow -- increase the buffer size... Jan 7 16:42:30 [4101] ERROR:avpops:ops_dbquery_avps: cannot print the query --- It ocurrs when the RURI is very long (because the SQL uses the RURI). How can I increase that buffer size? Thanks a lot. I've found in pvar.c: - #define PV_PRINT_BUF_SIZE 1024 #define PV_PRINT_BUF_NO3 /*IMPORTANT NOTE - even if the function prints and returns a static buffer, it * has built-in support for 3 levels of nesting (or concurrent usage). * If you think it's not enough for you, either use pv_printf() directly, * either increase PV_PRINT_BUF_NO --bogdan */ - Should I increase PV_PRINT_BUF_SIZE or PV_PRINT_BUF_NO ? -- Iñaki Baz Castillo [EMAIL PROTECTED] ___ Devel mailing list Devel@lists.openser.org http://lists.openser.org/cgi-bin/mailman/listinfo/devel
Re: [OpenSER-Devel] ERROR:core:pv_printf: buffer overflow (doing a long SQL query)
Hi Iñaki, You need to increase PV_PRINT_BUF_SIZE which is the size of the buffer used for printing the end result. PV_PRINT_BUF_NO is the number of buffers to be used in case of nested calls, but it is not your case. Regards, Bogdan Iñaki Baz Castillo wrote: On Monday 07 January 2008 16:45:24 Iñaki Baz Castillo wrote: --- Jan 7 16:42:30 [4101] ERROR:core:pv_printf: no more space for text [34] Jan 7 16:42:30 [4101] ERROR:core:pv_printf: buffer overflow -- increase the buffer size... Jan 7 16:42:30 [4101] ERROR:avpops:ops_dbquery_avps: cannot print the query --- It ocurrs when the RURI is very long (because the SQL uses the RURI). How can I increase that buffer size? Thanks a lot. I've found in pvar.c: - #define PV_PRINT_BUF_SIZE 1024 #define PV_PRINT_BUF_NO3 /*IMPORTANT NOTE - even if the function prints and returns a static buffer, it * has built-in support for 3 levels of nesting (or concurrent usage). * If you think it's not enough for you, either use pv_printf() directly, * either increase PV_PRINT_BUF_NO --bogdan */ - Should I increase PV_PRINT_BUF_SIZE or PV_PRINT_BUF_NO ? ___ Devel mailing list Devel@lists.openser.org http://lists.openser.org/cgi-bin/mailman/listinfo/devel
Re: [OpenSER-Devel] ERROR:core:pv_printf: buffer overflow (doing a long SQL query)
On Monday 07 January 2008 17:30:23 Bogdan-Andrei Iancu wrote: Hi Iñaki, You need to increase PV_PRINT_BUF_SIZE which is the size of the buffer used for printing the end result. PV_PRINT_BUF_NO is the number of buffers to be used in case of nested calls, but it is not your case. Thanks Bogdan, but Ive increased it (from 1024 to 4096): #define PV_PRINT_BUF_SIZE 4096 and the problem still occurs in exactly the same way: Jan 7 18:08:13 [31284] ERROR:core:pv_printf: no more space for text [34] Jan 7 18:08:13 [31284] ERROR:core:pv_printf: buffer overflow -- increase the buffer size... Jan 7 18:08:13 [31284] ERROR:avpops:ops_dbquery_avps: cannot print the query - Should I do anyhting else? Really thanks a lot for any help. -- Iñaki Baz Castillo [EMAIL PROTECTED] ___ Devel mailing list Devel@lists.openser.org http://lists.openser.org/cgi-bin/mailman/listinfo/devel
[OpenSER-Devel] SF.net SVN: openser: [3509] trunk/modules/lcr/lcr_mod.c
Revision: 3509 http://openser.svn.sourceforge.net/openser/?rev=3509view=rev Author: dan_pascu Date: 2008-01-07 12:24:41 -0800 (Mon, 07 Jan 2008) Log Message: --- Fixed a core dump caused by illegal memory access if the rpid AVP holds an integer value Modified Paths: -- trunk/modules/lcr/lcr_mod.c This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site. ___ Devel mailing list Devel@lists.openser.org http://lists.openser.org/cgi-bin/mailman/listinfo/devel
Re: [OpenSER-Devel] SF.net SVN: openser: [3483] trunk
Henning Westerholt writes: Its safe to use the pv_parse_spec function instead of the pv_parse_format? Or perhaps better use the pv_parse_format in the fixup function too? What is the suggested way of fixing PVs? if argument can be just a pvar and nothing else, i want its handling during message processing to as efficient as possible. if there is any performance penalty in pv_parse_format, then please write another fixup function for it. -- juha ___ Devel mailing list Devel@lists.openser.org http://lists.openser.org/cgi-bin/mailman/listinfo/devel
[OpenSER-Devel] SF.net SVN: openser: [3510] branches/1.3/modules/lcr/lcr_mod.c
Dan Pascu writes: Log Message: --- Fixed a core dump caused by illegal memory access if the rpid AVP holds an integer value dan, thanks for the fix. -- juha ___ Devel mailing list Devel@lists.openser.org http://lists.openser.org/cgi-bin/mailman/listinfo/devel
