From noreply at sourceforge.net  Sun Nov  1 16:36:02 2009
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun, 01 Nov 2009 15:36:02 +0000
Subject: [OpenSIPS-Devel] [ opensips-Patches-2867994 ] Non-blocking AAA
	Accounting
Message-ID: <E1N4cTK-0004y8-9U@155xhf1.ch3.sourceforge.com>

Patches item #2867994, was opened at 2009-09-27 11:34
Message generated for change (Settings changed) made by cupotka2008
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086412&aid=2867994&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.6.x
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Alex Massover (cupotka2008)
>Assigned to: Irina-Maria Stanescu (ironmissy)
Summary: Non-blocking AAA Accounting

Initial Comment:
Hi!

I know that OpenSIPS moves to asynchronous processing, but meanwhile I did this patch for me to make Radius accounting request non-blocking (anyway they return nothing).
The patch is against 1.5.3, but if you like it I'll prepare the same against the trunk (1.6).

----------------------------------------------------------------------

Comment By: Alex Massover (cupotka2008)
Date: 2009-10-19 11:23

Message:
Added a full patch against 1.6:
- aaa accounting requests run in detached thread
- AAA API extended with log_aaa_message() function, it supposed to created
a well formatted string from aaa_message. The idea is to provide
comprehensive log for failed accounting request.

----------------------------------------------------------------------

Comment By: Alex Massover (cupotka2008)
Date: 2009-10-19 11:14

Message:
Added a full patch agains 1.6:


----------------------------------------------------------------------

Comment By: Alex Massover (cupotka2008)
Date: 2009-10-01 10:26

Message:
The acc module needs to be linked with -lrt

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086412&aid=2867994&group_id=232389


From noreply at sourceforge.net  Mon Nov  2 12:47:07 2009
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 02 Nov 2009 11:47:07 +0000
Subject: [OpenSIPS-Devel] [ opensips-Bugs-2890649 ] dispatcher core dumps if
	all weights eq 0
Message-ID: <E1N4vNL-00082U-3E@565xhf1.ch3.sourceforge.com>

Bugs item #2890649, was opened at 2009-11-02 12:47
Message generated for change (Tracker Item Submitted) made by ppierscionek
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=2890649&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: None
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Urtho (ppierscionek)
Assigned to: Nobody/Anonymous (nobody)
Summary: dispatcher core dumps if all weights eq 0

Initial Comment:
not that it is a really big problem but I tried adding dispatcher entries with weights set to zero and started getting core dumps :)

Attached is a patch to correct for this.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=2890649&group_id=232389


From noreply at sourceforge.net  Mon Nov  2 12:48:06 2009
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 02 Nov 2009 11:48:06 +0000
Subject: [OpenSIPS-Devel] [ opensips-Bugs-2890649 ] dispatcher core dumps if
	all weights eq 0
Message-ID: <E1N4vOI-0006YV-7W@665xhf1.ch3.sourceforge.com>

Bugs item #2890649, was opened at 2009-11-02 12:47
Message generated for change (Settings changed) made by ppierscionek
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=2890649&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: None
Group: None
Status: Open
Resolution: None
>Priority: 1
Private: No
Submitted By: Urtho (ppierscionek)
Assigned to: Nobody/Anonymous (nobody)
Summary: dispatcher core dumps if all weights eq 0

Initial Comment:
not that it is a really big problem but I tried adding dispatcher entries with weights set to zero and started getting core dumps :)

Attached is a patch to correct for this.

----------------------------------------------------------------------

>Comment By: Urtho (ppierscionek)
Date: 2009-11-02 12:48

Message:
lowered the priority on this.

Urtho

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=2890649&group_id=232389


From noreply at sourceforge.net  Mon Nov  2 12:49:37 2009
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 02 Nov 2009 11:49:37 +0000
Subject: [OpenSIPS-Devel] [ opensips-Bugs-2890652 ] dispatcher addgw does
	not work in 1.6
Message-ID: <E1N4vPl-0003sT-D3@d45xhf1.ch3.sourceforge.com>

Bugs item #2890652, was opened at 2009-11-02 12:49
Message generated for change (Tracker Item Submitted) made by ppierscionek
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=2890652&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.6.x
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Urtho (ppierscionek)
Assigned to: Nobody/Anonymous (nobody)
Summary: dispatcher addgw does not work in 1.6

Initial Comment:
opensipctl dispatcher addgw adds entries to SQL that are not parsable by current dispatcher module.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=2890652&group_id=232389


From noreply at sourceforge.net  Mon Nov  2 12:50:08 2009
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 02 Nov 2009 11:50:08 +0000
Subject: [OpenSIPS-Devel] [ opensips-Bugs-2890649 ] dispatcher core dumps if
	all weights eq 0
Message-ID: <E1N4vQG-0004ce-9W@3bkjzd1.ch3.sourceforge.com>

Bugs item #2890649, was opened at 2009-11-02 12:47
Message generated for change (Settings changed) made by ppierscionek
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=2890649&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.6.x
Status: Open
Resolution: None
Priority: 1
Private: No
Submitted By: Urtho (ppierscionek)
Assigned to: Nobody/Anonymous (nobody)
Summary: dispatcher core dumps if all weights eq 0

Initial Comment:
not that it is a really big problem but I tried adding dispatcher entries with weights set to zero and started getting core dumps :)

Attached is a patch to correct for this.

----------------------------------------------------------------------

Comment By: Urtho (ppierscionek)
Date: 2009-11-02 12:48

Message:
lowered the priority on this.

Urtho

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=2890649&group_id=232389


From noreply at sourceforge.net  Mon Nov  2 12:54:29 2009
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 02 Nov 2009 11:54:29 +0000
Subject: [OpenSIPS-Devel] [ opensips-Bugs-2890657 ] timer_route cannot use
	memcached
Message-ID: <E1N4vUT-0007vW-7f@155xhf1.ch3.sourceforge.com>

Bugs item #2890657, was opened at 2009-11-02 12:54
Message generated for change (Tracker Item Submitted) made by ppierscionek
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=2890657&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.6.x
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Urtho (ppierscionek)
Assigned to: Nobody/Anonymous (nobody)
Summary: timer_route cannot use memcached 

Initial Comment:
using cache_store with memcached backend is not possible within timer_route:

ERROR:memcached:wrap_memcached_insert: Failed to insert: NO SERVERS DEFINED 


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=2890657&group_id=232389


From anca at opensips.org  Mon Nov  2 15:08:05 2009
From: anca at opensips.org (Anca Vamanu)
Date: Mon, 02 Nov 2009 14:08:05 +0000
Subject: [OpenSIPS-Devel] SF.net SVN: opensips:[6315] trunk/timer.c
Message-ID: <E1N4xZl-0001VB-Qh@d5vjzd1.ch3.sourceforge.com>

Revision: 6315
          http://opensips.svn.sourceforge.net/opensips/?rev=6315&view=rev
Author:   anca_vamanu
Date:     2009-11-02 14:08:02 +0000 (Mon, 02 Nov 2009)

Log Message:
-----------
- fixed bug: not calling child_init for timer route process ( bug #2890657)

Modified Paths:
--------------
    trunk/timer.c


This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site.


From noreply at sourceforge.net  Mon Nov  2 15:14:54 2009
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 02 Nov 2009 14:14:54 +0000
Subject: [OpenSIPS-Devel] [ opensips-Bugs-2890657 ] timer_route cannot use
	memcached
Message-ID: <E1N4xgM-00052U-4p@3bkjzd1.ch3.sourceforge.com>

Bugs item #2890657, was opened at 2009-11-02 13:54
Message generated for change (Settings changed) made by anca_vamanu
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=2890657&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.6.x
>Status: Closed
>Resolution: Fixed
Priority: 5
Private: No
Submitted By: Urtho (ppierscionek)
Assigned to: Nobody/Anonymous (nobody)
Summary: timer_route cannot use memcached 

Initial Comment:
using cache_store with memcached backend is not possible within timer_route:

ERROR:memcached:wrap_memcached_insert: Failed to insert: NO SERVERS DEFINED 


----------------------------------------------------------------------

>Comment By: Anca Vamanu (anca_vamanu)
Date: 2009-11-02 16:14

Message:
Hi Urtho,

Thank you for the report. There was an error in the timer route
implementation and child_init functions were not called for that timer
process. It is fixed now both in trunk and in 1.6 branch. Please update
from svn.

Regards,
Anca

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=2890657&group_id=232389


From anca at opensips.org  Mon Nov  2 15:15:09 2009
From: anca at opensips.org (Anca Vamanu)
Date: Mon, 02 Nov 2009 14:15:09 +0000
Subject: [OpenSIPS-Devel] SF.net SVN: opensips:[6316] branches/1.6/timer.c
Message-ID: <E1N4xgb-0001dk-BB@d5vjzd1.ch3.sourceforge.com>

Revision: 6316
          http://opensips.svn.sourceforge.net/opensips/?rev=6316&view=rev
Author:   anca_vamanu
Date:     2009-11-02 14:15:08 +0000 (Mon, 02 Nov 2009)

Log Message:
-----------
- fixed bug: not calling child_init for timer route process ( bug #2890657)

Modified Paths:
--------------
    branches/1.6/timer.c


This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site.


From noreply at sourceforge.net  Mon Nov  2 21:09:53 2009
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 02 Nov 2009 20:09:53 +0000
Subject: [OpenSIPS-Devel] [ opensips-Bugs-2890915 ] db_virtual no DB
	connection available if pool member lost
Message-ID: <E1N53Dt-0006H9-AX@3bkjzd1.ch3.sourceforge.com>

Bugs item #2890915, was opened at 2009-11-02 15:09
Message generated for change (Tracker Item Submitted) made by lucifuge
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=2890915&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.6.x
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Daryl G. Jurbala (lucifuge)
Assigned to: Nobody/Anonymous (nobody)
Summary: db_virtual no DB connection available if pool member lost

Initial Comment:
This is easily duplicated on 1.6.0 with postgres.  I have a pool of 5 pgsql servers that I point at for avpops, auth_db, and uri.  If any one of them becomes unavailable, I can no longer do anything with the db_virtual pool (registrations can not complete, etc.) and must remove the problem db server and restart OpenSIPS.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=2890915&group_id=232389


From stuart at myphones.com  Tue Nov  3 15:28:10 2009
From: stuart at myphones.com (Stuart Marsden)
Date: Tue, 03 Nov 2009 14:28:10 +0000
Subject: [OpenSIPS-Devel] Conntrack  - No buffer space available
Message-ID: <4AF03DFA.2050806@myphones.com>

 Hi

any clues on this? - failed once on one Dell 1950 server (Centos 5)  
running only after a few days - google the conntrack error - people are 
talking about bios and nic card upgrades

media-relay[6806]: delete conntrack - session 
[59CD8D35-C79A11DE-BCDADE8E-2ED52ADF at 88.215.56.205]
 media-relay[6806]: Traceback (most recent call last):
 media-relay[6806]:   File 
"/usr/local/lib/python2.6/site-packages/twisted/python/log.py", line 84, 
in callWithLogger
 media-relay[6806]:     return callWithContext({"system": lp}, func, 
*args, **kw)
 media-relay[6806]:   File 
"/usr/local/lib/python2.6/site-packages/twisted/python/log.py", line 69, 
in callWithContext
 media-relay[6806]:     return context.call({ILogContext: newCtx}, func, 
*args, **kw)
 media-relay[6806]:   File 
"/usr/local/lib/python2.6/site-packages/twisted/python/context.py", line 
59, in callWithContext
 media-relay[6806]:     return 
self.currentContext().callWithContext(ctx, func, *args, **kw)
 media-relay[6806]:   File 
"/usr/local/lib/python2.6/site-packages/twisted/python/context.py", line 
37, in callWithContext
 media-relay[6806]:     return func(*args,**kw)
 media-relay[6806]: --- <exception caught here> ---
 media-relay[6806]:   File 
"/usr/local/lib/python2.6/site-packages/twisted/internet/epollreactor.py", 
line 231, in _doReadOrWrite
 media-relay[6806]:     why = selectable.doRead()
 media-relay[6806]:   File 
"/usr/local/mediaproxy/mediaproxy/mediacontrol.py", line 732, in doRead
 media-relay[6806]:     stream = self.watcher.read()
 media-relay[6806]: mediaproxy.interfaces.system._conntrack.Error: No 
buffer space available

Stuart



From ironmissy at gmail.com  Tue Nov  3 16:28:03 2009
From: ironmissy at gmail.com (Irina-Maria Stanescu)
Date: Tue, 03 Nov 2009 15:28:03 +0000
Subject: [OpenSIPS-Devel] SF.net SVN: opensips:[6317]
	trunk/modules/aaa_radius/aaa_radius.c
Message-ID: <E1N5LIh-0005aM-D1@74yxhf1.ch3.sourceforge.com>

Revision: 6317
          http://opensips.svn.sourceforge.net/opensips/?rev=6317&view=rev
Author:   ironmissy
Date:     2009-11-03 15:28:03 +0000 (Tue, 03 Nov 2009)

Log Message:
-----------
- automatically converts strings from the sets avps into ipaddr when needed
- closes patch #2886450 submitted by Alex Massover

Modified Paths:
--------------
    trunk/modules/aaa_radius/aaa_radius.c


This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site.


From noreply at sourceforge.net  Tue Nov  3 16:29:23 2009
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue, 03 Nov 2009 15:29:23 +0000
Subject: [OpenSIPS-Devel] [ opensips-Patches-2886450 ] Sending radius ipaddr
	params with aaa_radius
Message-ID: <E1N5LJz-0002O0-HK@g45xhf1.ch3.sourceforge.com>

Patches item #2886450, was opened at 2009-10-26 15:00
Message generated for change (Settings changed) made by ironmissy
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086412&aid=2886450&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: Alex Massover (cupotka2008)
Assigned to: Irina-Maria Stanescu (ironmissy)
Summary: Sending radius ipaddr params with aaa_radius

Initial Comment:
Hi!

The problem:
______________________
Currently there's no easy way to send IP addresses via ipaddr radius parameters using aaa_radius module.
For example, Login-IP-Host is defined as ipaddr and it expects integer:
modparam("aaa_radius","sets","set1=(Login-IP-Host=$avp(i:10))")
For example if I want to pass 10.11.12.13 I need to have inside $avp(i:10)==168496141, but the most likely scenario that I have the dotted notation ip inside to opensips script.
Converting dotted notation ip to integer using avpops is too long and slow.

The solution:
_______________________________
The patch intoduces {s.ip} transformation:
$avp(s:ip)=?10.11.12.13?;
$avp(i:10)=$(avp(s:ip){s.ip})   # gives 168496141

Now I can natively send Login-IP-Host.


Another possible solution:
_______________________________
is to automatically and implicitly convert strings to int somewhere inside aaa_radius.c, for example if I do:
modparam("aaa_radius","sets","set1=(Login-IP-Host=$si)")
the module can check if Login-IP-Host is ipaddr then convert $si to int and only then to send it.

----------------------------------------------------------------------

>Comment By: Irina-Maria Stanescu (ironmissy)
Date: 2009-11-03 17:29

Message:
I tested and applied the patch.
Thanks Alex!

Regards, 
Irina Stanescu

----------------------------------------------------------------------

Comment By: Alex Massover (cupotka2008)
Date: 2009-10-27 15:00

Message:
I added a patch implementing solution #2, it will allow directly assigning
dotted notation ip variables to ipaddr radius types, like following:
modparam("aaa_radius","sets","set1=(Login-IP-Host=$si)")

The patch is also more clean than the first one, so I remove the first
one.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086412&aid=2886450&group_id=232389


From ironmissy at gmail.com  Tue Nov  3 16:56:54 2009
From: ironmissy at gmail.com (Irina-Maria Stanescu)
Date: Tue, 03 Nov 2009 15:56:54 +0000
Subject: [OpenSIPS-Devel] SF.net SVN: opensips:[6318]
	branches/1.6/modules/aaa_radius/aaa_radius.c
Message-ID: <E1N5Lkc-00068k-Ci@74yxhf1.ch3.sourceforge.com>

Revision: 6318
          http://opensips.svn.sourceforge.net/opensips/?rev=6318&view=rev
Author:   ironmissy
Date:     2009-11-03 15:56:54 +0000 (Tue, 03 Nov 2009)

Log Message:
-----------
backport from trunk (rev 6317)
- automatically converts strings from the sets avps into ipaddr when needed
- closes patch #2886450 submitted by Alex Massover

Revision Links:
--------------
    http://opensips.svn.sourceforge.net/opensips/?rev=6317&view=rev

Modified Paths:
--------------
    branches/1.6/modules/aaa_radius/aaa_radius.c


This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site.


From bogdan at voice-system.ro  Wed Nov  4 09:55:35 2009
From: bogdan at voice-system.ro (Bogdan-Andrei Iancu)
Date: Wed, 04 Nov 2009 08:55:35 +0000
Subject: [OpenSIPS-Devel] SF.net SVN: opensips:[6319]
	trunk/modules/mi_xmlrpc/mi_xmlrpc.c
Message-ID: <E1N5beR-0003dR-M8@dn4whf1.ch3.sourceforge.com>

Revision: 6319
          http://opensips.svn.sourceforge.net/opensips/?rev=6319&view=rev
Author:   bogdan_iancu
Date:     2009-11-04 08:55:35 +0000 (Wed, 04 Nov 2009)

Log Message:
-----------
- on some systems (following the System V specs), there is different SIGCLD signal, while on POSIX like systems you have SIGCHLD.......The difference is that the SIGCLD must be rearmed, while SIGCHLD not. On System V  the SIGCHLD is simply defined as SIGCLD...so you may end up with some confusion....
 -> if SIGCLD is defined do explicit re-arming of SIGCLD handler.

Modified Paths:
--------------
    trunk/modules/mi_xmlrpc/mi_xmlrpc.c


This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site.


From bogdan at voice-system.ro  Wed Nov  4 09:56:55 2009
From: bogdan at voice-system.ro (Bogdan-Andrei Iancu)
Date: Wed, 04 Nov 2009 08:56:55 +0000
Subject: [OpenSIPS-Devel] SF.net SVN: opensips:[6320]
	branches/1.5/modules/mi_xmlrpc/mi_xmlrpc.c
Message-ID: <E1N5bfj-0003fZ-K0@dn4whf1.ch3.sourceforge.com>

Revision: 6320
          http://opensips.svn.sourceforge.net/opensips/?rev=6320&view=rev
Author:   bogdan_iancu
Date:     2009-11-04 08:56:55 +0000 (Wed, 04 Nov 2009)

Log Message:
-----------
backport from trunk #6319
- on some systems (following the System V specs), there is different SIGCLD signal, while on POSIX like systems you have SIGCHLD.......The difference is that the SIGCLD must be rearmed, while SIGCHLD not. On System V  the SIGCHLD is simply defined as SIGCLD...so you may end up with some confusion....
 -> if SIGCLD is defined do explicit re-arming of SIGCLD handler.

Modified Paths:
--------------
    branches/1.5/modules/mi_xmlrpc/mi_xmlrpc.c


This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site.


From bogdan at voice-system.ro  Wed Nov  4 09:57:53 2009
From: bogdan at voice-system.ro (Bogdan-Andrei Iancu)
Date: Wed, 04 Nov 2009 08:57:53 +0000
Subject: [OpenSIPS-Devel] SF.net SVN: opensips:[6321]
	branches/1.6/modules/mi_xmlrpc/mi_xmlrpc.c
Message-ID: <E1N5bgf-0003hP-42@dn4whf1.ch3.sourceforge.com>

Revision: 6321
          http://opensips.svn.sourceforge.net/opensips/?rev=6321&view=rev
Author:   bogdan_iancu
Date:     2009-11-04 08:57:52 +0000 (Wed, 04 Nov 2009)

Log Message:
-----------
backport from trunk #6319
- on some systems (following the System V specs), there is different SIGCLD signal, while on POSIX like systems you have SIGCHLD.......The difference is that th
e SIGCLD must be rearmed, while SIGCHLD not. On System V  the SIGCHLD is simply 
defined as SIGCLD...so you may end up with some confusion....
 -> if SIGCLD is defined do explicit re-arming of SIGCLD handler

Modified Paths:
--------------
    branches/1.6/modules/mi_xmlrpc/mi_xmlrpc.c


This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site.


From noreply at sourceforge.net  Wed Nov  4 10:02:32 2009
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed, 04 Nov 2009 09:02:32 +0000
Subject: [OpenSIPS-Devel] [ opensips-Bugs-2890915 ] db_virtual no DB
	connection available if pool member lost
Message-ID: <E1N5blA-0001NB-0K@565xhf1.ch3.sourceforge.com>

Bugs item #2890915, was opened at 2009-11-02 22:09
Message generated for change (Settings changed) made by bogdan_iancu
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=2890915&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.6.x
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Daryl G. Jurbala (lucifuge)
>Assigned to: Razvan (rpistolea)
Summary: db_virtual no DB connection available if pool member lost

Initial Comment:
This is easily duplicated on 1.6.0 with postgres.  I have a pool of 5 pgsql servers that I point at for avpops, auth_db, and uri.  If any one of them becomes unavailable, I can no longer do anything with the db_virtual pool (registrations can not complete, etc.) and must remove the problem db server and restart OpenSIPS.

----------------------------------------------------------------------

>Comment By: Bogdan-Andrei Iancu (bogdan_iancu)
Date: 2009-11-04 11:02

Message:
Hi Daryl,

what mode do you use for the virtual connection - parallel, failover,
round-robin ?

Also, do you have some logs/debug during the error?

Regards,
Bogdan

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=2890915&group_id=232389


From noreply at sourceforge.net  Wed Nov  4 10:17:33 2009
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed, 04 Nov 2009 09:17:33 +0000
Subject: [OpenSIPS-Devel] [ opensips-Bugs-2889312 ] is_dlg_flag_set does not
	really checking the flag (ver1.5.3)
Message-ID: <E1N5bzh-0002FY-3o@b55xhf1.ch3.sourceforge.com>

Bugs item #2889312, was opened at 2009-10-30 11:01
Message generated for change (Comment added) made by bogdan_iancu
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=2889312&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.5.x
Status: Open
Resolution: Invalid
Priority: 5
Private: No
Submitted By: Alexey Nikolaev (iamthedeath)
Assigned to: Bogdan-Andrei Iancu (bogdan_iancu)
Summary: is_dlg_flag_set does not really checking the flag (ver1.5.3)

Initial Comment:
Hello.

I'm trying to catch the specific in-dialog request (BYE for call, that is on-hold). I try to make it with the dialog flags behavior:

route[1]
{
...
if(is_method("INVITE") && loose_route() && has_totag() && has_body("application/sdp")) {
    if(search_body("c=IN IP4 0.0.0.0")||search_body("a=sendonly")) {
        set_dlg_flag("1");
        }
    }
...
if ( is_method("BYE") && is_dlg_flag_set("1") ) {
    xlog("L_INFO, "!!! cathed FLAG !!!");
    }
...
}

When i check, how it works, i see: function is_dlg_flag_set("1") returns FALSE always. 
Then i try to make some check for how it works, and write next construction in request route:

create_dialog();
set_dlg_flag("1");
if ( is_dlg_flag_set("1") ) {
            xlog("L_INFO", "!!! SFLAG setup !!!");
}

And this message does not appear anytime in log. Other messages with L_INFO i can see properly, It seems that dialog flags behavior does not works fine.

Some configuration lines about dialog module:
loadmodule "dialog.so"
modparam("dialog", "dlg_flag", 3)
modparam("dialog", "bye_on_timeout_flag", 4)
modparam("dialog", "profiles_with_value", "termination")
modparam("dialog", "table_name", "dialog")
modparam("dialog", "default_timeout", 3600)
modparam("dialog", "dlg_extra_hdrs", "Hint: internal dialog timed out\r\n")

[root at sip-dev-an ~]# opensips -V
version: opensips 1.5.3-notls (x86_64/linux)
flags: STATS: Off, USE_IPV6, USE_TCP, DISABLE_NAGLE, USE_MCAST, SHM_MEM, SHM_MMAP, PKG_MALLOC, F_MALLOC, FAST_LOCK-ADAPTIVE_WAIT
ADAPTIVE_WAIT_LOOPS=1024, MAX_RECV_BUFFER_SIZE 262144, MAX_LISTEN 16, MAX_URI_SIZE 1024, BUF_SIZE 65535
poll method support: poll, epoll_lt, epoll_et, sigio_rt, select.
svnrevision: 4:784M
@(#) $Id: main.c 5887 2009-07-16 11:47:46Z bogdan_iancu $
main.c compiled on 08:19:11 Oct 23 2009 with gcc 4.1.2


Is this my misunderstanding or i should report a bug?

----------------------------------------------------------------------

>Comment By: Bogdan-Andrei Iancu (bogdan_iancu)
Date: 2009-11-04 11:17

Message:
Hi Alexey,

for having the dialog flags working (setting and reading), it is a must to
have a dialog context , so you must do "dialog_create()" before

regarding the performance - of course, adding dialog awareness into
opensips brings some performance penalties - we do plan to make some tests
to try to quantify this extra load due dialog usage. Anyhow, the penalty is
there, but not something to worry about as it is pure CPU and right now to
bottleneck is in I/O ops.

Regarding your second question - for INVITE you need to do
"create_dialog()" before doing any op with dlg flags ; for BYE be sure you
do loose_route() before accessing any information regarding the dialog
context.

Regards,
Bogdan

----------------------------------------------------------------------

Comment By: Alexey Nikolaev (iamthedeath)
Date: 2009-10-30 14:59

Message:
I research the problem again.

I point that, this problem appear (dialog FLAG can not be checked) when i
do not make create_dialog in initial request. When it used in initial
invite - all works perfect. This behavior described in documentation.


So i have two questions

1. How it deal with opensips performance, when i call create_dialog() in
every INVITE msg?

2. I was thinking that dialog automatically created when the initial
request is processed. So i try to use construction:
For reINVITE:
set_dlg_flag(1);

For BYE
if ( is_method("BYE") && is_dlg_flag_set("1") ) {
xlog("L_INFO, "!!! cathed FLAG !!!");
}
But have not get positive result.

Do i need to make create_dialog() for all initial requests, for using
flags and other dialog related fuctions in NOT INITIAL requests (re-INVITE,
BYE, ACK...)?
Is dialog was not created previously (in case when i do not call
create_dialog in the initial request) when initial request was processed?

Regards.
Alexey.

----------------------------------------------------------------------

Comment By: Alexey Nikolaev (iamthedeath)
Date: 2009-10-30 13:41

Message:
Hi, Bogdan.

Sorry, I can not check with 1.6.0 because 1.5.3 is used for production
with some custom modules. Upgrade to 1.6.0 is not possible.

However, if this make some clearence to you, i can contribute some debug
information. LOG output on debug level, or something else?

----------------------------------------------------------------------

Comment By: Bogdan-Andrei Iancu (bogdan_iancu)
Date: 2009-10-30 12:58

Message:
Hi,

I tried the the script sequence you posted (with setting and testing the
flag) and it worked in 1.6.0 (more or less the same code as in 1.5.3, for
the dialog flags) - and it did work with no problem.

Can you check also with 1.6.0 and confirm that it is working ?

Regards,
Bogdan

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=2889312&group_id=232389


From noreply at sourceforge.net  Wed Nov  4 10:28:00 2009
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed, 04 Nov 2009 09:28:00 +0000
Subject: [OpenSIPS-Devel] [ opensips-Bugs-2890649 ] dispatcher core dumps if
	all weights eq 0
Message-ID: <E1N5c9o-0005OA-MA@1bkjzd1.ch3.sourceforge.com>

Bugs item #2890649, was opened at 2009-11-02 13:47
Message generated for change (Settings changed) made by bogdan_iancu
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=2890649&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.6.x
Status: Open
>Resolution: Accepted
>Priority: 5
Private: No
Submitted By: Urtho (ppierscionek)
>Assigned to: Bogdan-Andrei Iancu (bogdan_iancu)
Summary: dispatcher core dumps if all weights eq 0

Initial Comment:
not that it is a really big problem but I tried adding dispatcher entries with weights set to zero and started getting core dumps :)

Attached is a patch to correct for this.

----------------------------------------------------------------------

>Comment By: Bogdan-Andrei Iancu (bogdan_iancu)
Date: 2009-11-04 11:27

Message:
Thanks Urtho - found the cause, working on a fix right now.

Regards,
Bogdan

----------------------------------------------------------------------

Comment By: Urtho (ppierscionek)
Date: 2009-11-02 13:48

Message:
lowered the priority on this.

Urtho

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=2890649&group_id=232389


From bogdan at voice-system.ro  Wed Nov  4 10:45:17 2009
From: bogdan at voice-system.ro (Bogdan-Andrei Iancu)
Date: Wed, 04 Nov 2009 09:45:17 +0000
Subject: [OpenSIPS-Devel] SF.net SVN: opensips:[6322]
	trunk/modules/dispatcher/dispatch.c
Message-ID: <E1N5cQX-0006T5-LF@d5vjzd1.ch3.sourceforge.com>

Revision: 6322
          http://opensips.svn.sourceforge.net/opensips/?rev=6322&view=rev
Author:   bogdan_iancu
Date:     2009-11-04 09:45:17 +0000 (Wed, 04 Nov 2009)

Log Message:
-----------
- fixed crash when the all the weights are zero.
  
  Closes bug ID 2890649.
  Reported by Urtho.

Modified Paths:
--------------
    trunk/modules/dispatcher/dispatch.c


This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site.


From noreply at sourceforge.net  Wed Nov  4 10:46:28 2009
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed, 04 Nov 2009 09:46:28 +0000
Subject: [OpenSIPS-Devel] [ opensips-Bugs-2890649 ] dispatcher core dumps if
	all weights eq 0
Message-ID: <E1N5cRg-0008OW-NV@d55xhf1.ch3.sourceforge.com>

Bugs item #2890649, was opened at 2009-11-02 13:47
Message generated for change (Settings changed) made by bogdan_iancu
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=2890649&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.6.x
Status: Open
>Resolution: Fixed
Priority: 5
Private: No
Submitted By: Urtho (ppierscionek)
Assigned to: Bogdan-Andrei Iancu (bogdan_iancu)
Summary: dispatcher core dumps if all weights eq 0

Initial Comment:
not that it is a really big problem but I tried adding dispatcher entries with weights set to zero and started getting core dumps :)

Attached is a patch to correct for this.

----------------------------------------------------------------------

>Comment By: Bogdan-Andrei Iancu (bogdan_iancu)
Date: 2009-11-04 11:46

Message:
A fix is available on SVN trunk (rev 6322) - if you could check it and
confirm that everything is ok, it will be great and I will do the backport
to 1.6 also

Thanks and regards,
Bogdan

----------------------------------------------------------------------

Comment By: Bogdan-Andrei Iancu (bogdan_iancu)
Date: 2009-11-04 11:27

Message:
Thanks Urtho - found the cause, working on a fix right now.

Regards,
Bogdan

----------------------------------------------------------------------

Comment By: Urtho (ppierscionek)
Date: 2009-11-02 13:48

Message:
lowered the priority on this.

Urtho

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=2890649&group_id=232389


From noreply at sourceforge.net  Wed Nov  4 11:18:22 2009
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed, 04 Nov 2009 10:18:22 +0000
Subject: [OpenSIPS-Devel] [ opensips-Bugs-2890652 ] dispatcher addgw does
	not work in 1.6
Message-ID: <E1N5cwY-0001jN-M9@d45xhf1.ch3.sourceforge.com>

Bugs item #2890652, was opened at 2009-11-02 13:49
Message generated for change (Settings changed) made by bogdan_iancu
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=2890652&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.6.x
Status: Open
>Resolution: Invalid
Priority: 5
Private: No
Submitted By: Urtho (ppierscionek)
>Assigned to: Bogdan-Andrei Iancu (bogdan_iancu)
Summary: dispatcher addgw does not work in 1.6

Initial Comment:
opensipctl dispatcher addgw adds entries to SQL that are not parsable by current dispatcher module.

----------------------------------------------------------------------

>Comment By: Bogdan-Andrei Iancu (bogdan_iancu)
Date: 2009-11-04 12:18

Message:
Hi Urtho,

Could you be more specific on the issue ? what is the error ?What is the
command line ?
I tried adding 2 GW and the reload was with no problem.

Regards,
Bogdan

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=2890652&group_id=232389


From bogdan at voice-system.ro  Wed Nov  4 15:49:12 2009
From: bogdan at voice-system.ro (Bogdan-Andrei Iancu)
Date: Wed, 04 Nov 2009 14:49:12 +0000
Subject: [OpenSIPS-Devel] SF.net SVN: opensips:[6323]
	trunk/modules/nathelper/nathelper.c
Message-ID: <E1N5hAe-0008Bn-5z@3kljzd1.ch3.sourceforge.com>

Revision: 6323
          http://opensips.svn.sourceforge.net/opensips/?rev=6323&view=rev
Author:   bogdan_iancu
Date:     2009-11-04 14:49:11 +0000 (Wed, 04 Nov 2009)

Log Message:
-----------
- fixed bug in calculating the the length of the table name.

Modified Paths:
--------------
    trunk/modules/nathelper/nathelper.c


This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site.


From bogdan at voice-system.ro  Wed Nov  4 15:53:43 2009
From: bogdan at voice-system.ro (Bogdan-Andrei Iancu)
Date: Wed, 04 Nov 2009 14:53:43 +0000
Subject: [OpenSIPS-Devel] SF.net SVN: opensips:[6325]
	branches/1.5/modules/nathelper/nathelper.c
Message-ID: <E1N5hF1-0008Hk-K5@3kljzd1.ch3.sourceforge.com>

Revision: 6325
          http://opensips.svn.sourceforge.net/opensips/?rev=6325&view=rev
Author:   bogdan_iancu
Date:     2009-11-04 14:53:43 +0000 (Wed, 04 Nov 2009)

Log Message:
-----------
backport from trunk (rev #6323):
- fixed bug in calculating the length of the table name

Revision Links:
--------------
    http://opensips.svn.sourceforge.net/opensips/?rev=6323&view=rev

Modified Paths:
--------------
    branches/1.5/modules/nathelper/nathelper.c


This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site.


From bogdan at voice-system.ro  Wed Nov  4 15:53:42 2009
From: bogdan at voice-system.ro (Bogdan-Andrei Iancu)
Date: Wed, 04 Nov 2009 14:53:42 +0000
Subject: [OpenSIPS-Devel] SF.net SVN: opensips:[6324]
	branches/1.6/modules/nathelper/nathelper.c
Message-ID: <E1N5hF0-0008HX-12@3kljzd1.ch3.sourceforge.com>

Revision: 6324
          http://opensips.svn.sourceforge.net/opensips/?rev=6324&view=rev
Author:   bogdan_iancu
Date:     2009-11-04 14:53:41 +0000 (Wed, 04 Nov 2009)

Log Message:
-----------
backport from trunk (rev #6323):
- fixed bug in calculating the length of the table name 

Revision Links:
--------------
    http://opensips.svn.sourceforge.net/opensips/?rev=6323&view=rev

Modified Paths:
--------------
    branches/1.6/modules/nathelper/nathelper.c


This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site.


From andreidragus at yahoo.com  Wed Nov  4 16:24:28 2009
From: andreidragus at yahoo.com (Andrei Dragus)
Date: Wed, 04 Nov 2009 15:24:28 +0000
Subject: [OpenSIPS-Devel] SF.net SVN: opensips:[6326] trunk
Message-ID: <E1N5him-0003C5-GI@74yxhf1.ch3.sourceforge.com>

Revision: 6326
          http://opensips.svn.sourceforge.net/opensips/?rev=6326&view=rev
Author:   andreidragus
Date:     2009-11-04 15:24:28 +0000 (Wed, 04 Nov 2009)

Log Message:
-----------
New versions of map, used for usrloc module.

Modified Paths:
--------------
    trunk/map.c
    trunk/map.h


This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site.


From andreidragus at yahoo.com  Wed Nov  4 16:33:38 2009
From: andreidragus at yahoo.com (Andrei Dragus)
Date: Wed, 04 Nov 2009 15:33:38 +0000
Subject: [OpenSIPS-Devel] SF.net SVN: opensips:[6327] trunk/map.c
Message-ID: <E1N5hre-0003LK-59@74yxhf1.ch3.sourceforge.com>

Revision: 6327
          http://opensips.svn.sourceforge.net/opensips/?rev=6327&view=rev
Author:   andreidragus
Date:     2009-11-04 15:33:37 +0000 (Wed, 04 Nov 2009)

Log Message:
-----------
Fixed warnings

Modified Paths:
--------------
    trunk/map.c


This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site.


From andreidragus at yahoo.com  Wed Nov  4 16:36:39 2009
From: andreidragus at yahoo.com (Andrei Dragus)
Date: Wed, 04 Nov 2009 15:36:39 +0000
Subject: [OpenSIPS-Devel] SF.net SVN: opensips:[6328] trunk/modules/usrloc
Message-ID: <E1N5huZ-0003On-7q@74yxhf1.ch3.sourceforge.com>

Revision: 6328
          http://opensips.svn.sourceforge.net/opensips/?rev=6328&view=rev
Author:   andreidragus
Date:     2009-11-04 15:36:38 +0000 (Wed, 04 Nov 2009)

Log Message:
-----------
New version of the usrloc module

Modified Paths:
--------------
    trunk/modules/usrloc/dlist.c
    trunk/modules/usrloc/hslot.c
    trunk/modules/usrloc/hslot.h
    trunk/modules/usrloc/udomain.c
    trunk/modules/usrloc/udomain.h
    trunk/modules/usrloc/ul_mi.c
    trunk/modules/usrloc/urecord.h
    trunk/modules/usrloc/usrloc.h


This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site.


From dan at ag-projects.com  Thu Nov  5 10:38:43 2009
From: dan at ag-projects.com (Dan Pascu)
Date: Thu, 5 Nov 2009 11:38:43 +0200
Subject: [OpenSIPS-Devel] Conntrack  - No buffer space available
In-Reply-To: <4AF03DFA.2050806@myphones.com>
References: <4AF03DFA.2050806@myphones.com>
Message-ID: <DEB6A09B-102B-4EA6-A7BC-B7578708330C@ag-projects.com>

I haven't seen this error till now. I suspect it may have something to  
do with you having too many conntrack rules and when it tries to read  
them it has not enough space to store them in the memory buffer. How  
many concurrent media sessions does the relay have when this happens?

On 3 Nov 2009, at 16:28, Stuart Marsden wrote:

> Hi
>
> any clues on this? - failed once on one Dell 1950 server (Centos 5)
> running only after a few days - google the conntrack error - people  
> are
> talking about bios and nic card upgrades
>
> media-relay[6806]: delete conntrack - session
> [59CD8D35-C79A11DE-BCDADE8E-2ED52ADF at 88.215.56.205]
> media-relay[6806]: Traceback (most recent call last):
> media-relay[6806]:   File
> "/usr/local/lib/python2.6/site-packages/twisted/python/log.py", line  
> 84,
> in callWithLogger
> media-relay[6806]:     return callWithContext({"system": lp}, func,
> *args, **kw)
> media-relay[6806]:   File
> "/usr/local/lib/python2.6/site-packages/twisted/python/log.py", line  
> 69,
> in callWithContext
> media-relay[6806]:     return context.call({ILogContext: newCtx},  
> func,
> *args, **kw)
> media-relay[6806]:   File
> "/usr/local/lib/python2.6/site-packages/twisted/python/context.py",  
> line
> 59, in callWithContext
> media-relay[6806]:     return
> self.currentContext().callWithContext(ctx, func, *args, **kw)
> media-relay[6806]:   File
> "/usr/local/lib/python2.6/site-packages/twisted/python/context.py",  
> line
> 37, in callWithContext
> media-relay[6806]:     return func(*args,**kw)
> media-relay[6806]: --- <exception caught here> ---
> media-relay[6806]:   File
> "/usr/local/lib/python2.6/site-packages/twisted/internet/ 
> epollreactor.py",
> line 231, in _doReadOrWrite
> media-relay[6806]:     why = selectable.doRead()
> media-relay[6806]:   File
> "/usr/local/mediaproxy/mediaproxy/mediacontrol.py", line 732, in  
> doRead
> media-relay[6806]:     stream = self.watcher.read()
> media-relay[6806]: mediaproxy.interfaces.system._conntrack.Error: No
> buffer space available
>
> Stuart
>
>
> _______________________________________________
> Devel mailing list
> Devel at lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/devel


--
Dan





From noreply at sourceforge.net  Thu Nov  5 15:28:28 2009
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 05 Nov 2009 14:28:28 +0000
Subject: [OpenSIPS-Devel] [ opensips-Bugs-2892636 ] Opensips crash
Message-ID: <E1N63K8-0005Xu-Kd@g45xhf1.ch3.sourceforge.com>

Bugs item #2892636, was opened at 2009-11-05 17:28
Message generated for change (Tracker Item Submitted) made by kuznetsov82
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=2892636&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.5.x
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Vladimir Kuznetsov (kuznetsov82)
Assigned to: Nobody/Anonymous (nobody)
Summary: Opensips crash

Initial Comment:
server version 1.5.3
callstack:
#0  search_shtable (htable=0x2adf94a1e2e0, callid=
      {s = 0x74212e "55525-14278 at 10.2.176.220\r\nCSeq: 3 SUBSCRIBE\r\nContact: sip:andrey11 at 10.2.176.220:5061\r\nMax-Forwards: 68\r\nExpires: 5\r\nEvent: presence\r\nSubject: Performance Test\r\nContent-Type: application/sdp\r\nContent-L"..., len = 24}, to_tag=
      {s = 0x2adf9d2b118e "70a5b204a9409a36294d5c67c6ad5ef1-2fc8\r\nCall-ID: 55525-14278 at 10.2.176.220\r\nCSeq: 3 SUBSCRIBE\r\nExpires: 5\r\nContact: <sip:94.25.209.130:5060>\r\nServer: Yota voip server 1.5.3-1.2.0-800\r\nContent-Length: 0\r"..., len = 37}, from_tag=
      {s = 0x7420f0 "14278SIPpTag0055525\r\nTo: sut <sip:andrey11 at yota.ru>\r\nCall-ID: 55525-14278 at 10.2.176.220\r\nCSeq: 3 SUBSCRIBE\r\nContact: sip:andrey11 at 10.2.176.220:5061\r\nMax-Forwards: 68\r\nExpires: 5\r\nEvent: presence\r\nSubje"..., len = 19}, hash_code=1280) at hash.c:110
#1  0x00002adf913a1ab2 in update_shtable (htable=0x2adf94a1e2e0, hash_code=80, subs=0x7fff1b4271a0, type=4) at hash.c:342
#2  0x00002adf913b09dc in notify (subs=0x7fff1b4271a0, watcher_subs=0x0, n_body=0x0, force_null_body=0) at notify.c:1776
#3  0x00002adf913c3dc9 in update_subscription (msg=<value optimized out>, subs=0x7fff1b4271a0, init_req=<value optimized out>) at subscribe.c:418
#4  0x00002adf913cae4c in handle_subscribe (msg=0x7dd0a0, str1=<value optimized out>, str2=<value optimized out>) at subscribe.c:697
#5  0x000000000040ddfc in do_action (a=0x79f3c0, msg=0x7dd0a0) at action.c:962
#6  0x000000000041089e in run_action_list (a=<value optimized out>, msg=0x7dd0a0) at action.c:139
#7  0x000000000040ec40 in do_action (a=0x79f710, msg=0x7dd0a0) at action.c:706
#8  0x000000000041089e in run_action_list (a=<value optimized out>, msg=0x7dd0a0) at action.c:139
#9  0x000000000040ec40 in do_action (a=0x79fdb0, msg=0x7dd0a0) at action.c:706
#10 0x000000000041089e in run_action_list (a=<value optimized out>, msg=0x7dd0a0) at action.c:139
#11 0x000000000040fc27 in do_action (a=0x79fe80, msg=0x7dd0a0) at action.c:712
#12 0x000000000041089e in run_action_list (a=<value optimized out>, msg=0x7dd0a0) at action.c:139
#13 0x000000000040fc27 in do_action (a=0x79ff50, msg=0x7dd0a0) at action.c:712
#14 0x000000000041089e in run_action_list (a=<value optimized out>, msg=0x7dd0a0) at action.c:139
#15 0x000000000040ebac in do_action (a=0x7824c0, msg=0x7dd0a0) at action.c:119
#16 0x000000000041089e in run_action_list (a=<value optimized out>, msg=0x7dd0a0) at action.c:139
#17 0x000000000040ec40 in do_action (a=0x782590, msg=0x7dd0a0) at action.c:706
#18 0x000000000041089e in run_action_list (a=<value optimized out>, msg=0x7dd0a0) at action.c:139
#19 0x000000000040ec40 in do_action (a=0x784180, msg=0x7dd0a0) at action.c:706
#20 0x000000000041089e in run_action_list (a=<value optimized out>, msg=0x7dd0a0) at action.c:139
#21 0x0000000000410bf9 in run_top_route (a=0x773bb8, msg=0x7dd0a0) at action.c:119
#22 0x000000000044f4df in receive_msg (
    buf=0x741fe0 "SUBSCRIBE sip:94.25.209.130:5060 SIP/2.0\r\nRecord-Route: <sip:94.25.209.132;lr=on;ftag=14278SIPpTag0055525>\r\nVia: SIP/2.0/UDP 94.25.209.132;branch=z9hG4bK6236.7f93e02.0\r\nVia: SIP/2.0/UDP 10.2.176.220:5"..., len=546, rcv_info=0x7fff1b4293a0) at receive.c:165
#23 0x000000000048efce in udp_rcv_loop () at udp_server.c:449
#24 0x0000000000427a8a in main (argc=7, argv=0x7fff1b4295a8) at main.c:779



In core dump I can see that variable 's' has not valid value. 'hash_code' value is 1280. I think in some place in the code 1280-record in htable was deleted without lock in the same time with search_shtable was called. I can see only this reason for crash in this situation. I trying to resolve this bug now, but I need help from this module developer...

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=2892636&group_id=232389


From noreply at sourceforge.net  Thu Nov  5 15:48:00 2009
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 05 Nov 2009 14:48:00 +0000
Subject: [OpenSIPS-Devel] [ opensips-Bugs-2892636 ] Opensips crash
Message-ID: <E1N63d2-0001F7-99@d45xhf1.ch3.sourceforge.com>

Bugs item #2892636, was opened at 2009-11-05 17:28
Message generated for change (Comment added) made by kuznetsov82
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=2892636&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.5.x
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Vladimir Kuznetsov (kuznetsov82)
Assigned to: Nobody/Anonymous (nobody)
Summary: Opensips crash

Initial Comment:
server version 1.5.3
callstack:
#0  search_shtable (htable=0x2adf94a1e2e0, callid=
      {s = 0x74212e "55525-14278 at 10.2.176.220\r\nCSeq: 3 SUBSCRIBE\r\nContact: sip:andrey11 at 10.2.176.220:5061\r\nMax-Forwards: 68\r\nExpires: 5\r\nEvent: presence\r\nSubject: Performance Test\r\nContent-Type: application/sdp\r\nContent-L"..., len = 24}, to_tag=
      {s = 0x2adf9d2b118e "70a5b204a9409a36294d5c67c6ad5ef1-2fc8\r\nCall-ID: 55525-14278 at 10.2.176.220\r\nCSeq: 3 SUBSCRIBE\r\nExpires: 5\r\nContact: <sip:94.25.209.130:5060>\r\nServer: Yota voip server 1.5.3-1.2.0-800\r\nContent-Length: 0\r"..., len = 37}, from_tag=
      {s = 0x7420f0 "14278SIPpTag0055525\r\nTo: sut <sip:andrey11 at yota.ru>\r\nCall-ID: 55525-14278 at 10.2.176.220\r\nCSeq: 3 SUBSCRIBE\r\nContact: sip:andrey11 at 10.2.176.220:5061\r\nMax-Forwards: 68\r\nExpires: 5\r\nEvent: presence\r\nSubje"..., len = 19}, hash_code=1280) at hash.c:110
#1  0x00002adf913a1ab2 in update_shtable (htable=0x2adf94a1e2e0, hash_code=80, subs=0x7fff1b4271a0, type=4) at hash.c:342
#2  0x00002adf913b09dc in notify (subs=0x7fff1b4271a0, watcher_subs=0x0, n_body=0x0, force_null_body=0) at notify.c:1776
#3  0x00002adf913c3dc9 in update_subscription (msg=<value optimized out>, subs=0x7fff1b4271a0, init_req=<value optimized out>) at subscribe.c:418
#4  0x00002adf913cae4c in handle_subscribe (msg=0x7dd0a0, str1=<value optimized out>, str2=<value optimized out>) at subscribe.c:697
#5  0x000000000040ddfc in do_action (a=0x79f3c0, msg=0x7dd0a0) at action.c:962
#6  0x000000000041089e in run_action_list (a=<value optimized out>, msg=0x7dd0a0) at action.c:139
#7  0x000000000040ec40 in do_action (a=0x79f710, msg=0x7dd0a0) at action.c:706
#8  0x000000000041089e in run_action_list (a=<value optimized out>, msg=0x7dd0a0) at action.c:139
#9  0x000000000040ec40 in do_action (a=0x79fdb0, msg=0x7dd0a0) at action.c:706
#10 0x000000000041089e in run_action_list (a=<value optimized out>, msg=0x7dd0a0) at action.c:139
#11 0x000000000040fc27 in do_action (a=0x79fe80, msg=0x7dd0a0) at action.c:712
#12 0x000000000041089e in run_action_list (a=<value optimized out>, msg=0x7dd0a0) at action.c:139
#13 0x000000000040fc27 in do_action (a=0x79ff50, msg=0x7dd0a0) at action.c:712
#14 0x000000000041089e in run_action_list (a=<value optimized out>, msg=0x7dd0a0) at action.c:139
#15 0x000000000040ebac in do_action (a=0x7824c0, msg=0x7dd0a0) at action.c:119
#16 0x000000000041089e in run_action_list (a=<value optimized out>, msg=0x7dd0a0) at action.c:139
#17 0x000000000040ec40 in do_action (a=0x782590, msg=0x7dd0a0) at action.c:706
#18 0x000000000041089e in run_action_list (a=<value optimized out>, msg=0x7dd0a0) at action.c:139
#19 0x000000000040ec40 in do_action (a=0x784180, msg=0x7dd0a0) at action.c:706
#20 0x000000000041089e in run_action_list (a=<value optimized out>, msg=0x7dd0a0) at action.c:139
#21 0x0000000000410bf9 in run_top_route (a=0x773bb8, msg=0x7dd0a0) at action.c:119
#22 0x000000000044f4df in receive_msg (
    buf=0x741fe0 "SUBSCRIBE sip:94.25.209.130:5060 SIP/2.0\r\nRecord-Route: <sip:94.25.209.132;lr=on;ftag=14278SIPpTag0055525>\r\nVia: SIP/2.0/UDP 94.25.209.132;branch=z9hG4bK6236.7f93e02.0\r\nVia: SIP/2.0/UDP 10.2.176.220:5"..., len=546, rcv_info=0x7fff1b4293a0) at receive.c:165
#23 0x000000000048efce in udp_rcv_loop () at udp_server.c:449
#24 0x0000000000427a8a in main (argc=7, argv=0x7fff1b4295a8) at main.c:779



In core dump I can see that variable 's' has not valid value. 'hash_code' value is 1280. I think in some place in the code 1280-record in htable was deleted without lock in the same time with search_shtable was called. I can see only this reason for crash in this situation. I trying to resolve this bug now, but I need help from this module developer...

----------------------------------------------------------------------

>Comment By: Vladimir Kuznetsov (kuznetsov82)
Date: 2009-11-05 17:47

Message:
just forgot...
htable[hash_code].entries == 0 in the core dump.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=2892636&group_id=232389


From noreply at sourceforge.net  Thu Nov  5 16:09:26 2009
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 05 Nov 2009 15:09:26 +0000
Subject: [OpenSIPS-Devel] [ opensips-Bugs-2892636 ] Opensips crash
Message-ID: <E1N63xm-0000Ew-OX@d55xhf1.ch3.sourceforge.com>

Bugs item #2892636, was opened at 2009-11-05 16:28
Message generated for change (Settings changed) made by anca_vamanu
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=2892636&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.5.x
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Vladimir Kuznetsov (kuznetsov82)
>Assigned to: Anca Vamanu (anca_vamanu)
Summary: Opensips crash

Initial Comment:
server version 1.5.3
callstack:
#0  search_shtable (htable=0x2adf94a1e2e0, callid=
      {s = 0x74212e "55525-14278 at 10.2.176.220\r\nCSeq: 3 SUBSCRIBE\r\nContact: sip:andrey11 at 10.2.176.220:5061\r\nMax-Forwards: 68\r\nExpires: 5\r\nEvent: presence\r\nSubject: Performance Test\r\nContent-Type: application/sdp\r\nContent-L"..., len = 24}, to_tag=
      {s = 0x2adf9d2b118e "70a5b204a9409a36294d5c67c6ad5ef1-2fc8\r\nCall-ID: 55525-14278 at 10.2.176.220\r\nCSeq: 3 SUBSCRIBE\r\nExpires: 5\r\nContact: <sip:94.25.209.130:5060>\r\nServer: Yota voip server 1.5.3-1.2.0-800\r\nContent-Length: 0\r"..., len = 37}, from_tag=
      {s = 0x7420f0 "14278SIPpTag0055525\r\nTo: sut <sip:andrey11 at yota.ru>\r\nCall-ID: 55525-14278 at 10.2.176.220\r\nCSeq: 3 SUBSCRIBE\r\nContact: sip:andrey11 at 10.2.176.220:5061\r\nMax-Forwards: 68\r\nExpires: 5\r\nEvent: presence\r\nSubje"..., len = 19}, hash_code=1280) at hash.c:110
