[OpenSIPS-Devel] Building Telephony Systems with OpenSIPS

2010-01-21 Thread Bogdan-Andrei Iancu
Thanks to Flavio E. Goncalves, a new edition of Building Telephony 
Systems with OpenSIPS is now available.

It covers the latest stable release, the OpenSIPS 1.6, updating existing 
topics (NAT traversal, accounting, etc), but also approaching new 1.6 
specific technologies (data caching, dialog usage, etc):

The book will teach you how to build scalable and robust telephony 
systems using SIP:

- Build a VoIP Provider based on the SIP Protocol
- Cater to scores of subscribers efficiently with a robust telephony 
system based in pure SIP
- Gain a competitive edge using the most scalable VoIP technology
- Learn how to avoid pitfalls using precise billing
- Packed with rich practical examples and case studies on the latest 
OpenSIPS version 1.6

More on : 
http://www.packtpub.com/building-telephony-systems-with-opensips-1-6/book

Regards,
Bogdan

-- 
Bogdan-Andrei Iancu
www.voice-system.ro

___
Devel mailing list
Devel@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/devel


[OpenSIPS-Devel] [ opensips-Bugs-2934618 ] possible memory leak in serialize.c

2010-01-21 Thread SourceForge.net
Bugs item #2934618, was opened at 2010-01-19 01:27
Message generated for change (Settings changed) made by bogdan_iancu
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detailatid=1086410aid=2934618group_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.6.x
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Richard Revels (rrevels)
Assigned to: Bogdan-Andrei Iancu (bogdan_iancu)
Summary: possible memory leak in serialize.c

Initial Comment:
We have been chasing what appears to be a memory leak in opensips-1.6.1-notls.  
We believe that in serialize_branches line 154 enc_info is being allocated but 
is not being freed in all cases.  We will continue tracking this but wanted to 
get it out where other eyes could look into it as well.

--

Comment By: Richard Revels (rrevels)
Date: 2010-01-19 17:56

Message:
To add to this, we think enc_info gets malloc'd.  Then contacts[i].enc_info
is set to that pointer.  Then val.s is also set to that pointer.  Next val
is used in a call to add_avp for serial_avp.  This malloc's and copies the
data from val.  val is left hanging on exit from serialize_branches and if
the pointer is freed from the contacts structure, we haven't found that
yet.

--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detailatid=1086410aid=2934618group_id=232389

___
Devel mailing list
Devel@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/devel


[OpenSIPS-Devel] [ opensips-Bugs-2936420 ] typo in load balancer documentation

2010-01-21 Thread SourceForge.net
Bugs item #2936420, was opened at 2010-01-21 15:56
Message generated for change (Tracker Item Submitted) made by nobody
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detailatid=1086410aid=2936420group_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: docs
Group: trunk
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: typo in load balancer documentation

Initial Comment:
Documentation of the load_balance module reads Example 1.7. set_dlg_profile 
usage in paragraph 1.6.1:

Example 1.7. set_dlg_profile usage

...
if (load_balance(1,trascoding;conference)) {
# dst URI points to the new destination
xlog(sending call to $du\n);
t_relay();
exit;
}
...

It should read load_balance usage instead.
As I see this typo is still present in trunk:

http://opensips.svn.sourceforge.net/viewvc/opensips/trunk/modules/load_balancer/doc/load_balancer_admin.xml?revision=5913view=markup

--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detailatid=1086410aid=2936420group_id=232389

___
Devel mailing list
Devel@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/devel


[OpenSIPS-Devel] [B2B_ENTITIES] ACK Strategy

2010-01-21 Thread Olivier Détour
Hi,

I'm having a hard time using b2b_entities:
After sending a 4xx error (long after the invite), I'd like to be
notified when the client sends the ACK. I'd want to be able to close
the call context when my module receives the client's ACK, but I never
see it, b2b_entities silently processes it.
Is it possible to change this behaviour?
I saw in the debug trace (debug=9) that the ACK is not for the
server_address parameter (in opensips.cfg), could this be a part of
the problem?
For example I've got a 404 error being resent continuously until phone timeout.
If I missed documentation on the subject I will gladly RTFM if someone
points me in the right direction.

