From noreply at sourceforge.net  Sat May  2 21:24:25 2009
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat, 02 May 2009 19:24:25 +0000
Subject: [OpenSIPS-Devel] [ opensips-Patches-2785741 ] fix: cpl - branch
	flags not set/reset correctly
Message-ID: <E1M0Koz-0000m9-SJ@g45xhf1.ch3.sourceforge.com>

Patches item #2785741, was opened at 2009-05-02 15:24
Message generated for change (Tracker Item Submitted) made by john_riordan
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086412&aid=2785741&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: John Riordan (john_riordan)
Assigned to: Nobody/Anonymous (nobody)
Summary: fix: cpl - branch flags not set/reset correctly

Initial Comment:
The branch flag of branch zero is not getting set/reset correctly when 
cpl is sequentially processing a location set - the value from the previously 
processed location is not getting cleared and the next location processed is
ending up with whatever flags were set by the previous branch.


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

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


From marc.leurent at vtx-telecom.ch  Mon May  4 14:07:54 2009
From: marc.leurent at vtx-telecom.ch (Marc Leurent)
Date: Mon, 4 May 2009 14:07:54 +0200
Subject: [OpenSIPS-Devel] strange behaviour of SNMPstats and usrloc with and
	without mysql backend
Message-ID: <200905041407.55192.marc.leurent@vtx-telecom.ch>

Hello all, I have noticed something strange about snmpstats and usrloc...
Have you got any explanation for me?
Thanks!

When I set the usrloc | db_mode parameter to 0 or 1 (0 - This disables database completely. 1 - Write-Through scheme.)
I can get Contact data through the snmpstats module!
snmpwalk -c public -v 2c 127.0.0.1 .1.3.6.1.4.1.27483
...
OPENSER-SIP-SERVER-MIB::openserSIPContactDisplayName.2.1 = STRING: sip:02131150 at 14.38.160.13:5070
OPENSER-SIP-SERVER-MIB::openserSIPContactURI.1.1 = STRING: DefaultUser
OPENSER-SIP-SERVER-MIB::openserSIPContactURI.2.1 = STRING: sip:02131150 at 14.38.160.13:5070
...


but when I set  usrloc | db_mode parameter to 2 (2 - Write-Back scheme) I don't get anything from the snmpstats module
snmpwalk -c public -v 2c 127.0.0.1 .1.3.6.1.4.1.27483
OPENSER-SIP-SERVER-MIB::openserSIPContactDisplayName.1.1 = STRING: DefaultUser
OPENSER-SIP-SERVER-MIB::openserSIPContactURI.1.1 = STRING: DefaultUser
...

Have a nice day!
++


the part of my opensips.cfg file about usrloc params

# ----- usrloc params -----
/* modparam("usrloc", "db_mode",   X)
   for location entries
        0 - This disables database completely.
        1 - Write-Through scheme. All changes to usrloc are immediately reflected in database too.
        2 - Write-Back scheme. This is a combination of previous two schemes. All changes are made to memory and database synchronization is done in the timer.
        3 - DB-Only scheme. No memory cache is kept, all operations being directly performed with the database.
*/
modparam("usrloc", "db_mode", 1)
modparam("usrloc", "db_url", "mysql://opensips:UqwdwfuJ at localhost/opensips")
modparam("usrloc", "nat_bflag", 6)              # The index of the branch flag to be used as NAT marker (if the contact is or not natted).
modparam("usrloc", "use_domain", 0)             # If the domain part of the user should be also saved and used for identifing the user
modparam("usrloc", "desc_time_order", 0)        # If the user's contacts should be kept timestamp ordered; otherwise the contact will be ordered based on q value.
modparam("usrloc", "timer_interval", 30)        # The module uses timer to delete expired contacts, synchronize with database and other tasks, that need to be run periodically.
modparam("usrloc", "matching_mode", 0)          # What contact matching algorithm to be used. 0 - CONTACT ONLY based matching algorithm
modparam("usrloc", "cseq_delay", 20)            # Delay (in seconds) for accepting as retransmissions register requests with same Call-ID and Cseq.
modparam("usrloc", "fetch_rows", 2000)          # number of the rows to be fetched at once from database when loading the location records.
modparam("usrloc", "hash_size", 9)              # Number of entries of the hash table used by usrloc to store the location records is 2^hash_size.





-- --
Marc LEURENT
Ing?nieur VoIP

DECKPOINT SA
Une soci?t? du groupe VTX Telecom
================================================================
Rue Eug?ne-Marziano 15 - 1227 Les Acacias
http://www.vtx.ch - marc.leurent at vtx-telecom.ch
----------------------------------------------------------------
VTX, votre partenaire telecom proche de vous !
================================================================


From bogdan at voice-system.ro  Mon May  4 16:15:29 2009
From: bogdan at voice-system.ro (Bogdan-Andrei Iancu)
Date: Mon, 04 May 2009 14:15:29 +0000
Subject: [OpenSIPS-Devel] SF.net SVN: opensips:[5658]
	trunk/modules/cpl-c/cpl_sig.c
Message-ID: <E1M0yx6-0003Oo-W9@bj8yhf1.ch3.sourceforge.com>

Revision: 5658
          http://opensips.svn.sourceforge.net/opensips/?rev=5658&view=rev
Author:   bogdan_iancu
Date:     2009-05-04 14:15:28 +0000 (Mon, 04 May 2009)

Log Message:
-----------
- fixed reseting the branch flag for NAT detection is the branch has no NAT is detected
  Credits go to John Riordan
  Closes bug report #2785741.

Modified Paths:
--------------
    trunk/modules/cpl-c/cpl_sig.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 May  4 16:24:25 2009
From: bogdan at voice-system.ro (Bogdan-Andrei Iancu)
Date: Mon, 04 May 2009 14:24:25 +0000
Subject: [OpenSIPS-Devel] SF.net SVN: opensips:[5659]
	branches/1.5/modules/cpl-c/cpl_sig.c
Message-ID: <E1M0z5l-0003an-7d@bj8yhf1.ch3.sourceforge.com>

Revision: 5659
          http://opensips.svn.sourceforge.net/opensips/?rev=5659&view=rev
Author:   bogdan_iancu
Date:     2009-05-04 14:24:25 +0000 (Mon, 04 May 2009)

Log Message:
-----------
backport from trunk (rev #5658):
- fixed NAT flag setting
  Closes bug #2785741

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

Modified Paths:
--------------
    branches/1.5/modules/cpl-c/cpl_sig.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 May  4 16:27:00 2009
From: bogdan at voice-system.ro (Bogdan-Andrei Iancu)
Date: Mon, 04 May 2009 14:27:00 +0000
Subject: [OpenSIPS-Devel] SF.net SVN: opensips:[5660]
	branches/1.4/modules/cpl-c/cpl_sig.c
Message-ID: <E1M0z8G-0003eY-90@bj8yhf1.ch3.sourceforge.com>

Revision: 5660
          http://opensips.svn.sourceforge.net/opensips/?rev=5660&view=rev
Author:   bogdan_iancu
Date:     2009-05-04 14:27:00 +0000 (Mon, 04 May 2009)

Log Message:
-----------
backport from trunk (rev #5658):
- fixed NAT flag setting
  Closes bug #278574

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

Modified Paths:
--------------
    branches/1.4/modules/cpl-c/cpl_sig.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 May  4 16:28:42 2009
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 04 May 2009 14:28:42 +0000
Subject: [OpenSIPS-Devel] [ opensips-Patches-2785741 ] fix: cpl - branch
	flags not set/reset correctly
Message-ID: <E1M0z9u-0003Rh-8a@cdv4jf1.ch3.sourceforge.com>

Patches item #2785741, was opened at 2009-05-02 22:24
Message generated for change (Comment added) made by bogdan_iancu
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086412&aid=2785741&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: Accepted
Priority: 5
Private: No
Submitted By: John Riordan (john_riordan)
>Assigned to: Bogdan-Andrei Iancu (bogdan_iancu)
Summary: fix: cpl - branch flags not set/reset correctly

Initial Comment:
The branch flag of branch zero is not getting set/reset correctly when 
cpl is sequentially processing a location set - the value from the previously 
processed location is not getting cleared and the next location processed is
ending up with whatever flags were set by the previous branch.


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

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

Message:
Hi John,

Thanks for the patch - it is on SVN on trunk, 1.5  and 1.4 branches.

Thanks and regards,
Bogdan

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

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


From noreply at sourceforge.net  Mon May  4 16:29:28 2009
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 04 May 2009 14:29:28 +0000
Subject: [OpenSIPS-Devel] [ opensips-Patches-2785741 ] fix: cpl - branch
	flags not set/reset correctly
Message-ID: <E1M0zAe-000819-Kn@d55xhf1.ch3.sourceforge.com>

Patches item #2785741, was opened at 2009-05-02 22:24
Message generated for change (Settings changed) made by bogdan_iancu
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086412&aid=2785741&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: Closed
Resolution: Accepted
Priority: 5
Private: No
Submitted By: John Riordan (john_riordan)
Assigned to: Bogdan-Andrei Iancu (bogdan_iancu)
Summary: fix: cpl - branch flags not set/reset correctly

Initial Comment:
The branch flag of branch zero is not getting set/reset correctly when 
cpl is sequentially processing a location set - the value from the previously 
processed location is not getting cleared and the next location processed is
ending up with whatever flags were set by the previous branch.


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

Comment By: Bogdan-Andrei Iancu (bogdan_iancu)
Date: 2009-05-04 17:28

Message:
Hi John,

Thanks for the patch - it is on SVN on trunk, 1.5  and 1.4 branches.

Thanks and regards,
Bogdan

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

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


From bogdan at voice-system.ro  Mon May  4 18:23:52 2009
From: bogdan at voice-system.ro (Bogdan-Andrei Iancu)
Date: Mon, 04 May 2009 19:23:52 +0300
Subject: [OpenSIPS-Devel] [OpenSIPS-Users] strange behaviour of
 SNMPstats and usrloc with and	without mysql backend
In-Reply-To: <200905041407.55192.marc.leurent@vtx-telecom.ch>
References: <200905041407.55192.marc.leurent@vtx-telecom.ch>
Message-ID: <49FF1698.2030403@voice-system.ro>

Hi Marc,

what opensips version are you using?

also, for db_mode 2, when pushing the snmp query, do you get any errors 
in opensips?

Regards,
Bogdan

Marc Leurent wrote:
> Hello all, I have noticed something strange about snmpstats and usrloc...
> Have you got any explanation for me?
> Thanks!
>
> When I set the usrloc | db_mode parameter to 0 or 1 (0 - This disables database completely. 1 - Write-Through scheme.)
> I can get Contact data through the snmpstats module!
> snmpwalk -c public -v 2c 127.0.0.1 .1.3.6.1.4.1.27483
> ...
> OPENSER-SIP-SERVER-MIB::openserSIPContactDisplayName.2.1 = STRING: sip:02131150 at 14.38.160.13:5070
> OPENSER-SIP-SERVER-MIB::openserSIPContactURI.1.1 = STRING: DefaultUser
> OPENSER-SIP-SERVER-MIB::openserSIPContactURI.2.1 = STRING: sip:02131150 at 14.38.160.13:5070
> ...
>
>
> but when I set  usrloc | db_mode parameter to 2 (2 - Write-Back scheme) I don't get anything from the snmpstats module
> snmpwalk -c public -v 2c 127.0.0.1 .1.3.6.1.4.1.27483
> OPENSER-SIP-SERVER-MIB::openserSIPContactDisplayName.1.1 = STRING: DefaultUser
> OPENSER-SIP-SERVER-MIB::openserSIPContactURI.1.1 = STRING: DefaultUser
> ...
>
> Have a nice day!
> ++
>
>
> the part of my opensips.cfg file about usrloc params
>
> # ----- usrloc params -----
> /* modparam("usrloc", "db_mode",   X)
>    for location entries
>         0 - This disables database completely.
>         1 - Write-Through scheme. All changes to usrloc are immediately reflected in database too.
>         2 - Write-Back scheme. This is a combination of previous two schemes. All changes are made to memory and database synchronization is done in the timer.
>         3 - DB-Only scheme. No memory cache is kept, all operations being directly performed with the database.
> */
> modparam("usrloc", "db_mode", 1)
> modparam("usrloc", "db_url", "mysql://opensips:UqwdwfuJ at localhost/opensips")
> modparam("usrloc", "nat_bflag", 6)              # The index of the branch flag to be used as NAT marker (if the contact is or not natted).
> modparam("usrloc", "use_domain", 0)             # If the domain part of the user should be also saved and used for identifing the user
> modparam("usrloc", "desc_time_order", 0)        # If the user's contacts should be kept timestamp ordered; otherwise the contact will be ordered based on q value.
> modparam("usrloc", "timer_interval", 30)        # The module uses timer to delete expired contacts, synchronize with database and other tasks, that need to be run periodically.
> modparam("usrloc", "matching_mode", 0)          # What contact matching algorithm to be used. 0 - CONTACT ONLY based matching algorithm
> modparam("usrloc", "cseq_delay", 20)            # Delay (in seconds) for accepting as retransmissions register requests with same Call-ID and Cseq.
> modparam("usrloc", "fetch_rows", 2000)          # number of the rows to be fetched at once from database when loading the location records.
> modparam("usrloc", "hash_size", 9)              # Number of entries of the hash table used by usrloc to store the location records is 2^hash_size.
>
>
>
>
>
> -- --
> Marc LEURENT
> Ing?nieur VoIP
>
> DECKPOINT SA
> Une soci?t? du groupe VTX Telecom
> ================================================================
> Rue Eug?ne-Marziano 15 - 1227 Les Acacias
> http://www.vtx.ch - marc.leurent at vtx-telecom.ch
> ----------------------------------------------------------------
> VTX, votre partenaire telecom proche de vous !
> ================================================================
>
> _______________________________________________
> Users mailing list
> Users at lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>
>   



From noreply at sourceforge.net  Mon May  4 19:06:16 2009
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 04 May 2009 17:06:16 +0000
Subject: [OpenSIPS-Devel] [ opensips-Bugs-2786735 ] drouting do not accept
	null prefixes
Message-ID: <E1M11cO-000746-Un@d45xhf1.ch3.sourceforge.com>

Bugs item #2786735, was opened at 2009-05-04 17:06
Message generated for change (Tracker Item Submitted) made by nobody
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=2786735&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: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: drouting do not accept null prefixes

Initial Comment:
drouting module doesn't accept null prefixes in dr_rules table but there isn't "blank" strings in oracle. So, I'm not able to use drouting with oracle.

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

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


From noreply at sourceforge.net  Mon May  4 21:34:10 2009
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 04 May 2009 19:34:10 +0000
Subject: [OpenSIPS-Devel] [ opensips-Patches-2786818 ] fix: cpl - priority
	not set correctly when Q_UNSPECIFIED
Message-ID: <E1M13vW-0006lw-Dx@b55xhf1.ch3.sourceforge.com>

Patches item #2786818, was opened at 2009-05-04 15:34
Message generated for change (Tracker Item Submitted) made by john_riordan
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086412&aid=2786818&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: John Riordan (john_riordan)
Assigned to: Nobody/Anonymous (nobody)
Summary: fix: cpl - priority not set correctly when Q_UNSPECIFIED

Initial Comment:
CPL "lookup" is not checking for the possibility that a contact's q-value could be Q_UNSPECIFIED when setting a locations "priority".

The patch adds this check and sets the priority to "1.0" in accordance with RFC3880 (CPL)
...
Section 5.1
...
"The optional "priority" parameter specifies a priority for the
location.  Its value is a floating-point number between 0.0 and 1.0.
If it is not specified, the server SHOULD assume a default priority
of 1.0."
...
Section 6.1.1
...
"SIP servers SHOULD honor the "q" parameter of SIP registrations when
determining location priority."


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

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


From noreply at sourceforge.net  Mon May  4 21:40:56 2009
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 04 May 2009 19:40:56 +0000
Subject: [OpenSIPS-Devel] [ opensips-Patches-2786822 ] fix: cpl - location
	set ordering on identical priorities
Message-ID: <E1M1424-0000yS-3d@d45xhf1.ch3.sourceforge.com>

Patches item #2786822, was opened at 2009-05-04 15:40
Message generated for change (Tracker Item Submitted) made by john_riordan
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086412&aid=2786822&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: John Riordan (john_riordan)
Assigned to: Nobody/Anonymous (nobody)
Summary: fix: cpl - location set ordering on identical priorities 

Initial Comment:
When locations having the same priority are added to the CPL location set, the add order is not maintained.


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

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


From noreply at sourceforge.net  Tue May  5 10:45:08 2009
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue, 05 May 2009 08:45:08 +0000
Subject: [OpenSIPS-Devel] [ opensips-Bugs-2787094 ] Crash with db_postgresql
	and no db connection
Message-ID: <E1M1GGy-0002wP-A2@1bkjzd1.ch3.sourceforge.com>

Bugs item #2787094, was opened at 2009-05-05 08:45
Message generated for change (Tracker Item Submitted) made by nobody
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=2787094&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: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: Crash with db_postgresql and no db connection

Initial Comment:
Opensips with usrloc and db_postgresql will crash if the db server is unreachable.


Scenario is the following, I have a remote postgres DB server, and had not opened the PG port on the firewall, which causes opensips to be unable to reach the DB server.
on init, opensips times out trying to connect to the DB, and then crash, looking at the logs, it seems to be usrloc module related.

It's easy to reproduce, I can provide as many tracks as needed.

If you need me bogdan, ask on irc ( Gled ).

bt:
#0  0x0000000000425f36 in handle_sigs () at main.c:486
486                                             if (pt[i].pid==chld) break;

#0  0x0000000000425f36 in handle_sigs () at main.c:486
#1  <signal handler called>
#2  0x00000030e6ae0cb7 in munmap () from /lib64/libc.so.6
#3  0x00000000004a4804 in shm_mem_destroy () at mem/shm_mem.c:238
#4  0x00000000004259a6 in cleanup (show_status=0) at main.c:365
#5  0x0000000000428560 in main (argc=<value optimized out>, argv=0x20) at main.c:1324

bt full:
#0  0x0000000000425f36 in handle_sigs () at main.c:486
        chld = 1909
        chld_status = 0
        i = <value optimized out>
        do_exit = 0
        __FUNCTION__ = "handle_sigs"
#1  <signal handler called>
No symbol table info available.
#2  0x00000030e6ae0cb7 in munmap () from /lib64/libc.so.6
No symbol table info available.
#3  0x00000000004a4804 in shm_mem_destroy () at mem/shm_mem.c:238
        __FUNCTION__ = "shm_mem_destroy"
#4  0x00000000004259a6 in cleanup (show_status=0) at main.c:365
No locals.
#5  0x0000000000428560 in main (argc=<value optimized out>, argv=0x20) at main.c:1324
        cfg_log_stderr = 1906
        cfg_stream = (FILE *) 0x772
        c = <value optimized out>
        r = 1
        tmp = 0x4ffe65 "H\205?t\0341?\017\037@"
        tmp_len = <value optimized out>
        port = <value optimized out>
        proto = <value optimized out>
        ret = -1
        seed = 2320449269
        rfd = <value optimized out>
        __FUNCTION__ = "main"


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

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


From marc.leurent at vtx-telecom.ch  Tue May  5 11:18:26 2009
From: marc.leurent at vtx-telecom.ch (Marc Leurent)
Date: Tue, 5 May 2009 11:18:26 +0200
Subject: [OpenSIPS-Devel]
	=?iso-8859-1?q?=5BOpenSIPS-Users=5D_strange_beha?=
	=?iso-8859-1?q?viour_of_SNMPstats_and_usrloc_with_and=09without_my?=
	=?iso-8859-1?q?sql_backend?=
In-Reply-To: <49FF1698.2030403@voice-system.ro>
References: <200905041407.55192.marc.leurent@vtx-telecom.ch>
	<49FF1698.2030403@voice-system.ro>
Message-ID: <200905051118.26783.marc.leurent@vtx-telecom.ch>

Good morning Bogdan, hello everybody!
About the problem I had with the snmpstats module, I think that I understand the bug: with usrloc db_mode 1 or 2, when I restart OpenSIPs,
usrloc has kept the user data, but snmpstats not. To summurize: snmpstats won't show data about users that was registered before an OpenSIPs restart even if the user register again after!

So if I'm registered on OpenSIPs and I restart it => snmpstats won't be able to show data about my user event if I register/unregister
but if I'm not registered on OpenSIPs and I restart it and only afer I register on it => snmpstats will show data about my new user

I think you can reproduce this easily!

Secondly, yesterday during these tests, I had several OpenSIPs crash running some snmpwalk on OpenSIPs, and I was able to reproduce it!

To reproduce the crash, I was running this command to get data from OpenSIPs through SNMP and I was registering/unregistering my account in the same time!

	while echo 1; do
	snmpwalk -c public -v 2c 127.0.0.1 .1.3.6.1.4.1.27483
	done

Here is the openips log file I had: http://www.pastebin.ca/1412212
I think line 42 isn't really good => CRITICAL:core:receive_fd: EOF on 24


I'm using:
version: opensips 1.5.1-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: unknown
@(#) $Id: main.c 5469 2009-03-18 12:43:10Z bogdan_iancu $
main.c compiled on 19:03:00 Apr 30 2009 with gcc 4.1.2

Thank you for your help and time!
Have a nice day!


-- --
Marc LEURENT
Ing?nieur VoIP

DECKPOINT SA
Une soci?t? du groupe VTX Telecom
================================================================
Rue Eug?ne-Marziano 15 - 1227 Les Acacias
http://www.vtx.ch - marc.leurent at vtx-telecom.ch
----------------------------------------------------------------
VTX, votre partenaire telecom proche de vous !
================================================================

Le Monday 04 May 2009 18.23:52 Bogdan-Andrei Iancu, vous avez ?crit?:
> Hi Marc,
> 
> what opensips version are you using?
> 
> also, for db_mode 2, when pushing the snmp query, do you get any errors 
> in opensips?
> 
> Regards,
> Bogdan
> 
> Marc Leurent wrote:
> > Hello all, I have noticed something strange about snmpstats and usrloc...
> > Have you got any explanation for me?
> > Thanks!
> >
> > When I set the usrloc | db_mode parameter to 0 or 1 (0 - This disables database completely. 1 - Write-Through scheme.)
> > I can get Contact data through the snmpstats module!
> > snmpwalk -c public -v 2c 127.0.0.1 .1.3.6.1.4.1.27483
> > ...
> > OPENSER-SIP-SERVER-MIB::openserSIPContactDisplayName.2.1 = STRING: sip:02131150 at 14.38.160.13:5070
> > OPENSER-SIP-SERVER-MIB::openserSIPContactURI.1.1 = STRING: DefaultUser
> > OPENSER-SIP-SERVER-MIB::openserSIPContactURI.2.1 = STRING: sip:02131150 at 14.38.160.13:5070
> > ...
> >
> >
> > but when I set  usrloc | db_mode parameter to 2 (2 - Write-Back scheme) I don't get anything from the snmpstats module
> > snmpwalk -c public -v 2c 127.0.0.1 .1.3.6.1.4.1.27483
> > OPENSER-SIP-SERVER-MIB::openserSIPContactDisplayName.1.1 = STRING: DefaultUser
> > OPENSER-SIP-SERVER-MIB::openserSIPContactURI.1.1 = STRING: DefaultUser
> > ...
> >
> > Have a nice day!
> > ++
> >
> >
> > the part of my opensips.cfg file about usrloc params
> >
> > # ----- usrloc params -----
> > /* modparam("usrloc", "db_mode",   X)
> >    for location entries
> >         0 - This disables database completely.
> >         1 - Write-Through scheme. All changes to usrloc are immediately reflected in database too.
> >         2 - Write-Back scheme. This is a combination of previous two schemes. All changes are made to memory and database synchronization is done in the timer.
> >         3 - DB-Only scheme. No memory cache is kept, all operations being directly performed with the database.
> > */
> > modparam("usrloc", "db_mode", 1)
> > modparam("usrloc", "db_url", "mysql://opensips:UqwdwfuJ at localhost/opensips")
> > modparam("usrloc", "nat_bflag", 6)              # The index of the branch flag to be used as NAT marker (if the contact is or not natted).
> > modparam("usrloc", "use_domain", 0)             # If the domain part of the user should be also saved and used for identifing the user
> > modparam("usrloc", "desc_time_order", 0)        # If the user's contacts should be kept timestamp ordered; otherwise the contact will be ordered based on q value.
> > modparam("usrloc", "timer_interval", 30)        # The module uses timer to delete expired contacts, synchronize with database and other tasks, that need to be run periodically.
> > modparam("usrloc", "matching_mode", 0)          # What contact matching algorithm to be used. 0 - CONTACT ONLY based matching algorithm
> > modparam("usrloc", "cseq_delay", 20)            # Delay (in seconds) for accepting as retransmissions register requests with same Call-ID and Cseq.
> > modparam("usrloc", "fetch_rows", 2000)          # number of the rows to be fetched at once from database when loading the location records.
> > modparam("usrloc", "hash_size", 9)              # Number of entries of the hash table used by usrloc to store the location records is 2^hash_size.
> >
> >
> >
> >
> >
> > -- --
> > Marc LEURENT
> > Ing?nieur VoIP
> >
> > DECKPOINT SA
> > Une soci?t? du groupe VTX Telecom
> > ================================================================
> > Rue Eug?ne-Marziano 15 - 1227 Les Acacias
> > http://www.vtx.ch - marc.leurent at vtx-telecom.ch
> > ----------------------------------------------------------------
> > VTX, votre partenaire telecom proche de vous !
> > ================================================================
> >
> > _______________________________________________
> > Users mailing list
> > Users at lists.opensips.org
> > http://lists.opensips.org/cgi-bin/mailman/listinfo/users
> >
> >   
> 
> 




From bogdan at voice-system.ro  Tue May  5 11:35:20 2009
From: bogdan at voice-system.ro (Bogdan-Andrei Iancu)
Date: Tue, 05 May 2009 09:35:20 +0000
Subject: [OpenSIPS-Devel] SF.net SVN: opensips:[5661] trunk/modules/alias_db
Message-ID: <E1M1H3Y-0000Ib-VR@d5vjzd1.ch3.sourceforge.com>

Revision: 5661
          http://opensips.svn.sourceforge.net/opensips/?rev=5661&view=rev
Author:   bogdan_iancu
Date:     2009-05-05 09:35:20 +0000 (Tue, 05 May 2009)

Log Message:
-----------
- new function alias_db_find("table","input_var","output_var") to lookup for a DB alias using as input whatever value from a Pseudo-Var and placing the result in a different Pseudo-Var; 
Similar to alias_db_lookup(), but it does not use and affect the current SIP mesassge (source and desitnation for alias lookup may be whatsoever).

Based on the patch 2713792, submited by Vladimir Romanov.


- both alias_db_lookup() and alias_db_find() may take a third param, a list of flags (char based flags):
    'd' - do not use domain part in the lookup (by default domain is used)
    'r' - do revers lookup - the input is the ID URI and the result is alias URI (normally the input is the alias URI and the result is the ID URI)

Modified Paths:
--------------
    trunk/modules/alias_db/alias_db.c
    trunk/modules/alias_db/alias_db.h
    trunk/modules/alias_db/alookup.c
    trunk/modules/alias_db/alookup.h


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


From noreply at sourceforge.net  Tue May  5 11:52:13 2009
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue, 05 May 2009 09:52:13 +0000
Subject: [OpenSIPS-Devel] [ opensips-Patches-2713792 ] New method in
	alias_db - alias_db_find
Message-ID: <E1M1HJt-0003p1-AC@d55xhf1.ch3.sourceforge.com>

Patches item #2713792, was opened at 2009-03-26 09:44
Message generated for change (Comment added) made by bogdan_iancu
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086412&aid=2713792&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: Vladimir Romanov (v-romanov)
Assigned to: Bogdan-Andrei Iancu (bogdan_iancu)
Summary: New method in alias_db - alias_db_find

Initial Comment:
I implement new  method in alias_db module ? alias_db_find(?tablename?,?avp?). This method  similar to alias_db_lookup but use avp as instead of message RURI. Also some refactoring to remove repeated code.
I use this this new method in in this case:

if (uri==myself) {
        if (is_method("REGISTER")) {
            sl_send_reply("100", "Trying");
            $avp(s:alias):=$tu;
            if (alias_db_find("dbaliases","$avp(s:alias)")) {
                xlog("L_INFO", "Registration was aliased - $tu -> $avp(s:alias)\n");
            }

            if (!www_authorize("_SIP_DOMAIN", "subscriber")) {
                  www_challenge("_SIP_DOMAIN", "0");
                  return;
            };
            if (!check_to()) {
                 xlog("L_INFO", "Spoofed To-URI detected - M=$rm RURI=$ru F=$fu T=$tu IP=$si ID=$ci\n");
                 sl_send_reply("403", "Spoofed To-URI Detected");
                 exit;
            };
            if (!save("location","0","$avp(s:alias)"))  {
                xlog("L_ERR", "Saving contact failed - M=$rm RURI=$ru F=$fu T=$tu IP=$si ID=$ci\n");
                sl_reply_error();
            }
            exit;
        };



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

>Comment By: Bogdan-Andrei Iancu (bogdan_iancu)
Date: 2009-05-05 12:52

Message:
Patched applied on trunk (opensips 1.6 version)

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

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


From bogdan at voice-system.ro  Tue May  5 12:04:58 2009
From: bogdan at voice-system.ro (Bogdan-Andrei Iancu)
Date: Tue, 05 May 2009 10:04:58 +0000
Subject: [OpenSIPS-Devel] SF.net SVN: opensips:[5662] trunk/modules/alias_db
Message-ID: <E1M1HWE-0007W1-Cf@bj8yhf1.ch3.sourceforge.com>

Revision: 5662
          http://opensips.svn.sourceforge.net/opensips/?rev=5662&view=rev
Author:   bogdan_iancu
Date:     2009-05-05 10:04:58 +0000 (Tue, 05 May 2009)

Log Message:
-----------
- docs updated to reflect the latest changes

Modified Paths:
--------------
    trunk/modules/alias_db/README
    trunk/modules/alias_db/doc/alias_db.xml
    trunk/modules/alias_db/doc/alias_db_admin.xml


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


From bogdan at voice-system.ro  Tue May  5 12:06:23 2009
From: bogdan at voice-system.ro (Bogdan-Andrei Iancu)
Date: Tue, 05 May 2009 10:06:23 +0000
Subject: [OpenSIPS-Devel] SF.net SVN: opensips:[5663]
	trunk/modules/alias_db/doc/alias_db_faq.xml
Message-ID: <E1M1HXb-0007Y9-QZ@bj8yhf1.ch3.sourceforge.com>

Revision: 5663
          http://opensips.svn.sourceforge.net/opensips/?rev=5663&view=rev
Author:   bogdan_iancu
Date:     2009-05-05 10:06:23 +0000 (Tue, 05 May 2009)

Log Message:
-----------
- added the FAQ file to docs

Added Paths:
-----------
    trunk/modules/alias_db/doc/alias_db_faq.xml


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


From bogdan at voice-system.ro  Tue May  5 12:36:49 2009
From: bogdan at voice-system.ro (Bogdan-Andrei Iancu)
Date: Tue, 05 May 2009 13:36:49 +0300
Subject: [OpenSIPS-Devel] [NEW] ALIAS_DB enhancements
Message-ID: <4A0016C1.7040002@voice-system.ro>

Hi,

The 1.6 version (trunk) has new enhancements for the alias_db module :

1) perform alias lookups with custom URI input and custom URI output - 
instead of using fixed input (RURI) and fixed output (RURI), the new 
"alias_db_find" function is able to get the input SIP URI from a 
pseudo-variable and place the result back also in a pseudo-variable.

2) reverse lookup - you perform URI-to-alias lookups also (previous only 
alias-to-URI lookups were possible) - the "r" flag to the lookup 
function reverse the lookup direction. This is very useful when heaving 
PBXs (with extensions) behind OpenSIPS: when users from behind PBX are 
dialling out and the proxy needs to replace the SIP URI with the alias 
(as outbound identity) - alias-2-URI for inbound calls and URI-2-alias 
for outbound calls, so only the alias is visible to the outside world.

3) use_domain global parameter was replace with the "d" per-lookup flag. 
This allows your opensips to perform in the same time lookups with or 
without domain part. This is useful when you consider the multi-domain 
scenario where you have SIP aliases (and user+domain lookups are 
required) and DID aliases (only user based lookups are required) (a DID 
is defined only by number and the domain part is irrelevant - even if 
you dial DID at domainA.com or DID at domainB.com, it is the same target).


For more, please also refer to http://www.opensips.org/Main/Ver160#toc3


Regards,
Bogdan


From ibc at aliax.net  Tue May  5 12:42:25 2009
From: ibc at aliax.net (=?UTF-8?Q?I=C3=B1aki_Baz_Castillo?=)
Date: Tue, 5 May 2009 12:42:25 +0200
Subject: [OpenSIPS-Devel] [NEW] ALIAS_DB enhancements
In-Reply-To: <4A0016C1.7040002@voice-system.ro>
References: <4A0016C1.7040002@voice-system.ro>
Message-ID: <cc1f582e0905050342u50eaa277x5afe6e7c7e4f1a4a@mail.gmail.com>

2009/5/5 Bogdan-Andrei Iancu <bogdan at voice-system.ro>:
> Hi,
>
> The 1.6 version (trunk) has new enhancements for the alias_db module :

Really great and useful enhancements.
Congratulations.

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


From bogdan at voice-system.ro  Tue May  5 12:43:24 2009
From: bogdan at voice-system.ro (Bogdan-Andrei Iancu)
Date: Tue, 05 May 2009 10:43:24 +0000
Subject: [OpenSIPS-Devel] SF.net SVN: opensips:[5664]
	trunk/modules/cpl-c/cpl_run.c
Message-ID: <E1M1I7Q-0002K6-5A@74yxhf1.ch3.sourceforge.com>

Revision: 5664
          http://opensips.svn.sourceforge.net/opensips/?rev=5664&view=rev
Author:   bogdan_iancu
Date:     2009-05-05 10:43:24 +0000 (Tue, 05 May 2009)

Log Message:
-----------
- fixed bug - CPL "lookup" is not checking for the possibility that a contact's q-value could be Q_UNSPECIFIED when setting a locations "priority".

Credits go to John Riordan.
Closes patch #2786818.

Modified Paths:
--------------
    trunk/modules/cpl-c/cpl_run.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  Tue May  5 12:47:23 2009
From: bogdan at voice-system.ro (Bogdan-Andrei Iancu)
Date: Tue, 05 May 2009 10:47:23 +0000
Subject: [OpenSIPS-Devel] SF.net SVN: opensips:[5665]
	branches/1.5/modules/cpl-c/cpl_run.c
Message-ID: <E1M1IBH-0002OR-F6@74yxhf1.ch3.sourceforge.com>

Revision: 5665
          http://opensips.svn.sourceforge.net/opensips/?rev=5665&view=rev
Author:   bogdan_iancu
Date:     2009-05-05 10:47:23 +0000 (Tue, 05 May 2009)

Log Message:
-----------
backport from trunk (rev #5664):
- fixed bug - CPL "lookup" is not checking for the possibility that a contact's q-value could be Q_UNSPECIFIED when setting a locations "priority".

Credits go to John Riordan.
Closes patch #2786818.

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

Modified Paths:
--------------
    branches/1.5/modules/cpl-c/cpl_run.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  Tue May  5 12:48:11 2009
From: bogdan at voice-system.ro (Bogdan-Andrei Iancu)
Date: Tue, 05 May 2009 10:48:11 +0000
Subject: [OpenSIPS-Devel] SF.net SVN: opensips:[5666]
	branches/1.4/modules/cpl-c/cpl_run.c
Message-ID: <E1M1IC3-0002PN-OX@74yxhf1.ch3.sourceforge.com>

Revision: 5666
          http://opensips.svn.sourceforge.net/opensips/?rev=5666&view=rev
Author:   bogdan_iancu
Date:     2009-05-05 10:48:11 +0000 (Tue, 05 May 2009)

Log Message:
-----------
backport from trunk (rev #5664):
- fixed bug - CPL "lookup" is not checking for the possibility that a contact's q-value could be Q_UNSPECIFIED when setting a locations "priority".

Credits go to John Riordan.
Closes patch #2786818

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

Modified Paths:
--------------
    branches/1.4/modules/cpl-c/cpl_run.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 May  5 12:49:15 2009
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue, 05 May 2009 10:49:15 +0000
Subject: [OpenSIPS-Devel] [ opensips-Patches-2786818 ] fix: cpl - priority
	not set correctly when Q_UNSPECIFIED
Message-ID: <E1M1ID5-0001VS-M1@g45xhf1.ch3.sourceforge.com>

Patches item #2786818, was opened at 2009-05-04 22:34
Message generated for change (Comment added) made by bogdan_iancu
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086412&aid=2786818&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: Closed
>Resolution: Accepted
Priority: 5
Private: No
Submitted By: John Riordan (john_riordan)
>Assigned to: Bogdan-Andrei Iancu (bogdan_iancu)
Summary: fix: cpl - priority not set correctly when Q_UNSPECIFIED

Initial Comment:
CPL "lookup" is not checking for the possibility that a contact's q-value could be Q_UNSPECIFIED when setting a locations "priority".

The patch adds this check and sets the priority to "1.0" in accordance with RFC3880 (CPL)
...
Section 5.1
...
"The optional "priority" parameter specifies a priority for the
location.  Its value is a floating-point number between 0.0 and 1.0.
If it is not specified, the server SHOULD assume a default priority
of 1.0."
...
Section 6.1.1
...
"SIP servers SHOULD honor the "q" parameter of SIP registrations when
determining location priority."


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

>Comment By: Bogdan-Andrei Iancu (bogdan_iancu)
Date: 2009-05-05 13:49

Message:
Hi John,

Thanks for the patch - I applied it on trunk, 1.5 and 1.4 OpenSIPS
versions.

Regards,
Bogdan

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

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


From bogdan at voice-system.ro  Tue May  5 12:52:28 2009
From: bogdan at voice-system.ro (Bogdan-Andrei Iancu)
Date: Tue, 05 May 2009 10:52:28 +0000
Subject: [OpenSIPS-Devel] SF.net SVN: opensips:[5667]
	trunk/modules/cpl-c/loc_set.h
Message-ID: <E1M1IGC-0002Uc-7R@74yxhf1.ch3.sourceforge.com>

Revision: 5667
          http://opensips.svn.sourceforge.net/opensips/?rev=5667&view=rev
Author:   bogdan_iancu
Date:     2009-05-05 10:52:27 +0000 (Tue, 05 May 2009)

Log Message:
-----------
- bug fixing: When locations having the same priority are added to the CPL location set, the add order is not maintained.
  Credits go to John Riordan.
  Closes patch #2786822

Modified Paths:
--------------
    trunk/modules/cpl-c/loc_set.h


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


From noreply at sourceforge.net  Tue May  5 12:53:59 2009
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue, 05 May 2009 10:53:59 +0000
Subject: [OpenSIPS-Devel] [ opensips-Patches-2786822 ] fix: cpl - location
	set ordering on identical priorities
Message-ID: <E1M1IHf-0003HI-Ej@1bkjzd1.ch3.sourceforge.com>

Patches item #2786822, was opened at 2009-05-04 22: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=2786822&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: Closed
>Resolution: Accepted
Priority: 5
Private: No
Submitted By: John Riordan (john_riordan)
>Assigned to: Bogdan-Andrei Iancu (bogdan_iancu)
Summary: fix: cpl - location set ordering on identical priorities 

Initial Comment:
When locations having the same priority are added to the CPL location set, the add order is not maintained.


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

>Comment By: Bogdan-Andrei Iancu (bogdan_iancu)
Date: 2009-05-05 13:53

Message:
Again, thanks for the patch :)
I already pushed it on all OpenSIPS branches.

Thanks and regards,
Bogdan

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

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


From bogdan at voice-system.ro  Tue May  5 12:56:05 2009
From: bogdan at voice-system.ro (Bogdan-Andrei Iancu)
Date: Tue, 05 May 2009 10:56:05 +0000
Subject: [OpenSIPS-Devel] SF.net SVN: opensips:[5668]
	branches/1.5/modules/cpl-c/loc_set.h
Message-ID: <E1M1IJh-0002aj-SX@74yxhf1.ch3.sourceforge.com>

Revision: 5668
          http://opensips.svn.sourceforge.net/opensips/?rev=5668&view=rev
Author:   bogdan_iancu
Date:     2009-05-05 10:56:05 +0000 (Tue, 05 May 2009)

Log Message:
-----------
backport from trunk (rev #5667):
- bug fixing: When locations having the same priority are added to the CPL location set, the add order is not maintained.
  Credits go to John Riordan.
  Closes patch #2786822

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

Modified Paths:
--------------
    branches/1.5/modules/cpl-c/loc_set.h


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


From bogdan at voice-system.ro  Tue May  5 12:56:38 2009
From: bogdan at voice-system.ro (Bogdan-Andrei Iancu)
Date: Tue, 05 May 2009 10:56:38 +0000
Subject: [OpenSIPS-Devel] SF.net SVN: opensips:[5669]
	branches/1.4/modules/cpl-c/loc_set.h
Message-ID: <E1M1IKE-0002bG-Jl@74yxhf1.ch3.sourceforge.com>

Revision: 5669
          http://opensips.svn.sourceforge.net/opensips/?rev=5669&view=rev
Author:   bogdan_iancu
Date:     2009-05-05 10:56:38 +0000 (Tue, 05 May 2009)

Log Message:
-----------
backport from trunk (rev #5667):
- bug fixing: When locations having the same priority are added to the CPL location set, the add order is not maintained.
  Credits go to John Riordan.
  Closes patch #2786822

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

Modified Paths:
--------------
    branches/1.4/modules/cpl-c/loc_set.h


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


From bogdan at voice-system.ro  Tue May  5 12:59:59 2009
From: bogdan at voice-system.ro (Bogdan-Andrei Iancu)
Date: Tue, 05 May 2009 10:59:59 +0000
Subject: [OpenSIPS-Devel] SF.net SVN: opensips:[5670] trunk/daemonize.c
Message-ID: <E1M1INT-0002f9-4z@74yxhf1.ch3.sourceforge.com>

Revision: 5670
          http://opensips.svn.sourceforge.net/opensips/?rev=5670&view=rev
Author:   bogdan_iancu
Date:     2009-05-05 10:59:59 +0000 (Tue, 05 May 2009)

Log Message:
-----------
- warning fixed : handle fscanf return value to avoid warning when compiling on Linux x86.
  Credits go to Sergio Gutierrez.
  Closes patch #2750920

Modified Paths:
--------------
    trunk/daemonize.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 May  5 13:00:45 2009
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue, 05 May 2009 11:00:45 +0000
Subject: [OpenSIPS-Devel] [ opensips-Patches-2750920 ] Warning in fscanf
	usage
Message-ID: <E1M1IOD-0008Ra-IL@d55xhf1.ch3.sourceforge.com>

Patches item #2750920, was opened at 2009-04-11 01:46
Message generated for change (Comment added) made by bogdan_iancu
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086412&aid=2750920&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: Accepted
Priority: 5
Private: No
Submitted By: Sergio Gutierrez (saguti)
>Assigned to: Bogdan-Andrei Iancu (bogdan_iancu)
Summary: Warning in fscanf usage

Initial Comment:
This patches handles fscanf return value to avoid warning when compiling on Linux x86.

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

>Comment By: Bogdan-Andrei Iancu (bogdan_iancu)
Date: 2009-05-05 14:00

Message:
Hi Sergio,

Thanks for the patch - I pushed it on SVN.

Regards,
Bogdan

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

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


From noreply at sourceforge.net  Tue May  5 13:02:19 2009
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue, 05 May 2009 11:02:19 +0000
Subject: [OpenSIPS-Devel] [ opensips-Bugs-2786735 ] drouting do not accept
	null prefixes
Message-ID: <E1M1IPj-0001DR-46@h45xhf1.ch3.sourceforge.com>

Bugs item #2786735, was opened at 2009-05-04 20:06
Message generated for change (Settings changed) made by bogdan_iancu
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=2786735&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: Accepted
Priority: 5
Private: No
Submitted By: Nobody/Anonymous (nobody)
>Assigned to: Bogdan-Andrei Iancu (bogdan_iancu)
Summary: drouting do not accept null prefixes

Initial Comment:
drouting module doesn't accept null prefixes in dr_rules table but there isn't "blank" strings in oracle. So, I'm not able to use drouting with oracle.

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

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


From noreply at sourceforge.net  Tue May  5 13:02:26 2009
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue, 05 May 2009 11:02:26 +0000
Subject: [OpenSIPS-Devel] [ opensips-Bugs-2787094 ] Crash with db_postgresql
	and no db connection
Message-ID: <E1M1IPq-0003qp-Gv@1bkjzd1.ch3.sourceforge.com>

Bugs item #2787094, was opened at 2009-05-05 11: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=2787094&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: Nobody/Anonymous (nobody)
>Assigned to: Bogdan-Andrei Iancu (bogdan_iancu)
Summary: Crash with db_postgresql and no db connection

Initial Comment:
Opensips with usrloc and db_postgresql will crash if the db server is unreachable.


Scenario is the following, I have a remote postgres DB server, and had not opened the PG port on the firewall, which causes opensips to be unable to reach the DB server.
on init, opensips times out trying to connect to the DB, and then crash, looking at the logs, it seems to be usrloc module related.

It's easy to reproduce, I can provide as many tracks as needed.

If you need me bogdan, ask on irc ( Gled ).

bt:
#0  0x0000000000425f36 in handle_sigs () at main.c:486
486                                             if (pt[i].pid==chld) break;

#0  0x0000000000425f36 in handle_sigs () at main.c:486
#1  <signal handler called>
#2  0x00000030e6ae0cb7 in munmap () from /lib64/libc.so.6
#3  0x00000000004a4804 in shm_mem_destroy () at mem/shm_mem.c:238
#4  0x00000000004259a6 in cleanup (show_status=0) at main.c:365
#5  0x0000000000428560 in main (argc=<value optimized out>, argv=0x20) at main.c:1324

bt full:
#0  0x0000000000425f36 in handle_sigs () at main.c:486
        chld = 1909
        chld_status = 0
        i = <value optimized out>
        do_exit = 0
        __FUNCTION__ = "handle_sigs"
#1  <signal handler called>
No symbol table info available.
#2  0x00000030e6ae0cb7 in munmap () from /lib64/libc.so.6
No symbol table info available.
#3  0x00000000004a4804 in shm_mem_destroy () at mem/shm_mem.c:238
        __FUNCTION__ = "shm_mem_destroy"
#4  0x00000000004259a6 in cleanup (show_status=0) at main.c:365
No locals.
#5  0x0000000000428560 in main (argc=<value optimized out>, argv=0x20) at main.c:1324
        cfg_log_stderr = 1906
        cfg_stream = (FILE *) 0x772
        c = <value optimized out>
        r = 1
        tmp = 0x4ffe65 "H\205?t\0341?\017\037@"
        tmp_len = <value optimized out>
        port = <value optimized out>
        proto = <value optimized out>
        ret = -1
        seed = 2320449269
        rfd = <value optimized out>
        __FUNCTION__ = "main"


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

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


From noreply at sourceforge.net  Tue May  5 13:05:41 2009
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue, 05 May 2009 11:05:41 +0000
Subject: [OpenSIPS-Devel] [ opensips-Bugs-2779524 ] ERROR in
	re_init_statement: failed while mysql_stmt_prepare.
Message-ID: <E1M1ISz-0002b1-5f@g45xhf1.ch3.sourceforge.com>

Bugs item #2779524, was opened at 2009-04-23 16:41
Message generated for change (Settings changed) made by bogdan_iancu
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=2779524&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: Deleted
>Resolution: Duplicate
Priority: 5
Private: No
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: ERROR in re_init_statement: failed while mysql_stmt_prepare.

Initial Comment:
When it happens, every registration gets rejected with 500 server internal error.

Apr 23 04:04:07 /usr/local/sbin/opensips[9042]: ERROR:db_mysql:re_init_statement: failed while mysql_stmt_prepare: (1243) Unknown prepared statement
handler (4) given to mysql_stmt_close
Apr 23 04:04:07 /usr/local/sbin/opensips[9042]: ERROR:db_mysql:db_mysql_do_prepared_query: failed to re-init statement!
Apr 23 04:04:07 /usr/local/sbin/opensips[9042]: ERROR:usrloc:db_update_ucontact: updating database failed
Apr 23 04:04:07 /usr/local/sbin/opensips[9042]: ERROR:usrloc:wb_timer: updating contact in db failed
Apr 23 04:04:13 /usr/local/sbin/opensips[9042]: ERROR:db_mysql:get_new_stmt_ctx: failed while mysql_stmt_prepare: (2013) Lost connection to MySQL ser
ver during query
[...]
Apr 23 04:07:08 /usr/local/sbin/opensips[9002]: ERROR:db_mysql:re_init_statement: failed while mysql_stmt_prepare: (1243) Unknown prepared statement
handler (1) given to mysql_stmt_close
Apr 23 04:07:08 /usr/local/sbin/opensips[9002]: ERROR:db_mysql:db_mysql_do_prepared_query: failed to re-init statement!
Apr 23 04:07:08 /usr/local/sbin/opensips[9002]: ERROR:siptrace:sip_trace: error storing trace
Apr 23 04:07:09 /usr/local/sbin/opensips[9005]: ERROR:db_mysql:db_mysql_do_prepared_query: mysql_stmt_bind_param() failed: Using unsupported buffer type: 858928432  (parameter: 2)

the later ones seems to be mysql errors, but triggered from the first one. Restarting opensips (1.5.1) solves the problem for a few days.

Thanks a lot!

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

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


From noreply at sourceforge.net  Tue May  5 13:06:11 2009
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue, 05 May 2009 11:06:11 +0000
Subject: [OpenSIPS-Devel] [ opensips-Bugs-2779502 ] ERROR in
	re_init_statement: failed while mysql_stmt_prepare.
Message-ID: <E1M1ITT-0000NH-Pz@d55xhf1.ch3.sourceforge.com>

Bugs item #2779502, was opened at 2009-04-23 16:27
Message generated for change (Settings changed) made by bogdan_iancu
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=2779502&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: Nobody/Anonymous (nobody)
>Assigned to: Bogdan-Andrei Iancu (bogdan_iancu)
Summary: ERROR in re_init_statement: failed while mysql_stmt_prepare.

Initial Comment:
When it happens, every registration gets rejected with 500 server internal error.

Apr 23 04:04:07 /usr/local/sbin/opensips[9042]: ERROR:db_mysql:re_init_statement: failed while mysql_stmt_prepare: (1243) Unknown prepared statement
handler (4) given to mysql_stmt_close
Apr 23 04:04:07 /usr/local/sbin/opensips[9042]: ERROR:db_mysql:db_mysql_do_prepared_query: failed to re-init statement!
Apr 23 04:04:07 /usr/local/sbin/opensips[9042]: ERROR:usrloc:db_update_ucontact: updating database failed
Apr 23 04:04:07 /usr/local/sbin/opensips[9042]: ERROR:usrloc:wb_timer: updating contact in db failed
Apr 23 04:04:13 /usr/local/sbin/opensips[9042]: ERROR:db_mysql:get_new_stmt_ctx: failed while mysql_stmt_prepare: (2013) Lost connection to MySQL ser
ver during query
[...]
Apr 23 04:07:08 /usr/local/sbin/opensips[9002]: ERROR:db_mysql:re_init_statement: failed while mysql_stmt_prepare: (1243) Unknown prepared statement
handler (1) given to mysql_stmt_close
Apr 23 04:07:08 /usr/local/sbin/opensips[9002]: ERROR:db_mysql:db_mysql_do_prepared_query: failed to re-init statement!
Apr 23 04:07:08 /usr/local/sbin/opensips[9002]: ERROR:siptrace:sip_trace: error storing trace
Apr 23 04:07:09 /usr/local/sbin/opensips[9005]: ERROR:db_mysql:db_mysql_do_prepared_query: mysql_stmt_bind_param() failed: Using unsupported buffer type: 858928432  (parameter: 2)

the later ones seems to be mysql errors, but triggered from the first one. Restarting opensips (1.5.1) solves the problem for a few days.

Thanks a lot!

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

Comment By: Nobody/Anonymous (nobody)
Date: 2009-04-23 16:42

Message:
sorry for the duplicate, my mistake!

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

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


From bogdan at voice-system.ro  Tue May  5 13:02:08 2009
From: bogdan at voice-system.ro (Bogdan-Andrei Iancu)
Date: Tue, 05 May 2009 11:02:08 +0000
Subject: [OpenSIPS-Devel] SF.net SVN: opensips:[5671]
	branches/1.4/daemonize.c
Message-ID: <E1M1IPY-0002iA-Kc@74yxhf1.ch3.sourceforge.com>

Revision: 5671
          http://opensips.svn.sourceforge.net/opensips/?rev=5671&view=rev
Author:   bogdan_iancu
Date:     2009-05-05 11:02:08 +0000 (Tue, 05 May 2009)

Log Message:
-----------
backport from trunk (rev #5670):
- warning fixed : handle fscanf return value to avoid warning when compiling on Linux x86.
  Credits go to Sergio Gutierrez.
  Closes patch #2750920

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

Modified Paths:
--------------
    branches/1.4/daemonize.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  Tue May  5 13:05:24 2009
From: bogdan at voice-system.ro (Bogdan-Andrei Iancu)
Date: Tue, 05 May 2009 11:05:24 +0000
Subject: [OpenSIPS-Devel] SF.net SVN: opensips:[5672]
	branches/1.5/daemonize.c
Message-ID: <E1M1ISi-0002m6-DM@74yxhf1.ch3.sourceforge.com>

Revision: 5672
          http://opensips.svn.sourceforge.net/opensips/?rev=5672&view=rev
Author:   bogdan_iancu
Date:     2009-05-05 11:05:24 +0000 (Tue, 05 May 2009)

Log Message:
-----------
backport from trunk (rev #5670):
- warning fixed : handle fscanf return value to avoid warning when compiling on Linux x86.
  Credits go to Sergio Gutierrez.
  Closes patch #2750920

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

Modified Paths:
--------------
    branches/1.5/daemonize.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 May  5 17:50:09 2009
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue, 05 May 2009 15:50:09 +0000
Subject: [OpenSIPS-Devel] [ opensips-Bugs-2786735 ] drouting do not accept
	null prefixes
Message-ID: <E1M1MuH-0007rt-Tm@155xhf1.ch3.sourceforge.com>

Bugs item #2786735, was opened at 2009-05-04 20:06
Message generated for change (Comment added) made by bogdan_iancu
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=2786735&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: Fixed
Priority: 5
Private: No
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Bogdan-Andrei Iancu (bogdan_iancu)
Summary: drouting do not accept null prefixes

Initial Comment:
drouting module doesn't accept null prefixes in dr_rules table but there isn't "blank" strings in oracle. So, I'm not able to use drouting with oracle.

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

>Comment By: Bogdan-Andrei Iancu (bogdan_iancu)
Date: 2009-05-05 18:50

Message:
Hi,

a fix is available on trunk version - please confirm it and I will do the
backport to 1.5 also.

Regards,
Bogdan

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

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


From bogdan at voice-system.ro  Tue May  5 17:51:44 2009
From: bogdan at voice-system.ro (Bogdan-Andrei Iancu)
Date: Tue, 05 May 2009 15:51:44 +0000
Subject: [OpenSIPS-Devel] SF.net SVN: opensips:[5673]
	trunk/modules/drouting/dr_load.c
Message-ID: <E1M1Mvo-0008LK-DR@c3vjzd1.ch3.sourceforge.com>

Revision: 5673
          http://opensips.svn.sourceforge.net/opensips/?rev=5673&view=rev
Author:   bogdan_iancu
Date:     2009-05-05 15:51:17 +0000 (Tue, 05 May 2009)

Log Message:
-----------
- fixed bugs: drouting module doesn't accept null prefixes in dr_rules table but there isn't "blank" strings in oracle. So, I'm not able to use drouting with oracle.

 Closes bug #2786735

Modified Paths:
--------------
    trunk/modules/drouting/dr_load.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 May  6 08:05:50 2009
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed, 06 May 2009 06:05:50 +0000
Subject: [OpenSIPS-Devel] [ opensips-Patches-2787654 ] fix: dialog -
	persistent attributes memory leak
Message-ID: <E1M1aGM-0004CP-4O@1bkjzd1.ch3.sourceforge.com>

Patches item #2787654, was opened at 2009-05-06 02:05
Message generated for change (Tracker Item Submitted) made by john_riordan
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086412&aid=2787654&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: John Riordan (john_riordan)
Assigned to: Nobody/Anonymous (nobody)
Summary: fix: dialog - persistent attributes memory leak

Initial Comment:
Shared memory allocated for dialog persistent attributes is not freed when dialog structure is destroyed.


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

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


From noreply at sourceforge.net  Wed May  6 11:19:51 2009
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed, 06 May 2009 09:19:51 +0000
Subject: [OpenSIPS-Devel] [ opensips-Bugs-2787745 ] No usrloc purge in
	snmpstats at unregister time
Message-ID: <E1M1dI7-0006vR-OK@665xhf1.ch3.sourceforge.com>

Bugs item #2787745, was opened at 2009-05-06 09:19
Message generated for change (Tracker Item Submitted) made by nobody
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=2787745&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: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: No usrloc purge in snmpstats at unregister time

Initial Comment:
Hello,
I'm using OpenSIPs 1.5.1 snmpstats module and each time I unregister a contact, it doesn't remove the entry from snmpstats data and put a strange expire date. But the user is correctly removed from usrloc. OpenSIPs reboot solve the problem and purge contacts from snmpstats. So If I unregister/reregister the contact 5 times, I will have 5 entries in snmpstats...

Have you got any idea how to solve the problem!

PS: I'm using OpenSIPs not as register proxy, it forwards the REGISTER requests to loadbalanced Asterisk but intercept it to be able to SIP ping users from OpenSIPs. I do not have other problem! Everything works!

I'm using :
version: opensips 1.5.1-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: unknown
@(#) $Id: main.c 5469 2009-03-18 12:43:10Z bogdan_iancu $
main.c compiled on 19:03:00 Apr 30 2009 with gcc 4.1.2

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

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


From bogdan at voice-system.ro  Wed May  6 17:08:29 2009
From: bogdan at voice-system.ro (Bogdan-Andrei Iancu)
Date: Wed, 06 May 2009 15:08:29 +0000
Subject: [OpenSIPS-Devel] SF.net SVN: opensips:[5674]
	branches/1.5/modules/drouting/dr_load.c
Message-ID: <E1M1ijV-0001sE-5u@d5vjzd1.ch3.sourceforge.com>

Revision: 5674
          http://opensips.svn.sourceforge.net/opensips/?rev=5674&view=rev
Author:   bogdan_iancu
Date:     2009-05-06 15:08:28 +0000 (Wed, 06 May 2009)

Log Message:
-----------
backport from trunk (rev #5673):
- fixed bugs: drouting module doesn't accept null prefixes in dr_rules table but there isn't "blank" strings in oracle. So, I'm not able to use drouting with oracle.

 Closes bug #2786735

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

Modified Paths:
--------------
    branches/1.5/modules/drouting/dr_load.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 May  6 17:09:38 2009
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed, 06 May 2009 15:09:38 +0000
Subject: [OpenSIPS-Devel] [ opensips-Bugs-2786735 ] drouting do not accept
	null prefixes
Message-ID: <E1M1ikc-0006P8-TG@1bkjzd1.ch3.sourceforge.com>

Bugs item #2786735, was opened at 2009-05-04 20:06
Message generated for change (Comment added) made by bogdan_iancu
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=2786735&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: Closed
Resolution: Fixed
Priority: 5
Private: No
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Bogdan-Andrei Iancu (bogdan_iancu)
Summary: drouting do not accept null prefixes

Initial Comment:
drouting module doesn't accept null prefixes in dr_rules table but there isn't "blank" strings in oracle. So, I'm not able to use drouting with oracle.

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

>Comment By: Bogdan-Andrei Iancu (bogdan_iancu)
Date: 2009-05-06 18:09

Message:
Fixed confirmed and backported to 1.5

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

Comment By: Bogdan-Andrei Iancu (bogdan_iancu)
Date: 2009-05-05 18:50

Message:
Hi,

a fix is available on trunk version - please confirm it and I will do the
backport to 1.5 also.

Regards,
Bogdan

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

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


From bogdan at voice-system.ro  Wed May  6 17:19:05 2009
From: bogdan at voice-system.ro (Bogdan-Andrei Iancu)
Date: Wed, 06 May 2009 15:19:05 +0000
Subject: [OpenSIPS-Devel] SF.net SVN: opensips:[5675]
	trunk/modules/dialog/dlg_hash.c
Message-ID: <E1M1itl-00024D-0E@d5vjzd1.ch3.sourceforge.com>

Revision: 5675
          http://opensips.svn.sourceforge.net/opensips/?rev=5675&view=rev
Author:   bogdan_iancu
Date:     2009-05-06 15:19:04 +0000 (Wed, 06 May 2009)

Log Message:
-----------
- fixed bug : free shared memory allocated for dialog persistent attributes  when dialog structure is destroyed.
  Credits go to John Riordan.
  Closes patch #2787654

Modified Paths:
--------------
    trunk/modules/dialog/dlg_hash.c


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


From noreply at sourceforge.net  Wed May  6 17:20:59 2009
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed, 06 May 2009 15:20:59 +0000
Subject: [OpenSIPS-Devel] [ opensips-Patches-2787654 ] fix: dialog -
	persistent attributes memory leak
Message-ID: <E1M1ivb-00067O-W6@g45xhf1.ch3.sourceforge.com>

Patches item #2787654, was opened at 2009-05-06 09:05
Message generated for change (Comment added) made by bogdan_iancu
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086412&aid=2787654&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: Closed
>Resolution: Accepted
Priority: 5
Private: No
Submitted By: John Riordan (john_riordan)
>Assigned to: Bogdan-Andrei Iancu (bogdan_iancu)
Summary: fix: dialog - persistent attributes memory leak

Initial Comment:
Shared memory allocated for dialog persistent attributes is not freed when dialog structure is destroyed.


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

>Comment By: Bogdan-Andrei Iancu (bogdan_iancu)
Date: 2009-05-06 18:20

Message:
Hi John,

Thanks again for the fix - It is correct and I uploaded it on the SVN.

Regards,
Bogdan

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

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


From bogdan at voice-system.ro  Wed May  6 17:21:07 2009
From: bogdan at voice-system.ro (Bogdan-Andrei Iancu)
Date: Wed, 06 May 2009 15:21:07 +0000
Subject: [OpenSIPS-Devel] SF.net SVN: opensips:[5676]
	branches/1.5/modules/dialog/dlg_hash.c
Message-ID: <E1M1ivj-00026L-Uv@d5vjzd1.ch3.sourceforge.com>

Revision: 5676
          http://opensips.svn.sourceforge.net/opensips/?rev=5676&view=rev
Author:   bogdan_iancu
Date:     2009-05-06 15:21:07 +0000 (Wed, 06 May 2009)

Log Message:
-----------
backport from trunk (rev #5675):
- fixed bug : free shared memory allocated for dialog persistent attributes  when dialog structure is destroyed.
  Credits go to John Riordan.
  Closes patch #2787654

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

Modified Paths:
--------------
    branches/1.5/modules/dialog/dlg_hash.c


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


From iulia at opensips.org  Wed May  6 19:51:15 2009
From: iulia at opensips.org (Iulia Bublea)
Date: Wed, 06 May 2009 17:51:15 +0000
Subject: [OpenSIPS-Devel] SF.net SVN: opensips:[5677]
	trunk/scripts/osipsconsole
Message-ID: <E1M1lH1-0005CW-4h@bj8yhf1.ch3.sourceforge.com>

Revision: 5677
          http://opensips.svn.sourceforge.net/opensips/?rev=5677&view=rev
Author:   iulia_bublea
Date:     2009-05-06 17:51:14 +0000 (Wed, 06 May 2009)

Log Message:
-----------
Fixed bogus with password encryption.

Modified Paths:
--------------
    trunk/scripts/osipsconsole


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


From iulia at opensips.org  Wed May  6 20:00:11 2009
From: iulia at opensips.org (Iulia Bublea)
Date: Wed, 06 May 2009 18:00:11 +0000
Subject: [OpenSIPS-Devel] SF.net SVN: opensips:[5678]
	branches/1.5/scripts/osipsconsole
Message-ID: <E1M1lPf-0005Nq-Jz@bj8yhf1.ch3.sourceforge.com>

Revision: 5678
          http://opensips.svn.sourceforge.net/opensips/?rev=5678&view=rev
Author:   iulia_bublea
Date:     2009-05-06 18:00:11 +0000 (Wed, 06 May 2009)

Log Message:
-----------
Fixed bogus regarding password encryption.

Modified Paths:
--------------
    branches/1.5/scripts/osipsconsole


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


From noreply at sourceforge.net  Thu May  7 05:38:50 2009
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 07 May 2009 03:38:50 +0000
Subject: [OpenSIPS-Devel] [ opensips-Patches-2788192 ] fix: cpl - branch
	flags not getting initialized correctly
Message-ID: <E1M1uRe-0004G9-1a@g45xhf1.ch3.sourceforge.com>

Patches item #2788192, was opened at 2009-05-06 23:38
Message generated for change (Tracker Item Submitted) made by john_riordan
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086412&aid=2788192&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: John Riordan (john_riordan)
Assigned to: Nobody/Anonymous (nobody)
Summary: fix: cpl - branch flags not getting initialized correctly

Initial Comment:
Hey Bogdan, 

This is #2785741 again. 

I just updated and it looks like my fix may have been lost in translation. The change which got implemented only partially fixes the problem I'm trying to solve.

Please bare with me while I attempt to explain the issue better. As I understand it (little that I do), the cpl proxy code implements sequential "ordering" by first creating a list of locations (location set). It then removes the first location from the head of the list, attempts to relay it, and then repeats until there are no more locations left in the list (or a positive final response). If additional branch flags are set while processing the first location (in the script branch_route for example), they are not getting cleared when the second location begins to be processed (as branch 0 again). The fix you implemented now initializes the nat branch flag correctly, but doesn't clear other flags that may have been set and these unexpectedly get carried over into for the next location processed. The patch attached completely clears the branch flags each time branch 0 is reused during this process. Note that an example of the correct behavior is implemented in the existing code a few lines down in the loop that add additional branches for parallel processing.

Cheers,

John


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

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


From noreply at sourceforge.net  Thu May  7 07:41:40 2009
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 07 May 2009 05:41:40 +0000
Subject: [OpenSIPS-Devel] [ opensips-Patches-2788216 ] cpl: 100 trying
	provisional reply not generated
Message-ID: <E1M1wMW-0003v8-5G@g45xhf1.ch3.sourceforge.com>

Patches item #2788216, was opened at 2009-05-07 01:41
Message generated for change (Tracker Item Submitted) made by john_riordan
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086412&aid=2788216&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: John Riordan (john_riordan)
Assigned to: Nobody/Anonymous (nobody)
Summary: cpl: 100 trying provisional reply not generated

Initial Comment:
cpl is not generating a 100 trying provisional reply when building the transaction. It seems like sending a provisional response should be the default behavior. Currently, unless a stateless 100 reply is pushed from the script prior to calling cpl the UAC tends to be left wanting and waiting when cpl initiates a transaction.

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

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


From bogdan at voice-system.ro  Thu May  7 11:01:09 2009
From: bogdan at voice-system.ro (Bogdan-Andrei Iancu)
Date: Thu, 07 May 2009 12:01:09 +0300
Subject: [OpenSIPS-Devel] [OpenSIPS-Business] OpenSIPS at Amoocon
 (former AsteriskTag)
In-Reply-To: <49F5DBC1.7050000@voice-system.ro>
References: <49A41899.8020401@voice-system.ro>
	<49F5DBC1.7050000@voice-system.ro>
Message-ID: <4A02A355.3080809@voice-system.ro>

Hi,

The Amoocon conference ended !

The presentations were uploaded on the OpenSIPS web site, so you can 
browse them at :
          http://www.opensips.org/Events/Amoocon2009

Regards,
Bogdan

Bogdan-Andrei Iancu wrote:
> Reminder : 1 week to Amoocon :)
>
> Bogdan-Andrei Iancu wrote:
>   
>> Hi,
>>
>> In behalf of OpenSIPS project, I submitted several papers for the 
>> Amoocon (Former AsteriskTag) on May 4th - 5th, 2009 - See 
>> http://www.amoocon.de/
>>
>> Covered topics are : Load-balancing (using the new load-balancer module) 
>> , Presence (deploy presence) and clustering (OpenSIPS + PBX integration):
>>
>> (1) Load balancing Workshop:
>>      http://www.amoocon.de/talks/8
>>
>> (2) Delivering Presence to end-users:
>>      http://www.amoocon.de/talks/46
>>
>> (3) OpenSIPS + Yate integration (unified clustering):
>>      http://www.amoocon.de/talks/47
>>
>>
>> So, for who ever participate to the Amoocon, feel free to join.
>>
>> Regards,
>> Bogdan
>>
>> _______________________________________________
>> Devel mailing list
>> Devel at lists.opensips.org
>> http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
>>
>>   
>>     
>
>
> _______________________________________________
> Business mailing list
> Business at lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/business
>
>   



From lftsy at leurent.eu  Fri May  8 13:27:51 2009
From: lftsy at leurent.eu (Marc Leurent)
Date: Fri, 8 May 2009 13:27:51 +0200
Subject: [OpenSIPS-Devel] [OpenSIPS-Users] Question about dialog max
	timeout...
In-Reply-To: <200905081320.54265.lftsy@leurent.eu>
References: <200905081306.18893.lftsy@leurent.eu>
	<200905081320.54265.lftsy@leurent.eu>
Message-ID: <200905081327.52111.lftsy@leurent.eu>

Sorry for the 3rd email.. but I think it's interesting, because the dialog timeout of my transactions seems to increase with OpenSIPs uptime!
So my shm memory increase all the time. Does any one have the same problem with OpenSIPs 1.5.1?
Thanks

opensipsctl fifo dlg_list | grep timeout | sort -nr
        timeout:: 20395
        timeout:: 20340
        timeout:: 20285
        timeout:: 20230
        timeout:: 20175
        timeout:: 20120
        timeout:: 20064
        timeout:: 20009
        timeout:: 19954
        timeout:: 19899
	...

and just after
opensipsctl fifo dlg_list | grep timeout | sort -nr
        timeout:: 20450
        timeout:: 20395
        timeout:: 20340
        timeout:: 20285
        timeout:: 20230
        timeout:: 20175
        timeout:: 20120
        timeout:: 20064
        timeout:: 20009
        timeout:: 19954
        timeout:: 19899
	...

PS: I'm using
opensips -V
version: opensips 1.5.1-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: unknown
@(#) $Id: main.c 5469 2009-03-18 12:43:10Z bogdan_iancu $
main.c compiled on 19:03:00 Apr 30 2009 with gcc 4.1.2


Le Friday 08 May 2009 13.06:18 Marc Leurent, vous avez ?crit?:
> Hello all, I have juste a small question about the dialog module, I have set the parameters below for OpenSIPs dialog module with a "default_timeout", ?to 3 hours,
> 
> # ----- dialog params -----
> modparam("dialog", "enable_stats", 1) ? ? ? ? ? ? ? ? ? ? ? ? ? # If the statistics support should be enabled or not.
> #modparam("dialog", "hash_size", 4096) ? ? ? ? ? ? ? ? ? ? ? ? ?# The size of the hash table internally used to keep the dialogs.
> modparam("dialog", "rr_param", "did") ? ? ? ? ? ? ? ? ? ? ? ? ? # Name of the Record-Route parameter to be added with the dialog cookie.
> modparam("dialog", "dlg_flag", 4) ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? # Flag to be used for marking if a dialog should be constructed for the current request.
> #modparam("dialog", "buy_on_timeout_flag", 6) ? ? ? ? ? ? ? ? ? # Message falg to be set if you want the dialog module to automatically send BYE requests (in both directions) when the dialog give timeout.
> #modparam("dialog", "timeout_avp", "$avp(i:10)") ? ? ? ? ? ? ? ?# The specification of an AVP to contain a custom timeout (in seconds) for the dialog.
> modparam("dialog", "default_timeout", 10800) ? ? ? ? ? ? ? ? ? ?# The default dialog timeout (in seconds) if no custom one is set.
> #modparam("dialog", "dlg_extra_hdrs", "Hint: credit expired\r\n") ? ? ? # A string containing the extra headers to be added in the requests generated
> modparam("dialog", "dlg_match_mode", 0) ? ? ? ? ? ? ? ? ? ? ? ? # The match is done exclusively based on DID;
> modparam("dialog", "db_url", "mysql://opensips:Uwefwefwefo3J at localhost/opensips")
> modparam("dialog", "db_mode", 1) ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?# Describe how to push into the DB the dialogs' information from memory.
> modparam("dialog", "db_update_period", 30) ? ? ? ? ? ? ? ? ? ? ?# The interval (seconds) at which to update dialogs' information if you chose to store.
> #modparam("dialog", "profiles_with_value", "caller ; my_profile") ? ? ? # List of names for profiles with values.
> #modparam("dialog", "profiles_no_value", "inbound ; outbound") ? ? ? ? ?# List of names for profiles without values.
> 
> but I have some dialogs that have a superior timeout like this one..
> Have you got any idea how to see where this timeout is defined and how to force it to a lower value!
> Because of this, I reach my "snmpstats", "dlg_minor_threshold", 900 very quickly
> Thanks!
> 
> dialog:: ?hash=1768:1584216798
> ? ? ? ? state:: 3
> ? ? ? ? user_flags:: 0
> ? ? ? ? timestart:: 1241777705
> ? ? ? ? timeout:: 16267
> ? ? ? ? callid:: zaltktgtpqzdqvo at leonhart.interne
> ? ? ? ? from_uri:: sip:0213115090 at 212.147.46.91
> ? ? ? ? from_tag:: ooctt
> ? ? ? ? caller_contact:: sip:0213115090 at 194.38.160.113:5070
> ? ? ? ? caller_cseq:: 960
> ? ? ? ? caller_route_set::
> ? ? ? ? caller_bind_addr:: udp:212.147.46.91:5060
> ? ? ? ? to_uri:: sip:0213115090 at 212.147.46.91
> ? ? ? ? to_tag:: as79ae919b
> ? ? ? ? callee_contact:: sip:0213115090 at 212.147.46.81:5060
> ? ? ? ? callee_cseq:: 960
> ? ? ? ? callee_route_set::
> ? ? ? ? callee_bind_addr:: udp:212.147.46.91:5060
> 
>


-- 
-- --
Marc LEURENT
lftsy at leurent.eu
Le Friday 08 May 2009 13.20:54 Marc Leurent, vous avez ?crit?:



From noreply at sourceforge.net  Fri May  8 13:57:19 2009
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 08 May 2009 11:57:19 +0000
Subject: [OpenSIPS-Devel] [ opensips-Bugs-2788937 ] presence: Wrong
	Subscription-State "expires" value in NOTIFY
Message-ID: <E1M2Ohb-0007bN-LJ@cdv4jf1.ch3.sourceforge.com>

Bugs item #2788937, was opened at 2009-05-08 13:57
Message generated for change (Tracker Item Submitted) made by ibc_sf
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=2788937&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: I?aki Baz Castillo (ibc_sf)
Assigned to: Nobody/Anonymous (nobody)
Summary: presence: Wrong Subscription-State "expires" value in NOTIFY

Initial Comment:
OpenSIPS "presence" module is generating really wrong "expires" values in "Subscription-State" header of NOTIFY. This causes the subscriber thinking that the subscription lives for long time (due to the exagerate high value of "expires" parameter) but the fact is that the subscriber dissapears from "active-watchers" table and leaves getting notifications.

I just use (these are really low values for testing, but the issue also occurs with higher values):

------------
modparam("presence", "max_expires_publish", 50)
modparam("presence", "max_expires_subscribe", 20)
modparam("presence", "expires_offset", 5)
modparam("presence", "fallback2db", 1)
------------

I attach a capture. Note in line 376 how the "Subscription-State" has a "cool" value:

  Subscription-State: active;expires=4294967285  <---- !!!!!!!!!!!!!

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

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


From noreply at sourceforge.net  Fri May  8 14:36:00 2009
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 08 May 2009 12:36:00 +0000
Subject: [OpenSIPS-Devel] [ opensips-Bugs-2788957 ] dialog entry purge and
	dialog timeout bug
Message-ID: <E1M2PJ2-000576-GW@d45xhf1.ch3.sourceforge.com>

Bugs item #2788957, was opened at 2009-05-08 12:36
Message generated for change (Tracker Item Submitted) made by nobody
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=2788957&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: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: dialog entry purge and dialog timeout bug

Initial Comment:
Hello all,
In OpenSIPs 1.4.5, dialog appeared in "opensipsctl fifo dlg_list" only if setflag was called on "modparam("dialog", "dlg_flag", 4)" that I triggered it only on an INVITE.
And everything looks fine, dialog was terminated receiving a BYE packet.

In OpenSIPS 1.5.1, all dialogs are visible in "opensipsctl fifo dlg_list", even without calling setflag(4) and furthermore, all my REGISTER transactions are not purged from memory after 200OK and the timeout parameter of these transaction increase with OpenSIPs uptime.

For example, I have put a default timeout of 10800s, my first REGISTER will get a timeout of 10807s, and another 60s later has a timeout of 10867s.

I'm trying to see where is the problem. I will keep you inform if I find something!

I used:
opensips -V
version: opensips 1.5.1-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: unknown
@(#) $Id: main.c 5469 2009-03-18 12:43:10Z bogdan_iancu $
main.c compiled on 19:03:00 Apr 30 2009 with gcc 4.1.2


PS: I put some other outputs in OpenSIPs user mailing list

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

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


From noreply at sourceforge.net  Fri May  8 14:38:07 2009
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 08 May 2009 12:38:07 +0000
Subject: [OpenSIPS-Devel] [ opensips-Bugs-2788957 ] dialog entry purge and
	dialog timeout bug
Message-ID: <E1M2PL5-00074c-3S@d55xhf1.ch3.sourceforge.com>

Bugs item #2788957, was opened at 2009-05-08 14:36
Message generated for change (Comment added) made by lftsy
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=2788957&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: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: dialog entry purge and dialog timeout bug

Initial Comment:
Hello all,
In OpenSIPs 1.4.5, dialog appeared in "opensipsctl fifo dlg_list" only if setflag was called on "modparam("dialog", "dlg_flag", 4)" that I triggered it only on an INVITE.
And everything looks fine, dialog was terminated receiving a BYE packet.

In OpenSIPS 1.5.1, all dialogs are visible in "opensipsctl fifo dlg_list", even without calling setflag(4) and furthermore, all my REGISTER transactions are not purged from memory after 200OK and the timeout parameter of these transaction increase with OpenSIPs uptime.

For example, I have put a default timeout of 10800s, my first REGISTER will get a timeout of 10807s, and another 60s later has a timeout of 10867s.

I'm trying to see where is the problem. I will keep you inform if I find something!

I used:
opensips -V
version: opensips 1.5.1-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: unknown
@(#) $Id: main.c 5469 2009-03-18 12:43:10Z bogdan_iancu $
main.c compiled on 19:03:00 Apr 30 2009 with gcc 4.1.2


PS: I put some other outputs in OpenSIPs user mailing list

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

Comment By: Marc LEURENT (lftsy)
Date: 2009-05-08 14:38

Message:
Sorry, I have posted this anonymously, Here is a comment...
Best Regards,
Marc Leurent

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

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


From noreply at sourceforge.net  Fri May  8 15:50:16 2009
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 08 May 2009 13:50:16 +0000
Subject: [OpenSIPS-Devel] [ opensips-Bugs-2788937 ] presence: Wrong
	Subscription-State "expires" value in NOTIFY
Message-ID: <E1M2QSu-00063b-KG@b55xhf1.ch3.sourceforge.com>

Bugs item #2788937, was opened at 2009-05-08 13:57
Message generated for change (Comment added) made by ibc_sf
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=2788937&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: I?aki Baz Castillo (ibc_sf)
Assigned to: Nobody/Anonymous (nobody)
Summary: presence: Wrong Subscription-State "expires" value in NOTIFY

Initial Comment:
OpenSIPS "presence" module is generating really wrong "expires" values in "Subscription-State" header of NOTIFY. This causes the subscriber thinking that the subscription lives for long time (due to the exagerate high value of "expires" parameter) but the fact is that the subscriber dissapears from "active-watchers" table and leaves getting notifications.

I just use (these are really low values for testing, but the issue also occurs with higher values):

------------
modparam("presence", "max_expires_publish", 50)
modparam("presence", "max_expires_subscribe", 20)
modparam("presence", "expires_offset", 5)
modparam("presence", "fallback2db", 1)
------------

I attach a capture. Note in line 376 how the "Subscription-State" has a "cool" value:

  Subscription-State: active;expires=4294967285  <---- !!!!!!!!!!!!!

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

>Comment By: I?aki Baz Castillo (ibc_sf)
Date: 2009-05-08 15:50

Message:
Here there is a sequence of "Subscription-State" header value in NOTIFY's
generated by presence module. There are just two subscribers, one of them
uses "expires=600" and the other "expires=3600". "max_expire_subscribe" is
set to 3600 in OpenSIPS presence module.

Subscription-State: active;expires=658
Subscription-State: active;expires=484
Subscription-State: active;expires=658
Subscription-State: active;expires=484
Subscription-State: active;expires=657
Subscription-State: active;expires=657
Subscription-State: active;expires=483
Subscription-State: active;expires=483
Subscription-State: active;expires=437
Subscription-State: active;expires=263
Subscription-State: active;expires=437
Subscription-State: active;expires=263
Subscription-State: active;expires=399
Subscription-State: active;expires=225
Subscription-State: active;expires=399
Subscription-State: active;expires=225
Subscription-State: active;expires=3600
Subscription-State: active;expires=3600
Subscription-State: active;expires=3600
Subscription-State: active;expires=3600
Subscription-State: active;expires=3600
Subscription-State: active;expires=3600
Subscription-State: active;expires=3600
Subscription-State: active;expires=3600
Subscription-State: active;expires=600
Subscription-State: active;expires=600
Subscription-State: active;expires=138
Subscription-State: active;expires=138
Subscription-State: active;expires=4294967260   <--- !!!
Subscription-State: active;expires=4294967260   <--- !!!
Subscription-State: active;expires=150
Subscription-State: active;expires=150
Subscription-State: active;expires=3600
Subscription-State: active;expires=3600
Subscription-State: active;expires=3600
Subscription-State: active;expires=3600
Subscription-State: active;expires=4294967279   <--- !!!
Subscription-State: active;expires=4294967279   <--- !!!
[...]

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

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


From genady.belenky at hp.com  Fri May  8 17:20:22 2009
From: genady.belenky at hp.com (genabel)
Date: Fri, 8 May 2009 08:20:22 -0700 (PDT)
Subject: [OpenSIPS-Devel] Presence and non integrated xcap server. Did
 somebody managed to get it working?
Message-ID: <1241796022506-2845885.post@n2.nabble.com>


Hi,

I'm trying to get the presence server (opensips 1.5.1) working together with
a non integrated xcap server. Currently I'm using openxcap for the demo
solution, but later I will use a commecial xcap server. In the demo solution
scenario openxcap has it's own database schema and tables and clearly
separated from the opensips data.

The first use case is presence authorization rules related. Getting a
watcher-info notification, the presence server should issue an xcap request
towards the xcap server and use the information for the authorization
decision. I created the corresponding document in openxcap and tested it
with xcapclient.

To make the life easier (tracing), I decided to use HTTP instead of HTTPS in
openxcap.  

As a client I'm using X-Lite. Both servers - opensips presence and openxcap
are running on the same virtual machine (Ubuntu).

I have the following setting in my opensips.cfg :

modparam("presence|presence_xml", "db_url",
"mysql://user:password at localhost/opensips")
modparam("presence_xml", "force_active", 0)
modparam("presence_xml", "pidf_manipulation", 1)
modparam("presence_xml", "integrated_xcap_server", 0)
modparam("presence_xml", "xcap_server", "myserver.local:8081")
modparam("presence", "server_address", "sip:XXX.XXX.XXX.XXX:5060")
modparam("presence", "fallback2db", 1)

My openxcap is configured like that :

[Server]
address = 0.0.0.0
port = 8081
root = http://myserver.local
backend = Database
document_validation = Yes


[Logging]

[Authentication]
type = basic
cleartext_passwords = Yes
default_realm = myserver.local
trusted_peers = XXX.XXX.XXX.XXX

[TLS]
certificate = tls/server.crt
private_key = tls/server.key

[Database]
authentication_db_uri = mysql://openxcap:openxcap at localhost/openxcap
storage_db_uri = mysql://openxcap:openxcap at localhost/openxcap
subscriber_table = subscriber
xcap_table = xcap

In this configuration I'm getting  "ERROR:xcap_client:send_http_get: Error
[22] while performing curl operation" as far as the presence server is
trying to send an xcap request to openxcap.

I also noticed that even I configured my presence server as a trusted peer
in the openxcap config file, I need to provide the user credentials in case
I want to access this URL in firefox or curl. 

Can it be the reason fot the error - missing xcap credentials configuration
or maybe I should use https?
And what is this curl related error message? 

I'm wondering if someone got a similar environment runnig. Any debugging
hints will be appreciated.

Hope you can help me,
Best regards,
Genady 

-- 
View this message in context: http://n2.nabble.com/Presence-and-non-integrated-xcap-server.-Did-somebody-managed-to-get-it-working--tp2845885p2845885.html
Sent from the OpenSIPS - Devel mailing list archive at Nabble.com.



From noreply at sourceforge.net  Fri May  8 19:17:54 2009
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 08 May 2009 17:17:54 +0000
Subject: [OpenSIPS-Devel] [ opensips-Patches-2789126 ] extend tm uac
	functions to support tmcb release function
Message-ID: <E1M2Thq-0007H8-5M@d45xhf1.ch3.sourceforge.com>

Patches item #2789126, was opened at 2009-05-08 13:17
Message generated for change (Tracker Item Submitted) made by john_riordan
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086412&aid=2789126&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: John Riordan (john_riordan)
Assigned to: Nobody/Anonymous (nobody)
Summary: extend tm uac functions to support tmcb release function

Initial Comment:
Currently there does not appear to be a reliable way to cleanup callback parameters passed to the tm uac functions - t_request, t_request_within, etc.. This patch extends the tm uac functions to support the tmcb release function for tm callback parameter cleanup. This is based on work done earlier which added the infrastructure necessary to do proper cleanup and here we are extending the existing uac functions to use that earlier work done in...
                                                                                                                                                                                                                                                                              
    Author: dan_pascu <dan_pascu at 689a6050-402a-0410-94f2-e92a70836424>                                                                 
    Date:   Thu Nov 20 18:55:23 2008 +0000                                                                                             
                                                                                                                                       
        Added infrastructure for tm callback parameter cleanup. Fixed memory corruption caused by invalid freeing of dialogs           
                                                                                                                                       
        git-svn-id: https://opensips.svn.sourceforge.net/svnroot/opensips/trunk at 4992 689a6050-402a-0410-94f2-e92a70836424              

Currently, callback parameters cannot be reliably cleaned up. For example, when using t_request to send an INVITE and the uas responds with a 200 but then the ACK(s) gets lost and the uas continues sending 200s the callback is called repeatedly with an indication that the request was completed so one is faced with either not freeing the callback parameters (leaking memory) or freeing them repeatedly (ah, umm).

Regardless, proper cleanup can best be done by utilizing the release function infrastructure.


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

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


From bogdan at voice-system.ro  Sat May  9 09:10:00 2009
From: bogdan at voice-system.ro (Bogdan-Andrei Iancu)
Date: Sat, 09 May 2009 07:10:00 +0000
Subject: [OpenSIPS-Devel] SF.net SVN: opensips:[5679]
	trunk/modules/cpl-c/cpl_sig.c
Message-ID: <E1M2gh6-00078j-4q@dn4whf1.ch3.sourceforge.com>

Revision: 5679
          http://opensips.svn.sourceforge.net/opensips/?rev=5679&view=rev
Author:   bogdan_iancu
Date:     2009-05-09 07:09:59 +0000 (Sat, 09 May 2009)

Log Message:
-----------
- fixed branch flags reseting when creating a new branch - related to the previous fix on this topic

  Credits go to John Riordan - thanks for pointing out that my changes in the previous patch were bogus.
  Closes patch #2785741.

Modified Paths:
--------------
    trunk/modules/cpl-c/cpl_sig.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  Sat May  9 09:10:48 2009
From: bogdan at voice-system.ro (Bogdan-Andrei Iancu)
Date: Sat, 09 May 2009 07:10:48 +0000
Subject: [OpenSIPS-Devel] SF.net SVN: opensips:[5680]
	branches/1.5/modules/cpl-c/cpl_sig.c
Message-ID: <E1M2ghs-00079q-9V@dn4whf1.ch3.sourceforge.com>

Revision: 5680
          http://opensips.svn.sourceforge.net/opensips/?rev=5680&view=rev
Author:   bogdan_iancu
Date:     2009-05-09 07:10:48 +0000 (Sat, 09 May 2009)

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

- fixed branch flags reseting when creating a new branch - related to the previo
us fix on this topic

  Credits go to John Riordan - thanks for pointing out that my changes in the pr
evious patch were bogus.
  Closes patch #2785741

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

Modified Paths:
--------------
    branches/1.5/modules/cpl-c/cpl_sig.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  Sat May  9 09:12:20 2009
From: bogdan at voice-system.ro (Bogdan-Andrei Iancu)
Date: Sat, 09 May 2009 07:12:20 +0000
Subject: [OpenSIPS-Devel] SF.net SVN: opensips:[5681]
	branches/1.4/modules/cpl-c/cpl_sig.c
Message-ID: <E1M2gjM-0007CI-DM@dn4whf1.ch3.sourceforge.com>

Revision: 5681
          http://opensips.svn.sourceforge.net/opensips/?rev=5681&view=rev
Author:   bogdan_iancu
Date:     2009-05-09 07:12:20 +0000 (Sat, 09 May 2009)

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

- fixed branch flags reseting when creating a new branch - related to the previo
us fix on this topic

  Credits go to John Riordan - thanks for pointing out that my changes in the pr
evious patch were bogus.
  Closes patch #2785741

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

Modified Paths:
--------------
    branches/1.4/modules/cpl-c/cpl_sig.c


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


From noreply at sourceforge.net  Sat May  9 09:13:19 2009
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat, 09 May 2009 07:13:19 +0000
Subject: [OpenSIPS-Devel] [ opensips-Patches-2788192 ] fix: cpl - branch
	flags not getting initialized correctly
Message-ID: <E1M2gkJ-0006Ku-W8@665xhf1.ch3.sourceforge.com>

Patches item #2788192, was opened at 2009-05-07 06:38
Message generated for change (Comment added) made by bogdan_iancu
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086412&aid=2788192&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: Closed
>Resolution: Accepted
Priority: 5
Private: No
Submitted By: John Riordan (john_riordan)
>Assigned to: Bogdan-Andrei Iancu (bogdan_iancu)
Summary: fix: cpl - branch flags not getting initialized correctly

Initial Comment:
Hey Bogdan, 

This is #2785741 again. 

I just updated and it looks like my fix may have been lost in translation. The change which got implemented only partially fixes the problem I'm trying to solve.

Please bare with me while I attempt to explain the issue better. As I understand it (little that I do), the cpl proxy code implements sequential "ordering" by first creating a list of locations (location set). It then removes the first location from the head of the list, attempts to relay it, and then repeats until there are no more locations left in the list (or a positive final response). If additional branch flags are set while processing the first location (in the script branch_route for example), they are not getting cleared when the second location begins to be processed (as branch 0 again). The fix you implemented now initializes the nat branch flag correctly, but doesn't clear other flags that may have been set and these unexpectedly get carried over into for the next location processed. The patch attached completely clears the branch flags each time branch 0 is reused during this process. Note that an example of the correct behavior is implemented in the existing code a few lines down in the loop that add additional branches for parallel processing.

Cheers,

John


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

>Comment By: Bogdan-Andrei Iancu (bogdan_iancu)
Date: 2009-05-09 10:13

Message:
Hi John,

You are right - I overlooked this aspect. Thank you for point this out. I
applied the patch in the original form :)

Thanks and regards,
Bogdan

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

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


From bogdan at voice-system.ro  Sat May  9 09:18:56 2009
From: bogdan at voice-system.ro (Bogdan-Andrei Iancu)
Date: Sat, 09 May 2009 07:18:56 +0000
Subject: [OpenSIPS-Devel] SF.net SVN: opensips:[5682]
	trunk/modules/cpl-c/cpl_proxy.h
Message-ID: <E1M2gpk-0007Jg-Ik@dn4whf1.ch3.sourceforge.com>

Revision: 5682
          http://opensips.svn.sourceforge.net/opensips/?rev=5682&view=rev
Author:   bogdan_iancu
Date:     2009-05-09 07:18:56 +0000 (Sat, 09 May 2009)

Log Message:
-----------
- fixed missing 100 Trying when the transaction is internally created by the CPL interpreter.

  Credits go to John Riordan.
  Closes patch #2788216

Modified Paths:
--------------
    trunk/modules/cpl-c/cpl_proxy.h


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


From noreply at sourceforge.net  Sat May  9 09:19:57 2009
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat, 09 May 2009 07:19:57 +0000
Subject: [OpenSIPS-Devel] [ opensips-Patches-2788216 ] cpl: 100 trying
	provisional reply not generated
Message-ID: <E1M2gqj-0003v2-UM@d45xhf1.ch3.sourceforge.com>

Patches item #2788216, was opened at 2009-05-07 08:41
Message generated for change (Comment added) made by bogdan_iancu
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086412&aid=2788216&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: Closed
>Resolution: Accepted
Priority: 5
Private: No
Submitted By: John Riordan (john_riordan)
>Assigned to: Bogdan-Andrei Iancu (bogdan_iancu)
Summary: cpl: 100 trying provisional reply not generated

Initial Comment:
cpl is not generating a 100 trying provisional reply when building the transaction. It seems like sending a provisional response should be the default behavior. Currently, unless a stateless 100 reply is pushed from the script prior to calling cpl the UAC tends to be left wanting and waiting when cpl initiates a transaction.

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

>Comment By: Bogdan-Andrei Iancu (bogdan_iancu)
Date: 2009-05-09 10:19

Message:
Hi John,

Indeed it is a more sane approach instead of relying on a 100 Trying from
script. I uploaded your patch on SVN.

Thanks and regards,
Bogdan

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

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


From noreply at sourceforge.net  Sat May  9 09:28:58 2009
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat, 09 May 2009 07:28:58 +0000
Subject: [OpenSIPS-Devel] [ opensips-Patches-2789126 ] extend tm uac
	functions to support tmcb release function
Message-ID: <E1M2gzS-0007Kx-T5@665xhf1.ch3.sourceforge.com>

Patches item #2789126, was opened at 2009-05-08 20:17
Message generated for change (Comment added) made by bogdan_iancu
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086412&aid=2789126&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: John Riordan (john_riordan)
>Assigned to: Bogdan-Andrei Iancu (bogdan_iancu)
Summary: extend tm uac functions to support tmcb release function

Initial Comment:
Currently there does not appear to be a reliable way to cleanup callback parameters passed to the tm uac functions - t_request, t_request_within, etc.. This patch extends the tm uac functions to support the tmcb release function for tm callback parameter cleanup. This is based on work done earlier which added the infrastructure necessary to do proper cleanup and here we are extending the existing uac functions to use that earlier work done in...
                                                                                                                                                                                                                                                                              
    Author: dan_pascu <dan_pascu at 689a6050-402a-0410-94f2-e92a70836424>                                                                 
    Date:   Thu Nov 20 18:55:23 2008 +0000                                                                                             
                                                                                                                                       
        Added infrastructure for tm callback parameter cleanup. Fixed memory corruption caused by invalid freeing of dialogs           
                                                                                                                                       
        git-svn-id: https://opensips.svn.sourceforge.net/svnroot/opensips/trunk at 4992 689a6050-402a-0410-94f2-e92a70836424              

Currently, callback parameters cannot be reliably cleaned up. For example, when using t_request to send an INVITE and the uas responds with a 200 but then the ACK(s) gets lost and the uas continues sending 200s the callback is called repeatedly with an indication that the request was completed so one is faced with either not freeing the callback parameters (leaking memory) or freeing them repeatedly (ah, umm).

Regardless, proper cleanup can best be done by utilizing the release function infrastructure.


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

>Comment By: Bogdan-Andrei Iancu (bogdan_iancu)
Date: 2009-05-09 10:28

Message:
Hi John,

I'm not 100% sure this is needed.
Currently all local UAC transaction do trigger a TMCB_LOCAL_COMPLETED
callback when the transaction is completed. So you can use this callback to
cleanup whatever params you attached to the transaction.
In regards to the multiple 200 OK (retransmissions), the registered
callback function should first check if the received param is NULL and if
so, to exit. If not NULL,  it should free it and set it to NULL to avoid
sequential executions.
As an example, see in the CPL module, the cpl_proxy.h , reply_callback()
function, how the param (inter var) is freed.

Regards,
Bogdan 

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

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


From bogdan at voice-system.ro  Sat May  9 09:37:24 2009
From: bogdan at voice-system.ro (Bogdan-Andrei Iancu)
Date: Sat, 09 May 2009 07:37:24 +0000
Subject: [OpenSIPS-Devel] SF.net SVN: opensips:[5684] trunk/daemonize.c
Message-ID: <E1M2h7c-0007eS-Ll@dn4whf1.ch3.sourceforge.com>

Revision: 5684
          http://opensips.svn.sourceforge.net/opensips/?rev=5684&view=rev
Author:   bogdan_iancu
Date:     2009-05-09 07:37:24 +0000 (Sat, 09 May 2009)

Log Message:
-----------
-typo fixed "pif"->"pid"
 Part for patch #2731979, contributed by "ledda".

Modified Paths:
--------------
    trunk/daemonize.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  Sat May  9 09:38:11 2009
From: bogdan at voice-system.ro (Bogdan-Andrei Iancu)
Date: Sat, 09 May 2009 07:38:11 +0000
Subject: [OpenSIPS-Devel] SF.net SVN: opensips:[5685]
	branches/1.5/daemonize.c
Message-ID: <E1M2h8N-0007fF-UR@dn4whf1.ch3.sourceforge.com>

Revision: 5685
          http://opensips.svn.sourceforge.net/opensips/?rev=5685&view=rev
Author:   bogdan_iancu
Date:     2009-05-09 07:38:11 +0000 (Sat, 09 May 2009)

Log Message:
-----------
- typo fixed "pif" -> "pid"

Modified Paths:
--------------
    branches/1.5/daemonize.c


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


From j-doedel at zonnet.nl  Sat May  9 09:52:23 2009
From: j-doedel at zonnet.nl (Jan D.)
Date: Sat, 9 May 2009 00:52:23 -0700 (PDT)
Subject: [OpenSIPS-Devel] expired registrations stay in the mysql location
 table
Message-ID: <1241855543708-2849261.post@n2.nabble.com>


Since the update from opensips 1.5.0 to 1.5.1 sometimes expired registrations
are still visible in the mysql location table.

It also happens there are multiple registrations from one user in the
location table.

A restart of opensips solves the problem, after some time the problems
starts again.

Is this a known problem / bug?

Jan

opensips -V
version: opensips 1.5.1-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: unknown
@(#) $Id: main.c 5469 2009-03-18 12:43:10Z bogdan_iancu $
main.c compiled on 17:23:47 Apr 13 2009 with gcc 4.3.3
-- 
View this message in context: http://n2.nabble.com/expired-registrations-stay-in-the-mysql-location-table-tp2849261p2849261.html
Sent from the OpenSIPS - Devel mailing list archive at Nabble.com.



From bogdan at voice-system.ro  Sat May  9 09:56:29 2009
From: bogdan at voice-system.ro (Bogdan-Andrei Iancu)
Date: Sat, 09 May 2009 07:56:29 +0000
Subject: [OpenSIPS-Devel] SF.net SVN: opensips:[5686] trunk/scripts
Message-ID: <E1M2hQ5-0007yv-II@dn4whf1.ch3.sourceforge.com>

Revision: 5686
          http://opensips.svn.sourceforge.net/opensips/?rev=5686&view=rev
Author:   bogdan_iancu
Date:     2009-05-09 07:56:25 +0000 (Sat, 09 May 2009)

Log Message:
-----------
- fixed start command - if bogus PID file is found, simplt purge it
- fixed restart command - do stop but do not exit if stop failed during a restart

  Credits go to ledda.
  Closes patch #2731979

Modified Paths:
--------------
    trunk/scripts/opensipsctl
    trunk/scripts/osipsconsole


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


From noreply at sourceforge.net  Sat May  9 09:56:55 2009
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat, 09 May 2009 07:56:55 +0000
Subject: [OpenSIPS-Devel] [ opensips-Patches-2731979 ] opensipsctl can't
	start proxy after crash
Message-ID: <E1M2hQV-0007mC-TM@d55xhf1.ch3.sourceforge.com>

Patches item #2731979, was opened at 2009-04-04 22:49
Message generated for change (Comment added) made by bogdan_iancu
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086412&aid=2731979&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: tools
Group: trunk
Status: Open
>Resolution: Accepted
Priority: 5
Private: No
Submitted By: ledda (ledda)
>Assigned to: Bogdan-Andrei Iancu (bogdan_iancu)
Summary: opensipsctl can't start proxy after crash

Initial Comment:
The way how opensipsctl was checking PID file doesn't allow to start OpenSIPS after crash or hard reboot.

This patch check if there is a process running with the PID specified in pid file. If not, it removes pid file and start opensips.

Also 'restart' feature was broken. It doesn't stop opensips - there was such comment in the code by it doesn't make sense to me. 
So I've updated 'restart' command to do 'stop' and 'start'.

Also it fixes small typo in  daemonize.c.

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

>Comment By: Bogdan-Andrei Iancu (bogdan_iancu)
Date: 2009-05-09 10:56

Message:
Hi ledda,

Thanks for the patch - I applied it in a modified version. Please test the
SVN trunk version and let me know if everything is ok. If so, I will
backport the fix to 1.5 version also.

Regards,
Bogdan


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

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


From noreply at sourceforge.net  Sat May  9 10:06:05 2009
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat, 09 May 2009 08:06:05 +0000
Subject: [OpenSIPS-Devel] [ opensips-Patches-2714507 ] Adding qvalue to
	lookup function
Message-ID: <E1M2hZN-0003BB-PI@cdv4jf1.ch3.sourceforge.com>

Patches item #2714507, was opened at 2009-03-26 15:38
Message generated for change (Comment added) made by bogdan_iancu
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086412&aid=2714507&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: 1.4.x
Status: Open
>Resolution: Invalid
Priority: 5
Private: No
Submitted By: Davi' Mauro (mdavi)
Assigned to: Bogdan-Andrei Iancu (bogdan_iancu)
Summary: Adding qvalue to lookup function

Initial Comment:
This patch is applicable to the registrar module for opensips version 1.4.5.

The append_branch function have a parameter in which I can set the qvalue, 
but I cannot set the qvalue of the first RURI branch (i.e. the message itself). 

So I add a parameter to the lookup function (registrar module). In this way I can set qvalue properly. 
The lookup function qvalue parameter can set also using script variable.

Regards,
     MD



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

>Comment By: Bogdan-Andrei Iancu (bogdan_iancu)
Date: 2009-05-09 11:06

Message:
Hi Mauro,

I'm a bit confused - If I understand correctly you want to have the
possibility to set the q value of the RURI branch, right ?
If so, why is the lookup() function changed? the lookup() function do load
the q values as stored in the user location (as registered) and you should
not override this.

Regards,
Bogdan

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

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


From noreply at sourceforge.net  Sat May  9 10:15:27 2009
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat, 09 May 2009 08:15:27 +0000
Subject: [OpenSIPS-Devel] [ opensips-Patches-2706135 ] Change to listen=
	syntax to support per-interface advertised
Message-ID: <E1M2hiR-0003or-Lx@cdv4jf1.ch3.sourceforge.com>

Patches item #2706135, was opened at 2009-03-23 15:50
Message generated for change (Comment added) made by bogdan_iancu
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086412&aid=2706135&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: Phil D'Amore (ptdamore)
>Assigned to: Bogdan-Andrei Iancu (bogdan_iancu)
Summary: Change to listen= syntax to support per-interface advertised

Initial Comment:
[This is the patch for an idea I posted several weeks ago to the devel list.
Below is the original list posting as an explanation.]

The patch extends the idea of the advertised_address and advertised_port
parameters so that it is possible to bind such an address to each
listen= statement.

Syntax-wise, it works like this:

  listen=[proto:]host[:port][ AS host[:port]]

This new AS host[:port] syntax binds the advertised address specifically to the
corresponding socket_info structure.  If such an address is specified, it will
be used before the address specified as advertised_address, or set in the
set_advertised_address function for packets being sent on that particular
socket.  If it is not specified, then the old methods work as before.

The core has been modified so that address tuples using the advertised address
work interchangeably with the real address where you'd expect them to.
grep_sock_info and find_si have been updated to allow this.  Therefore, it is
not necessary to explicitly name your advertised address on an alias= line.
The following are now equivalent:

  force_send_socket(udp:adv_address:adv_port);
  force_send_socket(udp:real_address:real_port);

Note we don't specify protocol on the advertised address.  The way I see
things, it makes no sense to advertise a different protocol, so it inherits the
protocol of the socket.

Via construction is affected in the same way that the old global
advertised_address does, except the Via is written specifically for
the socket used
to send the message.

Lump substitution is also affected.  The following lump substitutions are aware
of this new facility:

 SUBST_RCV_IP
 SUBST_RCV_PORT
 SUBST_RCV_ALL
 SUBST_SND_IP
 SUBST_SND_PORT
 SUBST_SND_ALL

As a result of this, I was able to stop using record_route_preset in
my own config, and
just use standard record_route.  This winds up working much better,
because double-rr
works properly, and add_rr_param now works as expected for me, where it was a
problem using record_route_preset.

Additionally, registrar and usrloc had to be modified:

registrar - update the add_sock_hdr function to put the advertised address in
the message instead of the real address.  This allows registration information
to be replicated between multi-homed proxies, and the correct interface on the
peer can be used.

usrloc - update db_insert_ucontact to store the advertised address in the
database instead of the real address.  Same reasoning as the mods to registrar.

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

>Comment By: Bogdan-Andrei Iancu (bogdan_iancu)
Date: 2009-05-09 11:15

Message:
Hi Phil,

I will start reviewing the patch in order to upload it on SVN. If I have
some questions about it, I will post them here.

Thanks and regards,
Bogdan

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

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


From noreply at sourceforge.net  Sat May  9 10:27:49 2009
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat, 09 May 2009 08:27:49 +0000
Subject: [OpenSIPS-Devel] [ opensips-Bugs-2788957 ] dialog entry purge and
	dialog timeout bug
Message-ID: <E1M2huP-0002qf-HZ@665xhf1.ch3.sourceforge.com>

Bugs item #2788957, was opened at 2009-05-08 15:36
Message generated for change (Comment added) made by bogdan_iancu
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=2788957&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: Nobody/Anonymous (nobody)
>Assigned to: Bogdan-Andrei Iancu (bogdan_iancu)
Summary: dialog entry purge and dialog timeout bug

Initial Comment:
Hello all,
In OpenSIPs 1.4.5, dialog appeared in "opensipsctl fifo dlg_list" only if setflag was called on "modparam("dialog", "dlg_flag", 4)" that I triggered it only on an INVITE.
And everything looks fine, dialog was terminated receiving a BYE packet.

In OpenSIPS 1.5.1, all dialogs are visible in "opensipsctl fifo dlg_list", even without calling setflag(4) and furthermore, all my REGISTER transactions are not purged from memory after 200OK and the timeout parameter of these transaction increase with OpenSIPs uptime.

For example, I have put a default timeout of 10800s, my first REGISTER will get a timeout of 10807s, and another 60s later has a timeout of 10867s.

I'm trying to see where is the problem. I will keep you inform if I find something!

I used:
opensips -V
version: opensips 1.5.1-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: unknown
@(#) $Id: main.c 5469 2009-03-18 12:43:10Z bogdan_iancu $
main.c compiled on 19:03:00 Apr 30 2009 with gcc 4.1.2


PS: I put some other outputs in OpenSIPs user mailing list

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

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

Message:
Hi Marc,

regarding the first issue, with seeing all the dialogs - do you use
mediaproxy with engage_mediaproxy() ? because it forces dialog creation in
order to keep track of the dialog changes.

Regards,
Bogdan

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

Comment By: Marc LEURENT (lftsy)
Date: 2009-05-08 15:38

Message:
Sorry, I have posted this anonymously, Here is a comment...
Best Regards,
Marc Leurent

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

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


From noreply at sourceforge.net  Sat May  9 10:41:40 2009
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat, 09 May 2009 08:41:40 +0000
Subject: [OpenSIPS-Devel] [ opensips-Bugs-2788957 ] dialog entry purge and
	dialog timeout bug
Message-ID: <E1M2i7o-0005WC-D7@cdv4jf1.ch3.sourceforge.com>

Bugs item #2788957, was opened at 2009-05-08 14:36
Message generated for change (Comment added) made by lftsy
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=2788957&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: Nobody/Anonymous (nobody)
Assigned to: Bogdan-Andrei Iancu (bogdan_iancu)
Summary: dialog entry purge and dialog timeout bug

Initial Comment:
Hello all,
In OpenSIPs 1.4.5, dialog appeared in "opensipsctl fifo dlg_list" only if setflag was called on "modparam("dialog", "dlg_flag", 4)" that I triggered it only on an INVITE.
And everything looks fine, dialog was terminated receiving a BYE packet.

In OpenSIPS 1.5.1, all dialogs are visible in "opensipsctl fifo dlg_list", even without calling setflag(4) and furthermore, all my REGISTER transactions are not purged from memory after 200OK and the timeout parameter of these transaction increase with OpenSIPs uptime.

For example, I have put a default timeout of 10800s, my first REGISTER will get a timeout of 10807s, and another 60s later has a timeout of 10867s.

I'm trying to see where is the problem. I will keep you inform if I find something!

I used:
opensips -V
version: opensips 1.5.1-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: unknown
@(#) $Id: main.c 5469 2009-03-18 12:43:10Z bogdan_iancu $
main.c compiled on 19:03:00 Apr 30 2009 with gcc 4.1.2


PS: I put some other outputs in OpenSIPs user mailing list

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

Comment By: Marc LEURENT (lftsy)
Date: 2009-05-09 10:41

Message:
Hello Bogdan,
no I'm not using Mediaproxy. I use nathelper module to deal with NATed
users.
The only strange thing, is that I'm forwarding REGISTER to loadbalanced
(with dispatcher module) Asterisks, but I?intercept REGISTER to be able to
ping all NATed users from the proxy.
Everything works fine with OpenSIPs 1.4.x


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

Comment By: Bogdan-Andrei Iancu (bogdan_iancu)
Date: 2009-05-09 10:27

Message:
Hi Marc,

regarding the first issue, with seeing all the dialogs - do you use
mediaproxy with engage_mediaproxy() ? because it forces dialog creation in
order to keep track of the dialog changes.

Regards,
Bogdan

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

Comment By: Marc LEURENT (lftsy)
Date: 2009-05-08 14:38

Message:
Sorry, I have posted this anonymously, Here is a comment...
Best Regards,
Marc Leurent

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

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


From noreply at sourceforge.net  Sat May  9 10:46:32 2009
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat, 09 May 2009 08:46:32 +0000
Subject: [OpenSIPS-Devel] [ opensips-Bugs-2787094 ] Crash with db_postgresql
	and no db connection
Message-ID: <E1M2iCW-0004g0-Nv@1bkjzd1.ch3.sourceforge.com>

Bugs item #2787094, was opened at 2009-05-05 11:45
Message generated for change (Comment added) made by bogdan_iancu
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=2787094&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: Nobody/Anonymous (nobody)
Assigned to: Bogdan-Andrei Iancu (bogdan_iancu)
Summary: Crash with db_postgresql and no db connection

Initial Comment:
Opensips with usrloc and db_postgresql will crash if the db server is unreachable.


Scenario is the following, I have a remote postgres DB server, and had not opened the PG port on the firewall, which causes opensips to be unable to reach the DB server.
on init, opensips times out trying to connect to the DB, and then crash, looking at the logs, it seems to be usrloc module related.

It's easy to reproduce, I can provide as many tracks as needed.

If you need me bogdan, ask on irc ( Gled ).

bt:
#0  0x0000000000425f36 in handle_sigs () at main.c:486
486                                             if (pt[i].pid==chld) break;

#0  0x0000000000425f36 in handle_sigs () at main.c:486
#1  <signal handler called>
#2  0x00000030e6ae0cb7 in munmap () from /lib64/libc.so.6
#3  0x00000000004a4804 in shm_mem_destroy () at mem/shm_mem.c:238
#4  0x00000000004259a6 in cleanup (show_status=0) at main.c:365
#5  0x0000000000428560 in main (argc=<value optimized out>, argv=0x20) at main.c:1324

bt full:
#0  0x0000000000425f36 in handle_sigs () at main.c:486
        chld = 1909
        chld_status = 0
        i = <value optimized out>
        do_exit = 0
        __FUNCTION__ = "handle_sigs"
#1  <signal handler called>
No symbol table info available.
#2  0x00000030e6ae0cb7 in munmap () from /lib64/libc.so.6
No symbol table info available.
#3  0x00000000004a4804 in shm_mem_destroy () at mem/shm_mem.c:238
        __FUNCTION__ = "shm_mem_destroy"
#4  0x00000000004259a6 in cleanup (show_status=0) at main.c:365
No locals.
#5  0x0000000000428560 in main (argc=<value optimized out>, argv=0x20) at main.c:1324
        cfg_log_stderr = 1906
        cfg_stream = (FILE *) 0x772
        c = <value optimized out>
        r = 1
        tmp = 0x4ffe65 "H\205?t\0341?\017\037@"
        tmp_len = <value optimized out>
        port = <value optimized out>
        proto = <value optimized out>
        ret = -1
        seed = 2320449269
        rfd = <value optimized out>
        __FUNCTION__ = "main"


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

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

Message:
Hi Gled,

I tried to reproduce this bug by configuring the usrloc module to use a
postgres DB. I put the URL to point to a bogus IP as I have no postgres
server and because actually the scenario is about unreachable DB
server....

But I got :
May  9 11:27:07 [2171] DBG:db_postgres:db_postgres_new_connection:
PQsetdbLogin(0x82b9770)
May  9 11:27:07 [2171] ERROR:db_postgres:db_postgres_new_connection: could
not connect to server: Connection timed out
        Is the server running on host "192.168.1.254" and accepting
        TCP/IP connections on port 5432?

May  9 11:27:07 [2171] ERROR:db_postgres:db_postgres_new_connection:
cleaning up 0x81b1998=pkg_free()

and a normal shutdown...

Regards,
Bogdan


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

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


From noreply at sourceforge.net  Sat May  9 10:47:47 2009
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat, 09 May 2009 08:47:47 +0000
Subject: [OpenSIPS-Devel] [ opensips-Bugs-2788937 ] presence: Wrong
	Subscription-State "expires" value in NOTIFY
Message-ID: <E1M2iDj-0003EF-Vj@h45xhf1.ch3.sourceforge.com>

Bugs item #2788937, was opened at 2009-05-08 14:57
Message generated for change (Settings changed) made by bogdan_iancu
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=2788937&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: I?aki Baz Castillo (ibc_sf)
>Assigned to: Anca Vamanu (anca_vamanu)
Summary: presence: Wrong Subscription-State "expires" value in NOTIFY

Initial Comment:
OpenSIPS "presence" module is generating really wrong "expires" values in "Subscription-State" header of NOTIFY. This causes the subscriber thinking that the subscription lives for long time (due to the exagerate high value of "expires" parameter) but the fact is that the subscriber dissapears from "active-watchers" table and leaves getting notifications.

I just use (these are really low values for testing, but the issue also occurs with higher values):

------------
modparam("presence", "max_expires_publish", 50)
modparam("presence", "max_expires_subscribe", 20)
modparam("presence", "expires_offset", 5)
modparam("presence", "fallback2db", 1)
------------

I attach a capture. Note in line 376 how the "Subscription-State" has a "cool" value:

  Subscription-State: active;expires=4294967285  <---- !!!!!!!!!!!!!

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

Comment By: I?aki Baz Castillo (ibc_sf)
Date: 2009-05-08 16:50

Message:
Here there is a sequence of "Subscription-State" header value in NOTIFY's
generated by presence module. There are just two subscribers, one of them
uses "expires=600" and the other "expires=3600". "max_expire_subscribe" is
set to 3600 in OpenSIPS presence module.

Subscription-State: active;expires=658
Subscription-State: active;expires=484
Subscription-State: active;expires=658
Subscription-State: active;expires=484
Subscription-State: active;expires=657
Subscription-State: active;expires=657
Subscription-State: active;expires=483
Subscription-State: active;expires=483
Subscription-State: active;expires=437
Subscription-State: active;expires=263
Subscription-State: active;expires=437
Subscription-State: active;expires=263
Subscription-State: active;expires=399
Subscription-State: active;expires=225
Subscription-State: active;expires=399
Subscription-State: active;expires=225
Subscription-State: active;expires=3600
Subscription-State: active;expires=3600
Subscription-State: active;expires=3600
Subscription-State: active;expires=3600
Subscription-State: active;expires=3600
Subscription-State: active;expires=3600
Subscription-State: active;expires=3600
Subscription-State: active;expires=3600
Subscription-State: active;expires=600
Subscription-State: active;expires=600
Subscription-State: active;expires=138
Subscription-State: active;expires=138
Subscription-State: active;expires=4294967260   <--- !!!
Subscription-State: active;expires=4294967260   <--- !!!
Subscription-State: active;expires=150
Subscription-State: active;expires=150
Subscription-State: active;expires=3600
Subscription-State: active;expires=3600
Subscription-State: active;expires=3600
Subscription-State: active;expires=3600
Subscription-State: active;expires=4294967279   <--- !!!
Subscription-State: active;expires=4294967279   <--- !!!
[...]

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

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


From bogdan at voice-system.ro  Sat May  9 10:59:18 2009
From: bogdan at voice-system.ro (Bogdan-Andrei Iancu)
Date: Sat, 09 May 2009 11:59:18 +0300
Subject: [OpenSIPS-Devel] [OpenSIPS-Users] Question about dialog max
	timeout...
In-Reply-To: <200905081327.52111.lftsy@leurent.eu>
References: <200905081306.18893.lftsy@leurent.eu>	<200905081320.54265.lftsy@leurent.eu>
	<200905081327.52111.lftsy@leurent.eu>
Message-ID: <4A0545E6.2040208@voice-system.ro>

Hi Marc,

It is normal to increase as it is an absolute timestamp - see my prev 
email on this thread.

Regarding the shm mem - do you see the dialogs actually being removed?

Regards,
Bogdan

Marc Leurent wrote:
> Sorry for the 3rd email.. but I think it's interesting, because the dialog timeout of my transactions seems to increase with OpenSIPs uptime!
> So my shm memory increase all the time. Does any one have the same problem with OpenSIPs 1.5.1?
> Thanks
>
> opensipsctl fifo dlg_list | grep timeout | sort -nr
>         timeout:: 20395
>         timeout:: 20340
>         timeout:: 20285
>         timeout:: 20230
>         timeout:: 20175
>         timeout:: 20120
>         timeout:: 20064
>         timeout:: 20009
>         timeout:: 19954
>         timeout:: 19899
> 	...
>
> and just after
> opensipsctl fifo dlg_list | grep timeout | sort -nr
>         timeout:: 20450
>         timeout:: 20395
>         timeout:: 20340
>         timeout:: 20285
>         timeout:: 20230
>         timeout:: 20175
>         timeout:: 20120
>         timeout:: 20064
>         timeout:: 20009
>         timeout:: 19954
>         timeout:: 19899
> 	...
>
> PS: I'm using
> opensips -V
> version: opensips 1.5.1-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: unknown
> @(#) $Id: main.c 5469 2009-03-18 12:43:10Z bogdan_iancu $
> main.c compiled on 19:03:00 Apr 30 2009 with gcc 4.1.2
>
>
> Le Friday 08 May 2009 13.06:18 Marc Leurent, vous avez ?crit :
>   
>> Hello all, I have juste a small question about the dialog module, I have set the parameters below for OpenSIPs dialog module with a "default_timeout",  to 3 hours,
>>
>> # ----- dialog params -----
>> modparam("dialog", "enable_stats", 1)                           # If the statistics support should be enabled or not.
>> #modparam("dialog", "hash_size", 4096)                          # The size of the hash table internally used to keep the dialogs.
>> modparam("dialog", "rr_param", "did")                           # Name of the Record-Route parameter to be added with the dialog cookie.
>> modparam("dialog", "dlg_flag", 4)                               # Flag to be used for marking if a dialog should be constructed for the current request.
>> #modparam("dialog", "buy_on_timeout_flag", 6)                   # Message falg to be set if you want the dialog module to automatically send BYE requests (in both directions) when the dialog give timeout.
>> #modparam("dialog", "timeout_avp", "$avp(i:10)")                # The specification of an AVP to contain a custom timeout (in seconds) for the dialog.
>> modparam("dialog", "default_timeout", 10800)                    # The default dialog timeout (in seconds) if no custom one is set.
>> #modparam("dialog", "dlg_extra_hdrs", "Hint: credit expired\r\n")       # A string containing the extra headers to be added in the requests generated
>> modparam("dialog", "dlg_match_mode", 0)                         # The match is done exclusively based on DID;
>> modparam("dialog", "db_url", "mysql://opensips:Uwefwefwefo3J at localhost/opensips")
>> modparam("dialog", "db_mode", 1)                                # Describe how to push into the DB the dialogs' information from memory.
>> modparam("dialog", "db_update_period", 30)                      # The interval (seconds) at which to update dialogs' information if you chose to store.
>> #modparam("dialog", "profiles_with_value", "caller ; my_profile")       # List of names for profiles with values.
>> #modparam("dialog", "profiles_no_value", "inbound ; outbound")          # List of names for profiles without values.
>>
>> but I have some dialogs that have a superior timeout like this one..
>> Have you got any idea how to see where this timeout is defined and how to force it to a lower value!
>> Because of this, I reach my "snmpstats", "dlg_minor_threshold", 900 very quickly
>> Thanks!
>>
>> dialog::  hash=1768:1584216798
>>         state:: 3
>>         user_flags:: 0
>>         timestart:: 1241777705
>>         timeout:: 16267
>>         callid:: zaltktgtpqzdqvo at leonhart.interne
>>         from_uri:: sip:0213115090 at 212.147.46.91
>>         from_tag:: ooctt
>>         caller_contact:: sip:0213115090 at 194.38.160.113:5070
>>         caller_cseq:: 960
>>         caller_route_set::
>>         caller_bind_addr:: udp:212.147.46.91:5060
>>         to_uri:: sip:0213115090 at 212.147.46.91
>>         to_tag:: as79ae919b
>>         callee_contact:: sip:0213115090 at 212.147.46.81:5060
>>         callee_cseq:: 960
>>         callee_route_set::
>>         callee_bind_addr:: udp:212.147.46.91:5060
>>
>>
>>     
>
>
>   



From noreply at sourceforge.net  Sat May  9 11:02:27 2009
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat, 09 May 2009 09:02:27 +0000
Subject: [OpenSIPS-Devel] [ opensips-Bugs-2788957 ] dialog entry purge and
	dialog timeout bug
Message-ID: <E1M2iRv-0004TD-HB@565xhf1.ch3.sourceforge.com>

Bugs item #2788957, was opened at 2009-05-08 15:36
Message generated for change (Comment added) made by bogdan_iancu
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=2788957&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: Nobody/Anonymous (nobody)
Assigned to: Bogdan-Andrei Iancu (bogdan_iancu)
Summary: dialog entry purge and dialog timeout bug

Initial Comment:
Hello all,
In OpenSIPs 1.4.5, dialog appeared in "opensipsctl fifo dlg_list" only if setflag was called on "modparam("dialog", "dlg_flag", 4)" that I triggered it only on an INVITE.
And everything looks fine, dialog was terminated receiving a BYE packet.

In OpenSIPS 1.5.1, all dialogs are visible in "opensipsctl fifo dlg_list", even without calling setflag(4) and furthermore, all my REGISTER transactions are not purged from memory after 200OK and the timeout parameter of these transaction increase with OpenSIPs uptime.

For example, I have put a default timeout of 10800s, my first REGISTER will get a timeout of 10807s, and another 60s later has a timeout of 10867s.

I'm trying to see where is the problem. I will keep you inform if I find something!

I used:
opensips -V
version: opensips 1.5.1-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: unknown
@(#) $Id: main.c 5469 2009-03-18 12:43:10Z bogdan_iancu $
main.c compiled on 19:03:00 Apr 30 2009 with gcc 4.1.2


PS: I put some other outputs in OpenSIPs user mailing list

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

>Comment By: Bogdan-Andrei Iancu (bogdan_iancu)
Date: 2009-05-09 12:02

Message:
I see....
Do you use create_dialog() function or any of these modules:
nat_traversal, siptrace, mediaproxy, sst, call_control, pua_dialoginfo,
qos, load_balancer ?

Regards,
Bogdan

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

Comment By: Marc LEURENT (lftsy)
Date: 2009-05-09 11:41

Message:
Hello Bogdan,
no I'm not using Mediaproxy. I use nathelper module to deal with NATed
users.
The only strange thing, is that I'm forwarding REGISTER to loadbalanced
(with dispatcher module) Asterisks, but I?intercept REGISTER to be able to
ping all NATed users from the proxy.
Everything works fine with OpenSIPs 1.4.x


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

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

Message:
Hi Marc,

regarding the first issue, with seeing all the dialogs - do you use
mediaproxy with engage_mediaproxy() ? because it forces dialog creation in
order to keep track of the dialog changes.

Regards,
Bogdan

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

Comment By: Marc LEURENT (lftsy)
Date: 2009-05-08 15:38

Message:
Sorry, I have posted this anonymously, Here is a comment...
Best Regards,
Marc Leurent

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

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


From bogdan at voice-system.ro  Sat May  9 11:03:17 2009
From: bogdan at voice-system.ro (Bogdan-Andrei Iancu)
Date: Sat, 09 May 2009 12:03:17 +0300
Subject: [OpenSIPS-Devel] expired registrations stay in the mysql
 location table
In-Reply-To: <1241855543708-2849261.post@n2.nabble.com>
References: <1241855543708-2849261.post@n2.nabble.com>
Message-ID: <4A0546D5.3050200@voice-system.ro>

Hi Jan,

What db_mode are you using for the usrloc module?

Regards,
Bogdan

Jan D. wrote:
> Since the update from opensips 1.5.0 to 1.5.1 sometimes expired registrations
> are still visible in the mysql location table.
>
> It also happens there are multiple registrations from one user in the
> location table.
>
> A restart of opensips solves the problem, after some time the problems
> starts again.
>
> Is this a known problem / bug?
>
> Jan
>
> opensips -V
> version: opensips 1.5.1-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: unknown
> @(#) $Id: main.c 5469 2009-03-18 12:43:10Z bogdan_iancu $
> main.c compiled on 17:23:47 Apr 13 2009 with gcc 4.3.3
>   



From noreply at sourceforge.net  Sat May  9 11:21:43 2009
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat, 09 May 2009 09:21:43 +0000
Subject: [OpenSIPS-Devel] [ opensips-Bugs-2788957 ] dialog entry purge and
	dialog timeout bug
Message-ID: <E1M2ikZ-0008Gi-QC@3bkjzd1.ch3.sourceforge.com>

Bugs item #2788957, was opened at 2009-05-08 14:36
Message generated for change (Comment added) made by lftsy
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=2788957&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: Nobody/Anonymous (nobody)
Assigned to: Bogdan-Andrei Iancu (bogdan_iancu)
Summary: dialog entry purge and dialog timeout bug

Initial Comment:
Hello all,
In OpenSIPs 1.4.5, dialog appeared in "opensipsctl fifo dlg_list" only if setflag was called on "modparam("dialog", "dlg_flag", 4)" that I triggered it only on an INVITE.
And everything looks fine, dialog was terminated receiving a BYE packet.

In OpenSIPS 1.5.1, all dialogs are visible in "opensipsctl fifo dlg_list", even without calling setflag(4) and furthermore, all my REGISTER transactions are not purged from memory after 200OK and the timeout parameter of these transaction increase with OpenSIPs uptime.

For example, I have put a default timeout of 10800s, my first REGISTER will get a timeout of 10807s, and another 60s later has a timeout of 10867s.

I'm trying to see where is the problem. I will keep you inform if I find something!

I used:
opensips -V
version: opensips 1.5.1-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: unknown
@(#) $Id: main.c 5469 2009-03-18 12:43:10Z bogdan_iancu $
main.c compiled on 19:03:00 Apr 30 2009 with gcc 4.1.2


PS: I put some other outputs in OpenSIPs user mailing list

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

Comment By: Marc LEURENT (lftsy)
Date: 2009-05-09 11:21

Message:
I?do not use any of these modules, I don't have my config here, but I?use
bacic modules: from default opensips,cfg
additionnal modules:?dispatcher, nathelper,db_mysql,domain
 
I use the function create_dialog() only in a if method == INVITE section,
but I?have commented it in OpenSIPs 1.5.1 and I?still have dialogs with
strange timeout, I have posted my dialog parameters in an email yesterday
if you want to see.

I should go an IRC, but I do not have access to my servers from here...
Thank you for your time

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

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

Message:
I see....
Do you use create_dialog() function or any of these modules:
nat_traversal, siptrace, mediaproxy, sst, call_control, pua_dialoginfo,
qos, load_balancer ?

Regards,
Bogdan

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

Comment By: Marc LEURENT (lftsy)
Date: 2009-05-09 10:41

Message:
Hello Bogdan,
no I'm not using Mediaproxy. I use nathelper module to deal with NATed
users.
The only strange thing, is that I'm forwarding REGISTER to loadbalanced
(with dispatcher module) Asterisks, but I?intercept REGISTER to be able to
ping all NATed users from the proxy.
Everything works fine with OpenSIPs 1.4.x


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

Comment By: Bogdan-Andrei Iancu (bogdan_iancu)
Date: 2009-05-09 10:27

Message:
Hi Marc,

regarding the first issue, with seeing all the dialogs - do you use
mediaproxy with engage_mediaproxy() ? because it forces dialog creation in
order to keep track of the dialog changes.

Regards,
Bogdan

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

Comment By: Marc LEURENT (lftsy)
Date: 2009-05-08 14:38

Message:
Sorry, I have posted this anonymously, Here is a comment...
Best Regards,
Marc Leurent

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

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


From j-doedel at zonnet.nl  Sat May  9 11:30:38 2009
From: j-doedel at zonnet.nl (Jan D.)
Date: Sat, 9 May 2009 02:30:38 -0700 (PDT)
Subject: [OpenSIPS-Devel] expired registrations stay in the mysql
 location table
In-Reply-To: <4A0546D5.3050200@voice-system.ro>
References: <1241855543708-2849261.post@n2.nabble.com>
	<4A0546D5.3050200@voice-system.ro>
Message-ID: <1241861438911-2849468.post@n2.nabble.com>


Bogdan,

I'm using 'modparam("usrloc", "db_mode", 1)' and mysql-server version
'5.0.81-1'

Jan
-- 
View this message in context: http://n2.nabble.com/expired-registrations-stay-in-the-mysql-location-table-tp2849261p2849468.html
Sent from the OpenSIPS - Devel mailing list archive at Nabble.com.



From bogdan at voice-system.ro  Sat May  9 11:40:22 2009
From: bogdan at voice-system.ro (Bogdan-Andrei Iancu)
Date: Sat, 09 May 2009 12:40:22 +0300
Subject: [OpenSIPS-Devel] expired registrations stay in the mysql
 location table
In-Reply-To: <1241861438911-2849468.post@n2.nabble.com>
References: <1241855543708-2849261.post@n2.nabble.com>	<4A0546D5.3050200@voice-system.ro>
	<1241861438911-2849468.post@n2.nabble.com>
Message-ID: <4A054F86.5080808@voice-system.ro>

That is real time update of DB - to you see any errors in the logs? 
maybe the DB delete fails for whatever reasons..

Regards,
Bogdan

Jan D. wrote:
> Bogdan,
>
> I'm using 'modparam("usrloc", "db_mode", 1)' and mysql-server version
> '5.0.81-1'
>
> Jan
>   



From bogdan at voice-system.ro  Sat May  9 11:55:01 2009
From: bogdan at voice-system.ro (Bogdan-Andrei Iancu)
Date: Sat, 09 May 2009 09:55:01 +0000
Subject: [OpenSIPS-Devel] SF.net SVN: opensips:[5687]
	trunk/scripts/opensipsctl
Message-ID: <E1M2jGn-0002ie-2A@dn4whf1.ch3.sourceforge.com>

Revision: 5687
          http://opensips.svn.sourceforge.net/opensips/?rev=5687&view=rev
Author:   bogdan_iancu
Date:     2009-05-09 09:55:00 +0000 (Sat, 09 May 2009)

Log Message:
-----------
- fixed syntax error introduced with the prev commit

Modified Paths:
--------------
    trunk/scripts/opensipsctl


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


From sameer.kasi200x at gmail.com  Sun May 10 00:35:24 2009
From: sameer.kasi200x at gmail.com (SAMEER KUMAR)
Date: Sun, 10 May 2009 04:05:24 +0530
Subject: [OpenSIPS-Devel] Important Contribution to OpenSIPS
Message-ID: <4faa72de0905091535p19976e9fg19f1b2968b96ef81@mail.gmail.com>

Dear Mr. Bogdan and OpenSIPS developers and users,

While working in a team of four, I have made some changes in OpenSIPS and
made it capable of providing multithreaded server. I am busy preparing a
user manual and developer manual for it.  Meanwhile, I would like to know
how can i share this change with every one in the developer community.

We were also working on AAA_Authenticaiton. We used WideDiameter Library.
But we are unable to integrate the changes. We will try to complete the
compilation of that module as well if we manage to.

Thankyou every one.


Regards,
Sameer Kumar
B.Tech, Computer Engineering
Institute of Technology,
Nirma University,
Ahmedabad, Gujarat
email: sameer.kasi200x at gmail.com
          05bce032 at nirmauni.ac.in
Phone: +919375220396
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.opensips.org/pipermail/devel/attachments/20090510/e5857767/attachment.htm 

From noreply at sourceforge.net  Sun May 10 05:07:42 2009
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun, 10 May 2009 03:07:42 +0000
Subject: [OpenSIPS-Devel] [ opensips-Patches-2789126 ] extend tm uac
	functions to support tmcb release function
Message-ID: <E1M2zOA-00020O-8s@3bkjzd1.ch3.sourceforge.com>

Patches item #2789126, was opened at 2009-05-08 13:17
Message generated for change (Comment added) made by john_riordan
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086412&aid=2789126&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: John Riordan (john_riordan)
Assigned to: Bogdan-Andrei Iancu (bogdan_iancu)
Summary: extend tm uac functions to support tmcb release function

Initial Comment:
Currently there does not appear to be a reliable way to cleanup callback parameters passed to the tm uac functions - t_request, t_request_within, etc.. This patch extends the tm uac functions to support the tmcb release function for tm callback parameter cleanup. This is based on work done earlier which added the infrastructure necessary to do proper cleanup and here we are extending the existing uac functions to use that earlier work done in...
                                                                                                                                                                                                                                                                              
    Author: dan_pascu <dan_pascu at 689a6050-402a-0410-94f2-e92a70836424>                                                                 
    Date:   Thu Nov 20 18:55:23 2008 +0000                                                                                             
                                                                                                                                       
        Added infrastructure for tm callback parameter cleanup. Fixed memory corruption caused by invalid freeing of dialogs           
                                                                                                                                       
        git-svn-id: https://opensips.svn.sourceforge.net/svnroot/opensips/trunk at 4992 689a6050-402a-0410-94f2-e92a70836424              

Currently, callback parameters cannot be reliably cleaned up. For example, when using t_request to send an INVITE and the uas responds with a 200 but then the ACK(s) gets lost and the uas continues sending 200s the callback is called repeatedly with an indication that the request was completed so one is faced with either not freeing the callback parameters (leaking memory) or freeing them repeatedly (ah, umm).

Regardless, proper cleanup can best be done by utilizing the release function infrastructure.


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

Comment By: John Riordan (john_riordan)
Date: 2009-05-09 23:07

Message:
Hey Bogan,

Well, I'll do my best as passionate patch proponent, but first I want to
mention that I don't have my head anywhere near completely around the tm
module so please forgive me if I end up making statements that turn out to
be patently false. And secondly, this is going to be a ramble and I'm
afraid I don't have the time to edit it, proof read it, or even spell check
it so please forgive me in advance for slaughtering the art of writing.
Here goes...

1) Cleanup on first callback could lead to double free unless lock is used
local_reply() in t_reply.c releases the REPLY_LOCK prior to calling the
running the callbacks for TMCB_LOCAL_COMPLETED. So without locking in the
callback, the series of 200s (from a badly behaving uas for example) could
still trigger a double free from the race condition (ie. proc1 check NULL,
proc 1 free, proc2 check NULL, proc 2 free, proc 1 set param NULL, proc 2
set param NULL). This would obviously be bad. While I know that under
normal circumstances this senario would likely not occur, but it would not
be hard for a determined uas to bring this scenario to life and I'd rather
sleep well knowing that double free simply will not happen.

2) CPL proxy example not a good comparison
The example you referenced (cpl_proxy.h , reply_callback()) doesn't make
for an apples to apples comparision since in that case the callback is
trigger cleanup on TMCB_RESPONSE_OUT which relay_reply() (t_reply.c)
guarantees will only be sent once (sets local var totag_retr inside
REPLY_LOCK and uses it as a test for triggering the callback).

3) Using cleanup callback (release function) makes for a good api
The general approach of using a release function has merit in this case.
When an api is defined so that a callback is called once, the clean up of a
callback parameter is straight forward. But when an api is defined so that
a callback can be registered for multiple events and called repeatedly in
different ways depending on external circumstances, a release function
allows for straight forward clean up by the api consumer. The api consumer
can simply trust the api will do the right thing and call the release
function once whenever callback cleanup needs to be done (transaction ends,
system shutdown, whatever, etc). Furthermore it make it straight forward
for the api maintainer to make future changes and updates to the api
without worrying about who the consumers might be depending on event
sequences for cleanup. 

4) Alternative makes for a bad api
The alternative of defining the api along the lines of "register your
callback and if you are doing such and such you can cleanup when this
happens, but if you are doing this then you should do you cleanup like..."
leads, in my opinion, to confusion and bugs and problems making changes in
the future. It is certainly harder for the api consumer and leads to the
following kind of thing "ok, if my callback can be called multiple times
then I need to figure out when to cleanup ... is the api expecting the
parameter pointer to by constant? ... I could check the source code ... can
multiple processes be running my callback at the same time ... is the api
locking to prevent that? ... I ccould check the source code ... if I do it
this way will the api change in the future so that my approach doesn't
work? ... well I certainly don't want to double free because then that will
cause memory corruption and bring down the whole server and I don't want my
module doing that on people and those kinds of problems are really hard to
track down so I best start reading the source code to see what is is doing
so I don't mess it up ... who this tm module is complicated ... timers and
mutexes ... this sucks ... sigh ... maybe I'll just call free and hope for
the best ... no maybe I just won't free at all and leak memory which at
least won't crash it right away". 
For example, a current comment at the top of uac_cb() in seas_action.c
seas module (a callback passed to t_request_within)...

/ * ...
 * TODO WARNING !!! there's a clear MEMORY LEAK here, see exit: at the
bottom of
 * the function... it should free ev_info !!!!!!!!
 * I have disabled the free() because It may be that we receive a
retransmitted 200 OK
 * if the ACK gets lost, that 200 OK will make SER invoke this callback a
second,third, etc time...
 *
 */

Nice!

5) Trying to make the single callback approch work leads ugly land
Update! It looks like the seas code is now registering for
TMCB_TRANS_DELETED which is an undocumented thing that does appear to do
right thing (based on what can tell by pouring over the source code) and
callback at a desirable time for cleanup (expect during shutdown - maybe a
bug and should it should be moved from free_cell() into empty_tmcb_list()).
Of course the api consumer needs to go trolling through the source code to
ever realize that it exists and then has to wonder if it will exist in the
future because, well, it is undocumented and buried and only appears to be
used by this seas module thing which is, well, ah. umm. And lets see how
using this TMCB_DELETED thing is being done - first call t_request_within
and then when the first TMCB_LOCAL_COMPLETED shows up register for
TMCB_TRANS_DELETED and pass my cb param to that instead of cleaning it up
now... ummm, but wait isn't there a 200s race condition here and we could
end up registering two callbacks? ahh.. and boy isn't this ugly register
one callback and then register another and it still doesn't do...

Sigh.

6) Cleanup callback (release function) plain and simple just works well
Wouldn't it be great if the api just provided the ability to pass in
cleanup callback? Simple and elegant. And if it did, I the api consumer
could just use it and not have to read tm source code for hours and
everything would just work - now and in the future - because I can trust
that the api maintainer will called exactly once and from exactly the right
time/place. (Note that is exactly what the prior commited by dan_pascu did
- the release function infrastructure is already in place and gets called
in empty_tmcb_list() exactly once when the callbacks are getting cleaned
up). And there are no race conditions to worry about and no double frees.
And the api maintainer doesn't have to worry about messing any consumers up
in the future if internals need to change etc. And the api consumers (motly
crew that they are) will not go off doing ugly, dumb, and buggy stuff which
ends up in modules that end users include thinking it will give then this
great new feature they want but just ends up causing random crashes.

So, in conclusion, having the api consumer provide the api with a release
function is a good solution which works well for the api maintainer, the
api consumer, and for the health of the entire project (I'm really spinning
it now!). 

And finally, I do need to sleep at night, so can you please confirm that
at a minimum I will need to lock before I free if I attempt to go the "free
and set to NULL on first LOCAL_COMPLETED" route to make sure I never double
free?

Whew.

Thanks for reading,

John


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

Comment By: Bogdan-Andrei Iancu (bogdan_iancu)
Date: 2009-05-09 03:28

Message:
Hi John,

I'm not 100% sure this is needed.
Currently all local UAC transaction do trigger a TMCB_LOCAL_COMPLETED
callback when the transaction is completed. So you can use this callback to
cleanup whatever params you attached to the transaction.
In regards to the multiple 200 OK (retransmissions), the registered
callback function should first check if the received param is NULL and if
so, to exit. If not NULL,  it should free it and set it to NULL to avoid
sequential executions.
As an example, see in the CPL module, the cpl_proxy.h , reply_callback()
function, how the param (inter var) is freed.

Regards,
Bogdan 

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

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


From noreply at sourceforge.net  Sun May 10 05:10:30 2009
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun, 10 May 2009 03:10:30 +0000
Subject: [OpenSIPS-Devel] [ opensips-Patches-2789126 ] extend tm uac
	functions to support tmcb release function
Message-ID: <E1M2zQs-000613-0W@d45xhf1.ch3.sourceforge.com>

Patches item #2789126, was opened at 2009-05-08 13:17
Message generated for change (Comment added) made by john_riordan
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086412&aid=2789126&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: John Riordan (john_riordan)
Assigned to: Bogdan-Andrei Iancu (bogdan_iancu)
Summary: extend tm uac functions to support tmcb release function

Initial Comment:
Currently there does not appear to be a reliable way to cleanup callback parameters passed to the tm uac functions - t_request, t_request_within, etc.. This patch extends the tm uac functions to support the tmcb release function for tm callback parameter cleanup. This is based on work done earlier which added the infrastructure necessary to do proper cleanup and here we are extending the existing uac functions to use that earlier work done in...
                                                                                                                                                                                                                                                                              
    Author: dan_pascu <dan_pascu at 689a6050-402a-0410-94f2-e92a70836424>                                                                 
    Date:   Thu Nov 20 18:55:23 2008 +0000                                                                                             
                                                                                                                                       
        Added infrastructure for tm callback parameter cleanup. Fixed memory corruption caused by invalid freeing of dialogs           
                                                                                                                                       
        git-svn-id: https://opensips.svn.sourceforge.net/svnroot/opensips/trunk at 4992 689a6050-402a-0410-94f2-e92a70836424              

Currently, callback parameters cannot be reliably cleaned up. For example, when using t_request to send an INVITE and the uas responds with a 200 but then the ACK(s) gets lost and the uas continues sending 200s the callback is called repeatedly with an indication that the request was completed so one is faced with either not freeing the callback parameters (leaking memory) or freeing them repeatedly (ah, umm).

Regardless, proper cleanup can best be done by utilizing the release function infrastructure.


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

Comment By: John Riordan (john_riordan)
Date: 2009-05-09 23:10

Message:
Sincerely sorry about the "Bogan" typo.

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

Comment By: John Riordan (john_riordan)
Date: 2009-05-09 23:07

Message:
Hey Bogan,

Well, I'll do my best as passionate patch proponent, but first I want to
mention that I don't have my head anywhere near completely around the tm
module so please forgive me if I end up making statements that turn out to
be patently false. And secondly, this is going to be a ramble and I'm
afraid I don't have the time to edit it, proof read it, or even spell check
it so please forgive me in advance for slaughtering the art of writing.
Here goes...

1) Cleanup on first callback could lead to double free unless lock is used
local_reply() in t_reply.c releases the REPLY_LOCK prior to calling the
running the callbacks for TMCB_LOCAL_COMPLETED. So without locking in the
callback, the series of 200s (from a badly behaving uas for example) could
still trigger a double free from the race condition (ie. proc1 check NULL,
proc 1 free, proc2 check NULL, proc 2 free, proc 1 set param NULL, proc 2
set param NULL). This would obviously be bad. While I know that under
normal circumstances this senario would likely not occur, but it would not
be hard for a determined uas to bring this scenario to life and I'd rather
sleep well knowing that double free simply will not happen.

2) CPL proxy example not a good comparison
The example you referenced (cpl_proxy.h , reply_callback()) doesn't make
for an apples to apples comparision since in that case the callback is
trigger cleanup on TMCB_RESPONSE_OUT which relay_reply() (t_reply.c)
guarantees will only be sent once (sets local var totag_retr inside
REPLY_LOCK and uses it as a test for triggering the callback).

3) Using cleanup callback (release function) makes for a good api
The general approach of using a release function has merit in this case.
When an api is defined so that a callback is called once, the clean up of a
callback parameter is straight forward. But when an api is defined so that
a callback can be registered for multiple events and called repeatedly in
different ways depending on external circumstances, a release function
allows for straight forward clean up by the api consumer. The api consumer
can simply trust the api will do the right thing and call the release
function once whenever callback cleanup needs to be done (transaction ends,
system shutdown, whatever, etc). Furthermore it make it straight forward
for the api maintainer to make future changes and updates to the api
without worrying about who the consumers might be depending on event
sequences for cleanup. 

4) Alternative makes for a bad api
The alternative of defining the api along the lines of "register your
callback and if you are doing such and such you can cleanup when this
happens, but if you are doing this then you should do you cleanup like..."
leads, in my opinion, to confusion and bugs and problems making changes in
the future. It is certainly harder for the api consumer and leads to the
following kind of thing "ok, if my callback can be called multiple times
then I need to figure out when to cleanup ... is the api expecting the
parameter pointer to by constant? ... I could check the source code ... can
multiple processes be running my callback at the same time ... is the api
locking to prevent that? ... I ccould check the source code ... if I do it
this way will the api change in the future so that my approach doesn't
work? ... well I certainly don't want to double free because then that will
cause memory corruption and bring down the whole server and I don't want my
module doing that on people and those kinds of problems are really hard to
track down so I best start reading the source code to see what is is doing
so I don't mess it up ... who this tm module is complicated ... timers and
mutexes ... this sucks ... sigh ... maybe I'll just call free and hope for
the best ... no maybe I just won't free at all and leak memory which at
least won't crash it right away". 
For example, a current comment at the top of uac_cb() in seas_action.c
seas module (a callback passed to t_request_within)...

/ * ...
 * TODO WARNING !!! there's a clear MEMORY LEAK here, see exit: at the
bottom of
 * the function... it should free ev_info !!!!!!!!
 * I have disabled the free() because It may be that we receive a
retransmitted 200 OK
 * if the ACK gets lost, that 200 OK will make SER invoke this callback a
second,third, etc time...
 *
 */

Nice!

5) Trying to make the single callback approch work leads ugly land
Update! It looks like the seas code is now registering for
TMCB_TRANS_DELETED which is an undocumented thing that does appear to do
right thing (based on what can tell by pouring over the source code) and
callback at a desirable time for cleanup (expect during shutdown - maybe a
bug and should it should be moved from free_cell() into empty_tmcb_list()).
Of course the api consumer needs to go trolling through the source code to
ever realize that it exists and then has to wonder if it will exist in the
future because, well, it is undocumented and buried and only appears to be
used by this seas module thing which is, well, ah. umm. And lets see how
using this TMCB_DELETED thing is being done - first call t_request_within
and then when the first TMCB_LOCAL_COMPLETED shows up register for
TMCB_TRANS_DELETED and pass my cb param to that instead of cleaning it up
now... ummm, but wait isn't there a 200s race condition here and we could
end up registering two callbacks? ahh.. and boy isn't this ugly register
one callback and then register another and it still doesn't do...

Sigh.

6) Cleanup callback (release function) plain and simple just works well
Wouldn't it be great if the api just provided the ability to pass in
cleanup callback? Simple and elegant. And if it did, I the api consumer
could just use it and not have to read tm source code for hours and
everything would just work - now and in the future - because I can trust
that the api maintainer will called exactly once and from exactly the right
time/place. (Note that is exactly what the prior commited by dan_pascu did
- the release function infrastructure is already in place and gets called
in empty_tmcb_list() exactly once when the callbacks are getting cleaned
up). And there are no race conditions to worry about and no double frees.
And the api maintainer doesn't have to worry about messing any consumers up
in the future if internals need to change etc. And the api consumers (motly
crew that they are) will not go off doing ugly, dumb, and buggy stuff which
ends up in modules that end users include thinking it will give then this
great new feature they want but just ends up causing random crashes.

So, in conclusion, having the api consumer provide the api with a release
function is a good solution which works well for the api maintainer, the
api consumer, and for the health of the entire project (I'm really spinning
it now!). 

And finally, I do need to sleep at night, so can you please confirm that
at a minimum I will need to lock before I free if I attempt to go the "free
and set to NULL on first LOCAL_COMPLETED" route to make sure I never double
free?

Whew.

Thanks for reading,

John


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

Comment By: Bogdan-Andrei Iancu (bogdan_iancu)
Date: 2009-05-09 03:28

Message:
Hi John,

I'm not 100% sure this is needed.
Currently all local UAC transaction do trigger a TMCB_LOCAL_COMPLETED
callback when the transaction is completed. So you can use this callback to
cleanup whatever params you attached to the transaction.
In regards to the multiple 200 OK (retransmissions), the registered
callback function should first check if the received param is NULL and if
so, to exit. If not NULL,  it should free it and set it to NULL to avoid
sequential executions.
As an example, see in the CPL module, the cpl_proxy.h , reply_callback()
function, how the param (inter var) is freed.

Regards,
Bogdan 

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

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


From noreply at sourceforge.net  Sun May 10 06:02:56 2009
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun, 10 May 2009 04:02:56 +0000
Subject: [OpenSIPS-Devel] [ opensips-Patches-2789126 ] extend tm uac
	functions to support tmcb release function
Message-ID: <E1M30Fc-0005Xw-5c@cdv4jf1.ch3.sourceforge.com>

Patches item #2789126, was opened at 2009-05-08 13:17
Message generated for change (Comment added) made by john_riordan
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086412&aid=2789126&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: John Riordan (john_riordan)
Assigned to: Bogdan-Andrei Iancu (bogdan_iancu)
Summary: extend tm uac functions to support tmcb release function

Initial Comment:
Currently there does not appear to be a reliable way to cleanup callback parameters passed to the tm uac functions - t_request, t_request_within, etc.. This patch extends the tm uac functions to support the tmcb release function for tm callback parameter cleanup. This is based on work done earlier which added the infrastructure necessary to do proper cleanup and here we are extending the existing uac functions to use that earlier work done in...
                                                                                                                                                                                                                                                                              
    Author: dan_pascu <dan_pascu at 689a6050-402a-0410-94f2-e92a70836424>                                                                 
    Date:   Thu Nov 20 18:55:23 2008 +0000                                                                                             
                                                                                                                                       
        Added infrastructure for tm callback parameter cleanup. Fixed memory corruption caused by invalid freeing of dialogs           
                                                                                                                                       
        git-svn-id: https://opensips.svn.sourceforge.net/svnroot/opensips/trunk at 4992 689a6050-402a-0410-94f2-e92a70836424              

Currently, callback parameters cannot be reliably cleaned up. For example, when using t_request to send an INVITE and the uas responds with a 200 but then the ACK(s) gets lost and the uas continues sending 200s the callback is called repeatedly with an indication that the request was completed so one is faced with either not freeing the callback parameters (leaking memory) or freeing them repeatedly (ah, umm).

Regardless, proper cleanup can best be done by utilizing the release function infrastructure.


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

Comment By: John Riordan (john_riordan)
Date: 2009-05-10 00:02

Message:
Bogdan,

Here is another example in evidence how getting this right is hard for
people. While I haven't tested it, a call to dlg_bridge() in the linked
code looks like it will cause a double free the first time an ack is lost
and the uas sends another 200 (and then triple free and so on as the 200s
come in). I suspect the author of this function would not have fallen into
this trap if t_request() presented an interface that took a release
function callback.

http://git.sip-router.org/cgi-bin/gitweb.cgi?p=kamailio;a=blob;f=modules/dialog/dlg_transfer.c;h=d208863ce83a0ca6d1004302368374d2b52b28b3;hb=HEAD

(If the link doesn't post through, the file it is
modules/dialog/dlg_transfer.c in kamailio head.)

So perhaps my patch, by extending the tm uac api functions to present an
interface for a release function callback, might help avoid mistakes like
this in the future for opensips.

Cheers,

John


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

Comment By: John Riordan (john_riordan)
Date: 2009-05-09 23:10

Message:
Sincerely sorry about the "Bogan" typo.

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

Comment By: John Riordan (john_riordan)
Date: 2009-05-09 23:07

Message:
Hey Bogan,

Well, I'll do my best as passionate patch proponent, but first I want to
mention that I don't have my head anywhere near completely around the tm
module so please forgive me if I end up making statements that turn out to
be patently false. And secondly, this is going to be a ramble and I'm
afraid I don't have the time to edit it, proof read it, or even spell check
it so please forgive me in advance for slaughtering the art of writing.
Here goes...

1) Cleanup on first callback could lead to double free unless lock is used
local_reply() in t_reply.c releases the REPLY_LOCK prior to calling the
running the callbacks for TMCB_LOCAL_COMPLETED. So without locking in the
callback, the series of 200s (from a badly behaving uas for example) could
still trigger a double free from the race condition (ie. proc1 check NULL,
proc 1 free, proc2 check NULL, proc 2 free, proc 1 set param NULL, proc 2
set param NULL). This would obviously be bad. While I know that under
normal circumstances this senario would likely not occur, but it would not
be hard for a determined uas to bring this scenario to life and I'd rather
sleep well knowing that double free simply will not happen.

2) CPL proxy example not a good comparison
The example you referenced (cpl_proxy.h , reply_callback()) doesn't make
for an apples to apples comparision since in that case the callback is
trigger cleanup on TMCB_RESPONSE_OUT which relay_reply() (t_reply.c)
guarantees will only be sent once (sets local var totag_retr inside
REPLY_LOCK and uses it as a test for triggering the callback).

3) Using cleanup callback (release function) makes for a good api
The general approach of using a release function has merit in this case.
When an api is defined so that a callback is called once, the clean up of a
callback parameter is straight forward. But when an api is defined so that
a callback can be registered for multiple events and called repeatedly in
different ways depending on external circumstances, a release function
allows for straight forward clean up by the api consumer. The api consumer
can simply trust the api will do the right thing and call the release
function once whenever callback cleanup needs to be done (transaction ends,
system shutdown, whatever, etc). Furthermore it make it straight forward
for the api maintainer to make future changes and updates to the api
without worrying about who the consumers might be depending on event
sequences for cleanup. 

4) Alternative makes for a bad api
The alternative of defining the api along the lines of "register your
callback and if you are doing such and such you can cleanup when this
happens, but if you are doing this then you should do you cleanup like..."
leads, in my opinion, to confusion and bugs and problems making changes in
the future. It is certainly harder for the api consumer and leads to the
following kind of thing "ok, if my callback can be called multiple times
then I need to figure out when to cleanup ... is the api expecting the
parameter pointer to by constant? ... I could check the source code ... can
multiple processes be running my callback at the same time ... is the api
locking to prevent that? ... I ccould check the source code ... if I do it
this way will the api change in the future so that my approach doesn't
work? ... well I certainly don't want to double free because then that will
cause memory corruption and bring down the whole server and I don't want my
module doing that on people and those kinds of problems are really hard to
track down so I best start reading the source code to see what is is doing
so I don't mess it up ... who this tm module is complicated ... timers and
mutexes ... this sucks ... sigh ... maybe I'll just call free and hope for
the best ... no maybe I just won't free at all and leak memory which at
least won't crash it right away". 
For example, a current comment at the top of uac_cb() in seas_action.c
seas module (a callback passed to t_request_within)...

/ * ...
 * TODO WARNING !!! there's a clear MEMORY LEAK here, see exit: at the
bottom of
 * the function... it should free ev_info !!!!!!!!
 * I have disabled the free() because It may be that we receive a
retransmitted 200 OK
 * if the ACK gets lost, that 200 OK will make SER invoke this callback a
second,third, etc time...
 *
 */

Nice!

5) Trying to make the single callback approch work leads ugly land
Update! It looks like the seas code is now registering for
TMCB_TRANS_DELETED which is an undocumented thing that does appear to do
right thing (based on what can tell by pouring over the source code) and
callback at a desirable time for cleanup (expect during shutdown - maybe a
bug and should it should be moved from free_cell() into empty_tmcb_list()).
Of course the api consumer needs to go trolling through the source code to
ever realize that it exists and then has to wonder if it will exist in the
future because, well, it is undocumented and buried and only appears to be
used by this seas module thing which is, well, ah. umm. And lets see how
using this TMCB_DELETED thing is being done - first call t_request_within
and then when the first TMCB_LOCAL_COMPLETED shows up register for
TMCB_TRANS_DELETED and pass my cb param to that instead of cleaning it up
now... ummm, but wait isn't there a 200s race condition here and we could
end up registering two callbacks? ahh.. and boy isn't this ugly register
one callback and then register another and it still doesn't do...

Sigh.

6) Cleanup callback (release function) plain and simple just works well
Wouldn't it be great if the api just provided the ability to pass in
cleanup callback? Simple and elegant. And if it did, I the api consumer
could just use it and not have to read tm source code for hours and
everything would just work - now and in the future - because I can trust
that the api maintainer will called exactly once and from exactly the right
time/place. (Note that is exactly what the prior commited by dan_pascu did
- the release function infrastructure is already in place and gets called
in empty_tmcb_list() exactly once when the callbacks are getting cleaned
up). And there are no race conditions to worry about and no double frees.
And the api maintainer doesn't have to worry about messing any consumers up
in the future if internals need to change etc. And the api consumers (motly
crew that they are) will not go off doing ugly, dumb, and buggy stuff which
ends up in modules that end users include thinking it will give then this
great new feature they want but just ends up causing random crashes.

So, in conclusion, having the api consumer provide the api with a release
function is a good solution which works well for the api maintainer, the
api consumer, and for the health of the entire project (I'm really spinning
it now!). 

And finally, I do need to sleep at night, so can you please confirm that
at a minimum I will need to lock before I free if I attempt to go the "free
and set to NULL on first LOCAL_COMPLETED" route to make sure I never double
free?

Whew.

Thanks for reading,

John


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

Comment By: Bogdan-Andrei Iancu (bogdan_iancu)
Date: 2009-05-09 03:28

Message:
Hi John,

I'm not 100% sure this is needed.
Currently all local UAC transaction do trigger a TMCB_LOCAL_COMPLETED
callback when the transaction is completed. So you can use this callback to
cleanup whatever params you attached to the transaction.
In regards to the multiple 200 OK (retransmissions), the registered
callback function should first check if the received param is NULL and if
so, to exit. If not NULL,  it should free it and set it to NULL to avoid
sequential executions.
As an example, see in the CPL module, the cpl_proxy.h , reply_callback()
function, how the param (inter var) is freed.

Regards,
Bogdan 

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

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


From noreply at sourceforge.net  Sun May 10 12:04:46 2009
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun, 10 May 2009 10:04:46 +0000
Subject: [OpenSIPS-Devel] [ opensips-Patches-2789126 ] extend tm uac
	functions to support tmcb release function
Message-ID: <E1M35tm-0006rM-B4@1bkjzd1.ch3.sourceforge.com>

Patches item #2789126, was opened at 2009-05-08 20:17
Message generated for change (Comment added) made by bogdan_iancu
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086412&aid=2789126&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: Accepted
Priority: 5
Private: No
Submitted By: John Riordan (john_riordan)
Assigned to: Bogdan-Andrei Iancu (bogdan_iancu)
Summary: extend tm uac functions to support tmcb release function

Initial Comment:
Currently there does not appear to be a reliable way to cleanup callback parameters passed to the tm uac functions - t_request, t_request_within, etc.. This patch extends the tm uac functions to support the tmcb release function for tm callback parameter cleanup. This is based on work done earlier which added the infrastructure necessary to do proper cleanup and here we are extending the existing uac functions to use that earlier work done in...
                                                                                                                                                                                                                                                                              
    Author: dan_pascu <dan_pascu at 689a6050-402a-0410-94f2-e92a70836424>                                                                 
    Date:   Thu Nov 20 18:55:23 2008 +0000                                                                                             
                                                                                                                                       
        Added infrastructure for tm callback parameter cleanup. Fixed memory corruption caused by invalid freeing of dialogs           
                                                                                                                                       
        git-svn-id: https://opensips.svn.sourceforge.net/svnroot/opensips/trunk at 4992 689a6050-402a-0410-94f2-e92a70836424              

Currently, callback parameters cannot be reliably cleaned up. For example, when using t_request to send an INVITE and the uas responds with a 200 but then the ACK(s) gets lost and the uas continues sending 200s the callback is called repeatedly with an indication that the request was completed so one is faced with either not freeing the callback parameters (leaking memory) or freeing them repeatedly (ah, umm).

Regardless, proper cleanup can best be done by utilizing the release function infrastructure.


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

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

Message:
Hi John,

trying to follow the numbering you did for my comments :)

1) you do not need lock as some of the callback are already synced by TM -
so you cannot have 2 callbacks executed in the same time....but this is not
true for all callbacks, so I agree this is a reason.

2) true - exactly what I mentioned in 1)

3) I agree with your arguments 

4) good example, indeed

5) right, the TMCB_TRANS_DELETED callback is the best place to cleanup
stuff, but I think you want cleanup per callback and not callback per
transaction. This is a new callback I added 2 years ago for the dialog
module (this module is also using the callback for getting events for the
dialog state machine). But your final point is good - you cannot use this
callback with local transactions as you cannot install it :(

6) make sense to me - what can I say...you convince me, so I will start
overviewing  the patch for integrating on SVN.

7 - dlg_dridge() ) not sure what this function does, but I guess somebody
without a good understanding of how the dialog and TM modules work just
pushed it there..

Thanks and best regards,
Bogdan

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

Comment By: John Riordan (john_riordan)
Date: 2009-05-10 07:02

Message:
Bogdan,

Here is another example in evidence how getting this right is hard for
people. While I haven't tested it, a call to dlg_bridge() in the linked
code looks like it will cause a double free the first time an ack is lost
and the uas sends another 200 (and then triple free and so on as the 200s
come in). I suspect the author of this function would not have fallen into
this trap if t_request() presented an interface that took a release
function callback.

http://git.sip-router.org/cgi-bin/gitweb.cgi?p=kamailio;a=blob;f=modules/dialog/dlg_transfer.c;h=d208863ce83a0ca6d1004302368374d2b52b28b3;hb=HEAD

(If the link doesn't post through, the file it is
modules/dialog/dlg_transfer.c in kamailio head.)

So perhaps my patch, by extending the tm uac api functions to present an
interface for a release function callback, might help avoid mistakes like
this in the future for opensips.

Cheers,

John


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

Comment By: John Riordan (john_riordan)
Date: 2009-05-10 06:10

Message:
Sincerely sorry about the "Bogan" typo.

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

Comment By: John Riordan (john_riordan)
Date: 2009-05-10 06:07

Message:
Hey Bogan,

Well, I'll do my best as passionate patch proponent, but first I want to
mention that I don't have my head anywhere near completely around the tm
module so please forgive me if I end up making statements that turn out to
be patently false. And secondly, this is going to be a ramble and I'm
afraid I don't have the time to edit it, proof read it, or even spell check
it so please forgive me in advance for slaughtering the art of writing.
Here goes...

1) Cleanup on first callback could lead to double free unless lock is used
local_reply() in t_reply.c releases the REPLY_LOCK prior to calling the
running the callbacks for TMCB_LOCAL_COMPLETED. So without locking in the
callback, the series of 200s (from a badly behaving uas for example) could
still trigger a double free from the race condition (ie. proc1 check NULL,
proc 1 free, proc2 check NULL, proc 2 free, proc 1 set param NULL, proc 2
set param NULL). This would obviously be bad. While I know that under
normal circumstances this senario would likely not occur, but it would not
be hard for a determined uas to bring this scenario to life and I'd rather
sleep well knowing that double free simply will not happen.

2) CPL proxy example not a good comparison
The example you referenced (cpl_proxy.h , reply_callback()) doesn't make
for an apples to apples comparision since in that case the callback is
trigger cleanup on TMCB_RESPONSE_OUT which relay_reply() (t_reply.c)
guarantees will only be sent once (sets local var totag_retr inside
REPLY_LOCK and uses it as a test for triggering the callback).

3) Using cleanup callback (release function) makes for a good api
The general approach of using a release function has merit in this case.
When an api is defined so that a callback is called once, the clean up of a
callback parameter is straight forward. But when an api is defined so that
a callback can be registered for multiple events and called repeatedly in
different ways depending on external circumstances, a release function
allows for straight forward clean up by the api consumer. The api consumer
can simply trust the api will do the right thing and call the release
function once whenever callback cleanup needs to be done (transaction ends,
system shutdown, whatever, etc). Furthermore it make it straight forward
for the api maintainer to make future changes and updates to the api
without worrying about who the consumers might be depending on event
sequences for cleanup. 

4) Alternative makes for a bad api
The alternative of defining the api along the lines of "register your
callback and if you are doing such and such you can cleanup when this
happens, but if you are doing this then you should do you cleanup like..."
leads, in my opinion, to confusion and bugs and problems making changes in
the future. It is certainly harder for the api consumer and leads to the
following kind of thing "ok, if my callback can be called multiple times
then I need to figure out when to cleanup ... is the api expecting the
parameter pointer to by constant? ... I could check the source code ... can
multiple processes be running my callback at the same time ... is the api
locking to prevent that? ... I ccould check the source code ... if I do it
this way will the api change in the future so that my approach doesn't
work? ... well I certainly don't want to double free because then that will
cause memory corruption and bring down the whole server and I don't want my
module doing that on people and those kinds of problems are really hard to
track down so I best start reading the source code to see what is is doing
so I don't mess it up ... who this tm module is complicated ... timers and
mutexes ... this sucks ... sigh ... maybe I'll just call free and hope for
the best ... no maybe I just won't free at all and leak memory which at
least won't crash it right away". 
For example, a current comment at the top of uac_cb() in seas_action.c
seas module (a callback passed to t_request_within)...

/ * ...
 * TODO WARNING !!! there's a clear MEMORY LEAK here, see exit: at the
bottom of
 * the function... it should free ev_info !!!!!!!!
 * I have disabled the free() because It may be that we receive a
retransmitted 200 OK
 * if the ACK gets lost, that 200 OK will make SER invoke this callback a
second,third, etc time...
 *
 */

Nice!

5) Trying to make the single callback approch work leads ugly land
Update! It looks like the seas code is now registering for
TMCB_TRANS_DELETED which is an undocumented thing that does appear to do
right thing (based on what can tell by pouring over the source code) and
callback at a desirable time for cleanup (expect during shutdown - maybe a
bug and should it should be moved from free_cell() into empty_tmcb_list()).
Of course the api consumer needs to go trolling through the source code to
ever realize that it exists and then has to wonder if it will exist in the
future because, well, it is undocumented and buried and only appears to be
used by this seas module thing which is, well, ah. umm. And lets see how
using this TMCB_DELETED thing is being done - first call t_request_within
and then when the first TMCB_LOCAL_COMPLETED shows up register for
TMCB_TRANS_DELETED and pass my cb param to that instead of cleaning it up
now... ummm, but wait isn't there a 200s race condition here and we could
end up registering two callbacks? ahh.. and boy isn't this ugly register
one callback and then register another and it still doesn't do...

Sigh.

6) Cleanup callback (release function) plain and simple just works well
Wouldn't it be great if the api just provided the ability to pass in
cleanup callback? Simple and elegant. And if it did, I the api consumer
could just use it and not have to read tm source code for hours and
everything would just work - now and in the future - because I can trust
that the api maintainer will called exactly once and from exactly the right
time/place. (Note that is exactly what the prior commited by dan_pascu did
- the release function infrastructure is already in place and gets called
in empty_tmcb_list() exactly once when the callbacks are getting cleaned
up). And there are no race conditions to worry about and no double frees.
And the api maintainer doesn't have to worry about messing any consumers up
in the future if internals need to change etc. And the api consumers (motly
crew that they are) will not go off doing ugly, dumb, and buggy stuff which
ends up in modules that end users include thinking it will give then this
great new feature they want but just ends up causing random crashes.

So, in conclusion, having the api consumer provide the api with a release
function is a good solution which works well for the api maintainer, the
api consumer, and for the health of the entire project (I'm really spinning
it now!). 

And finally, I do need to sleep at night, so can you please confirm that
at a minimum I will need to lock before I free if I attempt to go the "free
and set to NULL on first LOCAL_COMPLETED" route to make sure I never double
free?

Whew.

Thanks for reading,

John


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

Comment By: Bogdan-Andrei Iancu (bogdan_iancu)
Date: 2009-05-09 10:28

Message:
Hi John,

I'm not 100% sure this is needed.
Currently all local UAC transaction do trigger a TMCB_LOCAL_COMPLETED
callback when the transaction is completed. So you can use this callback to
cleanup whatever params you attached to the transaction.
In regards to the multiple 200 OK (retransmissions), the registered
callback function should first check if the received param is NULL and if
so, to exit. If not NULL,  it should free it and set it to NULL to avoid
sequential executions.
As an example, see in the CPL module, the cpl_proxy.h , reply_callback()
function, how the param (inter var) is freed.

Regards,
Bogdan 

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

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


From bogdan at voice-system.ro  Sun May 10 12:37:27 2009
From: bogdan at voice-system.ro (Bogdan-Andrei Iancu)
Date: Sun, 10 May 2009 10:37:27 +0000
Subject: [OpenSIPS-Devel] SF.net SVN: opensips:[5688] trunk/scripts
Message-ID: <E1M36PP-0002xU-4V@c3vjzd1.ch3.sourceforge.com>

Revision: 5688
          http://opensips.svn.sourceforge.net/opensips/?rev=5688&view=rev
Author:   bogdan_iancu
Date:     2009-05-10 10:37:26 +0000 (Sun, 10 May 2009)

Log Message:
-----------
- fixed versions in the migration help text

Modified Paths:
--------------
    trunk/scripts/opensipsdbctl.base
    trunk/scripts/osipsconsole


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 May 10 12:38:34 2009
From: bogdan at voice-system.ro (Bogdan-Andrei Iancu)
Date: Sun, 10 May 2009 10:38:34 +0000
Subject: [OpenSIPS-Devel] SF.net SVN: opensips:[5689] branches/1.5/scripts
Message-ID: <E1M36QU-0002yt-1k@c3vjzd1.ch3.sourceforge.com>

Revision: 5689
          http://opensips.svn.sourceforge.net/opensips/?rev=5689&view=rev
Author:   bogdan_iancu
Date:     2009-05-10 10:38:33 +0000 (Sun, 10 May 2009)

Log Message:
-----------
- fixed versions in the migration help text

Modified Paths:
--------------
    branches/1.5/scripts/opensipsdbctl.base
    branches/1.5/scripts/osipsconsole


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 May 10 16:04:54 2009
From: bogdan at voice-system.ro (Bogdan-Andrei Iancu)
Date: Sun, 10 May 2009 14:04:54 +0000
Subject: [OpenSIPS-Devel] SF.net SVN: opensips:[5690]
	trunk/modules/alias_db/doc/alias_db.xml
Message-ID: <E1M39eA-0001LW-Qj@3kljzd1.ch3.sourceforge.com>

Revision: 5690
          http://opensips.svn.sourceforge.net/opensips/?rev=5690&view=rev
Author:   bogdan_iancu
Date:     2009-05-10 14:04:54 +0000 (Sun, 10 May 2009)

Log Message:
-----------
- docs fixing

Modified Paths:
--------------
    trunk/modules/alias_db/doc/alias_db.xml


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 May 10 16:07:53 2009
From: bogdan at voice-system.ro (Bogdan-Andrei Iancu)
Date: Sun, 10 May 2009 14:07:53 +0000
Subject: [OpenSIPS-Devel] SF.net SVN: opensips:[5691] trunk/modules/tm
Message-ID: <E1M39h3-0001PT-NM@3kljzd1.ch3.sourceforge.com>

Revision: 5691
          http://opensips.svn.sourceforge.net/opensips/?rev=5691&view=rev
Author:   bogdan_iancu
Date:     2009-05-10 14:07:53 +0000 (Sun, 10 May 2009)

Log Message:
-----------
- cancel_brnach() function now takes flags:
	"a" - cancel all branches - it obsolets the cancel_call() function
	"o" - cancel all other branches but not the current one
	""  - cancel only current branch (backward compatible)

- cancel_call() function removed

Modified Paths:
--------------
    trunk/modules/tm/README
    trunk/modules/tm/doc/tm.xml
    trunk/modules/tm/doc/tm_admin.xml
    trunk/modules/tm/tm.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  Sun May 10 16:11:11 2009
From: bogdan at voice-system.ro (Bogdan-Andrei Iancu)
Date: Sun, 10 May 2009 14:11:11 +0000
Subject: [OpenSIPS-Devel] SF.net SVN: opensips:[5692]
	trunk/modules/tm/doc/tm_faq.xml
Message-ID: <E1M39kF-0001UY-52@3kljzd1.ch3.sourceforge.com>

Revision: 5692
          http://opensips.svn.sourceforge.net/opensips/?rev=5692&view=rev
Author:   bogdan_iancu
Date:     2009-05-10 14:11:10 +0000 (Sun, 10 May 2009)

Log Message:
-----------
 FAQ file added

Added Paths:
-----------
    trunk/modules/tm/doc/tm_faq.xml


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


From lftsy at leurent.eu  Mon May 11 10:21:14 2009
From: lftsy at leurent.eu (Marc Leurent)
Date: Mon, 11 May 2009 10:21:14 +0200
Subject: [OpenSIPS-Devel] [OpenSIPS-Users] Question about dialog max
	timeout...
In-Reply-To: <4A0545E6.2040208@voice-system.ro>
References: <200905081306.18893.lftsy@leurent.eu>
	<200905081327.52111.lftsy@leurent.eu>
	<4A0545E6.2040208@voice-system.ro>
Message-ID: <200905111021.14858.lftsy@leurent.eu>

Good morning everybody,
Thank you for the information!!

So my first problem is that dialogs are built even if I do not call the create_dialog() function or the setflag(4) that I have defined in dialog params..

To answer your question, yes dialogs are being removed, but some of them are not, I think because of reasons below:

Each time I REGISTER:
If Contact header is used to match the dialog, if I rewrite it because of routing specific architecture in fix_nated_contact();, dialogs won't be removed even if I use modparam("dialog", "dlg_match_mode", 0) ?? Because dialogs are still there after the 200 OK like this dialog for REGISTER:
dialog::  hash=3917:871117747
        state:: 3
        user_flags:: 0
        timestart:: 1242029446
        timeout:: 11025
        callid:: jjolrfphvjriywr at leonhart.interne
        from_uri:: sip:0213115090 at 212.147.46.91
        from_tag:: pnvkk
        caller_contact:: sip:02131090 at 194.38.160.113:5070
        caller_cseq:: 554
        caller_route_set::
        caller_bind_addr:: udp:212.147.46.91:5060
        to_uri:: sip:0213115090 at 212.147.46.91
        to_tag:: as54366440
        callee_contact:: sip:02131090 at 212.147.46.81:5060
        callee_cseq:: 554
        callee_route_set::
        callee_bind_addr:: udp:212.147.46.91:5060


Each time I unregister,I got an error:
	ERROR:dialog:populate_leg_info: bad sip message or missing Contact hdr
Indeed, my Asterisk servers are responding without a Contact header to unregister, keeping dialog data until timeout
and I thought dialog module didn't need it for matching the dialog!

Thank you
++

-- --
Marc LEURENT
lftsy at leurent.eu

Le Saturday 09 May 2009 10.59:18 Bogdan-Andrei Iancu, vous avez ?crit?:
> Hi Marc,
> 
> It is normal to increase as it is an absolute timestamp - see my prev 
> email on this thread.
> 
> Regarding the shm mem - do you see the dialogs actually being removed?
> 
> Regards,
> Bogdan
> 
> Marc Leurent wrote:
> > Sorry for the 3rd email.. but I think it's interesting, because the dialog timeout of my transactions seems to increase with OpenSIPs uptime!
> > So my shm memory increase all the time. Does any one have the same problem with OpenSIPs 1.5.1?
> > Thanks
> >
> > opensipsctl fifo dlg_list | grep timeout | sort -nr
> >         timeout:: 20395
> >         timeout:: 20340
> >         timeout:: 20285
> >         timeout:: 20230
> >         timeout:: 20175
> >         timeout:: 20120
> >         timeout:: 20064
> >         timeout:: 20009
> >         timeout:: 19954
> >         timeout:: 19899
> > 	...
> >
> > and just after
> > opensipsctl fifo dlg_list | grep timeout | sort -nr
> >         timeout:: 20450
> >         timeout:: 20395
> >         timeout:: 20340
> >         timeout:: 20285
> >         timeout:: 20230
> >         timeout:: 20175
> >         timeout:: 20120
> >         timeout:: 20064
> >         timeout:: 20009
> >         timeout:: 19954
> >         timeout:: 19899
> > 	...
> >
> > PS: I'm using
> > opensips -V
> > version: opensips 1.5.1-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: unknown
> > @(#) $Id: main.c 5469 2009-03-18 12:43:10Z bogdan_iancu $
> > main.c compiled on 19:03:00 Apr 30 2009 with gcc 4.1.2
> >
> >
> > Le Friday 08 May 2009 13.06:18 Marc Leurent, vous avez ?crit :
> >   
> >> Hello all, I have juste a small question about the dialog module, I have set the parameters below for OpenSIPs dialog module with a "default_timeout",  to 3 hours,
> >>
> >> # ----- dialog params -----
> >> modparam("dialog", "enable_stats", 1)                           # If the statistics support should be enabled or not.
> >> #modparam("dialog", "hash_size", 4096)                          # The size of the hash table internally used to keep the dialogs.
> >> modparam("dialog", "rr_param", "did")                           # Name of the Record-Route parameter to be added with the dialog cookie.
> >> modparam("dialog", "dlg_flag", 4)                               # Flag to be used for marking if a dialog should be constructed for the current request.
> >> #modparam("dialog", "buy_on_timeout_flag", 6)                   # Message falg to be set if you want the dialog module to automatically send BYE requests (in both directions) when the dialog give timeout.
> >> #modparam("dialog", "timeout_avp", "$avp(i:10)")                # The specification of an AVP to contain a custom timeout (in seconds) for the dialog.
> >> modparam("dialog", "default_timeout", 10800)                    # The default dialog timeout (in seconds) if no custom one is set.
> >> #modparam("dialog", "dlg_extra_hdrs", "Hint: credit expired\r\n")       # A string containing the extra headers to be added in the requests generated
> >> modparam("dialog", "dlg_match_mode", 0)                         # The match is done exclusively based on DID;
> >> modparam("dialog", "db_url", "mysql://opensips:Uwefwefwefo3J at localhost/opensips")
> >> modparam("dialog", "db_mode", 1)                                # Describe how to push into the DB the dialogs' information from memory.
> >> modparam("dialog", "db_update_period", 30)                      # The interval (seconds) at which to update dialogs' information if you chose to store.
> >> #modparam("dialog", "profiles_with_value", "caller ; my_profile")       # List of names for profiles with values.
> >> #modparam("dialog", "profiles_no_value", "inbound ; outbound")          # List of names for profiles without values.
> >>
> >> but I have some dialogs that have a superior timeout like this one..
> >> Have you got any idea how to see where this timeout is defined and how to force it to a lower value!
> >> Because of this, I reach my "snmpstats", "dlg_minor_threshold", 900 very quickly
> >> Thanks!
> >>
> >> dialog::  hash=1768:1584216798
> >>         state:: 3
> >>         user_flags:: 0
> >>         timestart:: 1241777705
> >>         timeout:: 16267
> >>         callid:: zaltktgtpqzdqvo at leonhart.interne
> >>         from_uri:: sip:0213115090 at 212.147.46.91
> >>         from_tag:: ooctt
> >>         caller_contact:: sip:0213115090 at 194.38.160.113:5070
> >>         caller_cseq:: 960
> >>         caller_route_set::
> >>         caller_bind_addr:: udp:212.147.46.91:5060
> >>         to_uri:: sip:0213115090 at 212.147.46.91
> >>         to_tag:: as79ae919b
> >>         callee_contact:: sip:0213115090 at 212.147.46.81:5060
> >>         callee_cseq:: 960
> >>         callee_route_set::
> >>         callee_bind_addr:: udp:212.147.46.91:5060
> >>
> >>
> >>     
> >
> >
> >   
> 




From noreply at sourceforge.net  Mon May 11 10:56:27 2009
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 11 May 2009 08:56:27 +0000
Subject: [OpenSIPS-Devel] [ opensips-Bugs-2787094 ] Crash with db_postgresql
	and no db connection
Message-ID: <E1M3RJD-0001Tg-Nh@d55xhf1.ch3.sourceforge.com>

Bugs item #2787094, was opened at 2009-05-05 08:45
Message generated for change (Comment added) made by nobody
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=2787094&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: Nobody/Anonymous (nobody)
Assigned to: Bogdan-Andrei Iancu (bogdan_iancu)
Summary: Crash with db_postgresql and no db connection

Initial Comment:
Opensips with usrloc and db_postgresql will crash if the db server is unreachable.


Scenario is the following, I have a remote postgres DB server, and had not opened the PG port on the firewall, which causes opensips to be unable to reach the DB server.
on init, opensips times out trying to connect to the DB, and then crash, looking at the logs, it seems to be usrloc module related.

It's easy to reproduce, I can provide as many tracks as needed.

If you need me bogdan, ask on irc ( Gled ).

bt:
#0  0x0000000000425f36 in handle_sigs () at main.c:486
486                                             if (pt[i].pid==chld) break;

#0  0x0000000000425f36 in handle_sigs () at main.c:486
#1  <signal handler called>
#2  0x00000030e6ae0cb7 in munmap () from /lib64/libc.so.6
#3  0x00000000004a4804 in shm_mem_destroy () at mem/shm_mem.c:238
#4  0x00000000004259a6 in cleanup (show_status=0) at main.c:365
#5  0x0000000000428560 in main (argc=<value optimized out>, argv=0x20) at main.c:1324

bt full:
#0  0x0000000000425f36 in handle_sigs () at main.c:486
        chld = 1909
        chld_status = 0
        i = <value optimized out>
        do_exit = 0
        __FUNCTION__ = "handle_sigs"
#1  <signal handler called>
No symbol table info available.
#2  0x00000030e6ae0cb7 in munmap () from /lib64/libc.so.6
No symbol table info available.
#3  0x00000000004a4804 in shm_mem_destroy () at mem/shm_mem.c:238
        __FUNCTION__ = "shm_mem_destroy"
#4  0x00000000004259a6 in cleanup (show_status=0) at main.c:365
No locals.
#5  0x0000000000428560 in main (argc=<value optimized out>, argv=0x20) at main.c:1324
        cfg_log_stderr = 1906
        cfg_stream = (FILE *) 0x772
        c = <value optimized out>
        r = 1
        tmp = 0x4ffe65 "H\205?t\0341?\017\037@"
        tmp_len = <value optimized out>
        port = <value optimized out>
        proto = <value optimized out>
        ret = -1
        seed = 2320449269
        rfd = <value optimized out>
        __FUNCTION__ = "main"


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

Comment By: Nobody/Anonymous (nobody)
Date: 2009-05-11 08:56

Message:
Morning Bogdan,

seems like it's fixed in r5678 of branch 1.5, tried again this morning and
I see like you a normal shutdown...

You must have fixed this fixing something else ;)

Regards,

Gled

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

Comment By: Bogdan-Andrei Iancu (bogdan_iancu)
Date: 2009-05-09 08:46

Message:
Hi Gled,

I tried to reproduce this bug by configuring the usrloc module to use a
postgres DB. I put the URL to point to a bogus IP as I have no postgres
server and because actually the scenario is about unreachable DB
server....

But I got :
May  9 11:27:07 [2171] DBG:db_postgres:db_postgres_new_connection:
PQsetdbLogin(0x82b9770)
May  9 11:27:07 [2171] ERROR:db_postgres:db_postgres_new_connection: could
not connect to server: Connection timed out
        Is the server running on host "192.168.1.254" and accepting
        TCP/IP connections on port 5432?

May  9 11:27:07 [2171] ERROR:db_postgres:db_postgres_new_connection:
cleaning up 0x81b1998=pkg_free()

and a normal shutdown...

Regards,
Bogdan


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

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


From marc.leurent at vtx-telecom.ch  Mon May 11 11:02:42 2009
From: marc.leurent at vtx-telecom.ch (Marc Leurent)
Date: Mon, 11 May 2009 11:02:42 +0200
Subject: [OpenSIPS-Devel] All debugs to set a diagnostic of why dialog are
	not removed in my OpenSIPs 1.5.1 (SIP trace + opensips debug
	4 + opensipsctl fifo dlg_list )
In-Reply-To: <200905111021.14858.lftsy@leurent.eu>
References: <200905081306.18893.lftsy@leurent.eu>
	<4A0545E6.2040208@voice-system.ro>
	<200905111021.14858.lftsy@leurent.eu>
Message-ID: <200905111102.42829.marc.leurent@vtx-telecom.ch>

When monitoring a REGISTER dialog, I have found that is creates 2 dialogs, here is an example,
it creates 2 dialogs (first REGISTER / 401 Unauthorized) with dialog 3102:436706855 or 0x2b2cc4ab4b58
and after (REGISTER / 200 OK) with dialog                                        3102:436706856 or 0x2b2cc4ab52d8 

The first one is correctly removed, but not the second one! I have to wait 3 hours before its removal

Here is the second dialog that is not removed:
dialog::  hash=3102:436706856
        state:: 3
        user_flags:: 0
        timestart:: 1242030852
        timeout:: 10915
        callid:: jjolrfphvjriywr at leonhart.interne.smart-telecom.ch
        from_uri:: sip:0213115090 at 212.147.46.91
        from_tag:: ypyiu
        caller_contact:: sip:0213115090 at 194.38.160.113:5070
        caller_cseq:: 604
        caller_route_set::
        caller_bind_addr:: udp:212.147.46.91:5060
        to_uri:: sip:0213115090 at 212.147.46.91
        to_tag:: as6c579ae5
        callee_contact:: sip:0213115090 at 212.147.46.81:5060
        callee_cseq:: 604
        callee_route_set::
        callee_bind_addr:: udp:212.147.46.91:5060



Here is my opensips.log file:
May 11 10:34:12 vp-pro-01 opensips[3265]: DBG:dialog:build_new_dlg: new dialog 0x2b2cc4ab4b58 (c=jjolrfphvjriywr at leonhart.interne.smart-telecom.ch
,f=sip:0213115097.46.91,t=5090 at 212.147.46.91,ft=ypyiu) on hash 3102
May 11 10:34:12 vp-pro-01 opensips[3265]: DBG:dialog:populate_leg_info: route_set , contact sip:0213115090 at 194.38.160.113:5070, cseq 603 and bind_
addr udp:212.147060
May 11 10:34:12 vp-pro-01 opensips[3265]: DBG:dialog:dlg_set_leg_info: set leg 0 for 0x2b2cc4ab4b58: tag=<ypyiu> rr=<> ct=<sip:0213115090 at 194.38.1
60.113:5070> cse
May 11 10:34:12 vp-pro-01 opensips[3265]: DBG:dialog:link_dlg: ref dlg 0x2b2cc4ab4b58 with 3 -> 3
May 11 10:34:12 vp-pro-01 opensips[3265]: DBG:dialog:get_dlg_timeout: invalid AVP value, use default timeout
May 11 10:34:12 vp-pro-01 opensips[3265]: DBG:dialog:unref_dlg: unref dlg 0x2b2cc4ab4b58 with 1 -> 2
May 11 10:34:12 vp-pro-01 opensips[3263]: DBG:dialog:next_state_dlg: dialog 0x2b2cc4ab4b58 changed from state 1 to state 5, due event 4
May 11 10:34:12 vp-pro-01 opensips[3263]: DBG:dialog:dlg_onreply: dialog 0x2b2cc4ab4b58 failed (negative reply)
May 11 10:34:12 vp-pro-01 opensips[3263]: DBG:dialog:unref_dlg: unref dlg 0x2b2cc4ab4b58 with 1 -> 1

May 11 10:34:12 vp-pro-01 opensips[3270]: DBG:dialog:build_new_dlg: new dialog 0x2b2cc4ab52d8 (c=jjolrfphvjriywr at leonhart.interne.smart-telecom.ch
,f=sip:0213115097.46.91,t=5090 at 212.147.46.91,ft=ypyiu) on hash 3102
May 11 10:34:12 vp-pro-01 opensips[3270]: DBG:dialog:populate_leg_info: route_set , contact sip:0213115090 at 194.38.160.113:5070, cseq 604 and bind_
addr udp:212.147060
May 11 10:34:12 vp-pro-01 opensips[3270]: DBG:dialog:dlg_set_leg_info: set leg 0 for 0x2b2cc4ab52d8: tag=<ypyiu> rr=<> ct=<sip:0213115090 at 194.38.1
60.113:5070> cse
May 11 10:34:12 vp-pro-01 opensips[3270]: DBG:dialog:link_dlg: ref dlg 0x2b2cc4ab52d8 with 3 -> 3
May 11 10:34:12 vp-pro-01 opensips[3270]: DBG:dialog:get_dlg_timeout: invalid AVP value, use default timeout
May 11 10:34:12 vp-pro-01 opensips[3270]: DBG:dialog:unref_dlg: unref dlg 0x2b2cc4ab52d8 with 1 -> 2
May 11 10:34:12 vp-pro-01 opensips[3269]: DBG:dialog:next_state_dlg: dialog 0x2b2cc4ab52d8 changed from state 1 to state 3, due event 3
May 11 10:34:12 vp-pro-01 opensips[3269]: DBG:dialog:dlg_onreply: dialog 0x2b2cc4ab52d8 confirmed
May 11 10:34:12 vp-pro-01 opensips[3269]: DBG:dialog:dlg_onreply: 0x2b2cc4ab52d8 totag in rpl is <as6c579ae5> (10)
May 11 10:34:12 vp-pro-01 opensips[3269]: DBG:dialog:populate_leg_info: route_set , contact sip:0213115090 at 212.147.46.81:5060, cseq 604 and bind_a
ddr udp:212.147.60
May 11 10:34:12 vp-pro-01 opensips[3269]: DBG:dialog:dlg_set_leg_info: set leg 1 for 0x2b2cc4ab52d8: tag=<as6c579ae5> rr=<> ct=<sip:0213115090 at 212
.147.46.81:5060>04>
May 11 10:34:12 vp-pro-01 opensips[3269]: DBG:dialog:insert_dlg_timer_unsafe: inserting 0x2b2cc4ab5310 for 10915
May 11 10:34:12 vp-pro-01 opensips[3269]: DBG:dialog:ref_dlg: ref dlg 0x2b2cc4ab52d8 with 1 -> 3
May 11 10:34:17 vp-pro-01 opensips[3280]: DBG:dialog:next_state_dlg: dialog 0x2b2cc4ab4b58 changed from state 5 to state 5, due event 1
May 11 10:34:17 vp-pro-01 opensips[3280]: DBG:dialog:unref_dlg: unref dlg 0x2b2cc4ab4b58 with 1 -> 0
May 11 10:34:17 vp-pro-01 opensips[3280]: DBG:dialog:unref_dlg: ref <=0 for dialog 0x2b2cc4ab4b58
May 11 10:34:17 vp-pro-01 opensips[3280]: DBG:dialog:destroy_dlg: destroing dialog 0x2b2cc4ab4b58
May 11 10:34:17 vp-pro-01 opensips[3280]: DBG:dialog:destroy_dlg: dlg expired or not in list - dlg 0x2b2cc4ab4b58 [3102:436706855] with clid 'jjol
rfphvjriywr at leonerne.smarth' and tags 'ypyiu' ''
May 11 10:34:17 vp-pro-01 opensips[3280]: DBG:dialog:next_state_dlg: unref dlg 0x2b2cc4ab52d8 with 1 -> 2
May 11 10:34:17 vp-pro-01 opensips[3280]: DBG:dialog:next_state_dlg: dialog 0x2b2cc4ab52d8 changed from state 3 to state 3, due event 1

you can see that it try to remove the first dialog twice, so it failed!



And here is my SIP trace:

REGISTER sip:212.147.46.91 SIP/2.0
Via: SIP/2.0/UDP 192.168.10.206:5070;rport;branch=z9hG4bKinxbzijz
Max-Forwards: 70
To: "0213115090" <sip:0213115090 at 212.147.46.91>
From: "0213115090" <sip:0213115090 at 212.147.46.91>;tag=ypyiu
Call-ID: jjolrfphvjriywr at leonhart.interne.smart-telecom.ch
CSeq: 603 REGISTER
Contact: <sip:0213115090 at 192.168.10.206:5070>;expires=1800
Allow: INVITE,ACK,BYE,CANCEL,OPTIONS,PRACK,REFER,NOTIFY,SUBSCRIBE,INFO,MESSAGE
User-Agent: Twinkle/1.4.2
Content-Length: 0


REGISTER sip:212.147.46.91 SIP/2.0
Record-Route: <sip:212.147.46.91;lr=on;ftag=ypyiu;did=e1c.72e970a1>
Via: SIP/2.0/UDP 212.147.46.91;branch=z9hG4bKc85e.d6359375.0
Via: SIP/2.0/UDP 192.168.10.206:5070;received=194.38.160.113;rport=5070;branch=z9hG4bKinxbzijz
Max-Forwards: 69
To: "0213115090" <sip:0213115090 at 212.147.46.91>
From: "0213115090" <sip:0213115090 at 212.147.46.91>;tag=ypyiu
Call-ID: jjolrfphvjriywr at leonhart.interne.smart-telecom.ch
CSeq: 603 REGISTER
Contact: <sip:0213115090 at 194.38.160.113:5070>;expires=1800
Allow: INVITE,ACK,BYE,CANCEL,OPTIONS,PRACK,REFER,NOTIFY,SUBSCRIBE,INFO,MESSAGE
User-Agent: Twinkle/1.4.2
Content-Length: 0


SIP/2.0 100 Trying
Via: SIP/2.0/UDP 212.147.46.91;branch=z9hG4bKc85e.d6359375.0;received=212.147.46.91
Via: SIP/2.0/UDP 192.168.10.206:5070;received=194.38.160.113;rport=5070;branch=z9hG4bKinxbzijz
Record-Route: <sip:212.147.46.91;lr=on;ftag=ypyiu;did=e1c.72e970a1>
From: "0213115090" <sip:0213115090 at 212.147.46.91>;tag=ypyiu
To: "0213115090" <sip:0213115090 at 212.147.46.91>
Call-ID: jjolrfphvjriywr at leonhart.interne.smart-telecom.ch
CSeq: 603 REGISTER
User-Agent: voipua
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY
Supported: replaces
Content-Length: 0


SIP/2.0 401 Unauthorized
Via: SIP/2.0/UDP 212.147.46.91;branch=z9hG4bKc85e.d6359375.0;received=212.147.46.91
Via: SIP/2.0/UDP 192.168.10.206:5070;received=194.38.160.113;rport=5070;branch=z9hG4bKinxbzijz
From: "0213115090" <sip:0213115090 at 212.147.46.91>;tag=ypyiu
To: "0213115090" <sip:0213115090 at 212.147.46.91>;tag=as6c579ae5
Call-ID: jjolrfphvjriywr at leonhart.interne.smart-telecom.ch
CSeq: 603 REGISTER
User-Agent: voipua
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY
Supported: replaces
WWW-Authenticate: Digest algorithm=MD5, realm="voip", nonce="143f1691"
Content-Length: 0



SIP/2.0 401 Unauthorized
Via: SIP/2.0/UDP 192.168.10.206:5070;received=194.38.160.113;rport=5070;branch=z9hG4bKinxbzijz
From: "0213115090" <sip:0213115090 at 212.147.46.91>;tag=ypyiu
To: "0213115090" <sip:0213115090 at 212.147.46.91>;tag=as6c579ae5
Call-ID: jjolrfphvjriywr at leonhart.interne.smart-telecom.ch
CSeq: 603 REGISTER
User-Agent: voipua
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY
Supported: replaces
WWW-Authenticate: Digest algorithm=MD5, realm="voip", nonce="143f1691"
Content-Length: 0


REGISTER sip:212.147.46.91 SIP/2.0
Via: SIP/2.0/UDP 192.168.10.206:5070;rport;branch=z9hG4bKfmplnebu
Max-Forwards: 70
To: "0213115090" <sip:0213115090 at 212.147.46.91>
From: "0213115090" <sip:0213115090 at 212.147.46.91>;tag=ypyiu
Call-ID: jjolrfphvjriywr at leonhart.interne.smart-telecom.ch
CSeq: 604 REGISTER
Contact: <sip:0213115090 at 192.168.10.206:5070>;expires=1800
Authorization: Digest username="0213115090",realm="voip",nonce="143f1691",uri="sip:212.147.46.91",response="xxxxxxxxxxxxxxx",algorithm=MD5
Allow: INVITE,ACK,BYE,CANCEL,OPTIONS,PRACK,REFER,NOTIFY,SUBSCRIBE,INFO,MESSAGE
User-Agent: Twinkle/1.4.2
Content-Length: 0


REGISTER sip:212.147.46.91 SIP/2.0
Record-Route: <sip:212.147.46.91;lr=on;ftag=ypyiu;did=e1c.82e970a1>
Via: SIP/2.0/UDP 212.147.46.91;branch=z9hG4bK985e.20bbcb63.0
Via: SIP/2.0/UDP 192.168.10.206:5070;received=194.38.160.113;rport=5070;branch=z9hG4bKfmplnebu
Max-Forwards: 69
To: "0213115090" <sip:0213115090 at 212.147.46.91>
From: "0213115090" <sip:0213115090 at 212.147.46.91>;tag=ypyiu
Call-ID: jjolrfphvjriywr at leonhart.interne.smart-telecom.ch
CSeq: 604 REGISTER
Contact: <sip:0213115090 at 194.38.160.113:5070>;expires=1800
Authorization: Digest username="0213115090",realm="voip",nonce="143f1691",uri="sip:212.147.46.91",response="xxxxxxxxxxxxxxx",algorithm=MD5
Allow: INVITE,ACK,BYE,CANCEL,OPTIONS,PRACK,REFER,NOTIFY,SUBSCRIBE,INFO,MESSAGE
User-Agent: Twinkle/1.4.2
Content-Length: 0


SIP/2.0 100 Trying
Via: SIP/2.0/UDP 212.147.46.91;branch=z9hG4bK985e.20bbcb63.0;received=212.147.46.91
Via: SIP/2.0/UDP 192.168.10.206:5070;received=194.38.160.113;rport=5070;branch=z9hG4bKfmplnebu
Record-Route: <sip:212.147.46.91;lr=on;ftag=ypyiu;did=e1c.82e970a1>
From: "0213115090" <sip:0213115090 at 212.147.46.91>;tag=ypyiu
To: "0213115090" <sip:0213115090 at 212.147.46.91>
Call-ID: jjolrfphvjriywr at leonhart.interne.smart-telecom.ch
CSeq: 604 REGISTER
User-Agent: voipua
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY
Supported: replaces
Content-Length: 0



SIP/2.0 200 OK
Via: SIP/2.0/UDP 212.147.46.91;branch=z9hG4bK985e.20bbcb63.0;received=212.147.46.91
Via: SIP/2.0/UDP 192.168.10.206:5070;received=194.38.160.113;rport=5070;branch=z9hG4bKfmplnebu
Record-Route: <sip:212.147.46.91;lr=on;ftag=ypyiu;did=e1c.82e970a1>
From: "0213115090" <sip:0213115090 at 212.147.46.91>;tag=ypyiu
To: "0213115090" <sip:0213115090 at 212.147.46.91>;tag=as6c579ae5
Call-ID: jjolrfphvjriywr at leonhart.interne.smart-telecom.ch
CSeq: 604 REGISTER
User-Agent: voipua
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY
Supported: replaces
Expires: 180
Contact: <sip:0213115090 at 194.38.160.113:5070>;expires=180
Date: Mon, 11 May 2009 08:34:12 GMT
Content-Length: 0


SIP/2.0 200 OK
Via: SIP/2.0/UDP 192.168.10.206:5070;received=194.38.160.113;rport=5070;branch=z9hG4bKfmplnebu
Record-Route: <sip:212.147.46.91;lr=on;ftag=ypyiu;did=e1c.82e970a1>
From: "0213115090" <sip:0213115090 at 212.147.46.91>;tag=ypyiu
To: "0213115090" <sip:0213115090 at 212.147.46.91>;tag=as6c579ae5
Call-ID: jjolrfphvjriywr at leonhart.interne.smart-telecom.ch
CSeq: 604 REGISTER
User-Agent: voipua
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY
Supported: replaces
Expires: 180
Contact: <sip:0213115090 at 212.147.46.81:5060>;expires=180
Date: Mon, 11 May 2009 08:34:12 GMT
Content-Length: 0





-- --
Marc LEURENT
Ing?nieur VoIP

DECKPOINT SA
Une soci?t? du groupe VTX Telecom
================================================================
Rue Eug?ne-Marziano 15 - 1227 Les Acacias
http://www.vtx.ch - marc.leurent at vtx-telecom.ch
----------------------------------------------------------------
VTX, votre partenaire telecom proche de vous !
================================================================

Le Monday 11 May 2009 10.21:14 Marc Leurent, vous avez ?crit?:
> Good morning everybody,
> Thank you for the information!!
> 
> So my first problem is that dialogs are built even if I do not call the create_dialog() function or the setflag(4) that I have defined in dialog params..
> 
> To answer your question, yes dialogs are being removed, but some of them are not, I think because of reasons below:
> 
> Each time I REGISTER:
> If Contact header is used to match the dialog, if I rewrite it because of routing specific architecture in fix_nated_contact();, dialogs won't be removed even if I use modparam("dialog", "dlg_match_mode", 0) ?? Because dialogs are still there after the 200 OK like this dialog for REGISTER:
> dialog::  hash=3917:871117747
>         state:: 3
>         user_flags:: 0
>         timestart:: 1242029446
>         timeout:: 11025
>         callid:: jjolrfphvjriywr at leonhart.interne
>         from_uri:: sip:0213115090 at 212.147.46.91
>         from_tag:: pnvkk
>         caller_contact:: sip:02131090 at 194.38.160.113:5070
>         caller_cseq:: 554
>         caller_route_set::
>         caller_bind_addr:: udp:212.147.46.91:5060
>         to_uri:: sip:0213115090 at 212.147.46.91
>         to_tag:: as54366440
>         callee_contact:: sip:02131090 at 212.147.46.81:5060
>         callee_cseq:: 554
>         callee_route_set::
>         callee_bind_addr:: udp:212.147.46.91:5060
> 
> 
> Each time I unregister,I got an error:
> 	ERROR:dialog:populate_leg_info: bad sip message or missing Contact hdr
> Indeed, my Asterisk servers are responding without a Contact header to unregister, keeping dialog data until timeout
> and I thought dialog module didn't need it for matching the dialog!
> 
> Thank you
> ++
> 
> -- --
> Marc LEURENT
> lftsy at leurent.eu
> 
> Le Saturday 09 May 2009 10.59:18 Bogdan-Andrei Iancu, vous avez ?crit?:
> > Hi Marc,
> > 
> > It is normal to increase as it is an absolute timestamp - see my prev 
> > email on this thread.
> > 
> > Regarding the shm mem - do you see the dialogs actually being removed?
> > 
> > Regards,
> > Bogdan
> > 
> > Marc Leurent wrote:
> > > Sorry for the 3rd email.. but I think it's interesting, because the dialog timeout of my transactions seems to increase with OpenSIPs uptime!
> > > So my shm memory increase all the time. Does any one have the same problem with OpenSIPs 1.5.1?
> > > Thanks
> > >
> > > opensipsctl fifo dlg_list | grep timeout | sort -nr
> > >         timeout:: 20395
> > >         timeout:: 20340
> > >         timeout:: 20285
> > >         timeout:: 20230
> > >         timeout:: 20175
> > >         timeout:: 20120
> > >         timeout:: 20064
> > >         timeout:: 20009
> > >         timeout:: 19954
> > >         timeout:: 19899
> > > 	...
> > >
> > > and just after
> > > opensipsctl fifo dlg_list | grep timeout | sort -nr
> > >         timeout:: 20450
> > >         timeout:: 20395
> > >         timeout:: 20340
> > >         timeout:: 20285
> > >         timeout:: 20230
> > >         timeout:: 20175
> > >         timeout:: 20120
> > >         timeout:: 20064
> > >         timeout:: 20009
> > >         timeout:: 19954
> > >         timeout:: 19899
> > > 	...
> > >
> > > PS: I'm using
> > > opensips -V
> > > version: opensips 1.5.1-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: unknown
> > > @(#) $Id: main.c 5469 2009-03-18 12:43:10Z bogdan_iancu $
> > > main.c compiled on 19:03:00 Apr 30 2009 with gcc 4.1.2
> > >
> > >
> > > Le Friday 08 May 2009 13.06:18 Marc Leurent, vous avez ?crit :
> > >   
> > >> Hello all, I have juste a small question about the dialog module, I have set the parameters below for OpenSIPs dialog module with a "default_timeout",  to 3 hours,
> > >>
> > >> # ----- dialog params -----
> > >> modparam("dialog", "enable_stats", 1)                           # If the statistics support should be enabled or not.
> > >> #modparam("dialog", "hash_size", 4096)                          # The size of the hash table internally used to keep the dialogs.
> > >> modparam("dialog", "rr_param", "did")                           # Name of the Record-Route parameter to be added with the dialog cookie.
> > >> modparam("dialog", "dlg_flag", 4)                               # Flag to be used for marking if a dialog should be constructed for the current request.
> > >> #modparam("dialog", "buy_on_timeout_flag", 6)                   # Message falg to be set if you want the dialog module to automatically send BYE requests (in both directions) when the dialog give timeout.
> > >> #modparam("dialog", "timeout_avp", "$avp(i:10)")                # The specification of an AVP to contain a custom timeout (in seconds) for the dialog.
> > >> modparam("dialog", "default_timeout", 10800)                    # The default dialog timeout (in seconds) if no custom one is set.
> > >> #modparam("dialog", "dlg_extra_hdrs", "Hint: credit expired\r\n")       # A string containing the extra headers to be added in the requests generated
> > >> modparam("dialog", "dlg_match_mode", 0)                         # The match is done exclusively based on DID;
> > >> modparam("dialog", "db_url", "mysql://opensips:Uwefwefwefo3J at localhost/opensips")
> > >> modparam("dialog", "db_mode", 1)                                # Describe how to push into the DB the dialogs' information from memory.
> > >> modparam("dialog", "db_update_period", 30)                      # The interval (seconds) at which to update dialogs' information if you chose to store.
> > >> #modparam("dialog", "profiles_with_value", "caller ; my_profile")       # List of names for profiles with values.
> > >> #modparam("dialog", "profiles_no_value", "inbound ; outbound")          # List of names for profiles without values.
> > >>
> > >> but I have some dialogs that have a superior timeout like this one..
> > >> Have you got any idea how to see where this timeout is defined and how to force it to a lower value!
> > >> Because of this, I reach my "snmpstats", "dlg_minor_threshold", 900 very quickly
> > >> Thanks!
> > >>
> > >> dialog::  hash=1768:1584216798
> > >>         state:: 3
> > >>         user_flags:: 0
> > >>         timestart:: 1241777705
> > >>         timeout:: 16267
> > >>         callid:: zaltktgtpqzdqvo at leonhart.interne
> > >>         from_uri:: sip:0213115090 at 212.147.46.91
> > >>         from_tag:: ooctt
> > >>         caller_contact:: sip:0213115090 at 194.38.160.113:5070
> > >>         caller_cseq:: 960
> > >>         caller_route_set::
> > >>         caller_bind_addr:: udp:212.147.46.91:5060
> > >>         to_uri:: sip:0213115090 at 212.147.46.91
> > >>         to_tag:: as79ae919b
> > >>         callee_contact:: sip:0213115090 at 212.147.46.81:5060
> > >>         callee_cseq:: 960
> > >>         callee_route_set::
> > >>         callee_bind_addr:: udp:212.147.46.91:5060
> > >>
> > >>
> > >>     
> > >
> > >
> > >   
> > 
> 
> 
> 
> _______________________________________________
> Devel mailing list
> Devel at lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
> 




From noreply at sourceforge.net  Mon May 11 12:16:01 2009
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 11 May 2009 10:16:01 +0000
Subject: [OpenSIPS-Devel] [ opensips-Bugs-2787094 ] Crash with db_postgresql
	and no db connection
Message-ID: <E1M3SYD-00020m-3Q@cdv4jf1.ch3.sourceforge.com>

Bugs item #2787094, was opened at 2009-05-05 11:45
Message generated for change (Comment added) made by bogdan_iancu
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=2787094&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: Closed
>Resolution: Out of Date
Priority: 5
Private: No
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Bogdan-Andrei Iancu (bogdan_iancu)
Summary: Crash with db_postgresql and no db connection

Initial Comment:
Opensips with usrloc and db_postgresql will crash if the db server is unreachable.


Scenario is the following, I have a remote postgres DB server, and had not opened the PG port on the firewall, which causes opensips to be unable to reach the DB server.
on init, opensips times out trying to connect to the DB, and then crash, looking at the logs, it seems to be usrloc module related.

It's easy to reproduce, I can provide as many tracks as needed.

If you need me bogdan, ask on irc ( Gled ).

bt:
#0  0x0000000000425f36 in handle_sigs () at main.c:486
486                                             if (pt[i].pid==chld) break;

#0  0x0000000000425f36 in handle_sigs () at main.c:486
#1  <signal handler called>
#2  0x00000030e6ae0cb7 in munmap () from /lib64/libc.so.6
#3  0x00000000004a4804 in shm_mem_destroy () at mem/shm_mem.c:238
#4  0x00000000004259a6 in cleanup (show_status=0) at main.c:365
#5  0x0000000000428560 in main (argc=<value optimized out>, argv=0x20) at main.c:1324

bt full:
#0  0x0000000000425f36 in handle_sigs () at main.c:486
        chld = 1909
        chld_status = 0
        i = <value optimized out>
        do_exit = 0
        __FUNCTION__ = "handle_sigs"
#1  <signal handler called>
No symbol table info available.
#2  0x00000030e6ae0cb7 in munmap () from /lib64/libc.so.6
No symbol table info available.
#3  0x00000000004a4804 in shm_mem_destroy () at mem/shm_mem.c:238
        __FUNCTION__ = "shm_mem_destroy"
#4  0x00000000004259a6 in cleanup (show_status=0) at main.c:365
No locals.
#5  0x0000000000428560 in main (argc=<value optimized out>, argv=0x20) at main.c:1324
        cfg_log_stderr = 1906
        cfg_stream = (FILE *) 0x772
        c = <value optimized out>
        r = 1
        tmp = 0x4ffe65 "H\205?t\0341?\017\037@"
        tmp_len = <value optimized out>
        port = <value optimized out>
        proto = <value optimized out>
        ret = -1
        seed = 2320449269
        rfd = <value optimized out>
        __FUNCTION__ = "main"


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

>Comment By: Bogdan-Andrei Iancu (bogdan_iancu)
Date: 2009-05-11 13:16

Message:
OK - good to know :)

Best regards,
Bogdan

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

Comment By: Nobody/Anonymous (nobody)
Date: 2009-05-11 11:56

Message:
Morning Bogdan,

seems like it's fixed in r5678 of branch 1.5, tried again this morning and
I see like you a normal shutdown...

You must have fixed this fixing something else ;)

Regards,

Gled

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

Comment By: Bogdan-Andrei Iancu (bogdan_iancu)
Date: 2009-05-09 11:46

Message:
Hi Gled,

I tried to reproduce this bug by configuring the usrloc module to use a
postgres DB. I put the URL to point to a bogus IP as I have no postgres
server and because actually the scenario is about unreachable DB
server....

But I got :
May  9 11:27:07 [2171] DBG:db_postgres:db_postgres_new_connection:
PQsetdbLogin(0x82b9770)
May  9 11:27:07 [2171] ERROR:db_postgres:db_postgres_new_connection: could
not connect to server: Connection timed out
        Is the server running on host "192.168.1.254" and accepting
        TCP/IP connections on port 5432?

May  9 11:27:07 [2171] ERROR:db_postgres:db_postgres_new_connection:
cleaning up 0x81b1998=pkg_free()

and a normal shutdown...

Regards,
Bogdan


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

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


From anca at opensips.org  Mon May 11 12:18:40 2009
From: anca at opensips.org (Anca Vamanu)
Date: Mon, 11 May 2009 10:18:40 +0000
Subject: [OpenSIPS-Devel] SF.net SVN: opensips:[5693]
	trunk/modules/presence/notify.c
Message-ID: <E1M3Sam-0006LX-Av@74yxhf1.ch3.sourceforge.com>

Revision: 5693
          http://opensips.svn.sourceforge.net/opensips/?rev=5693&view=rev
Author:   anca_vamanu
Date:     2009-05-11 10:18:40 +0000 (Mon, 11 May 2009)

Log Message:
-----------
- fixed bug in computing expires value for subscription dialogs - reported by Inaki Baz Castillo in bug report #2788937

Modified Paths:
--------------
    trunk/modules/presence/notify.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 May 11 12:21:20 2009
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 11 May 2009 10:21:20 +0000
Subject: [OpenSIPS-Devel] [ opensips-Bugs-2788937 ] presence: Wrong
	Subscription-State "expires" value in NOTIFY
Message-ID: <E1M3SdM-0001Es-S7@665xhf1.ch3.sourceforge.com>

Bugs item #2788937, was opened at 2009-05-08 14:57
Message generated for change (Comment added) made by anca_vamanu
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=2788937&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: I?aki Baz Castillo (ibc_sf)
Assigned to: Anca Vamanu (anca_vamanu)
Summary: presence: Wrong Subscription-State "expires" value in NOTIFY

Initial Comment:
OpenSIPS "presence" module is generating really wrong "expires" values in "Subscription-State" header of NOTIFY. This causes the subscriber thinking that the subscription lives for long time (due to the exagerate high value of "expires" parameter) but the fact is that the subscriber dissapears from "active-watchers" table and leaves getting notifications.

I just use (these are really low values for testing, but the issue also occurs with higher values):

------------
modparam("presence", "max_expires_publish", 50)
modparam("presence", "max_expires_subscribe", 20)
modparam("presence", "expires_offset", 5)
modparam("presence", "fallback2db", 1)
------------

I attach a capture. Note in line 376 how the "Subscription-State" has a "cool" value:

  Subscription-State: active;expires=4294967285  <---- !!!!!!!!!!!!!

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

>Comment By: Anca Vamanu (anca_vamanu)
Date: 2009-05-11 13:21

Message:
Hi,

I have tested myself and found the bug. I have committed a fix. Please
update and test.
I will close this bug report, but if you notice the problem again you can
reopen it. 

Thanks and regards,
Anca 

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

Comment By: I?aki Baz Castillo (ibc_sf)
Date: 2009-05-08 16:50

Message:
Here there is a sequence of "Subscription-State" header value in NOTIFY's
generated by presence module. There are just two subscribers, one of them
uses "expires=600" and the other "expires=3600". "max_expire_subscribe" is
set to 3600 in OpenSIPS presence module.

Subscription-State: active;expires=658
Subscription-State: active;expires=484
Subscription-State: active;expires=658
Subscription-State: active;expires=484
Subscription-State: active;expires=657
Subscription-State: active;expires=657
Subscription-State: active;expires=483
Subscription-State: active;expires=483
Subscription-State: active;expires=437
Subscription-State: active;expires=263
Subscription-State: active;expires=437
Subscription-State: active;expires=263
Subscription-State: active;expires=399
Subscription-State: active;expires=225
Subscription-State: active;expires=399
Subscription-State: active;expires=225
Subscription-State: active;expires=3600
Subscription-State: active;expires=3600
Subscription-State: active;expires=3600
Subscription-State: active;expires=3600
Subscription-State: active;expires=3600
Subscription-State: active;expires=3600
Subscription-State: active;expires=3600
Subscription-State: active;expires=3600
Subscription-State: active;expires=600
Subscription-State: active;expires=600
Subscription-State: active;expires=138
Subscription-State: active;expires=138
Subscription-State: active;expires=4294967260   <--- !!!
Subscription-State: active;expires=4294967260   <--- !!!
Subscription-State: active;expires=150
Subscription-State: active;expires=150
Subscription-State: active;expires=3600
Subscription-State: active;expires=3600
Subscription-State: active;expires=3600
Subscription-State: active;expires=3600
Subscription-State: active;expires=4294967279   <--- !!!
Subscription-State: active;expires=4294967279   <--- !!!
[...]

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

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


From bogdan at voice-system.ro  Mon May 11 12:23:22 2009
From: bogdan at voice-system.ro (Bogdan-Andrei Iancu)
Date: Mon, 11 May 2009 13:23:22 +0300
Subject: [OpenSIPS-Devel] [OpenSIPS-Users] Question about dialog max
	timeout...
In-Reply-To: <200905111021.14858.lftsy@leurent.eu>
References: <200905081306.18893.lftsy@leurent.eu>
	<200905081327.52111.lftsy@leurent.eu>
	<4A0545E6.2040208@voice-system.ro>
	<200905111021.14858.lftsy@leurent.eu>
Message-ID: <4A07FC9A.4090607@voice-system.ro>

Hi Marc,

Marc Leurent wrote:
> Good morning everybody,
> Thank you for the information!!
>
> So my first problem is that dialogs are built even if I do not call the create_dialog() function or the setflag(4) that I have defined in dialog params..
>   

to solve this mystery...can you grab a full debug log (debug=6) from 
your opensips ? I will try to see what is triggering the dialog creation 
- if no issue you can send me offlist the script to be able to correlate 
with the logs.
> To answer your question, yes dialogs are being removed, but some of them are not, I think because of reasons below:
>
> Each time I REGISTER:
> If Contact header is used to match the dialog, if I rewrite it because of routing specific architecture in fix_nated_contact();, dialogs won't be removed even if I use modparam("dialog", "dlg_match_mode", 0) ?? Because dialogs are still there after the 200 OK like this dialog for REGISTER:
> dialog::  hash=3917:871117747
>         state:: 3
>         user_flags:: 0
>         timestart:: 1242029446
>         timeout:: 11025
>         callid:: jjolrfphvjriywr at leonhart.interne
>         from_uri:: sip:0213115090 at 212.147.46.91
>         from_tag:: pnvkk
>         caller_contact:: sip:02131090 at 194.38.160.113:5070
>         caller_cseq:: 554
>         caller_route_set::
>         caller_bind_addr:: udp:212.147.46.91:5060
>         to_uri:: sip:0213115090 at 212.147.46.91
>         to_tag:: as54366440
>         callee_contact:: sip:02131090 at 212.147.46.81:5060
>         callee_cseq:: 554
>         callee_route_set::
>         callee_bind_addr:: udp:212.147.46.91:5060
>
>
> Each time I unregister,I got an error:
> 	ERROR:dialog:populate_leg_info: bad sip message or missing Contact hdr
> Indeed, my Asterisk servers are responding without a Contact header to unregister, keeping dialog data until timeout
> and I thought dialog module didn't need it for matching the dialog!
>   

You should not use dialog module for register - the dialog module works 
only for INVITE  !

REgards,
Bogdan
> Thank you
> ++
>
> -- --
> Marc LEURENT
> lftsy at leurent.eu
>
> Le Saturday 09 May 2009 10.59:18 Bogdan-Andrei Iancu, vous avez ?crit :
>   
>> Hi Marc,
>>
>> It is normal to increase as it is an absolute timestamp - see my prev 
>> email on this thread.
>>
>> Regarding the shm mem - do you see the dialogs actually being removed?
>>
>> Regards,
>> Bogdan
>>
>> Marc Leurent wrote:
>>     
>>> Sorry for the 3rd email.. but I think it's interesting, because the dialog timeout of my transactions seems to increase with OpenSIPs uptime!
>>> So my shm memory increase all the time. Does any one have the same problem with OpenSIPs 1.5.1?
>>> Thanks
>>>
>>> opensipsctl fifo dlg_list | grep timeout | sort -nr
>>>         timeout:: 20395
>>>         timeout:: 20340
>>>         timeout:: 20285
>>>         timeout:: 20230
>>>         timeout:: 20175
>>>         timeout:: 20120
>>>         timeout:: 20064
>>>         timeout:: 20009
>>>         timeout:: 19954
>>>         timeout:: 19899
>>> 	...
>>>
>>> and just after
>>> opensipsctl fifo dlg_list | grep timeout | sort -nr
>>>         timeout:: 20450
>>>         timeout:: 20395
>>>         timeout:: 20340
>>>         timeout:: 20285
>>>         timeout:: 20230
>>>         timeout:: 20175
>>>         timeout:: 20120
>>>         timeout:: 20064
>>>         timeout:: 20009
>>>         timeout:: 19954
>>>         timeout:: 19899
>>> 	...
>>>
>>> PS: I'm using
>>> opensips -V
>>> version: opensips 1.5.1-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: unknown
>>> @(#) $Id: main.c 5469 2009-03-18 12:43:10Z bogdan_iancu $
>>> main.c compiled on 19:03:00 Apr 30 2009 with gcc 4.1.2
>>>
>>>
>>> Le Friday 08 May 2009 13.06:18 Marc Leurent, vous avez ?crit :
>>>   
>>>       
>>>> Hello all, I have juste a small question about the dialog module, I have set the parameters below for OpenSIPs dialog module with a "default_timeout",  to 3 hours,
>>>>
>>>> # ----- dialog params -----
>>>> modparam("dialog", "enable_stats", 1)                           # If the statistics support should be enabled or not.
>>>> #modparam("dialog", "hash_size", 4096)                          # The size of the hash table internally used to keep the dialogs.
>>>> modparam("dialog", "rr_param", "did")                           # Name of the Record-Route parameter to be added with the dialog cookie.
>>>> modparam("dialog", "dlg_flag", 4)                               # Flag to be used for marking if a dialog should be constructed for the current request.
>>>> #modparam("dialog", "buy_on_timeout_flag", 6)                   # Message falg to be set if you want the dialog module to automatically send BYE requests (in both directions) when the dialog give timeout.
>>>> #modparam("dialog", "timeout_avp", "$avp(i:10)")                # The specification of an AVP to contain a custom timeout (in seconds) for the dialog.
>>>> modparam("dialog", "default_timeout", 10800)                    # The default dialog timeout (in seconds) if no custom one is set.
>>>> #modparam("dialog", "dlg_extra_hdrs", "Hint: credit expired\r\n")       # A string containing the extra headers to be added in the requests generated
>>>> modparam("dialog", "dlg_match_mode", 0)                         # The match is done exclusively based on DID;
>>>> modparam("dialog", "db_url", "mysql://opensips:Uwefwefwefo3J at localhost/opensips")
>>>> modparam("dialog", "db_mode", 1)                                # Describe how to push into the DB the dialogs' information from memory.
>>>> modparam("dialog", "db_update_period", 30)                      # The interval (seconds) at which to update dialogs' information if you chose to store.
>>>> #modparam("dialog", "profiles_with_value", "caller ; my_profile")       # List of names for profiles with values.
>>>> #modparam("dialog", "profiles_no_value", "inbound ; outbound")          # List of names for profiles without values.
>>>>
>>>> but I have some dialogs that have a superior timeout like this one..
>>>> Have you got any idea how to see where this timeout is defined and how to force it to a lower value!
>>>> Because of this, I reach my "snmpstats", "dlg_minor_threshold", 900 very quickly
>>>> Thanks!
>>>>
>>>> dialog::  hash=1768:1584216798
>>>>         state:: 3
>>>>         user_flags:: 0
>>>>         timestart:: 1241777705
>>>>         timeout:: 16267
>>>>         callid:: zaltktgtpqzdqvo at leonhart.interne
>>>>         from_uri:: sip:0213115090 at 212.147.46.91
>>>>         from_tag:: ooctt
>>>>         caller_contact:: sip:0213115090 at 194.38.160.113:5070
>>>>         caller_cseq:: 960
>>>>         caller_route_set::
>>>>         caller_bind_addr:: udp:212.147.46.91:5060
>>>>         to_uri:: sip:0213115090 at 212.147.46.91
>>>>         to_tag:: as79ae919b
>>>>         callee_contact:: sip:0213115090 at 212.147.46.81:5060
>>>>         callee_cseq:: 960
>>>>         callee_route_set::
>>>>         callee_bind_addr:: udp:212.147.46.91:5060
>>>>
>>>>
>>>>     
>>>>         
>>>   
>>>       
>
>
>
>   



From anca at opensips.org  Mon May 11 12:23:44 2009
From: anca at opensips.org (Anca Vamanu)
Date: Mon, 11 May 2009 10:23:44 +0000
Subject: [OpenSIPS-Devel] SF.net SVN: opensips:[5694]
	branches/1.5/modules/presence/notify.c
Message-ID: <E1M3Sfg-0006rd-Ok@74yxhf1.ch3.sourceforge.com>

Revision: 5694
          http://opensips.svn.sourceforge.net/opensips/?rev=5694&view=rev
Author:   anca_vamanu
Date:     2009-05-11 10:23:44 +0000 (Mon, 11 May 2009)

Log Message:
-----------
-fixed bug in computing expires value for subscription dialogs - reported by Inaki Baz Castillo in bug report #2788937

Modified Paths:
--------------
    branches/1.5/modules/presence/notify.c


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


From anca at opensips.org  Mon May 11 13:37:01 2009
From: anca at opensips.org (Anca Vamanu)
Date: Mon, 11 May 2009 11:37:01 +0000
Subject: [OpenSIPS-Devel] SF.net SVN: opensips:[5695] trunk/modules/presence
Message-ID: <E1M3Tob-0001xC-AT@c3vjzd1.ch3.sourceforge.com>

Revision: 5695
          http://opensips.svn.sourceforge.net/opensips/?rev=5695&view=rev
Author:   anca_vamanu
Date:     2009-05-11 11:37:01 +0000 (Mon, 11 May 2009)

Log Message:
-----------
- Improved privacy rules support configuration possbility - it is now possible to force a subscription to be considered allowed from the script.
	-  "handle_subscribe" function can now take one parameter meaningful when using a configuration with privacy rules enabled (force_active parameter in presence_xml module not set). Supposing that you have a means to tell that the contact the Subscribe message is destined to( the presentity) can not upload an xcap document with it's privacy rules, you can tell the presence server to consider that subscription allowed(with Subscription-Status:active) by calling the handle_subscribe function with the string parameter "1".
	Ex:
	if(uri =~ "kphone at opensips.org")
		handle_subscribe("1");
	This parameter allows building a presence platform with xcap privacy rules  were normal phones not supporting xcap still can send their presence information.

Modified Paths:
--------------
    trunk/modules/presence/README
    trunk/modules/presence/doc/presence_admin.xml
    trunk/modules/presence/presence.c
    trunk/modules/presence/subscribe.c


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


From anca at opensips.org  Mon May 11 18:53:33 2009
From: anca at opensips.org (Anca Vamanu)
Date: Mon, 11 May 2009 16:53:33 +0000
Subject: [OpenSIPS-Devel] SF.net SVN: opensips:[5696] trunk/modules
Message-ID: <E1M3Ykv-0002dh-1V@c3vjzd1.ch3.sourceforge.com>

Revision: 5696
          http://opensips.svn.sourceforge.net/opensips/?rev=5696&view=rev
Author:   anca_vamanu
Date:     2009-05-11 16:53:32 +0000 (Mon, 11 May 2009)

Log Message:
-----------
- fixup and improvement in xcap with non integrated xcap server operation mode
	- fixed HTTP etag retreiving from document 
	- fixed HTTP request generation to include If-None-Match header so that the document is fetched only when changed
	- added configuration parameters for XCAP AUID parameter and filename for pres-rules documents in presence_xml module; this way the URL is configurable and and it can be cnstructed according to OMA standard (followed by eyebeam)

Modified Paths:
--------------
    trunk/modules/presence_xml/presence_xml.c
    trunk/modules/presence_xml/presence_xml.h
    trunk/modules/presence_xml/xcap_auth.c
    trunk/modules/xcap_client/xcap_client.c
    trunk/modules/xcap_client/xcap_functions.c
    trunk/modules/xcap_client/xcap_functions.h


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


From anca at opensips.org  Mon May 11 19:10:55 2009
From: anca at opensips.org (Anca Vamanu)
Date: Mon, 11 May 2009 20:10:55 +0300
Subject: [OpenSIPS-Devel] Presence and non integrated xcap server. Did
 somebody managed to get it working?
In-Reply-To: <1241796022506-2845885.post@n2.nabble.com>
References: <1241796022506-2845885.post@n2.nabble.com>
Message-ID: <4A085C1F.2050108@opensips.org>

Hi Genady,

First of all, you say that you are using X-lite for testing, but X-lite 
does not have an XCAP storage support. You should upgrade to eyebeam or 
bria for this.

However, since the non integrated xcap part has not been much tested 
lately, after reading your e-mail I decided to test it a bit. And I 
discovered some problems. The ones from Counterpath seem to have changed 
some things in the XCAP URL format (I think that they are following OMA 
standards instead of IETF).

To make it possible for OpenSIPS to use the same URL format I added two 
new parameters in presence_xml module. Here is how you should set them 
to have your platform working with eyebeam phones:

modparam("presence_xml", "pres_rules_auid", 
"org.openmobilealliance.pres-rules")
modparam("presence_xml", "pres_rules_filename", "pres-rules")

Also I would mention that if you want a change in the xcap document to 
be effective more rapidly, you should change the 'query_period' 
parameter in 'xcap_client' module to a smaller value.

I can not back port all the changes in 1.5.x branch since I changed the 
module interface for an enhancement. Therefore I would suggest you to 
upgrade to the svn trunk version at least only for the presence_xml module.

I have another observation for your configuration:  If you want to test 
the non integrated xcap behaviour, be careful not to configure openxcap 
and opensips to use the same database table for storing xcap documents ( 
I think that this is exactly the case for your configuration).

Please update and test again and if you have some other problems I will 
look into them.

regards,
Anca


genabel wrote:
> Hi,
>
> I'm trying to get the presence server (opensips 1.5.1) working together with
> a non integrated xcap server. Currently I'm using openxcap for the demo
> solution, but later I will use a commecial xcap server. In the demo solution
> scenario openxcap has it's own database schema and tables and clearly
> separated from the opensips data.
>
> The first use case is presence authorization rules related. Getting a
> watcher-info notification, the presence server should issue an xcap request
> towards the xcap server and use the information for the authorization
> decision. I created the corresponding document in openxcap and tested it
> with xcapclient.
>
> To make the life easier (tracing), I decided to use HTTP instead of HTTPS in
> openxcap.  
>
> As a client I'm using X-Lite. Both servers - opensips presence and openxcap
> are running on the same virtual machine (Ubuntu).
>
> I have the following setting in my opensips.cfg :
>
> modparam("presence|presence_xml", "db_url",
> "mysql://user:password at localhost/opensips")
> modparam("presence_xml", "force_active", 0)
> modparam("presence_xml", "pidf_manipulation", 1)
> modparam("presence_xml", "integrated_xcap_server", 0)
> modparam("presence_xml", "xcap_server", "myserver.local:8081")
> modparam("presence", "server_address", "sip:XXX.XXX.XXX.XXX:5060")
> modparam("presence", "fallback2db", 1)
>
> My openxcap is configured like that :
>
> [Server]
> address = 0.0.0.0
> port = 8081
> root = http://myserver.local
> backend = Database
> document_validation = Yes
>
>
> [Logging]
>
> [Authentication]
> type = basic
> cleartext_passwords = Yes
> default_realm = myserver.local
> trusted_peers = XXX.XXX.XXX.XXX
>
> [TLS]
> certificate = tls/server.crt
> private_key = tls/server.key
>
> [Database]
> authentication_db_uri = mysql://openxcap:openxcap at localhost/openxcap
> storage_db_uri = mysql://openxcap:openxcap at localhost/openxcap
> subscriber_table = subscriber
> xcap_table = xcap
>
> In this configuration I'm getting  "ERROR:xcap_client:send_http_get: Error
> [22] while performing curl operation" as far as the presence server is
> trying to send an xcap request to openxcap.
>
> I also noticed that even I configured my presence server as a trusted peer
> in the openxcap config file, I need to provide the user credentials in case
> I want to access this URL in firefox or curl. 
>
> Can it be the reason fot the error - missing xcap credentials configuration
> or maybe I should use https?
> And what is this curl related error message? 
>
> I'm wondering if someone got a similar environment runnig. Any debugging
> hints will be appreciated.
>
> Hope you can help me,
> Best regards,
> Genady 
>
>   



From anca at opensips.org  Mon May 11 19:17:15 2009
From: anca at opensips.org (Anca Vamanu)
Date: Mon, 11 May 2009 17:17:15 +0000
Subject: [OpenSIPS-Devel] SF.net SVN: opensips:[5697]
	trunk/modules/presence_xml
Message-ID: <E1M3Z7r-000235-MT@74yxhf1.ch3.sourceforge.com>

Revision: 5697
          http://opensips.svn.sourceforge.net/opensips/?rev=5697&view=rev
Author:   anca_vamanu
Date:     2009-05-11 17:17:15 +0000 (Mon, 11 May 2009)

Log Message:
-----------
- added documentation for the parameters described in commit comment for rev #5696

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

Modified Paths:
--------------
    trunk/modules/presence_xml/README
    trunk/modules/presence_xml/doc/presence_xml_admin.xml


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 May 11 20:31:51 2009
From: bogdan at voice-system.ro (Bogdan-Andrei Iancu)
Date: Mon, 11 May 2009 18:31:51 +0000
Subject: [OpenSIPS-Devel] SF.net SVN: opensips:[5698] trunk/usr_avp.c
Message-ID: <E1M3aI3-0005ft-Lv@c3vjzd1.ch3.sourceforge.com>

Revision: 5698
          http://opensips.svn.sourceforge.net/opensips/?rev=5698&view=rev
Author:   bogdan_iancu
Date:     2009-05-11 18:31:51 +0000 (Mon, 11 May 2009)

Log Message:
-----------
- missing \n in logs

Modified Paths:
--------------
    trunk/usr_avp.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 May 11 20:36:08 2009
From: bogdan at voice-system.ro (Bogdan-Andrei Iancu)
Date: Mon, 11 May 2009 18:36:08 +0000
Subject: [OpenSIPS-Devel] SF.net SVN: opensips:[5699] trunk
Message-ID: <E1M3aMC-0005lL-HY@c3vjzd1.ch3.sourceforge.com>

Revision: 5699
          http://opensips.svn.sourceforge.net/opensips/?rev=5699&view=rev
Author:   bogdan_iancu
Date:     2009-05-11 18:36:08 +0000 (Mon, 11 May 2009)

Log Message:
-----------
new pvars available:
$an - authentication nonce
$ar - authentication response

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


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 May 11 22:38:25 2009
From: bogdan at voice-system.ro (Bogdan-Andrei Iancu)
Date: Mon, 11 May 2009 20:38:25 +0000
Subject: [OpenSIPS-Devel] SF.net SVN: opensips:[5700]
	trunk/modules/dispatcher
Message-ID: <E1M3cGX-0000n1-Az@c3vjzd1.ch3.sourceforge.com>

Revision: 5700
          http://opensips.svn.sourceforge.net/opensips/?rev=5700&view=rev
Author:   bogdan_iancu
Date:     2009-05-11 20:38:25 +0000 (Mon, 11 May 2009)

Log Message:
-----------
- ds_is_from_list() replaced with a more generc function ds_is_in_list("ip","port"). The new function takes as parameters the IP and PORT to test against the dispatcher list, instead of using only the source IP and PORT (as ds_is_from_list()).
  ds_is_from_list() == ds_is_in_list("$si","$sp")

The new function can be used also if the destination is part of a dispatching set :
   ds_is_in_list("$rd","$rp")

Modified Paths:
--------------
    trunk/modules/dispatcher/README
    trunk/modules/dispatcher/dispatch.c
    trunk/modules/dispatcher/dispatch.h
    trunk/modules/dispatcher/dispatcher.c
    trunk/modules/dispatcher/doc/dispatcher.xml
    trunk/modules/dispatcher/doc/dispatcher_admin.xml
    trunk/modules/dispatcher/doc/dispatcher_faq.xml


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


From genady.belenky at hp.com  Tue May 12 14:34:01 2009
From: genady.belenky at hp.com (Belenky, Genady (HP Software and Solutions))
Date: Tue, 12 May 2009 12:34:01 +0000
Subject: [OpenSIPS-Devel] Presence and non integrated xcap server. Did
 somebody managed to get it working?
In-Reply-To: <4A085C1F.2050108@opensips.org>
References: <1241796022506-2845885.post@n2.nabble.com>
	<4A085C1F.2050108@opensips.org>
Message-ID: <B83B7836D7025E4F855848D3F19DB9CE44568B3109@GVW1124EXC.americas.hpqcorp.net>

Hi Anca,

I will try to get eyebeam or bria licences for the proper testing. Thanks for the recommendation!
Meanwhile I just created all the necessary presence rules by myself and inserted them into OpenXCAP by using xcapclient (simulating the missing functionality in X-Lite).
    
I keep my "xcap" database tables in two different schemas - one in "opensips" and another one in "openxcap". This way I can be very close to the non-integrated XCAP server.

And I discovered the reason for the "Error [22] while performing curl operation" - this was because the value "localhost" in the openXCAP "trusted_peers" parameter was not correctly resolved. 
This caused an authorization failure in openXCAP - I also checked the openXCAP logs and they confirmed that.

After I replaced its value by 127.0.0.1, I did not get this error anymore, but I discovered another problem in the xcap_client module - "Error [23] while performing curl operation". According to the libcurl documentation it means  "An error occurred when writing received data to a local file, or an error was returned to libcurl from a write callback."

I added some debug output in xcap_functions.c, added a new errbuff variable and could see the libcurl error message in send_http_get: "Failed writing header".
After that I'm concentrated on  finding the error in get_xcap_etag - it seems that the body inside of "if(strncasecmp(ptr, ETAG_HDR, ETAG_HDR_LEN)== 0)" is not being executed. 
My debug output shows that ETAG_HDR has the value "Etag:", ETAG_HDR_LEN is set to "6" and ptr is "HTTP/1.1 200 OK"

Can it be the reason? I will still stay with 1.5.1 since I believe, I have a problem in the xcap_client and not in presence_xml. 
 
Many thanks for your help, I will keep you informed.

Best regards,
Genady

-----Original Message-----
From: Anca Vamanu [mailto:anca at opensips.org] 
Sent: Montag, 11. Mai 2009 19:11
To: Belenky, Genady (HP Software and Solutions)
Cc: devel at lists.opensips.org
Subject: Re: [OpenSIPS-Devel] Presence and non integrated xcap server. Did somebody managed to get it working?

Hi Genady,

First of all, you say that you are using X-lite for testing, but X-lite 
does not have an XCAP storage support. You should upgrade to eyebeam or 
bria for this.

However, since the non integrated xcap part has not been much tested 
lately, after reading your e-mail I decided to test it a bit. And I 
discovered some problems. The ones from Counterpath seem to have changed 
some things in the XCAP URL format (I think that they are following OMA 
standards instead of IETF).

To make it possible for OpenSIPS to use the same URL format I added two 
new parameters in presence_xml module. Here is how you should set them 
to have your platform working with eyebeam phones:

modparam("presence_xml", "pres_rules_auid", 
"org.openmobilealliance.pres-rules")
modparam("presence_xml", "pres_rules_filename", "pres-rules")

Also I would mention that if you want a change in the xcap document to 
be effective more rapidly, you should change the 'query_period' 
parameter in 'xcap_client' module to a smaller value.

I can not back port all the changes in 1.5.x branch since I changed the 
module interface for an enhancement. Therefore I would suggest you to 
upgrade to the svn trunk version at least only for the presence_xml module.

I have another observation for your configuration:  If you want to test 
the non integrated xcap behaviour, be careful not to configure openxcap 
and opensips to use the same database table for storing xcap documents ( 
I think that this is exactly the case for your configuration).

Please update and test again and if you have some other problems I will 
look into them.

regards,
Anca


genabel wrote:
> Hi,
>
> I'm trying to get the presence server (opensips 1.5.1) working together with
> a non integrated xcap server. Currently I'm using openxcap for the demo
> solution, but later I will use a commecial xcap server. In the demo solution
> scenario openxcap has it's own database schema and tables and clearly
> separated from the opensips data.
>
> The first use case is presence authorization rules related. Getting a
> watcher-info notification, the presence server should issue an xcap request
> towards the xcap server and use the information for the authorization
> decision. I created the corresponding document in openxcap and tested it
> with xcapclient.
>
> To make the life easier (tracing), I decided to use HTTP instead of HTTPS in
> openxcap.  
>
> As a client I'm using X-Lite. Both servers - opensips presence and openxcap
> are running on the same virtual machine (Ubuntu).
>
> I have the following setting in my opensips.cfg :
>
> modparam("presence|presence_xml", "db_url",
> "mysql://user:password at localhost/opensips")
> modparam("presence_xml", "force_active", 0)
> modparam("presence_xml", "pidf_manipulation", 1)
> modparam("presence_xml", "integrated_xcap_server", 0)
> modparam("presence_xml", "xcap_server", "myserver.local:8081")
> modparam("presence", "server_address", "sip:XXX.XXX.XXX.XXX:5060")
> modparam("presence", "fallback2db", 1)
>
> My openxcap is configured like that :
>
> [Server]
> address = 0.0.0.0
> port = 8081
> root = http://myserver.local
> backend = Database
> document_validation = Yes
>
>
> [Logging]
>
> [Authentication]
> type = basic
> cleartext_passwords = Yes
> default_realm = myserver.local
> trusted_peers = XXX.XXX.XXX.XXX
>
> [TLS]
> certificate = tls/server.crt
> private_key = tls/server.key
>
> [Database]
> authentication_db_uri = mysql://openxcap:openxcap at localhost/openxcap
> storage_db_uri = mysql://openxcap:openxcap at localhost/openxcap
> subscriber_table = subscriber
> xcap_table = xcap
>
> In this configuration I'm getting  "ERROR:xcap_client:send_http_get: Error
> [22] while performing curl operation" as far as the presence server is
> trying to send an xcap request to openxcap.
>
> I also noticed that even I configured my presence server as a trusted peer
> in the openxcap config file, I need to provide the user credentials in case
> I want to access this URL in firefox or curl. 
>
> Can it be the reason fot the error - missing xcap credentials configuration
> or maybe I should use https?
> And what is this curl related error message? 
>
> I'm wondering if someone got a similar environment runnig. Any debugging
> hints will be appreciated.
>
> Hope you can help me,
> Best regards,
> Genady 
>
>   



From anca at opensips.org  Wed May 13 10:46:53 2009
From: anca at opensips.org (Anca Vamanu)
Date: Wed, 13 May 2009 11:46:53 +0300
Subject: [OpenSIPS-Devel] Presence and non integrated xcap server. Did
 somebody managed to get it working?
In-Reply-To: <B83B7836D7025E4F855848D3F19DB9CE44568B3109@GVW1124EXC.americas.hpqcorp.net>
References: <1241796022506-2845885.post@n2.nabble.com>
	<4A085C1F.2050108@opensips.org>
	<B83B7836D7025E4F855848D3F19DB9CE44568B3109@GVW1124EXC.americas.hpqcorp.net>
Message-ID: <4A0A88FD.1090405@opensips.org>

 HI Genady,

You followed exactly my course of investigation. I also added an error 
buffer and discovered that there was an error when getting the etag. I 
already fixed that in xcap_client module.
You can stick with 1.5.x branch, but please take xcap_client module from 
svn branch of 1.5. It already contains the necessary fixes.
|
|# svn co 
https://opensips.svn.sourceforge.net/svnroot/opensips/branches/1.5 
opensips_1_5

Regards,
Anca

|

| 





Belenky, Genady (HP Software and Solutions) wrote:
> Hi Anca,
>
> I will try to get eyebeam or bria licences for the proper testing. Thanks for the recommendation!
> Meanwhile I just created all the necessary presence rules by myself and inserted them into OpenXCAP by using xcapclient (simulating the missing functionality in X-Lite).
>     
> I keep my "xcap" database tables in two different schemas - one in "opensips" and another one in "openxcap". This way I can be very close to the non-integrated XCAP server.
>
> And I discovered the reason for the "Error [22] while performing curl operation" - this was because the value "localhost" in the openXCAP "trusted_peers" parameter was not correctly resolved. 
> This caused an authorization failure in openXCAP - I also checked the openXCAP logs and they confirmed that.
>
> After I replaced its value by 127.0.0.1, I did not get this error anymore, but I discovered another problem in the xcap_client module - "Error [23] while performing curl operation". According to the libcurl documentation it means  "An error occurred when writing received data to a local file, or an error was returned to libcurl from a write callback."
>
> I added some debug output in xcap_functions.c, added a new errbuff variable and could see the libcurl error message in send_http_get: "Failed writing header".
> After that I'm concentrated on  finding the error in get_xcap_etag - it seems that the body inside of "if(strncasecmp(ptr, ETAG_HDR, ETAG_HDR_LEN)== 0)" is not being executed. 
> My debug output shows that ETAG_HDR has the value "Etag:", ETAG_HDR_LEN is set to "6" and ptr is "HTTP/1.1 200 OK"
>
> Can it be the reason? I will still stay with 1.5.1 since I believe, I have a problem in the xcap_client and not in presence_xml. 
>  
> Many thanks for your help, I will keep you informed.
>
> Best regards,
> Genady
>
> -----Original Message-----
> From: Anca Vamanu [mailto:anca at opensips.org] 
> Sent: Montag, 11. Mai 2009 19:11
> To: Belenky, Genady (HP Software and Solutions)
> Cc: devel at lists.opensips.org
> Subject: Re: [OpenSIPS-Devel] Presence and non integrated xcap server. Did somebody managed to get it working?
>
> Hi Genady,
>
> First of all, you say that you are using X-lite for testing, but X-lite 
> does not have an XCAP storage support. You should upgrade to eyebeam or 
> bria for this.
>
> However, since the non integrated xcap part has not been much tested 
> lately, after reading your e-mail I decided to test it a bit. And I 
> discovered some problems. The ones from Counterpath seem to have changed 
> some things in the XCAP URL format (I think that they are following OMA 
> standards instead of IETF).
>
> To make it possible for OpenSIPS to use the same URL format I added two 
> new parameters in presence_xml module. Here is how you should set them 
> to have your platform working with eyebeam phones:
>
> modparam("presence_xml", "pres_rules_auid", 
> "org.openmobilealliance.pres-rules")
> modparam("presence_xml", "pres_rules_filename", "pres-rules")
>
> Also I would mention that if you want a change in the xcap document to 
> be effective more rapidly, you should change the 'query_period' 
> parameter in 'xcap_client' module to a smaller value.
>
> I can not back port all the changes in 1.5.x branch since I changed the 
> module interface for an enhancement. Therefore I would suggest you to 
> upgrade to the svn trunk version at least only for the presence_xml module.
>
> I have another observation for your configuration:  If you want to test 
> the non integrated xcap behaviour, be careful not to configure openxcap 
> and opensips to use the same database table for storing xcap documents ( 
> I think that this is exactly the case for your configuration).
>
> Please update and test again and if you have some other problems I will 
> look into them.
>
> regards,
> Anca
>
>
> genabel wrote:
>   
>> Hi,
>>
>> I'm trying to get the presence server (opensips 1.5.1) working together with
>> a non integrated xcap server. Currently I'm using openxcap for the demo
>> solution, but later I will use a commecial xcap server. In the demo solution
>> scenario openxcap has it's own database schema and tables and clearly
>> separated from the opensips data.
>>
>> The first use case is presence authorization rules related. Getting a
>> watcher-info notification, the presence server should issue an xcap request
>> towards the xcap server and use the information for the authorization
>> decision. I created the corresponding document in openxcap and tested it
>> with xcapclient.
>>
>> To make the life easier (tracing), I decided to use HTTP instead of HTTPS in
>> openxcap.  
>>
>> As a client I'm using X-Lite. Both servers - opensips presence and openxcap
>> are running on the same virtual machine (Ubuntu).
>>
>> I have the following setting in my opensips.cfg :
>>
>> modparam("presence|presence_xml", "db_url",
>> "mysql://user:password at localhost/opensips")
>> modparam("presence_xml", "force_active", 0)
>> modparam("presence_xml", "pidf_manipulation", 1)
>> modparam("presence_xml", "integrated_xcap_server", 0)
>> modparam("presence_xml", "xcap_server", "myserver.local:8081")
>> modparam("presence", "server_address", "sip:XXX.XXX.XXX.XXX:5060")
>> modparam("presence", "fallback2db", 1)
>>
>> My openxcap is configured like that :
>>
>> [Server]
>> address = 0.0.0.0
>> port = 8081
>> root = http://myserver.local
>> backend = Database
>> document_validation = Yes
>>
>>
>> [Logging]
>>
>> [Authentication]
>> type = basic
>> cleartext_passwords = Yes
>> default_realm = myserver.local
>> trusted_peers = XXX.XXX.XXX.XXX
>>
>> [TLS]
>> certificate = tls/server.crt
>> private_key = tls/server.key
>>
>> [Database]
>> authentication_db_uri = mysql://openxcap:openxcap at localhost/openxcap
>> storage_db_uri = mysql://openxcap:openxcap at localhost/openxcap
>> subscriber_table = subscriber
>> xcap_table = xcap
>>
>> In this configuration I'm getting  "ERROR:xcap_client:send_http_get: Error
>> [22] while performing curl operation" as far as the presence server is
>> trying to send an xcap request to openxcap.
>>
>> I also noticed that even I configured my presence server as a trusted peer
>> in the openxcap config file, I need to provide the user credentials in case
>> I want to access this URL in firefox or curl. 
>>
>> Can it be the reason fot the error - missing xcap credentials configuration
>> or maybe I should use https?
>> And what is this curl related error message? 
>>
>> I'm wondering if someone got a similar environment runnig. Any debugging
>> hints will be appreciated.
>>
>> Hope you can help me,
>> Best regards,
>> Genady 
>>
>>   
>>     
>
>   



From noreply at sourceforge.net  Wed May 13 11:23:11 2009
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed, 13 May 2009 09:23:11 +0000
Subject: [OpenSIPS-Devel] [ opensips-Bugs-2791077 ] presence: wrong NOTIFY
	with "reason=timeout"
Message-ID: <E1M4AgB-0006ne-4W@d45xhf1.ch3.sourceforge.com>

Bugs item #2791077, was opened at 2009-05-13 11:23
Message generated for change (Tracker Item Submitted) made by ibc_sf
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=2791077&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: I?aki Baz Castillo (ibc_sf)
Assigned to: Nobody/Anonymous (nobody)
Summary: presence: wrong NOTIFY with "reason=timeout"

Initial Comment:
OpenSIPS trunk rev 5694.

I'm experimienting some issues in NOTIFY's from presence server module. "Sometimes" (but really often) when a refresh PUBLISH arrives (matching "SIP-If-Match") presence module generates a NOTIFY with:
  Subscription-State: terminated;reason=timeout

This forces the client to terminate the current subscription dialogs and resend a new initial SUBSCRIBE. Unfortunatelly some clients (as Qutecom) seem to react wrongly when this issue. Anyhow, I think there is some bug in the presence module behaviour.

I attach a SIP trave very simple:

- Just one user 30000 at domain.org.
- It publishes its state and subscribes to its state.

Note how the NOTIFY in line 428 has a strange header value:
  Subscription-State: terminated;reason=timeout
After it, Twinkle (which recats well on it) generates a new out-of-dialog SUBSCRIBE. But if Qutecom is being used, it doesn't generate the SUBSCRIBE (probably a bug inQutecom) and the subscription dissapear from "active_watchers" table.


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

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


From anca at opensips.org  Wed May 13 11:45:38 2009
From: anca at opensips.org (Anca Vamanu)
Date: Wed, 13 May 2009 09:45:38 +0000
Subject: [OpenSIPS-Devel] SF.net SVN: opensips:[5701] trunk/modules/pua
Message-ID: <E1M4B1u-00043g-7j@dn4whf1.ch3.sourceforge.com>

Revision: 5701
          http://opensips.svn.sourceforge.net/opensips/?rev=5701&view=rev
Author:   anca_vamanu
Date:     2009-05-13 09:45:37 +0000 (Wed, 13 May 2009)

Log Message:
-----------
- fixed a bug in pua module that caused memory leak

Modified Paths:
--------------
    trunk/modules/pua/add_events.c
    trunk/modules/pua/send_subscribe.c


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


From anca at opensips.org  Wed May 13 11:47:33 2009
From: anca at opensips.org (Anca Vamanu)
Date: Wed, 13 May 2009 09:47:33 +0000
Subject: [OpenSIPS-Devel] SF.net SVN: opensips:[5702]
	branches/1.5/modules/pua
Message-ID: <E1M4B3l-000474-JU@dn4whf1.ch3.sourceforge.com>

Revision: 5702
          http://opensips.svn.sourceforge.net/opensips/?rev=5702&view=rev
Author:   anca_vamanu
Date:     2009-05-13 09:47:33 +0000 (Wed, 13 May 2009)

Log Message:
-----------
- fixed a bug in pua module that caused memory leak

Modified Paths:
--------------
    branches/1.5/modules/pua/add_events.c
    branches/1.5/modules/pua/send_subscribe.c


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


From anca at opensips.org  Wed May 13 11:50:15 2009
From: anca at opensips.org (Anca Vamanu)
Date: Wed, 13 May 2009 09:50:15 +0000
Subject: [OpenSIPS-Devel] SF.net SVN: opensips:[5703]
	branches/1.4/modules/pua
Message-ID: <E1M4B6N-00049X-Id@dn4whf1.ch3.sourceforge.com>

Revision: 5703
          http://opensips.svn.sourceforge.net/opensips/?rev=5703&view=rev
Author:   anca_vamanu
Date:     2009-05-13 09:50:15 +0000 (Wed, 13 May 2009)

Log Message:
-----------
- fixed a bug in pua module that caused memory leak

Modified Paths:
--------------
    branches/1.4/modules/pua/add_events.c
    branches/1.4/modules/pua/send_subscribe.c


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


From genady.belenky at hp.com  Wed May 13 11:54:17 2009
From: genady.belenky at hp.com (Belenky, Genady (HP Software and Solutions))
Date: Wed, 13 May 2009 09:54:17 +0000
Subject: [OpenSIPS-Devel] Presence and non integrated xcap server. Did
 somebody managed to get it working?
In-Reply-To: <4A0A88FD.1090405@opensips.org>
References: <1241796022506-2845885.post@n2.nabble.com>
	<4A085C1F.2050108@opensips.org>
	<B83B7836D7025E4F855848D3F19DB9CE44568B3109@GVW1124EXC.americas.hpqcorp.net>
	<4A0A88FD.1090405@opensips.org>
Message-ID: <B83B7836D7025E4F855848D3F19DB9CE4456ADD427@GVW1124EXC.americas.hpqcorp.net>

Hi Anca,

Thank you very much for your reply.
 
I took the latest xcap_client source from the trunk, copied the source code in to my 1.5.1 workspace and could see that the etag issue had been solved.

Now I discovered the following mysql problem:

DBG:xcap_client:send_http_get: path = [buratino.local/pres-rules/users/sip:genady at buratino.local/index]
DBG:xcap_client:send_http_get: send_http_get return code 200. Content length=433
ERROR:db_mysql:db_mysql_val2str: destination buffer too short
ERROR:core:db_print_values: Error while converting value to string
ERROR:xcap_client:xcapGetNewDoc: in sql insert
ERROR:presence_xml:http_get_rules_doc: while fetching data from xcap server

This happens apparently when the document is about to be stored in the db - something wrong happens to the field buffer. I will check exactly what field it is. I think, something is wrong with the document blob.

I will keep you updated.

Best regards,
Genady

-----Original Message-----
From: Anca Vamanu [mailto:anca at opensips.org] 
Sent: Mittwoch, 13. Mai 2009 10:47
To: Belenky, Genady (HP Software and Solutions)
Cc: devel at lists.opensips.org
Subject: Re: [OpenSIPS-Devel] Presence and non integrated xcap server. Did somebody managed to get it working?

 HI Genady,

You followed exactly my course of investigation. I also added an error 
buffer and discovered that there was an error when getting the etag. I 
already fixed that in xcap_client module.
You can stick with 1.5.x branch, but please take xcap_client module from 
svn branch of 1.5. It already contains the necessary fixes.
|
|# svn co 
https://opensips.svn.sourceforge.net/svnroot/opensips/branches/1.5 
opensips_1_5

Regards,
Anca

|

| 





Belenky, Genady (HP Software and Solutions) wrote:
> Hi Anca,
>
> I will try to get eyebeam or bria licences for the proper testing. Thanks for the recommendation!
> Meanwhile I just created all the necessary presence rules by myself and inserted them into OpenXCAP by using xcapclient (simulating the missing functionality in X-Lite).
>     
> I keep my "xcap" database tables in two different schemas - one in "opensips" and another one in "openxcap". This way I can be very close to the non-integrated XCAP server.
>
> And I discovered the reason for the "Error [22] while performing curl operation" - this was because the value "localhost" in the openXCAP "trusted_peers" parameter was not correctly resolved. 
> This caused an authorization failure in openXCAP - I also checked the openXCAP logs and they confirmed that.
>
> After I replaced its value by 127.0.0.1, I did not get this error anymore, but I discovered another problem in the xcap_client module - "Error [23] while performing curl operation". According to the libcurl documentation it means  "An error occurred when writing received data to a local file, or an error was returned to libcurl from a write callback."
>
> I added some debug output in xcap_functions.c, added a new errbuff variable and could see the libcurl error message in send_http_get: "Failed writing header".
> After that I'm concentrated on  finding the error in get_xcap_etag - it seems that the body inside of "if(strncasecmp(ptr, ETAG_HDR, ETAG_HDR_LEN)== 0)" is not being executed. 
> My debug output shows that ETAG_HDR has the value "Etag:", ETAG_HDR_LEN is set to "6" and ptr is "HTTP/1.1 200 OK"
>
> Can it be the reason? I will still stay with 1.5.1 since I believe, I have a problem in the xcap_client and not in presence_xml. 
>  
> Many thanks for your help, I will keep you informed.
>
> Best regards,
> Genady
>
> -----Original Message-----
> From: Anca Vamanu [mailto:anca at opensips.org] 
> Sent: Montag, 11. Mai 2009 19:11
> To: Belenky, Genady (HP Software and Solutions)
> Cc: devel at lists.opensips.org
> Subject: Re: [OpenSIPS-Devel] Presence and non integrated xcap server. Did somebody managed to get it working?
>
> Hi Genady,
>
> First of all, you say that you are using X-lite for testing, but X-lite 
> does not have an XCAP storage support. You should upgrade to eyebeam or 
> bria for this.
>
> However, since the non integrated xcap part has not been much tested 
> lately, after reading your e-mail I decided to test it a bit. And I 
> discovered some problems. The ones from Counterpath seem to have changed 
> some things in the XCAP URL format (I think that they are following OMA 
> standards instead of IETF).
>
> To make it possible for OpenSIPS to use the same URL format I added two 
> new parameters in presence_xml module. Here is how you should set them 
> to have your platform working with eyebeam phones:
>
> modparam("presence_xml", "pres_rules_auid", 
> "org.openmobilealliance.pres-rules")
> modparam("presence_xml", "pres_rules_filename", "pres-rules")
>
> Also I would mention that if you want a change in the xcap document to 
> be effective more rapidly, you should change the 'query_period' 
> parameter in 'xcap_client' module to a smaller value.
>
> I can not back port all the changes in 1.5.x branch since I changed the 
> module interface for an enhancement. Therefore I would suggest you to 
> upgrade to the svn trunk version at least only for the presence_xml module.
>
> I have another observation for your configuration:  If you want to test 
> the non integrated xcap behaviour, be careful not to configure openxcap 
> and opensips to use the same database table for storing xcap documents ( 
> I think that this is exactly the case for your configuration).
>
> Please update and test again and if you have some other problems I will 
> look into them.
>
> regards,
> Anca
>
>
> genabel wrote:
>   
>> Hi,
>>
>> I'm trying to get the presence server (opensips 1.5.1) working together with
>> a non integrated xcap server. Currently I'm using openxcap for the demo
>> solution, but later I will use a commecial xcap server. In the demo solution
>> scenario openxcap has it's own database schema and tables and clearly
>> separated from the opensips data.
>>
>> The first use case is presence authorization rules related. Getting a
>> watcher-info notification, the presence server should issue an xcap request
>> towards the xcap server and use the information for the authorization
>> decision. I created the corresponding document in openxcap and tested it
>> with xcapclient.
>>
>> To make the life easier (tracing), I decided to use HTTP instead of HTTPS in
>> openxcap.  
>>
>> As a client I'm using X-Lite. Both servers - opensips presence and openxcap
>> are running on the same virtual machine (Ubuntu).
>>
>> I have the following setting in my opensips.cfg :
>>
>> modparam("presence|presence_xml", "db_url",
>> "mysql://user:password at localhost/opensips")
>> modparam("presence_xml", "force_active", 0)
>> modparam("presence_xml", "pidf_manipulation", 1)
>> modparam("presence_xml", "integrated_xcap_server", 0)
>> modparam("presence_xml", "xcap_server", "myserver.local:8081")
>> modparam("presence", "server_address", "sip:XXX.XXX.XXX.XXX:5060")
>> modparam("presence", "fallback2db", 1)
>>
>> My openxcap is configured like that :
>>
>> [Server]
>> address = 0.0.0.0
>> port = 8081
>> root = http://myserver.local
>> backend = Database
>> document_validation = Yes
>>
>>
>> [Logging]
>>
>> [Authentication]
>> type = basic
>> cleartext_passwords = Yes
>> default_realm = myserver.local
>> trusted_peers = XXX.XXX.XXX.XXX
>>
>> [TLS]
>> certificate = tls/server.crt
>> private_key = tls/server.key
>>
>> [Database]
>> authentication_db_uri = mysql://openxcap:openxcap at localhost/openxcap
>> storage_db_uri = mysql://openxcap:openxcap at localhost/openxcap
>> subscriber_table = subscriber
>> xcap_table = xcap
>>
>> In this configuration I'm getting  "ERROR:xcap_client:send_http_get: Error
>> [22] while performing curl operation" as far as the presence server is
>> trying to send an xcap request to openxcap.
>>
>> I also noticed that even I configured my presence server as a trusted peer
>> in the openxcap config file, I need to provide the user credentials in case
>> I want to access this URL in firefox or curl. 
>>
>> Can it be the reason fot the error - missing xcap credentials configuration
>> or maybe I should use https?
>> And what is this curl related error message? 
>>
>> I'm wondering if someone got a similar environment runnig. Any debugging
>> hints will be appreciated.
>>
>> Hope you can help me,
>> Best regards,
>> Genady 
>>
>>   
>>     
>
>   



From anca at opensips.org  Wed May 13 11:59:20 2009
From: anca at opensips.org (Anca Vamanu)
Date: Wed, 13 May 2009 09:59:20 +0000
Subject: [OpenSIPS-Devel] SF.net SVN: opensips:[5704]
	trunk/modules/presence/presence.c
Message-ID: <E1M4BFA-0004Jx-QK@dn4whf1.ch3.sourceforge.com>

Revision: 5704
          http://opensips.svn.sourceforge.net/opensips/?rev=5704&view=rev
Author:   anca_vamanu
Date:     2009-05-13 09:59:20 +0000 (Wed, 13 May 2009)

Log Message:
-----------
- took out a remaining usage of prepare statements when more rows are expected that caused bad behaviour in presence server with integrated xcap server operation mode

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


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


From anca at opensips.org  Wed May 13 12:59:13 2009
From: anca at opensips.org (Anca Vamanu)
Date: Wed, 13 May 2009 10:59:13 +0000
Subject: [OpenSIPS-Devel] SF.net SVN: opensips:[5705] trunk/modules/presence
Message-ID: <E1M4CB7-00013n-61@bj8yhf1.ch3.sourceforge.com>

Revision: 5705
          http://opensips.svn.sourceforge.net/opensips/?rev=5705&view=rev
Author:   anca_vamanu
Date:     2009-05-13 10:59:12 +0000 (Wed, 13 May 2009)

Log Message:
-----------
- fixed not updating expires value from subscription dialogs in database when refresh Subscribe received ( reported by Inaki Baz Castillo in bug report #2791077)

Modified Paths:
--------------
    trunk/modules/presence/notify.c
    trunk/modules/presence/subscribe.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 May 13 13:12:46 2009
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed, 13 May 2009 11:12:46 +0000
Subject: [OpenSIPS-Devel] [ opensips-Bugs-2791077 ] presence: wrong NOTIFY
	with "reason=timeout"
Message-ID: <E1M4COE-0008Qh-Vd@h45xhf1.ch3.sourceforge.com>

Bugs item #2791077, was opened at 2009-05-13 12:23
Message generated for change (Comment added) made by anca_vamanu
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=2791077&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: I?aki Baz Castillo (ibc_sf)
Assigned to: Nobody/Anonymous (nobody)
Summary: presence: wrong NOTIFY with "reason=timeout"

Initial Comment:
OpenSIPS trunk rev 5694.

I'm experimienting some issues in NOTIFY's from presence server module. "Sometimes" (but really often) when a refresh PUBLISH arrives (matching "SIP-If-Match") presence module generates a NOTIFY with:
  Subscription-State: terminated;reason=timeout

This forces the client to terminate the current subscription dialogs and resend a new initial SUBSCRIBE. Unfortunatelly some clients (as Qutecom) seem to react wrongly when this issue. Anyhow, I think there is some bug in the presence module behaviour.

I attach a SIP trave very simple:

- Just one user 30000 at domain.org.
- It publishes its state and subscribes to its state.

Note how the NOTIFY in line 428 has a strange header value:
  Subscription-State: terminated;reason=timeout
After it, Twinkle (which recats well on it) generates a new out-of-dialog SUBSCRIBE. But if Qutecom is being used, it doesn't generate the SUBSCRIBE (probably a bug inQutecom) and the subscription dissapear from "active_watchers" table.


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

>Comment By: Anca Vamanu (anca_vamanu)
Date: 2009-05-13 14:12

Message:
Hi Inaki,

Thanks for the detailed report.
I have found the bug - the expires value was not updated in database when
a refresh Subscribe was received - and since you are using the fallback2bd
mode it caused that erroneous ending of dialog.
Please update and test again.

Thanks and regards,
Anca 

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

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


From anca at opensips.org  Wed May 13 13:15:30 2009
From: anca at opensips.org (Anca Vamanu)
Date: Wed, 13 May 2009 11:15:30 +0000
Subject: [OpenSIPS-Devel] SF.net SVN: opensips:[5706]
	branches/1.5/modules/presence
Message-ID: <E1M4CQs-0001kU-TQ@bj8yhf1.ch3.sourceforge.com>

Revision: 5706
          http://opensips.svn.sourceforge.net/opensips/?rev=5706&view=rev
Author:   anca_vamanu
Date:     2009-05-13 11:15:30 +0000 (Wed, 13 May 2009)

Log Message:
-----------
- fixed not updating expires value from subscription dialogs in database when refresh Subscribe received ( reported by Inaki Baz Castillo in bug report #2791077)

Modified Paths:
--------------
    branches/1.5/modules/presence/notify.c
    branches/1.5/modules/presence/subscribe.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 May 13 15:36:52 2009
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed, 13 May 2009 13:36:52 +0000
Subject: [OpenSIPS-Devel] [ opensips-Bugs-2791186 ] [presence] crazy NOTIFY's
Message-ID: <E1M4Edg-0005sL-Hf@155xhf1.ch3.sourceforge.com>

Bugs item #2791186, was opened at 2009-05-13 15:36
Message generated for change (Tracker Item Submitted) made by ibc_sf
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=2791186&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: I?aki Baz Castillo (ibc_sf)
Assigned to: Nobody/Anonymous (nobody)
Summary: [presence] crazy NOTIFY's

Initial Comment:
Rev 5706.

modparam("presence", "max_expires_publish", 30)
modparam("presence", "max_expires_subscribe", 40)
modparam("presence", "expires_offset", 5)
modparam("presence", "fallback2db", 1)


Just one client subscribed to itself (30004). All works well at the beginning, but after some time OpenSIPS starts sending *a lot* of NOTIFY's (no retransmissions) in the same seconds (for the same subscription dialog and with the same info).
This causes the client (Qutecom) replying "500 Retry Later".

I attach a very long capture, but go to line 3265 to see the issue.


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

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


From noreply at sourceforge.net  Wed May 13 16:09:13 2009
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed, 13 May 2009 14:09:13 +0000
Subject: [OpenSIPS-Devel] [ opensips-Bugs-2791186 ] [presence] crazy NOTIFY's
Message-ID: <E1M4F8z-0004BH-Ha@1bkjzd1.ch3.sourceforge.com>

Bugs item #2791186, was opened at 2009-05-13 15:36
Message generated for change (Comment added) made by ibc_sf
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=2791186&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: I?aki Baz Castillo (ibc_sf)
Assigned to: Nobody/Anonymous (nobody)
Summary: [presence] crazy NOTIFY's

Initial Comment:
Rev 5706.

modparam("presence", "max_expires_publish", 30)
modparam("presence", "max_expires_subscribe", 40)
modparam("presence", "expires_offset", 5)
modparam("presence", "fallback2db", 1)


Just one client subscribed to itself (30004). All works well at the beginning, but after some time OpenSIPS starts sending *a lot* of NOTIFY's (no retransmissions) in the same seconds (for the same subscription dialog and with the same info).
This causes the client (Qutecom) replying "500 Retry Later".

I attach a very long capture, but go to line 3265 to see the issue.


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

>Comment By: I?aki Baz Castillo (ibc_sf)
Date: 2009-05-13 16:09

Message:
I can reproduce this error with Qutecom trunk (which has a not very good
presence implementation). I cna't reproduce it with Twinkle which works
perfectly now.

But anyway, it's very strange so many NOTIFY's for the same dialog, isn't?

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

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


From noreply at sourceforge.net  Wed May 13 16:17:59 2009
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed, 13 May 2009 14:17:59 +0000
Subject: [OpenSIPS-Devel] [ opensips-Bugs-2791186 ] [presence] crazy NOTIFY's
Message-ID: <E1M4FHT-000665-6H@665xhf1.ch3.sourceforge.com>

Bugs item #2791186, was opened at 2009-05-13 16:36
Message generated for change (Comment added) made by anca_vamanu
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=2791186&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: I?aki Baz Castillo (ibc_sf)
Assigned to: Nobody/Anonymous (nobody)
Summary: [presence] crazy NOTIFY's

Initial Comment:
Rev 5706.

modparam("presence", "max_expires_publish", 30)
modparam("presence", "max_expires_subscribe", 40)
modparam("presence", "expires_offset", 5)
modparam("presence", "fallback2db", 1)


Just one client subscribed to itself (30004). All works well at the beginning, but after some time OpenSIPS starts sending *a lot* of NOTIFY's (no retransmissions) in the same seconds (for the same subscription dialog and with the same info).
This causes the client (Qutecom) replying "500 Retry Later".

I attach a very long capture, but go to line 3265 to see the issue.


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

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

Message:
Yes, it is very strange - and it seems like the presence module generates a
couple of Notifies one after the other. I will look into this.

Anca

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

Comment By: I?aki Baz Castillo (ibc_sf)
Date: 2009-05-13 17:09

Message:
I can reproduce this error with Qutecom trunk (which has a not very good
presence implementation). I cna't reproduce it with Twinkle which works
perfectly now.

But anyway, it's very strange so many NOTIFY's for the same dialog, isn't?

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

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


From noreply at sourceforge.net  Wed May 13 16:21:48 2009
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed, 13 May 2009 14:21:48 +0000
Subject: [OpenSIPS-Devel] [ opensips-Bugs-2791186 ] [presence] crazy NOTIFY's
Message-ID: <E1M4FLA-0004mE-LH@b55xhf1.ch3.sourceforge.com>

Bugs item #2791186, was opened at 2009-05-13 15:36
Message generated for change (Comment added) made by ibc_sf
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=2791186&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: I?aki Baz Castillo (ibc_sf)
Assigned to: Nobody/Anonymous (nobody)
Summary: [presence] crazy NOTIFY's

Initial Comment:
Rev 5706.

modparam("presence", "max_expires_publish", 30)
modparam("presence", "max_expires_subscribe", 40)
modparam("presence", "expires_offset", 5)
modparam("presence", "fallback2db", 1)


Just one client subscribed to itself (30004). All works well at the beginning, but after some time OpenSIPS starts sending *a lot* of NOTIFY's (no retransmissions) in the same seconds (for the same subscription dialog and with the same info).
This causes the client (Qutecom) replying "500 Retry Later".

I attach a very long capture, but go to line 3265 to see the issue.


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

>Comment By: I?aki Baz Castillo (ibc_sf)
Date: 2009-05-13 16:21

Message:
Take into account that I have a proxy between clients and presence server
(and I forgot to filter one of them with ngrep).

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

Comment By: Anca Vamanu (anca_vamanu)
Date: 2009-05-13 16:17

Message:
Yes, it is very strange - and it seems like the presence module generates a
couple of Notifies one after the other. I will look into this.

Anca

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

Comment By: I?aki Baz Castillo (ibc_sf)
Date: 2009-05-13 16:09

Message:
I can reproduce this error with Qutecom trunk (which has a not very good
presence implementation). I cna't reproduce it with Twinkle which works
perfectly now.

But anyway, it's very strange so many NOTIFY's for the same dialog, isn't?

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

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


From noreply at sourceforge.net  Wed May 13 17:21:56 2009
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed, 13 May 2009 15:21:56 +0000
Subject: [OpenSIPS-Devel] [ opensips-Bugs-2791186 ] [presence] crazy NOTIFY's
Message-ID: <E1M4GHM-00084m-45@h45xhf1.ch3.sourceforge.com>

Bugs item #2791186, was opened at 2009-05-13 16:36
Message generated for change (Comment added) made by anca_vamanu
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=2791186&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: I?aki Baz Castillo (ibc_sf)
Assigned to: Nobody/Anonymous (nobody)
Summary: [presence] crazy NOTIFY's

Initial Comment:
Rev 5706.

modparam("presence", "max_expires_publish", 30)
modparam("presence", "max_expires_subscribe", 40)
modparam("presence", "expires_offset", 5)
modparam("presence", "fallback2db", 1)


Just one client subscribed to itself (30004). All works well at the beginning, but after some time OpenSIPS starts sending *a lot* of NOTIFY's (no retransmissions) in the same seconds (for the same subscription dialog and with the same info).
This causes the client (Qutecom) replying "500 Retry Later".

I attach a very long capture, but go to line 3265 to see the issue.


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

>Comment By: Anca Vamanu (anca_vamanu)
Date: 2009-05-13 18:21

Message:
It must be faith that the line in your file(3265) is exactly the number for
the RFC about sip event notifications (http://www.ietf.org/rfc/rfc3265.txt)
:) . 

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

Comment By: I?aki Baz Castillo (ibc_sf)
Date: 2009-05-13 17:21

Message:
Take into account that I have a proxy between clients and presence server
(and I forgot to filter one of them with ngrep).

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

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

Message:
Yes, it is very strange - and it seems like the presence module generates a
couple of Notifies one after the other. I will look into this.

Anca

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

Comment By: I?aki Baz Castillo (ibc_sf)
Date: 2009-05-13 17:09

Message:
I can reproduce this error with Qutecom trunk (which has a not very good
presence implementation). I cna't reproduce it with Twinkle which works
perfectly now.

But anyway, it's very strange so many NOTIFY's for the same dialog, isn't?

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

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


From mauro.davi at acotel.com  Thu May 14 16:40:08 2009
From: mauro.davi at acotel.com (=?us-ascii?Q?Mauro_Davi=27?=)
Date: Thu, 14 May 2009 16:40:08 +0200
Subject: [OpenSIPS-Devel] next_branch function, NAT and PATH (RFC 3327)
Message-ID: <E46BD5F8F26EE6489F2C246C0BBDB908029FA33E@office01.office.itrm.acotel.com>

Hi All,

 

I'm using a SIP Server connected to a SIP Proxy (load balancer)

When a client behind NAT is connected to the SIP flatform all works
fine, except one issue:

If I call an AOR via parallel fork all goes fine...

But if I use a serial forking, when I call the next_branch function to
handle a serial forking the INVITE from the server isn't sent to the SIP
Proxy (the outbound proxy defined in the PATH HF of the REGISTER).

It seems that also the received parameter isn't used... The INVITE go
direct to the private IP of the client behind NAT...

It is a mistake in my opensips configuration or it is a real BUG...

 

Could anyone give me a suggestion?

 

Thanks in advance

            MD

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.opensips.org/pipermail/devel/attachments/20090514/9250f872/attachment.htm 

From noreply at sourceforge.net  Thu May 14 17:02:07 2009
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 14 May 2009 15:02:07 +0000
Subject: [OpenSIPS-Devel] [ opensips-Bugs-2791758 ] xcap_client fails to
	store the xcap document in the database
Message-ID: <E1M4cRj-0001Pr-0T@h45xhf1.ch3.sourceforge.com>

Bugs item #2791758, was opened at 2009-05-14 17:02
Message generated for change (Tracker Item Submitted) made by genabel
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=2791758&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: genady (genabel)
Assigned to: Nobody/Anonymous (nobody)
Summary: xcap_client fails to store the xcap document in the database

Initial Comment:
the xcap document fetched from the non integrated xcap server cannot be saved in the mysql database. The error messages are:

ERROR:db_mysql:db_mysql_val2str: destination buffer too short
ERROR:core:db_print_values: Error while converting value to string

I analysed the source code of xcap_functions.c xcapGetNewDoc and found out that instead of str structure, char* and string_val should be used.  
This is due to fact, that in db_mysql/val.c db_mysql_val2str something goes wrong here:
	if (*_len < (VAL_STR(_v).len * 2 + 3)) {
	  LM_ERR("destination buffer too short\n");
	  return -6;
	...

This line caused bug:
query_vals[n_query_cols].val.str_val = user;

This solves the problem:
query_vals[n_query_cols].val.string_val = user.s;

This is also valid for the domain parameter passed to , here is the snippet of the working code, storing the data in the database:

	/* insert in xcap table*/
	query_cols[n_query_cols] = &str_username_col;
	query_vals[n_query_cols].type = DB_STR;
	query_vals[n_query_cols].nul = 0;
	query_vals[n_query_cols].val.string_val = user.s;
	n_query_cols++;
	
	query_cols[n_query_cols] = &str_domain_col;
	query_vals[n_query_cols].type = DB_STR;
	query_vals[n_query_cols].nul = 0;
	query_vals[n_query_cols].val.string_val = domain.s;
	n_query_cols++;
	
	query_cols[n_query_cols] = &str_doc_col;
	query_vals[n_query_cols].type = DB_BLOB;
	query_vals[n_query_cols].nul = 0;
	query_vals[n_query_cols].val.string_val= doc;
	n_query_cols++;

	query_cols[n_query_cols] = &str_doc_type_col;
	query_vals[n_query_cols].type = DB_INT;
	query_vals[n_query_cols].nul = 0;
	query_vals[n_query_cols].val.int_val= req.doc_sel.doc_type;
	n_query_cols++;

	query_cols[n_query_cols] = &str_etag_col;
	query_vals[n_query_cols].type = DB_STRING;
	query_vals[n_query_cols].nul = 0;
	query_vals[n_query_cols].val.string_val= etag;
	n_query_cols++;

	query_cols[n_query_cols] = &str_source_col;
	query_vals[n_query_cols].type = DB_INT;
	query_vals[n_query_cols].nul = 0;
	query_vals[n_query_cols].val.int_val= XCAP_CL_MOD;
	n_query_cols++;

	query_cols[n_query_cols] = &str_doc_uri_col;
	query_vals[n_query_cols].type = DB_STRING;
	query_vals[n_query_cols].nul = 0;
	query_vals[n_query_cols].val.string_val= path;
	n_query_cols++;
	
	query_cols[n_query_cols] = &str_port_col;
	query_vals[n_query_cols].type = DB_INT;
	query_vals[n_query_cols].nul = 0;
	query_vals[n_query_cols].val.int_val= req.port;
	n_query_cols++;

The 100% solution is to fix the db_mysql/val.c db_mysql_val2str for str type.

Regards, Genady 

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

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


From anca at opensips.org  Thu May 14 17:22:48 2009
From: anca at opensips.org (Anca Vamanu)
Date: Thu, 14 May 2009 15:22:48 +0000
Subject: [OpenSIPS-Devel] SF.net SVN: opensips:[5707]
	trunk/modules/pua/send_publish.c
Message-ID: <E1M4clk-0005Un-PO@74yxhf1.ch3.sourceforge.com>

Revision: 5707
          http://opensips.svn.sourceforge.net/opensips/?rev=5707&view=rev
Author:   anca_vamanu
Date:     2009-05-14 15:22:48 +0000 (Thu, 14 May 2009)

Log Message:
-----------
- fixed a race condition that caused using the same E-tag twice (generating a subsequent Publish before the reply for the previous is received) - reported by Piotr Sobolewski <sobolewski at gmail.com>

Modified Paths:
--------------
    trunk/modules/pua/send_publish.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 May 14 17:31:38 2009
From: anca at opensips.org (Anca Vamanu)
Date: Thu, 14 May 2009 15:31:38 +0000
Subject: [OpenSIPS-Devel] SF.net SVN: opensips:[5708]
	branches/1.5/modules/pua/send_publish.c
Message-ID: <E1M4cuI-00060J-Pm@74yxhf1.ch3.sourceforge.com>

Revision: 5708
          http://opensips.svn.sourceforge.net/opensips/?rev=5708&view=rev
Author:   anca_vamanu
Date:     2009-05-14 15:31:38 +0000 (Thu, 14 May 2009)

Log Message:
-----------
- fixed a race condition that caused using the same E-tag twice (generating a subsequent Publish before the reply for the previous is received) - reported by Piotr Sobolewski <sobolewski at gmail.com>

Modified Paths:
--------------
    branches/1.5/modules/pua/send_publish.c


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 May 14 17:42:38 2009
From: dan at ag-projects.com (Dan Pascu)
Date: Thu, 14 May 2009 18:42:38 +0300
Subject: [OpenSIPS-Devel] SF.net SVN: opensips:[5708]
	branches/1.5/modules/pua/send_publish.c
In-Reply-To: <E1M4cuI-00060J-Pm@74yxhf1.ch3.sourceforge.com>
References: <E1M4cuI-00060J-Pm@74yxhf1.ch3.sourceforge.com>
Message-ID: <200905141842.38898.dan@ag-projects.com>


If this fix applies to 1.4 as well, can we get a backport please?

On Thursday 14 May 2009, Anca Vamanu wrote:
> Revision: 5708
>           
http://opensips.svn.sourceforge.net/opensips/?rev=5708&view=rev
> Author:   anca_vamanu
> Date:     2009-05-14 15:31:38 +0000 (Thu, 14 May 2009)
> 
> Log Message:
> -----------
> - fixed a race condition that caused using the same E-tag twice 
(generating a subsequent Publish before the reply for the previous is 
received) - reported by Piotr Sobolewski <sobolewski at gmail.com>
> 
> Modified Paths:
> --------------
>     branches/1.5/modules/pua/send_publish.c
> 
> 
> This was sent by the SourceForge.net collaborative development platform, 
the world's largest Open Source development site.
> 
> _______________________________________________
> Devel mailing list
> Devel at lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
> 
> 


-- 
Dan


From ibc at aliax.net  Thu May 14 18:53:51 2009
From: ibc at aliax.net (=?UTF-8?Q?I=C3=B1aki_Baz_Castillo?=)
Date: Thu, 14 May 2009 18:53:51 +0200
Subject: [OpenSIPS-Devel] next_branch function, NAT and PATH (RFC 3327)
In-Reply-To: <E46BD5F8F26EE6489F2C246C0BBDB908029FA33E@office01.office.itrm.acotel.com>
References: <E46BD5F8F26EE6489F2C246C0BBDB908029FA33E@office01.office.itrm.acotel.com>
Message-ID: <cc1f582e0905140953l25e7351eh83ced72284ce4fbf@mail.gmail.com>

2009/5/14 Mauro Davi' <mauro.davi at acotel.com>:
> Hi All,

Hi Mauro, please send such a question just to "users" maillist (but no "devel").

Thanks.


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


From anca at opensips.org  Mon May 18 11:06:09 2009
From: anca at opensips.org (Anca Vamanu)
Date: Mon, 18 May 2009 09:06:09 +0000
Subject: [OpenSIPS-Devel] SF.net SVN: opensips:[5709]
	trunk/modules/presence/presence.c
Message-ID: <E1M5ynR-0002xk-3y@bj8yhf1.ch3.sourceforge.com>

Revision: 5709
          http://opensips.svn.sourceforge.net/opensips/?rev=5709&view=rev
Author:   anca_vamanu
Date:     2009-05-18 09:06:08 +0000 (Mon, 18 May 2009)

Log Message:
-----------
- fixed a bug in constructing watcher info event Notify bodies when refreshWatchers MI command was received (reported by Franz Edler <franz-edler at aon.at>)

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


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


From anca at opensips.org  Mon May 18 11:08:33 2009
From: anca at opensips.org (Anca Vamanu)
Date: Mon, 18 May 2009 09:08:33 +0000
Subject: [OpenSIPS-Devel] SF.net SVN: opensips:[5710]
	branches/1.5/modules/presence/presence.c
Message-ID: <E1M5ypl-00030K-H1@bj8yhf1.ch3.sourceforge.com>

Revision: 5710
          http://opensips.svn.sourceforge.net/opensips/?rev=5710&view=rev
Author:   anca_vamanu
Date:     2009-05-18 09:08:33 +0000 (Mon, 18 May 2009)

Log Message:
-----------
- fixed a bug in constructing watcher info event Notify bodies when refreshWatchers MI command was received (reported by Franz Edler <franz-edler at aon.at>)

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


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


From anca at opensips.org  Mon May 18 11:10:06 2009
From: anca at opensips.org (Anca Vamanu)
Date: Mon, 18 May 2009 09:10:06 +0000
Subject: [OpenSIPS-Devel] SF.net SVN: opensips:[5711]
	branches/1.4/modules/presence/presence.c
Message-ID: <E1M5yrG-000342-8G@bj8yhf1.ch3.sourceforge.com>

Revision: 5711
          http://opensips.svn.sourceforge.net/opensips/?rev=5711&view=rev
Author:   anca_vamanu
Date:     2009-05-18 09:10:06 +0000 (Mon, 18 May 2009)

Log Message:
-----------
- fixed a bug in constructing watcher info event Notify bodies when refreshWatchers MI command was received (reported by Franz Edler <franz-edler at aon.at>)

Modified Paths:
--------------
    branches/1.4/modules/presence/presence.c


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


From anca at opensips.org  Mon May 18 12:57:19 2009
From: anca at opensips.org (Anca Vamanu)
Date: Mon, 18 May 2009 10:57:19 +0000
Subject: [OpenSIPS-Devel] SF.net SVN: opensips:[5712]
	trunk/modules/pua/send_publish.c
Message-ID: <E1M60X1-0003Sr-4y@d5vjzd1.ch3.sourceforge.com>

Revision: 5712
          http://opensips.svn.sourceforge.net/opensips/?rev=5712&view=rev
Author:   anca_vamanu
Date:     2009-05-18 10:57:18 +0000 (Mon, 18 May 2009)

Log Message:
-----------
- completion for the fix in rev #5708; added etag restriction when searching for a pua record that received a negative reply ( thanks to Piotr Sobolewski <sobolewski at gmail.com> for help with testing)

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

Modified Paths:
--------------
    trunk/modules/pua/send_publish.c


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


From anca at opensips.org  Mon May 18 12:58:04 2009
From: anca at opensips.org (Anca Vamanu)
Date: Mon, 18 May 2009 10:58:04 +0000
Subject: [OpenSIPS-Devel] SF.net SVN: opensips:[5713]
	branches/1.5/modules/pua/send_publish.c
Message-ID: <E1M60Xk-0003UQ-Ed@d5vjzd1.ch3.sourceforge.com>

Revision: 5713
          http://opensips.svn.sourceforge.net/opensips/?rev=5713&view=rev
Author:   anca_vamanu
Date:     2009-05-18 10:58:04 +0000 (Mon, 18 May 2009)

Log Message:
-----------
- completion for the fix in rev #5708; added etag restriction when searching for a pua record that received a negative reply ( thanks to Piotr Sobolewski <sobolewski at gmail.com> for help with testing)

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

Modified Paths:
--------------
    branches/1.5/modules/pua/send_publish.c


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


From anca at opensips.org  Mon May 18 14:38:43 2009
From: anca at opensips.org (Anca Vamanu)
Date: Mon, 18 May 2009 12:38:43 +0000
Subject: [OpenSIPS-Devel] SF.net SVN: opensips:[5714]
	branches/1.4/modules/pua/send_publish.c
Message-ID: <E1M6279-0006IG-LU@d5vjzd1.ch3.sourceforge.com>

Revision: 5714
          http://opensips.svn.sourceforge.net/opensips/?rev=5714&view=rev
Author:   anca_vamanu
Date:     2009-05-18 12:38:43 +0000 (Mon, 18 May 2009)

Log Message:
-----------
- fixed a race condition that caused using the same E-tag twice (generating a subsequent Publish before the reply for the previous is received) - thanks to Piotr Sobolewski <sobolewski at gmail.com> for help with testing

Modified Paths:
--------------
    branches/1.4/modules/pua/send_publish.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 May 18 15:29:28 2009
From: bogdan at voice-system.ro (Bogdan-Andrei Iancu)
Date: Mon, 18 May 2009 13:29:28 +0000
Subject: [OpenSIPS-Devel] SF.net SVN: opensips:[5715]
	trunk/modules/dispatcher
Message-ID: <E1M62uG-0001ES-Jr@dn4whf1.ch3.sourceforge.com>

Revision: 5715
          http://opensips.svn.sourceforge.net/opensips/?rev=5715&view=rev
Author:   bogdan_iancu
Date:     2009-05-18 13:29:28 +0000 (Mon, 18 May 2009)

Log Message:
-----------
- weight support added for dispatcher (destinatinations may have different weights to be considered during the destination selection). The weights do work with all existing dispatching algorithm, except the Round-robin one.

- first stage in adding support for "destination attributes" (sutom string of properties for the destinations) - work on progress

Docs not upated yet

Modified Paths:
--------------
    trunk/modules/dispatcher/dispatch.c
    trunk/modules/dispatcher/dispatch.h
    trunk/modules/dispatcher/dispatcher.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 May 18 15:39:20 2009
From: bogdan at voice-system.ro (Bogdan-Andrei Iancu)
Date: Mon, 18 May 2009 13:39:20 +0000
Subject: [OpenSIPS-Devel] SF.net SVN: opensips:[5716] trunk
Message-ID: <E1M633o-0001RH-K2@dn4whf1.ch3.sourceforge.com>

Revision: 5716
          http://opensips.svn.sourceforge.net/opensips/?rev=5716&view=rev
Author:   bogdan_iancu
Date:     2009-05-18 13:39:20 +0000 (Mon, 18 May 2009)

Log Message:
-----------
- definition of the dispatcher table updated to include "weight" and "attrs" fields

Modified Paths:
--------------
    trunk/db/schema/dispatcher.xml
    trunk/scripts/db_berkeley/opensips/dispatcher
    trunk/scripts/db_berkeley/opensips/version
    trunk/scripts/dbtext/opensips/dispatcher
    trunk/scripts/dbtext/opensips/version
    trunk/scripts/mysql/dispatcher-create.sql
    trunk/scripts/oracle/dispatcher-create.sql
    trunk/scripts/postgres/dispatcher-create.sql


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


From noreply at sourceforge.net  Tue May 19 11:12:11 2009
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue, 19 May 2009 09:12:11 +0000
Subject: [OpenSIPS-Devel] [ opensips-Bugs-2791758 ] xcap_client fails to
	store the xcap document in the database
Message-ID: <E1M6LMp-0003wc-Sr@b55xhf1.ch3.sourceforge.com>

Bugs item #2791758, was opened at 2009-05-14 17:02
Message generated for change (Comment added) made by genabel
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=2791758&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: 9
Private: No
Submitted By: genady (genabel)
>Assigned to: Anca Vamanu (anca_vamanu)
Summary: xcap_client fails to store the xcap document in the database

Initial Comment:
the xcap document fetched from the non integrated xcap server cannot be saved in the mysql database. The error messages are:

ERROR:db_mysql:db_mysql_val2str: destination buffer too short
ERROR:core:db_print_values: Error while converting value to string

I analysed the source code of xcap_functions.c xcapGetNewDoc and found out that instead of str structure, char* and string_val should be used.  
This is due to fact, that in db_mysql/val.c db_mysql_val2str something goes wrong here:
	if (*_len < (VAL_STR(_v).len * 2 + 3)) {
	  LM_ERR("destination buffer too short\n");
	  return -6;
	...

This line caused bug:
query_vals[n_query_cols].val.str_val = user;

This solves the problem:
query_vals[n_query_cols].val.string_val = user.s;

This is also valid for the domain parameter passed to , here is the snippet of the working code, storing the data in the database:

	/* insert in xcap table*/
	query_cols[n_query_cols] = &str_username_col;
	query_vals[n_query_cols].type = DB_STR;
	query_vals[n_query_cols].nul = 0;
	query_vals[n_query_cols].val.string_val = user.s;
	n_query_cols++;
	
	query_cols[n_query_cols] = &str_domain_col;
	query_vals[n_query_cols].type = DB_STR;
	query_vals[n_query_cols].nul = 0;
	query_vals[n_query_cols].val.string_val = domain.s;
	n_query_cols++;
	
	query_cols[n_query_cols] = &str_doc_col;
	query_vals[n_query_cols].type = DB_BLOB;
	query_vals[n_query_cols].nul = 0;
	query_vals[n_query_cols].val.string_val= doc;
	n_query_cols++;

	query_cols[n_query_cols] = &str_doc_type_col;
	query_vals[n_query_cols].type = DB_INT;
	query_vals[n_query_cols].nul = 0;
	query_vals[n_query_cols].val.int_val= req.doc_sel.doc_type;
	n_query_cols++;

	query_cols[n_query_cols] = &str_etag_col;
	query_vals[n_query_cols].type = DB_STRING;
	query_vals[n_query_cols].nul = 0;
	query_vals[n_query_cols].val.string_val= etag;
	n_query_cols++;

	query_cols[n_query_cols] = &str_source_col;
	query_vals[n_query_cols].type = DB_INT;
	query_vals[n_query_cols].nul = 0;
	query_vals[n_query_cols].val.int_val= XCAP_CL_MOD;
	n_query_cols++;

	query_cols[n_query_cols] = &str_doc_uri_col;
	query_vals[n_query_cols].type = DB_STRING;
	query_vals[n_query_cols].nul = 0;
	query_vals[n_query_cols].val.string_val= path;
	n_query_cols++;
	
	query_cols[n_query_cols] = &str_port_col;
	query_vals[n_query_cols].type = DB_INT;
	query_vals[n_query_cols].nul = 0;
	query_vals[n_query_cols].val.int_val= req.port;
	n_query_cols++;

The 100% solution is to fix the db_mysql/val.c db_mysql_val2str for str type.

Regards, Genady 

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

>Comment By: genady (genabel)
Date: 2009-05-19 11:12

Message:
sorry, the BLOB handling should be done like this, since the BLOB value
must be str instead of char*:

query_cols[n_query_cols] = &str_doc_col;
query_vals[n_query_cols].type = DB_BLOB;
query_vals[n_query_cols].nul = 0;
/* change start*/
str str_doc={doc, strlen(doc)};
query_vals[n_query_cols].val.str_val= str_doc;
/* change end */ 
n_query_cols++;


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

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


From noreply at sourceforge.net  Tue May 19 12:41:24 2009
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue, 19 May 2009 10:41:24 +0000
Subject: [OpenSIPS-Devel] [ opensips-Bugs-2791758 ] xcap_client fails to
	store the xcap document in the database
Message-ID: <E1M6MlA-00073y-4k@565xhf1.ch3.sourceforge.com>

Bugs item #2791758, was opened at 2009-05-14 18:02
Message generated for change (Comment added) made by anca_vamanu
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=2791758&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: 9
Private: No
Submitted By: genady (genabel)
Assigned to: Anca Vamanu (anca_vamanu)
Summary: xcap_client fails to store the xcap document in the database

Initial Comment:
the xcap document fetched from the non integrated xcap server cannot be saved in the mysql database. The error messages are:

ERROR:db_mysql:db_mysql_val2str: destination buffer too short
ERROR:core:db_print_values: Error while converting value to string

I analysed the source code of xcap_functions.c xcapGetNewDoc and found out that instead of str structure, char* and string_val should be used.  
This is due to fact, that in db_mysql/val.c db_mysql_val2str something goes wrong here:
	if (*_len < (VAL_STR(_v).len * 2 + 3)) {
	  LM_ERR("destination buffer too short\n");
	  return -6;
	...

This line caused bug:
query_vals[n_query_cols].val.str_val = user;

This solves the problem:
query_vals[n_query_cols].val.string_val = user.s;

This is also valid for the domain parameter passed to , here is the snippet of the working code, storing the data in the database:

	/* insert in xcap table*/
	query_cols[n_query_cols] = &str_username_col;
	query_vals[n_query_cols].type = DB_STR;
	query_vals[n_query_cols].nul = 0;
	query_vals[n_query_cols].val.string_val = user.s;
	n_query_cols++;
	
	query_cols[n_query_cols] = &str_domain_col;
	query_vals[n_query_cols].type = DB_STR;
	query_vals[n_query_cols].nul = 0;
	query_vals[n_query_cols].val.string_val = domain.s;
	n_query_cols++;
	
	query_cols[n_query_cols] = &str_doc_col;
	query_vals[n_query_cols].type = DB_BLOB;
	query_vals[n_query_cols].nul = 0;
	query_vals[n_query_cols].val.string_val= doc;
	n_query_cols++;

	query_cols[n_query_cols] = &str_doc_type_col;
	query_vals[n_query_cols].type = DB_INT;
	query_vals[n_query_cols].nul = 0;
	query_vals[n_query_cols].val.int_val= req.doc_sel.doc_type;
	n_query_cols++;

	query_cols[n_query_cols] = &str_etag_col;
	query_vals[n_query_cols].type = DB_STRING;
	query_vals[n_query_cols].nul = 0;
	query_vals[n_query_cols].val.string_val= etag;
	n_query_cols++;

	query_cols[n_query_cols] = &str_source_col;
	query_vals[n_query_cols].type = DB_INT;
	query_vals[n_query_cols].nul = 0;
	query_vals[n_query_cols].val.int_val= XCAP_CL_MOD;
	n_query_cols++;

	query_cols[n_query_cols] = &str_doc_uri_col;
	query_vals[n_query_cols].type = DB_STRING;
	query_vals[n_query_cols].nul = 0;
	query_vals[n_query_cols].val.string_val= path;
	n_query_cols++;
	
	query_cols[n_query_cols] = &str_port_col;
	query_vals[n_query_cols].type = DB_INT;
	query_vals[n_query_cols].nul = 0;
	query_vals[n_query_cols].val.int_val= req.port;
	n_query_cols++;

The 100% solution is to fix the db_mysql/val.c db_mysql_val2str for str type.

Regards, Genady 

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

>Comment By: Anca Vamanu (anca_vamanu)
Date: 2009-05-19 13:41

Message:
Hi Genady,

Thanks for debugging the error and finding the solution. I will test
myself and apply the changes to svn.

regards,
Anca

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

Comment By: genady (genabel)
Date: 2009-05-19 12:12

Message:
sorry, the BLOB handling should be done like this, since the BLOB value
must be str instead of char*:

query_cols[n_query_cols] = &str_doc_col;
query_vals[n_query_cols].type = DB_BLOB;
query_vals[n_query_cols].nul = 0;
/* change start*/
str str_doc={doc, strlen(doc)};
query_vals[n_query_cols].val.str_val= str_doc;
/* change end */ 
n_query_cols++;


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

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


From noreply at sourceforge.net  Wed May 20 13:59:43 2009
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed, 20 May 2009 11:59:43 +0000
Subject: [OpenSIPS-Devel] [ opensips-Bugs-2791758 ] xcap_client fails to
	store the xcap document in the database
Message-ID: <E1M6kSV-0000wU-0e@b55xhf1.ch3.sourceforge.com>

Bugs item #2791758, was opened at 2009-05-14 17:02
Message generated for change (Comment added) made by genabel
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=2791758&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: 9
Private: No
Submitted By: genady (genabel)
Assigned to: Anca Vamanu (anca_vamanu)
Summary: xcap_client fails to store the xcap document in the database

Initial Comment:
the xcap document fetched from the non integrated xcap server cannot be saved in the mysql database. The error messages are:

ERROR:db_mysql:db_mysql_val2str: destination buffer too short
ERROR:core:db_print_values: Error while converting value to string

I analysed the source code of xcap_functions.c xcapGetNewDoc and found out that instead of str structure, char* and string_val should be used.  
This is due to fact, that in db_mysql/val.c db_mysql_val2str something goes wrong here:
	if (*_len < (VAL_STR(_v).len * 2 + 3)) {
	  LM_ERR("destination buffer too short\n");
	  return -6;
	...

This line caused bug:
query_vals[n_query_cols].val.str_val = user;

This solves the problem:
query_vals[n_query_cols].val.string_val = user.s;

This is also valid for the domain parameter passed to , here is the snippet of the working code, storing the data in the database:

	/* insert in xcap table*/
	query_cols[n_query_cols] = &str_username_col;
	query_vals[n_query_cols].type = DB_STR;
	query_vals[n_query_cols].nul = 0;
	query_vals[n_query_cols].val.string_val = user.s;
	n_query_cols++;
	
	query_cols[n_query_cols] = &str_domain_col;
	query_vals[n_query_cols].type = DB_STR;
	query_vals[n_query_cols].nul = 0;
	query_vals[n_query_cols].val.string_val = domain.s;
	n_query_cols++;
	
	query_cols[n_query_cols] = &str_doc_col;
	query_vals[n_query_cols].type = DB_BLOB;
	query_vals[n_query_cols].nul = 0;
	query_vals[n_query_cols].val.string_val= doc;
	n_query_cols++;

	query_cols[n_query_cols] = &str_doc_type_col;
	query_vals[n_query_cols].type = DB_INT;
	query_vals[n_query_cols].nul = 0;
	query_vals[n_query_cols].val.int_val= req.doc_sel.doc_type;
	n_query_cols++;

	query_cols[n_query_cols] = &str_etag_col;
	query_vals[n_query_cols].type = DB_STRING;
	query_vals[n_query_cols].nul = 0;
	query_vals[n_query_cols].val.string_val= etag;
	n_query_cols++;

	query_cols[n_query_cols] = &str_source_col;
	query_vals[n_query_cols].type = DB_INT;
	query_vals[n_query_cols].nul = 0;
	query_vals[n_query_cols].val.int_val= XCAP_CL_MOD;
	n_query_cols++;

	query_cols[n_query_cols] = &str_doc_uri_col;
	query_vals[n_query_cols].type = DB_STRING;
	query_vals[n_query_cols].nul = 0;
	query_vals[n_query_cols].val.string_val= path;
	n_query_cols++;
	
	query_cols[n_query_cols] = &str_port_col;
	query_vals[n_query_cols].type = DB_INT;
	query_vals[n_query_cols].nul = 0;
	query_vals[n_query_cols].val.int_val= req.port;
	n_query_cols++;

The 100% solution is to fix the db_mysql/val.c db_mysql_val2str for str type.

Regards, Genady 

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

>Comment By: genady (genabel)
Date: 2009-05-20 13:59

Message:
Anca, after a while I discovered that the existing branch code for
query_cols and query_vals is valid except DB_BLOB. See my previous comment
to this bug entry.

Best regards,
Genady

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

Comment By: Anca Vamanu (anca_vamanu)
Date: 2009-05-19 12:41

Message:
Hi Genady,

Thanks for debugging the error and finding the solution. I will test
myself and apply the changes to svn.

regards,
Anca

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

Comment By: genady (genabel)
Date: 2009-05-19 11:12

Message:
sorry, the BLOB handling should be done like this, since the BLOB value
must be str instead of char*:

query_cols[n_query_cols] = &str_doc_col;
query_vals[n_query_cols].type = DB_BLOB;
query_vals[n_query_cols].nul = 0;
/* change start*/
str str_doc={doc, strlen(doc)};
query_vals[n_query_cols].val.str_val= str_doc;
/* change end */ 
n_query_cols++;


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

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


From anca at opensips.org  Wed May 20 16:32:10 2009
From: anca at opensips.org (Anca Vamanu)
Date: Wed, 20 May 2009 14:32:10 +0000
Subject: [OpenSIPS-Devel] SF.net SVN: opensips:[5717]
	trunk/modules/xcap_client
Message-ID: <E1M6mq2-0001LX-T1@dn4whf1.ch3.sourceforge.com>

Revision: 5717
          http://opensips.svn.sourceforge.net/opensips/?rev=5717&view=rev
Author:   anca_vamanu
Date:     2009-05-20 14:32:07 +0000 (Wed, 20 May 2009)

Log Message:
-----------
- fixed bug when doing database optations with type DB_BLOB (credits for the fix go to Genady , bug #2791758)

Modified Paths:
--------------
    trunk/modules/xcap_client/xcap_client.c
    trunk/modules/xcap_client/xcap_functions.c


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


From anca at opensips.org  Wed May 20 16:46:11 2009
From: anca at opensips.org (Anca Vamanu)
Date: Wed, 20 May 2009 14:46:11 +0000
Subject: [OpenSIPS-Devel] SF.net SVN: opensips:[5718]
	branches/1.5/modules/xcap_client
Message-ID: <E1M6n3b-0001eY-Th@dn4whf1.ch3.sourceforge.com>

Revision: 5718
          http://opensips.svn.sourceforge.net/opensips/?rev=5718&view=rev
Author:   anca_vamanu
Date:     2009-05-20 14:46:11 +0000 (Wed, 20 May 2009)

Log Message:
-----------
- fixed bug when doing database optations with type DB_BLOB (credits for the fix go to Genady , bug #2791758)

Modified Paths:
--------------
    branches/1.5/modules/xcap_client/xcap_client.c
    branches/1.5/modules/xcap_client/xcap_functions.c


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


From noreply at sourceforge.net  Thu May 21 13:33:06 2009
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 21 May 2009 11:33:06 +0000
Subject: [OpenSIPS-Devel] [ opensips-Bugs-2791758 ] xcap_client fails to
	store the xcap document in the database
Message-ID: <E1M76WI-0002mm-7T@3bkjzd1.ch3.sourceforge.com>

Bugs item #2791758, was opened at 2009-05-14 18:02
Message generated for change (Settings changed) made by anca_vamanu
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=2791758&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: Closed
>Resolution: Fixed
Priority: 9
Private: No
Submitted By: genady (genabel)
Assigned to: Anca Vamanu (anca_vamanu)
Summary: xcap_client fails to store the xcap document in the database

Initial Comment:
the xcap document fetched from the non integrated xcap server cannot be saved in the mysql database. The error messages are:

ERROR:db_mysql:db_mysql_val2str: destination buffer too short
ERROR:core:db_print_values: Error while converting value to string

I analysed the source code of xcap_functions.c xcapGetNewDoc and found out that instead of str structure, char* and string_val should be used.  
This is due to fact, that in db_mysql/val.c db_mysql_val2str something goes wrong here:
	if (*_len < (VAL_STR(_v).len * 2 + 3)) {
	  LM_ERR("destination buffer too short\n");
	  return -6;
	...

This line caused bug:
query_vals[n_query_cols].val.str_val = user;

This solves the problem:
query_vals[n_query_cols].val.string_val = user.s;

This is also valid for the domain parameter passed to , here is the snippet of the working code, storing the data in the database:

	/* insert in xcap table*/
	query_cols[n_query_cols] = &str_username_col;
	query_vals[n_query_cols].type = DB_STR;
	query_vals[n_query_cols].nul = 0;
	query_vals[n_query_cols].val.string_val = user.s;
	n_query_cols++;
	
	query_cols[n_query_cols] = &str_domain_col;
	query_vals[n_query_cols].type = DB_STR;
	query_vals[n_query_cols].nul = 0;
	query_vals[n_query_cols].val.string_val = domain.s;
	n_query_cols++;
	
	query_cols[n_query_cols] = &str_doc_col;
	query_vals[n_query_cols].type = DB_BLOB;
	query_vals[n_query_cols].nul = 0;
	query_vals[n_query_cols].val.string_val= doc;
	n_query_cols++;

	query_cols[n_query_cols] = &str_doc_type_col;
	query_vals[n_query_cols].type = DB_INT;
	query_vals[n_query_cols].nul = 0;
	query_vals[n_query_cols].val.int_val= req.doc_sel.doc_type;
	n_query_cols++;

	query_cols[n_query_cols] = &str_etag_col;
	query_vals[n_query_cols].type = DB_STRING;
	query_vals[n_query_cols].nul = 0;
	query_vals[n_query_cols].val.string_val= etag;
	n_query_cols++;

	query_cols[n_query_cols] = &str_source_col;
	query_vals[n_query_cols].type = DB_INT;
	query_vals[n_query_cols].nul = 0;
	query_vals[n_query_cols].val.int_val= XCAP_CL_MOD;
	n_query_cols++;

	query_cols[n_query_cols] = &str_doc_uri_col;
	query_vals[n_query_cols].type = DB_STRING;
	query_vals[n_query_cols].nul = 0;
	query_vals[n_query_cols].val.string_val= path;
	n_query_cols++;
	
	query_cols[n_query_cols] = &str_port_col;
	query_vals[n_query_cols].type = DB_INT;
	query_vals[n_query_cols].nul = 0;
	query_vals[n_query_cols].val.int_val= req.port;
	n_query_cols++;

The 100% solution is to fix the db_mysql/val.c db_mysql_val2str for str type.

Regards, Genady 

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

>Comment By: Anca Vamanu (anca_vamanu)
Date: 2009-05-21 14:33

Message:
Hi Genady,

I have fixed the code yesterday. 
The problem was indeed with the blob type, the module used a str structure
for fetching and storing the results.
Thank you for debugging this.

regards,
Anca

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

Comment By: genady (genabel)
Date: 2009-05-20 14:59

Message:
Anca, after a while I discovered that the existing branch code for
query_cols and query_vals is valid except DB_BLOB. See my previous comment
to this bug entry.

Best regards,
Genady

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

Comment By: Anca Vamanu (anca_vamanu)
Date: 2009-05-19 13:41

Message:
Hi Genady,

Thanks for debugging the error and finding the solution. I will test
myself and apply the changes to svn.

regards,
Anca

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

Comment By: genady (genabel)
Date: 2009-05-19 12:12

Message:
sorry, the BLOB handling should be done like this, since the BLOB value
must be str instead of char*:

query_cols[n_query_cols] = &str_doc_col;
query_vals[n_query_cols].type = DB_BLOB;
query_vals[n_query_cols].nul = 0;
/* change start*/
str str_doc={doc, strlen(doc)};
query_vals[n_query_cols].val.str_val= str_doc;
/* change end */ 
n_query_cols++;


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

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


From bogdan at voice-system.ro  Thu May 21 14:50:24 2009
From: bogdan at voice-system.ro (Bogdan-Andrei Iancu)
Date: Thu, 21 May 2009 12:50:24 +0000
Subject: [OpenSIPS-Devel] SF.net SVN: opensips:[5719]
	trunk/modules/dispatcher
Message-ID: <E1M77j6-0006F3-2j@74yxhf1.ch3.sourceforge.com>

Revision: 5719
          http://opensips.svn.sourceforge.net/opensips/?rev=5719&view=rev
Author:   bogdan_iancu
Date:     2009-05-21 12:50:23 +0000 (Thu, 21 May 2009)

Log Message:
-----------
- finished work on adding attributes support for the destinations.

Modified Paths:
--------------
    trunk/modules/dispatcher/dispatch.c
    trunk/modules/dispatcher/dispatch.h
    trunk/modules/dispatcher/dispatcher.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  Thu May 21 18:15:40 2009
From: bogdan at voice-system.ro (Bogdan-Andrei Iancu)
Date: Thu, 21 May 2009 16:15:40 +0000
Subject: [OpenSIPS-Devel] SF.net SVN: opensips:[5720]
	trunk/modules/tm/t_lookup.c
Message-ID: <E1M7Avk-0002iO-DY@d5vjzd1.ch3.sourceforge.com>

Revision: 5720
          http://opensips.svn.sourceforge.net/opensips/?rev=5720&view=rev
Author:   bogdan_iancu
Date:     2009-05-21 16:15:40 +0000 (Thu, 21 May 2009)

Log Message:
-----------
- fixed detection and absorption of the ACKs for locally replied transactions.

Modified Paths:
--------------
    trunk/modules/tm/t_lookup.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  Thu May 21 18:45:29 2009
From: bogdan at voice-system.ro (Bogdan-Andrei Iancu)
Date: Thu, 21 May 2009 16:45:29 +0000
Subject: [OpenSIPS-Devel] SF.net SVN: opensips:[5721]
	trunk/modules/dispatcher
Message-ID: <E1M7BOb-0001fO-CW@c3vjzd1.ch3.sourceforge.com>

Revision: 5721
          http://opensips.svn.sourceforge.net/opensips/?rev=5721&view=rev
Author:   bogdan_iancu
Date:     2009-05-21 16:45:25 +0000 (Thu, 21 May 2009)

Log Message:
-----------
- docs updated -> new parameters:
  - attrs_avp
  - weight_col
  - attrs_col

Modified Paths:
--------------
    trunk/modules/dispatcher/README
    trunk/modules/dispatcher/dispatch.c
    trunk/modules/dispatcher/doc/dispatcher_admin.xml


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


From bogdan at voice-system.ro  Thu May 21 19:03:19 2009
From: bogdan at voice-system.ro (Bogdan-Andrei Iancu)
Date: Thu, 21 May 2009 20:03:19 +0300
Subject: [OpenSIPS-Devel] [NEW] More enhancements in DISPATCHER module
Message-ID: <4A158957.9030903@voice-system.ro>

Hi,

I just added 2 new interesting enhancements to the dispatcher module (on 
OpenSIPS 1.6 / trunk ) :


Weight for destination
=======================

The definition of the destinations includes a weight of that 
destination. This weight is to be used for controlling the distribution 
(as ratio) between the peers. Without weight, a relating equal shares of 
traffic is sent to all the peers; using weights, you can sent different 
shares (like 25% for one destinations, 60% to other and 15% to the third).

The weights are not necessary percentages - they simply define the 
distribution between the destinations, in a similar way as weights works 
for DNS : a entry with higher weight will have higher chances to be 
selected.

The weights to not affect the existing dispatching algorithms - it works 
for all except the Round Robin algorithm were weight is simply ignored.



Attributes for destination
==========================

The definition of the destinations includes a opaque string of 
attributes of that destination. This string is not used by the 
dispatcher module at all - it is simply made available in script 
whenever the destination is selected (by the functions of the dispatcher 
module).

This attribute string may encode whatever information about the 
destination, information useful to have when you use the destination. To 
get the attributes string, you simply have to put the string in the 
destination definition (DB or file) and to define the module parameter 
"attrs_avp" - this is the AVP that will be populated with the attribute 
string.

Regards,
Bogdan


From bogdan at voice-system.ro  Thu May 21 19:11:04 2009
From: bogdan at voice-system.ro (Bogdan-Andrei Iancu)
Date: Thu, 21 May 2009 17:11:04 +0000
Subject: [OpenSIPS-Devel] SF.net SVN: opensips:[5722] trunk/script_cb.c
Message-ID: <E1M7BnM-0000wg-FC@3kljzd1.ch3.sourceforge.com>

Revision: 5722
          http://opensips.svn.sourceforge.net/opensips/?rev=5722&view=rev
Author:   bogdan_iancu
Date:     2009-05-21 17:11:04 +0000 (Thu, 21 May 2009)

Log Message:
-----------
- fixed bogus order of callback in the list - it is critical to preserv the order of registerd callbacks (first registerd, first executed). Otherwise, the dependencies between the modules will be broken.

Modified Paths:
--------------
    trunk/script_cb.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  Fri May 22 11:00:30 2009
From: bogdan at voice-system.ro (Bogdan-Andrei Iancu)
Date: Fri, 22 May 2009 09:00:30 +0000
Subject: [OpenSIPS-Devel] SF.net SVN: opensips:[5723] trunk/tls/tls_server.c
Message-ID: <E1M7QcA-00060o-5L@3kljzd1.ch3.sourceforge.com>

Revision: 5723
          http://opensips.svn.sourceforge.net/opensips/?rev=5723&view=rev
Author:   bogdan_iancu
Date:     2009-05-22 09:00:29 +0000 (Fri, 22 May 2009)

Log Message:
-----------
- more verbous error logs for tls_accept()

Modified Paths:
--------------
    trunk/tls/tls_server.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  Fri May 22 11:00:45 2009
From: bogdan at voice-system.ro (Bogdan-Andrei Iancu)
Date: Fri, 22 May 2009 09:00:45 +0000
Subject: [OpenSIPS-Devel] SF.net SVN: opensips:[5724]
	branches/1.5/tls/tls_server.c
Message-ID: <E1M7QcP-00061A-T3@3kljzd1.ch3.sourceforge.com>

Revision: 5724
          http://opensips.svn.sourceforge.net/opensips/?rev=5724&view=rev
Author:   bogdan_iancu
Date:     2009-05-22 09:00:45 +0000 (Fri, 22 May 2009)

Log Message:
-----------
backport from trunk (rev #5723)
- more verbous error logs for tls_accept()

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

Modified Paths:
--------------
    branches/1.5/tls/tls_server.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 May 22 11:59:21 2009
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 22 May 2009 09:59:21 +0000
Subject: [OpenSIPS-Devel] [ opensips-Bugs-2795294 ] serialize branches does
	not store complete branch info
Message-ID: <E1M7RX7-0002IC-Gt@d55xhf1.ch3.sourceforge.com>

Bugs item #2795294, was opened at 2009-05-22 12:59
Message generated for change (Tracker Item Submitted) made by bogdan_iancu
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=2795294&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: 7
Private: No
Submitted By: Bogdan-Andrei Iancu (bogdan_iancu)
Assigned to: Bogdan-Andrei Iancu (bogdan_iancu)
Summary: serialize branches does not store complete branch info

Initial Comment:
serialize_branches() does not store the received and path information, so when doing serial forking , you will loose this information.

Reported by Mauro Davi'  and Alex Hermann.

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

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


From noreply at sourceforge.net  Fri May 22 12:05:05 2009
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 22 May 2009 10:05:05 +0000
Subject: [OpenSIPS-Devel] [ opensips-Feature Requests-2795297 ] Path
	problems in osipsconsole
Message-ID: <E1M7Rcf-0006Z5-DZ@1bkjzd1.ch3.sourceforge.com>

Feature Requests item #2795297, was opened at 2009-05-22 12:05
Message generated for change (Tracker Item Submitted) made by sacoo
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086413&aid=2795297&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: tools
Group: None
Status: Open
Priority: 5
Private: No
Submitted By: ASeques (sacoo)
Assigned to: Nobody/Anonymous (nobody)
Summary: Path problems in osipsconsole

Initial Comment:
I am using the 1.5.1 version on a debian platform compiled by "make deb".
Everything is working as expected except for osipsconsole.
There should be a proper path detection, because it currently causes lots of trouble.

Currently i see this variables poiting to fixed paths to /usr/local/ , there might be more that I already changed.
The optimal solution would be having a definition at the start of the document $INSTALL_PATH or similar that could be set on compile/install time.

140:my $MYLIBDIR = "/usr/local/lib/opensips/opensipsctl";
145:my $DATA_DIR = "/usr/local/share/opensips";
146:my $DBTEXT_PATH = "/usr/local/share/opensips/dbtext/opensips";
150:    $DB_PATH = "/usr/local/etc/opensips/db_berkeley";
531:    $ETCDIR="/usr/local/etc/opensips";
928:                if ( -x "/usr/local/bin/".$_[0] ) {
929:                        $TOOLPATH = "/usr/local/bin/$_[0]";


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

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


From noreply at sourceforge.net  Fri May 22 12:15:18 2009
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 22 May 2009 10:15:18 +0000
Subject: [OpenSIPS-Devel] [ opensips-Feature Requests-2795297 ] Path
	problems in osipsconsole
Message-ID: <E1M7RmY-0007TY-9R@665xhf1.ch3.sourceforge.com>

Feature Requests item #2795297, was opened at 2009-05-22 13:05
Message generated for change (Settings changed) made by bogdan_iancu
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086413&aid=2795297&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: tools
Group: None
Status: Open
Priority: 5
Private: No
Submitted By: ASeques (sacoo)
>Assigned to: Iulia Bublea (iulia_bublea)
Summary: Path problems in osipsconsole

Initial Comment:
I am using the 1.5.1 version on a debian platform compiled by "make deb".
Everything is working as expected except for osipsconsole.
There should be a proper path detection, because it currently causes lots of trouble.

Currently i see this variables poiting to fixed paths to /usr/local/ , there might be more that I already changed.
The optimal solution would be having a definition at the start of the document $INSTALL_PATH or similar that could be set on compile/install time.

140:my $MYLIBDIR = "/usr/local/lib/opensips/opensipsctl";
145:my $DATA_DIR = "/usr/local/share/opensips";
146:my $DBTEXT_PATH = "/usr/local/share/opensips/dbtext/opensips";
150:    $DB_PATH = "/usr/local/etc/opensips/db_berkeley";
531:    $ETCDIR="/usr/local/etc/opensips";
928:                if ( -x "/usr/local/bin/".$_[0] ) {
929:                        $TOOLPATH = "/usr/local/bin/$_[0]";


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

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


From noreply at sourceforge.net  Fri May 22 12:16:26 2009
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 22 May 2009 10:16:26 +0000
Subject: [OpenSIPS-Devel] [ opensips-Feature Requests-2795305 ] osipsconsole
	should create the db for drouting
Message-ID: <E1M7Rne-0004XB-Ec@565xhf1.ch3.sourceforge.com>

Feature Requests item #2795305, was opened at 2009-05-22 12:16
Message generated for change (Tracker Item Submitted) made by sacoo
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086413&aid=2795305&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: tools
Group: None
Status: Open
Priority: 5
Private: No
Submitted By: ASeques (sacoo)
Assigned to: Nobody/Anonymous (nobody)
Summary: osipsconsole should create the db for drouting

Initial Comment:
Since 1.5, drouting is one of the core modules, also the recommended replacement for the lcr modules. 
Around line 127, there is the list of tables:
my @STANDARD_TABLES = ('version', 'acc', 'dbaliases', 'lcr', 'domain', 'grp', 'uri', 'speed_dial', 'gw', 'pdt', 'subscriber', 'location', 're_grp', 'trusted', 'address', 'missed_calls', 'usr_preferences', 'aliases', 'silo', 'dialog', 'dispatcher', 'dialplan');
It should be:
my @STANDARD_TABLES = ('version', 'acc', 'dbaliases', 'lcr', 'domain', 'grp', 'uri', 'speed_dial', 'gw', 'pdt', 'subscriber', 'location', 're_grp', 'trusted', 'address', 'missed_calls', 'usr_preferences', 'aliases', 'silo', 'dialog', 'dispatcher', 'dialplan','drouting');

At least it should be in the EXTRA_MODULES if you don't like it to be in the STANDARD.

Cheers


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

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


From noreply at sourceforge.net  Fri May 22 12:26:57 2009
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 22 May 2009 10:26:57 +0000
Subject: [OpenSIPS-Devel] [ opensips-Feature Requests-2795305 ] osipsconsole
	should create the db for drouting
Message-ID: <E1M7Rxp-00082B-Vg@cdv4jf1.ch3.sourceforge.com>

Feature Requests item #2795305, was opened at 2009-05-22 13:16
Message generated for change (Settings changed) made by bogdan_iancu
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086413&aid=2795305&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: tools
Group: None
Status: Open
Priority: 5
Private: No
Submitted By: ASeques (sacoo)
>Assigned to: Iulia Bublea (iulia_bublea)
Summary: osipsconsole should create the db for drouting

Initial Comment:
Since 1.5, drouting is one of the core modules, also the recommended replacement for the lcr modules. 
Around line 127, there is the list of tables:
my @STANDARD_TABLES = ('version', 'acc', 'dbaliases', 'lcr', 'domain', 'grp', 'uri', 'speed_dial', 'gw', 'pdt', 'subscriber', 'location', 're_grp', 'trusted', 'address', 'missed_calls', 'usr_preferences', 'aliases', 'silo', 'dialog', 'dispatcher', 'dialplan');
It should be:
my @STANDARD_TABLES = ('version', 'acc', 'dbaliases', 'lcr', 'domain', 'grp', 'uri', 'speed_dial', 'gw', 'pdt', 'subscriber', 'location', 're_grp', 'trusted', 'address', 'missed_calls', 'usr_preferences', 'aliases', 'silo', 'dialog', 'dispatcher', 'dialplan','drouting');

At least it should be in the EXTRA_MODULES if you don't like it to be in the STANDARD.

Cheers


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

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


From bogdan at voice-system.ro  Fri May 22 13:20:58 2009
From: bogdan at voice-system.ro (Bogdan-Andrei Iancu)
Date: Fri, 22 May 2009 11:20:58 +0000
Subject: [OpenSIPS-Devel] SF.net SVN: opensips:[5725] trunk/modules/usrloc
Message-ID: <E1M7So6-0003JX-FL@74yxhf1.ch3.sourceforge.com>

Revision: 5725
          http://opensips.svn.sourceforge.net/opensips/?rev=5725&view=rev
Author:   bogdan_iancu
Date:     2009-05-22 11:20:58 +0000 (Fri, 22 May 2009)

Log Message:
-----------
- new internal API functions:
	lock_ulslot / unlock_ulsloti(udomain*, slot) - to lock a specific slot of the domain hash table
	get_next_udomain (udomain*) - returns the first udomain in input paramis NULL or the next udomain
	get_next_urecord (udomain*, slot, urecord*) - returns the next urecord (after given input urecord, or first urecord if input is NULL) from the udomain hash table slot.


This new functions provide a controlled way of accessing (from other modules) the usrloc data structures:

1) use get_next_udomain(udomain *) for iterating through  all the domains; if the param is NULL, it will return the first udomain;  otherwise the next following udomain.

2) for each udomain, use udomain->size to see the hash table size...and for each hash entry do:
       a) lock_ulslot(udomain, slot) 
       b) get_next_urecord(udomain, entry_id, urecord*) - iterates  through the all urecords from the hash entry
       c) unlock_ulslot(udomain, slot)

This is the ressult of a discussion with John Khvatov  on the devel list

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


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


From bogdan at voice-system.ro  Fri May 22 13:28:16 2009
From: bogdan at voice-system.ro (Bogdan-Andrei Iancu)
Date: Fri, 22 May 2009 14:28:16 +0300
Subject: [OpenSIPS-Devel] [NEW] USRLOC internal API extended
Message-ID: <4A168C50.6000207@voice-system.ro>

Hi,

Following some discussion with John Khvatov on the devel list (see 
http://lists.opensips.org/pipermail/devel/2009-April/003018.html), the 
internal API provided by USRLOC was extended with  new functions for 
providing a controlled way of accessing (from other modules) the usrloc 
data structures.

The algorithm is:

1) use get_next_udomain(udomain *) for iterating through all the 
domains; if the param is NULL, it will return the first udomain; 
otherwise the next following udomain.

2) for each udomain, use udomain->size to see the hash table size...and 
for each hash entry do:
    a) lock_ulslot(udomain, slot)
    b) get_next_urecord(udomain, entry_id, urecord*) - iterates through 
the all urecords from the hash entry
    c) unlock_ulslot(udomain, slot)


The new functions are:

- lock_ulslot / unlock_ulsloti(udomain*, slot) - to lock a specific slot 
of the domain hash table

- get_next_udomain (udomain*) - returns the first udomain in input 
paramis NULL or the next udomain

- get_next_urecord (udomain*, slot, urecord*) - returns the next urecord 
(after given input urecord, or first urecord if input is NULL) from the 
udomain hash table slot.


Regards,
Bogdan


From bogdan at voice-system.ro  Fri May 22 15:56:52 2009
From: bogdan at voice-system.ro (Bogdan-Andrei Iancu)
Date: Fri, 22 May 2009 13:56:52 +0000
Subject: [OpenSIPS-Devel] SF.net SVN: opensips:[5726]
	trunk/modules/usrloc/dlist.h
Message-ID: <E1M7VEy-00027d-Vo@c3vjzd1.ch3.sourceforge.com>

Revision: 5726
          http://opensips.svn.sourceforge.net/opensips/?rev=5726&view=rev
Author:   bogdan_iancu
Date:     2009-05-22 13:56:52 +0000 (Fri, 22 May 2009)

Log Message:
-----------
- fixed typo in comments

Modified Paths:
--------------
    trunk/modules/usrloc/dlist.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 May 22 16:36:20 2009
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 22 May 2009 14:36:20 +0000
Subject: [OpenSIPS-Devel] [ opensips-Patches-2795418 ] Adding
	/etc/default/opensips file for rpm packaging
Message-ID: <E1M7VrA-0002CJ-En@d45xhf1.ch3.sourceforge.com>

Patches item #2795418, was opened at 2009-05-22 16:36
Message generated for change (Tracker Item Submitted) made by lftsy
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086412&aid=2795418&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: packaging
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Marc LEURENT (lftsy)
Assigned to: Nobody/Anonymous (nobody)
Summary: Adding /etc/default/opensips file for rpm packaging

Initial Comment:
Hello all, I have just modified the opensips.spec.CentOS file to integrate /etc/default/opensips.
This new file will permit to modify some parameters without having to change the /etc/init.d/opensips file like the amount of shared memory to allow.
You will see that the modifications are debian style inspired!!

Here is the changelog:
* Fri May 22 2009 Marc Leurent <marc.leurent at vtx-telecom.ch>
- Add /etc/default/opensips file to allow shared memory configuration
- Modify snmpstats Requires to add net-snmp-utils

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

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


From noreply at sourceforge.net  Fri May 22 16:42:16 2009
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 22 May 2009 14:42:16 +0000
Subject: [OpenSIPS-Devel] [ opensips-Patches-2795418 ] Adding
	/etc/default/opensips file for rpm packaging
Message-ID: <E1M7Vwu-0004Mt-Nt@d55xhf1.ch3.sourceforge.com>

Patches item #2795418, was opened at 2009-05-22 16:36
Message generated for change (Comment added) made by lftsy
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086412&aid=2795418&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: packaging
Group: None
Status: Open
>Resolution: Accepted
Priority: 5
Private: No
Submitted By: Marc LEURENT (lftsy)
>Assigned to: Marc LEURENT (lftsy)
Summary: Adding /etc/default/opensips file for rpm packaging

Initial Comment:
Hello all, I have just modified the opensips.spec.CentOS file to integrate /etc/default/opensips.
This new file will permit to modify some parameters without having to change the /etc/init.d/opensips file like the amount of shared memory to allow.
You will see that the modifications are debian style inspired!!

Here is the changelog:
* Fri May 22 2009 Marc Leurent <marc.leurent at vtx-telecom.ch>
- Add /etc/default/opensips file to allow shared memory configuration
- Modify snmpstats Requires to add net-snmp-utils

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

>Comment By: Marc LEURENT (lftsy)
Date: 2009-05-22 16:42

Message:
Compilation and packaging ok,
I'm uploading the RPMs with new packaging on 
CentOS el5 (RPMs i386/x86_64) (thanks to Julian Yap & Marc Leurent)
http://centos.leurent.eu/
as referred from http://www.opensips.org/Resources/Downloads

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

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


From iulia at opensips.org  Fri May 22 17:25:09 2009
From: iulia at opensips.org (Iulia Bublea)
Date: Fri, 22 May 2009 15:25:09 +0000
Subject: [OpenSIPS-Devel] SF.net SVN: opensips:[5730]
	trunk/scripts/osipsconsole
Message-ID: <E1M7WcP-0005zB-Ln@3kljzd1.ch3.sourceforge.com>

Revision: 5730
          http://opensips.svn.sourceforge.net/opensips/?rev=5730&view=rev
Author:   iulia_bublea
Date:     2009-05-22 15:25:09 +0000 (Fri, 22 May 2009)

Log Message:
-----------
Fixed bug related to drouting table creation. Reported by sacoo, feature request number #2795305.

Modified Paths:
--------------
    trunk/scripts/osipsconsole


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


From noreply at sourceforge.net  Fri May 22 17:27:56 2009
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 22 May 2009 15:27:56 +0000
Subject: [OpenSIPS-Devel] [ opensips-Feature Requests-2795305 ] osipsconsole
	should create the db for drouting
Message-ID: <E1M7Wf6-00034E-UU@665xhf1.ch3.sourceforge.com>

Feature Requests item #2795305, was opened at 2009-05-22 13:16
Message generated for change (Comment added) made by iulia_bublea
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086413&aid=2795305&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: tools
Group: None
>Status: Closed
Priority: 5
Private: No
Submitted By: ASeques (sacoo)
Assigned to: Iulia Bublea (iulia_bublea)
Summary: osipsconsole should create the db for drouting

Initial Comment:
Since 1.5, drouting is one of the core modules, also the recommended replacement for the lcr modules. 
Around line 127, there is the list of tables:
my @STANDARD_TABLES = ('version', 'acc', 'dbaliases', 'lcr', 'domain', 'grp', 'uri', 'speed_dial', 'gw', 'pdt', 'subscriber', 'location', 're_grp', 'trusted', 'address', 'missed_calls', 'usr_preferences', 'aliases', 'silo', 'dialog', 'dispatcher', 'dialplan');
It should be:
my @STANDARD_TABLES = ('version', 'acc', 'dbaliases', 'lcr', 'domain', 'grp', 'uri', 'speed_dial', 'gw', 'pdt', 'subscriber', 'location', 're_grp', 'trusted', 'address', 'missed_calls', 'usr_preferences', 'aliases', 'silo', 'dialog', 'dispatcher', 'dialplan','drouting');

At least it should be in the EXTRA_MODULES if you don't like it to be in the STANDARD.

Cheers


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

>Comment By: Iulia Bublea (iulia_bublea)
Date: 2009-05-22 18:27

Message:
Hi,

The change has be done. Thanks for pointing that out.

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

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


From iulia at opensips.org  Fri May 22 17:31:44 2009
From: iulia at opensips.org (Iulia Bublea)
Date: Fri, 22 May 2009 15:31:44 +0000
Subject: [OpenSIPS-Devel] SF.net SVN: opensips:[5731]
	branches/1.5/scripts/osipsconsole
Message-ID: <E1M7Wim-000665-Uv@3kljzd1.ch3.sourceforge.com>

Revision: 5731
          http://opensips.svn.sourceforge.net/opensips/?rev=5731&view=rev
Author:   iulia_bublea
Date:     2009-05-22 15:31:44 +0000 (Fri, 22 May 2009)

Log Message:
-----------
Fixed bug related to drouting table creation. Reported by sacoo, feature request number #2795305.

Modified Paths:
--------------
    branches/1.5/scripts/osipsconsole


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


From noreply at sourceforge.net  Sat May 23 21:47:10 2009
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat, 23 May 2009 19:47:10 +0000
Subject: [OpenSIPS-Devel] [ opensips-Bugs-2795917 ] [PATCH] lcr module
	crashes if ruri_user is void
Message-ID: <E1M7xBW-0004Mq-Fs@g45xhf1.ch3.sourceforge.com>

Bugs item #2795917, was opened at 2009-05-23 19:47
Message generated for change (Tracker Item Submitted) made by nobody
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=2795917&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: 1.4.x
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: [PATCH] lcr module crashes if ruri_user is void

Initial Comment:
lcd module running in prefix_mode=1 is bound to crash in an incoming INVITE's Request-URI doesn't contain username part:

May 23 19:10:56 SIPS4 /usr/local/sbin/opensips[8754]: ----- Processing INVITE RURI=sip:11.11.11.11 F=sip:2123752645 at 22.22.22.22 T=sip:11.11.11.11 IP=22.22.22.22 ID=5781c4b2739bcab21003ab7162826e30 at 22.22.22.22
May 23 19:10:56 SIPS4 kernel: opensips[8754]: segfault at 0000000000000000 rip 00002aaaab15f080 rsp 00007fff1d3b27c8 error 4
May 23 19:10:57 SIPS4 /usr/local/sbin/opensips[8752]: INFO:core:handle_sigs: child process 8754 exited by a signal 11

(gdb) bt
#0  0x00002aaaab15f080 in strlen () from /lib/libc.so.6
#1  0x00002aaaab1a0d08 in regexec () from /lib/libc.so.6
#2  0x00002aaaada31fec in do_load_gws (_m=0x7bde18, _from_uri=0x0, _grp_id=-1) at lcr_mod.c:1271
#3  0x00002aaaada3387d in load_gws_0 (_m=0x7bde18, _s1=0x0, _s2=0x0) at lcr_mod.c:1512
#4  0x000000000041106b in do_action (a=0x771580, msg=0x7bde18) at action.c:845
#5  0x000000000040e13a in run_action_list (a=0x771580, msg=0x7bde18) at action.c:138
#6  0x0000000000452da3 in eval_elem (e=0x771650, msg=0x7bde18, val=0x0) at route.c:1133
#7  0x0000000000456e9d in eval_expr (e=0x771650, msg=0x7bde18, val=0x0) at route.c:1430
#8  0x0000000000456f81 in eval_expr (e=0x771698, msg=0x7bde18, val=0x0) at route.c:1446
#9  0x0000000000456fb5 in eval_expr (e=0x7716e0, msg=0x7bde18, val=0x0) at route.c:1451
#10 0x00000000004107cb in do_action (a=0x771a78, msg=0x7bde18) at action.c:700
#11 0x000000000040e13a in run_action_list (a=0x771a78, msg=0x7bde18) at action.c:138
#12 0x000000000040e415 in run_actions (a=0x771a78, msg=0x7bde18) at action.c:118
#13 0x000000000040fa19 in do_action (a=0x76e9d0, msg=0x7bde18) at action.c:483
#14 0x000000000040e13a in run_action_list (a=0x76e4e0, msg=0x7bde18) at action.c:138
#15 0x000000000041090a in do_action (a=0x76efa0, msg=0x7bde18) at action.c:717
#16 0x000000000040e13a in run_action_list (a=0x76efa0, msg=0x7bde18) at action.c:138
#17 0x000000000041090a in do_action (a=0x76f140, msg=0x7bde18) at action.c:717
#18 0x000000000040e13a in run_action_list (a=0x769008, msg=0x7bde18) at action.c:138
#19 0x000000000040e415 in run_actions (a=0x769008, msg=0x7bde18) at action.c:118
#20 0x000000000040e4de in run_top_route (a=0x769008, msg=0x7bde18) at action.c:179
#21 0x000000000044aae3 in receive_msg (
    buf=0x73cbe0 "INVITE sip:11.11.11.11 SIP/2.0\r\nVia: SIP/2.0/UDP 22.22.22.22:5060;branch=z9hG4bK0f49cc08;rport\r\nFrom: \"Unavailable\" <sip:2123752645 at 22.22.22.22>;tag=as5ae62e90\r\nTo: <sip:11.11.11.11>\r\nCont"..., len=869, rcv_info=0x7fff1d3c0430) at receive.c:165
#22 0x00000000004836fa in udp_rcv_loop () at udp_server.c:449
#23 0x0000000000423968 in main_loop () at main.c:780
#24 0x0000000000425d5d in main (argc=9, argv=0x7fff1d3c0688) at main.c:1319

Reproduced on 1.4.4 but all versions are affected. I suggest the following patch:

Index: lcr_mod.c
===================================================================
--- lcr_mod.c   (revision 5245)
+++ lcr_mod.c   (working copy)
@@ -1194,7 +1194,7 @@
     struct lcr_info lcr_rec;

     /* Find Request-URI user */
-    if (parse_sip_msg_uri(_m) < 0) {
+    if ((parse_sip_msg_uri(_m) < 0) || (!_m->parsed_uri.user.s)) {
            LM_ERR("Error while parsing R-URI\n");
            return -1;
     }


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

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


From noreply at sourceforge.net  Sat May 23 21:49:02 2009
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat, 23 May 2009 19:49:02 +0000
Subject: [OpenSIPS-Devel] [ opensips-Bugs-2795917 ] [PATCH] lcr module
	crashes if ruri_user is void
Message-ID: <E1M7xDK-0006NC-V2@3bkjzd1.ch3.sourceforge.com>

Bugs item #2795917, was opened at 2009-05-23 19:47
Message generated for change (Comment added) made by nobody
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=2795917&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: 1.4.x
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: [PATCH] lcr module crashes if ruri_user is void

Initial Comment:
lcd module running in prefix_mode=1 is bound to crash in an incoming INVITE's Request-URI doesn't contain username part:

May 23 19:10:56 SIPS4 /usr/local/sbin/opensips[8754]: ----- Processing INVITE RURI=sip:11.11.11.11 F=sip:2123752645 at 22.22.22.22 T=sip:11.11.11.11 IP=22.22.22.22 ID=5781c4b2739bcab21003ab7162826e30 at 22.22.22.22
May 23 19:10:56 SIPS4 kernel: opensips[8754]: segfault at 0000000000000000 rip 00002aaaab15f080 rsp 00007fff1d3b27c8 error 4
May 23 19:10:57 SIPS4 /usr/local/sbin/opensips[8752]: INFO:core:handle_sigs: child process 8754 exited by a signal 11

(gdb) bt
#0  0x00002aaaab15f080 in strlen () from /lib/libc.so.6
#1  0x00002aaaab1a0d08 in regexec () from /lib/libc.so.6
#2  0x00002aaaada31fec in do_load_gws (_m=0x7bde18, _from_uri=0x0, _grp_id=-1) at lcr_mod.c:1271
#3  0x00002aaaada3387d in load_gws_0 (_m=0x7bde18, _s1=0x0, _s2=0x0) at lcr_mod.c:1512
#4  0x000000000041106b in do_action (a=0x771580, msg=0x7bde18) at action.c:845
#5  0x000000000040e13a in run_action_list (a=0x771580, msg=0x7bde18) at action.c:138
#6  0x0000000000452da3 in eval_elem (e=0x771650, msg=0x7bde18, val=0x0) at route.c:1133
#7  0x0000000000456e9d in eval_expr (e=0x771650, msg=0x7bde18, val=0x0) at route.c:1430
#8  0x0000000000456f81 in eval_expr (e=0x771698, msg=0x7bde18, val=0x0) at route.c:1446
#9  0x0000000000456fb5 in eval_expr (e=0x7716e0, msg=0x7bde18, val=0x0) at route.c:1451
#10 0x00000000004107cb in do_action (a=0x771a78, msg=0x7bde18) at action.c:700
#11 0x000000000040e13a in run_action_list (a=0x771a78, msg=0x7bde18) at action.c:138
#12 0x000000000040e415 in run_actions (a=0x771a78, msg=0x7bde18) at action.c:118
#13 0x000000000040fa19 in do_action (a=0x76e9d0, msg=0x7bde18) at action.c:483
#14 0x000000000040e13a in run_action_list (a=0x76e4e0, msg=0x7bde18) at action.c:138
#15 0x000000000041090a in do_action (a=0x76efa0, msg=0x7bde18) at action.c:717
#16 0x000000000040e13a in run_action_list (a=0x76efa0, msg=0x7bde18) at action.c:138
#17 0x000000000041090a in do_action (a=0x76f140, msg=0x7bde18) at action.c:717
#18 0x000000000040e13a in run_action_list (a=0x769008, msg=0x7bde18) at action.c:138
#19 0x000000000040e415 in run_actions (a=0x769008, msg=0x7bde18) at action.c:118
#20 0x000000000040e4de in run_top_route (a=0x769008, msg=0x7bde18) at action.c:179
#21 0x000000000044aae3 in receive_msg (
    buf=0x73cbe0 "INVITE sip:11.11.11.11 SIP/2.0\r\nVia: SIP/2.0/UDP 22.22.22.22:5060;branch=z9hG4bK0f49cc08;rport\r\nFrom: \"Unavailable\" <sip:2123752645 at 22.22.22.22>;tag=as5ae62e90\r\nTo: <sip:11.11.11.11>\r\nCont"..., len=869, rcv_info=0x7fff1d3c0430) at receive.c:165
#22 0x00000000004836fa in udp_rcv_loop () at udp_server.c:449
#23 0x0000000000423968 in main_loop () at main.c:780
#24 0x0000000000425d5d in main (argc=9, argv=0x7fff1d3c0688) at main.c:1319

Reproduced on 1.4.4 but all versions are affected. I suggest the following patch:

Index: lcr_mod.c
===================================================================
--- lcr_mod.c   (revision 5245)
+++ lcr_mod.c   (working copy)
@@ -1194,7 +1194,7 @@
     struct lcr_info lcr_rec;

     /* Find Request-URI user */
-    if (parse_sip_msg_uri(_m) < 0) {
+    if ((parse_sip_msg_uri(_m) < 0) || (!_m->parsed_uri.user.s)) {
            LM_ERR("Error while parsing R-URI\n");
            return -1;
     }


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

Comment By: Nobody/Anonymous (nobody)
Date: 2009-05-23 19:49

Message:
Feel free to ask me should you want to test something since I have
everything set up.
Andrew <andrew.pogrebennyk at portaone.com>

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

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


From noreply at sourceforge.net  Sun May 24 00:49:18 2009
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat, 23 May 2009 22:49:18 +0000
Subject: [OpenSIPS-Devel] [ opensips-Bugs-2791186 ] [presence] crazy NOTIFY's
Message-ID: <E1M801m-00082Q-1O@1bkjzd1.ch3.sourceforge.com>

Bugs item #2791186, was opened at 2009-05-13 15:36
Message generated for change (Comment added) made by ibc_sf
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=2791186&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: I?aki Baz Castillo (ibc_sf)
Assigned to: Nobody/Anonymous (nobody)
Summary: [presence] crazy NOTIFY's

Initial Comment:
Rev 5706.

modparam("presence", "max_expires_publish", 30)
modparam("presence", "max_expires_subscribe", 40)
modparam("presence", "expires_offset", 5)
modparam("presence", "fallback2db", 1)


Just one client subscribed to itself (30004). All works well at the beginning, but after some time OpenSIPS starts sending *a lot* of NOTIFY's (no retransmissions) in the same seconds (for the same subscription dialog and with the same info).
This causes the client (Qutecom) replying "500 Retry Later".

I attach a very long capture, but go to line 3265 to see the issue.


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

>Comment By: I?aki Baz Castillo (ibc_sf)
Date: 2009-05-24 00:49

Message:
I've attached a new file (sequential_crazy_NOTIFY's.txt). It's a SIP
capture of OpenSIPS sending 6 NOTIFY's in less than a second. All of these
NOTIFY's are part of the same subscription dialog, and are sequential
requests (from CSeq: 8 to CSeq:13).
Twinkle replies 200 for each NOTIFY, but other clients, as Qutecom, reply
"500 Retry Later" and the subscription gets lost.

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

Comment By: Anca Vamanu (anca_vamanu)
Date: 2009-05-13 17:21

Message:
It must be faith that the line in your file(3265) is exactly the number for
the RFC about sip event notifications (http://www.ietf.org/rfc/rfc3265.txt)
:) . 

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

Comment By: I?aki Baz Castillo (ibc_sf)
Date: 2009-05-13 16:21

Message:
Take into account that I have a proxy between clients and presence server
(and I forgot to filter one of them with ngrep).

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

Comment By: Anca Vamanu (anca_vamanu)
Date: 2009-05-13 16:17

Message:
Yes, it is very strange - and it seems like the presence module generates a
couple of Notifies one after the other. I will look into this.

Anca

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

Comment By: I?aki Baz Castillo (ibc_sf)
Date: 2009-05-13 16:09

Message:
I can reproduce this error with Qutecom trunk (which has a not very good
presence implementation). I cna't reproduce it with Twinkle which works
perfectly now.

But anyway, it's very strange so many NOTIFY's for the same dialog, isn't?

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

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


From ag at ag-projects.com  Sun May 24 17:45:20 2009
From: ag at ag-projects.com (Adrian Georgescu)
Date: Sun, 24 May 2009 17:45:20 +0200
Subject: [OpenSIPS-Devel] new CDRTool release 6.8.0
Message-ID: <7F669583-368B-4A9C-AEC7-C056894B0EFB@ag-projects.com>

Hello,

The software contains bug fixes and new features related to  
partitioning of data for multiple resellers. You must read and apply  
the change log carefully to migrate from an older version, in  
particular the changes from setup/mysql/alter_tables.mysql

Changelog

cdrtool (6.8.0) unstable; urgency=low

   * Added reseller fields to all database tables to allow different  
login
     accounts to access their own data based on the account  
impersonate field
   * Allow import of CSV files from subdirectories (read updated 'Data
     partitioning for multiple resellers' section from RATING.txt)
   * Added prepaid_history table to rating table web management
   * Added increment and min_duration for each rate entry
   * Removed gateway, domain and subscriber columns from  
billing_profiles table
   * Removed gateway, domain and subscriber columns from billing_rates  
table
   * Removed gateway, domain and subscriber columns from  
billing_rates_history table
   * Updated CSV format for all rating tables to support the above  
changes,
     see setup/csv for updated examples of CSV files or export your  
live data
     from CDRTool rating tables page to see the new fields
   * Removed obsolete prepaid.call_lock and prepaid.call_in_progress  
columns
   * Removed obsolete customers.country_code column
   * Removed obsolete tables ratesNGN and profilesNGN
   * Renamed colummn prepaid_history.number with  
prepaid_history.description
   * Show SIP trace also in text only format
   * Do not log zero priced calls in prepaid_history table
   * Improved SIP prepaid provisioning screens
   * Skip math calculation for some rating tables
   * Added export balance history from SIP prepaid page
   * Updated ngnpro client to work with server version 4.1.1
   * Make stronger random passwords for SIP accounts
   * Improved NGNPro LCR functionality
   * Added scripts/OpenSIPS/notifyLastSessions.php to send email
     notifications containing the last sessions recived in the last 24  
hours.
     You must set notifyLastSessions per data source to tru to enable  
this
     feature and put the susbcriber into missed_calls group
   * You must apply the changes from setup/mysql/alter_tables.mysql
   * You must add an integer `reseller_id` column to opensips.trusted  
and
     opensips.domain tables
   * Changed column prepaid_cards.value to decimal
   * Droped unused columns from prepaid table
   * Added a script to test the speed of the rating engine


The software can be downloaded from:

http://download.ag-projects.com/CDRTool/

For people running Debian testing there is an official public  
repository. To use it, add
these lines in /etc/apt/sources.list

# AG Projects software
deb     http://ag-projects.com/debian unstable main
deb-src http://ag-projects.com/debian unstable main

Install the AG Projects debian software signing key:

wget http://download.ag-projects.com/agp-debian-gpg.key
apt-key add agp-debian-gpg.key

After that, run:

apt-get update
apt-get install cdrtool

Regards,
Adrian



From noreply at sourceforge.net  Mon May 25 10:20:08 2009
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 25 May 2009 08:20:08 +0000
Subject: [OpenSIPS-Devel] [ opensips-Patches-2706135 ] Change to listen=
	syntax to support per-interface advertised
Message-ID: <E1M8VPk-0006fv-D1@h45xhf1.ch3.sourceforge.com>

Patches item #2706135, was opened at 2009-03-23 14:50
Message generated for change (Comment added) made by nergalex
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086412&aid=2706135&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: Phil D'Amore (ptdamore)
Assigned to: Bogdan-Andrei Iancu (bogdan_iancu)
Summary: Change to listen= syntax to support per-interface advertised

Initial Comment:
[This is the patch for an idea I posted several weeks ago to the devel list.
Below is the original list posting as an explanation.]

The patch extends the idea of the advertised_address and advertised_port
parameters so that it is possible to bind such an address to each
listen= statement.

Syntax-wise, it works like this:

  listen=[proto:]host[:port][ AS host[:port]]

This new AS host[:port] syntax binds the advertised address specifically to the
corresponding socket_info structure.  If such an address is specified, it will
be used before the address specified as advertised_address, or set in the
set_advertised_address function for packets being sent on that particular
socket.  If it is not specified, then the old methods work as before.

The core has been modified so that address tuples using the advertised address
work interchangeably with the real address where you'd expect them to.
grep_sock_info and find_si have been updated to allow this.  Therefore, it is
not necessary to explicitly name your advertised address on an alias= line.
The following are now equivalent:

  force_send_socket(udp:adv_address:adv_port);
  force_send_socket(udp:real_address:real_port);

Note we don't specify protocol on the advertised address.  The way I see
things, it makes no sense to advertise a different protocol, so it inherits the
protocol of the socket.

Via construction is affected in the same way that the old global
advertised_address does, except the Via is written specifically for
the socket used
to send the message.

Lump substitution is also affected.  The following lump substitutions are aware
of this new facility:

 SUBST_RCV_IP
 SUBST_RCV_PORT
 SUBST_RCV_ALL
 SUBST_SND_IP
 SUBST_SND_PORT
 SUBST_SND_ALL

As a result of this, I was able to stop using record_route_preset in
my own config, and
just use standard record_route.  This winds up working much better,
because double-rr
works properly, and add_rr_param now works as expected for me, where it was a
problem using record_route_preset.

Additionally, registrar and usrloc had to be modified:

registrar - update the add_sock_hdr function to put the advertised address in
the message instead of the real address.  This allows registration information
to be replicated between multi-homed proxies, and the correct interface on the
peer can be used.

usrloc - update db_insert_ucontact to store the advertised address in the
database instead of the real address.  Same reasoning as the mods to registrar.

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

Comment By: Nergal (nergalex)
Date: 2009-05-25 10:20

Message:
Hello,

Sorry to post this comment so late, I was in vacancy.
History: https://sourceforge.net/forum/message.php?msg_id=7379817

Best regards 
Alexis 
-------------------
I have a bug on the patch "Change to listen= syntax to support
per-interface advertised - ID: 2706135". In the first Record-Route header,
a random caracter ends the <IP:Port> entry (see below 2 tests with the same
configuration and the extra caracter is ';'). 
Could you help me to fix it? 
I can do more test or give you more information if you need. 
 
Maybe a clue: the Advertised port is 4 digits long but the real port is 5
digits long. 
 
conf extract: 
- X.X.X.X is a public IP 
- listen=tcp:10.143.136.8:15060 AS 10.143.136.29:5060 
- force_send_socket(10.143.136.8:15060); 
- t_relay("tcp:10.143.81.130:5060") 
 
 
--- Test OK / proto TCP --- 
1. Before SIP proxy processing (Front interface capture) 
SUBSCRIBE sip:service at pilote-sip.my_domain:5060 SIP/2.0 
Via: SIP/2.0/TCP 10.95.10.1:10005;branch=z9hG4bK-1338-1-0 
From: userA at sfr.fr <sip:sipp at 10.95.10.1:10005>;tag=1338SIPpTag001 
To: userA at sfr.fr <sip:service at pilote-sip.my_domain:5060> 
Call-ID: 1-1338 at 10.95.10.1 
CSeq: 1 SUBSCRIBE 
Contact: sip:sipp at 10.95.10.1:10005 
Max-Forwards: 70 
Subject: Subscribe Test 
Content-Length: 0 
 
2. After SIP proxy processing (Back interface capture) 
SUBSCRIBE sip:service at pilote-sip.my_domain:5060 SIP/2.0 
Record-Route:
<sip:10.143.136.29:5060;transport=tcp;r2=on;lr=on;ftag=1338SIPpTag001> 
Record-Route:
<sip:X.X.X.X:5060;transport=tcp;r2=on;lr=on;ftag=1338SIPpTag001> 
Via: SIP/2.0/TCP 10.143.136.29:5060;branch=z9hG4bKa4b3.1d7725a.0;i=9e8f 
Via: SIP/2.0/TCP
10.95.10.1:10005;rport=32769;received=10.95.10.1;branch=z9hG4bK-1338-1-0 
From: userA at sfr.fr <sip:sipp at 10.95.10.1:10005>;tag=1338SIPpTag001 
To: userA at sfr.fr <sip:service at pilote-sip.my_domain:5060> 
Call-ID: 1-1338 at 10.95.10.1 
CSeq: 1 SUBSCRIBE 
Contact: sip:sipp at 10.95.10.1:10005 
Max-Forwards: 69 
Subject: Subscribe Test 
Content-Length: 0 
--- end Test OK --- 
 
--- Test NOK / proto TCP --- 
1. Before SIP proxy processing (Front interface capture) 
SUBSCRIBE sip:service at pilote-sip.my_domain:5060 SIP/2.0 
Via: SIP/2.0/TCP 10.95.10.1:10003;branch=z9hG4bK-1571-1-0 
From: userA at sfr.fr <sip:sipp at 10.95.10.1:10003>;tag=1571SIPpTag001 
To: userA at sfr.fr <sip:service at pilote-sip.my_domain:5060> 
Call-ID: 1-1571 at 10.95.10.1 
CSeq: 1 SUBSCRIBE 
Contact: sip:sipp at 10.95.10.1:10003 
Max-Forwards: 70 
Subject: Subscribe Test 
Content-Length: 0 
 
2. After SIP proxy processing (Back interface capture) 
SUBSCRIBE sip:service at pilote-sip.my_domain:5060 SIP/2.0 
Record-Route:
<sip:10.143.136.29:5060;transport=tcp;r2=on;lr=on;ftag=1571SIPpTag001> 
Record-Route:
<sip:X.X.X.X:5060;;transport=tcp;r2=on;lr=on;ftag=1571SIPpTag001> 
Via: SIP/2.0/TCP 10.143.136.29:5060;branch=z9hG4bK60ec.650af5e3.0;i=83401 
Via: SIP/2.0/TCP
10.95.10.1:10003;rport=32808;received=10.95.10.1;branch=z9hG4bK-1571-1-0 
From: userA at sfr.fr <sip:sipp at 10.95.10.1:10003>;tag=1571SIPpTag001 
To: userA at sfr.fr <sip:service at pilote-sip.my_domain:5060> 
Call-ID: 1-1571 at 10.95.10.1 
CSeq: 1 SUBSCRIBE 
Contact: sip:sipp at 10.95.10.1:10003 
Max-Forwards: 69 
Subject: Subscribe Test 
Content-Length: 0 
--- end Test NOK --- 
 
Best regards 
Alexis 

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

Comment By: Bogdan-Andrei Iancu (bogdan_iancu)
Date: 2009-05-09 10:15

Message:
Hi Phil,

I will start reviewing the patch in order to upload it on SVN. If I have
some questions about it, I will post them here.

Thanks and regards,
Bogdan

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

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


From bogdan at voice-system.ro  Mon May 25 11:17:20 2009
From: bogdan at voice-system.ro (Bogdan-Andrei Iancu)
Date: Mon, 25 May 2009 09:17:20 +0000
Subject: [OpenSIPS-Devel] SF.net SVN: opensips:[5732] trunk
Message-ID: <E1M8WJ6-00038S-FY@3kljzd1.ch3.sourceforge.com>

Revision: 5732
          http://opensips.svn.sourceforge.net/opensips/?rev=5732&view=rev
Author:   bogdan_iancu
Date:     2009-05-25 09:17:20 +0000 (Mon, 25 May 2009)

Log Message:
-----------
- fixed bug in version of rls-presentity table (1 instead of 0).
  Credits go to Franz Edler.

Modified Paths:
--------------
    trunk/db/schema/rls_presentity.xml
    trunk/scripts/db_berkeley/opensips/version
    trunk/scripts/dbtext/opensips/version
    trunk/scripts/mysql/rls-create.sql
    trunk/scripts/oracle/rls-create.sql
    trunk/scripts/postgres/rls-create.sql


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 May 25 11:21:19 2009
From: bogdan at voice-system.ro (Bogdan-Andrei Iancu)
Date: Mon, 25 May 2009 09:21:19 +0000
Subject: [OpenSIPS-Devel] SF.net SVN: opensips:[5733] branches/1.5
Message-ID: <E1M8WMx-0003CO-CK@3kljzd1.ch3.sourceforge.com>

Revision: 5733
          http://opensips.svn.sourceforge.net/opensips/?rev=5733&view=rev
Author:   bogdan_iancu
Date:     2009-05-25 09:21:19 +0000 (Mon, 25 May 2009)

Log Message:
-----------
backport from trunk (rev #5732):
- fixed bug in version of rls-presentity table (1 instead of 0).
  Credits go to Franz Edler.

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

Modified Paths:
--------------
    branches/1.5/db/schema/rls_presentity.xml
    branches/1.5/scripts/db_berkeley/opensips/version
    branches/1.5/scripts/dbtext/opensips/version
    branches/1.5/scripts/mysql/rls-create.sql
    branches/1.5/scripts/oracle/rls-create.sql
    branches/1.5/scripts/postgres/rls-create.sql


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


From noreply at sourceforge.net  Mon May 25 12:35:36 2009
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 25 May 2009 10:35:36 +0000
Subject: [OpenSIPS-Devel] [ opensips-Bugs-2791186 ] [presence] crazy NOTIFY's
Message-ID: <E1M8XWq-0002js-PO@d45xhf1.ch3.sourceforge.com>

Bugs item #2791186, was opened at 2009-05-13 15:36
Message generated for change (Comment added) made by ibc_sf
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=2791186&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: I?aki Baz Castillo (ibc_sf)
Assigned to: Nobody/Anonymous (nobody)
Summary: [presence] crazy NOTIFY's

Initial Comment:
Rev 5706.

modparam("presence", "max_expires_publish", 30)
modparam("presence", "max_expires_subscribe", 40)
modparam("presence", "expires_offset", 5)
modparam("presence", "fallback2db", 1)


Just one client subscribed to itself (30004). All works well at the beginning, but after some time OpenSIPS starts sending *a lot* of NOTIFY's (no retransmissions) in the same seconds (for the same subscription dialog and with the same info).
This causes the client (Qutecom) replying "500 Retry Later".

I attach a very long capture, but go to line 3265 to see the issue.


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

>Comment By: I?aki Baz Castillo (ibc_sf)
Date: 2009-05-25 12:35

Message:
Note that Qutecom has an error in the PUBLISH implementation since it
generates a *new* PUBLISH each time instead of using the SIP-If-Match
header:
  http://trac.qutecom.org/ticket/93

However I'm not sure that this should be the cause (but it could since
Qutecom always sets the same tuple id in the PUBLISH body).

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

Comment By: I?aki Baz Castillo (ibc_sf)
Date: 2009-05-24 00:49

Message:
I've attached a new file (sequential_crazy_NOTIFY's.txt). It's a SIP
capture of OpenSIPS sending 6 NOTIFY's in less than a second. All of these
NOTIFY's are part of the same subscription dialog, and are sequential
requests (from CSeq: 8 to CSeq:13).
Twinkle replies 200 for each NOTIFY, but other clients, as Qutecom, reply
"500 Retry Later" and the subscription gets lost.

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

Comment By: Anca Vamanu (anca_vamanu)
Date: 2009-05-13 17:21

Message:
It must be faith that the line in your file(3265) is exactly the number for
the RFC about sip event notifications (http://www.ietf.org/rfc/rfc3265.txt)
:) . 

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

Comment By: I?aki Baz Castillo (ibc_sf)
Date: 2009-05-13 16:21

Message:
Take into account that I have a proxy between clients and presence server
(and I forgot to filter one of them with ngrep).

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

Comment By: Anca Vamanu (anca_vamanu)
Date: 2009-05-13 16:17

Message:
Yes, it is very strange - and it seems like the presence module generates a
couple of Notifies one after the other. I will look into this.

Anca

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

Comment By: I?aki Baz Castillo (ibc_sf)
Date: 2009-05-13 16:09

Message:
I can reproduce this error with Qutecom trunk (which has a not very good
presence implementation). I cna't reproduce it with Twinkle which works
perfectly now.

But anyway, it's very strange so many NOTIFY's for the same dialog, isn't?

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

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


From noreply at sourceforge.net  Mon May 25 14:55:32 2009
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 25 May 2009 12:55:32 +0000
Subject: [OpenSIPS-Devel] [ opensips-Bugs-2791186 ] [presence] crazy NOTIFY's
Message-ID: <E1M8ZiG-0002n2-Bu@3bkjzd1.ch3.sourceforge.com>

Bugs item #2791186, was opened at 2009-05-13 16:36
Message generated for change (Settings changed) made by anca_vamanu
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=2791186&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: I?aki Baz Castillo (ibc_sf)
>Assigned to: Anca Vamanu (anca_vamanu)
Summary: [presence] crazy NOTIFY's

Initial Comment:
Rev 5706.

modparam("presence", "max_expires_publish", 30)
modparam("presence", "max_expires_subscribe", 40)
modparam("presence", "expires_offset", 5)
modparam("presence", "fallback2db", 1)


Just one client subscribed to itself (30004). All works well at the beginning, but after some time OpenSIPS starts sending *a lot* of NOTIFY's (no retransmissions) in the same seconds (for the same subscription dialog and with the same info).
This causes the client (Qutecom) replying "500 Retry Later".

I attach a very long capture, but go to line 3265 to see the issue.


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

>Comment By: Anca Vamanu (anca_vamanu)
Date: 2009-05-25 15:55

Message:
Hi Inaki,

I can not figure out from the code why such thing will happen. The
multiple Publish should not have anything to do with this. 
Can you please raise the debug level and attach the log file section
starting with the processing of the Subscribe that triggers a series of
Notifies?

regards,
Anca

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

Comment By: I?aki Baz Castillo (ibc_sf)
Date: 2009-05-25 13:35

Message:
Note that Qutecom has an error in the PUBLISH implementation since it
generates a *new* PUBLISH each time instead of using the SIP-If-Match
header:
  http://trac.qutecom.org/ticket/93

However I'm not sure that this should be the cause (but it could since
Qutecom always sets the same tuple id in the PUBLISH body).

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

Comment By: I?aki Baz Castillo (ibc_sf)
Date: 2009-05-24 01:49

Message:
I've attached a new file (sequential_crazy_NOTIFY's.txt). It's a SIP
capture of OpenSIPS sending 6 NOTIFY's in less than a second. All of these
NOTIFY's are part of the same subscription dialog, and are sequential
requests (from CSeq: 8 to CSeq:13).
Twinkle replies 200 for each NOTIFY, but other clients, as Qutecom, reply
"500 Retry Later" and the subscription gets lost.

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

Comment By: Anca Vamanu (anca_vamanu)
Date: 2009-05-13 18:21

Message:
It must be faith that the line in your file(3265) is exactly the number for
the RFC about sip event notifications (http://www.ietf.org/rfc/rfc3265.txt)
:) . 

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

Comment By: I?aki Baz Castillo (ibc_sf)
Date: 2009-05-13 17:21

Message:
Take into account that I have a proxy between clients and presence server
(and I forgot to filter one of them with ngrep).

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

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

Message:
Yes, it is very strange - and it seems like the presence module generates a
couple of Notifies one after the other. I will look into this.

Anca

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

Comment By: I?aki Baz Castillo (ibc_sf)
Date: 2009-05-13 17:09

Message:
I can reproduce this error with Qutecom trunk (which has a not very good
presence implementation). I cna't reproduce it with Twinkle which works
perfectly now.

But anyway, it's very strange so many NOTIFY's for the same dialog, isn't?

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

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


From noreply at sourceforge.net  Mon May 25 16:00:41 2009
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 25 May 2009 14:00:41 +0000
Subject: [OpenSIPS-Devel] [ opensips-Bugs-2796442 ] presence:
	active_watchers deletes data before "expires" time
Message-ID: <E1M8ajJ-0006VG-8m@b55xhf1.ch3.sourceforge.com>

Bugs item #2796442, was opened at 2009-05-25 16:00
Message generated for change (Tracker Item Submitted) made by ibc_sf
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=2796442&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: I?aki Baz Castillo (ibc_sf)
Assigned to: Nobody/Anonymous (nobody)
Summary: presence: active_watchers deletes data before "expires" time

Initial Comment:
OpenSIPS trunk rev 5706.

Presence related configuration:
-----------
modparam("presence", "max_expires_publish", 100)
modparam("presence", "max_expires_subscribe", 140)
modparam("presence", "expires_offset", 5)
modparam("presence", "fallback2db", 1)
-----------


After several testing I'm sure that the presence module is removing entries from active_watchers table before the "expires" time.
Please, take a look to the following real trace:


#### 30004 is subscribes to itself (30004) and it's receiving NOTIFY's correctly:

U 2009/05/25 15:47:21.530093 PROXY:5060 -> CLIENT:58198
NOTIFY sip:30004 at CLIENT:58198 SIP/2.0 
Via: SIP/2.0/UDP PROXY;branch=z9hG4bK95ab.5b04a0d3.0 
Via: SIP/2.0/UDP PROXY:5070;rport=5070;received=PROXY;branch=z9hG4bK95ab.d43429f5.0 
To: <sip:30004 at domain.org>;tag=549581004 
From: <sip:30004 at domain.org>;tag=13b52bc3e9f25b251a1546eb57a3a45c-f79d 
CSeq: 9 NOTIFY 
Call-ID: 498522887 at 10.134.16.124 
Content-Length: 286 
User-Agent: OpenSIPS (1.6.0dev0-notls (x86_64/linux)) 
Max-Forwards: 69 
Event: presence 
Contact: <sip:presence at PROXY:5070> 
Subscription-State: active;expires=129 
Content-Type: application/pidf+xml 
 
<?xml version="1.0" encoding="UTF-8"?>
<presence xmlns="urn:ietf:params:xml:ns:pidf" entity="sip:30004 at domain.org">
<tuple id="azersdqre">
<status><basic>closed</basic></status>
<note/>
<contact priority="1">sip:30004 at domain.org</contact>
</tuple>
</presence>

#
U 2009/05/25 15:47:21.537056 CLIENT:58198 -> PROXY:5060
SIP/2.0 100 Trying 
Via: SIP/2.0/UDP PROXY;branch=z9hG4bK95ab.5b04a0d3.0 
Via: SIP/2.0/UDP PROXY:5070;rport=5070;received=PROXY;branch=z9hG4bK95ab.d43429f5.0 
From: <sip:30004 at domain.org>;tag=13b52bc3e9f25b251a1546eb57a3a45c-f79d 
To: <sip:30004 at domain.org>;tag=549581004 
Call-ID: 498522887 at 10.134.16.124 
CSeq: 9 NOTIFY 
Allow: INVITE, ACK, OPTIONS, CANCEL, BYE, SUBSCRIBE, NOTIFY, MESSAGE, INFO, REFER 
Content-Length: 0 
 

U 2009/05/25 15:47:26.536018 CLIENT:58198 -> PROXY:5060
SIP/2.0 200 OK 
Via: SIP/2.0/UDP PROXY;branch=z9hG4bK95ab.5b04a0d3.0 
Via: SIP/2.0/UDP PROXY:5070;rport=5070;received=PROXY;branch=z9hG4bK95ab.d43429f5.0 
From: <sip:30004 at domain.org>;tag=13b52bc3e9f25b251a1546eb57a3a45c-f79d 
To: <sip:30004 at domain.org>;tag=549581004 
Call-ID: 498522887 at 10.134.16.124 
CSeq: 9 NOTIFY 
Allow: INVITE, ACK, OPTIONS, CANCEL, BYE, SUBSCRIBE, NOTIFY, MESSAGE, INFO, REFER 
Content-Length: 0 



### Note that the above NOTIFY has "expires=129" (time = 15:47:21)



### After some seconds, the client changes its presence status and sends a PUBLISH:

U 2009/05/25 15:47:34.247389 CLIENT:58198 -> PROXY:5060
PUBLISH sip:30004 at domain.org SIP/2.0 
Via: SIP/2.0/UDP 10.134.16.124:5060;rport;branch=z9hG4bK1904795625 
From: <sip:30004 at domain.org>;tag=1301576530 
To: <sip:30004 at domain.org> 
Call-ID: 2135969787 at 10.134.16.124 
CSeq: 21 PUBLISH 
Contact: <sip:30004 at 10.134.16.124:5060> 
Max-Forwards: 70 
User-Agent: qutecom/revb9d37dbd4b26/trunk/ 
Event: presence 
Allow: INVITE, ACK, CANCEL, BYE, OPTIONS, REFER, SUBSCRIBE, NOTIFY, MESSAGE 
Content-Type: application/pidf+xml 
Content-Length:   296 
 
<?xml version="1.0" encoding="UTF-8"?>
<presence xmlns="urn:ietf:params:xml:ns:pidf"
entity="sip:30004 at domain.org">
<tuple id="azersdqre">
<status><basic>open</basic></status>
<note>online</note>
<contact priority="1">sip:30004 at domain.org</contact>
</tuple>
</presence>

#
U 2009/05/25 15:47:34.249011 PROXY:5060 -> CLIENT:58198
SIP/2.0 200 OK 
Via: SIP/2.0/UDP 10.134.16.124:5060;received=CLIENT;rport=58198;branch=z9hG4bK1904795625 
From: <sip:30004 at domain.org>;tag=1301576530 
To: <sip:30004 at domain.org>;tag=13b52bc3e9f25b251a1546eb57a3a45c-8e7e 
Call-ID: 2135969787 at 10.134.16.124 
CSeq: 21 PUBLISH 
Expires: 95 
SIP-ETag: a.1243257770.21790.6.0 
Server: OpenSIPS (1.6.0dev0-notls (x86_64/linux)) 
Content-Length: 0 



#### And now, there is **NO** NOTIFY!!!
#### It doesn't make sense since the previous NOTIFY (15:47:21) said (expires=129)
#### and the new PUBLISH is at 15:47:34 (just 23 seconds after the previous NOTIFY).
#### I can sure that at this time the subscription has been deleted in the "active_watchers" 
#### table so this must be an error.

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

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


From noreply at sourceforge.net  Mon May 25 16:44:17 2009
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 25 May 2009 14:44:17 +0000
Subject: [OpenSIPS-Devel] [ opensips-Bugs-2796442 ] presence:
	active_watchers deletes data before "expires" time
Message-ID: <E1M8bPV-0006mx-DZ@h45xhf1.ch3.sourceforge.com>

Bugs item #2796442, was opened at 2009-05-25 16:00
Message generated for change (Comment added) made by ibc_sf
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=2796442&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: I?aki Baz Castillo (ibc_sf)
Assigned to: Nobody/Anonymous (nobody)
Summary: presence: active_watchers deletes data before "expires" time

Initial Comment:
OpenSIPS trunk rev 5706.

Presence related configuration:
-----------
modparam("presence", "max_expires_publish", 100)
modparam("presence", "max_expires_subscribe", 140)
modparam("presence", "expires_offset", 5)
modparam("presence", "fallback2db", 1)
-----------


After several testing I'm sure that the presence module is removing entries from active_watchers table before the "expires" time.
Please, take a look to the following real trace:


#### 30004 is subscribes to itself (30004) and it's receiving NOTIFY's correctly:

U 2009/05/25 15:47:21.530093 PROXY:5060 -> CLIENT:58198
NOTIFY sip:30004 at CLIENT:58198 SIP/2.0 
Via: SIP/2.0/UDP PROXY;branch=z9hG4bK95ab.5b04a0d3.0 
Via: SIP/2.0/UDP PROXY:5070;rport=5070;received=PROXY;branch=z9hG4bK95ab.d43429f5.0 
To: <sip:30004 at domain.org>;tag=549581004 
From: <sip:30004 at domain.org>;tag=13b52bc3e9f25b251a1546eb57a3a45c-f79d 
CSeq: 9 NOTIFY 
Call-ID: 498522887 at 10.134.16.124 
Content-Length: 286 
User-Agent: OpenSIPS (1.6.0dev0-notls (x86_64/linux)) 
Max-Forwards: 69 
Event: presence 
Contact: <sip:presence at PROXY:5070> 
Subscription-State: active;expires=129 
Content-Type: application/pidf+xml 
 
<?xml version="1.0" encoding="UTF-8"?>
<presence xmlns="urn:ietf:params:xml:ns:pidf" entity="sip:30004 at domain.org">
<tuple id="azersdqre">
<status><basic>closed</basic></status>
<note/>
<contact priority="1">sip:30004 at domain.org</contact>
</tuple>
</presence>

#
U 2009/05/25 15:47:21.537056 CLIENT:58198 -> PROXY:5060
SIP/2.0 100 Trying 
Via: SIP/2.0/UDP PROXY;branch=z9hG4bK95ab.5b04a0d3.0 
Via: SIP/2.0/UDP PROXY:5070;rport=5070;received=PROXY;branch=z9hG4bK95ab.d43429f5.0 
From: <sip:30004 at domain.org>;tag=13b52bc3e9f25b251a1546eb57a3a45c-f79d 
To: <sip:30004 at domain.org>;tag=549581004 
Call-ID: 498522887 at 10.134.16.124 
CSeq: 9 NOTIFY 
Allow: INVITE, ACK, OPTIONS, CANCEL, BYE, SUBSCRIBE, NOTIFY, MESSAGE, INFO, REFER 
Content-Length: 0 
 

U 2009/05/25 15:47:26.536018 CLIENT:58198 -> PROXY:5060
SIP/2.0 200 OK 
Via: SIP/2.0/UDP PROXY;branch=z9hG4bK95ab.5b04a0d3.0 
Via: SIP/2.0/UDP PROXY:5070;rport=5070;received=PROXY;branch=z9hG4bK95ab.d43429f5.0 
From: <sip:30004 at domain.org>;tag=13b52bc3e9f25b251a1546eb57a3a45c-f79d 
To: <sip:30004 at domain.org>;tag=549581004 
Call-ID: 498522887 at 10.134.16.124 
CSeq: 9 NOTIFY 
Allow: INVITE, ACK, OPTIONS, CANCEL, BYE, SUBSCRIBE, NOTIFY, MESSAGE, INFO, REFER 
Content-Length: 0 



### Note that the above NOTIFY has "expires=129" (time = 15:47:21)



### After some seconds, the client changes its presence status and sends a PUBLISH:

U 2009/05/25 15:47:34.247389 CLIENT:58198 -> PROXY:5060
PUBLISH sip:30004 at domain.org SIP/2.0 
Via: SIP/2.0/UDP 10.134.16.124:5060;rport;branch=z9hG4bK1904795625 
From: <sip:30004 at domain.org>;tag=1301576530 
To: <sip:30004 at domain.org> 
Call-ID: 2135969787 at 10.134.16.124 
CSeq: 21 PUBLISH 
Contact: <sip:30004 at 10.134.16.124:5060> 
Max-Forwards: 70 
User-Agent: qutecom/revb9d37dbd4b26/trunk/ 
Event: presence 
Allow: INVITE, ACK, CANCEL, BYE, OPTIONS, REFER, SUBSCRIBE, NOTIFY, MESSAGE 
Content-Type: application/pidf+xml 
Content-Length:   296 
 
<?xml version="1.0" encoding="UTF-8"?>
<presence xmlns="urn:ietf:params:xml:ns:pidf"
entity="sip:30004 at domain.org">
<tuple id="azersdqre">
<status><basic>open</basic></status>
<note>online</note>
<contact priority="1">sip:30004 at domain.org</contact>
</tuple>
</presence>

#
U 2009/05/25 15:47:34.249011 PROXY:5060 -> CLIENT:58198
SIP/2.0 200 OK 
Via: SIP/2.0/UDP 10.134.16.124:5060;received=CLIENT;rport=58198;branch=z9hG4bK1904795625 
From: <sip:30004 at domain.org>;tag=1301576530 
To: <sip:30004 at domain.org>;tag=13b52bc3e9f25b251a1546eb57a3a45c-8e7e 
Call-ID: 2135969787 at 10.134.16.124 
CSeq: 21 PUBLISH 
Expires: 95 
SIP-ETag: a.1243257770.21790.6.0 
Server: OpenSIPS (1.6.0dev0-notls (x86_64/linux)) 
Content-Length: 0 



#### And now, there is **NO** NOTIFY!!!
#### It doesn't make sense since the previous NOTIFY (15:47:21) said (expires=129)
#### and the new PUBLISH is at 15:47:34 (just 23 seconds after the previous NOTIFY).
#### I can sure that at this time the subscription has been deleted in the "active_watchers" 
#### table so this must be an error.

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

>Comment By: I?aki Baz Castillo (ibc_sf)
Date: 2009-05-25 16:44

Message:
Humm, maybe it's a bug in the refresh SUBSCRIBE from the boggus Qutecom
softphone (I think I didn't capture SUSBCRIBE in the ngrep filter...).
It just *doesn't* happen at all with Twinkle. Let me re-check it please.

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

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


From bogdan at voice-system.ro  Mon May 25 17:19:34 2009
From: bogdan at voice-system.ro (Bogdan-Andrei Iancu)
Date: Mon, 25 May 2009 18:19:34 +0300
Subject: [OpenSIPS-Devel] Looking for an official debian maintainer
Message-ID: <4A1AB706.30907@voice-system.ro>

Hi,

If anyone knows an official debian maintainer willing to introduce the 
OpenSIPS debs into the main Debian tree, please let me know.

Thanks and regards,
Bogdan


From noreply at sourceforge.net  Mon May 25 22:18:56 2009
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 25 May 2009 20:18:56 +0000
Subject: [OpenSIPS-Devel] [ opensips-Patches-2706135 ] Change to listen=
	syntax to support per-interface advertised
Message-ID: <E1M8gdM-0006Vc-IU@b55xhf1.ch3.sourceforge.com>

Patches item #2706135, was opened at 2009-03-23 09:50
Message generated for change (Comment added) made by ptdamore
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086412&aid=2706135&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: Phil D'Amore (ptdamore)
Assigned to: Bogdan-Andrei Iancu (bogdan_iancu)
Summary: Change to listen= syntax to support per-interface advertised

Initial Comment:
[This is the patch for an idea I posted several weeks ago to the devel list.
Below is the original list posting as an explanation.]

The patch extends the idea of the advertised_address and advertised_port
parameters so that it is possible to bind such an address to each
listen= statement.

Syntax-wise, it works like this:

  listen=[proto:]host[:port][ AS host[:port]]

This new AS host[:port] syntax binds the advertised address specifically to the
corresponding socket_info structure.  If such an address is specified, it will
be used before the address specified as advertised_address, or set in the
set_advertised_address function for packets being sent on that particular
socket.  If it is not specified, then the old methods work as before.

The core has been modified so that address tuples using the advertised address
work interchangeably with the real address where you'd expect them to.
grep_sock_info and find_si have been updated to allow this.  Therefore, it is
not necessary to explicitly name your advertised address on an alias= line.
The following are now equivalent:

  force_send_socket(udp:adv_address:adv_port);
  force_send_socket(udp:real_address:real_port);

Note we don't specify protocol on the advertised address.  The way I see
things, it makes no sense to advertise a different protocol, so it inherits the
protocol of the socket.

Via construction is affected in the same way that the old global
advertised_address does, except the Via is written specifically for
the socket used
to send the message.

Lump substitution is also affected.  The following lump substitutions are aware
of this new facility:

 SUBST_RCV_IP
 SUBST_RCV_PORT
 SUBST_RCV_ALL
 SUBST_SND_IP
 SUBST_SND_PORT
 SUBST_SND_ALL

As a result of this, I was able to stop using record_route_preset in
my own config, and
just use standard record_route.  This winds up working much better,
because double-rr
works properly, and add_rr_param now works as expected for me, where it was a
problem using record_route_preset.

Additionally, registrar and usrloc had to be modified:

registrar - update the add_sock_hdr function to put the advertised address in
the message instead of the real address.  This allows registration information
to be replicated between multi-homed proxies, and the correct interface on the
peer can be used.

usrloc - update db_insert_ucontact to store the advertised address in the
database instead of the real address.  Same reasoning as the mods to registrar.

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

>Comment By: Phil D'Amore (ptdamore)
Date: 2009-05-25 16:18

Message:
Alexis :

I have a few questions for you:

1) To make sure I understand the problem, I want to re-word it a bit. 
Which of these statements is true about the problem
  a) An extra ';' (always a ';') character appears in the first
Record-Route header after host:port, at random times.
  b) An extra random character (not always ';') appears in the first
Record-Route header after host:port, at random times

2) Since you are using double-rr can I assume that you also have a
listen=X.X.X.X:5060 line in your configuration for your public inbound
interface, but it was not included in your message because it does not
specify the [AS host:port] portion?

If the answer to 2 is yes, can you try to specify an alias on that listen=
line like this:

listen=X.X.X.X:5060 AS X.X.X.X:5060

The effect should be that no re-write appears to happen as the left and
right side are the same, but the code used to get there would be slightly
different.  I'm curious to see if the extra ';' goes away in that case.

Thanks,
Phil

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

Comment By: Nergal (nergalex)
Date: 2009-05-25 04:20

Message:
Hello,

Sorry to post this comment so late, I was in vacancy.
History: https://sourceforge.net/forum/message.php?msg_id=7379817

Best regards 
Alexis 
-------------------
I have a bug on the patch "Change to listen= syntax to support
per-interface advertised - ID: 2706135". In the first Record-Route header,
a random caracter ends the <IP:Port> entry (see below 2 tests with the same
configuration and the extra caracter is ';'). 
Could you help me to fix it? 
I can do more test or give you more information if you need. 
 
Maybe a clue: the Advertised port is 4 digits long but the real port is 5
digits long. 
 
conf extract: 
- X.X.X.X is a public IP 
- listen=tcp:10.143.136.8:15060 AS 10.143.136.29:5060 
- force_send_socket(10.143.136.8:15060); 
- t_relay("tcp:10.143.81.130:5060") 
 
 
--- Test OK / proto TCP --- 
1. Before SIP proxy processing (Front interface capture) 
SUBSCRIBE sip:service at pilote-sip.my_domain:5060 SIP/2.0 
Via: SIP/2.0/TCP 10.95.10.1:10005;branch=z9hG4bK-1338-1-0 
From: userA at sfr.fr <sip:sipp at 10.95.10.1:10005>;tag=1338SIPpTag001 
To: userA at sfr.fr <sip:service at pilote-sip.my_domain:5060> 
Call-ID: 1-1338 at 10.95.10.1 
CSeq: 1 SUBSCRIBE 
Contact: sip:sipp at 10.95.10.1:10005 
Max-Forwards: 70 
Subject: Subscribe Test 
Content-Length: 0 
 
2. After SIP proxy processing (Back interface capture) 
SUBSCRIBE sip:service at pilote-sip.my_domain:5060 SIP/2.0 
Record-Route:
<sip:10.143.136.29:5060;transport=tcp;r2=on;lr=on;ftag=1338SIPpTag001> 
Record-Route:
<sip:X.X.X.X:5060;transport=tcp;r2=on;lr=on;ftag=1338SIPpTag001> 
Via: SIP/2.0/TCP 10.143.136.29:5060;branch=z9hG4bKa4b3.1d7725a.0;i=9e8f 
Via: SIP/2.0/TCP
10.95.10.1:10005;rport=32769;received=10.95.10.1;branch=z9hG4bK-1338-1-0 
From: userA at sfr.fr <sip:sipp at 10.95.10.1:10005>;tag=1338SIPpTag001 
To: userA at sfr.fr <sip:service at pilote-sip.my_domain:5060> 
Call-ID: 1-1338 at 10.95.10.1 
CSeq: 1 SUBSCRIBE 
Contact: sip:sipp at 10.95.10.1:10005 
Max-Forwards: 69 
Subject: Subscribe Test 
Content-Length: 0 
--- end Test OK --- 
 
--- Test NOK / proto TCP --- 
1. Before SIP proxy processing (Front interface capture) 
SUBSCRIBE sip:service at pilote-sip.my_domain:5060 SIP/2.0 
Via: SIP/2.0/TCP 10.95.10.1:10003;branch=z9hG4bK-1571-1-0 
From: userA at sfr.fr <sip:sipp at 10.95.10.1:10003>;tag=1571SIPpTag001 
To: userA at sfr.fr <sip:service at pilote-sip.my_domain:5060> 
Call-ID: 1-1571 at 10.95.10.1 
CSeq: 1 SUBSCRIBE 
Contact: sip:sipp at 10.95.10.1:10003 
Max-Forwards: 70 
Subject: Subscribe Test 
Content-Length: 0 
 
2. After SIP proxy processing (Back interface capture) 
SUBSCRIBE sip:service at pilote-sip.my_domain:5060 SIP/2.0 
Record-Route:
<sip:10.143.136.29:5060;transport=tcp;r2=on;lr=on;ftag=1571SIPpTag001> 
Record-Route:
<sip:X.X.X.X:5060;;transport=tcp;r2=on;lr=on;ftag=1571SIPpTag001> 
Via: SIP/2.0/TCP 10.143.136.29:5060;branch=z9hG4bK60ec.650af5e3.0;i=83401 
Via: SIP/2.0/TCP
10.95.10.1:10003;rport=32808;received=10.95.10.1;branch=z9hG4bK-1571-1-0 
From: userA at sfr.fr <sip:sipp at 10.95.10.1:10003>;tag=1571SIPpTag001 
To: userA at sfr.fr <sip:service at pilote-sip.my_domain:5060> 
Call-ID: 1-1571 at 10.95.10.1 
CSeq: 1 SUBSCRIBE 
Contact: sip:sipp at 10.95.10.1:10003 
Max-Forwards: 69 
Subject: Subscribe Test 
Content-Length: 0 
--- end Test NOK --- 
 
Best regards 
Alexis 

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

Comment By: Bogdan-Andrei Iancu (bogdan_iancu)
Date: 2009-05-09 04:15

Message:
Hi Phil,

I will start reviewing the patch in order to upload it on SVN. If I have
some questions about it, I will post them here.

Thanks and regards,
Bogdan

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

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


From noreply at sourceforge.net  Tue May 26 10:15:38 2009
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue, 26 May 2009 08:15:38 +0000
Subject: [OpenSIPS-Devel] [ opensips-Bugs-2796442 ] presence:
	active_watchers deletes data before "expires" time
Message-ID: <E1M8row-0007Vd-5b@d55xhf1.ch3.sourceforge.com>

Bugs item #2796442, was opened at 2009-05-25 17:00
Message generated for change (Comment added) made by anca_vamanu
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=2796442&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: I?aki Baz Castillo (ibc_sf)
>Assigned to: Anca Vamanu (anca_vamanu)
Summary: presence: active_watchers deletes data before "expires" time

Initial Comment:
OpenSIPS trunk rev 5706.

Presence related configuration:
-----------
modparam("presence", "max_expires_publish", 100)
modparam("presence", "max_expires_subscribe", 140)
modparam("presence", "expires_offset", 5)
modparam("presence", "fallback2db", 1)
-----------


After several testing I'm sure that the presence module is removing entries from active_watchers table before the "expires" time.
Please, take a look to the following real trace:


#### 30004 is subscribes to itself (30004) and it's receiving NOTIFY's correctly:

U 2009/05/25 15:47:21.530093 PROXY:5060 -> CLIENT:58198
NOTIFY sip:30004 at CLIENT:58198 SIP/2.0 
Via: SIP/2.0/UDP PROXY;branch=z9hG4bK95ab.5b04a0d3.0 
Via: SIP/2.0/UDP PROXY:5070;rport=5070;received=PROXY;branch=z9hG4bK95ab.d43429f5.0 
To: <sip:30004 at domain.org>;tag=549581004 
From: <sip:30004 at domain.org>;tag=13b52bc3e9f25b251a1546eb57a3a45c-f79d 
CSeq: 9 NOTIFY 
Call-ID: 498522887 at 10.134.16.124 
Content-Length: 286 
User-Agent: OpenSIPS (1.6.0dev0-notls (x86_64/linux)) 
Max-Forwards: 69 
Event: presence 
Contact: <sip:presence at PROXY:5070> 
Subscription-State: active;expires=129 
Content-Type: application/pidf+xml 
 
<?xml version="1.0" encoding="UTF-8"?>
<presence xmlns="urn:ietf:params:xml:ns:pidf" entity="sip:30004 at domain.org">
<tuple id="azersdqre">
<status><basic>closed</basic></status>
<note/>
<contact priority="1">sip:30004 at domain.org</contact>
</tuple>
</presence>

#
U 2009/05/25 15:47:21.537056 CLIENT:58198 -> PROXY:5060
SIP/2.0 100 Trying 
Via: SIP/2.0/UDP PROXY;branch=z9hG4bK95ab.5b04a0d3.0 
Via: SIP/2.0/UDP PROXY:5070;rport=5070;received=PROXY;branch=z9hG4bK95ab.d43429f5.0 
From: <sip:30004 at domain.org>;tag=13b52bc3e9f25b251a1546eb57a3a45c-f79d 
To: <sip:30004 at domain.org>;tag=549581004 
Call-ID: 498522887 at 10.134.16.124 
CSeq: 9 NOTIFY 
Allow: INVITE, ACK, OPTIONS, CANCEL, BYE, SUBSCRIBE, NOTIFY, MESSAGE, INFO, REFER 
Content-Length: 0 
 

U 2009/05/25 15:47:26.536018 CLIENT:58198 -> PROXY:5060
SIP/2.0 200 OK 
Via: SIP/2.0/UDP PROXY;branch=z9hG4bK95ab.5b04a0d3.0 
Via: SIP/2.0/UDP PROXY:5070;rport=5070;received=PROXY;branch=z9hG4bK95ab.d43429f5.0 
From: <sip:30004 at domain.org>;tag=13b52bc3e9f25b251a1546eb57a3a45c-f79d 
To: <sip:30004 at domain.org>;tag=549581004 
Call-ID: 498522887 at 10.134.16.124 
CSeq: 9 NOTIFY 
Allow: INVITE, ACK, OPTIONS, CANCEL, BYE, SUBSCRIBE, NOTIFY, MESSAGE, INFO, REFER 
Content-Length: 0 



### Note that the above NOTIFY has "expires=129" (time = 15:47:21)



### After some seconds, the client changes its presence status and sends a PUBLISH:

U 2009/05/25 15:47:34.247389 CLIENT:58198 -> PROXY:5060
PUBLISH sip:30004 at domain.org SIP/2.0 
Via: SIP/2.0/UDP 10.134.16.124:5060;rport;branch=z9hG4bK1904795625 
From: <sip:30004 at domain.org>;tag=1301576530 
To: <sip:30004 at domain.org> 
Call-ID: 2135969787 at 10.134.16.124 
CSeq: 21 PUBLISH 
Contact: <sip:30004 at 10.134.16.124:5060> 
Max-Forwards: 70 
User-Agent: qutecom/revb9d37dbd4b26/trunk/ 
Event: presence 
Allow: INVITE, ACK, CANCEL, BYE, OPTIONS, REFER, SUBSCRIBE, NOTIFY, MESSAGE 
Content-Type: application/pidf+xml 
Content-Length:   296 
 
<?xml version="1.0" encoding="UTF-8"?>
<presence xmlns="urn:ietf:params:xml:ns:pidf"
entity="sip:30004 at domain.org">
<tuple id="azersdqre">
<status><basic>open</basic></status>
<note>online</note>
<contact priority="1">sip:30004 at domain.org</contact>
</tuple>
</presence>

#
U 2009/05/25 15:47:34.249011 PROXY:5060 -> CLIENT:58198
SIP/2.0 200 OK 
Via: SIP/2.0/UDP 10.134.16.124:5060;received=CLIENT;rport=58198;branch=z9hG4bK1904795625 
From: <sip:30004 at domain.org>;tag=1301576530 
To: <sip:30004 at domain.org>;tag=13b52bc3e9f25b251a1546eb57a3a45c-8e7e 
Call-ID: 2135969787 at 10.134.16.124 
CSeq: 21 PUBLISH 
Expires: 95 
SIP-ETag: a.1243257770.21790.6.0 
Server: OpenSIPS (1.6.0dev0-notls (x86_64/linux)) 
Content-Length: 0 



#### And now, there is **NO** NOTIFY!!!
#### It doesn't make sense since the previous NOTIFY (15:47:21) said (expires=129)
#### and the new PUBLISH is at 15:47:34 (just 23 seconds after the previous NOTIFY).
#### I can sure that at this time the subscription has been deleted in the "active_watchers" 
#### table so this must be an error.

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

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

Message:
Hi Inaki,

I have tested myself now, also with twinkle and I didn't see any problem.
Also looked through the code and it doesn't seem to be a change for a
subscription dialog to be deleted but only with 10 seconds before it
actualy expires to force the phone to resubscribe.

regards,
Anca

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

Comment By: I?aki Baz Castillo (ibc_sf)
Date: 2009-05-25 17:44

Message:
Humm, maybe it's a bug in the refresh SUBSCRIBE from the boggus Qutecom
softphone (I think I didn't capture SUSBCRIBE in the ngrep filter...).
It just *doesn't* happen at all with Twinkle. Let me re-check it please.

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

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


From anca at opensips.org  Tue May 26 10:17:04 2009
From: anca at opensips.org (Anca Vamanu)
Date: Tue, 26 May 2009 08:17:04 +0000
Subject: [OpenSIPS-Devel] SF.net SVN: opensips:[5734] trunk/modules/presence
Message-ID: <E1M8rqK-0008QW-Vj@3kljzd1.ch3.sourceforge.com>

Revision: 5734
          http://opensips.svn.sourceforge.net/opensips/?rev=5734&view=rev
Author:   anca_vamanu
Date:     2009-05-26 08:17:04 +0000 (Tue, 26 May 2009)

Log Message:
-----------
- synchronized the moment when subsription dialogs are deleted from database with when dialogs are deleted from hash table

Modified Paths:
--------------
    trunk/modules/presence/publish.c
    trunk/modules/presence/subscribe.c


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


From anca at opensips.org  Tue May 26 10:18:58 2009
From: anca at opensips.org (Anca Vamanu)
Date: Tue, 26 May 2009 08:18:58 +0000
Subject: [OpenSIPS-Devel] SF.net SVN: opensips:[5735]
	branches/1.5/modules/presence/subscribe.c
Message-ID: <E1M8rsA-0008Sp-AM@3kljzd1.ch3.sourceforge.com>

Revision: 5735
          http://opensips.svn.sourceforge.net/opensips/?rev=5735&view=rev
Author:   anca_vamanu
Date:     2009-05-26 08:18:58 +0000 (Tue, 26 May 2009)

Log Message:
-----------
- synchronized the moment when subsription dialogs are deleted from database with when dialogs are deleted from hash table

Modified Paths:
--------------
    branches/1.5/modules/presence/subscribe.c


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


From anca at opensips.org  Tue May 26 10:29:41 2009
From: anca at opensips.org (Anca Vamanu)
Date: Tue, 26 May 2009 08:29:41 +0000
Subject: [OpenSIPS-Devel] SF.net SVN: opensips:[5736]
	branches/1.4/modules/presence/subscribe.c
Message-ID: <E1M8s2X-0000Cr-1K@3kljzd1.ch3.sourceforge.com>

Revision: 5736
          http://opensips.svn.sourceforge.net/opensips/?rev=5736&view=rev
Author:   anca_vamanu
Date:     2009-05-26 08:29:40 +0000 (Tue, 26 May 2009)

Log Message:
-----------
- synchronized the moment when subsription dialogs are deleted from database with when dialogs are deleted from hash table

Modified Paths:
--------------
    branches/1.4/modules/presence/subscribe.c


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


From anca at opensips.org  Tue May 26 11:10:59 2009
From: anca at opensips.org (Anca Vamanu)
Date: Tue, 26 May 2009 09:10:59 +0000
Subject: [OpenSIPS-Devel] SF.net SVN: opensips:[5737] trunk/modules/tm
Message-ID: <E1M8sgV-0001Jp-0J@bj8yhf1.ch3.sourceforge.com>

Revision: 5737
          http://opensips.svn.sourceforge.net/opensips/?rev=5737&view=rev
Author:   anca_vamanu
Date:     2009-05-26 09:10:58 +0000 (Tue, 26 May 2009)

Log Message:
-----------
- properly setting of end to end ACK transaction marker
- resetting transaction marker before reply matching

Modified Paths:
--------------
    trunk/modules/tm/t_reply.c
    trunk/modules/tm/tm.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 May 26 11:31:02 2009
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue, 26 May 2009 09:31:02 +0000
Subject: [OpenSIPS-Devel] [ opensips-Bugs-2796442 ] presence:
	active_watchers deletes data before "expires" time
Message-ID: <E1M8szu-0006e3-Fu@cdv4jf1.ch3.sourceforge.com>

Bugs item #2796442, was opened at 2009-05-25 16:00
Message generated for change (Comment added) made by ibc_sf
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=2796442&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: I?aki Baz Castillo (ibc_sf)
Assigned to: Anca Vamanu (anca_vamanu)
Summary: presence: active_watchers deletes data before "expires" time

Initial Comment:
OpenSIPS trunk rev 5706.

Presence related configuration:
-----------
modparam("presence", "max_expires_publish", 100)
modparam("presence", "max_expires_subscribe", 140)
modparam("presence", "expires_offset", 5)
modparam("presence", "fallback2db", 1)
-----------


After several testing I'm sure that the presence module is removing entries from active_watchers table before the "expires" time.
Please, take a look to the following real trace:


#### 30004 is subscribes to itself (30004) and it's receiving NOTIFY's correctly:

U 2009/05/25 15:47:21.530093 PROXY:5060 -> CLIENT:58198
NOTIFY sip:30004 at CLIENT:58198 SIP/2.0 
Via: SIP/2.0/UDP PROXY;branch=z9hG4bK95ab.5b04a0d3.0 
Via: SIP/2.0/UDP PROXY:5070;rport=5070;received=PROXY;branch=z9hG4bK95ab.d43429f5.0 
To: <sip:30004 at domain.org>;tag=549581004 
From: <sip:30004 at domain.org>;tag=13b52bc3e9f25b251a1546eb57a3a45c-f79d 
CSeq: 9 NOTIFY 
Call-ID: 498522887 at 10.134.16.124 
Content-Length: 286 
User-Agent: OpenSIPS (1.6.0dev0-notls (x86_64/linux)) 
Max-Forwards: 69 
Event: presence 
Contact: <sip:presence at PROXY:5070> 
Subscription-State: active;expires=129 
Content-Type: application/pidf+xml 
 
<?xml version="1.0" encoding="UTF-8"?>
<presence xmlns="urn:ietf:params:xml:ns:pidf" entity="sip:30004 at domain.org">
<tuple id="azersdqre">
<status><basic>closed</basic></status>
<note/>
<contact priority="1">sip:30004 at domain.org</contact>
</tuple>
</presence>

#
U 2009/05/25 15:47:21.537056 CLIENT:58198 -> PROXY:5060
SIP/2.0 100 Trying 
Via: SIP/2.0/UDP PROXY;branch=z9hG4bK95ab.5b04a0d3.0 
Via: SIP/2.0/UDP PROXY:5070;rport=5070;received=PROXY;branch=z9hG4bK95ab.d43429f5.0 
From: <sip:30004 at domain.org>;tag=13b52bc3e9f25b251a1546eb57a3a45c-f79d 
To: <sip:30004 at domain.org>;tag=549581004 
Call-ID: 498522887 at 10.134.16.124 
CSeq: 9 NOTIFY 
Allow: INVITE, ACK, OPTIONS, CANCEL, BYE, SUBSCRIBE, NOTIFY, MESSAGE, INFO, REFER 
Content-Length: 0 
 

U 2009/05/25 15:47:26.536018 CLIENT:58198 -> PROXY:5060
SIP/2.0 200 OK 
Via: SIP/2.0/UDP PROXY;branch=z9hG4bK95ab.5b04a0d3.0 
Via: SIP/2.0/UDP PROXY:5070;rport=5070;received=PROXY;branch=z9hG4bK95ab.d43429f5.0 
From: <sip:30004 at domain.org>;tag=13b52bc3e9f25b251a1546eb57a3a45c-f79d 
To: <sip:30004 at domain.org>;tag=549581004 
Call-ID: 498522887 at 10.134.16.124 
CSeq: 9 NOTIFY 
Allow: INVITE, ACK, OPTIONS, CANCEL, BYE, SUBSCRIBE, NOTIFY, MESSAGE, INFO, REFER 
Content-Length: 0 



### Note that the above NOTIFY has "expires=129" (time = 15:47:21)



### After some seconds, the client changes its presence status and sends a PUBLISH:

U 2009/05/25 15:47:34.247389 CLIENT:58198 -> PROXY:5060
PUBLISH sip:30004 at domain.org SIP/2.0 
Via: SIP/2.0/UDP 10.134.16.124:5060;rport;branch=z9hG4bK1904795625 
From: <sip:30004 at domain.org>;tag=1301576530 
To: <sip:30004 at domain.org> 
Call-ID: 2135969787 at 10.134.16.124 
CSeq: 21 PUBLISH 
Contact: <sip:30004 at 10.134.16.124:5060> 
Max-Forwards: 70 
User-Agent: qutecom/revb9d37dbd4b26/trunk/ 
Event: presence 
Allow: INVITE, ACK, CANCEL, BYE, OPTIONS, REFER, SUBSCRIBE, NOTIFY, MESSAGE 
Content-Type: application/pidf+xml 
Content-Length:   296 
 
<?xml version="1.0" encoding="UTF-8"?>
<presence xmlns="urn:ietf:params:xml:ns:pidf"
entity="sip:30004 at domain.org">
<tuple id="azersdqre">
<status><basic>open</basic></status>
<note>online</note>
<contact priority="1">sip:30004 at domain.org</contact>
</tuple>
</presence>

#
U 2009/05/25 15:47:34.249011 PROXY:5060 -> CLIENT:58198
SIP/2.0 200 OK 
Via: SIP/2.0/UDP 10.134.16.124:5060;received=CLIENT;rport=58198;branch=z9hG4bK1904795625 
From: <sip:30004 at domain.org>;tag=1301576530 
To: <sip:30004 at domain.org>;tag=13b52bc3e9f25b251a1546eb57a3a45c-8e7e 
Call-ID: 2135969787 at 10.134.16.124 
CSeq: 21 PUBLISH 
Expires: 95 
SIP-ETag: a.1243257770.21790.6.0 
Server: OpenSIPS (1.6.0dev0-notls (x86_64/linux)) 
Content-Length: 0 



#### And now, there is **NO** NOTIFY!!!
#### It doesn't make sense since the previous NOTIFY (15:47:21) said (expires=129)
#### and the new PUBLISH is at 15:47:34 (just 23 seconds after the previous NOTIFY).
#### I can sure that at this time the subscription has been deleted in the "active_watchers" 
#### table so this must be an error.

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

>Comment By: I?aki Baz Castillo (ibc_sf)
Date: 2009-05-26 11:31

Message:
Sure Anca, in the trace I captured I set a very restricted filter and
didn't capture some important messages (as refresh SUBSCRIBE's). I've also
done a several testing with Twinkle and it works *perfectly*. I've also
detected more and more bugs in presence implementation of Qutecom, so for
sure, it's not a OpenSIPS related bug. Sorry.
I close this bug.

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

Comment By: Anca Vamanu (anca_vamanu)
Date: 2009-05-26 10:15

Message:
Hi Inaki,

I have tested myself now, also with twinkle and I didn't see any problem.
Also looked through the code and it doesn't seem to be a change for a
subscription dialog to be deleted but only with 10 seconds before it
actualy expires to force the phone to resubscribe.

regards,
Anca

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

Comment By: I?aki Baz Castillo (ibc_sf)
Date: 2009-05-25 16:44

Message:
Humm, maybe it's a bug in the refresh SUBSCRIBE from the boggus Qutecom
softphone (I think I didn't capture SUSBCRIBE in the ngrep filter...).
It just *doesn't* happen at all with Twinkle. Let me re-check it please.

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

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


From noreply at sourceforge.net  Tue May 26 11:44:22 2009
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue, 26 May 2009 09:44:22 +0000
Subject: [OpenSIPS-Devel] [ opensips-Patches-2706135 ] Change to listen=
	syntax to support per-interface advertised
Message-ID: <E1M8tCo-0007d7-3d@155xhf1.ch3.sourceforge.com>

Patches item #2706135, was opened at 2009-03-23 14:50
Message generated for change (Comment added) made by nergalex
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086412&aid=2706135&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: Phil D'Amore (ptdamore)
Assigned to: Bogdan-Andrei Iancu (bogdan_iancu)
Summary: Change to listen= syntax to support per-interface advertised

Initial Comment:
[This is the patch for an idea I posted several weeks ago to the devel list.
Below is the original list posting as an explanation.]

The patch extends the idea of the advertised_address and advertised_port
parameters so that it is possible to bind such an address to each
listen= statement.

Syntax-wise, it works like this:

  listen=[proto:]host[:port][ AS host[:port]]

This new AS host[:port] syntax binds the advertised address specifically to the
corresponding socket_info structure.  If such an address is specified, it will
be used before the address specified as advertised_address, or set in the
set_advertised_address function for packets being sent on that particular
socket.  If it is not specified, then the old methods work as before.

The core has been modified so that address tuples using the advertised address
work interchangeably with the real address where you'd expect them to.
grep_sock_info and find_si have been updated to allow this.  Therefore, it is
not necessary to explicitly name your advertised address on an alias= line.
The following are now equivalent:

  force_send_socket(udp:adv_address:adv_port);
  force_send_socket(udp:real_address:real_port);

Note we don't specify protocol on the advertised address.  The way I see
things, it makes no sense to advertise a different protocol, so it inherits the
protocol of the socket.

Via construction is affected in the same way that the old global
advertised_address does, except the Via is written specifically for
the socket used
to send the message.

Lump substitution is also affected.  The following lump substitutions are aware
of this new facility:

 SUBST_RCV_IP
 SUBST_RCV_PORT
 SUBST_RCV_ALL
 SUBST_SND_IP
 SUBST_SND_PORT
 SUBST_SND_ALL

As a result of this, I was able to stop using record_route_preset in
my own config, and
just use standard record_route.  This winds up working much better,
because double-rr
works properly, and add_rr_param now works as expected for me, where it was a
problem using record_route_preset.

Additionally, registrar and usrloc had to be modified:

registrar - update the add_sock_hdr function to put the advertised address in
the message instead of the real address.  This allows registration information
to be replicated between multi-homed proxies, and the correct interface on the
peer can be used.

usrloc - update db_insert_ucontact to store the advertised address in the
database instead of the real address.  Same reasoning as the mods to registrar.

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

Comment By: Nergal (nergalex)
Date: 2009-05-26 11:44

Message:
Hello Phil,

After few tests, I identified the exact context when the problem appear. I
answer to your questions before.

1) b) An extra random character, this morning is '.' that appears in the
first
Record-Route header after host:port BUT always in a specific context, see
#3.

2) I have "listen=X.X.X.X:5060 AS X.X.X.Y:5060" in my configuration and
also:
listen=X.X.X.X:15060 AS X.X.X.Y:5060

3) [NEW] The problem appears when the SIP message match the
"X.X.X.X:15060" instance. The rewrite of RR is done by the line
"listen=X.X.X.X:15060 AS X.X.X.Y:5060". In this case, the extra caracter is
suffixed to the first RR port (public inbound interface).
The problem appears for UDP and TCP protocol.

NB: 2 instances (5060 and 15060) of my SIP proxy is load-balanced. So, the
random effect is made by:
- If "SIP message destination = 5060" So test OK
- If "SIP message destination = 15060" So test Not OK

Best regards
Alexis

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

Comment By: Phil D'Amore (ptdamore)
Date: 2009-05-25 22:18

Message:
Alexis :

I have a few questions for you:

1) To make sure I understand the problem, I want to re-word it a bit. 
Which of these statements is true about the problem
  a) An extra ';' (always a ';') character appears in the first
Record-Route header after host:port, at random times.
  b) An extra random character (not always ';') appears in the first
Record-Route header after host:port, at random times

2) Since you are using double-rr can I assume that you also have a
listen=X.X.X.X:5060 line in your configuration for your public inbound
interface, but it was not included in your message because it does not
specify the [AS host:port] portion?

If the answer to 2 is yes, can you try to specify an alias on that listen=
line like this:

listen=X.X.X.X:5060 AS X.X.X.X:5060

The effect should be that no re-write appears to happen as the left and
right side are the same, but the code used to get there would be slightly
different.  I'm curious to see if the extra ';' goes away in that case.

Thanks,
Phil

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

Comment By: Nergal (nergalex)
Date: 2009-05-25 10:20

Message:
Hello,

Sorry to post this comment so late, I was in vacancy.
History: https://sourceforge.net/forum/message.php?msg_id=7379817

Best regards 
Alexis 
-------------------
I have a bug on the patch "Change to listen= syntax to support
per-interface advertised - ID: 2706135". In the first Record-Route header,
a random caracter ends the <IP:Port> entry (see below 2 tests with the same
configuration and the extra caracter is ';'). 
Could you help me to fix it? 
I can do more test or give you more information if you need. 
 
Maybe a clue: the Advertised port is 4 digits long but the real port is 5
digits long. 
 
conf extract: 
- X.X.X.X is a public IP 
- listen=tcp:10.143.136.8:15060 AS 10.143.136.29:5060 
- force_send_socket(10.143.136.8:15060); 
- t_relay("tcp:10.143.81.130:5060") 
 
 
--- Test OK / proto TCP --- 
1. Before SIP proxy processing (Front interface capture) 
SUBSCRIBE sip:service at pilote-sip.my_domain:5060 SIP/2.0 
Via: SIP/2.0/TCP 10.95.10.1:10005;branch=z9hG4bK-1338-1-0 
From: userA at sfr.fr <sip:sipp at 10.95.10.1:10005>;tag=1338SIPpTag001 
To: userA at sfr.fr <sip:service at pilote-sip.my_domain:5060> 
Call-ID: 1-1338 at 10.95.10.1 
CSeq: 1 SUBSCRIBE 
Contact: sip:sipp at 10.95.10.1:10005 
Max-Forwards: 70 
Subject: Subscribe Test 
Content-Length: 0 
 
2. After SIP proxy processing (Back interface capture) 
SUBSCRIBE sip:service at pilote-sip.my_domain:5060 SIP/2.0 
Record-Route:
<sip:10.143.136.29:5060;transport=tcp;r2=on;lr=on;ftag=1338SIPpTag001> 
Record-Route:
<sip:X.X.X.X:5060;transport=tcp;r2=on;lr=on;ftag=1338SIPpTag001> 
Via: SIP/2.0/TCP 10.143.136.29:5060;branch=z9hG4bKa4b3.1d7725a.0;i=9e8f 
Via: SIP/2.0/TCP
10.95.10.1:10005;rport=32769;received=10.95.10.1;branch=z9hG4bK-1338-1-0 
From: userA at sfr.fr <sip:sipp at 10.95.10.1:10005>;tag=1338SIPpTag001 
To: userA at sfr.fr <sip:service at pilote-sip.my_domain:5060> 
Call-ID: 1-1338 at 10.95.10.1 
CSeq: 1 SUBSCRIBE 
Contact: sip:sipp at 10.95.10.1:10005 
Max-Forwards: 69 
Subject: Subscribe Test 
Content-Length: 0 
--- end Test OK --- 
 
--- Test NOK / proto TCP --- 
1. Before SIP proxy processing (Front interface capture) 
SUBSCRIBE sip:service at pilote-sip.my_domain:5060 SIP/2.0 
Via: SIP/2.0/TCP 10.95.10.1:10003;branch=z9hG4bK-1571-1-0 
From: userA at sfr.fr <sip:sipp at 10.95.10.1:10003>;tag=1571SIPpTag001 
To: userA at sfr.fr <sip:service at pilote-sip.my_domain:5060> 
Call-ID: 1-1571 at 10.95.10.1 
CSeq: 1 SUBSCRIBE 
Contact: sip:sipp at 10.95.10.1:10003 
Max-Forwards: 70 
Subject: Subscribe Test 
Content-Length: 0 
 
2. After SIP proxy processing (Back interface capture) 
SUBSCRIBE sip:service at pilote-sip.my_domain:5060 SIP/2.0 
Record-Route:
<sip:10.143.136.29:5060;transport=tcp;r2=on;lr=on;ftag=1571SIPpTag001> 
Record-Route:
<sip:X.X.X.X:5060;;transport=tcp;r2=on;lr=on;ftag=1571SIPpTag001> 
Via: SIP/2.0/TCP 10.143.136.29:5060;branch=z9hG4bK60ec.650af5e3.0;i=83401 
Via: SIP/2.0/TCP
10.95.10.1:10003;rport=32808;received=10.95.10.1;branch=z9hG4bK-1571-1-0 
From: userA at sfr.fr <sip:sipp at 10.95.10.1:10003>;tag=1571SIPpTag001 
To: userA at sfr.fr <sip:service at pilote-sip.my_domain:5060> 
Call-ID: 1-1571 at 10.95.10.1 
CSeq: 1 SUBSCRIBE 
Contact: sip:sipp at 10.95.10.1:10003 
Max-Forwards: 69 
Subject: Subscribe Test 
Content-Length: 0 
--- end Test NOK --- 
 
Best regards 
Alexis 

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

Comment By: Bogdan-Andrei Iancu (bogdan_iancu)
Date: 2009-05-09 10:15

Message:
Hi Phil,

I will start reviewing the patch in order to upload it on SVN. If I have
some questions about it, I will post them here.

Thanks and regards,
Bogdan

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

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


From ibc at aliax.net  Tue May 26 11:55:57 2009
From: ibc at aliax.net (=?UTF-8?Q?I=C3=B1aki_Baz_Castillo?=)
Date: Tue, 26 May 2009 11:55:57 +0200
Subject: [OpenSIPS-Devel] [presence] 'expires_offset' also for NOTIFY
	('notify_expires_offset')
Message-ID: <cc1f582e0905260255sdf28edarfc838397d5678dd0@mail.gmail.com>

Hi, I've detected an issue related to NOTIFY "expires" value when
there are retransmissions for the NOTIFY sent by OpenSIPS:

Imagine that a OpenSIPS sends a NOTIFY "expires=30" to a client at 12:00:00.
Due to some reasons, the client doesn't reply to it (or perhaps there
are network errors) so the NOTIFY is retransmitted by OpenSIPS.
Finally the NOTIFY arrives to the client at 12:00:01.

If the client is too strict, it will send a refresh SUBSCRIBE at
12:00:31, so the subscription has expired in the server one second
ago.
This will cause a "481".

Unfortunatelly some clients (as Qutecom) work in this way, and the
worst: they don't react well when receiving a 481.

So I suggest a new option "notify_expires_offset":

  modparam("presence", "notify_expires_offset", 5)

In the above case (with retransmissions) it means that the client
would receive a NOTIFY with "expires=25" at 12:00:01, and the client
will send the refresh SUSBCRIBE at 12:00:26 (before 12:00:30, the time
in which the subscription would expire in the server), so it would
mitigate the 481 issue.

Is it feasible to add this option? opinions?

Thanks a lot.

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


From noreply at sourceforge.net  Tue May 26 11:58:36 2009
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue, 26 May 2009 09:58:36 +0000
Subject: [OpenSIPS-Devel] [ opensips-Bugs-2791186 ] [presence] crazy NOTIFY's
Message-ID: <E1M8tQa-0008PA-Da@cdv4jf1.ch3.sourceforge.com>

Bugs item #2791186, was opened at 2009-05-13 16:36
Message generated for change (Comment added) made by anca_vamanu
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=2791186&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: I?aki Baz Castillo (ibc_sf)
Assigned to: Anca Vamanu (anca_vamanu)
Summary: [presence] crazy NOTIFY's

Initial Comment:
Rev 5706.

modparam("presence", "max_expires_publish", 30)
modparam("presence", "max_expires_subscribe", 40)
modparam("presence", "expires_offset", 5)
modparam("presence", "fallback2db", 1)


Just one client subscribed to itself (30004). All works well at the beginning, but after some time OpenSIPS starts sending *a lot* of NOTIFY's (no retransmissions) in the same seconds (for the same subscription dialog and with the same info).
This causes the client (Qutecom) replying "500 Retry Later".

I attach a very long capture, but go to line 3265 to see the issue.


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

>Comment By: Anca Vamanu (anca_vamanu)
Date: 2009-05-26 12:58

Message:
Hi Inaki,

I found in the log the reason why so many Notifies are sent one after the
other. And it is indeed due to a bug in the phone.

What happens is that the phone sends Publish messages without Sip-If-Match
headers - so each creats a new record. The presence module has a function
that looks for expired records in database and its default running interval
is 100 seconds.
What happend in the log is that when this function run it found 5 expired
publish records in database. The implementation is that the module sends
Notifies with status closed to all the watchers for each expired publosh
record. An enhancement could indeed be done here - to check and send
Notifies only for disting presenties. Anyhow with a proper implementation
in the phone there shouldn't be so many  expired records.

regards,
Anca
 

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

Comment By: Anca Vamanu (anca_vamanu)
Date: 2009-05-25 15:55

Message:
Hi Inaki,

I can not figure out from the code why such thing will happen. The
multiple Publish should not have anything to do with this. 
Can you please raise the debug level and attach the log file section
starting with the processing of the Subscribe that triggers a series of
Notifies?

regards,
Anca

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

Comment By: I?aki Baz Castillo (ibc_sf)
Date: 2009-05-25 13:35

Message:
Note that Qutecom has an error in the PUBLISH implementation since it
generates a *new* PUBLISH each time instead of using the SIP-If-Match
header:
  http://trac.qutecom.org/ticket/93

However I'm not sure that this should be the cause (but it could since
Qutecom always sets the same tuple id in the PUBLISH body).

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

Comment By: I?aki Baz Castillo (ibc_sf)
Date: 2009-05-24 01:49

Message:
I've attached a new file (sequential_crazy_NOTIFY's.txt). It's a SIP
capture of OpenSIPS sending 6 NOTIFY's in less than a second. All of these
NOTIFY's are part of the same subscription dialog, and are sequential
requests (from CSeq: 8 to CSeq:13).
Twinkle replies 200 for each NOTIFY, but other clients, as Qutecom, reply
"500 Retry Later" and the subscription gets lost.

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

Comment By: Anca Vamanu (anca_vamanu)
Date: 2009-05-13 18:21

Message:
It must be faith that the line in your file(3265) is exactly the number for
the RFC about sip event notifications (http://www.ietf.org/rfc/rfc3265.txt)
:) . 

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

Comment By: I?aki Baz Castillo (ibc_sf)
Date: 2009-05-13 17:21

Message:
Take into account that I have a proxy between clients and presence server
(and I forgot to filter one of them with ngrep).

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

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

Message:
Yes, it is very strange - and it seems like the presence module generates a
couple of Notifies one after the other. I will look into this.

Anca

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

Comment By: I?aki Baz Castillo (ibc_sf)
Date: 2009-05-13 17:09

Message:
I can reproduce this error with Qutecom trunk (which has a not very good
presence implementation). I cna't reproduce it with Twinkle which works
perfectly now.

But anyway, it's very strange so many NOTIFY's for the same dialog, isn't?

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

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


From anca at opensips.org  Tue May 26 12:12:36 2009
From: anca at opensips.org (Anca Vamanu)
Date: Tue, 26 May 2009 13:12:36 +0300
Subject: [OpenSIPS-Devel] [presence] 'expires_offset' also for NOTIFY
 ('notify_expires_offset')
In-Reply-To: <cc1f582e0905260255sdf28edarfc838397d5678dd0@mail.gmail.com>
References: <cc1f582e0905260255sdf28edarfc838397d5678dd0@mail.gmail.com>
Message-ID: <4A1BC094.3010204@opensips.org>

Hi,

The expires_offset is somehow supposed to do that - but it lost the 
initial meaning in the mean time :) .
I will fix that.

Thanks,
Anca


I?aki Baz Castillo wrote:
> Hi, I've detected an issue related to NOTIFY "expires" value when
> there are retransmissions for the NOTIFY sent by OpenSIPS:
>
> Imagine that a OpenSIPS sends a NOTIFY "expires=30" to a client at 12:00:00.
> Due to some reasons, the client doesn't reply to it (or perhaps there
> are network errors) so the NOTIFY is retransmitted by OpenSIPS.
> Finally the NOTIFY arrives to the client at 12:00:01.
>
> If the client is too strict, it will send a refresh SUBSCRIBE at
> 12:00:31, so the subscription has expired in the server one second
> ago.
> This will cause a "481".
>
> Unfortunatelly some clients (as Qutecom) work in this way, and the
> worst: they don't react well when receiving a 481.
>
> So I suggest a new option "notify_expires_offset":
>
>   modparam("presence", "notify_expires_offset", 5)
>
> In the above case (with retransmissions) it means that the client
> would receive a NOTIFY with "expires=25" at 12:00:01, and the client
> will send the refresh SUSBCRIBE at 12:00:26 (before 12:00:30, the time
> in which the subscription would expire in the server), so it would
> mitigate the 481 issue.
>
> Is it feasible to add this option? opinions?
>
> Thanks a lot.
>
>   



From ibc at aliax.net  Tue May 26 12:31:07 2009
From: ibc at aliax.net (=?UTF-8?Q?I=C3=B1aki_Baz_Castillo?=)
Date: Tue, 26 May 2009 12:31:07 +0200
Subject: [OpenSIPS-Devel] [presence] 'expires_offset' also for NOTIFY
	('notify_expires_offset')
In-Reply-To: <4A1BC094.3010204@opensips.org>
References: <cc1f582e0905260255sdf28edarfc838397d5678dd0@mail.gmail.com>
	<4A1BC094.3010204@opensips.org>
Message-ID: <cc1f582e0905260331h5a6f7923n497bac514ce4415c@mail.gmail.com>

2009/5/26 Anca Vamanu <anca at opensips.org>:
> Hi,
>
> The expires_offset is somehow supposed to do that - but it lost the initial
> meaning in the mean time :) .
> I will fix that.


Hi Anca, the docs say that it only affects the "200 OK" "expires"
value for an incoming PUBLISH:

1.3.7. expires_offset (int)
 The value that should be subtracted from the expires value when
sending a 200OK
 for a publish. It is used for forcing the client cu send an update
before the old publish
 expires.


Thanks a lot.


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


From anca at opensips.org  Tue May 26 12:32:31 2009
From: anca at opensips.org (Anca Vamanu)
Date: Tue, 26 May 2009 10:32:31 +0000
Subject: [OpenSIPS-Devel] SF.net SVN: opensips:[5738] trunk/modules/presence
Message-ID: <E1M8txP-0006LR-Pq@c3vjzd1.ch3.sourceforge.com>

Revision: 5738
          http://opensips.svn.sourceforge.net/opensips/?rev=5738&view=rev
Author:   anca_vamanu
Date:     2009-05-26 10:32:28 +0000 (Tue, 26 May 2009)

Log Message:
-----------
- made the usage of expires_offset module parameter consistent - intended to force the clients to renew the subscription/publication by informing them of a smaller expires value that the real one (reported by Inaki Baz Castillo <ibc at aliax.net>)

Modified Paths:
--------------
    trunk/modules/presence/README
    trunk/modules/presence/doc/presence_admin.xml
    trunk/modules/presence/notify.c
    trunk/modules/presence/presentity.c
    trunk/modules/presence/subscribe.c


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


From anca at opensips.org  Tue May 26 12:34:26 2009
From: anca at opensips.org (Anca Vamanu)
Date: Tue, 26 May 2009 13:34:26 +0300
Subject: [OpenSIPS-Devel] [presence] 'expires_offset' also for NOTIFY
 ('notify_expires_offset')
In-Reply-To: <cc1f582e0905260331h5a6f7923n497bac514ce4415c@mail.gmail.com>
References: <cc1f582e0905260255sdf28edarfc838397d5678dd0@mail.gmail.com>	<4A1BC094.3010204@opensips.org>
	<cc1f582e0905260331h5a6f7923n497bac514ce4415c@mail.gmail.com>
Message-ID: <4A1BC5B2.9010102@opensips.org>


Yes, it was only for publish.
I extended it for subscribes and also changed the docs.

thanks,
Anca

I?aki Baz Castillo wrote:
> 2009/5/26 Anca Vamanu <anca at opensips.org>:
>   
>> Hi,
>>
>> The expires_offset is somehow supposed to do that - but it lost the initial
>> meaning in the mean time :) .
>> I will fix that.
>>     
>
>
> Hi Anca, the docs say that it only affects the "200 OK" "expires"
> value for an incoming PUBLISH:
>
> 1.3.7. expires_offset (int)
>  The value that should be subtracted from the expires value when
> sending a 200OK
>  for a publish. It is used for forcing the client cu send an update
> before the old publish
>  expires.
>
>
> Thanks a lot.
>
>
>   



From ibc at aliax.net  Tue May 26 12:37:30 2009
From: ibc at aliax.net (=?UTF-8?Q?I=C3=B1aki_Baz_Castillo?=)
Date: Tue, 26 May 2009 12:37:30 +0200
Subject: [OpenSIPS-Devel] [presence] 'expires_offset' also for NOTIFY
	('notify_expires_offset')
In-Reply-To: <4A1BC5B2.9010102@opensips.org>
References: <cc1f582e0905260255sdf28edarfc838397d5678dd0@mail.gmail.com>
	<4A1BC094.3010204@opensips.org>
	<cc1f582e0905260331h5a6f7923n497bac514ce4415c@mail.gmail.com>
	<4A1BC5B2.9010102@opensips.org>
Message-ID: <cc1f582e0905260337j37f3fc61jc41c5d095d846948@mail.gmail.com>

2009/5/26 Anca Vamanu <anca at opensips.org>:
>
> Yes, it was only for publish.
> I extended it for subscribes and also changed the docs.

But, will it also affect on the NOTIFY's "expires" value sent by
OpenSIPS upon receipt of a new PUBLISH?


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


From ibc at aliax.net  Tue May 26 12:39:18 2009
From: ibc at aliax.net (=?UTF-8?Q?I=C3=B1aki_Baz_Castillo?=)
Date: Tue, 26 May 2009 12:39:18 +0200
Subject: [OpenSIPS-Devel] SF.net SVN: opensips:[5738]
	trunk/modules/presence
In-Reply-To: <E1M8txP-0006LR-Pq@c3vjzd1.ch3.sourceforge.com>
References: <E1M8txP-0006LR-Pq@c3vjzd1.ch3.sourceforge.com>
Message-ID: <cc1f582e0905260339v3cd61d95v79c2b58a69ffaffb@mail.gmail.com>

2009/5/26 Anca Vamanu <anca at opensips.org>:
> Revision: 5738
> ? ? ? ? ?http://opensips.svn.sourceforge.net/opensips/?rev=5738&view=rev
> Author: ? anca_vamanu
> Date: ? ? 2009-05-26 10:32:28 +0000 (Tue, 26 May 2009)
>
> Log Message:
> -----------
> - made the usage of expires_offset module parameter consistent - intended to force the clients to renew the subscription/publication by informing them of a smaller expires value that the real one (reported by Inaki Baz Castillo <ibc at aliax.net>)

Increible! I've reported this wish just 5 minutes ago!
XD

Thanks a lot.


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


From anca at opensips.org  Tue May 26 12:41:42 2009
From: anca at opensips.org (Anca Vamanu)
Date: Tue, 26 May 2009 13:41:42 +0300
Subject: [OpenSIPS-Devel] [presence] 'expires_offset' also for NOTIFY
 ('notify_expires_offset')
In-Reply-To: <cc1f582e0905260337j37f3fc61jc41c5d095d846948@mail.gmail.com>
References: <cc1f582e0905260255sdf28edarfc838397d5678dd0@mail.gmail.com>	<4A1BC094.3010204@opensips.org>	<cc1f582e0905260331h5a6f7923n497bac514ce4415c@mail.gmail.com>	<4A1BC5B2.9010102@opensips.org>
	<cc1f582e0905260337j37f3fc61jc41c5d095d846948@mail.gmail.com>
Message-ID: <4A1BC766.8040501@opensips.org>

I?aki Baz Castillo wrote:
> 2009/5/26 Anca Vamanu <anca at opensips.org>:
>   
>> Yes, it was only for publish.
>> I extended it for subscribes and also changed the docs.
>>     
>
> But, will it also affect on the NOTIFY's "expires" value sent by
> OpenSIPS upon receipt of a new PUBLISH?
>
>
>   
No. It will affect all the Notifies. Each time a Notify is generated (no 
matter the cause) the expires value inserted in the message will be 
decreased with expires_offset.



From ibc at aliax.net  Tue May 26 12:43:46 2009
From: ibc at aliax.net (=?UTF-8?Q?I=C3=B1aki_Baz_Castillo?=)
Date: Tue, 26 May 2009 12:43:46 +0200
Subject: [OpenSIPS-Devel] [presence] 'expires_offset' also for NOTIFY
	('notify_expires_offset')
In-Reply-To: <4A1BC766.8040501@opensips.org>
References: <cc1f582e0905260255sdf28edarfc838397d5678dd0@mail.gmail.com>
	<4A1BC094.3010204@opensips.org>
	<cc1f582e0905260331h5a6f7923n497bac514ce4415c@mail.gmail.com>
	<4A1BC5B2.9010102@opensips.org>
	<cc1f582e0905260337j37f3fc61jc41c5d095d846948@mail.gmail.com>
	<4A1BC766.8040501@opensips.org>
Message-ID: <cc1f582e0905260343o30bc794ewd57f01bcd3df3555@mail.gmail.com>

2009/5/26 Anca Vamanu <anca at opensips.org>:
> I?aki Baz Castillo wrote:
>>
>> 2009/5/26 Anca Vamanu <anca at opensips.org>:
>>
>>>
>>> Yes, it was only for publish.
>>> I extended it for subscribes and also changed the docs.
>>>
>>
>> But, will it also affect on the NOTIFY's "expires" value sent by
>> OpenSIPS upon receipt of a new PUBLISH?
>>
>>
>>
>
> No. It will affect all the Notifies. Each time a Notify is generated (no
> matter the cause) the expires value inserted in the message will be
> decreased with expires_offset.

Great :)
Thanks a lot for the fastest implementation of a wish !


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


From anca at opensips.org  Tue May 26 12:45:06 2009
From: anca at opensips.org (Anca Vamanu)
Date: Tue, 26 May 2009 13:45:06 +0300
Subject: [OpenSIPS-Devel] [presence] 'expires_offset' also for NOTIFY
 ('notify_expires_offset')
In-Reply-To: <cc1f582e0905260343o30bc794ewd57f01bcd3df3555@mail.gmail.com>
References: <cc1f582e0905260255sdf28edarfc838397d5678dd0@mail.gmail.com>	<4A1BC094.3010204@opensips.org>	<cc1f582e0905260331h5a6f7923n497bac514ce4415c@mail.gmail.com>	<4A1BC5B2.9010102@opensips.org>	<cc1f582e0905260337j37f3fc61jc41c5d095d846948@mail.gmail.com>	<4A1BC766.8040501@opensips.org>
	<cc1f582e0905260343o30bc794ewd57f01bcd3df3555@mail.gmail.com>
Message-ID: <4A1BC832.305@opensips.org>

I?aki Baz Castillo wrote:
> 2009/5/26 Anca Vamanu <anca at opensips.org>:
>   
>> I?aki Baz Castillo wrote:
>>     
>>> 2009/5/26 Anca Vamanu <anca at opensips.org>:
>>>
>>>       
>>>> Yes, it was only for publish.
>>>> I extended it for subscribes and also changed the docs.
>>>>
>>>>         
>>> But, will it also affect on the NOTIFY's "expires" value sent by
>>> OpenSIPS upon receipt of a new PUBLISH?
>>>
>>>
>>>
>>>       
>> No. It will affect all the Notifies. Each time a Notify is generated (no
>> matter the cause) the expires value inserted in the message will be
>> decreased with expires_offset.
>>     
>
> Great :)
> Thanks a lot for the fastest implementation of a wish !
>
>
>   
;) It was a simple one.


From noreply at sourceforge.net  Tue May 26 14:20:46 2009
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue, 26 May 2009 12:20:46 +0000
Subject: [OpenSIPS-Devel] [ opensips-Bugs-2795917 ] [PATCH] lcr module
	crashes if ruri_user is void
Message-ID: <E1M8veA-00018v-UX@155xhf1.ch3.sourceforge.com>

Bugs item #2795917, was opened at 2009-05-23 22: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=2795917&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.4.x
Status: Open
>Resolution: Accepted
Priority: 5
Private: No
Submitted By: Nobody/Anonymous (nobody)
>Assigned to: Bogdan-Andrei Iancu (bogdan_iancu)
Summary: [PATCH] lcr module crashes if ruri_user is void

Initial Comment:
lcd module running in prefix_mode=1 is bound to crash in an incoming INVITE's Request-URI doesn't contain username part:

May 23 19:10:56 SIPS4 /usr/local/sbin/opensips[8754]: ----- Processing INVITE RURI=sip:11.11.11.11 F=sip:2123752645 at 22.22.22.22 T=sip:11.11.11.11 IP=22.22.22.22 ID=5781c4b2739bcab21003ab7162826e30 at 22.22.22.22
May 23 19:10:56 SIPS4 kernel: opensips[8754]: segfault at 0000000000000000 rip 00002aaaab15f080 rsp 00007fff1d3b27c8 error 4
May 23 19:10:57 SIPS4 /usr/local/sbin/opensips[8752]: INFO:core:handle_sigs: child process 8754 exited by a signal 11

(gdb) bt
#0  0x00002aaaab15f080 in strlen () from /lib/libc.so.6
#1  0x00002aaaab1a0d08 in regexec () from /lib/libc.so.6
#2  0x00002aaaada31fec in do_load_gws (_m=0x7bde18, _from_uri=0x0, _grp_id=-1) at lcr_mod.c:1271
#3  0x00002aaaada3387d in load_gws_0 (_m=0x7bde18, _s1=0x0, _s2=0x0) at lcr_mod.c:1512
#4  0x000000000041106b in do_action (a=0x771580, msg=0x7bde18) at action.c:845
#5  0x000000000040e13a in run_action_list (a=0x771580, msg=0x7bde18) at action.c:138
#6  0x0000000000452da3 in eval_elem (e=0x771650, msg=0x7bde18, val=0x0) at route.c:1133
#7  0x0000000000456e9d in eval_expr (e=0x771650, msg=0x7bde18, val=0x0) at route.c:1430
#8  0x0000000000456f81 in eval_expr (e=0x771698, msg=0x7bde18, val=0x0) at route.c:1446
#9  0x0000000000456fb5 in eval_expr (e=0x7716e0, msg=0x7bde18, val=0x0) at route.c:1451
#10 0x00000000004107cb in do_action (a=0x771a78, msg=0x7bde18) at action.c:700
#11 0x000000000040e13a in run_action_list (a=0x771a78, msg=0x7bde18) at action.c:138
#12 0x000000000040e415 in run_actions (a=0x771a78, msg=0x7bde18) at action.c:118
#13 0x000000000040fa19 in do_action (a=0x76e9d0, msg=0x7bde18) at action.c:483
#14 0x000000000040e13a in run_action_list (a=0x76e4e0, msg=0x7bde18) at action.c:138
#15 0x000000000041090a in do_action (a=0x76efa0, msg=0x7bde18) at action.c:717
#16 0x000000000040e13a in run_action_list (a=0x76efa0, msg=0x7bde18) at action.c:138
#17 0x000000000041090a in do_action (a=0x76f140, msg=0x7bde18) at action.c:717
#18 0x000000000040e13a in run_action_list (a=0x769008, msg=0x7bde18) at action.c:138
#19 0x000000000040e415 in run_actions (a=0x769008, msg=0x7bde18) at action.c:118
#20 0x000000000040e4de in run_top_route (a=0x769008, msg=0x7bde18) at action.c:179
#21 0x000000000044aae3 in receive_msg (
    buf=0x73cbe0 "INVITE sip:11.11.11.11 SIP/2.0\r\nVia: SIP/2.0/UDP 22.22.22.22:5060;branch=z9hG4bK0f49cc08;rport\r\nFrom: \"Unavailable\" <sip:2123752645 at 22.22.22.22>;tag=as5ae62e90\r\nTo: <sip:11.11.11.11>\r\nCont"..., len=869, rcv_info=0x7fff1d3c0430) at receive.c:165
#22 0x00000000004836fa in udp_rcv_loop () at udp_server.c:449
#23 0x0000000000423968 in main_loop () at main.c:780
#24 0x0000000000425d5d in main (argc=9, argv=0x7fff1d3c0688) at main.c:1319

Reproduced on 1.4.4 but all versions are affected. I suggest the following patch:

Index: lcr_mod.c
===================================================================
--- lcr_mod.c   (revision 5245)
+++ lcr_mod.c   (working copy)
@@ -1194,7 +1194,7 @@
     struct lcr_info lcr_rec;

     /* Find Request-URI user */
-    if (parse_sip_msg_uri(_m) < 0) {
+    if ((parse_sip_msg_uri(_m) < 0) || (!_m->parsed_uri.user.s)) {
            LM_ERR("Error while parsing R-URI\n");
            return -1;
     }


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

Comment By: Nobody/Anonymous (nobody)
Date: 2009-05-23 22:49

Message:
Feel free to ask me should you want to test something since I have
everything set up.
Andrew <andrew.pogrebennyk at portaone.com>

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

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


From bogdan at voice-system.ro  Tue May 26 18:05:11 2009
From: bogdan at voice-system.ro (Bogdan-Andrei Iancu)
Date: Tue, 26 May 2009 16:05:11 +0000
Subject: [OpenSIPS-Devel] SF.net SVN: opensips:[5739]
	trunk/modules/lcr/lcr_mod.c
Message-ID: <E1M8z9L-0002QQ-FN@dn4whf1.ch3.sourceforge.com>

Revision: 5739
          http://opensips.svn.sourceforge.net/opensips/?rev=5739&view=rev
Author:   bogdan_iancu
Date:     2009-05-26 16:05:11 +0000 (Tue, 26 May 2009)

Log Message:
-----------
- fixed bug in processing SIP URIs without username.
  Credits go to Andrew < andrew dot pogrebennyk at portaone dot com >
  Closes bug ID #2795917.

Modified Paths:
--------------
    trunk/modules/lcr/lcr_mod.c


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


From bogdan at voice-system.ro  Tue May 26 18:05:44 2009
From: bogdan at voice-system.ro (Bogdan-Andrei Iancu)
Date: Tue, 26 May 2009 16:05:44 +0000
Subject: [OpenSIPS-Devel] SF.net SVN: opensips:[5740]
	branches/1.5/modules/lcr/lcr_mod.c
Message-ID: <E1M8z9s-0002Qv-3D@dn4whf1.ch3.sourceforge.com>

Revision: 5740
          http://opensips.svn.sourceforge.net/opensips/?rev=5740&view=rev
Author:   bogdan_iancu
Date:     2009-05-26 16:05:43 +0000 (Tue, 26 May 2009)

Log Message:
-----------
backport from trunk (rev #5739):
- fixed bug in processing SIP URIs without username.
  Credits go to Andrew < andrew dot pogrebennyk at portaone dot com >
  Closes bug ID #2795917.

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

Modified Paths:
--------------
    branches/1.5/modules/lcr/lcr_mod.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 May 26 18:06:27 2009
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue, 26 May 2009 16:06:27 +0000
Subject: [OpenSIPS-Devel] [ opensips-Bugs-2795917 ] [PATCH] lcr module
	crashes if ruri_user is void
Message-ID: <E1M8zAZ-0006dg-DF@g45xhf1.ch3.sourceforge.com>

Bugs item #2795917, was opened at 2009-05-23 22:47
Message generated for change (Comment added) made by bogdan_iancu
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=2795917&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.4.x
>Status: Closed
>Resolution: Fixed
Priority: 5
Private: No
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Bogdan-Andrei Iancu (bogdan_iancu)
Summary: [PATCH] lcr module crashes if ruri_user is void

Initial Comment:
lcd module running in prefix_mode=1 is bound to crash in an incoming INVITE's Request-URI doesn't contain username part:

May 23 19:10:56 SIPS4 /usr/local/sbin/opensips[8754]: ----- Processing INVITE RURI=sip:11.11.11.11 F=sip:2123752645 at 22.22.22.22 T=sip:11.11.11.11 IP=22.22.22.22 ID=5781c4b2739bcab21003ab7162826e30 at 22.22.22.22
May 23 19:10:56 SIPS4 kernel: opensips[8754]: segfault at 0000000000000000 rip 00002aaaab15f080 rsp 00007fff1d3b27c8 error 4
May 23 19:10:57 SIPS4 /usr/local/sbin/opensips[8752]: INFO:core:handle_sigs: child process 8754 exited by a signal 11

(gdb) bt
#0  0x00002aaaab15f080 in strlen () from /lib/libc.so.6
#1  0x00002aaaab1a0d08 in regexec () from /lib/libc.so.6
#2  0x00002aaaada31fec in do_load_gws (_m=0x7bde18, _from_uri=0x0, _grp_id=-1) at lcr_mod.c:1271
#3  0x00002aaaada3387d in load_gws_0 (_m=0x7bde18, _s1=0x0, _s2=0x0) at lcr_mod.c:1512
#4  0x000000000041106b in do_action (a=0x771580, msg=0x7bde18) at action.c:845
#5  0x000000000040e13a in run_action_list (a=0x771580, msg=0x7bde18) at action.c:138
#6  0x0000000000452da3 in eval_elem (e=0x771650, msg=0x7bde18, val=0x0) at route.c:1133
#7  0x0000000000456e9d in eval_expr (e=0x771650, msg=0x7bde18, val=0x0) at route.c:1430
#8  0x0000000000456f81 in eval_expr (e=0x771698, msg=0x7bde18, val=0x0) at route.c:1446
#9  0x0000000000456fb5 in eval_expr (e=0x7716e0, msg=0x7bde18, val=0x0) at route.c:1451
#10 0x00000000004107cb in do_action (a=0x771a78, msg=0x7bde18) at action.c:700
#11 0x000000000040e13a in run_action_list (a=0x771a78, msg=0x7bde18) at action.c:138
#12 0x000000000040e415 in run_actions (a=0x771a78, msg=0x7bde18) at action.c:118
#13 0x000000000040fa19 in do_action (a=0x76e9d0, msg=0x7bde18) at action.c:483
#14 0x000000000040e13a in run_action_list (a=0x76e4e0, msg=0x7bde18) at action.c:138
#15 0x000000000041090a in do_action (a=0x76efa0, msg=0x7bde18) at action.c:717
#16 0x000000000040e13a in run_action_list (a=0x76efa0, msg=0x7bde18) at action.c:138
#17 0x000000000041090a in do_action (a=0x76f140, msg=0x7bde18) at action.c:717
#18 0x000000000040e13a in run_action_list (a=0x769008, msg=0x7bde18) at action.c:138
#19 0x000000000040e415 in run_actions (a=0x769008, msg=0x7bde18) at action.c:118
#20 0x000000000040e4de in run_top_route (a=0x769008, msg=0x7bde18) at action.c:179
#21 0x000000000044aae3 in receive_msg (
    buf=0x73cbe0 "INVITE sip:11.11.11.11 SIP/2.0\r\nVia: SIP/2.0/UDP 22.22.22.22:5060;branch=z9hG4bK0f49cc08;rport\r\nFrom: \"Unavailable\" <sip:2123752645 at 22.22.22.22>;tag=as5ae62e90\r\nTo: <sip:11.11.11.11>\r\nCont"..., len=869, rcv_info=0x7fff1d3c0430) at receive.c:165
#22 0x00000000004836fa in udp_rcv_loop () at udp_server.c:449
#23 0x0000000000423968 in main_loop () at main.c:780
#24 0x0000000000425d5d in main (argc=9, argv=0x7fff1d3c0688) at main.c:1319

Reproduced on 1.4.4 but all versions are affected. I suggest the following patch:

Index: lcr_mod.c
===================================================================
--- lcr_mod.c   (revision 5245)
+++ lcr_mod.c   (working copy)
@@ -1194,7 +1194,7 @@
     struct lcr_info lcr_rec;

     /* Find Request-URI user */
-    if (parse_sip_msg_uri(_m) < 0) {
+    if ((parse_sip_msg_uri(_m) < 0) || (!_m->parsed_uri.user.s)) {
            LM_ERR("Error while parsing R-URI\n");
            return -1;
     }


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

>Comment By: Bogdan-Andrei Iancu (bogdan_iancu)
Date: 2009-05-26 19:06

Message:
Hi Andrew,

Thanks for the patch - I uploaded it on SVN trunk and 1.5 branch.

Regards,
Bogdan

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

Comment By: Nobody/Anonymous (nobody)
Date: 2009-05-23 22:49

Message:
Feel free to ask me should you want to test something since I have
everything set up.
Andrew <andrew.pogrebennyk at portaone.com>

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

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


From bogdan at voice-system.ro  Tue May 26 18:40:31 2009
From: bogdan at voice-system.ro (Bogdan-Andrei Iancu)
Date: Tue, 26 May 2009 16:40:31 +0000
Subject: [OpenSIPS-Devel] SF.net SVN: opensips:[5741] trunk/modules
Message-ID: <E1M8zhX-00065U-QL@74yxhf1.ch3.sourceforge.com>

Revision: 5741
          http://opensips.svn.sourceforge.net/opensips/?rev=5741&view=rev
Author:   bogdan_iancu
Date:     2009-05-26 16:40:31 +0000 (Tue, 26 May 2009)

Log Message:
-----------
- extends the tm uac functions to support the tmcb release function for tm callback parameter cleanup. This is based on work done earlier which added the infrastructure necessary to do proper cleanup and here we are extending the existing uac functions to use that earlier work done in...

Credits go to John Riordan .
Closes Patch id #2789126.

Modified Paths:
--------------
    trunk/modules/dialog/dlg_req_within.c
    trunk/modules/dispatcher/dispatch.c
    trunk/modules/imc/imc_cmd.c
    trunk/modules/jabber/xjab_worker.c
    trunk/modules/msilo/msilo.c
    trunk/modules/presence/notify.c
    trunk/modules/pua/pua.c
    trunk/modules/pua/send_publish.c
    trunk/modules/pua/send_subscribe.c
    trunk/modules/rls/notify.c
    trunk/modules/seas/seas_action.c
    trunk/modules/sms/sms_funcs.c
    trunk/modules/tm/mi.c
    trunk/modules/tm/uac.c
    trunk/modules/tm/uac.h
    trunk/modules/xmpp/xmpp.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 May 26 18:41:02 2009
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue, 26 May 2009 16:41:02 +0000
Subject: [OpenSIPS-Devel] [ opensips-Patches-2789126 ] extend tm uac
	functions to support tmcb release function
Message-ID: <E1M8zi2-00088D-SQ@h45xhf1.ch3.sourceforge.com>

Patches item #2789126, was opened at 2009-05-08 20:17
Message generated for change (Settings changed) made by bogdan_iancu
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086412&aid=2789126&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: John Riordan (john_riordan)
Assigned to: Bogdan-Andrei Iancu (bogdan_iancu)
Summary: extend tm uac functions to support tmcb release function

Initial Comment:
Currently there does not appear to be a reliable way to cleanup callback parameters passed to the tm uac functions - t_request, t_request_within, etc.. This patch extends the tm uac functions to support the tmcb release function for tm callback parameter cleanup. This is based on work done earlier which added the infrastructure necessary to do proper cleanup and here we are extending the existing uac functions to use that earlier work done in...
                                                                                                                                                                                                                                                                              
    Author: dan_pascu <dan_pascu at 689a6050-402a-0410-94f2-e92a70836424>                                                                 
    Date:   Thu Nov 20 18:55:23 2008 +0000                                                                                             
                                                                                                                                       
        Added infrastructure for tm callback parameter cleanup. Fixed memory corruption caused by invalid freeing of dialogs           
                                                                                                                                       
        git-svn-id: https://opensips.svn.sourceforge.net/svnroot/opensips/trunk at 4992 689a6050-402a-0410-94f2-e92a70836424              

Currently, callback parameters cannot be reliably cleaned up. For example, when using t_request to send an INVITE and the uas responds with a 200 but then the ACK(s) gets lost and the uas continues sending 200s the callback is called repeatedly with an indication that the request was completed so one is faced with either not freeing the callback parameters (leaking memory) or freeing them repeatedly (ah, umm).

Regardless, proper cleanup can best be done by utilizing the release function infrastructure.


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

>Comment By: Bogdan-Andrei Iancu (bogdan_iancu)
Date: 2009-05-26 19:41

Message:
Hi John,

The patch is on SVN trunk (version 1.6). Thanks for your coding and
explanation work  ;)

Best regards,
Bogdan

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

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

Message:
Hi John,

trying to follow the numbering you did for my comments :)

1) you do not need lock as some of the callback are already synced by TM -
so you cannot have 2 callbacks executed in the same time....but this is not
true for all callbacks, so I agree this is a reason.

2) true - exactly what I mentioned in 1)

3) I agree with your arguments 

4) good example, indeed

5) right, the TMCB_TRANS_DELETED callback is the best place to cleanup
stuff, but I think you want cleanup per callback and not callback per
transaction. This is a new callback I added 2 years ago for the dialog
module (this module is also using the callback for getting events for the
dialog state machine). But your final point is good - you cannot use this
callback with local transactions as you cannot install it :(

6) make sense to me - what can I say...you convince me, so I will start
overviewing  the patch for integrating on SVN.

7 - dlg_dridge() ) not sure what this function does, but I guess somebody
without a good understanding of how the dialog and TM modules work just
pushed it there..

Thanks and best regards,
Bogdan

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

Comment By: John Riordan (john_riordan)
Date: 2009-05-10 07:02

Message:
Bogdan,

Here is another example in evidence how getting this right is hard for
people. While I haven't tested it, a call to dlg_bridge() in the linked
code looks like it will cause a double free the first time an ack is lost
and the uas sends another 200 (and then triple free and so on as the 200s
come in). I suspect the author of this function would not have fallen into
this trap if t_request() presented an interface that took a release
function callback.

http://git.sip-router.org/cgi-bin/gitweb.cgi?p=kamailio;a=blob;f=modules/dialog/dlg_transfer.c;h=d208863ce83a0ca6d1004302368374d2b52b28b3;hb=HEAD

(If the link doesn't post through, the file it is
modules/dialog/dlg_transfer.c in kamailio head.)

So perhaps my patch, by extending the tm uac api functions to present an
interface for a release function callback, might help avoid mistakes like
this in the future for opensips.

Cheers,

John


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

Comment By: John Riordan (john_riordan)
Date: 2009-05-10 06:10

Message:
Sincerely sorry about the "Bogan" typo.

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

Comment By: John Riordan (john_riordan)
Date: 2009-05-10 06:07

Message:
Hey Bogan,

Well, I'll do my best as passionate patch proponent, but first I want to
mention that I don't have my head anywhere near completely around the tm
module so please forgive me if I end up making statements that turn out to
be patently false. And secondly, this is going to be a ramble and I'm
afraid I don't have the time to edit it, proof read it, or even spell check
it so please forgive me in advance for slaughtering the art of writing.
Here goes...

1) Cleanup on first callback could lead to double free unless lock is used
local_reply() in t_reply.c releases the REPLY_LOCK prior to calling the
running the callbacks for TMCB_LOCAL_COMPLETED. So without locking in the
callback, the series of 200s (from a badly behaving uas for example) could
still trigger a double free from the race condition (ie. proc1 check NULL,
proc 1 free, proc2 check NULL, proc 2 free, proc 1 set param NULL, proc 2
set param NULL). This would obviously be bad. While I know that under
normal circumstances this senario would likely not occur, but it would not
be hard for a determined uas to bring this scenario to life and I'd rather
sleep well knowing that double free simply will not happen.

2) CPL proxy example not a good comparison
The example you referenced (cpl_proxy.h , reply_callback()) doesn't make
for an apples to apples comparision since in that case the callback is
trigger cleanup on TMCB_RESPONSE_OUT which relay_reply() (t_reply.c)
guarantees will only be sent once (sets local var totag_retr inside
REPLY_LOCK and uses it as a test for triggering the callback).

3) Using cleanup callback (release function) makes for a good api
The general approach of using a release function has merit in this case.
When an api is defined so that a callback is called once, the clean up of a
callback parameter is straight forward. But when an api is defined so that
a callback can be registered for multiple events and called repeatedly in
different ways depending on external circumstances, a release function
allows for straight forward clean up by the api consumer. The api consumer
can simply trust the api will do the right thing and call the release
function once whenever callback cleanup needs to be done (transaction ends,
system shutdown, whatever, etc). Furthermore it make it straight forward
for the api maintainer to make future changes and updates to the api
without worrying about who the consumers might be depending on event
sequences for cleanup. 

4) Alternative makes for a bad api
The alternative of defining the api along the lines of "register your
callback and if you are doing such and such you can cleanup when this
happens, but if you are doing this then you should do you cleanup like..."
leads, in my opinion, to confusion and bugs and problems making changes in
the future. It is certainly harder for the api consumer and leads to the
following kind of thing "ok, if my callback can be called multiple times
then I need to figure out when to cleanup ... is the api expecting the
parameter pointer to by constant? ... I could check the source code ... can
multiple processes be running my callback at the same time ... is the api
locking to prevent that? ... I ccould check the source code ... if I do it
this way will the api change in the future so that my approach doesn't
work? ... well I certainly don't want to double free because then that will
cause memory corruption and bring down the whole server and I don't want my
module doing that on people and those kinds of problems are really hard to
track down so I best start reading the source code to see what is is doing
so I don't mess it up ... who this tm module is complicated ... timers and
mutexes ... this sucks ... sigh ... maybe I'll just call free and hope for
the best ... no maybe I just won't free at all and leak memory which at
least won't crash it right away". 
For example, a current comment at the top of uac_cb() in seas_action.c
seas module (a callback passed to t_request_within)...

/ * ...
 * TODO WARNING !!! there's a clear MEMORY LEAK here, see exit: at the
bottom of
 * the function... it should free ev_info !!!!!!!!
 * I have disabled the free() because It may be that we receive a
retransmitted 200 OK
 * if the ACK gets lost, that 200 OK will make SER invoke this callback a
second,third, etc time...
 *
 */

Nice!

5) Trying to make the single callback approch work leads ugly land
Update! It looks like the seas code is now registering for
TMCB_TRANS_DELETED which is an undocumented thing that does appear to do
right thing (based on what can tell by pouring over the source code) and
callback at a desirable time for cleanup (expect during shutdown - maybe a
bug and should it should be moved from free_cell() into empty_tmcb_list()).
Of course the api consumer needs to go trolling through the source code to
ever realize that it exists and then has to wonder if it will exist in the
future because, well, it is undocumented and buried and only appears to be
used by this seas module thing which is, well, ah. umm. And lets see how
using this TMCB_DELETED thing is being done - first call t_request_within
and then when the first TMCB_LOCAL_COMPLETED shows up register for
TMCB_TRANS_DELETED and pass my cb param to that instead of cleaning it up
now... ummm, but wait isn't there a 200s race condition here and we could
end up registering two callbacks? ahh.. and boy isn't this ugly register
one callback and then register another and it still doesn't do...

Sigh.

6) Cleanup callback (release function) plain and simple just works well
Wouldn't it be great if the api just provided the ability to pass in
cleanup callback? Simple and elegant. And if it did, I the api consumer
could just use it and not have to read tm source code for hours and
everything would just work - now and in the future - because I can trust
that the api maintainer will called exactly once and from exactly the right
time/place. (Note that is exactly what the prior commited by dan_pascu did
- the release function infrastructure is already in place and gets called
in empty_tmcb_list() exactly once when the callbacks are getting cleaned
up). And there are no race conditions to worry about and no double frees.
And the api maintainer doesn't have to worry about messing any consumers up
in the future if internals need to change etc. And the api consumers (motly
crew that they are) will not go off doing ugly, dumb, and buggy stuff which
ends up in modules that end users include thinking it will give then this
great new feature they want but just ends up causing random crashes.

So, in conclusion, having the api consumer provide the api with a release
function is a good solution which works well for the api maintainer, the
api consumer, and for the health of the entire project (I'm really spinning
it now!). 

And finally, I do need to sleep at night, so can you please confirm that
at a minimum I will need to lock before I free if I attempt to go the "free
and set to NULL on first LOCAL_COMPLETED" route to make sure I never double
free?

Whew.

Thanks for reading,

John


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

Comment By: Bogdan-Andrei Iancu (bogdan_iancu)
Date: 2009-05-09 10:28

Message:
Hi John,

I'm not 100% sure this is needed.
Currently all local UAC transaction do trigger a TMCB_LOCAL_COMPLETED
callback when the transaction is completed. So you can use this callback to
cleanup whatever params you attached to the transaction.
In regards to the multiple 200 OK (retransmissions), the registered
callback function should first check if the received param is NULL and if
so, to exit. If not NULL,  it should free it and set it to NULL to avoid
sequential executions.
As an example, see in the CPL module, the cpl_proxy.h , reply_callback()
function, how the param (inter var) is freed.

Regards,
Bogdan 

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

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


From noreply at sourceforge.net  Tue May 26 18:47:29 2009
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue, 26 May 2009 16:47:29 +0000
Subject: [OpenSIPS-Devel] [ opensips-Patches-2731979 ] opensipsctl can't
	start proxy after crash
Message-ID: <E1M8zoH-0000w1-Pr@g45xhf1.ch3.sourceforge.com>

Patches item #2731979, was opened at 2009-04-04 22:49
Message generated for change (Comment added) made by bogdan_iancu
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086412&aid=2731979&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: tools
Group: trunk
>Status: Closed
Resolution: Accepted
Priority: 5
Private: No
Submitted By: ledda (ledda)
Assigned to: Bogdan-Andrei Iancu (bogdan_iancu)
Summary: opensipsctl can't start proxy after crash

Initial Comment:
The way how opensipsctl was checking PID file doesn't allow to start OpenSIPS after crash or hard reboot.

This patch check if there is a process running with the PID specified in pid file. If not, it removes pid file and start opensips.

Also 'restart' feature was broken. It doesn't stop opensips - there was such comment in the code by it doesn't make sense to me. 
So I've updated 'restart' command to do 'stop' and 'start'.

Also it fixes small typo in  daemonize.c.

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

>Comment By: Bogdan-Andrei Iancu (bogdan_iancu)
Date: 2009-05-26 19:47

Message:
Backport to 1.5 done.

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

Comment By: Bogdan-Andrei Iancu (bogdan_iancu)
Date: 2009-05-09 10:56

Message:
Hi ledda,

Thanks for the patch - I applied it in a modified version. Please test the
SVN trunk version and let me know if everything is ok. If so, I will
backport the fix to 1.5 version also.

Regards,
Bogdan


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

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


From bogdan at voice-system.ro  Tue May 26 18:48:39 2009
From: bogdan at voice-system.ro (Bogdan-Andrei Iancu)
Date: Tue, 26 May 2009 16:48:39 +0000
Subject: [OpenSIPS-Devel] SF.net SVN: opensips:[5742] branches/1.5/scripts
Message-ID: <E1M8zpP-0006DZ-4u@74yxhf1.ch3.sourceforge.com>

Revision: 5742
          http://opensips.svn.sourceforge.net/opensips/?rev=5742&view=rev
Author:   bogdan_iancu
Date:     2009-05-26 16:48:38 +0000 (Tue, 26 May 2009)

Log Message:
-----------
backport from trunk (rev #5686 + #5687):
- fixed start command - if bogus PID file is found, simplt purge it
- fixed restart command - do stop but do not exit if stop failed during a restart

  Credits go to ledda.
  Closes patch #2731979

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

Modified Paths:
--------------
    branches/1.5/scripts/opensipsctl
    branches/1.5/scripts/osipsconsole


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


From noreply at sourceforge.net  Tue May 26 18:52:30 2009
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue, 26 May 2009 16:52:30 +0000
Subject: [OpenSIPS-Devel] [ opensips-Patches-2706135 ] Change to listen=
	syntax to support per-interface advertised
Message-ID: <E1M8zt8-0001GC-IE@g45xhf1.ch3.sourceforge.com>

Patches item #2706135, was opened at 2009-03-23 15:50
Message generated for change (Comment added) made by bogdan_iancu
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086412&aid=2706135&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: Phil D'Amore (ptdamore)
Assigned to: Bogdan-Andrei Iancu (bogdan_iancu)
Summary: Change to listen= syntax to support per-interface advertised

Initial Comment:
[This is the patch for an idea I posted several weeks ago to the devel list.
Below is the original list posting as an explanation.]

The patch extends the idea of the advertised_address and advertised_port
parameters so that it is possible to bind such an address to each
listen= statement.

Syntax-wise, it works like this:

  listen=[proto:]host[:port][ AS host[:port]]

This new AS host[:port] syntax binds the advertised address specifically to the
corresponding socket_info structure.  If such an address is specified, it will
be used before the address specified as advertised_address, or set in the
set_advertised_address function for packets being sent on that particular
socket.  If it is not specified, then the old methods work as before.

The core has been modified so that address tuples using the advertised address
work interchangeably with the real address where you'd expect them to.
grep_sock_info and find_si have been updated to allow this.  Therefore, it is
not necessary to explicitly name your advertised address on an alias= line.
The following are now equivalent:

  force_send_socket(udp:adv_address:adv_port);
  force_send_socket(udp:real_address:real_port);

Note we don't specify protocol on the advertised address.  The way I see
things, it makes no sense to advertise a different protocol, so it inherits the
protocol of the socket.

Via construction is affected in the same way that the old global
advertised_address does, except the Via is written specifically for
the socket used
to send the message.

Lump substitution is also affected.  The following lump substitutions are aware
of this new facility:

 SUBST_RCV_IP
 SUBST_RCV_PORT
 SUBST_RCV_ALL
 SUBST_SND_IP
 SUBST_SND_PORT
 SUBST_SND_ALL

As a result of this, I was able to stop using record_route_preset in
my own config, and
just use standard record_route.  This winds up working much better,
because double-rr
works properly, and add_rr_param now works as expected for me, where it was a
problem using record_route_preset.

Additionally, registrar and usrloc had to be modified:

registrar - update the add_sock_hdr function to put the advertised address in
the message instead of the real address.  This allows registration information
to be replicated between multi-homed proxies, and the correct interface on the
peer can be used.

usrloc - update db_insert_ucontact to store the advertised address in the
database instead of the real address.  Same reasoning as the mods to registrar.

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

>Comment By: Bogdan-Andrei Iancu (bogdan_iancu)
Date: 2009-05-26 19:52

Message:
Hi Guys,

Is the bug fixed in the patch ? I just want to know to start evaluating
the patch for upload.

Thanks and regards,
Bogdan

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

Comment By: Nergal (nergalex)
Date: 2009-05-26 12:44

Message:
Hello Phil,

After few tests, I identified the exact context when the problem appear. I
answer to your questions before.

1) b) An extra random character, this morning is '.' that appears in the
first
Record-Route header after host:port BUT always in a specific context, see
#3.

2) I have "listen=X.X.X.X:5060 AS X.X.X.Y:5060" in my configuration and
also:
listen=X.X.X.X:15060 AS X.X.X.Y:5060

3) [NEW] The problem appears when the SIP message match the
"X.X.X.X:15060" instance. The rewrite of RR is done by the line
"listen=X.X.X.X:15060 AS X.X.X.Y:5060". In this case, the extra caracter is
suffixed to the first RR port (public inbound interface).
The problem appears for UDP and TCP protocol.

NB: 2 instances (5060 and 15060) of my SIP proxy is load-balanced. So, the
random effect is made by:
- If "SIP message destination = 5060" So test OK
- If "SIP message destination = 15060" So test Not OK

Best regards
Alexis

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

Comment By: Phil D'Amore (ptdamore)
Date: 2009-05-25 23:18

Message:
Alexis :

I have a few questions for you:

1) To make sure I understand the problem, I want to re-word it a bit. 
Which of these statements is true about the problem
  a) An extra ';' (always a ';') character appears in the first
Record-Route header after host:port, at random times.
  b) An extra random character (not always ';') appears in the first
Record-Route header after host:port, at random times

2) Since you are using double-rr can I assume that you also have a
listen=X.X.X.X:5060 line in your configuration for your public inbound
interface, but it was not included in your message because it does not
specify the [AS host:port] portion?

If the answer to 2 is yes, can you try to specify an alias on that listen=
line like this:

listen=X.X.X.X:5060 AS X.X.X.X:5060

The effect should be that no re-write appears to happen as the left and
right side are the same, but the code used to get there would be slightly
different.  I'm curious to see if the extra ';' goes away in that case.

Thanks,
Phil

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

Comment By: Nergal (nergalex)
Date: 2009-05-25 11:20

Message:
Hello,

Sorry to post this comment so late, I was in vacancy.
History: https://sourceforge.net/forum/message.php?msg_id=7379817

Best regards 
Alexis 
-------------------
I have a bug on the patch "Change to listen= syntax to support
per-interface advertised - ID: 2706135". In the first Record-Route header,
a random caracter ends the <IP:Port> entry (see below 2 tests with the same
configuration and the extra caracter is ';'). 
Could you help me to fix it? 
I can do more test or give you more information if you need. 
 
Maybe a clue: the Advertised port is 4 digits long but the real port is 5
digits long. 
 
conf extract: 
- X.X.X.X is a public IP 
- listen=tcp:10.143.136.8:15060 AS 10.143.136.29:5060 
- force_send_socket(10.143.136.8:15060); 
- t_relay("tcp:10.143.81.130:5060") 
 
 
--- Test OK / proto TCP --- 
1. Before SIP proxy processing (Front interface capture) 
SUBSCRIBE sip:service at pilote-sip.my_domain:5060 SIP/2.0 
Via: SIP/2.0/TCP 10.95.10.1:10005;branch=z9hG4bK-1338-1-0 
From: userA at sfr.fr <sip:sipp at 10.95.10.1:10005>;tag=1338SIPpTag001 
To: userA at sfr.fr <sip:service at pilote-sip.my_domain:5060> 
Call-ID: 1-1338 at 10.95.10.1 
CSeq: 1 SUBSCRIBE 
Contact: sip:sipp at 10.95.10.1:10005 
Max-Forwards: 70 
Subject: Subscribe Test 
Content-Length: 0 
 
2. After SIP proxy processing (Back interface capture) 
SUBSCRIBE sip:service at pilote-sip.my_domain:5060 SIP/2.0 
Record-Route:
<sip:10.143.136.29:5060;transport=tcp;r2=on;lr=on;ftag=1338SIPpTag001> 
Record-Route:
<sip:X.X.X.X:5060;transport=tcp;r2=on;lr=on;ftag=1338SIPpTag001> 
Via: SIP/2.0/TCP 10.143.136.29:5060;branch=z9hG4bKa4b3.1d7725a.0;i=9e8f 
Via: SIP/2.0/TCP
10.95.10.1:10005;rport=32769;received=10.95.10.1;branch=z9hG4bK-1338-1-0 
From: userA at sfr.fr <sip:sipp at 10.95.10.1:10005>;tag=1338SIPpTag001 
To: userA at sfr.fr <sip:service at pilote-sip.my_domain:5060> 
Call-ID: 1-1338 at 10.95.10.1 
CSeq: 1 SUBSCRIBE 
Contact: sip:sipp at 10.95.10.1:10005 
Max-Forwards: 69 
Subject: Subscribe Test 
Content-Length: 0 
--- end Test OK --- 
 
--- Test NOK / proto TCP --- 
1. Before SIP proxy processing (Front interface capture) 
SUBSCRIBE sip:service at pilote-sip.my_domain:5060 SIP/2.0 
Via: SIP/2.0/TCP 10.95.10.1:10003;branch=z9hG4bK-1571-1-0 
From: userA at sfr.fr <sip:sipp at 10.95.10.1:10003>;tag=1571SIPpTag001 
To: userA at sfr.fr <sip:service at pilote-sip.my_domain:5060> 
Call-ID: 1-1571 at 10.95.10.1 
CSeq: 1 SUBSCRIBE 
Contact: sip:sipp at 10.95.10.1:10003 
Max-Forwards: 70 
Subject: Subscribe Test 
Content-Length: 0 
 
2. After SIP proxy processing (Back interface capture) 
SUBSCRIBE sip:service at pilote-sip.my_domain:5060 SIP/2.0 
Record-Route:
<sip:10.143.136.29:5060;transport=tcp;r2=on;lr=on;ftag=1571SIPpTag001> 
Record-Route:
<sip:X.X.X.X:5060;;transport=tcp;r2=on;lr=on;ftag=1571SIPpTag001> 
Via: SIP/2.0/TCP 10.143.136.29:5060;branch=z9hG4bK60ec.650af5e3.0;i=83401 
Via: SIP/2.0/TCP
10.95.10.1:10003;rport=32808;received=10.95.10.1;branch=z9hG4bK-1571-1-0 
From: userA at sfr.fr <sip:sipp at 10.95.10.1:10003>;tag=1571SIPpTag001 
To: userA at sfr.fr <sip:service at pilote-sip.my_domain:5060> 
Call-ID: 1-1571 at 10.95.10.1 
CSeq: 1 SUBSCRIBE 
Contact: sip:sipp at 10.95.10.1:10003 
Max-Forwards: 69 
Subject: Subscribe Test 
Content-Length: 0 
--- end Test NOK --- 
 
Best regards 
Alexis 

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

Comment By: Bogdan-Andrei Iancu (bogdan_iancu)
Date: 2009-05-09 11:15

Message:
Hi Phil,

I will start reviewing the patch in order to upload it on SVN. If I have
some questions about it, I will post them here.

Thanks and regards,
Bogdan

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

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


From noreply at sourceforge.net  Tue May 26 19:03:02 2009
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue, 26 May 2009 17:03:02 +0000
Subject: [OpenSIPS-Devel] [ opensips-Patches-2706135 ] Change to listen=
	syntax to support per-interface advertised
Message-ID: <E1M903K-0002bL-SE@1bkjzd1.ch3.sourceforge.com>

Patches item #2706135, was opened at 2009-03-23 09:50
Message generated for change (Comment added) made by ptdamore
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086412&aid=2706135&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: Phil D'Amore (ptdamore)
Assigned to: Bogdan-Andrei Iancu (bogdan_iancu)
Summary: Change to listen= syntax to support per-interface advertised

Initial Comment:
[This is the patch for an idea I posted several weeks ago to the devel list.
Below is the original list posting as an explanation.]

The patch extends the idea of the advertised_address and advertised_port
parameters so that it is possible to bind such an address to each
listen= statement.

Syntax-wise, it works like this:

  listen=[proto:]host[:port][ AS host[:port]]

This new AS host[:port] syntax binds the advertised address specifically to the
corresponding socket_info structure.  If such an address is specified, it will
be used before the address specified as advertised_address, or set in the
set_advertised_address function for packets being sent on that particular
socket.  If it is not specified, then the old methods work as before.

The core has been modified so that address tuples using the advertised address
work interchangeably with the real address where you'd expect them to.
grep_sock_info and find_si have been updated to allow this.  Therefore, it is
not necessary to explicitly name your advertised address on an alias= line.
The following are now equivalent:

  force_send_socket(udp:adv_address:adv_port);
  force_send_socket(udp:real_address:real_port);

Note we don't specify protocol on the advertised address.  The way I see
things, it makes no sense to advertise a different protocol, so it inherits the
protocol of the socket.

Via construction is affected in the same way that the old global
advertised_address does, except the Via is written specifically for
the socket used
to send the message.

Lump substitution is also affected.  The following lump substitutions are aware
of this new facility:

 SUBST_RCV_IP
 SUBST_RCV_PORT
 SUBST_RCV_ALL
 SUBST_SND_IP
 SUBST_SND_PORT
 SUBST_SND_ALL

As a result of this, I was able to stop using record_route_preset in
my own config, and
just use standard record_route.  This winds up working much better,
because double-rr
works properly, and add_rr_param now works as expected for me, where it was a
problem using record_route_preset.

Additionally, registrar and usrloc had to be modified:

registrar - update the add_sock_hdr function to put the advertised address in
the message instead of the real address.  This allows registration information
to be replicated between multi-homed proxies, and the correct interface on the
peer can be used.

usrloc - update db_insert_ucontact to store the advertised address in the
database instead of the real address.  Same reasoning as the mods to registrar.

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

Comment By: Phil D'Amore (ptdamore)
Date: 2009-05-26 13:03

Message:
Alexis:

Thanks for the extra information.  I think I found the cause of the issue,
and I've uploaded a new version of the patch.  Please try the
listen_alias_port_fixed.patch.  I have not had time to test the issue in my
environment since I use port 5060 everywhere.  Since I don't know if I'll
be able to do it today I'm uploading the modified patch so you can test if
you'd like.

The issue was in the changes to msg_translator.c.  I was incorrectly using
the length of the original port to calculate an offset.  It was not
properly re-written with the rest of the code to use the alias port when
it's available.

Thanks,
Phil

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

Comment By: Bogdan-Andrei Iancu (bogdan_iancu)
Date: 2009-05-26 12:52

Message:
Hi Guys,

Is the bug fixed in the patch ? I just want to know to start evaluating
the patch for upload.

Thanks and regards,
Bogdan

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

Comment By: Nergal (nergalex)
Date: 2009-05-26 05:44

Message:
Hello Phil,

After few tests, I identified the exact context when the problem appear. I
answer to your questions before.

1) b) An extra random character, this morning is '.' that appears in the
first
Record-Route header after host:port BUT always in a specific context, see
#3.

2) I have "listen=X.X.X.X:5060 AS X.X.X.Y:5060" in my configuration and
also:
listen=X.X.X.X:15060 AS X.X.X.Y:5060

3) [NEW] The problem appears when the SIP message match the
"X.X.X.X:15060" instance. The rewrite of RR is done by the line
"listen=X.X.X.X:15060 AS X.X.X.Y:5060". In this case, the extra caracter is
suffixed to the first RR port (public inbound interface).
The problem appears for UDP and TCP protocol.

NB: 2 instances (5060 and 15060) of my SIP proxy is load-balanced. So, the
random effect is made by:
- If "SIP message destination = 5060" So test OK
- If "SIP message destination = 15060" So test Not OK

Best regards
Alexis

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

Comment By: Phil D'Amore (ptdamore)
Date: 2009-05-25 16:18

Message:
Alexis :

I have a few questions for you:

1) To make sure I understand the problem, I want to re-word it a bit. 
Which of these statements is true about the problem
  a) An extra ';' (always a ';') character appears in the first
Record-Route header after host:port, at random times.
  b) An extra random character (not always ';') appears in the first
Record-Route header after host:port, at random times

2) Since you are using double-rr can I assume that you also have a
listen=X.X.X.X:5060 line in your configuration for your public inbound
interface, but it was not included in your message because it does not
specify the [AS host:port] portion?

If the answer to 2 is yes, can you try to specify an alias on that listen=
line like this:

listen=X.X.X.X:5060 AS X.X.X.X:5060

The effect should be that no re-write appears to happen as the left and
right side are the same, but the code used to get there would be slightly
different.  I'm curious to see if the extra ';' goes away in that case.

Thanks,
Phil

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

Comment By: Nergal (nergalex)
Date: 2009-05-25 04:20

Message:
Hello,

Sorry to post this comment so late, I was in vacancy.
History: https://sourceforge.net/forum/message.php?msg_id=7379817

Best regards 
Alexis 
-------------------
I have a bug on the patch "Change to listen= syntax to support
per-interface advertised - ID: 2706135". In the first Record-Route header,
a random caracter ends the <IP:Port> entry (see below 2 tests with the same
configuration and the extra caracter is ';'). 
Could you help me to fix it? 
I can do more test or give you more information if you need. 
 
Maybe a clue: the Advertised port is 4 digits long but the real port is 5
digits long. 
 
conf extract: 
- X.X.X.X is a public IP 
- listen=tcp:10.143.136.8:15060 AS 10.143.136.29:5060 
- force_send_socket(10.143.136.8:15060); 
- t_relay("tcp:10.143.81.130:5060") 
 
 
--- Test OK / proto TCP --- 
1. Before SIP proxy processing (Front interface capture) 
SUBSCRIBE sip:service at pilote-sip.my_domain:5060 SIP/2.0 
Via: SIP/2.0/TCP 10.95.10.1:10005;branch=z9hG4bK-1338-1-0 
From: userA at sfr.fr <sip:sipp at 10.95.10.1:10005>;tag=1338SIPpTag001 
To: userA at sfr.fr <sip:service at pilote-sip.my_domain:5060> 
Call-ID: 1-1338 at 10.95.10.1 
CSeq: 1 SUBSCRIBE 
Contact: sip:sipp at 10.95.10.1:10005 
Max-Forwards: 70 
Subject: Subscribe Test 
Content-Length: 0 
 
2. After SIP proxy processing (Back interface capture) 
SUBSCRIBE sip:service at pilote-sip.my_domain:5060 SIP/2.0 
Record-Route:
<sip:10.143.136.29:5060;transport=tcp;r2=on;lr=on;ftag=1338SIPpTag001> 
Record-Route:
<sip:X.X.X.X:5060;transport=tcp;r2=on;lr=on;ftag=1338SIPpTag001> 
Via: SIP/2.0/TCP 10.143.136.29:5060;branch=z9hG4bKa4b3.1d7725a.0;i=9e8f 
Via: SIP/2.0/TCP
10.95.10.1:10005;rport=32769;received=10.95.10.1;branch=z9hG4bK-1338-1-0 
From: userA at sfr.fr <sip:sipp at 10.95.10.1:10005>;tag=1338SIPpTag001 
To: userA at sfr.fr <sip:service at pilote-sip.my_domain:5060> 
Call-ID: 1-1338 at 10.95.10.1 
CSeq: 1 SUBSCRIBE 
Contact: sip:sipp at 10.95.10.1:10005 
Max-Forwards: 69 
Subject: Subscribe Test 
Content-Length: 0 
--- end Test OK --- 
 
--- Test NOK / proto TCP --- 
1. Before SIP proxy processing (Front interface capture) 
SUBSCRIBE sip:service at pilote-sip.my_domain:5060 SIP/2.0 
Via: SIP/2.0/TCP 10.95.10.1:10003;branch=z9hG4bK-1571-1-0 
From: userA at sfr.fr <sip:sipp at 10.95.10.1:10003>;tag=1571SIPpTag001 
To: userA at sfr.fr <sip:service at pilote-sip.my_domain:5060> 
Call-ID: 1-1571 at 10.95.10.1 
CSeq: 1 SUBSCRIBE 
Contact: sip:sipp at 10.95.10.1:10003 
Max-Forwards: 70 
Subject: Subscribe Test 
Content-Length: 0 
 
2. After SIP proxy processing (Back interface capture) 
SUBSCRIBE sip:service at pilote-sip.my_domain:5060 SIP/2.0 
Record-Route:
<sip:10.143.136.29:5060;transport=tcp;r2=on;lr=on;ftag=1571SIPpTag001> 
Record-Route:
<sip:X.X.X.X:5060;;transport=tcp;r2=on;lr=on;ftag=1571SIPpTag001> 
Via: SIP/2.0/TCP 10.143.136.29:5060;branch=z9hG4bK60ec.650af5e3.0;i=83401 
Via: SIP/2.0/TCP
10.95.10.1:10003;rport=32808;received=10.95.10.1;branch=z9hG4bK-1571-1-0 
From: userA at sfr.fr <sip:sipp at 10.95.10.1:10003>;tag=1571SIPpTag001 
To: userA at sfr.fr <sip:service at pilote-sip.my_domain:5060> 
Call-ID: 1-1571 at 10.95.10.1 
CSeq: 1 SUBSCRIBE 
Contact: sip:sipp at 10.95.10.1:10003 
Max-Forwards: 69 
Subject: Subscribe Test 
Content-Length: 0 
--- end Test NOK --- 
 
Best regards 
Alexis 

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

Comment By: Bogdan-Andrei Iancu (bogdan_iancu)
Date: 2009-05-09 04:15

Message:
Hi Phil,

I will start reviewing the patch in order to upload it on SVN. If I have
some questions about it, I will post them here.

Thanks and regards,
Bogdan

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

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


From bogdan at voice-system.ro  Tue May 26 19:03:23 2009
From: bogdan at voice-system.ro (Bogdan-Andrei Iancu)
Date: Tue, 26 May 2009 17:03:23 +0000
Subject: [OpenSIPS-Devel] SF.net SVN: opensips:[5743] trunk/modules/mi_xmlrpc
Message-ID: <E1M903f-0006VJ-V0@74yxhf1.ch3.sourceforge.com>

Revision: 5743
          http://opensips.svn.sourceforge.net/opensips/?rev=5743&view=rev
Author:   bogdan_iancu
Date:     2009-05-26 17:03:23 +0000 (Tue, 26 May 2009)

Log Message:
-----------
-removed bug hunting logs - bug was found, fixing follows

Modified Paths:
--------------
    trunk/modules/mi_xmlrpc/abyss_conn.c
    trunk/modules/mi_xmlrpc/abyss_server.c
    trunk/modules/mi_xmlrpc/abyss_thread_fork.c


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


From iulia at opensips.org  Tue May 26 19:15:10 2009
From: iulia at opensips.org (Iulia Bublea)
Date: Tue, 26 May 2009 17:15:10 +0000
Subject: [OpenSIPS-Devel] SF.net SVN: opensips:[5744]
	trunk/scripts/osipsconsole
Message-ID: <E1M90F4-0006i1-Mu@74yxhf1.ch3.sourceforge.com>

Revision: 5744
          http://opensips.svn.sourceforge.net/opensips/?rev=5744&view=rev
Author:   iulia_bublea
Date:     2009-05-26 17:15:10 +0000 (Tue, 26 May 2009)

Log Message:
-----------
Fixed bug.

Modified Paths:
--------------
    trunk/scripts/osipsconsole


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 May 27 11:35:08 2009
From: bogdan at voice-system.ro (Bogdan-Andrei Iancu)
Date: Wed, 27 May 2009 09:35:08 +0000
Subject: [OpenSIPS-Devel] SF.net SVN: opensips:[5745]
	trunk/modules/mi_xmlrpc/abyss_thread_fork.c
Message-ID: <E1M9FXQ-0007X8-Sr@3kljzd1.ch3.sourceforge.com>

Revision: 5745
          http://opensips.svn.sourceforge.net/opensips/?rev=5745&view=rev
Author:   bogdan_iancu
Date:     2009-05-27 09:35:08 +0000 (Wed, 27 May 2009)

Log Message:
-----------
removed old include

Modified Paths:
--------------
    trunk/modules/mi_xmlrpc/abyss_thread_fork.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 May 27 15:25:34 2009
From: bogdan at voice-system.ro (Bogdan-Andrei Iancu)
Date: Wed, 27 May 2009 13:25:34 +0000
Subject: [OpenSIPS-Devel] SF.net SVN: opensips:[5746] trunk/modules/mi_xmlrpc
Message-ID: <E1M9J8Q-0007tO-Sm@bj8yhf1.ch3.sourceforge.com>

Revision: 5746
          http://opensips.svn.sourceforge.net/opensips/?rev=5746&view=rev
Author:   bogdan_iancu
Date:     2009-05-27 13:25:34 +0000 (Wed, 27 May 2009)

Log Message:
-----------
- fixed bug in xmlrpc lib - the signal handler used for getting the SIGCHLD (for the terminated worker processes) contains functions that may trigger a deadlock between the process and the handler (for example because of malloc/free which have an internal lock).
  Thannks to Dan Pascu for the support in troubleshooting this blocking.

Modified Paths:
--------------
    trunk/modules/mi_xmlrpc/abyss_conn.c
    trunk/modules/mi_xmlrpc/abyss_server.c
    trunk/modules/mi_xmlrpc/abyss_socket.c
    trunk/modules/mi_xmlrpc/abyss_socket.h
    trunk/modules/mi_xmlrpc/abyss_socket_unix.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 May 27 15:28:37 2009
From: bogdan at voice-system.ro (Bogdan-Andrei Iancu)
Date: Wed, 27 May 2009 13:28:37 +0000
Subject: [OpenSIPS-Devel] SF.net SVN: opensips:[5748]
	branches/1.5/modules/mi_xmlrpc
Message-ID: <E1M9JBN-0007wo-4w@bj8yhf1.ch3.sourceforge.com>

Revision: 5748
          http://opensips.svn.sourceforge.net/opensips/?rev=5748&view=rev
Author:   bogdan_iancu
Date:     2009-05-27 13:28:36 +0000 (Wed, 27 May 2009)

Log Message:
-----------
backport from trunk (rev #5746):
- fixed bug in xmlrpc lib - the signal handler used for getting the SIGCHLD (for the terminated worker processes) contains functions that may trigger a deadlock between the process and the handler (for example because of malloc/free which have an internal lock).
  Thannks to Dan Pascu for the support in troubleshooting this blocking.

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

Modified Paths:
--------------
    branches/1.5/modules/mi_xmlrpc/abyss_server.c
    branches/1.5/modules/mi_xmlrpc/abyss_socket.c
    branches/1.5/modules/mi_xmlrpc/abyss_socket.h
    branches/1.5/modules/mi_xmlrpc/abyss_socket_unix.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 May 27 15:28:35 2009
From: bogdan at voice-system.ro (Bogdan-Andrei Iancu)
Date: Wed, 27 May 2009 13:28:35 +0000
Subject: [OpenSIPS-Devel] SF.net SVN: opensips:[5747]
	branches/1.4/modules/mi_xmlrpc
Message-ID: <E1M9JBL-0007wc-F0@bj8yhf1.ch3.sourceforge.com>

Revision: 5747
          http://opensips.svn.sourceforge.net/opensips/?rev=5747&view=rev
Author:   bogdan_iancu
Date:     2009-05-27 13:28:35 +0000 (Wed, 27 May 2009)

Log Message:
-----------
backport from trunk (rev #5746):
- fixed bug in xmlrpc lib - the signal handler used for getting the SIGCHLD (for the terminated worker processes) contains functions that may trigger a deadlock between the process and the handler (for example because of malloc/free which have an internal lock).
  Thannks to Dan Pascu for the support in troubleshooting this blocking.

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

Modified Paths:
--------------
    branches/1.4/modules/mi_xmlrpc/abyss_server.c
    branches/1.4/modules/mi_xmlrpc/abyss_socket.c
    branches/1.4/modules/mi_xmlrpc/abyss_socket.h
    branches/1.4/modules/mi_xmlrpc/abyss_socket_unix.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 May 27 15:53:24 2009
From: bogdan at voice-system.ro (Bogdan-Andrei Iancu)
Date: Wed, 27 May 2009 16:53:24 +0300
Subject: [OpenSIPS-Devel] MI-XMLRCP: major fix - upgrade recommended
Message-ID: <4A1D45D4.70103@voice-system.ro>

Hi,

In the last years there were several reports about the blocking of the 
mi_xmlrpc module - actually this was the reason for having this MI 
XMLRPC 2 FIFO proxy right now.

Thanks to the help of Dan Pascu, we manage to identify the cause :a 
design bug in xmlrpc lib - the signal handler used for getting the 
SIGCHLD (for the terminated worker processes) contained functions that 
may trigger a deadlock between the main code and the handler (for 
example because of malloc/free which have an internal lock).

This bug was fixed in all OpenSIPS versions (available on SVN) and it is 
strongly recommended to upgrade your code.


Regards,
Bogdan


From lebing76 at gmail.com  Wed May 27 17:04:52 2009
From: lebing76 at gmail.com (Lebing Xie)
Date: Wed, 27 May 2009 23:04:52 +0800
Subject: [OpenSIPS-Devel] OpenSIP Presence Server and OMA/3GPP
Message-ID: <c208a9c90905270804s2b39ba94qee1113d7ef95442f@mail.gmail.com>

Hi,



I am a new bee by OpenSIP presence server and thinking about to build a OMA
compliant presence server on top of OpenSIP. The whole architecture includes
a RLS, a PS and external XDMS.

I have following questions, would you guys mind to ask them:



   1. I check the document, said OpenSIP PS follows following RFCs - RFC3265,
   RFC3856, RFC3857, RFC3858. Is there any information or statement about
   the compatibility with OMA SIP SIMPLE 1.X and 3GPP IMS Presence (24.141)?
   How about the effort to achieve them (or done by other open source project
   )?



   1. In case using an external XDMS hosting the presence policy, the Client
   can modify the policy directly via the XDMS?s XCAP interface?



Thanks in advance.



Lebing
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.opensips.org/pipermail/devel/attachments/20090527/31dd6e53/attachment.htm 

From bogdan at voice-system.ro  Wed May 27 17:35:40 2009
From: bogdan at voice-system.ro (Bogdan-Andrei Iancu)
Date: Wed, 27 May 2009 18:35:40 +0300
Subject: [OpenSIPS-Devel] [OpenSIPS-Users] MI-XMLRCP: major fix -
	upgrade recommended
In-Reply-To: <4f67656a0905270818jea4dedfsd198bb966a306dfc@mail.gmail.com>
References: <4A1D45D4.70103@voice-system.ro>
	<4f67656a0905270818jea4dedfsd198bb966a306dfc@mail.gmail.com>
Message-ID: <4A1D5DCC.9080203@voice-system.ro>

No, this is some XMPRPC specific stuff.

What kind of errors did you get on FIFO?

Regards,
Bogdan

Brett Nemeroff wrote:
> Bogdan,
> I've had some issues where running fifo commands sometimes returns 
> errors. Simple things like dumping the dialogs. Is this related do you 
> think?
> -Brett
>
>
> On Wed, May 27, 2009 at 8:53 AM, Bogdan-Andrei Iancu 
> <bogdan at voice-system.ro <mailto:bogdan at voice-system.ro>> wrote:
>
>     Hi,
>
>     In the last years there were several reports about the blocking of the
>     mi_xmlrpc module - actually this was the reason for having this MI
>     XMLRPC 2 FIFO proxy right now.
>
>     Thanks to the help of Dan Pascu, we manage to identify the cause :a
>     design bug in xmlrpc lib - the signal handler used for getting the
>     SIGCHLD (for the terminated worker processes) contained functions that
>     may trigger a deadlock between the main code and the handler (for
>     example because of malloc/free which have an internal lock).
>
>     This bug was fixed in all OpenSIPS versions (available on SVN) and
>     it is
>     strongly recommended to upgrade your code.
>
>
>     Regards,
>     Bogdan
>
>     _______________________________________________
>     Users mailing list
>     Users at lists.opensips.org <mailto:Users at lists.opensips.org>
>     http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>
>



From lftsy at users.sourceforge.net  Fri May 22 16:37:22 2009
From: lftsy at users.sourceforge.net (lftsy at users.sourceforge.net)
Date: Fri, 22 May 2009 14:37:22 +0000
Subject: [OpenSIPS-Devel] SF.net SVN: opensips:[5727] trunk/packaging/rpm
Message-ID: <E1M7VsA-0007O2-92@74yxhf1.ch3.sourceforge.com>

Revision: 5727
          http://opensips.svn.sourceforge.net/opensips/?rev=5727&view=rev
Author:   lftsy
Date:     2009-05-22 14:37:21 +0000 (Fri, 22 May 2009)

Log Message:
-----------
* Fri May 22 2009 Marc Leurent <marc.leurent at vtx-telecom.ch>
- Add /etc/default/opensips file to allow shared memory configuration
- Modify snmpstats Requires to add net-snmp-utils

Modified Paths:
--------------
    trunk/packaging/rpm/opensips.init
    trunk/packaging/rpm/opensips.spec.CentOS

Added Paths:
-----------
    trunk/packaging/rpm/opensips.default


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


From lftsy at users.sourceforge.net  Fri May 22 16:38:10 2009
From: lftsy at users.sourceforge.net (lftsy at users.sourceforge.net)
Date: Fri, 22 May 2009 14:38:10 +0000
Subject: [OpenSIPS-Devel] SF.net SVN: opensips:[5728]
	branches/1.4/packaging/rpm
Message-ID: <E1M7Vsw-0007P2-TK@74yxhf1.ch3.sourceforge.com>

Revision: 5728
          http://opensips.svn.sourceforge.net/opensips/?rev=5728&view=rev
Author:   lftsy
Date:     2009-05-22 14:38:10 +0000 (Fri, 22 May 2009)

Log Message:
-----------
* Fri May 22 2009 Marc Leurent <marc.leurent at vtx-telecom.ch>
- Add /etc/default/opensips file to allow shared memory configuration
- Modify snmpstats Requires to add net-snmp-utils

Modified Paths:
--------------
    branches/1.4/packaging/rpm/opensips.init

Added Paths:
-----------
    branches/1.4/packaging/rpm/opensips.default
    branches/1.4/packaging/rpm/opensips.spec.CentOS

Removed Paths:
-------------
    branches/1.4/packaging/rpm/opensips.spec-4.4


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


From lftsy at users.sourceforge.net  Fri May 22 16:39:19 2009
From: lftsy at users.sourceforge.net (lftsy at users.sourceforge.net)
Date: Fri, 22 May 2009 14:39:19 +0000
Subject: [OpenSIPS-Devel] SF.net SVN: opensips:[5729]
	branches/1.5/packaging/rpm
Message-ID: <E1M7Vu3-0007Qw-9z@74yxhf1.ch3.sourceforge.com>

Revision: 5729
          http://opensips.svn.sourceforge.net/opensips/?rev=5729&view=rev
Author:   lftsy
Date:     2009-05-22 14:39:19 +0000 (Fri, 22 May 2009)

Log Message:
-----------
* Fri May 22 2009 Marc Leurent <marc.leurent at vtx-telecom.ch>
- Add /etc/default/opensips file to allow shared memory configuration
- Modify snmpstats Requires to add net-snmp-utils

Modified Paths:
--------------
    branches/1.5/packaging/rpm/opensips.init
    branches/1.5/packaging/rpm/opensips.spec.CentOS

Added Paths:
-----------
    branches/1.5/packaging/rpm/opensips.default


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


From bpassanha at brastel.com.br  Mon May 25 16:42:01 2009
From: bpassanha at brastel.com.br (Brenno)
Date: Mon, 25 May 2009 11:42:01 -0300
Subject: [OpenSIPS-Devel] OpenSIPS script
Message-ID: <4A1AAE39.60505@terra.com.br>

Hi,

Sorry for my english, but i need something.

I'm working in my university project, and i need to do a virtual PBX, 
and the only way i know that i can do it, is using opensips.

I was studying some scripts, but i have a little dificult to understand 
somethings.

What i need is, some script that can validate the REGISTER of user in 
some mysql table (like subscriber), log the informations of calls in the 
database (like in acc table, this i'm sure i can do) and it have to work 
in different networks (i guess with RTP Proxy, and this is my greater 
dificult to find some examples, because i dont know if the script change 
with the RTP working). And of course, can make calls between user in the 
some domain like 'user1 at google.com' can make calls to 
'user2 at google.com', but cannot do to 'user at linux.com', can you 
understand? this is a dificult too, because i don't know if is possible 
to do.

Does anyone have a example script for Opensips that has these features?

Thanks in advanced,

Brenno Passanha


From bpassanha at brastel.com.br  Mon May 25 16:43:43 2009
From: bpassanha at brastel.com.br (Brenno)
Date: Mon, 25 May 2009 11:43:43 -0300
Subject: [OpenSIPS-Devel] Opensips study script
Message-ID: <4A1AAE9F.8080001@terra.com.br>

Hi,

Sorry for my english, but i need something.

I'm working in my university project, and i need to do a virtual PBX, 
and the only way i know that i can do it, is using opensips.

I was studying some scripts, but i have a little dificult to understand 
somethings.

What i need is, some script that can validate the REGISTER of user in 
some mysql table (like subscriber), log the informations of calls in the 
database (like in acc table, this i'm sure i can do) and it have to work 
in different networks (i guess with RTP Proxy, and this is my greater 
dificult to find some examples, because i dont know if the script change 
with the RTP working). And of course, can make calls between user in the 
some domain like 'user1 at google.com' can make calls to 
'user2 at google.com', but cannot do to 'user at linux.com', can you 
understand? this is a dificult too, because i don't know if is possible 
to do.

Does anyone have a example script for Opensips that has these features?

Thanks in advanced,

Brenno Passanha


From brett at nemeroff.com  Wed May 27 17:18:34 2009
From: brett at nemeroff.com (Brett Nemeroff)
Date: Wed, 27 May 2009 10:18:34 -0500
Subject: [OpenSIPS-Devel] [OpenSIPS-Users] MI-XMLRCP: major fix -
	upgrade recommended
In-Reply-To: <4A1D45D4.70103@voice-system.ro>
References: <4A1D45D4.70103@voice-system.ro>
Message-ID: <4f67656a0905270818jea4dedfsd198bb966a306dfc@mail.gmail.com>

Bogdan,I've had some issues where running fifo commands sometimes returns
errors. Simple things like dumping the dialogs. Is this related do you
think?
-Brett


On Wed, May 27, 2009 at 8:53 AM, Bogdan-Andrei Iancu <bogdan at voice-system.ro
> wrote:

> Hi,
>
> In the last years there were several reports about the blocking of the
> mi_xmlrpc module - actually this was the reason for having this MI
> XMLRPC 2 FIFO proxy right now.
>
> Thanks to the help of Dan Pascu, we manage to identify the cause :a
> design bug in xmlrpc lib - the signal handler used for getting the
> SIGCHLD (for the terminated worker processes) contained functions that
> may trigger a deadlock between the main code and the handler (for
> example because of malloc/free which have an internal lock).
>
> This bug was fixed in all OpenSIPS versions (available on SVN) and it is
> strongly recommended to upgrade your code.
>
>
> Regards,
> Bogdan
>
> _______________________________________________
> Users mailing list
> Users at lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.opensips.org/pipermail/devel/attachments/20090527/4d151981/attachment.htm 

From noreply at sourceforge.net  Thu May 28 14:58:28 2009
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 28 May 2009 12:58:28 +0000
Subject: [OpenSIPS-Devel] [ opensips-Bugs-2797896 ] sql connection timeout
	w/ media dispatcher
Message-ID: <E1M9fBk-0007d6-L0@g45xhf1.ch3.sourceforge.com>

Bugs item #2797896, was opened at 2009-05-28 12:58
Message generated for change (Tracker Item Submitted) made by rrevels
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=2797896&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: tools
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Richard Revels (rrevels)
Assigned to: Nobody/Anonymous (nobody)
Summary: sql connection timeout w/ media dispatcher 

Initial Comment:
Having a problem with the media dispatcher from media proxy 2.3.2 (which is an Excellent tool!) if calls don't hit the platform for several hours.  The connection to the mysql server times out and the application does not attempt to reconnect.  An error is logged and the record is dropped.  Restarting dispatcher solves problem but if a reconnect attempt could be made before giving up it would be helpful.  

error message:

media-dispatcher[7194]: error: failed to insert record into database: MySQL server has gone away


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

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


From ibc at aliax.net  Thu May 28 15:51:25 2009
From: ibc at aliax.net (=?UTF-8?Q?I=C3=B1aki_Baz_Castillo?=)
Date: Thu, 28 May 2009 15:51:25 +0200
Subject: [OpenSIPS-Devel] Opensips study script
In-Reply-To: <4A1AAE9F.8080001@terra.com.br>
References: <4A1AAE9F.8080001@terra.com.br>
Message-ID: <cc1f582e0905280651v3308aa7dh956ab6dc0ac5feb7@mail.gmail.com>

2009/5/25 Brenno <bpassanha at brastel.com.br>:
> Hi,
>
> Sorry for my english, but i need something.
>
> I'm working in my university project, and i need to do a virtual PBX,
> and the only way i know that i can do it, is using opensips.
>
> I was studying some scripts, but i have a little dificult to understand
> somethings.
>
> What i need is, some script that can validate the REGISTER of user in
> some mysql table (like subscriber), log the informations of calls in the
> database (like in acc table, this i'm sure i can do) and it have to work
> in different networks (i guess with RTP Proxy, and this is my greater
> dificult to find some examples, because i dont know if the script change
> with the RTP working). And of course, can make calls between user in the
> some domain like 'user1 at google.com' can make calls to
> 'user2 at google.com', but cannot do to 'user at linux.com', can you
> understand? this is a dificult too, because i don't know if is possible
> to do.
>
> Does anyone have a example script for Opensips that has these features?

All your requeriments are really feasible with OpenSIPS, but of
course, it requieres to learn about managing OpenSIPS.

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


From noreply at sourceforge.net  Fri May 29 09:32:23 2009
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 29 May 2009 07:32:23 +0000
Subject: [OpenSIPS-Devel] [ opensips-Patches-2795418 ] Adding
	/etc/default/opensips file for rpm packaging
Message-ID: <E1M9wZj-0006dS-4d@1bkjzd1.ch3.sourceforge.com>

Patches item #2795418, was opened at 2009-05-22 16:36
Message generated for change (Comment added) made by lftsy
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086412&aid=2795418&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: packaging
Group: None
>Status: Closed
Resolution: Accepted
Priority: 5
Private: No
Submitted By: Marc LEURENT (lftsy)
Assigned to: Marc LEURENT (lftsy)
Summary: Adding /etc/default/opensips file for rpm packaging

Initial Comment:
Hello all, I have just modified the opensips.spec.CentOS file to integrate /etc/default/opensips.
This new file will permit to modify some parameters without having to change the /etc/init.d/opensips file like the amount of shared memory to allow.
You will see that the modifications are debian style inspired!!

Here is the changelog:
* Fri May 22 2009 Marc Leurent <marc.leurent at vtx-telecom.ch>
- Add /etc/default/opensips file to allow shared memory configuration
- Modify snmpstats Requires to add net-snmp-utils

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

>Comment By: Marc LEURENT (lftsy)
Date: 2009-05-29 09:32

Message:
Good morning,
CentOS rpm packaging is ok.
Closing ticket

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

Comment By: Marc LEURENT (lftsy)
Date: 2009-05-22 16:42

Message:
Compilation and packaging ok,
I'm uploading the RPMs with new packaging on 
CentOS el5 (RPMs i386/x86_64) (thanks to Julian Yap & Marc Leurent)
http://centos.leurent.eu/
as referred from http://www.opensips.org/Resources/Downloads

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

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


From bogdan at voice-system.ro  Fri May 29 14:21:08 2009
From: bogdan at voice-system.ro (Bogdan-Andrei Iancu)
Date: Fri, 29 May 2009 12:21:08 +0000
Subject: [OpenSIPS-Devel] SF.net SVN: opensips:[5749] trunk/modules/dialog
Message-ID: <E1MA15A-0007JP-Pm@d5vjzd1.ch3.sourceforge.com>

Revision: 5749
          http://opensips.svn.sourceforge.net/opensips/?rev=5749&view=rev
Author:   bogdan_iancu
Date:     2009-05-29 12:21:08 +0000 (Fri, 29 May 2009)

Log Message:
-----------
- added DB persistency for the dialog profiles, dialog script flags, dialog variables - all this values will survive an OpenSIPS restart now.

Modified Paths:
--------------
    trunk/modules/dialog/dlg_db_handler.c
    trunk/modules/dialog/dlg_db_handler.h


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


From bogdan at voice-system.ro  Fri May 29 14:57:11 2009
From: bogdan at voice-system.ro (Bogdan-Andrei Iancu)
Date: Fri, 29 May 2009 12:57:11 +0000
Subject: [OpenSIPS-Devel] SF.net SVN: opensips:[5750] trunk
Message-ID: <E1MA1e3-0003rI-7z@3kljzd1.ch3.sourceforge.com>

Revision: 5750
          http://opensips.svn.sourceforge.net/opensips/?rev=5750&view=rev
Author:   bogdan_iancu
Date:     2009-05-29 12:57:10 +0000 (Fri, 29 May 2009)

Log Message:
-----------
- extension to dialog table to allow saving of dialog flags, dialog vars and dialog profiles

Modified Paths:
--------------
    trunk/db/schema/dialog.xml
    trunk/scripts/db_berkeley/opensips/dialog
    trunk/scripts/dbtext/opensips/dialog
    trunk/scripts/mysql/dialog-create.sql
    trunk/scripts/oracle/dialog-create.sql
    trunk/scripts/postgres/dialog-create.sql


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


From bogdan at voice-system.ro  Fri May 29 14:58:39 2009
From: bogdan at voice-system.ro (Bogdan-Andrei Iancu)
Date: Fri, 29 May 2009 12:58:39 +0000
Subject: [OpenSIPS-Devel] SF.net SVN: opensips:[5751]
	trunk/modules/dialog/dlg_db_handler.h
Message-ID: <E1MA1fT-0003tc-6K@3kljzd1.ch3.sourceforge.com>

Revision: 5751
          http://opensips.svn.sourceforge.net/opensips/?rev=5751&view=rev
Author:   bogdan_iancu
Date:     2009-05-29 12:58:39 +0000 (Fri, 29 May 2009)

Log Message:
-----------
- increased table version from 3 to 4

Modified Paths:
--------------
    trunk/modules/dialog/dlg_db_handler.h


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


From bogdan at voice-system.ro  Fri May 29 15:04:21 2009
From: bogdan at voice-system.ro (Bogdan-Andrei Iancu)
Date: Fri, 29 May 2009 16:04:21 +0300
Subject: [OpenSIPS-Devel] [NEW] Dialog data persistence across reboot
Message-ID: <4A1FDD55.8010405@voice-system.ro>

Hi,

I added to the dialog module support for data persistence (dialog script 
flags, dialog script variables, dialog profiles) across restart. As this 
data is highly dynamic nature (may changes very often), it is flushed to 
DB only at shutdown time - so do not expect to see it in DB during runtime.

This will directly affect the script functionality - you can rely on not 
loosing the dialog context if rebooting, and also the module using 
dialog module (like load-balancer which needs to keep the profiles in 
order to do the job).

Regards,
Bogdan


From bogdan at voice-system.ro  Fri May 29 15:51:45 2009
From: bogdan at voice-system.ro (Bogdan-Andrei Iancu)
Date: Fri, 29 May 2009 16:51:45 +0300
Subject: [OpenSIPS-Devel] [OpenSIPS-Users] [NEW] Dialog data persistence
	across reboot
In-Reply-To: <4f67656a0905290614o41114a9jf127027ec46239c4@mail.gmail.com>
References: <4A1FDD55.8010405@voice-system.ro>
	<4f67656a0905290614o41114a9jf127027ec46239c4@mail.gmail.com>
Message-ID: <4A1FE871.10707@voice-system.ro>

Hi Brett,

not following you :(....you refer to "cfg script reload" ??

regards,
Bogdan

Brett Nemeroff wrote:
> Bogdan,
> similar, yet unrelated question. Any plans to implement a "reload" 
> where the config file is checked, then applied without restarting?
>
> Please let me know..
> -Brett
>
> On Fri, May 29, 2009 at 8:04 AM, Bogdan-Andrei Iancu 
> <bogdan at voice-system.ro <mailto:bogdan at voice-system.ro>> wrote:
>
>     Hi,
>
>     I added to the dialog module support for data persistence (dialog
>     script
>     flags, dialog script variables, dialog profiles) across restart.
>     As this
>     data is highly dynamic nature (may changes very often), it is
>     flushed to
>     DB only at shutdown time - so do not expect to see it in DB during
>     runtime.
>
>     This will directly affect the script functionality - you can rely
>     on not
>     loosing the dialog context if rebooting, and also the module using
>     dialog module (like load-balancer which needs to keep the profiles in
>     order to do the job).
>
>     Regards,
>     Bogdan
>
>     _______________________________________________
>     Users mailing list
>     Users at lists.opensips.org <mailto:Users at lists.opensips.org>
>     http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>
>



From thomas at gelf.net  Fri May 29 16:16:59 2009
From: thomas at gelf.net (Thomas Gelf)
Date: Fri, 29 May 2009 16:16:59 +0200
Subject: [OpenSIPS-Devel] [OpenSIPS-Users] [NEW] Dialog data persistence
	across reboot
In-Reply-To: <4A1FDD55.8010405@voice-system.ro>
References: <4A1FDD55.8010405@voice-system.ro>
Message-ID: <gvoqor$v4f$3@ger.gmane.org>

That's great, thank you very much - I'll intensively test it during this
weekend!

Cheers,
Thomas

> I added to the dialog module support for data persistence (dialog script 
> flags, dialog script variables, dialog profiles) across restart. As this 
> data is highly dynamic nature (may changes very often), it is flushed to 
> DB only at shutdown time - so do not expect to see it in DB during runtime.
> 
> This will directly affect the script functionality - you can rely on not 
> loosing the dialog context if rebooting, and also the module using 
> dialog module (like load-balancer which needs to keep the profiles in 
> order to do the job).



From brett at nemeroff.com  Fri May 29 15:14:21 2009
From: brett at nemeroff.com (Brett Nemeroff)
Date: Fri, 29 May 2009 08:14:21 -0500
Subject: [OpenSIPS-Devel] [OpenSIPS-Users] [NEW] Dialog data persistence
	across reboot
In-Reply-To: <4A1FDD55.8010405@voice-system.ro>
References: <4A1FDD55.8010405@voice-system.ro>
Message-ID: <4f67656a0905290614o41114a9jf127027ec46239c4@mail.gmail.com>

Bogdan,
similar, yet unrelated question. Any plans to implement a "reload" where the
config file is checked, then applied without restarting?

Please let me know..
-Brett

On Fri, May 29, 2009 at 8:04 AM, Bogdan-Andrei Iancu <bogdan at voice-system.ro
> wrote:

> Hi,
>
> I added to the dialog module support for data persistence (dialog script
> flags, dialog script variables, dialog profiles) across restart. As this
> data is highly dynamic nature (may changes very often), it is flushed to
> DB only at shutdown time - so do not expect to see it in DB during runtime.
>
> This will directly affect the script functionality - you can rely on not
> loosing the dialog context if rebooting, and also the module using
> dialog module (like load-balancer which needs to keep the profiles in
> order to do the job).
>
> Regards,
> Bogdan
>
> _______________________________________________
> Users mailing list
> Users at lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.opensips.org/pipermail/devel/attachments/20090529/4bc5ad84/attachment.htm 

From brett at nemeroff.com  Fri May 29 17:34:15 2009
From: brett at nemeroff.com (Brett Nemeroff)
Date: Fri, 29 May 2009 10:34:15 -0500
Subject: [OpenSIPS-Devel] [OpenSIPS-Users] [NEW] Dialog data persistence
	across reboot
In-Reply-To: <4A1FE871.10707@voice-system.ro>
References: <4A1FDD55.8010405@voice-system.ro>
	<4f67656a0905290614o41114a9jf127027ec46239c4@mail.gmail.com> 
	<4A1FE871.10707@voice-system.ro>
Message-ID: <4f67656a0905290834u58b6d348s996a4b1531bb7c9f@mail.gmail.com>

Yes, that is what I mean. Sorry for the confusion.

On Fri, May 29, 2009 at 8:51 AM, Bogdan-Andrei Iancu <bogdan at voice-system.ro
> wrote:

> Hi Brett,
>
> not following you :(....you refer to "cfg script reload" ??
>
> regards,
> Bogdan
>
> Brett Nemeroff wrote:
>
>> Bogdan,
>> similar, yet unrelated question. Any plans to implement a "reload" where
>> the config file is checked, then applied without restarting?
>>
>> Please let me know..
>> -Brett
>>
>> On Fri, May 29, 2009 at 8:04 AM, Bogdan-Andrei Iancu <
>> bogdan at voice-system.ro <mailto:bogdan at voice-system.ro>> wrote:
>>
>>    Hi,
>>
>>    I added to the dialog module support for data persistence (dialog
>>    script
>>    flags, dialog script variables, dialog profiles) across restart.
>>    As this
>>    data is highly dynamic nature (may changes very often), it is
>>    flushed to
>>    DB only at shutdown time - so do not expect to see it in DB during
>>    runtime.
>>
>>    This will directly affect the script functionality - you can rely
>>    on not
>>    loosing the dialog context if rebooting, and also the module using
>>    dialog module (like load-balancer which needs to keep the profiles in
>>    order to do the job).
>>
>>    Regards,
>>    Bogdan
>>
>>    _______________________________________________
>>    Users mailing list
>>    Users at lists.opensips.org <mailto:Users at lists.opensips.org>
>>    http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.opensips.org/pipermail/devel/attachments/20090529/1e2db287/attachment.htm 