#1  0x00002adf913a1ab2 in update_shtable (htable=0x2adf94a1e2e0, hash_code=80, subs=0x7fff1b4271a0, type=4) at hash.c:342
#2  0x00002adf913b09dc in notify (subs=0x7fff1b4271a0, watcher_subs=0x0, n_body=0x0, force_null_body=0) at notify.c:1776
#3  0x00002adf913c3dc9 in update_subscription (msg=<value optimized out>, subs=0x7fff1b4271a0, init_req=<value optimized out>) at subscribe.c:418
#4  0x00002adf913cae4c in handle_subscribe (msg=0x7dd0a0, str1=<value optimized out>, str2=<value optimized out>) at subscribe.c:697
#5  0x000000000040ddfc in do_action (a=0x79f3c0, msg=0x7dd0a0) at action.c:962
#6  0x000000000041089e in run_action_list (a=<value optimized out>, msg=0x7dd0a0) at action.c:139
#7  0x000000000040ec40 in do_action (a=0x79f710, msg=0x7dd0a0) at action.c:706
#8  0x000000000041089e in run_action_list (a=<value optimized out>, msg=0x7dd0a0) at action.c:139
#9  0x000000000040ec40 in do_action (a=0x79fdb0, msg=0x7dd0a0) at action.c:706
#10 0x000000000041089e in run_action_list (a=<value optimized out>, msg=0x7dd0a0) at action.c:139
#11 0x000000000040fc27 in do_action (a=0x79fe80, msg=0x7dd0a0) at action.c:712
#12 0x000000000041089e in run_action_list (a=<value optimized out>, msg=0x7dd0a0) at action.c:139
#13 0x000000000040fc27 in do_action (a=0x79ff50, msg=0x7dd0a0) at action.c:712
#14 0x000000000041089e in run_action_list (a=<value optimized out>, msg=0x7dd0a0) at action.c:139
#15 0x000000000040ebac in do_action (a=0x7824c0, msg=0x7dd0a0) at action.c:119
#16 0x000000000041089e in run_action_list (a=<value optimized out>, msg=0x7dd0a0) at action.c:139
#17 0x000000000040ec40 in do_action (a=0x782590, msg=0x7dd0a0) at action.c:706
#18 0x000000000041089e in run_action_list (a=<value optimized out>, msg=0x7dd0a0) at action.c:139
#19 0x000000000040ec40 in do_action (a=0x784180, msg=0x7dd0a0) at action.c:706
#20 0x000000000041089e in run_action_list (a=<value optimized out>, msg=0x7dd0a0) at action.c:139
#21 0x0000000000410bf9 in run_top_route (a=0x773bb8, msg=0x7dd0a0) at action.c:119
#22 0x000000000044f4df in receive_msg (
    buf=0x741fe0 "SUBSCRIBE sip:94.25.209.130:5060 SIP/2.0\r\nRecord-Route: <sip:94.25.209.132;lr=on;ftag=14278SIPpTag0055525>\r\nVia: SIP/2.0/UDP 94.25.209.132;branch=z9hG4bK6236.7f93e02.0\r\nVia: SIP/2.0/UDP 10.2.176.220:5"..., len=546, rcv_info=0x7fff1b4293a0) at receive.c:165
#23 0x000000000048efce in udp_rcv_loop () at udp_server.c:449
#24 0x0000000000427a8a in main (argc=7, argv=0x7fff1b4295a8) at main.c:779



In core dump I can see that variable 's' has not valid value. 'hash_code' value is 1280. I think in some place in the code 1280-record in htable was deleted without lock in the same time with search_shtable was called. I can see only this reason for crash in this situation. I trying to resolve this bug now, but I need help from this module developer...

----------------------------------------------------------------------

>Comment By: Anca Vamanu (anca_vamanu)
Date: 2009-11-05 17:09

Message:
Hi Vladimir,

Have you set the subs_htable_size module parameter? By default the maximum
value for hash code is 512.

Regards,
Anca 

----------------------------------------------------------------------

Comment By: Vladimir Kuznetsov (kuznetsov82)
Date: 2009-11-05 16:47

Message:
just forgot...
htable[hash_code].entries == 0 in the core dump.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=2892636&group_id=232389


From noreply at sourceforge.net  Thu Nov  5 16:17:54 2009
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 05 Nov 2009 15:17:54 +0000
Subject: [OpenSIPS-Devel] [ opensips-Bugs-2892636 ] Opensips crash
Message-ID: <E1N645y-0001rV-4B@d45xhf1.ch3.sourceforge.com>

Bugs item #2892636, was opened at 2009-11-05 17:28
Message generated for change (Comment added) made by kuznetsov82
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=2892636&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.5.x
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Vladimir Kuznetsov (kuznetsov82)
Assigned to: Anca Vamanu (anca_vamanu)
Summary: Opensips crash

Initial Comment:
server version 1.5.3
callstack:
#0  search_shtable (htable=0x2adf94a1e2e0, callid=
      {s = 0x74212e "55525-14278 at 10.2.176.220\r\nCSeq: 3 SUBSCRIBE\r\nContact: sip:andrey11 at 10.2.176.220:5061\r\nMax-Forwards: 68\r\nExpires: 5\r\nEvent: presence\r\nSubject: Performance Test\r\nContent-Type: application/sdp\r\nContent-L"..., len = 24}, to_tag=
      {s = 0x2adf9d2b118e "70a5b204a9409a36294d5c67c6ad5ef1-2fc8\r\nCall-ID: 55525-14278 at 10.2.176.220\r\nCSeq: 3 SUBSCRIBE\r\nExpires: 5\r\nContact: <sip:94.25.209.130:5060>\r\nServer: Yota voip server 1.5.3-1.2.0-800\r\nContent-Length: 0\r"..., len = 37}, from_tag=
      {s = 0x7420f0 "14278SIPpTag0055525\r\nTo: sut <sip:andrey11 at yota.ru>\r\nCall-ID: 55525-14278 at 10.2.176.220\r\nCSeq: 3 SUBSCRIBE\r\nContact: sip:andrey11 at 10.2.176.220:5061\r\nMax-Forwards: 68\r\nExpires: 5\r\nEvent: presence\r\nSubje"..., len = 19}, hash_code=1280) at hash.c:110
#1  0x00002adf913a1ab2 in update_shtable (htable=0x2adf94a1e2e0, hash_code=80, subs=0x7fff1b4271a0, type=4) at hash.c:342
#2  0x00002adf913b09dc in notify (subs=0x7fff1b4271a0, watcher_subs=0x0, n_body=0x0, force_null_body=0) at notify.c:1776
#3  0x00002adf913c3dc9 in update_subscription (msg=<value optimized out>, subs=0x7fff1b4271a0, init_req=<value optimized out>) at subscribe.c:418
#4  0x00002adf913cae4c in handle_subscribe (msg=0x7dd0a0, str1=<value optimized out>, str2=<value optimized out>) at subscribe.c:697
#5  0x000000000040ddfc in do_action (a=0x79f3c0, msg=0x7dd0a0) at action.c:962
#6  0x000000000041089e in run_action_list (a=<value optimized out>, msg=0x7dd0a0) at action.c:139
#7  0x000000000040ec40 in do_action (a=0x79f710, msg=0x7dd0a0) at action.c:706
#8  0x000000000041089e in run_action_list (a=<value optimized out>, msg=0x7dd0a0) at action.c:139
#9  0x000000000040ec40 in do_action (a=0x79fdb0, msg=0x7dd0a0) at action.c:706
#10 0x000000000041089e in run_action_list (a=<value optimized out>, msg=0x7dd0a0) at action.c:139
#11 0x000000000040fc27 in do_action (a=0x79fe80, msg=0x7dd0a0) at action.c:712
#12 0x000000000041089e in run_action_list (a=<value optimized out>, msg=0x7dd0a0) at action.c:139
#13 0x000000000040fc27 in do_action (a=0x79ff50, msg=0x7dd0a0) at action.c:712
#14 0x000000000041089e in run_action_list (a=<value optimized out>, msg=0x7dd0a0) at action.c:139
#15 0x000000000040ebac in do_action (a=0x7824c0, msg=0x7dd0a0) at action.c:119
#16 0x000000000041089e in run_action_list (a=<value optimized out>, msg=0x7dd0a0) at action.c:139
#17 0x000000000040ec40 in do_action (a=0x782590, msg=0x7dd0a0) at action.c:706
#18 0x000000000041089e in run_action_list (a=<value optimized out>, msg=0x7dd0a0) at action.c:139
#19 0x000000000040ec40 in do_action (a=0x784180, msg=0x7dd0a0) at action.c:706
#20 0x000000000041089e in run_action_list (a=<value optimized out>, msg=0x7dd0a0) at action.c:139
#21 0x0000000000410bf9 in run_top_route (a=0x773bb8, msg=0x7dd0a0) at action.c:119
#22 0x000000000044f4df in receive_msg (
    buf=0x741fe0 "SUBSCRIBE sip:94.25.209.130:5060 SIP/2.0\r\nRecord-Route: <sip:94.25.209.132;lr=on;ftag=14278SIPpTag0055525>\r\nVia: SIP/2.0/UDP 94.25.209.132;branch=z9hG4bK6236.7f93e02.0\r\nVia: SIP/2.0/UDP 10.2.176.220:5"..., len=546, rcv_info=0x7fff1b4293a0) at receive.c:165
#23 0x000000000048efce in udp_rcv_loop () at udp_server.c:449
#24 0x0000000000427a8a in main (argc=7, argv=0x7fff1b4295a8) at main.c:779



In core dump I can see that variable 's' has not valid value. 'hash_code' value is 1280. I think in some place in the code 1280-record in htable was deleted without lock in the same time with search_shtable was called. I can see only this reason for crash in this situation. I trying to resolve this bug now, but I need help from this module developer...

----------------------------------------------------------------------

>Comment By: Vladimir Kuznetsov (kuznetsov82)
Date: 2009-11-05 18:17