Thanks,

Regards,

-- 
Olivier Détour

___
Devel mailing list
Devel@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/devel


[OpenSIPS-Devel] [ opensips-Bugs-2934618 ] possible memory leak in serialize.c

2010-01-21 Thread SourceForge.net
Bugs item #2934618, was opened at 2010-01-19 01:27
Message generated for change (Comment added) made by bogdan_iancu
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detailatid=1086410aid=2934618group_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.6.x
Status: Open
Resolution: Fixed
Priority: 5
Private: No
Submitted By: Richard Revels (rrevels)
Assigned to: Bogdan-Andrei Iancu (bogdan_iancu)
Summary: possible memory leak in serialize.c

Initial Comment:
We have been chasing what appears to be a memory leak in opensips-1.6.1-notls.  
We believe that in serialize_branches line 154 enc_info is being allocated but 
is not being freed in all cases.  We will continue tracking this but wanted to 
get it out where other eyes could look into it as well.

--

Comment By: Bogdan-Andrei Iancu (bogdan_iancu)
Date: 2010-01-21 19:34

Message:
Hi Richard,

Indeed there was a mem leak there - could you test the attached patch? it
should fix the problem. If ok, I will upload the patch on SVN.

Thanks and regards,
Bogdan

--

Comment By: Richard Revels (rrevels)
Date: 2010-01-19 17:56

Message:
To add to this, we think enc_info gets malloc'd.  Then contacts[i].enc_info
is set to that pointer.  Then val.s is also set to that pointer.  Next val
is used in a call to add_avp for serial_avp.  This malloc's and copies the
data from val.  val is left hanging on exit from serialize_branches and if
the pointer is freed from the contacts structure, we haven't found that
yet.

--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detailatid=1086410aid=2934618group_id=232389

___
Devel mailing list
Devel@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/devel


[OpenSIPS-Devel] SF.net SVN: opensips:[6516] branches/1.6/modules/load_balancer

2010-01-21 Thread Bogdan-Andrei Iancu
Revision: 6516
  http://opensips.svn.sourceforge.net/opensips/?rev=6516view=rev
Author:   bogdan_iancu
Date: 2010-01-21 17:39:33 + (Thu, 21 Jan 2010)

Log Message:
---
- fixed typo in docs.
  Closes bug report 2936420

Modified Paths:
--
branches/1.6/modules/load_balancer/README
branches/1.6/modules/load_balancer/doc/load_balancer_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:[6517] branches/1.5/modules/load_balancer

2010-01-21 Thread Bogdan-Andrei Iancu
Revision: 6517
  http://opensips.svn.sourceforge.net/opensips/?rev=6517view=rev
Author:   bogdan_iancu
Date: 2010-01-21 17:39:42 + (Thu, 21 Jan 2010)

Log Message:
---
- fixed typo in docs.
  Closes bug report 2936420

Modified Paths:
--
branches/1.5/modules/load_balancer/README
branches/1.5/modules/load_balancer/doc/load_balancer_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] [ opensips-Bugs-2936420 ] typo in load balancer documentation

2010-01-21 Thread SourceForge.net
Bugs item #2936420, was opened at 2010-01-21 17:56
Message generated for change (Settings changed) made by bogdan_iancu
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detailatid=1086410aid=2936420group_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: docs
Group: trunk
Status: Closed
Resolution: Fixed
Priority: 5
Private: No
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Bogdan-Andrei Iancu (bogdan_iancu)
Summary: typo in load balancer documentation

Initial Comment:
Documentation of the load_balance module reads Example 1.7. set_dlg_profile 
usage in paragraph 1.6.1:

Example 1.7. set_dlg_profile usage

...
if (load_balance(1,trascoding;conference)) {
# dst URI points to the new destination
xlog(sending call to $du\n);
t_relay();
exit;
}
...

It should read load_balance usage instead.
As I see this typo is still present in trunk:

http://opensips.svn.sourceforge.net/viewvc/opensips/trunk/modules/load_balancer/doc/load_balancer_admin.xml?revision=5913view=markup

--

Comment By: Bogdan-Andrei Iancu (bogdan_iancu)
Date: 2010-01-21 19:40

Message:
Thanks for the fix - it was applied on all versions.

Regards,
Bogdan

--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detailatid=1086410aid=2936420group_id=232389

___
Devel mailing list
Devel@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/devel


[OpenSIPS-Devel] [ opensips-Bugs-2936343 ] 'opensipsctl fifo get_statistics all' crashes opensips

2010-01-21 Thread SourceForge.net
Bugs item #2936343, was opened at 2010-01-21 15:51
Message generated for change (Comment added) made by bogdan_iancu
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detailatid=1086410aid=2936343group_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.6.x
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Alex Massover (cupotka2008)
Assigned to: Bogdan-Andrei Iancu (bogdan_iancu)
Summary: 'opensipsctl fifo get_statistics all' crashes opensips

Initial Comment:
Hi!

'opensipsctl fifo get_statistics all' always crashes opensips. Core is somehow 
not produced.
Always reproducible for me on 1.6.1.

Here's a strace of parent process:

Process 9509 attached - interrupt to quit
pause() = ? ERESTARTNOHAND (To be restarted)
--- SIGUSR2 (User defined signal 2) @ 0 (0) ---
sigreturn() = ? (mask now [])
pause() = ? ERESTARTNOHAND (To be restarted)
--- SIGCHLD (Child exited) @ 0 (0) ---
sigreturn() = ? (mask now [])
waitpid(-1, [{WIFSIGNALED(s)  WTERMSIG(s) == SIGUSR2}], WNOHANG) = 9520
waitpid(-1, 0xbf84b4c8, WNOHANG)= 0
kill(0, SIGTERM)= 0
--- SIGTERM (Terminated) @ 0 (0) ---
--- SIGCHLD (Child exited) @ 0 (0) ---
sigreturn() = ? (mask now [TERM])
sigreturn() = ? (mask now [])
rt_sigaction(SIGALRM, {0x8065920, [ALRM], SA_RESTART}, {SIG_DFL}, 8) = 0
alarm(60)   = 0
wait4(-1, NULL, 0, NULL)= 9514
wait4(-1, NULL, 0, NULL)= 9519
wait4(-1, NULL, 0, NULL)= 9521
wait4(-1, NULL, 0, NULL)= 9522
wait4(-1, NULL, 0, NULL)= 9512
--- SIGCHLD (Child exited) @ 0 (0) ---
sigreturn() = ? (mask now [])
--- SIGCHLD (Child exited) @ 0 (0) ---
sigreturn() = ? (mask now [])
wait4(-1, NULL, 0, NULL)= 9510
wait4(-1, NULL, 0, NULL)= 9516
--- SIGCHLD (Child exited) @ 0 (0) ---
sigreturn() = ? (mask now [])
--- SIGCHLD (Child exited) @ 0 (0) ---
sigreturn() = ? (mask now [])
wait4(-1, NULL, 0, NULL)= 9515
wait4(-1, NULL, 0, NULL)= 9517
wait4(-1, NULL, 0, NULL)= 9524
wait4(-1, NULL, 0, NULL)= 9525
--- SIGCHLD (Child exited) @ 0 (0) ---
sigreturn() = ? (mask now [])
--- SIGCHLD (Child exited) @ 0 (0) ---
sigreturn() = ? (mask now [])
--- SIGCHLD (Child exited) @ 0 (0) ---
sigreturn() = ? (mask now [])
--- SIGCHLD (Child exited) @ 0 (0) ---
sigreturn() = ? (mask now [])
wait4(-1, NULL, 0, NULL)= 9511
wait4(-1, NULL, 0, NULL)= 9513
wait4(-1, NULL, 0, NULL)= 9518
wait4(-1, NULL, 0, NULL)= 9523
wait4(-1, NULL, 0, NULL)= -1 ECHILD (No child processes)
rt_sigaction(SIGALRM, {0x8066080, [ALRM], SA_RESTART}, {0x8065920, [ALRM], 
SA_RESTART}, 8) = 0 stat64(/tmp/opensips_fifo, {st_mode=S_IFIFO|0660, 
st_size=0, ...}) = 0
unlink(/tmp/opensips_fifo)= 0
munmap(0xaed25000, 134217728)   = 0
unlink(/var/run/opensips/opensips.pid) = 0
alarm(0)= 60
rt_sigaction(SIGALRM, {SIG_IGN}, {0x8066080, [ALRM], SA_RESTART}, 8) = 0
exit_group(0)   = ?
Process 9509 detached