Message:
I see((( No, this parameter has default value = 512. 
GDB is crazy now(( On frame #2 hash_code == 37, on frame 1 hash_code ==
80, on frame 0 hash_code == 1280. Now I trying to crash opensips server
with valgrind and memcheck utilities...

----------------------------------------------------------------------

Comment By: Anca Vamanu (anca_vamanu)
Date: 2009-11-05 18:09

Message:
Hi Vladimir,

Have you set the subs_htable_size module parameter? By default the maximum
value for hash code is 512.

Regards,
Anca 

----------------------------------------------------------------------

Comment By: Vladimir Kuznetsov (kuznetsov82)
Date: 2009-11-05 17:47

Message:
just forgot...
htable[hash_code].entries == 0 in the core dump.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=2892636&group_id=232389


From anca at opensips.org  Thu Nov  5 17:17:45 2009
From: anca at opensips.org (Anca Vamanu)
Date: Thu, 05 Nov 2009 16:17:45 +0000
Subject: [OpenSIPS-Devel] SF.net SVN: opensips:[6329] trunk/modules
Message-ID: <E1N651t-00070a-Gc@dn4whf1.ch3.sourceforge.com>

Revision: 6329
          http://opensips.svn.sourceforge.net/opensips/?rev=6329&view=rev
Author:   anca_vamanu
Date:     2009-11-05 16:17:45 +0000 (Thu, 05 Nov 2009)

Log Message:
-----------
- added support for handling refer at server ( extended the configuration possibility for the b2bua scenarios)
- extended the number of supported methods to pass through the B2BUA
- fixed bug when no custom headers were defined

Modified Paths:
--------------
    trunk/modules/b2b_entities/dlg.c
    trunk/modules/b2b_entities/server.c
    trunk/modules/b2b_logic/b2b_logic.c
    trunk/modules/b2b_logic/b2b_logic.h
    trunk/modules/b2b_logic/logic.c
    trunk/modules/b2b_logic/records.c
    trunk/modules/b2b_logic/records.h


This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site.


From noreply at sourceforge.net  Thu Nov  5 21:15:54 2009
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 05 Nov 2009 20:15:54 +0000
Subject: [OpenSIPS-Devel] [ opensips-Bugs-2890915 ] db_virtual no DB
	connection available if pool member lost
Message-ID: <E1N68kM-0006dI-Tx@d55xhf1.ch3.sourceforge.com>

Bugs item #2890915, was opened at 2009-11-02 22:09
Message generated for change (Comment added) made by rpistolea
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=2890915&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.6.x
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Daryl G. Jurbala (lucifuge)
Assigned to: Razvan (rpistolea)
Summary: db_virtual no DB connection available if pool member lost

Initial Comment:
This is easily duplicated on 1.6.0 with postgres.  I have a pool of 5 pgsql servers that I point at for avpops, auth_db, and uri.  If any one of them becomes unavailable, I can no longer do anything with the db_virtual pool (registrations can not complete, etc.) and must remove the problem db server and restart OpenSIPS.

----------------------------------------------------------------------

Comment By: Razvan (rpistolea)
Date: 2009-11-05 22:15

Message:
what mode are you using?
what do you mean by "pool"? fails before a query or an insert? 
does the exported MI db_set/db_get work (to ignore the failed one by
hand?)?

----------------------------------------------------------------------

Comment By: Bogdan-Andrei Iancu (bogdan_iancu)
Date: 2009-11-04 11:02

Message:
Hi Daryl,

what mode do you use for the virtual connection - parallel, failover,
round-robin ?

Also, do you have some logs/debug during the error?

Regards,
Bogdan

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=2890915&group_id=232389


From noreply at sourceforge.net  Fri Nov  6 11:38:29 2009
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 06 Nov 2009 10:38:29 +0000
Subject: [OpenSIPS-Devel] [ opensips-Patches-2887877 ] nathelper : allow
	millisecond timeout for Rtpproxy reply
Message-ID: <E1N6MD7-0003IN-0m@665xhf1.ch3.sourceforge.com>

Patches item #2887877, was opened at 2009-10-28 13:29
Message generated for change (Comment added) made by cfc
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086412&aid=2887877&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: Christophe Sollet (csollet)
Assigned to: Bogdan-Andrei Iancu (bogdan_iancu)
Summary: nathelper : allow millisecond timeout for Rtpproxy reply

Initial Comment:
Hello,

Current parameter 'rtpproxy_tout' can be used to set a timeout with second resolution.

Sadly, one second is generally too long to wait generating a lot of SIP retransmission

This patch add a 'rtpproxy_tout_ms' parameter to set a timeout with millisecond resolution. The used timeout become (rtpproxy_tout * 1000) + rtpproxy_tout_ms)

Setting 'rtpproxy_tout' to 0, this new parameter can be used to set a sub second timeout.

----------------------------------------------------------------------

Comment By: Christophe Sollet (cfc)
Date: 2009-11-06 11:38

Message:
Hi Bogdan,

New patch that follow your last comment is ready. I will upload it as a
new one as it seems I can't upload on this one.

Regards,
Christophe.

----------------------------------------------------------------------

Comment By: Bogdan-Andrei Iancu (bogdan_iancu)
Date: 2009-10-30 12:22

Message:
I was thinking also about BC, but mixing two params may be even more
confusing.

if we change it to accept floating vals, we need to change the type of the
param from INT to STR (modparam does not natively support floats)....So, if
we have to change something and to have BC, I suggest:
- adding a new param 'rtpproxy_timeout' - accepts an INT with full timeout
in milisecs
- 'rtpproxy_tout' will be keept, but warning will be fired if used (as
will become obsolete)
- if both are used from the script, some error should be fired...

What do you say?

Regards,
Bogdan

----------------------------------------------------------------------

Comment By: Christophe Sollet (csollet)
Date: 2009-10-30 12:13

Message:
Hi Bogdan,

In fact, our first implementation  was just to change to millisecond. This
new attribute was added only to keep BC.
But you're right, the best solution is to accept floating numbers. New
patch will come next week.

Regards,
Christophe.


----------------------------------------------------------------------

Comment By: Bogdan-Andrei Iancu (bogdan_iancu)
Date: 2009-10-30 12:04

Message:
Hi Christophe,

Thanks for the patch - shouldn't be simpler to use only one parameter
('rtpproxy_tout') and to change the value from secs to milisecs ? or to
keep secs, but to accept floating numbers ("0.01") ?

Regards,
Bogdan

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086412&aid=2887877&group_id=232389


From noreply at sourceforge.net  Fri Nov  6 11:40:16 2009
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 06 Nov 2009 10:40:16 +0000
Subject: [OpenSIPS-Devel] [ opensips-Patches-2893189 ] nathelper : add
	rtpproxy_timeout param
Message-ID: <E1N6MEq-00049o-Cc@1bkjzd1.ch3.sourceforge.com>

Patches item #2893189, was opened at 2009-11-06 11:40
Message generated for change (Tracker Item Submitted) made by cfc
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086412&aid=2893189&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: Christophe Sollet (cfc)
Assigned to: Nobody/Anonymous (nobody)
Summary: nathelper : add rtpproxy_timeout param

Initial Comment:
see 2887877 for details.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086412&aid=2893189&group_id=232389


From anca at opensips.org  Fri Nov  6 12:00:17 2009
From: anca at opensips.org (Anca Vamanu)
Date: Fri, 06 Nov 2009 11:00:17 +0000
Subject: [OpenSIPS-Devel] SF.net SVN: opensips:[6330] branches/1.6/modules
Message-ID: <E1N6MYD-0007eB-Vc@3kljzd1.ch3.sourceforge.com>

Revision: 6330
          http://opensips.svn.sourceforge.net/opensips/?rev=6330&view=rev
Author:   anca_vamanu
Date:     2009-11-06 11:00:17 +0000 (Fri, 06 Nov 2009)

Log Message:
-----------
- fixed bug if t_newtran() was not called from the script
- fixed some isses when closing a call while in bridging state - send ACK for invite and switch to a new state for the scenario instance

Modified Paths:
--------------
    branches/1.6/modules/b2b_entities/dlg.c
    branches/1.6/modules/b2b_entities/server.c
    branches/1.6/modules/b2b_logic/b2b_logic.h
    branches/1.6/modules/b2b_logic/logic.c
    branches/1.6/modules/b2b_logic/records.c


This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site.


From anca at opensips.org  Fri Nov  6 12:14:43 2009
From: anca at opensips.org (Anca Vamanu)
Date: Fri, 06 Nov 2009 11:14:43 +0000
Subject: [OpenSIPS-Devel] SF.net SVN: opensips:[6331] trunk/modules/b2b_logic
Message-ID: <E1N6MmB-0007tL-4v@3kljzd1.ch3.sourceforge.com>

Revision: 6331
          http://opensips.svn.sourceforge.net/opensips/?rev=6331&view=rev
Author:   anca_vamanu
Date:     2009-11-06 11:14:42 +0000 (Fri, 06 Nov 2009)

Log Message:
-----------
- fixed some isses when closing a call while in bridging state - send ACK for invite and switch to a new state for the scenario instance

Modified Paths:
--------------
    trunk/modules/b2b_logic/b2b_logic.h
    trunk/modules/b2b_logic/logic.c


This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site.


From anca at opensips.org  Fri Nov  6 17:44:30 2009
From: anca at opensips.org (Anca Vamanu)
Date: Fri, 06 Nov 2009 16:44:30 +0000
Subject: [OpenSIPS-Devel] SF.net SVN: opensips:[6332]
	trunk/modules/b2b_logic/logic.c
Message-ID: <E1N6RvK-0006sh-Lo@c3vjzd1.ch3.sourceforge.com>

Revision: 6332
          http://opensips.svn.sourceforge.net/opensips/?rev=6332&view=rev
Author:   anca_vamanu
Date:     2009-11-06 16:44:27 +0000 (Fri, 06 Nov 2009)

Log Message:
-----------
- changed the way to search for the value of a certain SIP header

Modified Paths:
--------------
    trunk/modules/b2b_logic/logic.c


This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site.


From noreply at sourceforge.net  Fri Nov  6 18:20:45 2009
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 06 Nov 2009 17:20:45 +0000
Subject: [OpenSIPS-Devel] [ opensips-Bugs-2893439 ] compile failure
Message-ID: <E1N6SUP-0004nh-3R@665xhf1.ch3.sourceforge.com>

Bugs item #2893439, was opened at 2009-11-06 17:20
Message generated for change (Tracker Item Submitted) made by norm_brandinger
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=2893439&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: Norm Brandinger (norm_brandinger)
Assigned to: Nobody/Anonymous (nobody)
Summary: compile failure

Initial Comment:
In file included from records.h:36,
                 from b2b_logic.c:41:
b2b_logic.h: In function ?b2b_get_request_id?:
b2b_logic.h:104: error: ?REFER_LEN? undeclared (first use in this function)
b2b_logic.h:104: error: (Each undeclared identifier is reported only once
b2b_logic.h:104: error: for each function it appears in.)
b2b_logic.h:104: error: ?REFER? undeclared (first use in this function)
b2b_logic.h:110: error: ?SUBSCRIBE_LEN? undeclared (first use in this function)
b2b_logic.h:110: error: ?SUBSCRIBE? undeclared (first use in this function)
b2b_logic.h:113: error: ?NOTIFY_LEN? undeclared (first use in this function)
b2b_logic.h:113: error: ?NOTIFY? undeclared (first use in this function)
b2b_logic.h:116: error: ?MESSAGE_LEN? undeclared (first use in this function)
b2b_logic.h:116: error: ?MESSAGE? undeclared (first use in this function)
make[1]: *** [b2b_logic.o] Error 1

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=2893439&group_id=232389


From noreply at sourceforge.net  Fri Nov  6 22:44:45 2009
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 06 Nov 2009 21:44:45 +0000
Subject: [OpenSIPS-Devel] [ opensips-Feature Requests-2893576 ] Inverse
	Codec Match
Message-ID: <E1N6Wbt-0001PX-2I@h45xhf1.ch3.sourceforge.com>

Feature Requests item #2893576, was opened at 2009-11-06 16:44
Message generated for change (Tracker Item Submitted) made by rrb3942
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086413&aid=2893576&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: None
Group: None
Status: Open
Priority: 5
Private: No
Submitted By: Ryan Bullock (rrb3942)
Assigned to: Nobody/Anonymous (nobody)
Summary: Inverse Codec Match

Initial Comment:
The new codec functions in textops are awesome. However there is one feature I would like to see.

Currently there is codec_delete_re() and codec_exists_re that lets you delete and check for any codecs that match a regular expression.

If would be nice if there was the ability to also delete codecs that do NOT match an expression, perhaps through a option. This would allow you to enforce a list of supported codecs only. Right now to remove all other codecs would need an exhaustive list of what to remove (or some really awful inverse regex that would be confusing to write/read, if it is even possible to write)

For example, if you only want to permit G711 and G729 you could do something like the following to remove any other codecs:

codec_delete_re("[gG]711|[gG]729", v) 

And the only codecs left would be G711 and G729 in the message. Or if it had only g711 and say speex, you would be left with only g711.

One would of course have to be careful to not remove telephony-events as well, but that should be up to the script writer.

I think this would be useful only for the codec_exists_re and codec_delete_re, so you could check for, and remove any foreign codecs.

codec_move_up_re and codec_move_down_re are already their inverses (for the most part).

Also a case insensitive option for the regex might be nice. But that would just be more icing on the cake.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086413&aid=2893576&group_id=232389


From noreply at sourceforge.net  Sat Nov  7 13:50:24 2009
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat, 07 Nov 2009 12:50:24 +0000
Subject: [OpenSIPS-Devel] [ opensips-Bugs-2893439 ] compile failure
Message-ID: <E1N6kkK-0004rS-BU@d55xhf1.ch3.sourceforge.com>

Bugs item #2893439, was opened at 2009-11-06 17:20
Message generated for change (Comment added) made by norm_brandinger
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=2893439&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: Norm Brandinger (norm_brandinger)
Assigned to: Nobody/Anonymous (nobody)
Summary: compile failure

Initial Comment:
In file included from records.h:36,
                 from b2b_logic.c:41:
b2b_logic.h: In function ?b2b_get_request_id?:
b2b_logic.h:104: error: ?REFER_LEN? undeclared (first use in this function)
b2b_logic.h:104: error: (Each undeclared identifier is reported only once
b2b_logic.h:104: error: for each function it appears in.)
b2b_logic.h:104: error: ?REFER? undeclared (first use in this function)
b2b_logic.h:110: error: ?SUBSCRIBE_LEN? undeclared (first use in this function)
b2b_logic.h:110: error: ?SUBSCRIBE? undeclared (first use in this function)
b2b_logic.h:113: error: ?NOTIFY_LEN? undeclared (first use in this function)
b2b_logic.h:113: error: ?NOTIFY? undeclared (first use in this function)
b2b_logic.h:116: error: ?MESSAGE_LEN? undeclared (first use in this function)
b2b_logic.h:116: error: ?MESSAGE? undeclared (first use in this function)
make[1]: *** [b2b_logic.o] Error 1

----------------------------------------------------------------------

>Comment By: Norm Brandinger (norm_brandinger)
Date: 2009-11-07 12:50

Message:
Added patch to include all METHODs defined by
http://www.iana.org/assignments/sip-parameters.

Applying the patch fixes the compile problem.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=2893439&group_id=232389


From noreply at sourceforge.net  Sun Nov  8 00:07:11 2009
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat, 07 Nov 2009 23:07:11 +0000
Subject: [OpenSIPS-Devel] [ opensips-Bugs-2893969 ] SST not setting the
	avp_timeout
Message-ID: <E1N6uND-0006Qq-1X@1bkjzd1.ch3.sourceforge.com>

Bugs item #2893969, was opened at 2009-11-07 21:07
Message generated for change (Tracker Item Submitted) made by flaviogoncalves
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=2893969&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.6.x
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Flavio Goncalves (flaviogoncalves)
Assigned to: Nobody/Anonymous (nobody)
Summary: SST not setting the avp_timeout

Initial Comment:
I'm trying to use the SST module, but the system never set the timeout to the value of the Session-Expires Header.  There is no error being shown,  even with debug=9. Using opensipsctl fifo dlg_list, the value of the parameter timeout is always in the default value. All flags were set and the timeout_avp(i:4042) is set to both modules SST and DIALOG. The dialog is matching ok. I have checked everything I could. If I drop the network cable, the dialog stays active for the default timeout 43200. It never assumes the value of the Session-Expires. I tried setting the value in the uac, uas and in the proxy itself. 

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=2893969&group_id=232389


From whitearchey at gmail.com  Sun Nov  8 16:33:41 2009
From: whitearchey at gmail.com (WhiteWind)
Date: Sun, 08 Nov 2009 23:33:41 +0800
Subject: [OpenSIPS-Devel] Patch for auth_aaa module
Message-ID: <op.u221idi95ahtmm@comp>


I needed proper auth of INVITE requests and I implemented it.
I wish to see this patch in the mainstream and I'm ready to correct this  
patch if it doesn't fit some standards or contains bugs

Index: modules/auth_aaa/authaaa_mod.c
===================================================================
--- modules/auth_aaa/authaaa_mod.c      (revision 6274)
+++ modules/auth_aaa/authaaa_mod.c      (working copy)
@@ -119,6 +119,8 @@

         memset(attrs, 0, sizeof(attrs));
         memset(vals, 0, sizeof(vals));
+       attrs[A_CALLED_STATION_ID].name                 =  
"Called-Station-Id";
+       attrs[A_CALLING_STATION_ID].name                =  
"Calling-Station-Id";
         attrs[A_SERVICE_TYPE].name                      = "Service-Type";
         attrs[A_SIP_URI_USER].name                      = "Sip-URI-User";
         attrs[A_DIGEST_RESPONSE].name           = "Digest-Response";
Index: modules/auth_aaa/sterman.c
===================================================================
--- modules/auth_aaa/sterman.c  (revision 6274)
+++ modules/auth_aaa/sterman.c  (working copy)
@@ -231,6 +231,21 @@
                 goto err;
         }

+       if (method.len == 6 && !strncmp(method.s, "INVITE", 6)) {
+            struct sip_uri *uri = parse_to_uri(_msg);
+            if (uri && uri->user.s)
+                if (proto.avp_add(conn, send,  
&attrs[A_CALLED_STATION_ID], uri->user.s,
+                                  uri->user.len, 0)) {
+                        LM_ERR("unable to add Called-Station-Id  
attribute\n");
+                        goto err;
+                }
+
+            if (proto.avp_add(conn, send, &attrs[A_CALLING_STATION_ID],  
user.s,user.len,0)) {
+                    LM_ERR("unable to add Calling-Station-Id  
attribute\n");
+                    goto err;
+            }
+        }
+
         /* Add CALL-ID in Acct-Session-Id Attribute */
         if ( _msg->callid==NULL &&
                 (parse_headers(_msg, HDR_CALLID_F, 0)==-1 ||  
_msg->callid==NULL)  ) {

-- 
???????? ? ???????? ??????? ???????? Opera: http://www.opera.com/mail/


From bogdan at voice-system.ro  Sun Nov  8 19:33:20 2009
From: bogdan at voice-system.ro (Bogdan-Andrei Iancu)
Date: Sun, 08 Nov 2009 18:33:20 +0000
Subject: [OpenSIPS-Devel] SF.net SVN: opensips:[6333] trunk/packaging/fedora
Message-ID: <E1N7CZk-0002TF-EP@bj8yhf1.ch3.sourceforge.com>

Revision: 6333
          http://opensips.svn.sourceforge.net/opensips/?rev=6333&view=rev
Author:   bogdan_iancu
Date:     2009-11-08 18:33:20 +0000 (Sun, 08 Nov 2009)

Log Message:
-----------
specs and init updated
- credits go to John Khvatov, the opensips maintainer on fedora.

Modified Paths:
--------------
    trunk/packaging/fedora/opensips.init
    trunk/packaging/fedora/opensips.spec


This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site.


From bogdan at voice-system.ro  Sun Nov  8 19:34:52 2009
From: bogdan at voice-system.ro (Bogdan-Andrei Iancu)
Date: Sun, 08 Nov 2009 18:34:52 +0000
Subject: [OpenSIPS-Devel] SF.net SVN: opensips:[6334]
	branches/1.6/packaging/fedora
Message-ID: <E1N7CbE-0002UV-Q9@bj8yhf1.ch3.sourceforge.com>

Revision: 6334
          http://opensips.svn.sourceforge.net/opensips/?rev=6334&view=rev
Author:   bogdan_iancu
Date:     2009-11-08 18:34:52 +0000 (Sun, 08 Nov 2009)

Log Message:
-----------
backport from trunk (rev #6333):
- specs and init updated
- credits go to John Khvatov, the opensips maintainer on fedora.

Revision Links:
--------------
    http://opensips.svn.sourceforge.net/opensips/?rev=6333&view=rev

Modified Paths:
--------------
    branches/1.6/packaging/fedora/opensips.init
    branches/1.6/packaging/fedora/opensips.spec


This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site.


From bogdan at voice-system.ro  Sun Nov  8 19:37:14 2009
From: bogdan at voice-system.ro (Bogdan-Andrei Iancu)
Date: Sun, 08 Nov 2009 18:37:14 +0000
Subject: [OpenSIPS-Devel] SF.net SVN: opensips:[6335]
	branches/1.5/packaging/fedora/opensips.init
Message-ID: <E1N7CdW-0002XU-84@bj8yhf1.ch3.sourceforge.com>

Revision: 6335
          http://opensips.svn.sourceforge.net/opensips/?rev=6335&view=rev
Author:   bogdan_iancu
Date:     2009-11-08 18:37:14 +0000 (Sun, 08 Nov 2009)

Log Message:
-----------
ckport from trunk (rev #6333):
- init updated
- credits go to John Khvatov, the opensips maintainer on fedora.

Revision Links:
--------------
    http://opensips.svn.sourceforge.net/opensips/?rev=6333&view=rev

Modified Paths:
--------------
    branches/1.5/packaging/fedora/opensips.init


This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site.


From bogdan at voice-system.ro  Sun Nov  8 19:40:14 2009
From: bogdan at voice-system.ro (Bogdan-Andrei Iancu)
Date: Sun, 08 Nov 2009 20:40:14 +0200
Subject: [OpenSIPS-Devel] fedora rpm package
In-Reply-To: <20091103142932.GB9075@aki.main.sgu.ru>
References: <20091103142932.GB9075@aki.main.sgu.ru>
Message-ID: <4AF7108E.6090503@voice-system.ro>

Hi John,

Thank you very much for your fixes and contribution - I already pushed 
them into the SVN.

If I understand correctly, you are the official maintainer of OpenSIPS 
on fedora - if so, would you be interested in getting SVN access and 
officially maintain the fedora packaging directly in the SVN tree ?

Best regards,
Bogdan

John Khvatov wrote:
> Hello all.
>
> I'm opensips maintainer on fedora.
>
> This patch for init script to fix malformed comment block:
> http://dev.sgu.ru/fedora/opensips--init.patch
>
> Current spec file with new opensips modules:
> http://dev.sgu.ru/fedora/opensips.spec
>
> Consider to apply these changes to the upstream, please.
>
>   



From bogdan at voice-system.ro  Sun Nov  8 19:42:58 2009
From: bogdan at voice-system.ro (Bogdan-Andrei Iancu)
Date: Sun, 08 Nov 2009 20:42:58 +0200
Subject: [OpenSIPS-Devel] patch for compatibility with openssl-1.0.0
In-Reply-To: <20091103135804.GA9075@aki.main.sgu.ru>
References: <20091103135804.GA9075@aki.main.sgu.ru>
Message-ID: <4AF71132.2090405@voice-system.ro>

Hi John,

I tested the patch and seams ok, but I want to be sure we do not break 
the compiling for some older versions of OpenSSL. So, what is the 
version when this change was done in OpenSSL ?

Thanks and regards,
Bogdan

John Khvatov wrote:
> Hello all!
>
> Fedora 12 will be with new OpenSSL. Could you apply this patch?
>
> Current version of the code fails to build:
> tls/tls_init.c: In function 'check_for_krb':
> tls/tls_init.c:470: error: 'struct stack_st_SSL_CIPHER' has no member
> named 'num'
> tls/tls_init.c:471: error: 'struct stack_st_SSL_CIPHER' has no member
> named 'data'
> make: *** [tls/tls_init.o] Error 1
>
>   



From bogdan at voice-system.ro  Sun Nov  8 19:48:54 2009
From: bogdan at voice-system.ro (Bogdan-Andrei Iancu)
Date: Sun, 08 Nov 2009 20:48:54 +0200
Subject: [OpenSIPS-Devel] Patch for auth_aaa module
In-Reply-To: <op.u221idi95ahtmm@comp>
References: <op.u221idi95ahtmm@comp>
Message-ID: <4AF71296.3040108@voice-system.ro>

Hi,

Couldn't you obtain this functionality by using a custom set (see 
http://www.opensips.org/html/docs/modules/devel/aaa_radius.html#id227231) 
to push extra information that you need.

If there is something different, please let me know.

Regards,
Bogdan

WhiteWind wrote:
> I needed proper auth of INVITE requests and I implemented it.
> I wish to see this patch in the mainstream and I'm ready to correct this  
> patch if it doesn't fit some standards or contains bugs
>
> Index: modules/auth_aaa/authaaa_mod.c
> ===================================================================
> --- modules/auth_aaa/authaaa_mod.c      (revision 6274)
> +++ modules/auth_aaa/authaaa_mod.c      (working copy)
> @@ -119,6 +119,8 @@
>
>          memset(attrs, 0, sizeof(attrs));
>          memset(vals, 0, sizeof(vals));
> +       attrs[A_CALLED_STATION_ID].name                 =  
> "Called-Station-Id";
> +       attrs[A_CALLING_STATION_ID].name                =  
> "Calling-Station-Id";
>          attrs[A_SERVICE_TYPE].name                      = "Service-Type";
>          attrs[A_SIP_URI_USER].name                      = "Sip-URI-User";
>          attrs[A_DIGEST_RESPONSE].name           = "Digest-Response";
> Index: modules/auth_aaa/sterman.c
> ===================================================================
> --- modules/auth_aaa/sterman.c  (revision 6274)
> +++ modules/auth_aaa/sterman.c  (working copy)
> @@ -231,6 +231,21 @@
>                  goto err;
>          }
>
> +       if (method.len == 6 && !strncmp(method.s, "INVITE", 6)) {
> +            struct sip_uri *uri = parse_to_uri(_msg);
> +            if (uri && uri->user.s)
> +                if (proto.avp_add(conn, send,  
> &attrs[A_CALLED_STATION_ID], uri->user.s,
> +                                  uri->user.len, 0)) {
> +                        LM_ERR("unable to add Called-Station-Id  
> attribute\n");
> +                        goto err;
> +                }
> +
> +            if (proto.avp_add(conn, send, &attrs[A_CALLING_STATION_ID],  
> user.s,user.len,0)) {
> +                    LM_ERR("unable to add Calling-Station-Id  
> attribute\n");
> +                    goto err;
> +            }
> +        }
> +
>          /* Add CALL-ID in Acct-Session-Id Attribute */
>          if ( _msg->callid==NULL &&
>                  (parse_headers(_msg, HDR_CALLID_F, 0)==-1 ||  
> _msg->callid==NULL)  ) {
>
>   



From ivaxer at gmail.com  Sun Nov  8 21:18:08 2009
From: ivaxer at gmail.com (John Khvatov)
Date: Sun, 8 Nov 2009 23:18:08 +0300
Subject: [OpenSIPS-Devel] patch for compatibility with openssl-1.0.0
In-Reply-To: <4AF71132.2090405@voice-system.ro>
References: <20091103135804.GA9075@aki.main.sgu.ru>
	<4AF71132.2090405@voice-system.ro>
Message-ID: <628ff2820911081218s37bbfd1dib4eab1e64b6425c5@mail.gmail.com>

Hi Bogdan,

On Sun, Nov 8, 2009 at 9:42 PM, Bogdan-Andrei Iancu
<bogdan at voice-system.ro> wrote:
> Hi John,
>
> I tested the patch and seams ok, but I want to be sure we do not break the
> compiling for some older versions of OpenSSL. So, what is the version when
> this change was done in OpenSSL ?
>
> Thanks and regards,
> Bogdan
>
I've looked at first available version of sample application
'ciphers.c' in cvs.openssl
(http://cvs.openssl.org/rlog?f=openssl/apps/ciphers.c). Macroses
sk_SSL_CIPHER_{num,value} are available since April 1999. So, patched
code will work since 0.9.3 version of OpenSSL.
Which version is required for OpenSIPS? If older than 0.9.3 I will
continue to research.

> John Khvatov wrote:
>>
>> Hello all!
>>
>> Fedora 12 will be with new OpenSSL. Could you apply this patch?
>>
>> Current version of the code fails to build:
>> tls/tls_init.c: In function 'check_for_krb':
>> tls/tls_init.c:470: error: 'struct stack_st_SSL_CIPHER' has no member
>> named 'num'
>> tls/tls_init.c:471: error: 'struct stack_st_SSL_CIPHER' has no member
>> named 'data'
>> make: *** [tls/tls_init.o] Error 1
>>
>>
>
>

-- 
WBR, John Khvatov


From ivaxer at gmail.com  Sun Nov  8 21:32:24 2009
From: ivaxer at gmail.com (John Khvatov)
Date: Sun, 8 Nov 2009 23:32:24 +0300
Subject: [OpenSIPS-Devel] fedora rpm package
In-Reply-To: <4AF7108E.6090503@voice-system.ro>
References: <20091103142932.GB9075@aki.main.sgu.ru>
	<4AF7108E.6090503@voice-system.ro>
Message-ID: <628ff2820911081232n6e85c19ds5fb90257716beb02@mail.gmail.com>

Hi Bogdan,

On Sun, Nov 8, 2009 at 9:40 PM, Bogdan-Andrei Iancu
<bogdan at voice-system.ro> wrote:
> Hi John,
>
> Thank you very much for your fixes and contribution - I already pushed them
> into the SVN.
>
> If I understand correctly, you are the official maintainer of OpenSIPS on
> fedora - if so, would you be interested in getting SVN access and officially
> maintain the fedora packaging directly in the SVN tree ?
>
> Best regards,
> Bogdan
>

Thanks for applying patches.

Yes, I'm official maintainer of OpenSIPS on fedora (To verify You can
send me a email to opensips-owner at fp :) ).
And yes, it would be great to make changes directly in the SVN tree.

> John Khvatov wrote:
>>
>> Hello all.
>>
>> I'm opensips maintainer on fedora.
>>
>> This patch for init script to fix malformed comment block:
>> http://dev.sgu.ru/fedora/opensips--init.patch
>>
>> Current spec file with new opensips modules:
>> http://dev.sgu.ru/fedora/opensips.spec
>>
>> Consider to apply these changes to the upstream, please.
>>
>>
>
>


P.S. fp = fedoraproject.org
-- 
WBR, John Khvatov


From whitearchey at gmail.com  Mon Nov  9 01:15:26 2009
From: whitearchey at gmail.com (WhiteWind)
Date: Mon, 09 Nov 2009 08:15:26 +0800
Subject: [OpenSIPS-Devel] Patch for auth_aaa module
In-Reply-To: <4AF71296.3040108@voice-system.ro>
References: <op.u221idi95ahtmm@comp> <4AF71296.3040108@voice-system.ro>
Message-ID: <op.u23pn0uh5ahtmm@comp>

Then I should append Digest attributes to request by myself using  
modparam("aaa_radius","sets", ...)

On Mon, 09 Nov 2009 02:48:54 +0800, Bogdan-Andrei Iancu  
<bogdan at voice-system.ro> wrote:

> Hi,
>
> Couldn't you obtain this functionality by using a custom set (see
> http://www.opensips.org/html/docs/modules/devel/aaa_radius.html#id227231)
> to push extra information that you need.
>
> If there is something different, please let me know.
>
> Regards,
> Bogdan
>
> WhiteWind wrote:
>> I needed proper auth of INVITE requests and I implemented it.
>> I wish to see this patch in the mainstream and I'm ready to correct this
>> patch if it doesn't fit some standards or contains bugs
>>
>> Index: modules/auth_aaa/authaaa_mod.c
>> ===================================================================
>> --- modules/auth_aaa/authaaa_mod.c      (revision 6274)
>> +++ modules/auth_aaa/authaaa_mod.c      (working copy)
>> @@ -119,6 +119,8 @@
>>
>>          memset(attrs, 0, sizeof(attrs));
>>          memset(vals, 0, sizeof(vals));
>> +       attrs[A_CALLED_STATION_ID].name                 =
>> "Called-Station-Id";
>> +       attrs[A_CALLING_STATION_ID].name                =
>> "Calling-Station-Id";
>>          attrs[A_SERVICE_TYPE].name                      =  
>> "Service-Type";
>>          attrs[A_SIP_URI_USER].name                      =  
>> "Sip-URI-User";
>>          attrs[A_DIGEST_RESPONSE].name           = "Digest-Response";
>> Index: modules/auth_aaa/sterman.c
>> ===================================================================
>> --- modules/auth_aaa/sterman.c  (revision 6274)
>> +++ modules/auth_aaa/sterman.c  (working copy)
>> @@ -231,6 +231,21 @@
>>                  goto err;
>>          }
>>
>> +       if (method.len == 6 && !strncmp(method.s, "INVITE", 6)) {
>> +            struct sip_uri *uri = parse_to_uri(_msg);
>> +            if (uri && uri->user.s)
>> +                if (proto.avp_add(conn, send,
>> &attrs[A_CALLED_STATION_ID], uri->user.s,
>> +                                  uri->user.len, 0)) {
>> +                        LM_ERR("unable to add Called-Station-Id
>> attribute\n");
>> +                        goto err;
>> +                }
>> +
>> +            if (proto.avp_add(conn, send, &attrs[A_CALLING_STATION_ID],
>> user.s,user.len,0)) {
>> +                    LM_ERR("unable to add Calling-Station-Id
>> attribute\n");
>> +                    goto err;
>> +            }
>> +        }
>> +
>>          /* Add CALL-ID in Acct-Session-Id Attribute */
>>          if ( _msg->callid==NULL &&
>>                  (parse_headers(_msg, HDR_CALLID_F, 0)==-1 ||
>> _msg->callid==NULL)  ) {
>>
>>
>
>
> _______________________________________________
> Devel mailing list
> Devel at lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/devel


-- 
???????? ? ???????? ??????? ???????? Opera: http://www.opera.com/mail/


From noreply at sourceforge.net  Mon Nov  9 10:11:19 2009
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 09 Nov 2009 09:11:19 +0000
Subject: [OpenSIPS-Devel] [ opensips-Bugs-2892636 ] Opensips crash
Message-ID: <E1N7QHP-0007KU-O3@665xhf1.ch3.sourceforge.com>

Bugs item #2892636, was opened at 2009-11-05 17:28
Message generated for change (Comment added) made by kuznetsov82
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=2892636&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.5.x
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Vladimir Kuznetsov (kuznetsov82)
Assigned to: Anca Vamanu (anca_vamanu)
Summary: Opensips crash

Initial Comment:
server version 1.5.3
callstack:
#0  search_shtable (htable=0x2adf94a1e2e0, callid=
      {s = 0x74212e "55525-14278 at 10.2.176.220\r\nCSeq: 3 SUBSCRIBE\r\nContact: sip:andrey11 at 10.2.176.220:5061\r\nMax-Forwards: 68\r\nExpires: 5\r\nEvent: presence\r\nSubject: Performance Test\r\nContent-Type: application/sdp\r\nContent-L"..., len = 24}, to_tag=
      {s = 0x2adf9d2b118e "70a5b204a9409a36294d5c67c6ad5ef1-2fc8\r\nCall-ID: 55525-14278 at 10.2.176.220\r\nCSeq: 3 SUBSCRIBE\r\nExpires: 5\r\nContact: <sip:94.25.209.130:5060>\r\nServer: Yota voip server 1.5.3-1.2.0-800\r\nContent-Length: 0\r"..., len = 37}, from_tag=
      {s = 0x7420f0 "14278SIPpTag0055525\r\nTo: sut <sip:andrey11 at yota.ru>\r\nCall-ID: 55525-14278 at 10.2.176.220\r\nCSeq: 3 SUBSCRIBE\r\nContact: sip:andrey11 at 10.2.176.220:5061\r\nMax-Forwards: 68\r\nExpires: 5\r\nEvent: presence\r\nSubje"..., len = 19}, hash_code=1280) at hash.c:110
#1  0x00002adf913a1ab2 in update_shtable (htable=0x2adf94a1e2e0, hash_code=80, subs=0x7fff1b4271a0, type=4) at hash.c:342
#2  0x00002adf913b09dc in notify (subs=0x7fff1b4271a0, watcher_subs=0x0, n_body=0x0, force_null_body=0) at notify.c:1776
#3  0x00002adf913c3dc9 in update_subscription (msg=<value optimized out>, subs=0x7fff1b4271a0, init_req=<value optimized out>) at subscribe.c:418
#4  0x00002adf913cae4c in handle_subscribe (msg=0x7dd0a0, str1=<value optimized out>, str2=<value optimized out>) at subscribe.c:697
#5  0x000000000040ddfc in do_action (a=0x79f3c0, msg=0x7dd0a0) at action.c:962
#6  0x000000000041089e in run_action_list (a=<value optimized out>, msg=0x7dd0a0) at action.c:139
#7  0x000000000040ec40 in do_action (a=0x79f710, msg=0x7dd0a0) at action.c:706
#8  0x000000000041089e in run_action_list (a=<value optimized out>, msg=0x7dd0a0) at action.c:139
#9  0x000000000040ec40 in do_action (a=0x79fdb0, msg=0x7dd0a0) at action.c:706
#10 0x000000000041089e in run_action_list (a=<value optimized out>, msg=0x7dd0a0) at action.c:139
#11 0x000000000040fc27 in do_action (a=0x79fe80, msg=0x7dd0a0) at action.c:712
#12 0x000000000041089e in run_action_list (a=<value optimized out>, msg=0x7dd0a0) at action.c:139
#13 0x000000000040fc27 in do_action (a=0x79ff50, msg=0x7dd0a0) at action.c:712
#14 0x000000000041089e in run_action_list (a=<value optimized out>, msg=0x7dd0a0) at action.c:139
#15 0x000000000040ebac in do_action (a=0x7824c0, msg=0x7dd0a0) at action.c:119
#16 0x000000000041089e in run_action_list (a=<value optimized out>, msg=0x7dd0a0) at action.c:139
#17 0x000000000040ec40 in do_action (a=0x782590, msg=0x7dd0a0) at action.c:706
#18 0x000000000041089e in run_action_list (a=<value optimized out>, msg=0x7dd0a0) at action.c:139
#19 0x000000000040ec40 in do_action (a=0x784180, msg=0x7dd0a0) at action.c:706
#20 0x000000000041089e in run_action_list (a=<value optimized out>, msg=0x7dd0a0) at action.c:139
#21 0x0000000000410bf9 in run_top_route (a=0x773bb8, msg=0x7dd0a0) at action.c:119
#22 0x000000000044f4df in receive_msg (
    buf=0x741fe0 "SUBSCRIBE sip:94.25.209.130:5060 SIP/2.0\r\nRecord-Route: <sip:94.25.209.132;lr=on;ftag=14278SIPpTag0055525>\r\nVia: SIP/2.0/UDP 94.25.209.132;branch=z9hG4bK6236.7f93e02.0\r\nVia: SIP/2.0/UDP 10.2.176.220:5"..., len=546, rcv_info=0x7fff1b4293a0) at receive.c:165
#23 0x000000000048efce in udp_rcv_loop () at udp_server.c:449
#24 0x0000000000427a8a in main (argc=7, argv=0x7fff1b4295a8) at main.c:779



In core dump I can see that variable 's' has not valid value. 'hash_code' value is 1280. I think in some place in the code 1280-record in htable was deleted without lock in the same time with search_shtable was called. I can see only this reason for crash in this situation. I trying to resolve this bug now, but I need help from this module developer...

----------------------------------------------------------------------

>Comment By: Vladimir Kuznetsov (kuznetsov82)
Date: 2009-11-09 12:11

Message:
I can reproduce this crash with SUBSCRIBE requests- -about 20 requests per
second during 30-40 minutes.

----------------------------------------------------------------------

Comment By: Vladimir Kuznetsov (kuznetsov82)
Date: 2009-11-05 18:17

Message:
I see((( No, this parameter has default value = 512. 
GDB is crazy now(( On frame #2 hash_code == 37, on frame 1 hash_code ==
80, on frame 0 hash_code == 1280. Now I trying to crash opensips server
with valgrind and memcheck utilities...

----------------------------------------------------------------------

Comment By: Anca Vamanu (anca_vamanu)
Date: 2009-11-05 18:09

Message:
Hi Vladimir,

Have you set the subs_htable_size module parameter? By default the maximum
value for hash code is 512.

Regards,
Anca 

----------------------------------------------------------------------

Comment By: Vladimir Kuznetsov (kuznetsov82)
Date: 2009-11-05 17:47

Message:
just forgot...
htable[hash_code].entries == 0 in the core dump.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=2892636&group_id=232389


From anca at opensips.org  Mon Nov  9 10:13:47 2009
From: anca at opensips.org (Anca Vamanu)
Date: Mon, 09 Nov 2009 09:13:47 +0000
Subject: [OpenSIPS-Devel] SF.net SVN: opensips:[6336]
	trunk/parser/parse_fline.h
Message-ID: <E1N7QJn-0005bs-8D@74yxhf1.ch3.sourceforge.com>

Revision: 6336
          http://opensips.svn.sourceforge.net/opensips/?rev=6336&view=rev
Author:   anca_vamanu
Date:     2009-11-09 09:13:46 +0000 (Mon, 09 Nov 2009)

Log Message:
-----------
- applied patch from Norm Brandinger (fixes bug #2893439)

Modified Paths:
--------------
    trunk/parser/parse_fline.h


This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site.


From noreply at sourceforge.net  Mon Nov  9 10:15:46 2009
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 09 Nov 2009 09:15:46 +0000
Subject: [OpenSIPS-Devel] [ opensips-Bugs-2893439 ] compile failure
Message-ID: <E1N7QLi-0001LD-Ma@cdv4jf1.ch3.sourceforge.com>

Bugs item #2893439, was opened at 2009-11-06 19:20
Message generated for change (Settings changed) made by anca_vamanu
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=2893439&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: 5
Private: No
Submitted By: Norm Brandinger (norm_brandinger)
Assigned to: Nobody/Anonymous (nobody)
Summary: compile failure

Initial Comment:
In file included from records.h:36,
                 from b2b_logic.c:41:
b2b_logic.h: In function ?b2b_get_request_id?:
b2b_logic.h:104: error: ?REFER_LEN? undeclared (first use in this function)
b2b_logic.h:104: error: (Each undeclared identifier is reported only once
b2b_logic.h:104: error: for each function it appears in.)
b2b_logic.h:104: error: ?REFER? undeclared (first use in this function)
b2b_logic.h:110: error: ?SUBSCRIBE_LEN? undeclared (first use in this function)
b2b_logic.h:110: error: ?SUBSCRIBE? undeclared (first use in this function)
b2b_logic.h:113: error: ?NOTIFY_LEN? undeclared (first use in this function)
b2b_logic.h:113: error: ?NOTIFY? undeclared (first use in this function)
b2b_logic.h:116: error: ?MESSAGE_LEN? undeclared (first use in this function)
b2b_logic.h:116: error: ?MESSAGE? undeclared (first use in this function)
make[1]: *** [b2b_logic.o] Error 1

----------------------------------------------------------------------

>Comment By: Anca Vamanu (anca_vamanu)
Date: 2009-11-09 11:15

Message:
Hi Norm,

I had that file modified but forgot to commit it. I applied your patch
since it contained all methods(mine contained only the ones I used).
Thanks,
Anca

----------------------------------------------------------------------

Comment By: Norm Brandinger (norm_brandinger)
Date: 2009-11-07 14:50

Message:
Added patch to include all METHODs defined by
http://www.iana.org/assignments/sip-parameters.

Applying the patch fixes the compile problem.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=2893439&group_id=232389


From noreply at sourceforge.net  Mon Nov  9 10:17:53 2009
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 09 Nov 2009 09:17:53 +0000
Subject: [OpenSIPS-Devel] [ opensips-Bugs-2892636 ] Opensips crash
Message-ID: <E1N7QNl-0008EJ-Su@d45xhf1.ch3.sourceforge.com>

Bugs item #2892636, was opened at 2009-11-05 16:28
Message generated for change (Comment added) made by anca_vamanu
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=2892636&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.5.x
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Vladimir Kuznetsov (kuznetsov82)
Assigned to: Anca Vamanu (anca_vamanu)
Summary: Opensips crash

Initial Comment:
server version 1.5.3
callstack:
#0  search_shtable (htable=0x2adf94a1e2e0, callid=
      {s = 0x74212e "55525-14278 at 10.2.176.220\r\nCSeq: 3 SUBSCRIBE\r\nContact: sip:andrey11 at 10.2.176.220:5061\r\nMax-Forwards: 68\r\nExpires: 5\r\nEvent: presence\r\nSubject: Performance Test\r\nContent-Type: application/sdp\r\nContent-L"..., len = 24}, to_tag=
      {s = 0x2adf9d2b118e "70a5b204a9409a36294d5c67c6ad5ef1-2fc8\r\nCall-ID: 55525-14278 at 10.2.176.220\r\nCSeq: 3 SUBSCRIBE\r\nExpires: 5\r\nContact: <sip:94.25.209.130:5060>\r\nServer: Yota voip server 1.5.3-1.2.0-800\r\nContent-Length: 0\r"..., len = 37}, from_tag=
      {s = 0x7420f0 "14278SIPpTag0055525\r\nTo: sut <sip:andrey11 at yota.ru>\r\nCall-ID: 55525-14278 at 10.2.176.220\r\nCSeq: 3 SUBSCRIBE\r\nContact: sip:andrey11 at 10.2.176.220:5061\r\nMax-Forwards: 68\r\nExpires: 5\r\nEvent: presence\r\nSubje"..., len = 19}, hash_code=1280) at hash.c:110
#1  0x00002adf913a1ab2 in update_shtable (htable=0x2adf94a1e2e0, hash_code=80, subs=0x7fff1b4271a0, type=4) at hash.c:342
#2  0x00002adf913b09dc in notify (subs=0x7fff1b4271a0, watcher_subs=0x0, n_body=0x0, force_null_body=0) at notify.c:1776
#3  0x00002adf913c3dc9 in update_subscription (msg=<value optimized out>, subs=0x7fff1b4271a0, init_req=<value optimized out>) at subscribe.c:418
#4  0x00002adf913cae4c in handle_subscribe (msg=0x7dd0a0, str1=<value optimized out>, str2=<value optimized out>) at subscribe.c:697
#5  0x000000000040ddfc in do_action (a=0x79f3c0, msg=0x7dd0a0) at action.c:962
#6  0x000000000041089e in run_action_list (a=<value optimized out>, msg=0x7dd0a0) at action.c:139
#7  0x000000000040ec40 in do_action (a=0x79f710, msg=0x7dd0a0) at action.c:706
#8  0x000000000041089e in run_action_list (a=<value optimized out>, msg=0x7dd0a0) at action.c:139
#9  0x000000000040ec40 in do_action (a=0x79fdb0, msg=0x7dd0a0) at action.c:706
#10 0x000000000041089e in run_action_list (a=<value optimized out>, msg=0x7dd0a0) at action.c:139
#11 0x000000000040fc27 in do_action (a=0x79fe80, msg=0x7dd0a0) at action.c:712
#12 0x000000000041089e in run_action_list (a=<value optimized out>, msg=0x7dd0a0) at action.c:139
#13 0x000000000040fc27 in do_action (a=0x79ff50, msg=0x7dd0a0) at action.c:712
#14 0x000000000041089e in run_action_list (a=<value optimized out>, msg=0x7dd0a0) at action.c:139
#15 0x000000000040ebac in do_action (a=0x7824c0, msg=0x7dd0a0) at action.c:119
#16 0x000000000041089e in run_action_list (a=<value optimized out>, msg=0x7dd0a0) at action.c:139
#17 0x000000000040ec40 in do_action (a=0x782590, msg=0x7dd0a0) at action.c:706
#18 0x000000000041089e in run_action_list (a=<value optimized out>, msg=0x7dd0a0) at action.c:139
#19 0x000000000040ec40 in do_action (a=0x784180, msg=0x7dd0a0) at action.c:706
#20 0x000000000041089e in run_action_list (a=<value optimized out>, msg=0x7dd0a0) at action.c:139
#21 0x0000000000410bf9 in run_top_route (a=0x773bb8, msg=0x7dd0a0) at action.c:119
#22 0x000000000044f4df in receive_msg (
    buf=0x741fe0 "SUBSCRIBE sip:94.25.209.130:5060 SIP/2.0\r\nRecord-Route: <sip:94.25.209.132;lr=on;ftag=14278SIPpTag0055525>\r\nVia: SIP/2.0/UDP 94.25.209.132;branch=z9hG4bK6236.7f93e02.0\r\nVia: SIP/2.0/UDP 10.2.176.220:5"..., len=546, rcv_info=0x7fff1b4293a0) at receive.c:165
#23 0x000000000048efce in udp_rcv_loop () at udp_server.c:449
#24 0x0000000000427a8a in main (argc=7, argv=0x7fff1b4295a8) at main.c:779



In core dump I can see that variable 's' has not valid value. 'hash_code' value is 1280. I think in some place in the code 1280-record in htable was deleted without lock in the same time with search_shtable was called. I can see only this reason for crash in this situation. I trying to resolve this bug now, but I need help from this module developer...

----------------------------------------------------------------------

>Comment By: Anca Vamanu (anca_vamanu)
Date: 2009-11-09 11:17

Message:
Ok, I will try this also.

----------------------------------------------------------------------

Comment By: Vladimir Kuznetsov (kuznetsov82)
Date: 2009-11-09 11:11

Message:
I can reproduce this crash with SUBSCRIBE requests- -about 20 requests per
second during 30-40 minutes.

----------------------------------------------------------------------

Comment By: Vladimir Kuznetsov (kuznetsov82)
Date: 2009-11-05 17:17

Message:
I see((( No, this parameter has default value = 512. 
GDB is crazy now(( On frame #2 hash_code == 37, on frame 1 hash_code ==
80, on frame 0 hash_code == 1280. Now I trying to crash opensips server
with valgrind and memcheck utilities...

----------------------------------------------------------------------

Comment By: Anca Vamanu (anca_vamanu)
Date: 2009-11-05 17:09

Message:
Hi Vladimir,

Have you set the subs_htable_size module parameter? By default the maximum
value for hash code is 512.

Regards,
Anca 

----------------------------------------------------------------------

Comment By: Vladimir Kuznetsov (kuznetsov82)
Date: 2009-11-05 16:47

Message:
just forgot...
htable[hash_code].entries == 0 in the core dump.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=2892636&group_id=232389


From alex at jajah.com  Mon Nov  9 11:46:48 2009
From: alex at jajah.com (Alex Massover)
Date: Mon, 9 Nov 2009 12:46:48 +0200
Subject: [OpenSIPS-Devel] Patch for auth_aaa module
In-Reply-To: <op.u23pn0uh5ahtmm@comp>
References: <op.u221idi95ahtmm@comp> <4AF71296.3040108@voice-system.ro>
	<op.u23pn0uh5ahtmm@comp>
Message-ID: <F5B5EF8F78C0BC4BB417E1DBB9D7F7D00B85A25A4A@jjex01.jajah.dublin>

Hi!

Maybe it's better to enrich auth_aaa functions aaa_www_authorize(realm) and aaa_proxy_authorize(realm [, uri_user]) to take optional sets from aaa_radius?
Like this:
aaa_www_authorize(realm [,set]), aaa_proxy_authorize(realm [, uri_user][, set])

It will be more generic and anyone could pass whatever he needs.

--
Best Regards,
Alex Massover
VoIP R&D TL
Jajah Inc.
> -----Original Message-----
> From: devel-bounces at lists.opensips.org [mailto:devel-
> bounces at lists.opensips.org] On Behalf Of WhiteWind
> Sent: Monday, November 09, 2009 2:15 AM
> To: OpenSIPS devel mailling list
> Subject: Re: [OpenSIPS-Devel] Patch for auth_aaa module
>
> Then I should append Digest attributes to request by myself using
> modparam("aaa_radius","sets", ...)
>
> On Mon, 09 Nov 2009 02:48:54 +0800, Bogdan-Andrei Iancu
> <bogdan at voice-system.ro> wrote:
>
> > Hi,
> >
> > Couldn't you obtain this functionality by using a custom set (see
> >
> http://www.opensips.org/html/docs/modules/devel/aaa_radius.html#id22723
> 1)
> > to push extra information that you need.
> >
> > If there is something different, please let me know.
> >
> > Regards,
> > Bogdan
> >
> > WhiteWind wrote:
> >> I needed proper auth of INVITE requests and I implemented it.
> >> I wish to see this patch in the mainstream and I'm ready to correct
> this
> >> patch if it doesn't fit some standards or contains bugs
> >>
> >> Index: modules/auth_aaa/authaaa_mod.c
> >> ===================================================================
> >> --- modules/auth_aaa/authaaa_mod.c      (revision 6274)
> >> +++ modules/auth_aaa/authaaa_mod.c      (working copy)
> >> @@ -119,6 +119,8 @@
> >>
> >>          memset(attrs, 0, sizeof(attrs));
> >>          memset(vals, 0, sizeof(vals));
> >> +       attrs[A_CALLED_STATION_ID].name                 =
> >> "Called-Station-Id";
> >> +       attrs[A_CALLING_STATION_ID].name                =
> >> "Calling-Station-Id";
> >>          attrs[A_SERVICE_TYPE].name                      =
> >> "Service-Type";
> >>          attrs[A_SIP_URI_USER].name                      =
> >> "Sip-URI-User";
> >>          attrs[A_DIGEST_RESPONSE].name           = "Digest-
> Response";
> >> Index: modules/auth_aaa/sterman.c
> >> ===================================================================
> >> --- modules/auth_aaa/sterman.c  (revision 6274)
> >> +++ modules/auth_aaa/sterman.c  (working copy)
> >> @@ -231,6 +231,21 @@
> >>                  goto err;
> >>          }
> >>
> >> +       if (method.len == 6 && !strncmp(method.s, "INVITE", 6)) {
> >> +            struct sip_uri *uri = parse_to_uri(_msg);
> >> +            if (uri && uri->user.s)
> >> +                if (proto.avp_add(conn, send,
> >> &attrs[A_CALLED_STATION_ID], uri->user.s,
> >> +                                  uri->user.len, 0)) {
> >> +                        LM_ERR("unable to add Called-Station-Id
> >> attribute\n");
> >> +                        goto err;
> >> +                }
> >> +
> >> +            if (proto.avp_add(conn, send,
> &attrs[A_CALLING_STATION_ID],
> >> user.s,user.len,0)) {
> >> +                    LM_ERR("unable to add Calling-Station-Id
> >> attribute\n");
> >> +                    goto err;
> >> +            }
> >> +        }
> >> +
> >>          /* Add CALL-ID in Acct-Session-Id Attribute */
> >>          if ( _msg->callid==NULL &&
> >>                  (parse_headers(_msg, HDR_CALLID_F, 0)==-1 ||
> >> _msg->callid==NULL)  ) {
> >>
> >>
> >
> >
> > _______________________________________________
> > Devel mailing list
> > Devel at lists.opensips.org
> > http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
>
>
> --
> ???????? ? ???????? ??????? ???????? Opera: http://www.opera.com/mail/
>
> _______________________________________________
> Devel mailing list
> Devel at lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
>
> This mail was received via Mail-SeCure System.

This mail was sent via Mail-SeCure System.




From whitearchey at gmail.com  Mon Nov  9 11:46:43 2009
From: whitearchey at gmail.com (=?koi8-r?B?4dfEycXOy88g7cnIwcnM?=)
Date: Mon, 09 Nov 2009 18:46:43 +0800
Subject: [OpenSIPS-Devel] Patch for auth_aaa module
In-Reply-To: <F5B5EF8F78C0BC4BB417E1DBB9D7F7D00B85A25A4A@jjex01.jajah.dublin>
References: <op.u221idi95ahtmm@comp> <4AF71296.3040108@voice-system.ro>
	<op.u23pn0uh5ahtmm@comp>
	<F5B5EF8F78C0BC4BB417E1DBB9D7F7D00B85A25A4A@jjex01.jajah.dublin>
Message-ID: <op.u24iv1qltqk0r3@whitewind_work.skysib.com>


Yes, it will be nice. I'm not sure if I can implement this but I will try

On Mon, 09 Nov 2009 18:46:48 +0800, Alex Massover <alex at jajah.com> wrote:

> Hi!
>
> Maybe it's better to enrich auth_aaa functions aaa_www_authorize(realm)  
> and aaa_proxy_authorize(realm [, uri_user]) to take optional sets from  
> aaa_radius?
> Like this:
> aaa_www_authorize(realm [,set]), aaa_proxy_authorize(realm [,  
> uri_user][, set])
>
> It will be more generic and anyone could pass whatever he needs.
>
> --
> Best Regards,
> Alex Massover
> VoIP R&D TL
> Jajah Inc.
>> -----Original Message-----
>> From: devel-bounces at lists.opensips.org [mailto:devel-
>> bounces at lists.opensips.org] On Behalf Of WhiteWind
>> Sent: Monday, November 09, 2009 2:15 AM
>> To: OpenSIPS devel mailling list
>> Subject: Re: [OpenSIPS-Devel] Patch for auth_aaa module
>>
>> Then I should append Digest attributes to request by myself using
>> modparam("aaa_radius","sets", ...)
>>
>> On Mon, 09 Nov 2009 02:48:54 +0800, Bogdan-Andrei Iancu
>> <bogdan at voice-system.ro> wrote:
>>
>> > Hi,
>> >
>> > Couldn't you obtain this functionality by using a custom set (see
>> >
>> http://www.opensips.org/html/docs/modules/devel/aaa_radius.html#id22723
>> 1)
>> > to push extra information that you need.
>> >
>> > If there is something different, please let me know.
>> >
>> > Regards,
>> > Bogdan
>> >
>> > WhiteWind wrote:
>> >> I needed proper auth of INVITE requests and I implemented it.
>> >> I wish to see this patch in the mainstream and I'm ready to correct
>> this
>> >> patch if it doesn't fit some standards or contains bugs
>> >>
>> >> Index: modules/auth_aaa/authaaa_mod.c
>> >> ===================================================================
>> >> --- modules/auth_aaa/authaaa_mod.c      (revision 6274)
>> >> +++ modules/auth_aaa/authaaa_mod.c      (working copy)
>> >> @@ -119,6 +119,8 @@
>> >>
>> >>          memset(attrs, 0, sizeof(attrs));
>> >>          memset(vals, 0, sizeof(vals));
>> >> +       attrs[A_CALLED_STATION_ID].name                 =
>> >> "Called-Station-Id";
>> >> +       attrs[A_CALLING_STATION_ID].name                =
>> >> "Calling-Station-Id";
>> >>          attrs[A_SERVICE_TYPE].name                      =
>> >> "Service-Type";
>> >>          attrs[A_SIP_URI_USER].name                      =
>> >> "Sip-URI-User";
>> >>          attrs[A_DIGEST_RESPONSE].name           = "Digest-
>> Response";
>> >> Index: modules/auth_aaa/sterman.c
>> >> ===================================================================
>> >> --- modules/auth_aaa/sterman.c  (revision 6274)
>> >> +++ modules/auth_aaa/sterman.c  (working copy)
>> >> @@ -231,6 +231,21 @@
>> >>                  goto err;
>> >>          }
>> >>
>> >> +       if (method.len == 6 && !strncmp(method.s, "INVITE", 6)) {
>> >> +            struct sip_uri *uri = parse_to_uri(_msg);
>> >> +            if (uri && uri->user.s)
>> >> +                if (proto.avp_add(conn, send,
>> >> &attrs[A_CALLED_STATION_ID], uri->user.s,
>> >> +                                  uri->user.len, 0)) {
>> >> +                        LM_ERR("unable to add Called-Station-Id
>> >> attribute\n");
>> >> +                        goto err;
>> >> +                }
>> >> +
>> >> +            if (proto.avp_add(conn, send,
>> &attrs[A_CALLING_STATION_ID],
>> >> user.s,user.len,0)) {
>> >> +                    LM_ERR("unable to add Calling-Station-Id
>> >> attribute\n");
>> >> +                    goto err;
>> >> +            }
>> >> +        }
>> >> +
>> >>          /* Add CALL-ID in Acct-Session-Id Attribute */
>> >>          if ( _msg->callid==NULL &&
>> >>                  (parse_headers(_msg, HDR_CALLID_F, 0)==-1 ||
>> >> _msg->callid==NULL)  ) {
>> >>
>> >>
>> >
>> >
>> > _______________________________________________
>> > Devel mailing list
>> > Devel at lists.opensips.org
>> > http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
>>
>>
>> --
>> ???????? ? ???????? ??????? ???????? Opera: http://www.opera.com/mail/
>>
>> _______________________________________________
>> Devel mailing list
>> Devel at lists.opensips.org
>> http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
>>
>> This mail was received via Mail-SeCure System.
>
> This mail was sent via Mail-SeCure System.
>
>
>
> _______________________________________________
> Devel mailing list
> Devel at lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/devel



From bogdan at voice-system.ro  Mon Nov  9 03:50:18 2009
From: bogdan at voice-system.ro (Bogdan-Andrei Iancu)
Date: Mon, 09 Nov 2009 04:50:18 +0200
Subject: [OpenSIPS-Devel] patch for compatibility with openssl-1.0.0
In-Reply-To: <628ff2820911081218s37bbfd1dib4eab1e64b6425c5@mail.gmail.com>
References: <20091103135804.GA9075@aki.main.sgu.ru>
	<4AF71132.2090405@voice-system.ro>
	<628ff2820911081218s37bbfd1dib4eab1e64b6425c5@mail.gmail.com>
Message-ID: <4AF7836A.8060409@voice-system.ro>

Hi John,

I wouldn't worry - the TLS implementation support only openssl versions 
newer than 0.9.7, so the patch is ok - I will apply it on SVN asap.

Thanks & Regards,
Bogdan

John Khvatov wrote:
> Hi Bogdan,
>
> On Sun, Nov 8, 2009 at 9:42 PM, Bogdan-Andrei Iancu
> <bogdan at voice-system.ro> wrote:
>   
>> Hi John,
>>
>> I tested the patch and seams ok, but I want to be sure we do not break the
>> compiling for some older versions of OpenSSL. So, what is the version when
>> this change was done in OpenSSL ?
>>
>> Thanks and regards,
>> Bogdan
>>
>>     
> I've looked at first available version of sample application
> 'ciphers.c' in cvs.openssl
> (http://cvs.openssl.org/rlog?f=openssl/apps/ciphers.c). Macroses
> sk_SSL_CIPHER_{num,value} are available since April 1999. So, patched
> code will work since 0.9.3 version of OpenSSL.
> Which version is required for OpenSIPS? If older than 0.9.3 I will
> continue to research.
>
>   
>> John Khvatov wrote:
>>     
>>> Hello all!
>>>
>>> Fedora 12 will be with new OpenSSL. Could you apply this patch?
>>>
>>> Current version of the code fails to build:
>>> tls/tls_init.c: In function 'check_for_krb':
>>> tls/tls_init.c:470: error: 'struct stack_st_SSL_CIPHER' has no member
>>> named 'num'
>>> tls/tls_init.c:471: error: 'struct stack_st_SSL_CIPHER' has no member
>>> named 'data'
>>> make: *** [tls/tls_init.o] Error 1
>>>
>>>
>>>       
>>     
>
>   




From bogdan at voice-system.ro  Mon Nov  9 16:37:24 2009
From: bogdan at voice-system.ro (Bogdan-Andrei Iancu)
Date: Mon, 09 Nov 2009 17:37:24 +0200
Subject: [OpenSIPS-Devel] fedora rpm package
In-Reply-To: <628ff2820911081232n6e85c19ds5fb90257716beb02@mail.gmail.com>
References: <20091103142932.GB9075@aki.main.sgu.ru>
	<4AF7108E.6090503@voice-system.ro>
	<628ff2820911081232n6e85c19ds5fb90257716beb02@mail.gmail.com>
Message-ID: <4AF83734.8050900@voice-system.ro>

Hi John,

Just send me the SourForge ID to add you to the project.

Regards,
Bogdan

John Khvatov wrote:
> Hi Bogdan,
>
> On Sun, Nov 8, 2009 at 9:40 PM, Bogdan-Andrei Iancu
> <bogdan at voice-system.ro> wrote:
>   
>> Hi John,
>>
>> Thank you very much for your fixes and contribution - I already pushed them
>> into the SVN.
>>
>> If I understand correctly, you are the official maintainer of OpenSIPS on
>> fedora - if so, would you be interested in getting SVN access and officially
>> maintain the fedora packaging directly in the SVN tree ?
>>
>> Best regards,
>> Bogdan
>>
>>     
>
> Thanks for applying patches.
>
> Yes, I'm official maintainer of OpenSIPS on fedora (To verify You can
> send me a email to opensips-owner at fp :) ).
> And yes, it would be great to make changes directly in the SVN tree.
>
>   
>> John Khvatov wrote:
>>     
>>> Hello all.
>>>
>>> I'm opensips maintainer on fedora.
>>>
>>> This patch for init script to fix malformed comment block:
>>> http://dev.sgu.ru/fedora/opensips--init.patch
>>>
>>> Current spec file with new opensips modules:
>>> http://dev.sgu.ru/fedora/opensips.spec
>>>
>>> Consider to apply these changes to the upstream, please.
>>>
>>>
>>>       
>>     
>
>
> P.S. fp = fedoraproject.org
>   



From bogdan at voice-system.ro  Mon Nov  9 16:42:25 2009
From: bogdan at voice-system.ro (Bogdan-Andrei Iancu)
Date: Mon, 09 Nov 2009 15:42:25 +0000
Subject: [OpenSIPS-Devel] SF.net SVN: opensips:[6337] trunk/tls/tls_init.c
Message-ID: <E1N7WNt-0003lg-Gq@74yxhf1.ch3.sourceforge.com>

Revision: 6337
          http://opensips.svn.sourceforge.net/opensips/?rev=6337&view=rev
Author:   bogdan_iancu
Date:     2009-11-09 15:42:25 +0000 (Mon, 09 Nov 2009)

Log Message:
-----------
- upgraded the code to be compatible with the latest openssl version. backward compatibility preserved.
  Credits goto John Khvatov

Modified Paths:
--------------
    trunk/tls/tls_init.c


This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site.


From bogdan at voice-system.ro  Mon Nov  9 16:43:00 2009
From: bogdan at voice-system.ro (Bogdan-Andrei Iancu)
Date: Mon, 09 Nov 2009 15:43:00 +0000
Subject: [OpenSIPS-Devel] SF.net SVN: opensips:[6338]
	branches/1.6/tls/tls_init.c
Message-ID: <E1N7WOS-0003mQ-No@74yxhf1.ch3.sourceforge.com>

Revision: 6338
          http://opensips.svn.sourceforge.net/opensips/?rev=6338&view=rev
Author:   bogdan_iancu
Date:     2009-11-09 15:43:00 +0000 (Mon, 09 Nov 2009)

Log Message:
-----------
backport from trunk (rev #6337):

- upgraded the code to be compatible with the latest openssl version. backward c
ompatibility preserved.
  Credits goto John Khvatov

Revision Links:
--------------
    http://opensips.svn.sourceforge.net/opensips/?rev=6337&view=rev

Modified Paths:
--------------
    branches/1.6/tls/tls_init.c


This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site.


From bogdan at voice-system.ro  Mon Nov  9 16:43:25 2009
From: bogdan at voice-system.ro (Bogdan-Andrei Iancu)
Date: Mon, 09 Nov 2009 15:43:25 +0000
Subject: [OpenSIPS-Devel] SF.net SVN: opensips:[6339]
	branches/1.5/tls/tls_init.c
Message-ID: <E1N7WOr-0003mm-UV@74yxhf1.ch3.sourceforge.com>

Revision: 6339
          http://opensips.svn.sourceforge.net/opensips/?rev=6339&view=rev
Author:   bogdan_iancu
Date:     2009-11-09 15:43:25 +0000 (Mon, 09 Nov 2009)

Log Message:
-----------
backport from trunk (rev #6337):

- upgraded the code to be compatible with the latest openssl version. backward c
ompatibility preserved.
  Credits goto John Khvatov

Revision Links:
--------------
    http://opensips.svn.sourceforge.net/opensips/?rev=6337&view=rev

Modified Paths:
--------------
    branches/1.5/tls/tls_init.c


This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site.


From saul at ag-projects.com  Tue Nov 10 18:31:47 2009
From: saul at ag-projects.com (Saul Ibarra Corretge)
Date: Tue, 10 Nov 2009 18:31:47 +0100
Subject: [OpenSIPS-Devel] Adding support for 'dialog-rules'
Message-ID: <C2B3D8F9-C521-403C-B791-0FD244B5F0B6@ag-projects.com>

Hi,

As it was discussed earlier (http://www.openser.org/pipermail/devel/2009-July/003522.html) we are planning to support access rules for Event: dialog in the same fashion pres-rules do for Event: presence.

For achieving that I added support for dialog-rules to OpenXCAP. Along with it we need to choose a type number for this in xcap_client/xcap_callbacks.h The last used is 1<<4 for PIDF_MANIPULATION, so how about using 1<<5 for DIALOG_RULES?

In addition, the presence_dialoginfo module will be modified so it can handle the permissions stuff. Following presence_xml module I'd name the module parameter force_active.

If there are no constraints about this I'll go and implement it in presence_dialoginfo.


Best regards,


-- 
Saul Ibarra Corretge
AG Projects






From saul at ag-projects.com  Tue Nov 10 19:48:31 2009
From: saul at ag-projects.com (Saul Ibarra Corretge)
Date: Tue, 10 Nov 2009 19:48:31 +0100
Subject: [OpenSIPS-Devel] Adding support for 'dialog-rules'
In-Reply-To: <C2B3D8F9-C521-403C-B791-0FD244B5F0B6@ag-projects.com>
References: <C2B3D8F9-C521-403C-B791-0FD244B5F0B6@ag-projects.com>
Message-ID: <F224C28E-D284-45B0-8157-D09583E4CB60@ag-projects.com>


On Nov 10, 2009, at 6:31 PM, Saul Ibarra Corretge wrote:

> Hi,
> 
> As it was discussed earlier (http://www.openser.org/pipermail/devel/2009-July/003522.html) we are planning to support access rules for Event: dialog in the same fashion pres-rules do for Event: presence.
> 
> For achieving that I added support for dialog-rules to OpenXCAP. Along with it we need to choose a type number for this in xcap_client/xcap_callbacks.h The last used is 1<<4 for PIDF_MANIPULATION, so how about using 1<<5 for DIALOG_RULES?
> 
> In addition, the presence_dialoginfo module will be modified so it can handle the permissions stuff. Following presence_xml module I'd name the module parameter force_active.
> 
> If there are no constraints about this I'll go and implement it in presence_dialoginfo.
> 

By looking at the presence_xml module I think there are some parameters which could be shared between presence_xml and presece_dialoginfo: xcap_server. Should we have same options on both modules or is there any way to share it?

Thanks,

-- 
Saul Ibarra Corretge
AG Projects






From whitearchey at gmail.com  Wed Nov 11 09:02:54 2009
From: whitearchey at gmail.com (=?koi8-r?B?4dfEycXOy88g7cnIwcnM?=)
Date: Wed, 11 Nov 2009 16:02:54 +0800
Subject: [OpenSIPS-Devel] Patch for aaa_radius.c: memleak
Message-ID: <op.u270m0f3tqk0r3@whitewind_work.skysib.com>



Index: /home/whitewind/Projects/opensips/modules/aaa_radius/aaa_radius.c
===================================================================
---  
/home/whitewind/Projects/opensips/modules/aaa_radius/aaa_radius.c	(revision  
6339)
+++  
/home/whitewind/Projects/opensips/modules/aaa_radius/aaa_radius.c	(working  
copy)
@@ -383,28 +383,18 @@

  int send_auth_fixup(void** param, int param_no) {

-	str *s1, *s2;
+	str *s;

-	s1 = (str*) pkg_malloc(sizeof(str));
-	CHECK_ALLOC(s1);
+	s = (str*) pkg_malloc(sizeof(str));
+	CHECK_ALLOC(s);

-	s2 = (str*) pkg_malloc(sizeof(str));
-	CHECK_ALLOC(s2);
-
-	if (param_no == 1) {
-		s1->s = *param;
-		s1->len = strlen(s1->s);
-		*param = s1;
+	if (param_no == 1 || param_no == 2) {
+		s->s = *param;
+		s->len = strlen(s->s);
+		*param = s;
  		return 0;
  	}

-	if (param_no == 2) {
-		s2->s = *param;
-		s2->len = strlen(s2->s);
-		*param = s2;
-		return 0;
-	}
-
  	return E_UNSPEC;
  }



From anca at opensips.org  Wed Nov 11 09:27:10 2009
From: anca at opensips.org (Anca Vamanu)
Date: Wed, 11 Nov 2009 10:27:10 +0200
Subject: [OpenSIPS-Devel] Adding support for 'dialog-rules'
In-Reply-To: <F224C28E-D284-45B0-8157-D09583E4CB60@ag-projects.com>
References: <C2B3D8F9-C521-403C-B791-0FD244B5F0B6@ag-projects.com>
	<F224C28E-D284-45B0-8157-D09583E4CB60@ag-projects.com>
Message-ID: <4AFA755E.7060301@opensips.org>

Hi Saul,

No there are no constraints about this as there is no RFC :). If you 
wish to implement it, please go ahead. I think also that it is best to 
make it resemble the rules for presence as much as possible.
As for the question about sharing the parameters, it is not possible.
As a suggestion, if you require some entire functions(maybe modified a 
bit and with parametrized more) from presence_xml module you could 
instead of rewriting them in presence_dialoginfo module to export them 
from presence_xml and use them in presence_dialoginfo(as I did with 
presence and rls modules).

Regards,
Anca

Saul Ibarra Corretge wrote:
> On Nov 10, 2009, at 6:31 PM, Saul Ibarra Corretge wrote:
>
>   
>> Hi,
>>
>> As it was discussed earlier (http://www.openser.org/pipermail/devel/2009-July/003522.html) we are planning to support access rules for Event: dialog in the same fashion pres-rules do for Event: presence.
>>
>> For achieving that I added support for dialog-rules to OpenXCAP. Along with it we need to choose a type number for this in xcap_client/xcap_callbacks.h The last used is 1<<4 for PIDF_MANIPULATION, so how about using 1<<5 for DIALOG_RULES?
>>
>> In addition, the presence_dialoginfo module will be modified so it can handle the permissions stuff. Following presence_xml module I'd name the module parameter force_active.
>>
>> If there are no constraints about this I'll go and implement it in presence_dialoginfo.
>>
>>     
>
> By looking at the presence_xml module I think there are some parameters which could be shared between presence_xml and presece_dialoginfo: xcap_server. Should we have same options on both modules or is there any way to share it?
>
> Thanks,
>
>   



From noreply at sourceforge.net  Wed Nov 11 09:48:19 2009
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed, 11 Nov 2009 08:48:19 +0000
Subject: [OpenSIPS-Devel] [ opensips-Patches-2867994 ] Non-blocking AAA
	Accounting
Message-ID: <E1N88sF-00027N-PW@g45xhf1.ch3.sourceforge.com>

Patches item #2867994, was opened at 2009-09-27 11:34
Message generated for change (Comment added) made by cupotka2008
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086412&aid=2867994&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.6.x
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Alex Massover (cupotka2008)
Assigned to: Irina-Maria Stanescu (ironmissy)
Summary: Non-blocking AAA Accounting

Initial Comment:
Hi!

I know that OpenSIPS moves to asynchronous processing, but meanwhile I did this patch for me to make Radius accounting request non-blocking (anyway they return nothing).
The patch is against 1.5.3, but if you like it I'll prepare the same against the trunk (1.6).

----------------------------------------------------------------------

>Comment By: Alex Massover (cupotka2008)
Date: 2009-11-11 10:48

Message:
+ Not loosing accounting if can't create detached thread. In such case
accounting will happen in main thread in blocking mode.
- Removed old patch for 1.5.3

----------------------------------------------------------------------

Comment By: Alex Massover (cupotka2008)
Date: 2009-10-19 11:23

Message:
Added a full patch against 1.6:
- aaa accounting requests run in detached thread
- AAA API extended with log_aaa_message() function, it supposed to created
a well formatted string from aaa_message. The idea is to provide
comprehensive log for failed accounting request.

----------------------------------------------------------------------

Comment By: Alex Massover (cupotka2008)
Date: 2009-10-19 11:14

Message:
Added a full patch agains 1.6:


----------------------------------------------------------------------

Comment By: Alex Massover (cupotka2008)
Date: 2009-10-01 10:26

Message:
The acc module needs to be linked with -lrt

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086412&aid=2867994&group_id=232389


From bogdan at voice-system.ro  Wed Nov 11 18:48:02 2009
From: bogdan at voice-system.ro (Bogdan-Andrei Iancu)
Date: Wed, 11 Nov 2009 17:48:02 +0000
Subject: [OpenSIPS-Devel] SF.net SVN: opensips:[6340]
	trunk/modules/dispatcher/dispatch.c
Message-ID: <E1N8HIY-0005hI-6C@3kljzd1.ch3.sourceforge.com>

Revision: 6340
          http://opensips.svn.sourceforge.net/opensips/?rev=6340&view=rev
Author:   bogdan_iancu
Date:     2009-11-11 17:48:01 +0000 (Wed, 11 Nov 2009)

Log Message:
-----------
- fixed bogus test for return code of avp_add()

Modified Paths:
--------------
    trunk/modules/dispatcher/dispatch.c


This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site.


From bogdan at voice-system.ro  Wed Nov 11 18:58:17 2009
From: bogdan at voice-system.ro (Bogdan-Andrei Iancu)
Date: Wed, 11 Nov 2009 17:58:17 +0000
Subject: [OpenSIPS-Devel] SF.net SVN: opensips:[6341]
	branches/1.6/modules/dispatcher/dispatch.c
Message-ID: <E1N8HST-0005sZ-7y@3kljzd1.ch3.sourceforge.com>

Revision: 6341
          http://opensips.svn.sourceforge.net/opensips/?rev=6341&view=rev
Author:   bogdan_iancu
Date:     2009-11-11 17:58:16 +0000 (Wed, 11 Nov 2009)

Log Message:
-----------
backport from trunk (rev #6340):
- fixed bogus test for return code of avp_add()

Revision Links:
--------------
    http://opensips.svn.sourceforge.net/opensips/?rev=6340&view=rev

Modified Paths:
--------------
    branches/1.6/modules/dispatcher/dispatch.c


This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site.


From ivaxer at gmail.com  Fri Nov 13 10:38:43 2009
From: ivaxer at gmail.com (John Khvatov)
Date: Fri, 13 Nov 2009 12:38:43 +0300
Subject: [OpenSIPS-Devel] fedora rpm package
In-Reply-To: <4AF83734.8050900@voice-system.ro>
References: <20091103142932.GB9075@aki.main.sgu.ru>
	<4AF7108E.6090503@voice-system.ro> 
	<628ff2820911081232n6e85c19ds5fb90257716beb02@mail.gmail.com> 
	<4AF83734.8050900@voice-system.ro>
Message-ID: <628ff2820911130138h6f039197xcf70c29d9729869e@mail.gmail.com>

Hi Bogdan,

On Mon, Nov 9, 2009 at 6:37 PM, Bogdan-Andrei Iancu
<bogdan at voice-system.ro> wrote:
> Hi John,
>
> Just send me the SourForge ID to add you to the project.
>
> Regards,
> Bogdan

My SF id is 2387889.


-- 
WBR, John Khvatov


From adragus at opensips.org  Fri Nov 13 16:04:07 2009
From: adragus at opensips.org (Andrei Dragus)
Date: Fri, 13 Nov 2009 17:04:07 +0200
Subject: [OpenSIPS-Devel] [Improvement]Speed-up in user location
Message-ID: <4AFD7567.7080500@opensips.org>

Hi all,

A new version of the usrloc module has been added to OpenSIPS trunk.
What is added when compared to the old version:
       - user location queries are now faster ( up to 3 times faster)
       - user location queries now take a constant amount of time 
regardless of the number
of registered users.

For a comparison between the two versions go to:
http://www.opensips.org/Resources/TestsUsrloc

Hope you find this useful.

-- 
Andrei Dragus
www.voice-system.ro 



From noreply at sourceforge.net  Sat Nov 14 13:08:24 2009
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat, 14 Nov 2009 12:08:24 +0000
Subject: [OpenSIPS-Devel] [ opensips-Bugs-2897651 ] config.h parameters not
	reflecting
Message-ID: <E1N9HQW-0002yY-Eg@3bkjzd1.ch3.sourceforge.com>

Bugs item #2897651, was opened at 2009-11-14 17:38
Message generated for change (Tracker Item Submitted) made by ranahimal
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=2897651&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: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Himal Rana (ranahimal)
Assigned to: Nobody/Anonymous (nobody)
Summary: config.h parameters not reflecting

Initial Comment:
Setting parameters in config.h parameters does not reflected in complied  binary.

Version  tested : 1.5.X  , 1.6.0

OS : RHEL 5.4 Fedora  11 Centos 5.4

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=2897651&group_id=232389


From noreply at sourceforge.net  Sun Nov 15 18:45:36 2009
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun, 15 Nov 2009 17:45:36 +0000
Subject: [OpenSIPS-Devel] [ opensips-Bugs-2898097 ] b2bua retransmits 200 OK
	even after ACK received
Message-ID: <E1N9jAO-0001cE-Fz@1bkjzd1.ch3.sourceforge.com>

Bugs item #2898097, was opened at 2009-11-15 12:45
Message generated for change (Tracker Item Submitted) made by sokhapkin
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=2898097&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: Sergey Okhapkin (sokhapkin)
Assigned to: Nobody/Anonymous (nobody)
Summary: b2bua retransmits 200 OK even after ACK received

Initial Comment:
B2bua in topology hide mode sits betweeb UAC and UAS. UAC sends INVITE to b2bua, b2bus forwards INVITE to UAS. UAS replies with 200 OK, b2bua forwards the reply to UAC, UAC sends ACK to b2bua, but b2bua sends 200 OK to UAC again and again.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=2898097&group_id=232389


From bogdan at voice-system.ro  Sun Nov 15 18:58:09 2009
From: bogdan at voice-system.ro (Bogdan-Andrei Iancu)
Date: Sun, 15 Nov 2009 19:58:09 +0200
Subject: [OpenSIPS-Devel] segmenfault in db_mysql_do_prepared_query
In-Reply-To: <cc1f582e0910280929i58f2b181t4103f86cee47109c@mail.gmail.com>
References: <cc1f582e0910280929i58f2b181t4103f86cee47109c@mail.gmail.com>
Message-ID: <4B004131.2090507@voice-system.ro>

Hi Inaki,

Sorry for late reply. Before the crash, is there any indication in the 
log about  a DB re-connect event (or other DB related events)?

Do you still have the core file and the corresponding binaries ? I will 
be very helpful in tracing the issue.

Thanks and regards,
Bogdan


I?aki Baz Castillo wrote:
> Hi, opensips trunk rev 5738 working as presence server. It was running
> properly (note that there is no traffic yet, just some times). But 8
> days ago there was a segmenfault:
>
>
> (gdb) bt full
> #0  0x00007fc95c7f7197 in memcpy () from /lib/libc.so.6
> No symbol table info available.
> #1  0x00007fc95bfa14d1 in mysql_stmt_bind_param () from
> /usr/lib/libmysqlclient.so.15
> No symbol table info available.
> #2  0x00007fc95c3564fb in db_mysql_do_prepared_query (conn=0x734fe8,
> query=0x7fc95c56d6f0, v=0x7fff650ff1c0, n=9, uv=0x0, un=0) at
> dbase.c:497
>         i = 0
>         code = 9
>         cols = 7571504
>         pq_ptr = (struct prep_stmt *) 0x73c2e8
>         ctx = (struct my_stmt_ctx *) 0x73b950
>         mysql_bind = (MYSQL_BIND *) 0x73c328
>         id = <value optimized out>
>         __FUNCTION__ = "db_mysql_do_prepared_query"
> #3  0x00007fc95c357c86 in db_mysql_query (_h=0x734fe8,
> _k=0x7fff650ff300, _op=0x0, _v=0x7fff650ff1c0, _c=0x7fff650ff350,
> _n=9, _nc=7, _o=0x0, _r=0x7fff650ff3a8) at dbase.c:763
>         ret = 0
>         __FUNCTION__ = "db_mysql_query"
> #4  0x00007fc95a5cbd53 in get_database_info (msg=<value optimized
> out>, subs=0x7fff650ff5f0, reply_code=0x7fff650ff724,
> reply_str=0x7fff650ff700) at subscribe.c:1222
>         query_cols = {0x7fc95a7d5b90, 0x7fc95a7d5bd0, 0x7fc95a7d5be0,
> 0x7fc95a7d5bf0, 0x7fc95a7d5c10, 0x7fc95a7d5c00, 0x7fc95a7d5c50,
> 0x7fc95a7d5c40, 0x7fc95a7d5c30, 0x40}
>         query_vals = {{type = DB_STR, nul = 0, free = 1554811360, val
> = {int_val = 7352181, double_val = 3.6324600541067419e-317, time_val =
> 7352181,
>       string_val = 0x702f75
> "500 at sip.mydomain.net>;tag=13b52bc3e9f25b251a1546eb57a3a45c-28f3\r\nCall-ID:
> 3743611798 at 10.134.16.230\r\nCSeq: 30 SUBSCRIBE\r\nContact:
> <sip:30001 at 222.111.253.254:52189>\r\nMax-Forwards: 68\r\nEvent:
> presence\r\nU"..., str_val = {
>         s = 0x702f75
> "500 at sip.mydomain.net>;tag=13b52bc3e9f25b251a1546eb57a3a45c-28f3\r\nCall-ID:
> 3743611798 at 10.134.16.230\r\nCSeq: 30 SUBSCRIBE\r\nContact:
> <sip:30001 at 222.111.253.254:52189>\r\nMax-Forwards: 68\r\nEvent:
> presence\r\nU"..., len = 3}, blob_val = {
>         s = 0x702f75
> "500 at sip.mydomain.net>;tag=13b52bc3e9f25b251a1546eb57a3a45c-28f3\r\nCall-ID:
> 3743611798 at 10.134.16.230\r\nCSeq: 30 SUBSCRIBE\r\nContact:
> <sip:30001 at 222.111.253.254:52189>\r\nMax-Forwards: 68\r\nEvent:
> presence\r\nU"..., len = 3}, bitmap_val = 7352181}}, {type = DB_STR,
> nul = 0, free = 1695544080, val = {int_val = 7352185,
>       double_val = 3.6324620303693252e-317, time_val = 7352185,
>       string_val = 0x702f79
> "sip.mydomain.net>;tag=13b52bc3e9f25b251a1546eb57a3a45c-28f3\r\nCall-ID:
> 3743611798 at 10.134.16.230\r\nCSeq: 30 SUBSCRIBE\r\nContact:
> <sip:30001 at 222.111.253.254:52189>\r\nMax-Forwards: 68\r\nEvent:
> presence\r\nUser-"..., str_val = {
>         s = 0x702f79
> "sip.mydomain.net>;tag=13b52bc3e9f25b251a1546eb57a3a45c-28f3\r\nCall-ID:
> 3743611798 at 10.134.16.230\r\nCSeq: 30 SUBSCRIBE\r\nContact:
> <sip:30001 at 222.111.253.254:52189>\r\nMax-Forwards: 68\r\nEvent:
> presence\r\nUser-"..., len = 16}, blob_val = {
>         s = 0x702f79
> "sip.mydomain.net>;tag=13b52bc3e9f25b251a1546eb57a3a45c-28f3\r\nCall-ID:
> 3743611798 at 10.134.16.230\r\nCSeq: 30 SUBSCRIBE\r\nContact:
> <sip:30001 at 222.111.253.254:52189>\r\nMax-Forwards: 68\r\nEvent:
> presence\r\nUser-"..., len = 16}, bitmap_val = 7352185}}, {type =
> DB_STR, nul = 0, free = 1552178514, val = {int_val = 7352132,
>       double_val = 3.6324358448900956e-317, time_val = 7352132,
>       string_val = 0x702f44
> "30001 at sip.mydomain.net>;tag=2341707388\r\nTo:
> <sip:500 at sip.mydomain.net>;tag=13b52bc3e9f25b251a1546eb57a3a45c-28f3\r\nCall-ID:
> 3743611798 at 10.134.16.230\r\nCSeq: 30 SUBSCRIBE\r\nContact:
> <sip:30001 at 222.111.253"..., str_val = {
>
>
> Is it known bug?
>
>   



From noreply at sourceforge.net  Sun Nov 15 19:03:40 2009
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun, 15 Nov 2009 18:03:40 +0000
Subject: [OpenSIPS-Devel] [ opensips-Patches-2887877 ] nathelper : allow
	millisecond timeout for Rtpproxy reply
Message-ID: <E1N9jRs-00028T-Ot@565xhf1.ch3.sourceforge.com>

Patches item #2887877, was opened at 2009-10-28 14:29
Message generated for change (Comment added) made by bogdan_iancu
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086412&aid=2887877&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: Invalid
Priority: 5
Private: No
Submitted By: Christophe Sollet (csollet)
Assigned to: Bogdan-Andrei Iancu (bogdan_iancu)
Summary: nathelper : allow millisecond timeout for Rtpproxy reply

Initial Comment:
Hello,

Current parameter 'rtpproxy_tout' can be used to set a timeout with second resolution.

Sadly, one second is generally too long to wait generating a lot of SIP retransmission

This patch add a 'rtpproxy_tout_ms' parameter to set a timeout with millisecond resolution. The used timeout become (rtpproxy_tout * 1000) + rtpproxy_tout_ms)

Setting 'rtpproxy_tout' to 0, this new parameter can be used to set a sub second timeout.

----------------------------------------------------------------------

>Comment By: Bogdan-Andrei Iancu (bogdan_iancu)
Date: 2009-11-15 20:03

Message:
Replaced by #2893189

----------------------------------------------------------------------

Comment By: Christophe Sollet (cfc)
Date: 2009-11-06 12:38

Message:
Hi Bogdan,

New patch that follow your last comment is ready. I will upload it as a
new one as it seems I can't upload on this one.

Regards,
Christophe.

----------------------------------------------------------------------

Comment By: Bogdan-Andrei Iancu (bogdan_iancu)
Date: 2009-10-30 13:22

Message:
I was thinking also about BC, but mixing two params may be even more
confusing.

if we change it to accept floating vals, we need to change the type of the
param from INT to STR (modparam does not natively support floats)....So, if
we have to change something and to have BC, I suggest:
- adding a new param 'rtpproxy_timeout' - accepts an INT with full timeout
in milisecs
- 'rtpproxy_tout' will be keept, but warning will be fired if used (as
will become obsolete)
- if both are used from the script, some error should be fired...

What do you say?

Regards,
Bogdan

----------------------------------------------------------------------

Comment By: Christophe Sollet (csollet)
Date: 2009-10-30 13:13

Message:
Hi Bogdan,

In fact, our first implementation  was just to change to millisecond. This
new attribute was added only to keep BC.
But you're right, the best solution is to accept floating numbers. New
patch will come next week.

Regards,
Christophe.


----------------------------------------------------------------------

Comment By: Bogdan-Andrei Iancu (bogdan_iancu)
Date: 2009-10-30 13:04

Message:
Hi Christophe,

Thanks for the patch - shouldn't be simpler to use only one parameter
('rtpproxy_tout') and to change the value from secs to milisecs ? or to
keep secs, but to accept floating numbers ("0.01") ?

Regards,
Bogdan

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086412&aid=2887877&group_id=232389


From noreply at sourceforge.net  Sun Nov 15 19:04:22 2009
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun, 15 Nov 2009 18:04:22 +0000
Subject: [OpenSIPS-Devel] [ opensips-Patches-2893189 ] nathelper : add
	rtpproxy_timeout param
Message-ID: <E1N9jSY-00029M-Td@565xhf1.ch3.sourceforge.com>

Patches item #2893189, was opened at 2009-11-06 12:40
Message generated for change (Comment added) made by bogdan_iancu
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086412&aid=2893189&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: Accepted
Priority: 5
Private: No
Submitted By: Christophe Sollet (cfc)
>Assigned to: Bogdan-Andrei Iancu (bogdan_iancu)
Summary: nathelper : add rtpproxy_timeout param

Initial Comment:
see 2887877 for details.

----------------------------------------------------------------------

>Comment By: Bogdan-Andrei Iancu (bogdan_iancu)
Date: 2009-11-15 20:04

Message:
I will overview the patch asap.

Thanks Christophe for your work.

Best regards,
Bogdan

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086412&aid=2893189&group_id=232389


From noreply at sourceforge.net  Sun Nov 15 19:39:33 2009
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun, 15 Nov 2009 18:39:33 +0000
Subject: [OpenSIPS-Devel] [ opensips-Feature Requests-2893576 ] Inverse
	Codec Match
Message-ID: <E1N9k0b-0002pe-Ry@565xhf1.ch3.sourceforge.com>

Feature Requests item #2893576, was opened at 2009-11-06 23:44
Message generated for change (Settings changed) made by bogdan_iancu
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086413&aid=2893576&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
Priority: 5
Private: No
Submitted By: Ryan Bullock (rrb3942)
>Assigned to: Andrei Dragus (andreidragus)
Summary: Inverse Codec Match

Initial Comment:
The new codec functions in textops are awesome. However there is one feature I would like to see.

Currently there is codec_delete_re() and codec_exists_re that lets you delete and check for any codecs that match a regular expression.

If would be nice if there was the ability to also delete codecs that do NOT match an expression, perhaps through a option. This would allow you to enforce a list of supported codecs only. Right now to remove all other codecs would need an exhaustive list of what to remove (or some really awful inverse regex that would be confusing to write/read, if it is even possible to write)

For example, if you only want to permit G711 and G729 you could do something like the following to remove any other codecs:

codec_delete_re("[gG]711|[gG]729", v) 

And the only codecs left would be G711 and G729 in the message. Or if it had only g711 and say speex, you would be left with only g711.

One would of course have to be careful to not remove telephony-events as well, but that should be up to the script writer.

I think this would be useful only for the codec_exists_re and codec_delete_re, so you could check for, and remove any foreign codecs.

codec_move_up_re and codec_move_down_re are already their inverses (for the most part).

Also a case insensitive option for the regex might be nice. But that would just be more icing on the cake.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086413&aid=2893576&group_id=232389


From ibc at aliax.net  Sun Nov 15 20:57:54 2009
From: ibc at aliax.net (=?iso-8859-1?q?I=F1aki_Baz_Castillo?=)
Date: Sun, 15 Nov 2009 20:57:54 +0100
Subject: [OpenSIPS-Devel] Adding support for 'dialog-rules'
In-Reply-To: <C2B3D8F9-C521-403C-B791-0FD244B5F0B6@ag-projects.com>
References: <C2B3D8F9-C521-403C-B791-0FD244B5F0B6@ag-projects.com>
Message-ID: <200911152057.54855.ibc@aliax.net>

El Martes, 10 de Noviembre de 2009, Saul Ibarra Corretge escribi?:
> As it was discussed earlier
>  (http://www.openser.org/pipermail/devel/2009-July/003522.html) we are
>  planning to support access rules for Event: dialog in the same fashion
>  pres-rules do for Event: presence.

So we'll end with two components supporting this non estandar feature: 
OpenXCAP as XCAP server and OpenSIPS as SIP presence server. And I expect that 
Blink (SIP/XCAP softphone) will also implement it.

Proprietary appplications on top of open source software. Not so great IMHO.

Also, what does it mean "using like pres-rules format"? pres-rules format (RFC 
5025) is more than "uri A => allow", uri B => block". It allows filtering the 
notified information (however it's not used at all). But this could be useful 
for dialog-info event ("I allow alice to monitor call to me, but not call made 
by me" or "I allow bob to also monitor calls made by me, but he cannot know 
how I call"). These filetering features are also suggested in RFC 4235.

It would be great if a draft is written with this specification instead of 
just coding a propietary feature (IMHO).

Regards.


-- 
I?aki Baz Castillo <ibc at aliax.net>


From saul at ag-projects.com  Mon Nov 16 00:00:42 2009
From: saul at ag-projects.com (Saul Ibarra Corretge)
Date: Mon, 16 Nov 2009 00:00:42 +0100
Subject: [OpenSIPS-Devel] Adding support for 'dialog-rules'
In-Reply-To: <200911152057.54855.ibc@aliax.net>
References: <C2B3D8F9-C521-403C-B791-0FD244B5F0B6@ag-projects.com>
	<200911152057.54855.ibc@aliax.net>
Message-ID: <B503AD4B-C27A-47FF-89E1-8ED0EDE0778B@ag-projects.com>


On Nov 15, 2009, at 8:57 PM, I?aki Baz Castillo wrote:

> El Martes, 10 de Noviembre de 2009, Saul Ibarra Corretge escribi?:
>> As it was discussed earlier
>> (http://www.openser.org/pipermail/devel/2009-July/003522.html) we are
>> planning to support access rules for Event: dialog in the same fashion
>> pres-rules do for Event: presence.
> 
> So we'll end with two components supporting this non estandar feature: 
> OpenXCAP as XCAP server and OpenSIPS as SIP presence server. And I expect that 
> Blink (SIP/XCAP softphone) will also implement it.
> 
> Proprietary appplications on top of open source software. Not so great IMHO.
> 

Every piece of software involved is Open Source, so no 'propietary' application is being developed.

> Also, what does it mean "using like pres-rules format"? pres-rules format (RFC 
> 5025) is more than "uri A => allow", uri B => block". It allows filtering the 
> notified information (however it's not used at all). But this could be useful 
> for dialog-info event ("I allow alice to monitor call to me, but not call made 
> by me" or "I allow bob to also monitor calls made by me, but he cannot know 
> how I call"). These filetering features are also suggested in RFC 4235.
> 
> It would be great if a draft is written with this specification instead of 
> just coding a propietary feature (IMHO).
> 

There is a lack of a standard in dealing this way with dialog-info, so we'll use the same schema as pre-rules to achieve same functionality: permissions for the dialog-info presence events.

If this feature get's standardized or covered on an RFC, we'll modify it so if fits. 


-- 
Saul Ibarra Corretge
AG Projects






From ibc at aliax.net  Mon Nov 16 00:30:20 2009
From: ibc at aliax.net (=?iso-8859-1?q?I=F1aki_Baz_Castillo?=)
Date: Mon, 16 Nov 2009 00:30:20 +0100
Subject: [OpenSIPS-Devel] Adding support for 'dialog-rules'
In-Reply-To: <B503AD4B-C27A-47FF-89E1-8ED0EDE0778B@ag-projects.com>
References: <C2B3D8F9-C521-403C-B791-0FD244B5F0B6@ag-projects.com>
	<200911152057.54855.ibc@aliax.net>
	<B503AD4B-C27A-47FF-89E1-8ED0EDE0778B@ag-projects.com>
Message-ID: <200911160030.20398.ibc@aliax.net>

El Lunes, 16 de Noviembre de 2009, Saul Ibarra Corretge escribi?:
> > Proprietary appplications on top of open source software. Not so great
> > IMHO.
> 
> Every piece of software involved is Open Source, so no 'propietary'
>  application is being developed.

With "propietary" I mean "non standard". It's not required to be "privative" 
in order to be "propietary".
For example, Asterisk Manager Interface (AMI) is a propietary protocol even if 
it's implemented as open source.

 
> > Also, what does it mean "using like pres-rules format"? pres-rules format
> > (RFC 5025) is more than "uri A => allow", uri B => block". It allows
> > filtering the notified information (however it's not used at all). But
> > this could be useful for dialog-info event ("I allow alice to monitor
> > call to me, but not call made by me" or "I allow bob to also monitor
> > calls made by me, but he cannot know how I call"). These filetering
> > features are also suggested in RFC 4235.
> >
> > It would be great if a draft is written with this specification instead
> > of just coding a propietary feature (IMHO).
> 
> There is a lack of a standard in dealing this way with dialog-info, so
>  we'll use the same schema as pre-rules to achieve same functionality:
>  permissions for the dialog-info presence events.

I fully agree.

 
> If this feature get's standardized or covered on an RFC, we'll modify it so
>  if fits.

As a suggestion, you could elaborate a draft with such specifications as it 
seems there is no IETF people interested in this feature.

Regards.
 


-- 
I?aki Baz Castillo <ibc at aliax.net>


From noreply at sourceforge.net  Mon Nov 16 09:38:40 2009
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 16 Nov 2009 08:38:40 +0000
Subject: [OpenSIPS-Devel] [ opensips-Bugs-2897651 ] config.h parameters not
	reflecting
Message-ID: <E1N9x6e-0006X3-L8@b55xhf1.ch3.sourceforge.com>

Bugs item #2897651, was opened at 2009-11-14 14:08
Message generated for change (Comment added) made by bogdan_iancu
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=2897651&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: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Himal Rana (ranahimal)
>Assigned to: Bogdan-Andrei Iancu (bogdan_iancu)
Summary: config.h parameters not reflecting

Initial Comment:
Setting parameters in config.h parameters does not reflected in complied  binary.

Version  tested : 1.5.X  , 1.6.0

OS : RHEL 5.4 Fedora  11 Centos 5.4

----------------------------------------------------------------------

>Comment By: Bogdan-Andrei Iancu (bogdan_iancu)
Date: 2009-11-16 10:38

Message:
Hi Himal,
what parameters you tried to change and did not work? How you tested that
the param actually did not work?

Regards,
Bogdan

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=2897651&group_id=232389


From ironmissy at gmail.com  Mon Nov 16 17:09:07 2009
From: ironmissy at gmail.com (Irina-Maria Stanescu)
Date: Mon, 16 Nov 2009 16:09:07 +0000
Subject: [OpenSIPS-Devel] SF.net SVN: opensips:[6342]
	trunk/modules/aaa_radius/aaa_radius.c
Message-ID: <E1NA48Z-0007aY-PJ@dn4whf1.ch3.sourceforge.com>

Revision: 6342
          http://opensips.svn.sourceforge.net/opensips/?rev=6342&view=rev
Author:   ironmissy
Date:     2009-11-16 16:08:59 +0000 (Mon, 16 Nov 2009)

Log Message:
-----------
- applied patch from ?\208?\144?\208?\178?\208?\180?\208?\184?\208?\181?\208?\189?\208?\186?\208?\190 ?\208?\156?\208?\184?\209?\133?\208?\176?\208?\184?\208?\187 (fixes minor memleak)

Modified Paths:
--------------
    trunk/modules/aaa_radius/aaa_radius.c


This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site.


From noreply at sourceforge.net  Mon Nov 16 18:24:12 2009
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 16 Nov 2009 17:24:12 +0000
Subject: [OpenSIPS-Devel] [ opensips-Bugs-2898097 ] b2bua retransmits 200 OK
	even after ACK received
Message-ID: <E1NA5JE-0005AN-BQ@565xhf1.ch3.sourceforge.com>

Bugs item #2898097, was opened at 2009-11-15 19:45
Message generated for change (Settings changed) made by bogdan_iancu
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=2898097&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: Sergey Okhapkin (sokhapkin)
>Assigned to: Anca Vamanu (anca_vamanu)
Summary: b2bua retransmits 200 OK even after ACK received

Initial Comment:
B2bua in topology hide mode sits betweeb UAC and UAS. UAC sends INVITE to b2bua, b2bus forwards INVITE to UAS. UAS replies with 200 OK, b2bua forwards the reply to UAC, UAC sends ACK to b2bua, but b2bua sends 200 OK to UAC again and again.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=2898097&group_id=232389


From noreply at sourceforge.net  Mon Nov 16 19:14:56 2009
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 16 Nov 2009 18:14:56 +0000
Subject: [OpenSIPS-Devel] [ opensips-Bugs-2897651 ] config.h parameters not
	reflecting
Message-ID: <E1NA66K-0006Yy-18@565xhf1.ch3.sourceforge.com>

Bugs item #2897651, was opened at 2009-11-14 17:38
Message generated for change (Comment added) made by ranahimal
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=2897651&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: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Himal Rana (ranahimal)
Assigned to: Bogdan-Andrei Iancu (bogdan_iancu)
Summary: config.h parameters not reflecting

Initial Comment:
Setting parameters in config.h parameters does not reflected in complied  binary.

Version  tested : 1.5.X  , 1.6.0

OS : RHEL 5.4 Fedora  11 Centos 5.4

----------------------------------------------------------------------

>Comment By: Himal Rana (ranahimal)
Date: 2009-11-16 23:44

Message:
Dear Bogdan,
I was trying to set following parameters:

PKG_MEM_POOL_SIZE
SHM_MEM_SIZE

Thanks,
Himal 

----------------------------------------------------------------------

Comment By: Bogdan-Andrei Iancu (bogdan_iancu)
Date: 2009-11-16 14:08

Message:
Hi Himal,
what parameters you tried to change and did not work? How you tested that
the param actually did not work?

Regards,
Bogdan

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=2897651&group_id=232389


From noreply at sourceforge.net  Mon Nov 16 19:16:38 2009
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 16 Nov 2009 18:16:38 +0000
Subject: [OpenSIPS-Devel] [ opensips-Bugs-2897651 ] config.h parameters not
	reflecting
Message-ID: <E1NA67y-0007Iq-1Y@3bkjzd1.ch3.sourceforge.com>

Bugs item #2897651, was opened at 2009-11-14 17:38
Message generated for change (Comment added) made by ranahimal
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=2897651&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: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Himal Rana (ranahimal)
Assigned to: Bogdan-Andrei Iancu (bogdan_iancu)
Summary: config.h parameters not reflecting

Initial Comment:
Setting parameters in config.h parameters does not reflected in complied  binary.

Version  tested : 1.5.X  , 1.6.0

OS : RHEL 5.4 Fedora  11 Centos 5.4

----------------------------------------------------------------------

>Comment By: Himal Rana (ranahimal)
Date: 2009-11-16 23:46

Message:
Dear Bogdan,

I was complie using following shell command.

make all



----------------------------------------------------------------------

Comment By: Himal Rana (ranahimal)
Date: 2009-11-16 23:44

Message:
Dear Bogdan,
I was trying to set following parameters:

PKG_MEM_POOL_SIZE
SHM_MEM_SIZE

Thanks,
Himal 

----------------------------------------------------------------------

Comment By: Bogdan-Andrei Iancu (bogdan_iancu)
Date: 2009-11-16 14:08

Message:
Hi Himal,
what parameters you tried to change and did not work? How you tested that
the param actually did not work?

Regards,
Bogdan

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=2897651&group_id=232389


From ag at ag-projects.com  Mon Nov 16 19:19:59 2009
From: ag at ag-projects.com (Adrian Georgescu)
Date: Mon, 16 Nov 2009 19:19:59 +0100
Subject: [OpenSIPS-Devel] Adding support for 'dialog-rules'
In-Reply-To: <200911152057.54855.ibc@aliax.net>
References: <C2B3D8F9-C521-403C-B791-0FD244B5F0B6@ag-projects.com>
	<200911152057.54855.ibc@aliax.net>
Message-ID: <B1AD2BF3-539A-49B3-A631-6E7CE064E4BD@ag-projects.com>

Inaki,

One of the IETF goals is to make protocols extensible without having  
to go back to the standards body for adding new stuff. In SIP you can  
an extra header for instance without breaking anything and without  
having to standardize it either.

This is one example for extending the usage of the standard common- 
policy. It takes 5 lines of code to use it for other useful purposes.   
It means that IETF did something good in the end.

--
Adrian





On Nov 15, 2009, at 8:57 PM, I?aki Baz Castillo wrote:

> El Martes, 10 de Noviembre de 2009, Saul Ibarra Corretge escribi?:
>> As it was discussed earlier
>> (http://www.openser.org/pipermail/devel/2009-July/003522.html) we are
>> planning to support access rules for Event: dialog in the same  
>> fashion
>> pres-rules do for Event: presence.
>
> So we'll end with two components supporting this non estandar feature:
> OpenXCAP as XCAP server and OpenSIPS as SIP presence server. And I  
> expect that
> Blink (SIP/XCAP softphone) will also implement it.
>
> Proprietary appplications on top of open source software. Not so  
> great IMHO.
>
> Also, what does it mean "using like pres-rules format"? pres-rules  
> format (RFC
> 5025) is more than "uri A => allow", uri B => block". It allows  
> filtering the
> notified information (however it's not used at all). But this could  
> be useful
> for dialog-info event ("I allow alice to monitor call to me, but not  
> call made
> by me" or "I allow bob to also monitor calls made by me, but he  
> cannot know
> how I call"). These filetering features are also suggested in RFC  
> 4235.
>
> It would be great if a draft is written with this specification  
> instead of
> just coding a propietary feature (IMHO).
>
> Regards.
>
>
> -- 
> I?aki Baz Castillo <ibc at aliax.net>
>
> _______________________________________________
> Devel mailing list
> Devel at lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/devel



From ibc at aliax.net  Tue Nov 17 01:56:04 2009
From: ibc at aliax.net (=?iso-8859-1?q?I=F1aki_Baz_Castillo?=)
Date: Tue, 17 Nov 2009 01:56:04 +0100
Subject: [OpenSIPS-Devel] Adding support for 'dialog-rules'
In-Reply-To: <B1AD2BF3-539A-49B3-A631-6E7CE064E4BD@ag-projects.com>
References: <C2B3D8F9-C521-403C-B791-0FD244B5F0B6@ag-projects.com>
	<200911152057.54855.ibc@aliax.net>
	<B1AD2BF3-539A-49B3-A631-6E7CE064E4BD@ag-projects.com>
Message-ID: <200911170156.05065.ibc@aliax.net>

El Lunes, 16 de Noviembre de 2009, Adrian Georgescu escribi?:
> Inaki,
> 
> One of the IETF goals is to make protocols extensible without having
> to go back to the standards body for adding new stuff. In SIP you can
> an extra header for instance without breaking anything and without
> having to standardize it either.
> 
> This is one example for extending the usage of the standard common-
> policy. It takes 5 lines of code to use it for other useful purposes.
> It means that IETF did something good in the end.

Well, IETF's pres-rules is not something good IMHO as it's a half-done 
specification that creates, for sure, interoperability problems. In fact I 
would say that IETF pres-rules is a big pain.

The main problem is that the pres-rules XML format is not stricted at all so 
client A can generate a correct pres-rules document but client B couldn't read 
it as it would generate a pres-rules document with same meaning in a very 
different way.

I remember that IETF doesn't specify at all the format of pres-rules document. 
Some vendors (as Counterpath or you, AG) use two <rules> sections 
("pres_whitelist" with action "allow" and "pres_blacklist" with action 
"block"). In this way interoperability """works""" when just Counterpath or AG 
software is involved. I would like to know what happens if Eyebeam or 
SipSimpleClient gets, via XCAP, a pres-rules document with lots of <rule> 
sections and <many> (not just <one>) in <condition> sections. Some 
<transformation> would be also cool...
For sure they would ignore or would interpret wrongly the meaning of the 
document. But the pres-rules document is 100% valid according to the RFC.

So, we have a half-done specification, pres-rules, and now a custom 
specification (pres-dialog-rules) based on it, so keeping all the issues I've 
explained above. This is the reason why I don't like a lot this new feature.

Regards.



-- 
I?aki Baz Castillo <ibc at aliax.net>


From di-shi at transnexus.com  Wed Nov 18 03:45:20 2009
From: di-shi at transnexus.com (Di-Shi Sun)
Date: Wed, 18 Nov 2009 02:45:20 +0000
Subject: [OpenSIPS-Devel] SF.net SVN: opensips:[6343]
	trunk/modules/osp/etc/sample-osp-opensips.cfg
Message-ID: <E1NAaXo-0000Ts-Uv@74yxhf1.ch3.sourceforge.com>

Revision: 6343
          http://opensips.svn.sourceforge.net/opensips/?rev=6343&view=rev
Author:   di-shi
Date:     2009-11-18 02:45:20 +0000 (Wed, 18 Nov 2009)

Log Message:
-----------
Fixed a running error message by adding null string check.

Modified Paths:
--------------
    trunk/modules/osp/etc/sample-osp-opensips.cfg


This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site.


From noreply at sourceforge.net  Wed Nov 18 04:01:40 2009
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed, 18 Nov 2009 03:01:40 +0000
Subject: [OpenSIPS-Devel] [ opensips-Bugs-2899555 ] osp module running time
	error messages
Message-ID: <E1NAanc-00057q-G2@1bkjzd1.ch3.sourceforge.com>

Bugs item #2899555, was opened at 2009-11-17 22:01
Message generated for change (Tracker Item Submitted) made by di-shi
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=2899555&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: 5
Private: No
Submitted By: Di-Shi Sun (di-shi)
Assigned to: Nobody/Anonymous (nobody)
Summary: osp module running time error messages

Initial Comment:
The sample configuration does not check $hdr null string for network ID. It may cause running time error messages like 

Nov 17 21:33:46 e520 ./opensips[17750]: Requesting OSP authorization and routing
Nov 17 21:33:46 e520 ./opensips[17750]: ERROR:core:do_assign: no value in right expression
Nov 17 21:33:46 e520 ./opensips[17750]: ERROR:core:do_assign: error at line: 490


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=2899555&group_id=232389


From noreply at sourceforge.net  Wed Nov 18 04:04:19 2009
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed, 18 Nov 2009 03:04:19 +0000
Subject: [OpenSIPS-Devel] [ opensips-Bugs-2899555 ] osp module running time
	error messages
Message-ID: <E1NAaqB-0005Hr-I0@1bkjzd1.ch3.sourceforge.com>

Bugs item #2899555, was opened at 2009-11-17 22:01
Message generated for change (Comment added) made by di-shi
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=2899555&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: 5
Private: No
Submitted By: Di-Shi Sun (di-shi)
>Assigned to: Di-Shi Sun (di-shi)
Summary: osp module running time error messages

Initial Comment:
The sample configuration does not check $hdr null string for network ID. It may cause running time error messages like 

Nov 17 21:33:46 e520 ./opensips[17750]: Requesting OSP authorization and routing
Nov 17 21:33:46 e520 ./opensips[17750]: ERROR:core:do_assign: no value in right expression
Nov 17 21:33:46 e520 ./opensips[17750]: ERROR:core:do_assign: error at line: 490


----------------------------------------------------------------------

>Comment By: Di-Shi Sun (di-shi)
Date: 2009-11-17 22:04

Message:
Fixed in reversion 6343.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=2899555&group_id=232389


From anca at opensips.org  Wed Nov 18 13:17:36 2009
From: anca at opensips.org (Anca Vamanu)
Date: Wed, 18 Nov 2009 12:17:36 +0000
Subject: [OpenSIPS-Devel] SF.net SVN: opensips:[6345] trunk/modules/drouting
Message-ID: <E1NAjTc-0006Ls-EQ@3kljzd1.ch3.sourceforge.com>

Revision: 6345
          http://opensips.svn.sourceforge.net/opensips/?rev=6345&view=rev
Author:   anca_vamanu
Date:     2009-11-18 12:17:36 +0000 (Wed, 18 Nov 2009)

Log Message:
-----------
- fixed small typing error in documentation

Modified Paths:
--------------
    trunk/modules/drouting/README
    trunk/modules/drouting/doc/drouting_admin.xml


This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site.


From ag at ag-projects.com  Wed Nov 18 14:05:04 2009
From: ag at ag-projects.com (Adrian Georgescu)
Date: Wed, 18 Nov 2009 14:05:04 +0100
Subject: [OpenSIPS-Devel]  Adding support for 'dialog-rules'
Message-ID: <41B2EE4A-2E25-4047-A067-E896CDAE3E2D@ag-projects.com>

 >>
I would like to know what happens if Eyebeam or
SipSimpleClient gets, via XCAP, a pres-rules document with lots of  
<rule>
sections and <many> (not just <one>) in <condition> sections. Some
<transformation> would be also cool...

Inaki,
You can make a patch to make it work and we will add it.

--
Adrian







From ibc at aliax.net  Wed Nov 18 19:24:10 2009
From: ibc at aliax.net (=?iso-8859-1?q?I=F1aki_Baz_Castillo?=)
Date: Wed, 18 Nov 2009 19:24:10 +0100
Subject: [OpenSIPS-Devel] Adding support for 'dialog-rules'
In-Reply-To: <41B2EE4A-2E25-4047-A067-E896CDAE3E2D@ag-projects.com>
References: <41B2EE4A-2E25-4047-A067-E896CDAE3E2D@ag-projects.com>
Message-ID: <200911181924.10272.ibc@aliax.net>

El Mi?rcoles, 18 de Noviembre de 2009, Adrian Georgescu escribi?:
> I would like to know what happens if Eyebeam or
> SipSimpleClient gets, via XCAP, a pres-rules document with lots of
> <rule>
> sections and <many> (not just <one>) in <condition> sections. Some
> <transformation> would be also cool...
> 
> Inaki,
> You can make a patch to make it work and we will add it.

That's the problem Adrian, it's imposible to fix it. Is not posible to know 
how a vendor X client will generate its 100% valid pres-rules documents.
This is just possible using a more strict layer on top of pres-rules format, 
as OMA has done:

The OMA pres rules document is a well and strictly documented subset of IETF 
pres-rules format, so any client could interpret a OMA pres-rules generated by 
any other OMA compliant client. This is not posible with "plain" IETF pres-
rules.

-- 
I?aki Baz Castillo <ibc at aliax.net>


From ag at ag-projects.com  Wed Nov 18 21:00:50 2009
From: ag at ag-projects.com (Adrian Georgescu)
Date: Wed, 18 Nov 2009 21:00:50 +0100
Subject: [OpenSIPS-Devel] Adding support for 'dialog-rules'
In-Reply-To: <200911181924.10272.ibc@aliax.net>
References: <41B2EE4A-2E25-4047-A067-E896CDAE3E2D@ag-projects.com>
	<200911181924.10272.ibc@aliax.net>
Message-ID: <6EBB1792-5AE0-44B5-9769-8602C2609955@ag-projects.com>

Inaki,

So what are you gonna do about it?
--
Adrian





On Nov 18, 2009, at 7:24 PM, I?aki Baz Castillo wrote:

> El Mi?rcoles, 18 de Noviembre de 2009, Adrian Georgescu escribi?:
>> I would like to know what happens if Eyebeam or
>> SipSimpleClient gets, via XCAP, a pres-rules document with lots of
>> <rule>
>> sections and <many> (not just <one>) in <condition> sections. Some
>> <transformation> would be also cool...
>>
>> Inaki,
>> You can make a patch to make it work and we will add it.
>
> That's the problem Adrian, it's imposible to fix it. Is not posible  
> to know
> how a vendor X client will generate its 100% valid pres-rules  
> documents.
> This is just possible using a more strict layer on top of pres-rules  
> format,
> as OMA has done:
>
> The OMA pres rules document is a well and strictly documented subset  
> of IETF
> pres-rules format, so any client could interpret a OMA pres-rules  
> generated by
> any other OMA compliant client. This is not posible with "plain"  
> IETF pres-
> rules.
>
> -- 
> I?aki Baz Castillo <ibc at aliax.net>
>
> _______________________________________________
> Devel mailing list
> Devel at lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/devel



From ibc at aliax.net  Wed Nov 18 22:06:36 2009
From: ibc at aliax.net (=?iso-8859-1?q?I=F1aki_Baz_Castillo?=)
Date: Wed, 18 Nov 2009 22:06:36 +0100
Subject: [OpenSIPS-Devel] Adding support for 'dialog-rules'
In-Reply-To: <6EBB1792-5AE0-44B5-9769-8602C2609955@ag-projects.com>
References: <41B2EE4A-2E25-4047-A067-E896CDAE3E2D@ag-projects.com>
	<200911181924.10272.ibc@aliax.net>
	<6EBB1792-5AE0-44B5-9769-8602C2609955@ag-projects.com>
Message-ID: <200911182206.36913.ibc@aliax.net>

El Mi?rcoles, 18 de Noviembre de 2009, Adrian Georgescu escribi?:
> Inaki,
> 
> So what are you gonna do about it?

Code :)


-- 
I?aki Baz Castillo <ibc at aliax.net>


From ag at ag-projects.com  Wed Nov 18 23:27:03 2009
From: ag at ag-projects.com (Adrian Georgescu)
Date: Wed, 18 Nov 2009 23:27:03 +0100
Subject: [OpenSIPS-Devel] Adding support for 'dialog-rules'
In-Reply-To: <200911182206.36913.ibc@aliax.net>
References: <41B2EE4A-2E25-4047-A067-E896CDAE3E2D@ag-projects.com>
	<200911181924.10272.ibc@aliax.net>
	<6EBB1792-5AE0-44B5-9769-8602C2609955@ag-projects.com>
	<200911182206.36913.ibc@aliax.net>
Message-ID: <E6C82B75-8C5D-4345-90A4-BE3A1DF84B35@ag-projects.com>

That's the spirit!

Adrian





On Nov 18, 2009, at 10:06 PM, I?aki Baz Castillo wrote:

> El Mi?rcoles, 18 de Noviembre de 2009, Adrian Georgescu escribi?:
>> Inaki,
>>
>> So what are you gonna do about it?
>
> Code :)
>
>
> -- 
> I?aki Baz Castillo <ibc at aliax.net>
>
> _______________________________________________
> Devel mailing list
> Devel at lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/devel



From ibc at aliax.net  Thu Nov 19 00:43:20 2009
From: ibc at aliax.net (=?utf-8?q?I=C3=B1aki_Baz_Castillo?=)
Date: Thu, 19 Nov 2009 00:43:20 +0100
Subject: [OpenSIPS-Devel] Add X-XCAP-Preferred-Identity header to XCAP
	clients
Message-ID: <200911190043.20371.ibc@aliax.net>

Hi, authorization in IETF's pure XCAP is not defined. This is: a XCAP request 
doesn't identify the originator but just the requested user's document.

A too much simplistic workaround is requiring authentication for all the 
requests and just allow the request if the credentials username matches the 
request XUI.

However this is not valid for some cool XCAP applications as fetching users' 
icon (alice couldn't fetch bob's icon stored in the XCAP server as alice 
cannot authenticate as bob).

As I sad above, IETF didn't manage it. Instead there are some solutions born 
in OMA, 3GPP and so...

The solution is adding an identity header in the client request identifying 
the desired identity (SIP or TEL URI), so the server would ask authentication 
based on  the identity rather than on the XUI. This would allow the server to 
authorize alice (after authentication) to access bob's icon.

This header can be:

  X-XCAP-Preferred-Identity
    and/or
  X-3GPP-Preferred-Identity

In OMA architecture, where there is an aggregation proxy in front of the XCAP 
servers, the proxy authenticates the client and asserts its identity by adding 
"X-XCAP/3GPP-Asserted-Identity" (some mechanism as in pure SIP protocol).

I've already implemented it in my Ruby XCAP client library (version 1.2):
  http://dev.sipdoc.net/projects/ruby-xcapclient/news

I suggest to include it in other XCAP clients (AG's Python xcapclient, 
sipsimpleclient, Blink...).

Regards.

 

-- 
I?aki Baz Castillo <ibc at aliax.net>


From ibc at aliax.net  Thu Nov 19 01:00:15 2009
From: ibc at aliax.net (=?utf-8?q?I=C3=B1aki_Baz_Castillo?=)
Date: Thu, 19 Nov 2009 01:00:15 +0100
Subject: [OpenSIPS-Devel] Add X-XCAP-Preferred-Identity header to XCAP
	clients
In-Reply-To: <200911190043.20371.ibc@aliax.net>
References: <200911190043.20371.ibc@aliax.net>
Message-ID: <200911190100.15503.ibc@aliax.net>

El Jueves, 19 de Noviembre de 2009, I?aki Baz Castillo escribi?:
> This header can be:
> 
>   X-XCAP-Preferred-Identity
>     and/or
>   X-3GPP-Preferred-Identity

References:
- OMA-TS-XDM_Core-V1_1-20080627-A (6.3.2 XDM Client identity assertion)
- 3GPP TS 24.109 (7.2 Authentication)


However there is other approach:

1) The client doesn't include a identity header.

2) The XCAP proxy/server requires autentication, but it *doesn't* set the 
realm based on the XUI domain. Instead it sets the realm with a constant value 
(i.e.: "provider.com") even if it's a multidomain environment.

3) The client creates the credentials and sets as username the *full* SPI URI 
("sip:alice at domain.org").

4) The servers checks the credentials and parses the credentials username so 
it already knows the identity of the client and can check authorization based 
on the identity, the xui and the requested document.


But it's important to understand that Digest credentials username should 
contain a SIP URI (or TEL URI) rather than just the SIP username or a pseudo-
uri ("alice at domain.org").

In fact, I would like that OpenSIPS itself adds a new field "ha1c" in 
subscriber table so:

  ha1  => credentials username = "alice"
  ha1b => credentials username = "alice at domain.org"
  ha1c => credentials username = "sip:alice at domain.org"


Also, OMA specs mandate it:

----------------------------------------------
OMA-TS-XDM_Core_V2

 5.1 Security Procedures
   3. The ?username? parameter SHALL have the value of the XUI (i.e. the SIP
      URI or Tel URI) identifying the user (the public user identity);
----------------------------------------------


Regards.


-- 
I?aki Baz Castillo <ibc at aliax.net>


From di-shi at transnexus.com  Thu Nov 19 10:07:40 2009
From: di-shi at transnexus.com (Di-Shi Sun)
Date: Thu, 19 Nov 2009 09:07:40 +0000
Subject: [OpenSIPS-Devel] SF.net SVN: opensips:[6346] trunk/modules/osp
Message-ID: <E1NB2zM-00081Q-Nu@dn4whf1.ch3.sourceforge.com>

Revision: 6346
          http://opensips.svn.sourceforge.net/opensips/?rev=6346&view=rev
Author:   di-shi
Date:     2009-11-19 09:07:38 +0000 (Thu, 19 Nov 2009)

Log Message:
-----------
Added IP port support for inbound/outbound IP addresses.

Modified Paths:
--------------
    trunk/modules/osp/README
    trunk/modules/osp/destination.c
    trunk/modules/osp/destination.h
    trunk/modules/osp/doc/osp_admin.xml
    trunk/modules/osp/etc/sample-osp-opensips.cfg
    trunk/modules/osp/globals.c
    trunk/modules/osp/orig_transaction.c
    trunk/modules/osp/osp_mod.c
    trunk/modules/osp/osptoolkit.c
    trunk/modules/osp/sipheader.c
    trunk/modules/osp/sipheader.h
    trunk/modules/osp/term_transaction.c
    trunk/modules/osp/usage.c
    trunk/modules/osp/usage.h


This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site.


From anca at opensips.org  Thu Nov 19 10:21:11 2009
From: anca at opensips.org (Anca Vamanu)
Date: Thu, 19 Nov 2009 09:21:11 +0000
Subject: [OpenSIPS-Devel] SF.net SVN: opensips:[6347]
 branches/1.6/modules/pua_dialoginfo/ pua_dialoginfo.c
Message-ID: <E1NB3CR-0004V1-Hg@d5vjzd1.ch3.sourceforge.com>

Revision: 6347
          http://opensips.svn.sourceforge.net/opensips/?rev=6347&view=rev
Author:   anca_vamanu
Date:     2009-11-19 09:21:11 +0000 (Thu, 19 Nov 2009)

Log Message:
-----------
- fixed bug when a FAKED_REPLY was received ( reported by elm0 at #opensips)

Modified Paths:
--------------
    branches/1.6/modules/pua_dialoginfo/pua_dialoginfo.c


This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site.


From anca at opensips.org  Thu Nov 19 10:21:51 2009
From: anca at opensips.org (Anca Vamanu)
Date: Thu, 19 Nov 2009 09:21:51 +0000
Subject: [OpenSIPS-Devel] SF.net SVN: opensips:[6348]
	trunk/modules/pua_dialoginfo/pua_dialoginfo.c
Message-ID: <E1NB3D5-0004WI-2q@d5vjzd1.ch3.sourceforge.com>

Revision: 6348
          http://opensips.svn.sourceforge.net/opensips/?rev=6348&view=rev
Author:   anca_vamanu
Date:     2009-11-19 09:21:50 +0000 (Thu, 19 Nov 2009)

Log Message:
-----------
- fixed bug when a FAKED_REPLY is received (reported by elmo at #opensips)

Modified Paths:
--------------
    trunk/modules/pua_dialoginfo/pua_dialoginfo.c


This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site.


From thiago at aware.com.br  Thu Nov 19 12:45:55 2009
From: thiago at aware.com.br (Thiago Rondon)
Date: Thu, 19 Nov 2009 09:45:55 -0200
Subject: [OpenSIPS-Devel] Add X-XCAP-Preferred-Identity header to XCAP
 clients
In-Reply-To: <200911190043.20371.ibc@aliax.net>
References: <200911190043.20371.ibc@aliax.net>
Message-ID: <4B052FF3.7080509@aware.com.br>


I?aki,

In this scenario that you said, alice could fetch bob's icon store in 
the XCAP server by authentication as alice, how the security roles works?

For example, if you can just give access to alice to see bob's icon if 
alice in the 'whitelist' of presence-rules.xml ?

Thanks!
-Thiago Rondon

I?aki Baz Castillo escreveu:
> Hi, authorization in IETF's pure XCAP is not defined. This is: a XCAP request 
> doesn't identify the originator but just the requested user's document.
>
> A too much simplistic workaround is requiring authentication for all the 
> requests and just allow the request if the credentials username matches the 
> request XUI.
>
> However this is not valid for some cool XCAP applications as fetching users' 
> icon (alice couldn't fetch bob's icon stored in the XCAP server as alice 
> cannot authenticate as bob).
>
> As I sad above, IETF didn't manage it. Instead there are some solutions born 
> in OMA, 3GPP and so...
>
> The solution is adding an identity header in the client request identifying 
> the desired identity (SIP or TEL URI), so the server would ask authentication 
> based on  the identity rather than on the XUI. This would allow the server to 
> authorize alice (after authentication) to access bob's icon.
>
> This header can be:
>
>   X-XCAP-Preferred-Identity
>     and/or
>   X-3GPP-Preferred-Identity
>
> In OMA architecture, where there is an aggregation proxy in front of the XCAP 
> servers, the proxy authenticates the client and asserts its identity by adding 
> "X-XCAP/3GPP-Asserted-Identity" (some mechanism as in pure SIP protocol).
>
> I've already implemented it in my Ruby XCAP client library (version 1.2):
>   http://dev.sipdoc.net/projects/ruby-xcapclient/news
>
> I suggest to include it in other XCAP clients (AG's Python xcapclient, 
> sipsimpleclient, Blink...).
>
> Regards.
>
>  
>
>   



From ibc at aliax.net  Thu Nov 19 12:58:20 2009
From: ibc at aliax.net (=?utf-8?q?I=C3=B1aki_Baz_Castillo?=)
Date: Thu, 19 Nov 2009 12:58:20 +0100
Subject: [OpenSIPS-Devel] Add X-XCAP-Preferred-Identity header to XCAP
	clients
In-Reply-To: <4B052FF3.7080509@aware.com.br>
References: <200911190043.20371.ibc@aliax.net> <4B052FF3.7080509@aware.com.br>
Message-ID: <200911191258.20563.ibc@aliax.net>

El Jueves, 19 de Noviembre de 2009, Thiago Rondon escribi?:
> I?aki,
> 
> In this scenario that you said, alice could fetch bob's icon store in
> the XCAP server by authentication as alice, how the security roles works?
> 
> For example, if you can just give access to alice to see bob's icon if
> alice in the 'whitelist' of presence-rules.xml ?

That's a very good question for which there is no specifications (AFAIK).
However the server could have local policies (i.e: alice can get bob's icon, 
after authentication, since alice's domain matches bob's domain).

Inspecting the pres-rules of bob would be the more ellegant solution: if bob 
allows alice to see his status, then it makes sense that alice could fetch 
bob's icon (same as in XMPP, MSN networks).

However it requires that the XCAP server inspect bob's pres-rules, but it 
could be feasible.



> 
> Thanks!
> -Thiago Rondon
> 
> I?aki Baz Castillo escreveu:
> > Hi, authorization in IETF's pure XCAP is not defined. This is: a XCAP
> > request doesn't identify the originator but just the requested user's
> > document.
> >
> > A too much simplistic workaround is requiring authentication for all the
> > requests and just allow the request if the credentials username matches
> > the request XUI.
> >
> > However this is not valid for some cool XCAP applications as fetching
> > users' icon (alice couldn't fetch bob's icon stored in the XCAP server as
> > alice cannot authenticate as bob).
> >
> > As I sad above, IETF didn't manage it. Instead there are some solutions
> > born in OMA, 3GPP and so...
> >
> > The solution is adding an identity header in the client request
> > identifying the desired identity (SIP or TEL URI), so the server would
> > ask authentication based on  the identity rather than on the XUI. This
> > would allow the server to authorize alice (after authentication) to
> > access bob's icon.
> >
> > This header can be:
> >
> >   X-XCAP-Preferred-Identity
> >     and/or
> >   X-3GPP-Preferred-Identity
> >
> > In OMA architecture, where there is an aggregation proxy in front of the
> > XCAP servers, the proxy authenticates the client and asserts its identity
> > by adding "X-XCAP/3GPP-Asserted-Identity" (some mechanism as in pure SIP
> > protocol).
> >
> > I've already implemented it in my Ruby XCAP client library (version 1.2):
> >   http://dev.sipdoc.net/projects/ruby-xcapclient/news
> >
> > I suggest to include it in other XCAP clients (AG's Python xcapclient,
> > sipsimpleclient, Blink...).
> >
> > Regards.
> 
> _______________________________________________
> Devel mailing list
> Devel at lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
> 


-- 
I?aki Baz Castillo <ibc at aliax.net>


From andreidragus at yahoo.com  Wed Nov 18 11:47:35 2009
From: andreidragus at yahoo.com (Andrei Dragus)
Date: Wed, 18 Nov 2009 10:47:35 +0000
Subject: [OpenSIPS-Devel] SF.net SVN: opensips:[6344] trunk
Message-ID: <E1NAi4V-0002l7-Bk@bj8yhf1.ch3.sourceforge.com>

Revision: 6344
          http://opensips.svn.sourceforge.net/opensips/?rev=6344&view=rev
Author:   andreidragus
Date:     2009-11-18 10:47:35 +0000 (Wed, 18 Nov 2009)

Log Message:
-----------
Added method to parse multipart bodies.

Modified Paths:
--------------
    trunk/modules/textops/textops.c
    trunk/modules/tm/sip_msg.c
    trunk/parser/hf.c
    trunk/parser/hf.h
    trunk/parser/msg_parser.c
    trunk/parser/msg_parser.h
    trunk/parser/parse_content.c
    trunk/parser/parse_content.h
    trunk/parser/parse_param.c
    trunk/parser/sdp/sdp.c

Added Paths:
-----------
    trunk/parser/parse_multipart.c
    trunk/parser/parse_multipart.h


This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site.


From andreidragus at yahoo.com  Thu Nov 19 15:53:38 2009
From: andreidragus at yahoo.com (Andrei Dragus)
Date: Thu, 19 Nov 2009 14:53:38 +0000
Subject: [OpenSIPS-Devel] SF.net SVN: opensips:[6349] trunk/modules/textops
Message-ID: <E1NB8OA-0004sK-Kg@bj8yhf1.ch3.sourceforge.com>

Revision: 6349
          http://opensips.svn.sourceforge.net/opensips/?rev=6349&view=rev
Author:   andreidragus
Date:     2009-11-19 14:53:38 +0000 (Thu, 19 Nov 2009)

Log Message:
-----------
Made has_body check into multipart bodies.
Added strip_body(mime), which looks into multipart.

Modified Paths:
--------------
    trunk/modules/textops/README
    trunk/modules/textops/doc/textops_admin.xml
    trunk/modules/textops/textops.c


This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site.


From andreidragus at yahoo.com  Thu Nov 19 17:54:08 2009
From: andreidragus at yahoo.com (Andrei Dragus)
Date: Thu, 19 Nov 2009 16:54:08 +0000
Subject: [OpenSIPS-Devel] SF.net SVN: opensips:[6350] trunk/modules/nathelper
Message-ID: <E1NBAGm-0000HT-8a@c3vjzd1.ch3.sourceforge.com>

Revision: 6350
          http://opensips.svn.sourceforge.net/opensips/?rev=6350&view=rev
Author:   andreidragus
Date:     2009-11-19 16:54:07 +0000 (Thu, 19 Nov 2009)

Log Message:
-----------
Modified nathelper so now it works wih multipart messages.

Modified Paths:
--------------
    trunk/modules/nathelper/README
    trunk/modules/nathelper/doc/nathelper_admin.xml
    trunk/modules/nathelper/nathelper.c


This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site.


From ag at ag-projects.com  Thu Nov 19 21:02:42 2009
From: ag at ag-projects.com (Adrian Georgescu)
Date: Thu, 19 Nov 2009 21:02:42 +0100
Subject: [OpenSIPS-Devel] Add X-XCAP-Preferred-Identity header to XCAP
	clients
In-Reply-To: <200911191258.20563.ibc@aliax.net>
References: <200911190043.20371.ibc@aliax.net> <4B052FF3.7080509@aware.com.br>
	<200911191258.20563.ibc@aliax.net>
Message-ID: <09498336-7DAC-4F02-8F88-DC9D9ADCFA25@ag-projects.com>

First of all, there is no correlation on protocols level between the  
SIP Subscribe from a foreign domain and the HTTP GET requests the  
watcher performs for fetching an icon stored in an XCAP server in a  
foreign domain. So technically you cannot enforce  a policy about who  
is allowed to HTTP GET your icon.

According to OMA everything is pipe between operators that have  
agreements between them. So by proxying all HTTP requests to an  
outbound proxy of operator A the HTTP request will arrive with some  
extra asserted headers to operator B who will then trust them and  
honor the HTTP request based on them. This is non-sense on the Internet.

Protecting an icon is also complete non-sense as once somebody fetched  
it no matter by what means or credentials it can post it on Facebook  
and the rest of the universe got it. Is a picture in the end,  
something you display in a small area of a remote device, something  
you published in the first place to be reachable and not some credit  
card secret details. If you think you need high security for an icon  
do not publish it in the first place.

The only reasonable thing you can do with the icon is to anonymize the  
URL so that people cannot simply guess it. The ones who obtain the URL  
from the Notify with presence Event can fetch it because they know  
where it is. This is what we are now building in OpenXCAP.

--
Adrian





On Nov 19, 2009, at 12:58 PM, I?aki Baz Castillo wrote:

> El Jueves, 19 de Noviembre de 2009, Thiago Rondon escribi?:
>> I?aki,
>>
>> In this scenario that you said, alice could fetch bob's icon store in
>> the XCAP server by authentication as alice, how the security roles  
>> works?
>>
>> For example, if you can just give access to alice to see bob's icon  
>> if
>> alice in the 'whitelist' of presence-rules.xml ?
>
> That's a very good question for which there is no specifications  
> (AFAIK).
> However the server could have local policies (i.e: alice can get  
> bob's icon,
> after authentication, since alice's domain matches bob's domain).
>
> Inspecting the pres-rules of bob would be the more ellegant  
> solution: if bob
> allows alice to see his status, then it makes sense that alice could  
> fetch
> bob's icon (same as in XMPP, MSN networks).
>
> However it requires that the XCAP server inspect bob's pres-rules,  
> but it
> could be feasible.
>
>
>
>>
>> Thanks!
>> -Thiago Rondon
>>
>> I?aki Baz Castillo escreveu:
>>> Hi, authorization in IETF's pure XCAP is not defined. This is: a  
>>> XCAP
>>> request doesn't identify the originator but just the requested  
>>> user's
>>> document.
>>>
>>> A too much simplistic workaround is requiring authentication for  
>>> all the
>>> requests and just allow the request if the credentials username  
>>> matches
>>> the request XUI.
>>>
>>> However this is not valid for some cool XCAP applications as  
>>> fetching
>>> users' icon (alice couldn't fetch bob's icon stored in the XCAP  
>>> server as
>>> alice cannot authenticate as bob).
>>>
>>> As I sad above, IETF didn't manage it. Instead there are some  
>>> solutions
>>> born in OMA, 3GPP and so...
>>>
>>> The solution is adding an identity header in the client request
>>> identifying the desired identity (SIP or TEL URI), so the server  
>>> would
>>> ask authentication based on  the identity rather than on the XUI.  
>>> This
>>> would allow the server to authorize alice (after authentication) to
>>> access bob's icon.
>>>
>>> This header can be:
>>>
>>>  X-XCAP-Preferred-Identity
>>>    and/or
>>>  X-3GPP-Preferred-Identity
>>>
>>> In OMA architecture, where there is an aggregation proxy in front  
>>> of the
>>> XCAP servers, the proxy authenticates the client and asserts its  
>>> identity
>>> by adding "X-XCAP/3GPP-Asserted-Identity" (some mechanism as in  
>>> pure SIP
>>> protocol).
>>>
>>> I've already implemented it in my Ruby XCAP client library  
>>> (version 1.2):
>>>  http://dev.sipdoc.net/projects/ruby-xcapclient/news
>>>
>>> I suggest to include it in other XCAP clients (AG's Python  
>>> xcapclient,
>>> sipsimpleclient, Blink...).
>>>
>>> Regards.
>>
>> _______________________________________________
>> Devel mailing list
>> Devel at lists.opensips.org
>> http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
>>
>
>
> -- 
> I?aki Baz Castillo <ibc at aliax.net>
>
> _______________________________________________
> Devel mailing list
> Devel at lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/devel



From ibc at aliax.net  Thu Nov 19 21:43:49 2009
From: ibc at aliax.net (=?iso-8859-1?q?I=F1aki_Baz_Castillo?=)
Date: Thu, 19 Nov 2009 21:43:49 +0100
Subject: [OpenSIPS-Devel] Add X-XCAP-Preferred-Identity header to XCAP
	clients
In-Reply-To: <09498336-7DAC-4F02-8F88-DC9D9ADCFA25@ag-projects.com>
References: <200911190043.20371.ibc@aliax.net>
	<200911191258.20563.ibc@aliax.net>
	<09498336-7DAC-4F02-8F88-DC9D9ADCFA25@ag-projects.com>
Message-ID: <200911192143.49615.ibc@aliax.net>

El Jueves, 19 de Noviembre de 2009, Adrian Georgescu escribi?:
> First of all, there is no correlation on protocols level between the
> SIP Subscribe from a foreign domain and the HTTP GET requests the
> watcher performs for fetching an icon stored in an XCAP server in a
> foreign domain. So technically you cannot enforce  a policy about who
> is allowed to HTTP GET your icon.

At least you can implement a local policy. The SIP proxy and the HTTP 
proxy/server can ask for authentication just in case the "From" domain and the 
"X-XCAP-Preferred-Identity" domain is a provider local domain.
Other domains (untrusted) can be considered as "others" and the local policy 
could be different for trusted and untrusted domains.


> According to OMA everything is pipe between operators that have
> agreements between them. So by proxying all HTTP requests to an
> outbound proxy of operator A the HTTP request will arrive with some
> extra asserted headers to operator B who will then trust them and
> honor the HTTP request based on them. This is non-sense on the Internet.

Sure.

 
> Protecting an icon is also complete non-sense as once somebody fetched
> it no matter by what means or credentials it can post it on Facebook
> and the rest of the universe got it. Is a picture in the end,
> something you display in a small area of a remote device, something
> you published in the first place to be reachable and not some credit
> card secret details. If you think you need high security for an icon
> do not publish it in the first place.

The icon is just an example. I expect there could be other kind of documents a 
user desires to share just to others.

 

> The only reasonable thing you can do with the icon is to anonymize the
> URL so that people cannot simply guess it. The ones who obtain the URL
> from the Notify with presence Event can fetch it because they know
> where it is.

And he can also upload it to Facebook again.


> This is what we are now building in OpenXCAP.

Another propietary (even if it's open source) XCAP application? good, and 
which client will implement it (uploading an naming an icon in a propietary 
way)? Let me guess... Blink?

I could agree with these kind of new features if they would be, at least, 
documented as proposed drafts.

This is, now pres-dialog-rules has been released and supported by OpenSIPS, 
OpenXCAP and Blink. Will be a concise documentation of this custom format? or 
should I inspect the requests Blink generates to "imitate" them?
The same for this new "XCAP icon storage application": which mime-type will be 
used? which format and size is allowed? which kind od transfer type? or should 
I do a ngrep?

Please don't take wrong Adrian, I want to be constructive.

Regards.


-- 
I?aki Baz Castillo <ibc at aliax.net>


From ag at ag-projects.com  Fri Nov 20 10:44:49 2009
From: ag at ag-projects.com (Adrian Georgescu)
Date: Fri, 20 Nov 2009 10:44:49 +0100
Subject: [OpenSIPS-Devel] Add X-XCAP-Preferred-Identity header to XCAP
	clients
In-Reply-To: <200911192143.49615.ibc@aliax.net>
References: <200911190043.20371.ibc@aliax.net>
	<200911191258.20563.ibc@aliax.net>
	<09498336-7DAC-4F02-8F88-DC9D9ADCFA25@ag-projects.com>
	<200911192143.49615.ibc@aliax.net>
Message-ID: <B1EE5368-E195-4BCE-BA2E-AC320727E0AD@ag-projects.com>

>
> Another propietary (even if it's open source) XCAP application?  
> good, and
> which client will implement it (uploading an naming an icon in a  
> propietary
> way)? Let me guess... Blink?
>

Inaki,

Can you explain what is proprietary about using a random file name for  
the icon auid?


Adrian




-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.opensips.org/pipermail/devel/attachments/20091120/f5b76d04/attachment-0001.htm 

From ibc at aliax.net  Fri Nov 20 10:54:31 2009
From: ibc at aliax.net (=?utf-8?q?I=C3=B1aki_Baz_Castillo?=)
Date: Fri, 20 Nov 2009 10:54:31 +0100
Subject: [OpenSIPS-Devel] Add X-XCAP-Preferred-Identity header to XCAP
	clients
In-Reply-To: <B1EE5368-E195-4BCE-BA2E-AC320727E0AD@ag-projects.com>
References: <200911190043.20371.ibc@aliax.net>
	<200911192143.49615.ibc@aliax.net>
	<B1EE5368-E195-4BCE-BA2E-AC320727E0AD@ag-projects.com>
Message-ID: <200911201054.31859.ibc@aliax.net>

El Viernes, 20 de Noviembre de 2009, Adrian Georgescu escribi?:
> > Another propietary (even if it's open source) XCAP application?
> > good, and
> > which client will implement it (uploading an naming an icon in a
> > propietary
> > way)? Let me guess... Blink?
> 
> Inaki,
> 
> Can you explain what is proprietary about using a random file name for
> the icon auid?

The mechanism is propietary as storing a non XML document in a XCAP server is 
not a IETF/XCAP standard, the naming convention, the transfer mode, the icon 
image requeriments (size, formats)... all is propietary.

Replace "propietary" with "non standard" if you prefer, but the concept is the 
same: non standard features/specs on top of real standars (SIP and XCAP), so 
just the clients and servers managed by same vendor (AG) will implement them.

But as I already said, the main problem here are the IETF's XCAP specs as they 
are incomplete and don't provide needed features (as icon storage). But I 
don't agree if the proposed solution is adding these features using vendor 
propietary specs. If at least they were really well documented...

Regards.

-- 
I?aki Baz Castillo <ibc at aliax.net>


From ag at ag-projects.com  Fri Nov 20 15:02:25 2009
From: ag at ag-projects.com (Adrian Georgescu)
Date: Fri, 20 Nov 2009 15:02:25 +0100
Subject: [OpenSIPS-Devel] Add X-XCAP-Preferred-Identity header to XCAP
	clients
Message-ID: <1E874228-6017-4BA9-90B3-0C0606DD5D91@ag-projects.com>



El Viernes, 20 de Noviembre de 2009, Adrian Georgescu escribi?:
 > > Another propietary (even if it's open source) XCAP application?
 > > good, and
 > > which client will implement it (uploading an naming an icon in a
 > > propietary
 > > way)? Let me guess... Blink?
 >
 > Inaki,
 >
 > Can you explain what is proprietary about using a random file name  
for
 > the icon auid?

The mechanism is propietary as storing a non XML document in a XCAP  
server is
not a IETF/XCAP standard, the naming convention, the transfer mode,  
the icon
image requeriments (size, formats)... all is propietary.

See OMA *icon auid.
It is well documented and it makes sense except for those X- headers  
that are completely useless on the public Internet.
--
Adrian





-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.opensips.org/pipermail/devel/attachments/20091120/dc2985a6/attachment.htm 

From ibc at aliax.net  Fri Nov 20 15:12:18 2009
From: ibc at aliax.net (=?utf-8?q?I=C3=B1aki_Baz_Castillo?=)
Date: Fri, 20 Nov 2009 15:12:18 +0100
Subject: [OpenSIPS-Devel] Add X-XCAP-Preferred-Identity header to XCAP
	clients
In-Reply-To: <1E874228-6017-4BA9-90B3-0C0606DD5D91@ag-projects.com>
References: <1E874228-6017-4BA9-90B3-0C0606DD5D91@ag-projects.com>
Message-ID: <200911201512.18272.ibc@aliax.net>

El Viernes, 20 de Noviembre de 2009, Adrian Georgescu escribi?:
> See OMA *icon auid.
> It is well documented and it makes sense except for those X- headers
> that are completely useless on the public Internet.

But will you implement OMA icon auid?


-- 
I?aki Baz Castillo <ibc at aliax.net>


From adragus at opensips.org  Fri Nov 20 16:07:47 2009
From: adragus at opensips.org (Andrei Dragus)
Date: Fri, 20 Nov 2009 15:07:47 +0000
Subject: [OpenSIPS-Devel] SF.net SVN: opensips:[6351] trunk/mem
Message-ID: <E1NBV5P-0003LR-Ck@74yxhf1.ch3.sourceforge.com>

Revision: 6351
          http://opensips.svn.sourceforge.net/opensips/?rev=6351&view=rev
Author:   andreidragus
Date:     2009-11-20 15:07:47 +0000 (Fri, 20 Nov 2009)

Log Message:
-----------
Fixed warning in nat_traversal

Modified Paths:
--------------
    trunk/mem/f_malloc.c
    trunk/mem/f_malloc.h


This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site.


From noreply at sourceforge.net  Fri Nov 20 16:33:36 2009
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 20 Nov 2009 15:33:36 +0000
Subject: [OpenSIPS-Devel] [ opensips-Feature Requests-2901204 ] Allow
	specification of the database port
Message-ID: <E1NBVUO-0005QG-4L@cdv4jf1.ch3.sourceforge.com>

Feature Requests item #2901204, was opened at 2009-11-20 15:33
Message generated for change (Tracker Item Submitted) made by nobody
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086413&aid=2901204&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: None
Status: Open
Priority: 5
Private: No
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: Allow specification of the database port

Initial Comment:
I'm trying to connect opensips to a postgresql database through pgpool, which defaults to port 9999.  It would be really helpful if I could set the port number in the config file.

Thanks!

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086413&aid=2901204&group_id=232389


From anca at opensips.org  Fri Nov 20 17:06:10 2009
From: anca at opensips.org (Anca Vamanu)
Date: Fri, 20 Nov 2009 16:06:10 +0000
Subject: [OpenSIPS-Devel] SF.net SVN: opensips:[6352]
	trunk/modules/b2b_entities
Message-ID: <E1NBVzu-0003su-N3@3kljzd1.ch3.sourceforge.com>

Revision: 6352
          http://opensips.svn.sourceforge.net/opensips/?rev=6352&view=rev
Author:   anca_vamanu
Date:     2009-11-20 16:06:10 +0000 (Fri, 20 Nov 2009)

Log Message:
-----------
- fixed bug of resending 200OK reply (reported by Jeff Kronlage )

Modified Paths:
--------------
    trunk/modules/b2b_entities/b2b_entities.c
    trunk/modules/b2b_entities/dlg.c
    trunk/modules/b2b_entities/server.c


This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site.


From anca at opensips.org  Fri Nov 20 17:17:14 2009
From: anca at opensips.org (Anca Vamanu)
Date: Fri, 20 Nov 2009 16:17:14 +0000
Subject: [OpenSIPS-Devel] SF.net SVN: opensips:[6353]
	branches/1.6/modules/b2b_entities
Message-ID: <E1NBWAc-00044t-0U@3kljzd1.ch3.sourceforge.com>

Revision: 6353
          http://opensips.svn.sourceforge.net/opensips/?rev=6353&view=rev
Author:   anca_vamanu
Date:     2009-11-20 16:17:13 +0000 (Fri, 20 Nov 2009)

Log Message:
-----------
- fixed bug of resending 200OK reply (reported by Jeff Kronlage )

Modified Paths:
--------------
    branches/1.6/modules/b2b_entities/b2b_entities.c
    branches/1.6/modules/b2b_entities/dlg.c
    branches/1.6/modules/b2b_entities/server.c


This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site.


From anca at opensips.org  Fri Nov 20 17:23:26 2009
From: anca at opensips.org (Anca Vamanu)
Date: Fri, 20 Nov 2009 16:23:26 +0000
Subject: [OpenSIPS-Devel] SF.net SVN: opensips:[6354]
	trunk/modules/b2b_logic/records.c
Message-ID: <E1NBWGc-0004Ai-M5@3kljzd1.ch3.sourceforge.com>

Revision: 6354
          http://opensips.svn.sourceforge.net/opensips/?rev=6354&view=rev
Author:   anca_vamanu
Date:     2009-11-20 16:23:26 +0000 (Fri, 20 Nov 2009)

Log Message:
-----------
- fixed not checking if variable is null on destroy

Modified Paths:
--------------
    trunk/modules/b2b_logic/records.c


This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site.


From anca at opensips.org  Fri Nov 20 17:37:08 2009
From: anca at opensips.org (Anca Vamanu)
Date: Fri, 20 Nov 2009 16:37:08 +0000
Subject: [OpenSIPS-Devel] SF.net SVN: opensips:[6355]
	branches/1.6/modules/b2b_logic/records.c
Message-ID: <E1NBWTs-000181-Ka@d5vjzd1.ch3.sourceforge.com>

Revision: 6355
          http://opensips.svn.sourceforge.net/opensips/?rev=6355&view=rev
Author:   anca_vamanu
Date:     2009-11-20 16:37:08 +0000 (Fri, 20 Nov 2009)

Log Message:
-----------
- fixed not checking if variable is null on destroy

Modified Paths:
--------------
    branches/1.6/modules/b2b_logic/records.c


This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site.


From ag at ag-projects.com  Fri Nov 20 19:33:04 2009
From: ag at ag-projects.com (Adrian Georgescu)
Date: Fri, 20 Nov 2009 19:33:04 +0100
Subject: [OpenSIPS-Devel] Add X-XCAP-Preferred-Identity header to XCAP
	clients
In-Reply-To: <200911201512.18272.ibc@aliax.net>
References: <1E874228-6017-4BA9-90B3-0C0606DD5D91@ag-projects.com>
	<200911201512.18272.ibc@aliax.net>
Message-ID: <DB75508F-17B0-46B2-AFB5-0080C6C7A9B8@ag-projects.com>

Yes

Except those useless headers.

--
Adrian





On Nov 20, 2009, at 3:12 PM, I?aki Baz Castillo wrote:

> El Viernes, 20 de Noviembre de 2009, Adrian Georgescu escribi?:
>> See OMA *icon auid.
>> It is well documented and it makes sense except for those X- headers
>> that are completely useless on the public Internet.
>
> But will you implement OMA icon auid?
>
>
> -- 
> I?aki Baz Castillo <ibc at aliax.net>
>
> _______________________________________________
> Devel mailing list
> Devel at lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/devel



From noreply at sourceforge.net  Sat Nov 21 15:08:10 2009
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat, 21 Nov 2009 14:08:10 +0000
Subject: [OpenSIPS-Devel] [ opensips-Bugs-2901758 ] b2bua doesn't pass SIP
	INFO messages.
Message-ID: <E1NBqdG-0002Zg-SU@cdv4jf1.ch3.sourceforge.com>

Bugs item #2901758, was opened at 2009-11-21 09:08
Message generated for change (Tracker Item Submitted) made by sokhapkin
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=2901758&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: Sergey Okhapkin (sokhapkin)
Assigned to: Nobody/Anonymous (nobody)
Summary: b2bua doesn't pass SIP INFO messages.

Initial Comment:
SIP INFO message received yelds to log ERROR:b2b_logic:b2b_logic_notify: Method not supported.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=2901758&group_id=232389


From noreply at sourceforge.net  Sun Nov 22 21:43:34 2009
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun, 22 Nov 2009 20:43:34 +0000
Subject: [OpenSIPS-Devel] [ opensips-Patches-2902164 ] Man page for
	osipsconsole
Message-ID: <E1NCJHS-0001Bh-BY@565xhf1.ch3.sourceforge.com>

Patches item #2902164, was opened at 2009-11-22 15:43
Message generated for change (Tracker Item Submitted) made by alerios
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086412&aid=2902164&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: docs
Group: 1.6.x
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Alejandro Rios (alerios)
Assigned to: Nobody/Anonymous (nobody)
Summary: Man page for osipsconsole

Initial Comment:
Hello.

'osipsconsole' doesn't have a man page. I did a simple one for the debian package and I'm putting it here for your reference.

Note tah man page for 'bdb_recover' is also missing.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086412&aid=2902164&group_id=232389


From adragus at opensips.org  Mon Nov 23 12:18:16 2009
From: adragus at opensips.org (Andrei Dragus)
Date: Mon, 23 Nov 2009 11:18:16 +0000
Subject: [OpenSIPS-Devel] SF.net SVN: opensips:[6356] trunk/modules/textops
Message-ID: <E1NCWvw-00058W-7D@d5vjzd1.ch3.sourceforge.com>

Revision: 6356
          http://opensips.svn.sourceforge.net/opensips/?rev=6356&view=rev
Author:   andreidragus
Date:     2009-11-23 11:18:15 +0000 (Mon, 23 Nov 2009)

Log Message:
-----------
Added codec_delete_except_re(),
	  feature request  2893576

Modified Paths:
--------------
    trunk/modules/textops/README
    trunk/modules/textops/codecs.c
    trunk/modules/textops/codecs.h
    trunk/modules/textops/doc/textops_admin.xml
    trunk/modules/textops/textops.c


This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site.


From noreply at sourceforge.net  Mon Nov 23 12:21:56 2009
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 23 Nov 2009 11:21:56 +0000
Subject: [OpenSIPS-Devel] [ opensips-Feature Requests-2893576 ] Inverse
	Codec Match
Message-ID: <E1NCWzU-0002WI-Bz@d55xhf1.ch3.sourceforge.com>

Feature Requests item #2893576, was opened at 2009-11-06 23:44
Message generated for change (Comment added) made by andreidragus
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086413&aid=2893576&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
Priority: 5
Private: No
Submitted By: Ryan Bullock (rrb3942)
Assigned to: Andrei Dragus (andreidragus)
Summary: Inverse Codec Match

Initial Comment:
The new codec functions in textops are awesome. However there is one feature I would like to see.

Currently there is codec_delete_re() and codec_exists_re that lets you delete and check for any codecs that match a regular expression.

If would be nice if there was the ability to also delete codecs that do NOT match an expression, perhaps through a option. This would allow you to enforce a list of supported codecs only. Right now to remove all other codecs would need an exhaustive list of what to remove (or some really awful inverse regex that would be confusing to write/read, if it is even possible to write)

For example, if you only want to permit G711 and G729 you could do something like the following to remove any other codecs:

codec_delete_re("[gG]711|[gG]729", v) 

And the only codecs left would be G711 and G729 in the message. Or if it had only g711 and say speex, you would be left with only g711.

One would of course have to be careful to not remove telephony-events as well, but that should be up to the script writer.

I think this would be useful only for the codec_exists_re and codec_delete_re, so you could check for, and remove any foreign codecs.

codec_move_up_re and codec_move_down_re are already their inverses (for the most part).

Also a case insensitive option for the regex might be nice. But that would just be more icing on the cake.

----------------------------------------------------------------------

>Comment By: Andrei Dragus (andreidragus)
Date: 2009-11-23 13:21

Message:
Added "codec_delete_except_re( regexp ) " in r 6356.
This function  deletes all codecs except those matching the regular
expression.

As for the case insensitive option I don't think it will  be implemented,
I will leave it open for now and we will see.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086413&aid=2893576&group_id=232389


From saguti at gmail.com  Mon Nov 23 17:44:49 2009
From: saguti at gmail.com (Sergio Gutierrez)
Date: Mon, 23 Nov 2009 11:44:49 -0500
Subject: [OpenSIPS-Devel] Capacity of dialplan module
Message-ID: <8a4af3e20911230844ld9ae5beqf680aa14459a80dd@mail.gmail.com>

Hello to all members on list.

Is there any restriction regarding how many dialplan entries can be loaded?
I mean, a restriction imposed on the module.

Thanks and regards.

-- 
Sergio Guti?rrez
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.opensips.org/pipermail/devel/attachments/20091123/7d15712e/attachment.htm 

From bogdan at voice-system.ro  Mon Nov 23 22:18:35 2009
From: bogdan at voice-system.ro (Bogdan-Andrei Iancu)
Date: Mon, 23 Nov 2009 23:18:35 +0200
Subject: [OpenSIPS-Devel] Capacity of dialplan module
In-Reply-To: <8a4af3e20911230844ld9ae5beqf680aa14459a80dd@mail.gmail.com>
References: <8a4af3e20911230844ld9ae5beqf680aa14459a80dd@mail.gmail.com>
Message-ID: <4B0AFC2B.8030803@voice-system.ro>

Hi Sergio,

There is no limitation at all - only the available memory :)

Regards,
Bogdan

Sergio Gutierrez wrote:
> Hello to all members on list.
>
> Is there any restriction regarding how many dialplan entries can be 
> loaded? I mean, a restriction imposed on the module.
>
> Thanks and regards.
>
> -- 
> Sergio Guti?rrez
> ------------------------------------------------------------------------
>
> _______________________________________________
> Devel mailing list
> Devel at lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
>   


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



From di-shi at transnexus.com  Tue Nov 24 04:31:08 2009
From: di-shi at transnexus.com (Di-Shi Sun)
Date: Tue, 24 Nov 2009 03:31:08 +0000
Subject: [OpenSIPS-Devel] SF.net SVN: opensips:[6357]
	trunk/modules/osp/orig_transaction.c
Message-ID: <E1NCm7Q-0004mz-Mz@74yxhf1.ch3.sourceforge.com>

Revision: 6357
          http://opensips.svn.sourceforge.net/opensips/?rev=6357&view=rev
Author:   di-shi
Date:     2009-11-24 03:31:08 +0000 (Tue, 24 Nov 2009)

Log Message:
-----------
Removed an unused variable.

Modified Paths:
--------------
    trunk/modules/osp/orig_transaction.c


This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site.


From di-shi at transnexus.com  Tue Nov 24 09:46:27 2009
From: di-shi at transnexus.com (Di-Shi Sun)
Date: Tue, 24 Nov 2009 08:46:27 +0000
Subject: [OpenSIPS-Devel] SF.net SVN: opensips:[6358]
	branches/1.6/modules/osp
Message-ID: <E1NCr2Z-0005Uv-27@3kljzd1.ch3.sourceforge.com>

Revision: 6358
          http://opensips.svn.sourceforge.net/opensips/?rev=6358&view=rev
Author:   di-shi
Date:     2009-11-24 08:46:26 +0000 (Tue, 24 Nov 2009)

Log Message:
-----------
Fixed the bug of generating wrong new ruri.

Modified Paths:
--------------
    branches/1.6/modules/osp/destination.c
    branches/1.6/modules/osp/destination.h
    branches/1.6/modules/osp/sipheader.c


This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site.


From noreply at sourceforge.net  Tue Nov 24 18:27:53 2009
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue, 24 Nov 2009 17:27:53 +0000
Subject: [OpenSIPS-Devel] [ opensips-Bugs-2903244 ] Segfault when using
	pua_dialoginfo
Message-ID: <E1NCzBB-0007pm-Pc@h45xhf1.ch3.sourceforge.com>

Bugs item #2903244, was opened at 2009-11-25 02:27
Message generated for change (Tracker Item Submitted) made by mayamatakeshi
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=2903244&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.6.x
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: takeshi (mayamatakeshi)
Assigned to: Nobody/Anonymous (nobody)
Summary: Segfault when using pua_dialoginfo

Initial Comment:
I'm testing with presence and pua dialoginfo modules. It is segfaulting frequently.
I got this in the log file:
Nov 25 00:57:27 lab kernel: opensips[10924]: segfault at 0000000000000008 rip 00002b2fe86c65f9 rsp 00007fffc3b581e0 error 4

And here's a backtrace:

Program terminated with signal 11, Segmentation fault.
[New process 10924]
#0  0x00002b2fe86c65f9 in publ_build_hdr (expires=3600, ev=0x0, content_type=0x0, etag=0x2b2fe940c248, extra_headers=0x2b2fe940c335,
    is_body=0) at send_publish.c:80
80              memcpy(str_hdr->s+ str_hdr->len, ev->name.s, ev->name.len);
(gdb) bt full
#0  0x00002b2fe86c65f9 in publ_build_hdr (expires=3600, ev=0x0, content_type=0x0, etag=0x2b2fe940c248, extra_headers=0x2b2fe940c335,
    is_body=0) at send_publish.c:80
        str_hdr = (str *) 0x785ff0
        len = <value optimized out>
        t = <value optimized out>
        buf = "Max-Forwards: 70\r\nEvent: ", '\0' <repeats 2974 times>
        __FUNCTION__ = "publ_build_hdr"
#1  0x00002b2fe86c24d1 in update_pua (p=0x2b2fe940c1f8, hash_code=<value optimized out>) at pua.c:670
        met = {s = 0x2b2fe86d4ab1 "PUBLISH", len = 7}
        str_hdr = <value optimized out>
        expires = 3600
        result = <value optimized out>
        __FUNCTION__ = "update_pua"
#2  0x00002b2fe86c2f74 in hashT_clean (ticks=<value optimized out>, param=<value optimized out>) at pua.c:625
        i = <value optimized out>
        now = 1259078247
        p = (ua_pres_t *) 0x2b2fe940c1f8
        __FUNCTION__ = "hashT_clean"
#3  0x000000000048bf63 in start_timer_processes () at timer.c:325
        tpl = (struct sr_timer_process *) 0x784b20
        pid = <value optimized out>
        __FUNCTION__ = "start_timer_processes"
#4  0x00000000004297e1 in main (argc=3, argv=0x4) at main.c:867
        cfg_log_stderr = <value optimized out>
        cfg_stream = (FILE *) 0x1a715010
        c = <value optimized out>
        r = <value optimized out>
        tmp = 0x4f7d67 "H\215\005\222?#"
        tmp_len = <value optimized out>
        port = <value optimized out>
        proto = <value optimized out>
        ret = <value optimized out>
        seed = 2113776588
        rfd = <value optimized out>
        __FUNCTION__ = "main"

I'm using opensips 1.6. Revision: 6358.

For my tests, I just adapted the sample from here:
http://opensips.org/index.php?n=Resources.PuaDialoinfoConfig
(I'm attaching my cfg, just in case)



----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=2903244&group_id=232389


From noreply at sourceforge.net  Wed Nov 25 07:34:25 2009
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed, 25 Nov 2009 06:34:25 +0000
Subject: [OpenSIPS-Devel] [ opensips-Bugs-2903579 ] mysql_stmt_bind_param
	bind failed: Using unsupported buffer
Message-ID: <E1NDBSL-0003kn-Ts@665xhf1.ch3.sourceforge.com>

Bugs item #2903579, was opened at 2009-11-25 14:34
Message generated for change (Tracker Item Submitted) made by bestiring
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=2903579&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: Alexander Gong (bestiring)
Assigned to: Nobody/Anonymous (nobody)
Summary: mysql_stmt_bind_param bind failed: Using unsupported buffer 

Initial Comment:
Environment:  Red Hat E4U5, 
Packages:  
    opensips-1.6.0-tls_src.tar.gz,   get from trunk 
Mysql:  
     mysql-4.1.22-2.el4.i386.rpm  mysql-devel-4.1.22-2.el4.i386.rpm  mysql-server-4.1.22-2.el4.i386.rpm 

Error info in Log:
 Nov 25 12:21:43 localhost /usr/local/sbin/opensips[25063]: ERROR:db_mysql:db_mysql_do_prepared_query: mysql_stmt_bind_param() failed: Using unsupported buffer type: 0  (parameter: 10) 
Nov 25 12:21:43 localhost /usr/local/sbin/opensips[25063]: ERROR:db_mysql:db_mysql_do_prepared_query: param 0 was found as type 254 
Nov 25 12:21:43 localhost /usr/local/sbin/opensips[25063]: ERROR:db_mysql:db_mysql_do_prepared_query: param 1 was found as type 254 
Nov 25 12:21:43 localhost /usr/local/sbin/opensips[25063]: ERROR:db_mysql:db_mysql_do_prepared_query: param 2 was found as type 12 
Nov 25 12:21:43 localhost /usr/local/sbin/opensips[25063]: ERROR:db_mysql:db_mysql_do_prepared_query: param 3 was found as type 5 
Nov 25 12:21:43 localhost /usr/local/sbin/opensips[25063]: ERROR:db_mysql:db_mysql_do_prepared_query: param 4 was found as type 254 
Nov 25 12:21:43 localhost /usr/local/sbin/opensips[25063]: ERROR:db_mysql:db_mysql_do_prepared_query: param 5 was found as type 3 
Nov 25 12:21:43 localhost /usr/local/sbin/opensips[25063]: ERROR:db_mysql:db_mysql_do_prepared_query: param 6 was found as type 3 
Nov 25 12:21:43 localhost /usr/local/sbin/opensips[25063]: ERROR:db_mysql:db_mysql_do_prepared_query: param 7 was found as type 3 
Nov 25 12:21:43 localhost /usr/local/sbin/opensips[25063]: ERROR:db_mysql:db_mysql_do_prepared_query: param 8 was found as type 254 
Nov 25 12:21:43 localhost /usr/local/sbin/opensips[25063]: ERROR:db_mysql:db_mysql_do_prepared_query: param 9 was found as type 0 
Nov 25 12:21:43 localhost /usr/local/sbin/opensips[25063]: ERROR:db_mysql:db_mysql_do_prepared_query: param 10 was found as type 0 
Nov 25 12:21:43 localhost /usr/local/sbin/opensips[25063]: ERROR:db_mysql:db_mysql_do_prepared_query: param 11 was found as type 254 
Nov 25 12:21:43 localhost /usr/local/sbin/opensips[25063]: ERROR:db_mysql:db_mysql_do_prepared_query: param 12 was found as type 3 
Nov 25 12:21:43 localhost /usr/local/sbin/opensips[25063]: ERROR:db_mysql:db_mysql_do_prepared_query: param 13 was found as type 12 
Nov 25 12:21:43 localhost /usr/local/sbin/opensips[25063]: ERROR:usrloc:db_insert_ucontact: inserting contact in db failed 
Nov 25 12:21:43 localhost /usr/local/sbin/opensips[25063]: ERROR:usrloc:wb_timer: inserting contact into database failed 

************************************************************************
i compared the source code of db_mysql in packages with SVN current branch or trunk
there are no code changes, ex : 
dbase.c  , etc. 

Could you help me do the check? what's the problem
thanks 
 

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=2903579&group_id=232389


From anca at opensips.org  Wed Nov 25 12:03:15 2009
From: anca at opensips.org (Anca Vamanu)
Date: Wed, 25 Nov 2009 11:03:15 +0000
Subject: [OpenSIPS-Devel] SF.net SVN: opensips:[6359] trunk/modules/pua
Message-ID: <E1NDFeV-0006sl-CX@bj8yhf1.ch3.sourceforge.com>

Revision: 6359
          http://opensips.svn.sourceforge.net/opensips/?rev=6359&view=rev
Author:   anca_vamanu
Date:     2009-11-25 11:03:15 +0000 (Wed, 25 Nov 2009)

Log Message:
-----------
- added check if NULL value returned by get_event function

Modified Paths:
--------------
    trunk/modules/pua/event_list.c
    trunk/modules/pua/pua.c


This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site.


From noreply at sourceforge.net  Wed Nov 25 13:46:56 2009
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed, 25 Nov 2009 12:46:56 +0000
Subject: [OpenSIPS-Devel] [ opensips-Bugs-2903244 ] Segfault when using
	pua_dialoginfo
Message-ID: <E1NDHGq-0006IS-AI@155xhf1.ch3.sourceforge.com>

Bugs item #2903244, was opened at 2009-11-24 19:27
Message generated for change (Comment added) made by anca_vamanu
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=2903244&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.6.x
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: takeshi (mayamatakeshi)
Assigned to: Nobody/Anonymous (nobody)
Summary: Segfault when using pua_dialoginfo

Initial Comment:
I'm testing with presence and pua dialoginfo modules. It is segfaulting frequently.
I got this in the log file:
Nov 25 00:57:27 lab kernel: opensips[10924]: segfault at 0000000000000008 rip 00002b2fe86c65f9 rsp 00007fffc3b581e0 error 4

And here's a backtrace:

Program terminated with signal 11, Segmentation fault.
[New process 10924]
#0  0x00002b2fe86c65f9 in publ_build_hdr (expires=3600, ev=0x0, content_type=0x0, etag=0x2b2fe940c248, extra_headers=0x2b2fe940c335,
    is_body=0) at send_publish.c:80
80              memcpy(str_hdr->s+ str_hdr->len, ev->name.s, ev->name.len);
(gdb) bt full
#0  0x00002b2fe86c65f9 in publ_build_hdr (expires=3600, ev=0x0, content_type=0x0, etag=0x2b2fe940c248, extra_headers=0x2b2fe940c335,
    is_body=0) at send_publish.c:80
        str_hdr = (str *) 0x785ff0
        len = <value optimized out>
        t = <value optimized out>
        buf = "Max-Forwards: 70\r\nEvent: ", '\0' <repeats 2974 times>
        __FUNCTION__ = "publ_build_hdr"
#1  0x00002b2fe86c24d1 in update_pua (p=0x2b2fe940c1f8, hash_code=<value optimized out>) at pua.c:670
        met = {s = 0x2b2fe86d4ab1 "PUBLISH", len = 7}
        str_hdr = <value optimized out>
        expires = 3600
        result = <value optimized out>
        __FUNCTION__ = "update_pua"
#2  0x00002b2fe86c2f74 in hashT_clean (ticks=<value optimized out>, param=<value optimized out>) at pua.c:625
        i = <value optimized out>
        now = 1259078247
        p = (ua_pres_t *) 0x2b2fe940c1f8
        __FUNCTION__ = "hashT_clean"
#3  0x000000000048bf63 in start_timer_processes () at timer.c:325
        tpl = (struct sr_timer_process *) 0x784b20
        pid = <value optimized out>
        __FUNCTION__ = "start_timer_processes"
#4  0x00000000004297e1 in main (argc=3, argv=0x4) at main.c:867
        cfg_log_stderr = <value optimized out>
        cfg_stream = (FILE *) 0x1a715010
        c = <value optimized out>
        r = <value optimized out>
        tmp = 0x4f7d67 "H\215\005\222?#"
        tmp_len = <value optimized out>
        port = <value optimized out>
        proto = <value optimized out>
        ret = <value optimized out>
        seed = 2113776588
        rfd = <value optimized out>
        __FUNCTION__ = "main"

I'm using opensips 1.6. Revision: 6358.

For my tests, I just adapted the sample from here:
http://opensips.org/index.php?n=Resources.PuaDialoinfoConfig
(I'm attaching my cfg, just in case)



----------------------------------------------------------------------

>Comment By: Anca Vamanu (anca_vamanu)
Date: 2009-11-25 14:46

Message:
Hi,

I have made a fix now for that crash. Please update.

Regards,
Anca

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=2903244&group_id=232389


From noreply at sourceforge.net  Wed Nov 25 15:42:25 2009
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed, 25 Nov 2009 14:42:25 +0000
Subject: [OpenSIPS-Devel] [ opensips-Bugs-2903765 ] Many warning messages
	during compile
Message-ID: <E1NDJ4b-0006pe-RF@1bkjzd1.ch3.sourceforge.com>

Bugs item #2903765, was opened at 2009-11-25 14:42
Message generated for change (Tracker Item Submitted) made by norm_brandinger
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=2903765&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: trunk
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Norm Brandinger (norm_brandinger)
Assigned to: Nobody/Anonymous (nobody)
Summary: Many warning messages during compile

Initial Comment:
../../parser/parse_multipart.h:41:7: warning: no newline at end of file

One fix is to place a blank line at the end of the include file.  Perhaps there is a compiler option to suppress this warning or some other way to eliminate the warning message.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=2903765&group_id=232389


From noreply at sourceforge.net  Wed Nov 25 15:52:47 2009
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed, 25 Nov 2009 14:52:47 +0000
Subject: [OpenSIPS-Devel] [ opensips-Bugs-2903771 ] Many warning messages
	during compile
Message-ID: <E1NDJEd-0008C1-67@h45xhf1.ch3.sourceforge.com>

Bugs item #2903771, was opened at 2009-11-25 14:52
Message generated for change (Tracker Item Submitted) made by norm_brandinger
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=2903771&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: trunk
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Norm Brandinger (norm_brandinger)
Assigned to: Nobody/Anonymous (nobody)
Summary: Many warning messages during compile

Initial Comment:
../../parser/parse_multipart.h:41:7: warning: no newline at end of file

One fix is to place a blank line at the end of the include file.  Perhaps there is a compiler option to suppress this warning or some other way to eliminate the warning message.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=2903771&group_id=232389


From noreply at sourceforge.net  Wed Nov 25 17:20:23 2009
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed, 25 Nov 2009 16:20:23 +0000
Subject: [OpenSIPS-Devel] [ opensips-Bugs-2903829 ] mmegeoip module loading
	problem
Message-ID: <E1NDKbP-0001uM-A0@cdv4jf1.ch3.sourceforge.com>

Bugs item #2903829, was opened at 2009-11-25 16:20
Message generated for change (Tracker Item Submitted) made by nobody
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=2903829&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.6.x
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: mmegeoip module loading problem

Initial Comment:
opensips -c -f /etc/opensips/opensips.cfg
Nov 25 11:09:26 [10240] ERROR:core:sr_load_module: could not open module <//lib/opensips/modules/mmgeoip.so>: //lib/opensips/modules/mmgeoip.so: undefined symbol: GeoIP_time_zone_by_country_and_region
Nov 25 11:09:26 [10240] CRITICAL:core:yyerror: parse error in config file, line 68, column 13-14: failed to load module
Nov 25 11:09:26 [10240] ERROR:core:set_mod_param_regex: no module matching mmgeoip found
Nov 25 11:09:26 [10240] CRITICAL:core:yyerror: parse error in config file, line 272, column 19-20: Parameter <mmgeoip_city_db_path> not found in module <mmgeoip> - can't set
Nov 25 11:09:26 [10240] CRITICAL:core:yyerror: parse error in config file, line 295, column 32-49: syntax error
Nov 25 11:09:26 [10240] CRITICAL:core:yyerror: parse error in config file, line 295, column 49-50: bad arguments for command <mmg_lookup>
Nov 25 11:09:26 [10240] ERROR:core:main: bad config file (4 errors)



loadmodule "mmgeoip.so"

modparam("mmgeoip", "mmgeoip_city_db_path","/usr/share/GeoIP/GeoLiteCity.dat")

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=2903829&group_id=232389


From saul at ag-projects.com  Thu Nov 26 17:48:54 2009
From: saul at ag-projects.com (Saul Ibarra Corretge)
Date: Thu, 26 Nov 2009 17:48:54 +0100
Subject: [OpenSIPS-Devel] Enlarging xcap table doc field
Message-ID: <2D08C49E-6956-4A40-9D72-07BFEA3FFA06@ag-projects.com>

Hi,

We'll soon have icon application support in OpenXCAP and while testing I realized the documents where truncated upon insert because the 'doc' field is too small.

Currently 'doc' field is a BLOB, and is too small for storing a 256x256 base64 encoded image. We'd need that field to be at least MEDIUMBLOB.


Thanks!

-- 
Saul Ibarra Corretge
AG Projects






From saul at ag-projects.com  Thu Nov 26 19:40:00 2009
From: saul at ag-projects.com (Saul Ibarra Corretge)
Date: Thu, 26 Nov 2009 19:40:00 +0100
Subject: [OpenSIPS-Devel] Enlarging xcap table doc field
In-Reply-To: <2D08C49E-6956-4A40-9D72-07BFEA3FFA06@ag-projects.com>
References: <2D08C49E-6956-4A40-9D72-07BFEA3FFA06@ag-projects.com>
Message-ID: <693F1B72-6C07-4C70-80E1-EB2CDA451E7A@ag-projects.com>

Hi again,

My previous mail maybe wasn't really clear, let me explain it again:

There is an OMA spec (OMA-TS-Presence-SIMPLE_Content_XDM-V1_0) regarding icon storage on an XCAP server. We are actually implementing it in OpenXCAP when using OpenSIPS backend the 'doc' field is not able to accommodate the size of the icon. 

This could also happen with larger documents in the future so Anca, I would like to enlarge the field to MEDIUMBLOB if you have no objection?


Thanks in advance,

-- 
Saul Ibarra Corretge
AG Projects






From noreply at sourceforge.net  Thu Nov 26 21:22:54 2009
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 26 Nov 2009 20:22:54 +0000
Subject: [OpenSIPS-Devel] [ opensips-Bugs-2904684 ] Segfault at
	ip_addr.h:418 when listen=tls:<IP>:<PORT>
Message-ID: <E1NDkre-0004nf-4Q@b55xhf1.ch3.sourceforge.com>

Bugs item #2904684, was opened at 2009-11-26 20:22
Message generated for change (Tracker Item Submitted) made by nobody
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=2904684&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.6.x
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: Segfault at ip_addr.h:418 when listen=tls:<IP>:<PORT>

Initial Comment:
happen with latest 1.6 (rev 6359) when listen=tls:<IP>:<PORT> or listen=tcp:<IP>:<PORT> is set in opensips.cfg
does not happen when listen=udp:<IP>:<PORT> is set

Program received signal SIGSEGV, Segmentation fault.
init_acc_extra () at ../../ip_addr.h:418
418             switch(ip->af){
(gdb) bt
#0  init_acc_extra () at ../../ip_addr.h:418
#1  0xb7b8d06c in mod_init () at acc_mod.c:363
#2  0x080c00d5 in init_mod (m=0x81c2ff0) at sr_module.c:457
#3  0x08070c6a in main (argc=1, argv=0xbfd5ef14) at main.c:1351
(gdb) bt full
#0  init_acc_extra () at ../../ip_addr.h:418
No locals.
#1  0xb7b8d06c in mod_init () at acc_mod.c:363
        tmp = <value optimized out>
        __FUNCTION__ = "mod_init"
#2  0x080c00d5 in init_mod (m=0x81c2ff0) at sr_module.c:457
        __FUNCTION__ = "init_mod"
#3  0x08070c6a in main (argc=1, argv=0xbfd5ef14) at main.c:1351
        cfg_log_stderr = 0
        cfg_stream = (FILE *) 0x82be008
        c = <value optimized out>
        r = <value optimized out>
        tmp = 0xb7f1c028 ""
        tmp_len = <value optimized out>
        port = <value optimized out>
        proto = <value optimized out>
        ret = <value optimized out>
        seed = 1029995666
        rfd = 7
        __FUNCTION__ = "main"


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=2904684&group_id=232389


From ibc at aliax.net  Thu Nov 26 22:20:53 2009
From: ibc at aliax.net (=?iso-8859-1?q?I=F1aki_Baz_Castillo?=)
Date: Thu, 26 Nov 2009 22:20:53 +0100
Subject: [OpenSIPS-Devel] Enlarging xcap table doc field
In-Reply-To: <693F1B72-6C07-4C70-80E1-EB2CDA451E7A@ag-projects.com>
References: <2D08C49E-6956-4A40-9D72-07BFEA3FFA06@ag-projects.com>
	<693F1B72-6C07-4C70-80E1-EB2CDA451E7A@ag-projects.com>
Message-ID: <200911262220.53448.ibc@aliax.net>

El Jueves, 26 de Noviembre de 2009, Saul Ibarra Corretge escribi?:
> Hi again,
> 
> My previous mail maybe wasn't really clear, let me explain it again:
> 
> There is an OMA spec (OMA-TS-Presence-SIMPLE_Content_XDM-V1_0) regarding
>  icon storage on an XCAP server. We are actually implementing it in
>  OpenXCAP when using OpenSIPS backend the 'doc' field is not able to
>  accommodate the size of the icon.
> 
> This could also happen with larger documents in the future so Anca, I would
>  like to enlarge the field to MEDIUMBLOB if you have no objection?

IMHO a more scalable and suitable solution would be using different tables (or 
also databases) for each XCAP auid.

-- 
I?aki Baz Castillo <ibc at aliax.net>


From saul at ag-projects.com  Thu Nov 26 23:12:15 2009
From: saul at ag-projects.com (Saul Ibarra Corretge)
Date: Thu, 26 Nov 2009 23:12:15 +0100
Subject: [OpenSIPS-Devel] Enlarging xcap table doc field
In-Reply-To: <200911262220.53448.ibc@aliax.net>
References: <2D08C49E-6956-4A40-9D72-07BFEA3FFA06@ag-projects.com>
	<693F1B72-6C07-4C70-80E1-EB2CDA451E7A@ag-projects.com>
	<200911262220.53448.ibc@aliax.net>
Message-ID: <58FEECD8-0BD3-4A6B-A628-B5061F140091@ag-projects.com>


> IMHO a more scalable and suitable solution would be using different tables (or 
> also databases) for each XCAP auid.
> 

Documents are currently differenced by an integer field, so AFAIK having lots of documents stored is not much trouble for MySQL.

Having a table for each auid would make the addition of new applications more painful, don't you think? Now they are added seamlessly, well, apart from this little issue.


Regards,

-- 
Saul Ibarra Corretge
AG Projects






From noreply at sourceforge.net  Fri Nov 27 12:59:03 2009
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 27 Nov 2009 11:59:03 +0000
Subject: [OpenSIPS-Devel] [ opensips-Bugs-2904933 ] Field 'From' corrupted
	on HOLD
Message-ID: <E1NDzTb-00080Y-94@1bkjzd1.ch3.sourceforge.com>

Bugs item #2904933, was opened at 2009-11-27 14:59
Message generated for change (Tracker Item Submitted) made by kuznetsov82
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=2904933&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.5.x
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Vladimir Kuznetsov (kuznetsov82)
Assigned to: Nobody/Anonymous (nobody)
Summary: Field 'From' corrupted on HOLD

Initial Comment:
1. On first invite we use uac_replace_from in SIP config
2. On reinvite (hold) we have corrupt outgoing message like this (look to 'From' field):
NVITE sip:tstsipusr1 at 10.2.60.226:55748;rinstance=538c1ccfc0cc50ca SIP/2.0.
Via: SIP/2.0/UDP 10.2.176.238:5161;branch=z9hG4bK3077.feabda46.0.
Via: SIP/2.0/UDP 10.2.176.238;branch=z9hG4bK3077.b001a9f7.0.
Via: SIP/2.0/UDP 10.2.60.226:31290;received=10.2.60.226;branch=z9hG4bK-d8754z-351d13144e767d31-1---d8754z-;rport=31290.
Max-Forwards: 68.
Route: <sip:10.2.176.238;lr;ftag=322a7b31>.
Contact: <sip:2174626949 at 10.2.60.226:31290>.
To: "tstsipusr1"<sip:tstsipusr1 at yota.ru>;tag=69525808.
From: "2174626949"<sip:thedeath at yota.rusip:thedeath at yota.ru>;tag=322a7b31.
Call-ID: YzEyOTUzMjE4ZGJjMTkzYzgwZGE4OTkxMDA5YmNmNmU..
CSeq: 2 INVITE.
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY, MESSAGE, SUBSCRIBE, INFO.
Content-Type: application/sdp.
User-Agent: eyeBeam release 1102q stamp 51814.
Content-Length: 281.
.
v=0.
o=- 6 3 IN IP4 10.2.176.238.
s=CounterPath eyeBeam 1.5.
c=IN IP4 10.2.176.238.
t=0 0.
m=audio 21704 RTP/AVP 107 0 8 18 101.
a=fmtp:18 annexb=yes.
a=fmtp:101 0-15.
a=rtpmap:107 BV32/16000.
a=rtpmap:18 G729/8000.
a=rtpmap:101 telephone-event/8000.
a=sendonly.
a=nortpproxy:yes.


function restore_from (uac module) was called twice:

#0  restore_from (msg=0x7df840, is_from=0x7fff1814d2bc) at from.c:423
#1  0x00002b1f969d9279 in rr_checker (msg=0x7df840, r_param=<value optimized out>, cb_param=0x0) at from.c:543
#2  0x00002b1f931f2f15 in run_rr_callbacks (req=0x7df840, rr_params=0x2b1f933f5ad0) at rr_cb.c:89
#3  0x00002b1f931ed212 in after_loose (_m=0x7df840, preloaded=0) at loose.c:874
#4  0x00002b1f931f0088 in loose_route (_m=0x7df840, _s1=<value optimized out>, _s2=<value optimized out>) at loose.c:910
#5  0x000000000040ddfc in do_action (a=0x774f10, msg=0x7df840) at action.c:962
#6  0x000000000041089e in run_action_list (a=<value optimized out>, msg=0x7df840) at action.c:139
#7  0x000000000045ed02 in eval_expr (e=0x774fe0, msg=0x7df840, val=0x0) at route.c:1189
#8  0x000000000045e725 in eval_expr (e=0x775028, msg=0x7df840, val=0x0) at route.c:1507
#9  0x000000000040cdef in do_action (a=0x7765a8, msg=0x7df840) at action.c:689
#10 0x000000000041089e in run_action_list (a=<value optimized out>, msg=0x7df840) at action.c:139
#11 0x0000000000410bf9 in run_top_route (a=0x773c90, msg=0x7df840) at action.c:119
#12 0x000000000044f56f in receive_msg (
    buf=0x7420c0 "INVITE sip:andrey11 at 10.2.44.153:56867;rinstance=b7437acf90db9db6 SIP/2.0\r\nVia: SIP/2.0/UDP 10.2.176.223;branch=z9hG4bK97f5.58d94591.0\r\nVia: SIP/2.0/UDP 10.2.44.153:27905;received=10.2.44.153;branch=z9"..., len=1011, rcv_info=0x7fff1814e300) at receive.c:164
#13 0x000000000048f05e in udp_rcv_loop () at udp_server.c:449
#14 0x00000000004279be in main (argc=5, argv=0x7fff1814e508) at main.c:692


#0  restore_from (msg=0x7df840, is_from=0x7fff1814c31c) at from.c:423
#1  0x00002b1f969d9279 in rr_checker (msg=0x7df840, r_param=<value optimized out>, cb_param=0x0) at from.c:543
#2  0x00002b1f931f2f15 in run_rr_callbacks (req=0x7df840, rr_params=0x2b1f933f5ad0) at rr_cb.c:89
#3  0x00002b1f931ed212 in after_loose (_m=0x7df840, preloaded=0) at loose.c:874
#4  0x00002b1f931f0088 in loose_route (_m=0x7df840, _s1=<value optimized out>, _s2=<value optimized out>) at loose.c:910
#5  0x000000000040ddfc in do_action (a=0x790e98, msg=0x7df840) at action.c:962
#6  0x000000000041089e in run_action_list (a=<value optimized out>, msg=0x7df840) at action.c:139
#7  0x000000000045ed02 in eval_expr (e=0x790f68, msg=0x7df840, val=0x0) at route.c:1189
#8  0x000000000045e797 in eval_expr (e=0x791158, msg=0x7df840, val=0x0) at route.c:1490
#9  0x000000000045e797 in eval_expr (e=0x7913d8, msg=0x7df840, val=0x0) at route.c:1490
#10 0x000000000045e725 in eval_expr (e=0x791420, msg=0x7df840, val=0x0) at route.c:1507
#11 0x000000000040cdef in do_action (a=0x796380, msg=0x7df840) at action.c:689
#12 0x000000000041089e in run_action_list (a=<value optimized out>, msg=0x7df840) at action.c:139
#13 0x000000000040ec40 in do_action (a=0x796450, msg=0x7df840) at action.c:706
#14 0x000000000041089e in run_action_list (a=<value optimized out>, msg=0x7df840) at action.c:139
#15 0x000000000040ebac in do_action (a=0x7764d8, msg=0x7df840) at action.c:119
#16 0x000000000041089e in run_action_list (a=<value optimized out>, msg=0x7df840) at action.c:139
#17 0x000000000040ec40 in do_action (a=0x7765a8, msg=0x7df840) at action.c:706
#18 0x000000000041089e in run_action_list (a=<value optimized out>, msg=0x7df840) at action.c:139
#19 0x0000000000410bf9 in run_top_route (a=0x773c90, msg=0x7df840) at action.c:119
#20 0x000000000044f56f in receive_msg (
    buf=0x7420c0 "INVITE sip:andrey11 at 10.2.44.153:56867;rinstance=b7437acf90db9db6 SIP/2.0\r\nVia: SIP/2.0/UDP 10.2.176.223;branch=z9hG4bK97f5.58d94591.0\r\nVia: SIP/2.0/UDP 10.2.44.153:27905;received=10.2.44.153;branch=z9"..., len=1011, rcv_info=0x7fff1814e300) at receive.c:164
#21 0x000000000048f05e in udp_rcv_loop () at udp_server.c:449
#22 0x00000000004279be in main (argc=5, argv=0x7fff1814e508) at main.c:692

I have a question:
1. How I can understand why?
2. Is it wrong configuration file or bug in source code?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=2904933&group_id=232389


From ibc at aliax.net  Fri Nov 27 13:47:21 2009
From: ibc at aliax.net (=?UTF-8?Q?I=C3=B1aki_Baz_Castillo?=)
Date: Fri, 27 Nov 2009 13:47:21 +0100
Subject: [OpenSIPS-Devel] Enlarging xcap table doc field
In-Reply-To: <58FEECD8-0BD3-4A6B-A628-B5061F140091@ag-projects.com>
References: <2D08C49E-6956-4A40-9D72-07BFEA3FFA06@ag-projects.com>
	<693F1B72-6C07-4C70-80E1-EB2CDA451E7A@ag-projects.com>
	<200911262220.53448.ibc@aliax.net>
	<58FEECD8-0BD3-4A6B-A628-B5061F140091@ag-projects.com>
Message-ID: <cc1f582e0911270447nf020edavec48c5988347a1a8@mail.gmail.com>

2009/11/26 Saul Ibarra Corretge <saul at ag-projects.com>:
>
>> IMHO a more scalable and suitable solution would be using different tables (or
>> also databases) for each XCAP auid.
>>
>
> Documents are currently differenced by an integer field, so AFAIK having lots of documents stored is not much trouble for MySQL.

In a high load environment I wouldn't like to imagine a MySQL MyISAM
table (xcap) storing millions of rows with a MEDIUMBLOB field. Such
kind of tables get corrupted after some time and so, for sure.
IMHO is not a good design.


> Having a table for each auid would make the addition of new applications more painful, don't you think? Now they are added seamlessly, well, apart from this little issue.

XCAP application are (should be) standarized, and AFAIK for now XCAP
related RFC's define just 3-4 auids, and OMA defines 6-7.



-- 
I?aki Baz Castillo
<ibc at aliax.net>


From noreply at sourceforge.net  Fri Nov 27 13:50:53 2009
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 27 Nov 2009 12:50:53 +0000
Subject: [OpenSIPS-Devel] [ opensips-Bugs-2904933 ] Field 'From' corrupted
	on HOLD
Message-ID: <E1NE0Hl-00032l-KC@665xhf1.ch3.sourceforge.com>

Bugs item #2904933, was opened at 2009-11-27 14:59
Message generated for change (Comment added) made by kuznetsov82
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=2904933&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.5.x
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Vladimir Kuznetsov (kuznetsov82)
Assigned to: Nobody/Anonymous (nobody)
Summary: Field 'From' corrupted on HOLD

Initial Comment:
1. On first invite we use uac_replace_from in SIP config
2. On reinvite (hold) we have corrupt outgoing message like this (look to 'From' field):
NVITE sip:tstsipusr1 at 10.2.60.226:55748;rinstance=538c1ccfc0cc50ca SIP/2.0.
Via: SIP/2.0/UDP 10.2.176.238:5161;branch=z9hG4bK3077.feabda46.0.
Via: SIP/2.0/UDP 10.2.176.238;branch=z9hG4bK3077.b001a9f7.0.
Via: SIP/2.0/UDP 10.2.60.226:31290;received=10.2.60.226;branch=z9hG4bK-d8754z-351d13144e767d31-1---d8754z-;rport=31290.
Max-Forwards: 68.
Route: <sip:10.2.176.238;lr;ftag=322a7b31>.
Contact: <sip:2174626949 at 10.2.60.226:31290>.
To: "tstsipusr1"<sip:tstsipusr1 at yota.ru>;tag=69525808.
From: "2174626949"<sip:thedeath at yota.rusip:thedeath at yota.ru>;tag=322a7b31.
Call-ID: YzEyOTUzMjE4ZGJjMTkzYzgwZGE4OTkxMDA5YmNmNmU..
CSeq: 2 INVITE.
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY, MESSAGE, SUBSCRIBE, INFO.
Content-Type: application/sdp.
User-Agent: eyeBeam release 1102q stamp 51814.
Content-Length: 281.
.
v=0.
o=- 6 3 IN IP4 10.2.176.238.
s=CounterPath eyeBeam 1.5.
c=IN IP4 10.2.176.238.
t=0 0.
m=audio 21704 RTP/AVP 107 0 8 18 101.
a=fmtp:18 annexb=yes.
a=fmtp:101 0-15.
a=rtpmap:107 BV32/16000.
a=rtpmap:18 G729/8000.
a=rtpmap:101 telephone-event/8000.
a=sendonly.
a=nortpproxy:yes.


function restore_from (uac module) was called twice:

#0  restore_from (msg=0x7df840, is_from=0x7fff1814d2bc) at from.c:423
#1  0x00002b1f969d9279 in rr_checker (msg=0x7df840, r_param=<value optimized out>, cb_param=0x0) at from.c:543
#2  0x00002b1f931f2f15 in run_rr_callbacks (req=0x7df840, rr_params=0x2b1f933f5ad0) at rr_cb.c:89
#3  0x00002b1f931ed212 in after_loose (_m=0x7df840, preloaded=0) at loose.c:874
#4  0x00002b1f931f0088 in loose_route (_m=0x7df840, _s1=<value optimized out>, _s2=<value optimized out>) at loose.c:910
#5  0x000000000040ddfc in do_action (a=0x774f10, msg=0x7df840) at action.c:962
#6  0x000000000041089e in run_action_list (a=<value optimized out>, msg=0x7df840) at action.c:139
#7  0x000000000045ed02 in eval_expr (e=0x774fe0, msg=0x7df840, val=0x0) at route.c:1189
#8  0x000000000045e725 in eval_expr (e=0x775028, msg=0x7df840, val=0x0) at route.c:1507
#9  0x000000000040cdef in do_action (a=0x7765a8, msg=0x7df840) at action.c:689
#10 0x000000000041089e in run_action_list (a=<value optimized out>, msg=0x7df840) at action.c:139
#11 0x0000000000410bf9 in run_top_route (a=0x773c90, msg=0x7df840) at action.c:119
#12 0x000000000044f56f in receive_msg (
    buf=0x7420c0 "INVITE sip:andrey11 at 10.2.44.153:56867;rinstance=b7437acf90db9db6 SIP/2.0\r\nVia: SIP/2.0/UDP 10.2.176.223;branch=z9hG4bK97f5.58d94591.0\r\nVia: SIP/2.0/UDP 10.2.44.153:27905;received=10.2.44.153;branch=z9"..., len=1011, rcv_info=0x7fff1814e300) at receive.c:164
#13 0x000000000048f05e in udp_rcv_loop () at udp_server.c:449
#14 0x00000000004279be in main (argc=5, argv=0x7fff1814e508) at main.c:692


#0  restore_from (msg=0x7df840, is_from=0x7fff1814c31c) at from.c:423
#1  0x00002b1f969d9279 in rr_checker (msg=0x7df840, r_param=<value optimized out>, cb_param=0x0) at from.c:543
#2  0x00002b1f931f2f15 in run_rr_callbacks (req=0x7df840, rr_params=0x2b1f933f5ad0) at rr_cb.c:89
#3  0x00002b1f931ed212 in after_loose (_m=0x7df840, preloaded=0) at loose.c:874
#4  0x00002b1f931f0088 in loose_route (_m=0x7df840, _s1=<value optimized out>, _s2=<value optimized out>) at loose.c:910
#5  0x000000000040ddfc in do_action (a=0x790e98, msg=0x7df840) at action.c:962
#6  0x000000000041089e in run_action_list (a=<value optimized out>, msg=0x7df840) at action.c:139
#7  0x000000000045ed02 in eval_expr (e=0x790f68, msg=0x7df840, val=0x0) at route.c:1189
#8  0x000000000045e797 in eval_expr (e=0x791158, msg=0x7df840, val=0x0) at route.c:1490
#9  0x000000000045e797 in eval_expr (e=0x7913d8, msg=0x7df840, val=0x0) at route.c:1490
#10 0x000000000045e725 in eval_expr (e=0x791420, msg=0x7df840, val=0x0) at route.c:1507
#11 0x000000000040cdef in do_action (a=0x796380, msg=0x7df840) at action.c:689
#12 0x000000000041089e in run_action_list (a=<value optimized out>, msg=0x7df840) at action.c:139
#13 0x000000000040ec40 in do_action (a=0x796450, msg=0x7df840) at action.c:706
#14 0x000000000041089e in run_action_list (a=<value optimized out>, msg=0x7df840) at action.c:139
#15 0x000000000040ebac in do_action (a=0x7764d8, msg=0x7df840) at action.c:119
#16 0x000000000041089e in run_action_list (a=<value optimized out>, msg=0x7df840) at action.c:139
#17 0x000000000040ec40 in do_action (a=0x7765a8, msg=0x7df840) at action.c:706
#18 0x000000000041089e in run_action_list (a=<value optimized out>, msg=0x7df840) at action.c:139
#19 0x0000000000410bf9 in run_top_route (a=0x773c90, msg=0x7df840) at action.c:119
#20 0x000000000044f56f in receive_msg (
    buf=0x7420c0 "INVITE sip:andrey11 at 10.2.44.153:56867;rinstance=b7437acf90db9db6 SIP/2.0\r\nVia: SIP/2.0/UDP 10.2.176.223;branch=z9hG4bK97f5.58d94591.0\r\nVia: SIP/2.0/UDP 10.2.44.153:27905;received=10.2.44.153;branch=z9"..., len=1011, rcv_info=0x7fff1814e300) at receive.c:164
#21 0x000000000048f05e in udp_rcv_loop () at udp_server.c:449
#22 0x00000000004279be in main (argc=5, argv=0x7fff1814e508) at main.c:692

I have a question:
1. How I can understand why?
2. Is it wrong configuration file or bug in source code?

----------------------------------------------------------------------

>Comment By: Vladimir Kuznetsov (kuznetsov82)
Date: 2009-11-27 15:50

Message:
This situation reproduces when we have two loose_route() calls in SIP
configuration. I think it is bug, because I can corrupt data just with
using config.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=2904933&group_id=232389


From saul at ag-projects.com  Fri Nov 27 13:59:07 2009
From: saul at ag-projects.com (Saul Ibarra Corretge)
Date: Fri, 27 Nov 2009 13:59:07 +0100
Subject: [OpenSIPS-Devel] Enlarging xcap table doc field
In-Reply-To: <cc1f582e0911270447nf020edavec48c5988347a1a8@mail.gmail.com>
References: <2D08C49E-6956-4A40-9D72-07BFEA3FFA06@ag-projects.com>
	<693F1B72-6C07-4C70-80E1-EB2CDA451E7A@ag-projects.com>
	<200911262220.53448.ibc@aliax.net>
	<58FEECD8-0BD3-4A6B-A628-B5061F140091@ag-projects.com>
	<cc1f582e0911270447nf020edavec48c5988347a1a8@mail.gmail.com>
Message-ID: <33B63F65-F7AE-4E57-A2E4-841CA6963FDE@ag-projects.com>

> 
> In a high load environment I wouldn't like to imagine a MySQL MyISAM
> table (xcap) storing millions of rows with a MEDIUMBLOB field. Such
> kind of tables get corrupted after some time and so, for sure.
> IMHO is not a good design.
> 

No binary data gets stored, it's just text. An XML with a base64 encoded image. Do you think storing at most 16MB of text (there are size constraints for the image so i'll never get bigger than a few MBs) it could get corrupted?


-- 
Saul Ibarra Corretge
AG Projects






From doolinwu at gmail.com  Sat Nov 28 14:41:45 2009
From: doolinwu at gmail.com (doolin wu)
Date: Sat, 28 Nov 2009 21:41:45 +0800
Subject: [OpenSIPS-Devel] Regarding the CANCEL request
In-Reply-To: <f3085a9c0911262106r2eeec806s2c5da7313e9e39e1@mail.gmail.com>
References: <f3085a9c0911262106r2eeec806s2c5da7313e9e39e1@mail.gmail.com>
Message-ID: <f3085a9c0911280541o238fe5ck81f9c910eb7db3c7@mail.gmail.com>

>
>
> I'm facing a CANCEL problem now. The problem can be described as "UAC
> canceled the INVITE but UAS still state ringing status"
> The UAS is a desk phone connected to VoIP network by a VoIP gatway, the SIP
> server is OpenSIPS 1.5.
>
> Based on the SIP singaling at UAC side, there scenarios to cause the
> problem:
> *1. Cancel before 407 Proxy Authentication Required*
> INVITE ->
> 100 ->
> CANCEL->
> 200 for CANCEL ( from proxy server)<-
> 407 for INVITE <-
> ACK ->
> INVITE (with authorization) ->
> 180 <-
>
> In this case, the INVITE with authorization caused the UAS rining.
> My question is shall UAC send INVITE after receive 407 if the first INVITE
> is canceling?
> ...
> *2. Cancel after 407 Proxy Authentication Required.*
> INVITE ->
> 100 ->
> 407 <-
> CANCEL->
> 400 for CANCEL <-
> ACK ->
> INVITE (with authorization) ->
> 180 <-
> The reason caused UAS rining is same with case 1.
> How to handle this scenario?
> The cancel was treated as bad request due to the INVITE has generate final
> response 407.
> Shall UAC send CANCEL again when receive 180?
> --
> Best Regards,
> Steven Wu
>



-- 
Steven Wu
Teleca Mobile Solution
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.opensips.org/pipermail/devel/attachments/20091128/e4ca0ccb/attachment.htm 

From ibc at aliax.net  Sat Nov 28 19:30:04 2009
From: ibc at aliax.net (=?UTF-8?Q?I=C3=B1aki_Baz_Castillo?=)
Date: Sat, 28 Nov 2009 19:30:04 +0100
Subject: [OpenSIPS-Devel] Enlarging xcap table doc field
In-Reply-To: <33B63F65-F7AE-4E57-A2E4-841CA6963FDE@ag-projects.com>
References: <2D08C49E-6956-4A40-9D72-07BFEA3FFA06@ag-projects.com>
	<693F1B72-6C07-4C70-80E1-EB2CDA451E7A@ag-projects.com>
	<200911262220.53448.ibc@aliax.net>
	<58FEECD8-0BD3-4A6B-A628-B5061F140091@ag-projects.com>
	<cc1f582e0911270447nf020edavec48c5988347a1a8@mail.gmail.com>
	<33B63F65-F7AE-4E57-A2E4-841CA6963FDE@ag-projects.com>
Message-ID: <cc1f582e0911281030q7e2584c7j8d84fc7e7902e695@mail.gmail.com>

2009/11/27 Saul Ibarra Corretge <saul at ag-projects.com>:
>>
>> In a high load environment I wouldn't like to imagine a MySQL MyISAM
>> table (xcap) storing millions of rows with a MEDIUMBLOB field. Such
>> kind of tables get corrupted after some time and so, for sure.
>> IMHO is not a good design.
>>
>
> No binary data gets stored, it's just text.

It doesn't matter fi it's text or binary, finally it's MySQL data :)


> An XML with a base64 encoded image. Do you think storing at most 16MB of text (there are size constraints for the image so i'll never get bigger than a few MBs) it could get corrupted?

Let's suppose a provider with 10000 users using XCAP.
Also imagine 50Kb per image/icon plus 1Kb per text XML document. Let's
suppose 3 documents per user (pres-rules, resource-list and icon). So
we end with more than 500 MB in the xcap table.

Under my experience, MySQL large tables get corrupted "some times",
and that's really more probable if the table contains long fields.
This is as least what I've issued working with MySQL MyISAM long
tables.




-- 
I?aki Baz Castillo
<ibc at aliax.net>


From noreply at sourceforge.net  Mon Nov 30 08:34:15 2009
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 30 Nov 2009 07:34:15 +0000
Subject: [OpenSIPS-Devel] [ opensips-Bugs-2903771 ] Many warning messages
	during compile
Message-ID: <E1NF0lz-0002Q0-8T@cdv4jf1.ch3.sourceforge.com>

Bugs item #2903771, was opened at 2009-11-25 16:52
Message generated for change (Settings changed) made by bogdan_iancu
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=2903771&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: trunk
>Status: Deleted
>Resolution: Duplicate
Priority: 5
Private: No
Submitted By: Norm Brandinger (norm_brandinger)
Assigned to: Nobody/Anonymous (nobody)
Summary: Many warning messages during compile

Initial Comment:
../../parser/parse_multipart.h:41:7: warning: no newline at end of file

One fix is to place a blank line at the end of the include file.  Perhaps there is a compiler option to suppress this warning or some other way to eliminate the warning message.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=2903771&group_id=232389


From bogdan at voice-system.ro  Mon Nov 30 08:50:37 2009
From: bogdan at voice-system.ro (Bogdan-Andrei Iancu)
Date: Mon, 30 Nov 2009 07:50:37 +0000
Subject: [OpenSIPS-Devel] SF.net SVN: opensips:[6360] trunk/parser
Message-ID: <E1NF11p-0002FR-AX@74yxhf1.ch3.sourceforge.com>

Revision: 6360
          http://opensips.svn.sourceforge.net/opensips/?rev=6360&view=rev
Author:   bogdan_iancu
Date:     2009-11-30 07:50:37 +0000 (Mon, 30 Nov 2009)

Log Message:
-----------
- added new line at the end of the file to get rid of compile warning.
  Closes bug #2903765

Modified Paths:
--------------
    trunk/parser/parse_multipart.c
    trunk/parser/parse_multipart.h


This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site.


From noreply at sourceforge.net  Mon Nov 30 08:50:59 2009
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 30 Nov 2009 07:50:59 +0000
Subject: [OpenSIPS-Devel] [ opensips-Bugs-2903765 ] Many warning messages
	during compile
Message-ID: <E1NF12B-0000uo-Kn@h45xhf1.ch3.sourceforge.com>

Bugs item #2903765, was opened at 2009-11-25 16:42
Message generated for change (Comment added) made by bogdan_iancu
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=2903765&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: trunk
>Status: Closed
>Resolution: Fixed
Priority: 5
Private: No
Submitted By: Norm Brandinger (norm_brandinger)
>Assigned to: Bogdan-Andrei Iancu (bogdan_iancu)
Summary: Many warning messages during compile

Initial Comment:
../../parser/parse_multipart.h:41:7: warning: no newline at end of file

One fix is to place a blank line at the end of the include file.  Perhaps there is a compiler option to suppress this warning or some other way to eliminate the warning message.

----------------------------------------------------------------------

>Comment By: Bogdan-Andrei Iancu (bogdan_iancu)
Date: 2009-11-30 09:50

Message:
Fixed ! 

Thanks and regards,
Bogdan

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=2903765&group_id=232389


From noreply at sourceforge.net  Mon Nov 30 08:52:26 2009
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 30 Nov 2009 07:52:26 +0000
Subject: [OpenSIPS-Devel] [ opensips-Bugs-2903829 ] mmegeoip module loading
	problem
Message-ID: <E1NF13a-0004O8-90@g45xhf1.ch3.sourceforge.com>

Bugs item #2903829, was opened at 2009-11-25 18:20
Message generated for change (Settings changed) made by bogdan_iancu
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=2903829&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.6.x
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Nobody/Anonymous (nobody)
>Assigned to: Kobi Eshun (ekobi)
Summary: mmegeoip module loading problem

Initial Comment:
opensips -c -f /etc/opensips/opensips.cfg
Nov 25 11:09:26 [10240] ERROR:core:sr_load_module: could not open module <//lib/opensips/modules/mmgeoip.so>: //lib/opensips/modules/mmgeoip.so: undefined symbol: GeoIP_time_zone_by_country_and_region
Nov 25 11:09:26 [10240] CRITICAL:core:yyerror: parse error in config file, line 68, column 13-14: failed to load module
Nov 25 11:09:26 [10240] ERROR:core:set_mod_param_regex: no module matching mmgeoip found
Nov 25 11:09:26 [10240] CRITICAL:core:yyerror: parse error in config file, line 272, column 19-20: Parameter <mmgeoip_city_db_path> not found in module <mmgeoip> - can't set
Nov 25 11:09:26 [10240] CRITICAL:core:yyerror: parse error in config file, line 295, column 32-49: syntax error
Nov 25 11:09:26 [10240] CRITICAL:core:yyerror: parse error in config file, line 295, column 49-50: bad arguments for command <mmg_lookup>
Nov 25 11:09:26 [10240] ERROR:core:main: bad config file (4 errors)



loadmodule "mmgeoip.so"

modparam("mmgeoip", "mmgeoip_city_db_path","/usr/share/GeoIP/GeoLiteCity.dat")

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=2903829&group_id=232389


From bogdan at voice-system.ro  Mon Nov 30 09:53:14 2009
From: bogdan at voice-system.ro (Bogdan-Andrei Iancu)
Date: Mon, 30 Nov 2009 08:53:14 +0000
Subject: [OpenSIPS-Devel] SF.net SVN: opensips:[6361]
	trunk/modules/acc/acc_extra.c
Message-ID: <E1NF20Q-0001IN-EX@3kljzd1.ch3.sourceforge.com>

Revision: 6361
          http://opensips.svn.sourceforge.net/opensips/?rev=6361&view=rev
Author:   bogdan_iancu
Date:     2009-11-30 08:53:14 +0000 (Mon, 30 Nov 2009)

Log Message:
-----------
- fixed detection of static string (used for string IPs) when UDP is not used.
  Closes bug #2904684. 

Modified Paths:
--------------
    trunk/modules/acc/acc_extra.c


This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site.


From bogdan at voice-system.ro  Mon Nov 30 09:54:36 2009
From: bogdan at voice-system.ro (Bogdan-Andrei Iancu)
Date: Mon, 30 Nov 2009 08:54:36 +0000
Subject: [OpenSIPS-Devel] SF.net SVN: opensips:[6362]
	branches/1.5/modules/acc/acc_extra.c
Message-ID: <E1NF21k-0001Jb-3e@3kljzd1.ch3.sourceforge.com>

Revision: 6362
          http://opensips.svn.sourceforge.net/opensips/?rev=6362&view=rev
Author:   bogdan_iancu
Date:     2009-11-30 08:54:35 +0000 (Mon, 30 Nov 2009)

Log Message:
-----------
backport from trunk (rev #6361):
- fixed detection of static string (used for string IPs) when UDP is not used.
  Closes bug #2904684.

Revision Links:
--------------
    http://opensips.svn.sourceforge.net/opensips/?rev=6361&view=rev

Modified Paths:
--------------
    branches/1.5/modules/acc/acc_extra.c


This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site.


From bogdan at voice-system.ro  Mon Nov 30 09:55:58 2009
From: bogdan at voice-system.ro (Bogdan-Andrei Iancu)
Date: Mon, 30 Nov 2009 08:55:58 +0000
Subject: [OpenSIPS-Devel] SF.net SVN: opensips:[6363]
	branches/1.6/modules/acc/acc_extra.c
Message-ID: <E1NF234-0001LR-J7@3kljzd1.ch3.sourceforge.com>

Revision: 6363
          http://opensips.svn.sourceforge.net/opensips/?rev=6363&view=rev
Author:   bogdan_iancu
Date:     2009-11-30 08:55:58 +0000 (Mon, 30 Nov 2009)

Log Message:
-----------
backport from trunk (rev #6361):
- fixed detection of static string (used for string IPs) when UDP is not used.
  Closes bug #2904684.

Revision Links:
--------------
    http://opensips.svn.sourceforge.net/opensips/?rev=6361&view=rev

Modified Paths:
--------------
    branches/1.6/modules/acc/acc_extra.c


This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site.


From noreply at sourceforge.net  Mon Nov 30 09:56:19 2009
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 30 Nov 2009 08:56:19 +0000
Subject: [OpenSIPS-Devel] [ opensips-Bugs-2904684 ] Segfault at
	ip_addr.h:418 when listen=tls:<IP>:<PORT>
Message-ID: <E1NF23P-0006j1-VE@d45xhf1.ch3.sourceforge.com>

Bugs item #2904684, was opened at 2009-11-26 22:22
Message generated for change (Settings changed) made by bogdan_iancu
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=2904684&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.6.x
>Status: Closed
>Resolution: Fixed
Priority: 5
Private: No
Submitted By: Nobody/Anonymous (nobody)
>Assigned to: Bogdan-Andrei Iancu (bogdan_iancu)
Summary: Segfault at ip_addr.h:418 when listen=tls:<IP>:<PORT>

Initial Comment:
happen with latest 1.6 (rev 6359) when listen=tls:<IP>:<PORT> or listen=tcp:<IP>:<PORT> is set in opensips.cfg
does not happen when listen=udp:<IP>:<PORT> is set

Program received signal SIGSEGV, Segmentation fault.
init_acc_extra () at ../../ip_addr.h:418
418             switch(ip->af){
(gdb) bt
#0  init_acc_extra () at ../../ip_addr.h:418
#1  0xb7b8d06c in mod_init () at acc_mod.c:363
#2  0x080c00d5 in init_mod (m=0x81c2ff0) at sr_module.c:457
#3  0x08070c6a in main (argc=1, argv=0xbfd5ef14) at main.c:1351
(gdb) bt full
#0  init_acc_extra () at ../../ip_addr.h:418
No locals.
#1  0xb7b8d06c in mod_init () at acc_mod.c:363
        tmp = <value optimized out>
        __FUNCTION__ = "mod_init"
#2  0x080c00d5 in init_mod (m=0x81c2ff0) at sr_module.c:457
        __FUNCTION__ = "init_mod"
#3  0x08070c6a in main (argc=1, argv=0xbfd5ef14) at main.c:1351
        cfg_log_stderr = 0
        cfg_stream = (FILE *) 0x82be008
        c = <value optimized out>
        r = <value optimized out>
        tmp = 0xb7f1c028 ""
        tmp_len = <value optimized out>
        port = <value optimized out>
        proto = <value optimized out>
        ret = <value optimized out>
        seed = 1029995666
        rfd = 7
        __FUNCTION__ = "main"


----------------------------------------------------------------------

>Comment By: Bogdan-Andrei Iancu (bogdan_iancu)
Date: 2009-11-30 10:56

Message:
Fix is available on all versions starting with 1.5.

Thanks and regards,
Bogdan

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=2904684&group_id=232389


From noreply at sourceforge.net  Mon Nov 30 10:04:40 2009
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 30 Nov 2009 09:04:40 +0000
Subject: [OpenSIPS-Devel] [ opensips-Bugs-2904933 ] Field 'From' corrupted
	on HOLD
Message-ID: <E1NF2BU-0004mF-He@665xhf1.ch3.sourceforge.com>

Bugs item #2904933, was opened at 2009-11-27 13:59
Message generated for change (Comment added) made by bogdan_iancu
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=2904933&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.5.x
Status: Open
>Resolution: Invalid
Priority: 5
Private: No
Submitted By: Vladimir Kuznetsov (kuznetsov82)
>Assigned to: Bogdan-Andrei Iancu (bogdan_iancu)
Summary: Field 'From' corrupted on HOLD

Initial Comment:
1. On first invite we use uac_replace_from in SIP config
2. On reinvite (hold) we have corrupt outgoing message like this (look to 'From' field):
NVITE sip:tstsipusr1 at 10.2.60.226:55748;rinstance=538c1ccfc0cc50ca SIP/2.0.
Via: SIP/2.0/UDP 10.2.176.238:5161;branch=z9hG4bK3077.feabda46.0.
Via: SIP/2.0/UDP 10.2.176.238;branch=z9hG4bK3077.b001a9f7.0.
Via: SIP/2.0/UDP 10.2.60.226:31290;received=10.2.60.226;branch=z9hG4bK-d8754z-351d13144e767d31-1---d8754z-;rport=31290.
Max-Forwards: 68.
Route: <sip:10.2.176.238;lr;ftag=322a7b31>.
Contact: <sip:2174626949 at 10.2.60.226:31290>.
To: "tstsipusr1"<sip:tstsipusr1 at yota.ru>;tag=69525808.
From: "2174626949"<sip:thedeath at yota.rusip:thedeath at yota.ru>;tag=322a7b31.
Call-ID: YzEyOTUzMjE4ZGJjMTkzYzgwZGE4OTkxMDA5YmNmNmU..
CSeq: 2 INVITE.
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY, MESSAGE, SUBSCRIBE, INFO.
Content-Type: application/sdp.
User-Agent: eyeBeam release 1102q stamp 51814.
Content-Length: 281.
.
v=0.
o=- 6 3 IN IP4 10.2.176.238.
s=CounterPath eyeBeam 1.5.
c=IN IP4 10.2.176.238.
t=0 0.
m=audio 21704 RTP/AVP 107 0 8 18 101.
a=fmtp:18 annexb=yes.
a=fmtp:101 0-15.
a=rtpmap:107 BV32/16000.
a=rtpmap:18 G729/8000.
a=rtpmap:101 telephone-event/8000.
a=sendonly.
a=nortpproxy:yes.


function restore_from (uac module) was called twice:

#0  restore_from (msg=0x7df840, is_from=0x7fff1814d2bc) at from.c:423
#1  0x00002b1f969d9279 in rr_checker (msg=0x7df840, r_param=<value optimized out>, cb_param=0x0) at from.c:543
#2  0x00002b1f931f2f15 in run_rr_callbacks (req=0x7df840, rr_params=0x2b1f933f5ad0) at rr_cb.c:89
#3  0x00002b1f931ed212 in after_loose (_m=0x7df840, preloaded=0) at loose.c:874
#4  0x00002b1f931f0088 in loose_route (_m=0x7df840, _s1=<value optimized out>, _s2=<value optimized out>) at loose.c:910
#5  0x000000000040ddfc in do_action (a=0x774f10, msg=0x7df840) at action.c:962
#6  0x000000000041089e in run_action_list (a=<value optimized out>, msg=0x7df840) at action.c:139
#7  0x000000000045ed02 in eval_expr (e=0x774fe0, msg=0x7df840, val=0x0) at route.c:1189
#8  0x000000000045e725 in eval_expr (e=0x775028, msg=0x7df840, val=0x0) at route.c:1507
#9  0x000000000040cdef in do_action (a=0x7765a8, msg=0x7df840) at action.c:689
#10 0x000000000041089e in run_action_list (a=<value optimized out>, msg=0x7df840) at action.c:139
#11 0x0000000000410bf9 in run_top_route (a=0x773c90, msg=0x7df840) at action.c:119
#12 0x000000000044f56f in receive_msg (
    buf=0x7420c0 "INVITE sip:andrey11 at 10.2.44.153:56867;rinstance=b7437acf90db9db6 SIP/2.0\r\nVia: SIP/2.0/UDP 10.2.176.223;branch=z9hG4bK97f5.58d94591.0\r\nVia: SIP/2.0/UDP 10.2.44.153:27905;received=10.2.44.153;branch=z9"..., len=1011, rcv_info=0x7fff1814e300) at receive.c:164
#13 0x000000000048f05e in udp_rcv_loop () at udp_server.c:449
#14 0x00000000004279be in main (argc=5, argv=0x7fff1814e508) at main.c:692


#0  restore_from (msg=0x7df840, is_from=0x7fff1814c31c) at from.c:423
#1  0x00002b1f969d9279 in rr_checker (msg=0x7df840, r_param=<value optimized out>, cb_param=0x0) at from.c:543
#2  0x00002b1f931f2f15 in run_rr_callbacks (req=0x7df840, rr_params=0x2b1f933f5ad0) at rr_cb.c:89
#3  0x00002b1f931ed212 in after_loose (_m=0x7df840, preloaded=0) at loose.c:874
#4  0x00002b1f931f0088 in loose_route (_m=0x7df840, _s1=<value optimized out>, _s2=<value optimized out>) at loose.c:910
#5  0x000000000040ddfc in do_action (a=0x790e98, msg=0x7df840) at action.c:962
#6  0x000000000041089e in run_action_list (a=<value optimized out>, msg=0x7df840) at action.c:139
#7  0x000000000045ed02 in eval_expr (e=0x790f68, msg=0x7df840, val=0x0) at route.c:1189
#8  0x000000000045e797 in eval_expr (e=0x791158, msg=0x7df840, val=0x0) at route.c:1490
#9  0x000000000045e797 in eval_expr (e=0x7913d8, msg=0x7df840, val=0x0) at route.c:1490
#10 0x000000000045e725 in eval_expr (e=0x791420, msg=0x7df840, val=0x0) at route.c:1507
#11 0x000000000040cdef in do_action (a=0x796380, msg=0x7df840) at action.c:689
#12 0x000000000041089e in run_action_list (a=<value optimized out>, msg=0x7df840) at action.c:139
#13 0x000000000040ec40 in do_action (a=0x796450, msg=0x7df840) at action.c:706
#14 0x000000000041089e in run_action_list (a=<value optimized out>, msg=0x7df840) at action.c:139
#15 0x000000000040ebac in do_action (a=0x7764d8, msg=0x7df840) at action.c:119
#16 0x000000000041089e in run_action_list (a=<value optimized out>, msg=0x7df840) at action.c:139
#17 0x000000000040ec40 in do_action (a=0x7765a8, msg=0x7df840) at action.c:706
#18 0x000000000041089e in run_action_list (a=<value optimized out>, msg=0x7df840) at action.c:139
#19 0x0000000000410bf9 in run_top_route (a=0x773c90, msg=0x7df840) at action.c:119
#20 0x000000000044f56f in receive_msg (
    buf=0x7420c0 "INVITE sip:andrey11 at 10.2.44.153:56867;rinstance=b7437acf90db9db6 SIP/2.0\r\nVia: SIP/2.0/UDP 10.2.176.223;branch=z9hG4bK97f5.58d94591.0\r\nVia: SIP/2.0/UDP 10.2.44.153:27905;received=10.2.44.153;branch=z9"..., len=1011, rcv_info=0x7fff1814e300) at receive.c:164
#21 0x000000000048f05e in udp_rcv_loop () at udp_server.c:449
#22 0x00000000004279be in main (argc=5, argv=0x7fff1814e508) at main.c:692

I have a question:
1. How I can understand why?
2. Is it wrong configuration file or bug in source code?

----------------------------------------------------------------------

>Comment By: Bogdan-Andrei Iancu (bogdan_iancu)
Date: 2009-11-30 11:04

Message:
Hi Vladimir,

First of all,  you should call the restore function twice!!! this is the
why you get the broken FROM. If you fix this (calling restore function only
once) and you still get a broken INVITE, please post both the incoming and
outgoing re-INVITE.

Regards,
Bogdan

----------------------------------------------------------------------

Comment By: Vladimir Kuznetsov (kuznetsov82)
Date: 2009-11-27 14:50

Message:
This situation reproduces when we have two loose_route() calls in SIP
configuration. I think it is bug, because I can corrupt data just with
using config.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=2904933&group_id=232389


From noreply at sourceforge.net  Mon Nov 30 10:32:19 2009
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 30 Nov 2009 09:32:19 +0000
Subject: [OpenSIPS-Devel] [ opensips-Bugs-2903579 ] mysql_stmt_bind_param
	bind failed: Using unsupported buffer
Message-ID: <E1NF2cF-0005Gc-L9@b55xhf1.ch3.sourceforge.com>

Bugs item #2903579, was opened at 2009-11-25 08:34
Message generated for change (Comment added) made by bogdan_iancu
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=2903579&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: Accepted
Priority: 5
Private: No
Submitted By: Alexander Gong (bestiring)
>Assigned to: Bogdan-Andrei Iancu (bogdan_iancu)
Summary: mysql_stmt_bind_param bind failed: Using unsupported buffer 

Initial Comment:
Environment:  Red Hat E4U5, 
Packages:  
    opensips-1.6.0-tls_src.tar.gz,   get from trunk 
Mysql:  
     mysql-4.1.22-2.el4.i386.rpm  mysql-devel-4.1.22-2.el4.i386.rpm  mysql-server-4.1.22-2.el4.i386.rpm 

Error info in Log:
 Nov 25 12:21:43 localhost /usr/local/sbin/opensips[25063]: ERROR:db_mysql:db_mysql_do_prepared_query: mysql_stmt_bind_param() failed: Using unsupported buffer type: 0  (parameter: 10) 
Nov 25 12:21:43 localhost /usr/local/sbin/opensips[25063]: ERROR:db_mysql:db_mysql_do_prepared_query: param 0 was found as type 254 
Nov 25 12:21:43 localhost /usr/local/sbin/opensips[25063]: ERROR:db_mysql:db_mysql_do_prepared_query: param 1 was found as type 254 
Nov 25 12:21:43 localhost /usr/local/sbin/opensips[25063]: ERROR:db_mysql:db_mysql_do_prepared_query: param 2 was found as type 12 
Nov 25 12:21:43 localhost /usr/local/sbin/opensips[25063]: ERROR:db_mysql:db_mysql_do_prepared_query: param 3 was found as type 5 
Nov 25 12:21:43 localhost /usr/local/sbin/opensips[25063]: ERROR:db_mysql:db_mysql_do_prepared_query: param 4 was found as type 254 
Nov 25 12:21:43 localhost /usr/local/sbin/opensips[25063]: ERROR:db_mysql:db_mysql_do_prepared_query: param 5 was found as type 3 
Nov 25 12:21:43 localhost /usr/local/sbin/opensips[25063]: ERROR:db_mysql:db_mysql_do_prepared_query: param 6 was found as type 3 
Nov 25 12:21:43 localhost /usr/local/sbin/opensips[25063]: ERROR:db_mysql:db_mysql_do_prepared_query: param 7 was found as type 3 
Nov 25 12:21:43 localhost /usr/local/sbin/opensips[25063]: ERROR:db_mysql:db_mysql_do_prepared_query: param 8 was found as type 254 
Nov 25 12:21:43 localhost /usr/local/sbin/opensips[25063]: ERROR:db_mysql:db_mysql_do_prepared_query: param 9 was found as type 0 
Nov 25 12:21:43 localhost /usr/local/sbin/opensips[25063]: ERROR:db_mysql:db_mysql_do_prepared_query: param 10 was found as type 0 
Nov 25 12:21:43 localhost /usr/local/sbin/opensips[25063]: ERROR:db_mysql:db_mysql_do_prepared_query: param 11 was found as type 254 
Nov 25 12:21:43 localhost /usr/local/sbin/opensips[25063]: ERROR:db_mysql:db_mysql_do_prepared_query: param 12 was found as type 3 
Nov 25 12:21:43 localhost /usr/local/sbin/opensips[25063]: ERROR:db_mysql:db_mysql_do_prepared_query: param 13 was found as type 12 
Nov 25 12:21:43 localhost /usr/local/sbin/opensips[25063]: ERROR:usrloc:db_insert_ucontact: inserting contact in db failed 
Nov 25 12:21:43 localhost /usr/local/sbin/opensips[25063]: ERROR:usrloc:wb_timer: inserting contact into database failed 

************************************************************************
i compared the source code of db_mysql in packages with SVN current branch or trunk
there are no code changes, ex : 
dbase.c  , etc. 

Could you help me do the check? what's the problem
thanks 
 

----------------------------------------------------------------------

>Comment By: Bogdan-Andrei Iancu (bogdan_iancu)
Date: 2009-11-30 11:32

Message:
Hi Alexander,

It is a bit strange, but to be 100% I found the source of the error, could
you apply the attached patch and make on more run -> post the ERROR logs
again.
I said it is strange as the columns 9 and 10 (mysql complains about) have
NULL values and no type set...It looks some drivers do not like it...so I
want first to check if they are indeed null (with the patch).
If my guessing is right, I will generate a fix asap.

Thanks and regards,
Bogdan

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=2903579&group_id=232389


From bogdan at voice-system.ro  Mon Nov 30 10:47:43 2009
From: bogdan at voice-system.ro (Bogdan-Andrei Iancu)
Date: Mon, 30 Nov 2009 09:47:43 +0000
Subject: [OpenSIPS-Devel] SF.net SVN: opensips:[6364]
	branches/1.6/modules/pua
Message-ID: <E1NF2r8-00049R-V4@74yxhf1.ch3.sourceforge.com>

Revision: 6364
          http://opensips.svn.sourceforge.net/opensips/?rev=6364&view=rev
Author:   bogdan_iancu
Date:     2009-11-30 09:47:42 +0000 (Mon, 30 Nov 2009)

Log Message:
-----------
backport from trunk (rev #6359):
- added check if NULL value returned by get_event function

Revision Links:
--------------
    http://opensips.svn.sourceforge.net/opensips/?rev=6359&view=rev

Modified Paths:
--------------
    branches/1.6/modules/pua/event_list.c
    branches/1.6/modules/pua/pua.c


This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site.


From bogdan at voice-system.ro  Mon Nov 30 10:47:44 2009
From: bogdan at voice-system.ro (Bogdan-Andrei Iancu)
Date: Mon, 30 Nov 2009 09:47:44 +0000
Subject: [OpenSIPS-Devel] SF.net SVN: opensips:[6365]
	branches/1.5/modules/pua
Message-ID: <E1NF2rA-00049d-7K@74yxhf1.ch3.sourceforge.com>

Revision: 6365
          http://opensips.svn.sourceforge.net/opensips/?rev=6365&view=rev
Author:   bogdan_iancu
Date:     2009-11-30 09:47:44 +0000 (Mon, 30 Nov 2009)

Log Message:
-----------
backport from trunk (rev #6359):
- added check if NULL value returned by get_event function

Revision Links:
--------------
    http://opensips.svn.sourceforge.net/opensips/?rev=6359&view=rev

Modified Paths:
--------------
    branches/1.5/modules/pua/event_list.c
    branches/1.5/modules/pua/pua.c


This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site.


From noreply at sourceforge.net  Mon Nov 30 10:48:06 2009
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 30 Nov 2009 09:48:06 +0000
Subject: [OpenSIPS-Devel] [ opensips-Bugs-2903244 ] Segfault when using
	pua_dialoginfo
Message-ID: <E1NF2rW-0003TB-J1@g45xhf1.ch3.sourceforge.com>

Bugs item #2903244, was opened at 2009-11-24 19:27
Message generated for change (Comment added) made by bogdan_iancu
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=2903244&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.6.x
>Status: Closed
>Resolution: Fixed
Priority: 5
Private: No
Submitted By: takeshi (mayamatakeshi)
>Assigned to: Anca Vamanu (anca_vamanu)
Summary: Segfault when using pua_dialoginfo

Initial Comment:
I'm testing with presence and pua dialoginfo modules. It is segfaulting frequently.
I got this in the log file:
Nov 25 00:57:27 lab kernel: opensips[10924]: segfault at 0000000000000008 rip 00002b2fe86c65f9 rsp 00007fffc3b581e0 error 4

And here's a backtrace:

Program terminated with signal 11, Segmentation fault.
[New process 10924]
#0  0x00002b2fe86c65f9 in publ_build_hdr (expires=3600, ev=0x0, content_type=0x0, etag=0x2b2fe940c248, extra_headers=0x2b2fe940c335,
    is_body=0) at send_publish.c:80
80              memcpy(str_hdr->s+ str_hdr->len, ev->name.s, ev->name.len);
(gdb) bt full
#0  0x00002b2fe86c65f9 in publ_build_hdr (expires=3600, ev=0x0, content_type=0x0, etag=0x2b2fe940c248, extra_headers=0x2b2fe940c335,
    is_body=0) at send_publish.c:80
        str_hdr = (str *) 0x785ff0
        len = <value optimized out>
        t = <value optimized out>
        buf = "Max-Forwards: 70\r\nEvent: ", '\0' <repeats 2974 times>
        __FUNCTION__ = "publ_build_hdr"
#1  0x00002b2fe86c24d1 in update_pua (p=0x2b2fe940c1f8, hash_code=<value optimized out>) at pua.c:670
        met = {s = 0x2b2fe86d4ab1 "PUBLISH", len = 7}
        str_hdr = <value optimized out>
        expires = 3600
        result = <value optimized out>
        __FUNCTION__ = "update_pua"
#2  0x00002b2fe86c2f74 in hashT_clean (ticks=<value optimized out>, param=<value optimized out>) at pua.c:625
        i = <value optimized out>
        now = 1259078247
        p = (ua_pres_t *) 0x2b2fe940c1f8
        __FUNCTION__ = "hashT_clean"
#3  0x000000000048bf63 in start_timer_processes () at timer.c:325
        tpl = (struct sr_timer_process *) 0x784b20
        pid = <value optimized out>
        __FUNCTION__ = "start_timer_processes"
#4  0x00000000004297e1 in main (argc=3, argv=0x4) at main.c:867
        cfg_log_stderr = <value optimized out>
        cfg_stream = (FILE *) 0x1a715010
        c = <value optimized out>
        r = <value optimized out>
        tmp = 0x4f7d67 "H\215\005\222?#"
        tmp_len = <value optimized out>
        port = <value optimized out>
        proto = <value optimized out>
        ret = <value optimized out>
        seed = 2113776588
        rfd = <value optimized out>
        __FUNCTION__ = "main"

I'm using opensips 1.6. Revision: 6358.

For my tests, I just adapted the sample from here:
http://opensips.org/index.php?n=Resources.PuaDialoinfoConfig
(I'm attaching my cfg, just in case)



----------------------------------------------------------------------

>Comment By: Bogdan-Andrei Iancu (bogdan_iancu)
Date: 2009-11-30 11:48

Message:
the fix was backported from trunk to 1.5 and 1.6 releases.

----------------------------------------------------------------------

Comment By: Anca Vamanu (anca_vamanu)
Date: 2009-11-25 14:46

Message:
Hi,

I have made a fix now for that crash. Please update.

Regards,
Anca

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=2903244&group_id=232389


From noreply at sourceforge.net  Mon Nov 30 10:53:22 2009
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 30 Nov 2009 09:53:22 +0000
Subject: [OpenSIPS-Devel] [ opensips-Bugs-2897651 ] config.h parameters not
	reflecting
Message-ID: <E1NF2wc-0005AZ-NW@d55xhf1.ch3.sourceforge.com>

Bugs item #2897651, was opened at 2009-11-14 14:08
Message generated for change (Comment added) made by bogdan_iancu
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=2897651&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: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Himal Rana (ranahimal)
Assigned to: Bogdan-Andrei Iancu (bogdan_iancu)
Summary: config.h parameters not reflecting

Initial Comment:
Setting parameters in config.h parameters does not reflected in complied  binary.

Version  tested : 1.5.X  , 1.6.0

OS : RHEL 5.4 Fedora  11 Centos 5.4

----------------------------------------------------------------------

>Comment By: Bogdan-Andrei Iancu (bogdan_iancu)
Date: 2009-11-30 11:53

Message:
So, you changed the PKG_MEM_POOL_SIZE & SHM_MEM_SIZE in config.h and
recompiled (make all) opensips ....how do you check after that to see if
the new values do reflect ?

Regards,
Bogdan

----------------------------------------------------------------------

Comment By: Himal Rana (ranahimal)
Date: 2009-11-16 20:16

Message:
Dear Bogdan,

I was complie using following shell command.

make all



----------------------------------------------------------------------

Comment By: Himal Rana (ranahimal)
Date: 2009-11-16 20:14

Message:
Dear Bogdan,
I was trying to set following parameters:

PKG_MEM_POOL_SIZE
SHM_MEM_SIZE

Thanks,
Himal 

----------------------------------------------------------------------

Comment By: Bogdan-Andrei Iancu (bogdan_iancu)
Date: 2009-11-16 10:38

Message:
Hi Himal,
what parameters you tried to change and did not work? How you tested that
the param actually did not work?

Regards,
Bogdan

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=2897651&group_id=232389


From noreply at sourceforge.net  Mon Nov 30 11:04:12 2009
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 30 Nov 2009 10:04:12 +0000
Subject: [OpenSIPS-Devel] [ opensips-Bugs-2901758 ] b2bua doesn't pass SIP
	INFO messages.
Message-ID: <E1NF376-0005vd-8U@d55xhf1.ch3.sourceforge.com>

Bugs item #2901758, was opened at 2009-11-21 16:08
Message generated for change (Settings changed) made by bogdan_iancu
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=2901758&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: Sergey Okhapkin (sokhapkin)
>Assigned to: Anca Vamanu (anca_vamanu)
Summary: b2bua doesn't pass SIP INFO messages.

Initial Comment:
SIP INFO message received yelds to log ERROR:b2b_logic:b2b_logic_notify: Method not supported.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=2901758&group_id=232389


From noreply at sourceforge.net  Mon Nov 30 11:12:54 2009
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 30 Nov 2009 10:12:54 +0000
Subject: [OpenSIPS-Devel] [ opensips-Bugs-2893969 ] SST not setting the
	avp_timeout
Message-ID: <E1NF3FW-0006Uq-E1@d55xhf1.ch3.sourceforge.com>

Bugs item #2893969, was opened at 2009-11-08 01:07
Message generated for change (Comment added) made by bogdan_iancu
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=2893969&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.6.x
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Flavio Goncalves (flaviogoncalves)
>Assigned to: Bogdan-Andrei Iancu (bogdan_iancu)
Summary: SST not setting the avp_timeout

Initial Comment:
I'm trying to use the SST module, but the system never set the timeout to the value of the Session-Expires Header.  There is no error being shown,  even with debug=9. Using opensipsctl fifo dlg_list, the value of the parameter timeout is always in the default value. All flags were set and the timeout_avp(i:4042) is set to both modules SST and DIALOG. The dialog is matching ok. I have checked everything I could. If I drop the network cable, the dialog stays active for the default timeout 43200. It never assumes the value of the Session-Expires. I tried setting the value in the uac, uas and in the proxy itself. 

----------------------------------------------------------------------

>Comment By: Bogdan-Andrei Iancu (bogdan_iancu)
Date: 2009-11-30 12:12

Message:
Hi Flavio,

At INVITE time, do you see something like:
   invalid AVP value, use default timeout

Regards,
Bogdan

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=2893969&group_id=232389


From bogdan at voice-system.ro  Mon Nov 30 11:15:38 2009
From: bogdan at voice-system.ro (Bogdan-Andrei Iancu)
Date: Mon, 30 Nov 2009 12:15:38 +0200
Subject: [OpenSIPS-Devel] Regarding the CANCEL request
In-Reply-To: <f3085a9c0911280541o238fe5ck81f9c910eb7db3c7@mail.gmail.com>
References: <f3085a9c0911262106r2eeec806s2c5da7313e9e39e1@mail.gmail.com>
	<f3085a9c0911280541o238fe5ck81f9c910eb7db3c7@mail.gmail.com>
Message-ID: <4B139B4A.2030408@voice-system.ro>

Hi Steven,

Is the caller device doing retransmission for the INVITE (which has the 
credentials) ?

Regards,
Bogdan

doolin wu wrote:
>
>      
>     I'm facing a CANCEL problem now. The problem can be described as
>     "UAC canceled the INVITE but UAS still state ringing status"
>     The UAS is a desk phone connected to VoIP network by a VoIP
>     gatway, the SIP server is OpenSIPS 1.5.
>      
>     Based on the SIP singaling at UAC side, there scenarios to cause
>     the problem:
>     *1. Cancel before 407 Proxy Authentication Required*
>     INVITE ->
>     100 ->
>     CANCEL->
>     200 for CANCEL ( from proxy server)<-
>     407 for INVITE <-
>     ACK ->
>     INVITE (with authorization) ->
>     180 <-
>      
>     In this case, the INVITE with authorization caused the UAS rining.
>     My question is shall UAC send INVITE after receive 407 if the
>     first INVITE is canceling?
>     ...
>     *2. Cancel after 407 Proxy Authentication Required.*
>     INVITE ->
>     100 ->
>     407 <-
>     CANCEL->
>     400 for CANCEL <-
>     ACK ->
>     INVITE (with authorization) ->
>     180 <-
>     The reason caused UAS rining is same with case 1.
>     How to handle this scenario?
>     The cancel was treated as bad request due to the INVITE has
>     generate final response 407.
>     Shall UAC send CANCEL again when receive 180?
>     -- 
>     Best Regards,
>     Steven Wu
>
>
>
>
> -- 
> Steven Wu
> Teleca Mobile Solution
> ------------------------------------------------------------------------
>
> _______________________________________________
> Devel mailing list
> Devel at lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
>   


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



From noreply at sourceforge.net  Mon Nov 30 22:05:18 2009
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 30 Nov 2009 21:05:18 +0000
Subject: [OpenSIPS-Devel] [ opensips-Bugs-2903829 ] mmegeoip module loading
	problem
Message-ID: <E1NFDQs-0004VT-N2@565xhf1.ch3.sourceforge.com>

Bugs item #2903829, was opened at 2009-11-25 08:20
Message generated for change (Comment added) made by ekobi
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=2903829&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.6.x
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Kobi Eshun (ekobi)
Summary: mmegeoip module loading problem

Initial Comment:
opensips -c -f /etc/opensips/opensips.cfg
Nov 25 11:09:26 [10240] ERROR:core:sr_load_module: could not open module <//lib/opensips/modules/mmgeoip.so>: //lib/opensips/modules/mmgeoip.so: undefined symbol: GeoIP_time_zone_by_country_and_region
Nov 25 11:09:26 [10240] CRITICAL:core:yyerror: parse error in config file, line 68, column 13-14: failed to load module
Nov 25 11:09:26 [10240] ERROR:core:set_mod_param_regex: no module matching mmgeoip found
Nov 25 11:09:26 [10240] CRITICAL:core:yyerror: parse error in config file, line 272, column 19-20: Parameter <mmgeoip_city_db_path> not found in module <mmgeoip> - can't set
Nov 25 11:09:26 [10240] CRITICAL:core:yyerror: parse error in config file, line 295, column 32-49: syntax error
Nov 25 11:09:26 [10240] CRITICAL:core:yyerror: parse error in config file, line 295, column 49-50: bad arguments for command <mmg_lookup>
Nov 25 11:09:26 [10240] ERROR:core:main: bad config file (4 errors)



loadmodule "mmgeoip.so"

modparam("mmgeoip", "mmgeoip_city_db_path","/usr/share/GeoIP/GeoLiteCity.dat")

----------------------------------------------------------------------

>Comment By: Kobi Eshun (ekobi)
Date: 2009-11-30 13:05

Message:
This patch should fix the problem. Please confirm it works for you, and
I'll commit. Cheers,
--
kobi

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=2903829&group_id=232389