--

Comment By: Bogdan-Andrei Iancu (bogdan_iancu)
Date: 2010-01-21 19:51

Message:
Hi Alex,

The strace of the main proc is irrelevant here - what is important is the
bt or strace of the FIFO/xmlrpc process. BTW, what MI backend do you use ?

Regards,
Bogdan

--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detailatid=1086410aid=2936343group_id=232389

___
Devel mailing list
Devel@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/devel


Re: [OpenSIPS-Devel] Possible bug in dbt_lib.c with suggested correction

2010-01-21 Thread Bogdan-Andrei Iancu
Hi Michael,

There is a huge difference between STR and STRING . STR is a string with 
length (a start pointer and its len), while STRING is just a starting 
pointer with a \0 terminator at the end.

STR and BLOB are compatible as they do not rely on the \0 terminator , 
but STRING and BLOB are not alike as BLOB contain data (including \0).

Regards,
Bogdan

Michael Schloh von Bennewitz wrote:
 Hello Bogdan,

 On Tues., Jan 20, 2010, Bogdan-Andrei Iancu wrote:
   
 Michael Schloh von Bennewitz wrote:
 
 Hello list,

 It would seem that Bogdan's recent correction relating to the BLOB
 datatype support was not complete.

 Index: modules/db_text/dbt_lib.c
 diff -Nau modules/db_text/dbt_lib.c.orig modules/db_text/dbt_lib.c
 --- modules/db_text/dbt_lib.c.orig  2010-01-20 11:10:07.967990871 +0100
 +++ modules/db_text/dbt_lib.c   2010-01-20 11:10:21.649138475 +0100
 @@ -440,7 +440,7 @@
 case DB_DOUBLE:
 break;
 case DB_STRING:
 -   if(_t0==DB_STR)
 +   if(_t0==DB_STR || _t0==DB_BLOB)
 return 0;
 case DB_STR:
 if(_t0==DB_STRING || _t0==DB_BLOB)


 The '-' and '+' indicate my suggested correction, keeping in line
 with Bogdan's recent change SVN revision 6382.

   
 Have this fix resulted from troubleshooting some error ? or it is a
 logical fix ?

 
 Your own comment for checkin 6382 is 'fixed incomatibility between
 BLOB data type and string format for columns' and your change is:

 --- trunk/modules/db_text/dbt_lib.c   2009/07/21 07:45:05 5901
 +++ trunk/modules/db_text/dbt_lib.c   2009/12/09 16:33:12 6382
 @@ -446,7 +446,7 @@
   if(_t0==DB_STRING || _t0==DB_BLOB)
   return 0;
   case DB_BLOB:
 - if(_t0==DB_STR)
 + if(_t0==DB_STR || _t0==DB_STRING)
   return 0;
   case DB_BITMAP:
   if (_t0==DB_INT)

 That fixed a nondocumented bug in which the sip_trace module could
 not write to its table when the database is dbtext.

 Then I looked at the code block and saw that DB_STR and DB_STRING
 are logically equal. See 'case DB_STRING: if(_t0==DB_STR) return 0;'
 above.

 ...so I assume that if comparing DB_STR and DB_BLOB should return
 0, then comparing DB_STRING and DB_BLOB should return 0 as well.
 It's a long winded way of saying 'my suggestion is a logical fix.'
 I've found no runtime failure to motivate this correction, although
 there could be one hiding.

   
 Because the STRING and BLOB times are not really compatible. STRING
 is zero terminated data while BLOB contains data (including 0), if
 you get my point.

 
 Just how different are DB_STRING and DB_STR? Is one zero terminated
 and the other not? If that's right, then maybe the best thing is to
 return 0 when comparing DB_BLOB with whichever [DB_STR|DB_STRING] is
 most similar (in which zero termination plays a role in deciding.)

 ...and if that's how the code was in the first place, then just
 disregard my patch suggestion.

 Regards,
 Michael

   


-- 
Bogdan-Andrei Iancu
www.voice-system.ro


___
Devel mailing list
Devel@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/devel


Re: [OpenSIPS-Devel] New contribution, ISN lookup in ENUM module

2010-01-21 Thread Bogdan-Andrei Iancu
Hello Michael,

Thanks for your contribution - I will take a quick look over the patch 
to see if everything is ok and I will upload it on SVN. BTW, are you 
interested in activly maintaining that code ? I can grant you SVN access 
for the enum part.

Thanks and regards,
Bogdan

Michael Schloh von Bennewitz wrote:
 Hello list,

 I see from http://www.opensips.org/Development/Development that the
 ENUM module is 'commonly maintained.' Whoever has commit authority
 might like to take a look at the new ISN lookup integration that
 we are using with freenum.org and DNS delegation of our ITAD:

   http://scm.europalab.com/contrib/file/tip/opensips/
   http://scm.europalab.com/contrib/file/tip/opensips/enum-isn.txt
   http://scm.europalab.com/contrib/file/tip/opensips/enum-isn.diff

 References:

   http://www.freenum.org/
   ftp://ftp.ietf.org/rfc/rfc3872.txt
   ftp://ftp.ietf.org/rfc/rfc2871.txt
   http://www.iana.org/assignments/trip-parameters/

 Basically, files (both code and documentation) in modules/enum of
 SVN trunk revision 6511 were modified to allow ISN formatting and
 lookup to succeed. This was broken in all distributions, because
 ISN and ENUM URLs must be formatted differently when looking up
 their NAPTR entries.

 A new function is exported by the ENUM module called 'isn_query()'
 as well as the supporting variable isn_suffix. I didn't provide
 code to handle the idea of draft-haberler-carrier-enum-01.txt or
 a function 'is_from_user_isn()' but that can come later if it's
 necessary.

 I recommend that this or similar logic be integrated into the
 next OpenSIPS distribution, partly because the distributed and
 online documentation already implies that ISN lookups succeed
 Search with grep(1) for 'freenum.org' in the ENUM module docs.

 Cheers,
 Michael

   


-- 
Bogdan-Andrei Iancu
www.voice-system.ro


___
Devel mailing list
Devel@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/devel


Re: [OpenSIPS-Devel] [ opensips-Bugs-2936343 ] 'opensipsctl fifo get_statistics all' crashes opensips

2010-01-21 Thread Richard Revels
Oh yeah.  I get same result.  I am using unix domain socket for MI.  
get_statistics core: no problem.  get_statistics all dumps opensips.  No core 
generated.  Here is the opensips log when it happens:

Jan 21 18:08:19 guinea-pig1 osips-log[3931]: INFO:core:handle_sigs: child 
process 3943 exited by a signal 12 
Jan 21 18:08:19 guinea-pig1 osips-log[3931]: INFO:core:handle_sigs: core was 
not generated 
Jan 21 18:08:19 guinea-pig1 osips-log[3931]: INFO:core:handle_sigs: terminating 
due to SIGCHLD 

Richard Revels


On Jan 21, 2010, at 12:51 PM, SourceForge.net wrote:

 Bugs item #2936343, was opened at 2010-01-21 15:51
 Message generated for change (Comment added) made by bogdan_iancu
 You can respond by visiting: 
 https://sourceforge.net/tracker/?func=detailatid=1086410aid=2936343group_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.6.x
 Status: Open
 Resolution: None
 Priority: 5
 Private: No
 Submitted By: Alex Massover (cupotka2008)
 Assigned to: Bogdan-Andrei Iancu (bogdan_iancu)
 Summary: 'opensipsctl fifo get_statistics all' crashes opensips
 
 Initial Comment:
 Hi!
 
 'opensipsctl fifo get_statistics all' always crashes opensips. Core is 
 somehow not produced.
 Always reproducible for me on 1.6.1.
 
 Here's a strace of parent process:
 
 Process 9509 attached - interrupt to quit
 pause() = ? ERESTARTNOHAND (To be restarted)
 --- SIGUSR2 (User defined signal 2) @ 0 (0) ---
 sigreturn() = ? (mask now [])
 pause() = ? ERESTARTNOHAND (To be restarted)
 --- SIGCHLD (Child exited) @ 0 (0) ---
 sigreturn() = ? (mask now [])
 waitpid(-1, [{WIFSIGNALED(s)  WTERMSIG(s) == SIGUSR2}], WNOHANG) = 9520
 waitpid(-1, 0xbf84b4c8, WNOHANG)= 0
 kill(0, SIGTERM)= 0
 --- SIGTERM (Terminated) @ 0 (0) ---
 --- SIGCHLD (Child exited) @ 0 (0) ---
 sigreturn() = ? (mask now [TERM])
 sigreturn() = ? (mask now [])
 rt_sigaction(SIGALRM, {0x8065920, [ALRM], SA_RESTART}, {SIG_DFL}, 8) = 0
 alarm(60)   = 0
 wait4(-1, NULL, 0, NULL)= 9514
 wait4(-1, NULL, 0, NULL)= 9519
 wait4(-1, NULL, 0, NULL)= 9521
 wait4(-1, NULL, 0, NULL)= 9522
 wait4(-1, NULL, 0, NULL)= 9512
 --- SIGCHLD (Child exited) @ 0 (0) ---
 sigreturn() = ? (mask now [])
 --- SIGCHLD (Child exited) @ 0 (0) ---
 sigreturn() = ? (mask now [])
 wait4(-1, NULL, 0, NULL)= 9510
 wait4(-1, NULL, 0, NULL)= 9516
 --- SIGCHLD (Child exited) @ 0 (0) ---
 sigreturn() = ? (mask now [])
 --- SIGCHLD (Child exited) @ 0 (0) ---
 sigreturn() = ? (mask now [])
 wait4(-1, NULL, 0, NULL)= 9515
 wait4(-1, NULL, 0, NULL)= 9517
 wait4(-1, NULL, 0, NULL)= 9524
 wait4(-1, NULL, 0, NULL)= 9525
 --- SIGCHLD (Child exited) @ 0 (0) ---
 sigreturn() = ? (mask now [])
 --- SIGCHLD (Child exited) @ 0 (0) ---
 sigreturn() = ? (mask now [])
 --- SIGCHLD (Child exited) @ 0 (0) ---
 sigreturn() = ? (mask now [])
 --- SIGCHLD (Child exited) @ 0 (0) ---
 sigreturn() = ? (mask now [])
 wait4(-1, NULL, 0, NULL)= 9511
 wait4(-1, NULL, 0, NULL)= 9513
 wait4(-1, NULL, 0, NULL)= 9518
 wait4(-1, NULL, 0, NULL)= 9523
 wait4(-1, NULL, 0, NULL)= -1 ECHILD (No child processes)
 rt_sigaction(SIGALRM, {0x8066080, [ALRM], SA_RESTART}, {0x8065920, [ALRM], 
 SA_RESTART}, 8) = 0 stat64(/tmp/opensips_fifo, {st_mode=S_IFIFO|0660, 
 st_size=0, ...}) = 0
 unlink(/tmp/opensips_fifo)= 0
 munmap(0xaed25000, 134217728)   = 0
 unlink(/var/run/opensips/opensips.pid) = 0
 alarm(0)= 60
 rt_sigaction(SIGALRM, {SIG_IGN}, {0x8066080, [ALRM], SA_RESTART}, 8) = 0
 exit_group(0)   = ?
 Process 9509 detached
 
 
 --
 
 Comment By: Bogdan-Andrei Iancu (bogdan_iancu)
 Date: 2010-01-21 19:51
 
 Message:
 Hi Alex,
 
 The strace of the main proc is irrelevant here - what is important is the
 bt or strace of the FIFO/xmlrpc process. BTW, what MI backend do you use ?
 
 Regards,
 Bogdan
 
 --
 
 You can respond by visiting: 
 https://sourceforge.net/tracker/?func=detailatid=1086410aid=2936343group_id=232389
 
 ___
 Devel mailing 

[OpenSIPS-Devel] [ opensips-Bugs-2936343 ] 'opensipsctl fifo get_statistics all' crashes opensips

2010-01-21 Thread SourceForge.net
Bugs item #2936343, was opened at 2010-01-21 15:51
Message generated for change (Comment added) made by cupotka2008
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detailatid=1086410aid=2936343group_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.6.x
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Alex Massover (cupotka2008)
Assigned to: Bogdan-Andrei Iancu (bogdan_iancu)
Summary: 'opensipsctl fifo get_statistics all' crashes opensips

Initial Comment:
Hi!

'opensipsctl fifo get_statistics all' always crashes opensips. Core is somehow 
not produced.
Always reproducible for me on 1.6.1.

Here's a strace of parent process:

Process 9509 attached - interrupt to quit
pause() = ? ERESTARTNOHAND (To be restarted)
--- SIGUSR2 (User defined signal 2) @ 0 (0) ---
sigreturn() = ? (mask now [])
pause() = ? ERESTARTNOHAND (To be restarted)
--- SIGCHLD (Child exited) @ 0 (0) ---
sigreturn() = ? (mask now [])
waitpid(-1, [{WIFSIGNALED(s)  WTERMSIG(s) == SIGUSR2}], WNOHANG) = 9520
waitpid(-1, 0xbf84b4c8, WNOHANG)= 0
kill(0, SIGTERM)= 0
--- SIGTERM (Terminated) @ 0 (0) ---
--- SIGCHLD (Child exited) @ 0 (0) ---
sigreturn() = ? (mask now [TERM])
sigreturn() = ? (mask now [])
rt_sigaction(SIGALRM, {0x8065920, [ALRM], SA_RESTART}, {SIG_DFL}, 8) = 0
alarm(60)   = 0
wait4(-1, NULL, 0, NULL)= 9514
wait4(-1, NULL, 0, NULL)= 9519
wait4(-1, NULL, 0, NULL)= 9521
wait4(-1, NULL, 0, NULL)= 9522
wait4(-1, NULL, 0, NULL)= 9512
--- SIGCHLD (Child exited) @ 0 (0) ---
sigreturn() = ? (mask now [])
--- SIGCHLD (Child exited) @ 0 (0) ---
sigreturn() = ? (mask now [])
wait4(-1, NULL, 0, NULL)= 9510
wait4(-1, NULL, 0, NULL)= 9516
--- SIGCHLD (Child exited) @ 0 (0) ---
sigreturn() = ? (mask now [])
--- SIGCHLD (Child exited) @ 0 (0) ---
sigreturn() = ? (mask now [])
wait4(-1, NULL, 0, NULL)= 9515
wait4(-1, NULL, 0, NULL)= 9517
wait4(-1, NULL, 0, NULL)= 9524
wait4(-1, NULL, 0, NULL)= 9525
--- SIGCHLD (Child exited) @ 0 (0) ---
sigreturn() = ? (mask now [])
--- SIGCHLD (Child exited) @ 0 (0) ---
sigreturn() = ? (mask now [])
--- SIGCHLD (Child exited) @ 0 (0) ---
sigreturn() = ? (mask now [])
--- SIGCHLD (Child exited) @ 0 (0) ---
sigreturn() = ? (mask now [])
wait4(-1, NULL, 0, NULL)= 9511
wait4(-1, NULL, 0, NULL)= 9513
wait4(-1, NULL, 0, NULL)= 9518
wait4(-1, NULL, 0, NULL)= 9523
wait4(-1, NULL, 0, NULL)= -1 ECHILD (No child processes)
rt_sigaction(SIGALRM, {0x8066080, [ALRM], SA_RESTART}, {0x8065920, [ALRM], 
SA_RESTART}, 8) = 0 stat64(/tmp/opensips_fifo, {st_mode=S_IFIFO|0660, 
st_size=0, ...}) = 0
unlink(/tmp/opensips_fifo)= 0
munmap(0xaed25000, 134217728)   = 0
unlink(/var/run/opensips/opensips.pid) = 0
alarm(0)= 60
rt_sigaction(SIGALRM, {SIG_IGN}, {0x8066080, [ALRM], SA_RESTART}, 8) = 0
exit_group(0)   = ?
Process 9509 detached


--

Comment By: Alex Massover (cupotka2008)
Date: 2010-01-21 20:38

Message:
Hi!

I use fifo.
Is there any intelligent way to recognize which process do FIFO? Or only
stracing all of them?

(On Sunday I back to work and will bring the strace.)

BR,
Alex.

--

Comment By: Bogdan-Andrei Iancu (bogdan_iancu)
Date: 2010-01-21 19:51

Message:
Hi Alex,

The strace of the main proc is irrelevant here - what is important is the
bt or strace of the FIFO/xmlrpc process. BTW, what MI backend do you use ?

Regards,
Bogdan

--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detailatid=1086410aid=2936343group_id=232389

___
Devel mailing list
Devel@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/devel


Re: [OpenSIPS-Devel] New contribution, ISN lookup in ENUM module

2010-01-21 Thread Michael Schloh von Bennewitz

Hello Bogdan,

An jeu., janv 21, 2010, Bogdan-Andrei Iancu schrieb:
Michael Schloh von Bennewitz wrote:
 I see from http://www.opensips.org/Development/Development that the
 ENUM module is 'commonly maintained.' Whoever has commit authority
 might like to take a look at the new ISN lookup integration that
 we are using with freenum.org and DNS delegation of our ITAD:

Thanks for your contribution - I will take a quick look over the
patch to see if everything is ok and I will upload it on SVN. BTW,
are you interested in activly maintaining that code? I can grant
you SVN access for the enum part.

That's good, I'm glad if the ISN code gets in. I'll maintain the
ENUM module. If your SVN repository authenticates over SSH, then
here's my key:

  http://michael.schloh.com/download/msvb-ssh.txt

Regards,
Michael

-- 
Michael Schloh von Bennewitz
http://michael.schloh.com/

___
Devel mailing list
Devel@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/devel


[OpenSIPS-Devel] [ opensips-Bugs-2936843 ] db_check_from fails if From header contains double quotes.

2010-01-21 Thread SourceForge.net
Bugs item #2936843, was opened at 2010-01-21 22:22
Message generated for change (Tracker Item Submitted) made by seadweller
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detailatid=1086410aid=2936843group_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.6.x
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: seadweller (seadweller)
Assigned to: Nobody/Anonymous (nobody)
Summary: db_check_from fails if From header contains double quotes.

Initial Comment:
Running OpenSIPS 1.6.1 with uri_db module.  If db_check_from receives a From 
header containing a double quoted value, it fails even if the from username is 
valid.  An example From header would be as such:

From: Test User sip:testu...@10.1.1.1;tag=as4b4ca259 

Client was reporting a 403 Forbidden.  When I duplicated this From header using 
an IAX client through Asterisk, I too received the 403.  When I removed the 
extra set of quotes, db_check_from returned properly.

--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detailatid=1086410aid=2936843group_id=232389

___
Devel mailing list
Devel@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/devel