From noreply at sourceforge.net  Sun Jan  3 01:36:45 2010
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun, 03 Jan 2010 00:36:45 +0000
Subject: [OpenSIPS-Devel] [ opensips-Patches-2925069 ] nathelper :
	set_rtp_proxy_set support AVPs
Message-ID: <E1NRESb-0000RQ-5O@b55xhf1.ch3.sourceforge.com>

Patches item #2925069, was opened at 2010-01-03 01:36
Message generated for change (Tracker Item Submitted) made by neutrino38
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086412&aid=2925069&group_id=232389

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: modules
Group: 1.6.x
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Emmanuel BUU (neutrino38)
Assigned to: Nobody/Anonymous (nobody)
Summary: nathelper : set_rtp_proxy_set support AVPs

Initial Comment:
Enhancement of set_rtp_proxy_set function tu support AVP so proxy sets can be choosen dynamically

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

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


From ag at ag-projects.com  Sun Jan  3 12:33:20 2010
From: ag at ag-projects.com (Adrian Georgescu)
Date: Sun, 3 Jan 2010 12:33:20 +0100
Subject: [OpenSIPS-Devel] AG Projects Exhibits at ITEXPO 2010
Message-ID: <BB551D2C-0C70-4BA9-8B47-D2CE65DBEFA8@ag-projects.com>

Hello,

AG Projects exhibits at ITEXPO/Digium Asterisk World in Miami/Florida  
taking place between January 20-22.

http://www.tmcnet.com/voip/conference/digium-asterisk-world/

If you wish to learn more about using OpenSIPS and related software  
supported by our company (MediaProxy, CDRTool, CallControl and  
OpenXCAP) you are welcome to visit us at booth D15 and listen to our  
session about how to use OpenSIPS to scale up Asterisk infrastructures:

http://www.tmcnet.com/voip/conference/digium-asterisk-world/daw-e10-agenda.aspx?t=DA1#DA1-06

Kind regards,
Adrian Georgescu




From noreply at sourceforge.net  Sun Jan  3 19:19:38 2010
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun, 03 Jan 2010 18:19:38 +0000
Subject: [OpenSIPS-Devel] [ opensips-Bugs-2925298 ] tm module socket write
	problems
Message-ID: <E1NRV3C-0004iV-MM@565xhf1.ch3.sourceforge.com>

Bugs item #2925298, was opened at 2010-01-03 18:19
Message generated for change (Tracker Item Submitted) made by rrevels
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=2925298&group_id=232389

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: modules
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Richard Revels (rrevels)
Assigned to: Nobody/Anonymous (nobody)
Summary: tm module socket write problems

Initial Comment:
Found that the documentation refers to function as t_write_fifo but code exports function as t_write_req.

Function fixup_t_write (line 300 in t_fifo.c) checks param_no against 2 but should be checked for 1.

Function t_write_fifo fails with "t_get_trans_ident failed" on line 504 of t_fifo.c.

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

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


From sobomax at sippysoft.com  Mon Jan  4 13:26:41 2010
From: sobomax at sippysoft.com (Maxim Sobolev)
Date: Mon, 04 Jan 2010 12:26:41 +0000
Subject: [OpenSIPS-Devel] SF.net SVN: opensips:[6487]
	trunk/modules/python/python_msgobj.c
Message-ID: <E1NRm1B-0007R5-Jj@3kljzd1.ch3.sourceforge.com>

Revision: 6487
          http://opensips.svn.sourceforge.net/opensips/?rev=6487&view=rev
Author:   sobomax
Date:     2010-01-04 12:26:41 +0000 (Mon, 04 Jan 2010)

Log Message:
-----------
Add dst_address property to the message object. It returns destination
address (ip, port) of the packet in question.

Modified Paths:
--------------
    trunk/modules/python/python_msgobj.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 Jan  4 16:10:37 2010
From: bogdan at voice-system.ro (Bogdan-Andrei Iancu)
Date: Mon, 04 Jan 2010 15:10:37 +0000
Subject: [OpenSIPS-Devel] SF.net SVN: opensips:[6488] trunk/modules/tm
Message-ID: <E1NRoZp-0002Nd-J2@c3vjzd1.ch3.sourceforge.com>

Revision: 6488
          http://opensips.svn.sourceforge.net/opensips/?rev=6488&view=rev
Author:   bogdan_iancu
Date:     2010-01-04 15:10:37 +0000 (Mon, 04 Jan 2010)

Log Message:
-----------
- fixed documentation (t_write_fifo -> t_write_req )
- fixed fixup function for t_write_XXX  (wrong param no).

Closes bug #2925298
Credits go to Richard Revels

Modified Paths:
--------------
    trunk/modules/tm/README
    trunk/modules/tm/doc/tm_admin.xml
    trunk/modules/tm/t_fifo.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 Jan  4 16:11:15 2010
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 04 Jan 2010 15:11:15 +0000
Subject: [OpenSIPS-Devel] [ opensips-Bugs-2925298 ] tm module socket write
	problems
Message-ID: <E1NRoaR-0001si-48@665xhf1.ch3.sourceforge.com>

Bugs item #2925298, was opened at 2010-01-03 20:19
Message generated for change (Comment added) made by bogdan_iancu
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=2925298&group_id=232389

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: modules
>Group: 1.6.x
Status: Open
>Resolution: Fixed
Priority: 5
Private: No
Submitted By: Richard Revels (rrevels)
>Assigned to: Bogdan-Andrei Iancu (bogdan_iancu)
Summary: tm module socket write problems

Initial Comment:
Found that the documentation refers to function as t_write_fifo but code exports function as t_write_req.

Function fixup_t_write (line 300 in t_fifo.c) checks param_no against 2 but should be checked for 1.

Function t_write_fifo fails with "t_get_trans_ident failed" on line 504 of t_fifo.c.

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

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

Message:
Hi Richard,

I fixed the docs t_write_fifo -> t_write_req (the web pages will be
updated over the night)

Also, you are right about the fixup function - it was fixing the wrong
param.

Regarding the "t_get_trans_ident failed" error, do you create the
transaction (from script via t_newtran) before running the t_write_req()
function ?

Thanks and Regards,
Bogdan

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

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


From bogdan at voice-system.ro  Mon Jan  4 16:11:38 2010
From: bogdan at voice-system.ro (Bogdan-Andrei Iancu)
Date: Mon, 04 Jan 2010 15:11:38 +0000
Subject: [OpenSIPS-Devel] SF.net SVN: opensips:[6490] branches/1.6/modules/tm
Message-ID: <E1NRoao-0002PW-34@c3vjzd1.ch3.sourceforge.com>

Revision: 6490
          http://opensips.svn.sourceforge.net/opensips/?rev=6490&view=rev
Author:   bogdan_iancu
Date:     2010-01-04 15:11:34 +0000 (Mon, 04 Jan 2010)

Log Message:
-----------
backport from trunk (rev #6488):
- fixed documentation (t_write_fifo -> t_write_req )
- fixed fixup function for t_write_XXX  (wrong param no).

Closes bug #2925298
Credits go to Richard Revels

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

Modified Paths:
--------------
    branches/1.6/modules/tm/README
    branches/1.6/modules/tm/doc/tm_admin.xml
    branches/1.6/modules/tm/t_fifo.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 Jan  4 16:11:38 2010
From: bogdan at voice-system.ro (Bogdan-Andrei Iancu)
Date: Mon, 04 Jan 2010 15:11:38 +0000
Subject: [OpenSIPS-Devel] SF.net SVN: opensips:[6489] branches/1.5/modules/tm
Message-ID: <E1NRoao-0002PX-3K@c3vjzd1.ch3.sourceforge.com>

Revision: 6489
          http://opensips.svn.sourceforge.net/opensips/?rev=6489&view=rev
Author:   bogdan_iancu
Date:     2010-01-04 15:11:30 +0000 (Mon, 04 Jan 2010)

Log Message:
-----------
backport from trunk (rev #6488):
- fixed documentation (t_write_fifo -> t_write_req )
- fixed fixup function for t_write_XXX  (wrong param no).

Closes bug #2925298
Credits go to Richard Revels

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

Modified Paths:
--------------
    branches/1.5/modules/tm/README
    branches/1.5/modules/tm/doc/tm_admin.xml
    branches/1.5/modules/tm/t_fifo.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 Jan  4 16:22:13 2010
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 04 Jan 2010 15:22:13 +0000
Subject: [OpenSIPS-Devel] [ opensips-Bugs-2923461 ] INVITE without Contact
	relayed
Message-ID: <E1NRol3-0006vz-8Y@b55xhf1.ch3.sourceforge.com>

Bugs item #2923461, was opened at 2009-12-30 13:28
Message generated for change (Comment added) made by bogdan_iancu
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=2923461&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: INVITE without Contact relayed

Initial Comment:
Hello.

I think, thath i have found a bug.

opensips recieve this message:
INVITE sip:1000085110 at 10.254.157.42:5060 SIP/2.0.
Record-Route: <sip:10.2.166.17;lr=on;ftag=861013891;vsf=AAAAAFVXVwMCCXVLWkchVx0BYS5ydQ-->.
Record-Route: <sip:[--IP-HERE--];lr=on;ftag=861013891>.
Via: SIP/2.0/UDP 10.2.166.17;branch=z9hG4bK2874.b998c896.0.
Via: SIP/2.0/UDP [--IP-HERE--];branch=z9hG4bK2874.8f3e33b6.0.
Via: SIP/2.0/UDP 10.254.157.104:5060;received=[--IP-HERE--];branch=z9hG4bK609371529;rport=14259.
Max-Forwards: 68.
From: "1000085253" <sip:dgg321@[--DOMAIN-HERE--]>;tag=861013891.
To: "anonymous" <sip:1000085110@[--DOMAIN-HERE--]>.
Call-ID: 3335133038 at 10.254.157.104.
Server: IMS Server 1.0.
User-Agent: IMS Client v0.001.
sip:[--DOMAIN-HERE--].
Supported: timer,replaces.
Allow: INVITE,ACK,CANCEL,BYE,SUBSCRIBE,NOTIFY,MESSAGE,INFO,UPDATE.
Accept-Contact: *;description="VT";explicit;require.
Session-Expires: 1800;refresher=uac.
CSeq: 2 INVITE.
Content-Type: application/sdp.
Content-Length: 232.
.
[--SDP-CUTTED--]

than this message was relayed to the client pointed in the Request URI, client answer with response:
SIP/2.0 400 Bad Request.
Via: SIP/2.0/UDP [--IP_HERE--];branch=z9hG4bK2874.9f3e33b6.0.
Via: SIP/2.0/UDP 10.2.166.17;branch=z9hG4bK2874.b998c896.0.
Via: SIP/2.0/UDP [--IP_HERE--];branch=z9hG4bK2874.8f3e33b6.0.
Via: SIP/2.0/UDP 10.254.157.104:5060;received=[--IP_HERE--];branch=z9hG4bK609371529;rport=14259.
Max-Forwards: 70.
From: ""1000085253"" <sip:dgg321@[--DOMAIN_HERE--]>;tag=861013891.
To: ""anonymous"" <sip:1000085110@[--DOMAIN_HERE--]>.
Call-ID: 3335133038 at 10.254.157.104.
CSeq: 2 INVITE.
Content-Length: 0.

but opensips still trying to retransmit initial invite to client...

First of all, in accordance with RFC3261 (Section 8.1.1.8) INVITE without "Contact" header must be rejected. 
I see, I can reject such message using configuration to check presentity of this header in INVITE message, but it would be better when it will be done thru the parser/tm modules by opensips.

Second is the question: why opensips try to retransmit initial INVITE when response was already recieved.

version: opensips 1.5.3-notls (x86_64/linux)
flags: STATS: Off, USE_IPV6, USE_TCP, DISABLE_NAGLE, USE_MCAST, SHM_MEM, SHM_MMAP, PKG_MALLOC, F_MALLOC, FAST_LOCK-ADAPTIVE_WAIT
ADAPTIVE_WAIT_LOOPS=1024, MAX_RECV_BUFFER_SIZE 262144, MAX_LISTEN 16, MAX_URI_SIZE 1024, BUF_SIZE 65535
poll method support: poll, epoll_lt, epoll_et, sigio_rt, select.
svnrevision: 4:921M
@(#) $Id: main.c 5887 2009-07-16 11:47:46Z bogdan_iancu $
main.c compiled on 18:10:15 Dec 29 2009 with gcc 4.1.2


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

>Comment By: Bogdan-Andrei Iancu (bogdan_iancu)
Date: 2010-01-04 17:22

Message:
Hi Alexey ,

For the first issue, contact related, if you want to do some very advanced
sanity checks, you need to do them explicitly from the script. OpenSIPS is
checking by default just the syntax part and the elements it is interested
in.

Now, about the 400 reply and retransmission...Are you sure OpenSIPS is
receiving the 400 reply? can you run in full debug (debug=6) and post the
part corresponding the reply processing ?

Regards,
Bogdan

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

Comment By: Alexey Nikolaev (iamthedeath)
Date: 2009-12-30 13:29

Message:
Forget to login. This is my issue.

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

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


From bogdan at voice-system.ro  Mon Jan  4 16:25:01 2010
From: bogdan at voice-system.ro (Bogdan-Andrei Iancu)
Date: Mon, 04 Jan 2010 15:25:01 +0000
Subject: [OpenSIPS-Devel] SF.net SVN: opensips:[6491]
	trunk/modules/load_balancer/lb_db.c
Message-ID: <E1NRonl-0002i1-61@c3vjzd1.ch3.sourceforge.com>

Revision: 6491
          http://opensips.svn.sourceforge.net/opensips/?rev=6491&view=rev
Author:   bogdan_iancu
Date:     2010-01-04 15:24:59 +0000 (Mon, 04 Jan 2010)

Log Message:
-----------
- fixed bug in improper handling of probing mode 1.
  Reported by Bill W.

Modified Paths:
--------------
    trunk/modules/load_balancer/lb_db.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 Jan  4 16:25:42 2010
From: bogdan at voice-system.ro (Bogdan-Andrei Iancu)
Date: Mon, 04 Jan 2010 15:25:42 +0000
Subject: [OpenSIPS-Devel] SF.net SVN: opensips:[6492]
	branches/1.6/modules/load_balancer/lb_db.c
Message-ID: <E1NRooQ-0002if-Ew@c3vjzd1.ch3.sourceforge.com>

Revision: 6492
          http://opensips.svn.sourceforge.net/opensips/?rev=6492&view=rev
Author:   bogdan_iancu
Date:     2010-01-04 15:25:42 +0000 (Mon, 04 Jan 2010)

Log Message:
-----------
backport from trunk (rev #6491):
- fixed bug in improper handling of probing mode 1.
  Reported by Bill W.

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

Modified Paths:
--------------
    branches/1.6/modules/load_balancer/lb_db.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 Jan  4 16:27:56 2010
From: bogdan at voice-system.ro (Bogdan-Andrei Iancu)
Date: Mon, 04 Jan 2010 15:27:56 +0000
Subject: [OpenSIPS-Devel] SF.net SVN: opensips:[6493]
	trunk/modules/dialog/dlg_handlers.c
Message-ID: <E1NRoqa-0002lU-OB@c3vjzd1.ch3.sourceforge.com>

Revision: 6493
          http://opensips.svn.sourceforge.net/opensips/?rev=6493&view=rev
Author:   bogdan_iancu
Date:     2010-01-04 15:27:53 +0000 (Mon, 04 Jan 2010)

Log Message:
-----------
- added some more info in error report.

Modified Paths:
--------------
    trunk/modules/dialog/dlg_handlers.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 Jan  4 16:28:13 2010
From: bogdan at voice-system.ro (Bogdan-Andrei Iancu)
Date: Mon, 04 Jan 2010 15:28:13 +0000
Subject: [OpenSIPS-Devel] SF.net SVN: opensips:[6494]
	branches/1.6/modules/dialog/dlg_handlers.c
Message-ID: <E1NRoqr-0002m5-RV@c3vjzd1.ch3.sourceforge.com>

Revision: 6494
          http://opensips.svn.sourceforge.net/opensips/?rev=6494&view=rev
Author:   bogdan_iancu
Date:     2010-01-04 15:28:13 +0000 (Mon, 04 Jan 2010)

Log Message:
-----------
- added some more info in error report.

Modified Paths:
--------------
    branches/1.6/modules/dialog/dlg_handlers.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 Jan  4 16:46:17 2010
From: bogdan at voice-system.ro (Bogdan-Andrei Iancu)
Date: Mon, 04 Jan 2010 15:46:17 +0000
Subject: [OpenSIPS-Devel] SF.net SVN: opensips:[6495]
	trunk/parser/msg_parser.h
Message-ID: <E1NRp8L-0003AQ-AH@c3vjzd1.ch3.sourceforge.com>

Revision: 6495
          http://opensips.svn.sourceforge.net/opensips/?rev=6495&view=rev
Author:   bogdan_iancu
Date:     2010-01-04 15:46:17 +0000 (Mon, 04 Jan 2010)

Log Message:
-----------
- just spacing 

Modified Paths:
--------------
    trunk/parser/msg_parser.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 Jan  4 16:46:52 2010
From: bogdan at voice-system.ro (Bogdan-Andrei Iancu)
Date: Mon, 04 Jan 2010 15:46:52 +0000
Subject: [OpenSIPS-Devel] SF.net SVN: opensips:[6496]
	branches/1.6/parser/msg_parser.h
Message-ID: <E1NRp8u-0003BK-1e@c3vjzd1.ch3.sourceforge.com>

Revision: 6496
          http://opensips.svn.sourceforge.net/opensips/?rev=6496&view=rev
Author:   bogdan_iancu
Date:     2010-01-04 15:46:51 +0000 (Mon, 04 Jan 2010)

Log Message:
-----------
-just spacing

Modified Paths:
--------------
    branches/1.6/parser/msg_parser.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 Jan  4 16:49:34 2010
From: bogdan at voice-system.ro (Bogdan-Andrei Iancu)
Date: Mon, 04 Jan 2010 15:49:34 +0000
Subject: [OpenSIPS-Devel] SF.net SVN: opensips:[6497] trunk/Makefile.defs
Message-ID: <E1NRpBW-0003Eo-12@c3vjzd1.ch3.sourceforge.com>

Revision: 6497
          http://opensips.svn.sourceforge.net/opensips/?rev=6497&view=rev
Author:   bogdan_iancu
Date:     2010-01-04 15:49:33 +0000 (Mon, 04 Jan 2010)

Log Message:
-----------
- fixed detection for gcc params on OSX (arch related)
  Reported by Norman Brandinger
  Closes bug #2911660

Modified Paths:
--------------
    trunk/Makefile.defs


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 Jan  4 17:00:56 2010
From: bogdan at voice-system.ro (Bogdan-Andrei Iancu)
Date: Mon, 04 Jan 2010 16:00:56 +0000
Subject: [OpenSIPS-Devel] SF.net SVN: opensips:[6498]
	branches/1.6/Makefile.defs
Message-ID: <E1NRpMW-0003X8-33@c3vjzd1.ch3.sourceforge.com>

Revision: 6498
          http://opensips.svn.sourceforge.net/opensips/?rev=6498&view=rev
Author:   bogdan_iancu
Date:     2010-01-04 16:00:55 +0000 (Mon, 04 Jan 2010)

Log Message:
-----------
backport from trunk (rev #6497)
- fixed detection for gcc params on OSX (arch related)
  Reported by Norman Brandinger
  Closes bug #2911660

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

Modified Paths:
--------------
    branches/1.6/Makefile.defs


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 Jan  4 17:01:08 2010
From: bogdan at voice-system.ro (Bogdan-Andrei Iancu)
Date: Mon, 04 Jan 2010 16:01:08 +0000
Subject: [OpenSIPS-Devel] SF.net SVN: opensips:[6499]
	branches/1.5/Makefile.defs
Message-ID: <E1NRpMi-0003XT-OE@c3vjzd1.ch3.sourceforge.com>

Revision: 6499
          http://opensips.svn.sourceforge.net/opensips/?rev=6499&view=rev
Author:   bogdan_iancu
Date:     2010-01-04 16:01:08 +0000 (Mon, 04 Jan 2010)

Log Message:
-----------
backport from trunk (rev #6497)
- fixed detection for gcc params on OSX (arch related)
  Reported by Norman Brandinger
  Closes bug #2911660

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

Modified Paths:
--------------
    branches/1.5/Makefile.defs


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


From noreply at sourceforge.net  Mon Jan  4 17:01:41 2010
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 04 Jan 2010 16:01:41 +0000
Subject: [OpenSIPS-Devel] [ opensips-Bugs-2911660 ] OpenSIPS fails to
	compile on OSX
Message-ID: <E1NRpNF-0008WL-6Z@d55xhf1.ch3.sourceforge.com>

Bugs item #2911660, was opened at 2009-12-09 23:59
Message generated for change (Comment added) made by bogdan_iancu
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=2911660&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: trunk
>Status: Closed
>Resolution: Fixed
Priority: 5
Private: No
Submitted By: Norm Brandinger (norm_brandinger)
Assigned to: Bogdan-Andrei Iancu (bogdan_iancu)
Summary: OpenSIPS fails to compile on OSX

Initial Comment:
Trying to MAKE OpenSIPS on OSX (Snow Leopard)
MacBookPro Intel Core 2 Duo
Darwin Kernel Version 10.2.0: Tue Nov  3 10:37:10 PST 2009; root:xnu-1486.2.11~1/RELEASE_I386 i386 i386

Produces the following:

yacc -d -b cfg cfg.y
conflicts: 1 shift/reduce
flex cfg.lex
New SVN revision: 2:6382
Compiling action.c
gcc  -g -O9 -funroll-loops  -Wcast-align  -Wall  -minline-all-stringops -falign-loops -ftree-vectorize -mtune=prescott -Wold-style-definition -Wmissing-field-initializers -Wredundant-decls     -DNAME='"opensips"' -DVERSION='"1.6.1-notls"' -DARCH='"i386"' -DOS='"darwin"' -DCOMPILER='"gcc 4.2.1"' -D__CPU_i386 -D__OS_darwin -D__SMP_no -DCFG_DIR='"/usr/local/etc/opensips/"' -DPKG_MALLOC -DSHM_MEM  -DSHM_MMAP -DUSE_IPV6 -DUSE_MCAST -DUSE_TCP -DDISABLE_NAGLE -DHAVE_RESOLV_RES -DSTATISTICS -DCHANGEABLE_DEBUG_LEVEL -DF_MALLOC  -DSVNREVISION='"2:6382"'  -DFAST_LOCK -DADAPTIVE_WAIT -DADAPTIVE_WAIT_LOOPS=1024  -DHAVE_SOCKADDR_SA_LEN -DHAVE_GETHOSTBYNAME2 -DHAVE_UNION_SEMUN -DHAVE_SCHED_YIELD -DHAVE_MSGHDR_MSG_CONTROL -DUSE_ANON_MMAP -DNDEBUG -DHAVE_CONNECT_ECONNRESET_BUG -DHAVE_TIMEGM -DHAVE_KQUEUE -DHAVE_SELECT -c action.c -o action.o
action.c:1: error: CPU you selected does not support x86-64 instruction set
make: *** [action.o] Error 1

The attached patch corrects this problem.

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

>Comment By: Bogdan-Andrei Iancu (bogdan_iancu)
Date: 2010-01-04 18:01

Message:
patch uploaded

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

Comment By: Bogdan-Andrei Iancu (bogdan_iancu)
Date: 2009-12-11 20:54

Message:
Could you try the new patch please ?

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

Comment By: Norm Brandinger (norm_brandinger)
Date: 2009-12-11 13:35

Message:
uname -m returns i386

Tried using i386 previously and the compile error remained.  Perhaps a new
test for this environment should be considered.

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

Comment By: Bogdan-Andrei Iancu (bogdan_iancu)
Date: 2009-12-11 11:19

Message:
the patch is a bit to intrusive - you downgrade the CPU tuning for all i386
like arch.

What does "uname -m" returns on your machine?

Thanks and regards,
Bogdan

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

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


From noreply at sourceforge.net  Mon Jan  4 17:04:34 2010
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 04 Jan 2010 16:04:34 +0000
Subject: [OpenSIPS-Devel] [ opensips-Bugs-2897651 ] config.h parameters not
	reflecting
Message-ID: <E1NRpQ2-0007TK-5p@d45xhf1.ch3.sourceforge.com>

Bugs item #2897651, was opened at 2009-11-14 14:08
Message generated for change (Settings changed) made by bogdan_iancu
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=2897651&group_id=232389

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: core
Group: None
>Status: Closed
Resolution: Invalid
Priority: 2
Private: No
Submitted By: Himal Rana (ranahimal)
Assigned to: Bogdan-Andrei Iancu (bogdan_iancu)
Summary: config.h parameters not reflecting

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

Version  tested : 1.5.X  , 1.6.0

OS : RHEL 5.4 Fedora  11 Centos 5.4

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

>Comment By: Bogdan-Andrei Iancu (bogdan_iancu)
Date: 2010-01-04 18:04

Message:
please reopen if you have some more relevant input.

Regards,
Bogdan

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

Comment By: Bogdan-Andrei Iancu (bogdan_iancu)
Date: 2009-12-11 13:54

Message:
any input ?

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

Comment By: Bogdan-Andrei Iancu (bogdan_iancu)
Date: 2009-11-30 11:53

Message:
So, you changed the PKG_MEM_POOL_SIZE & SHM_MEM_SIZE in config.h and
recompiled (make all) opensips ....how do you check after that to see if
the new values do reflect ?

Regards,
Bogdan

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

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

Message:
Dear Bogdan,

I was complie using following shell command.

make all



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

Comment By: Himal Rana (ranahimal)
Date: 2009-11-16 20:14

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

PKG_MEM_POOL_SIZE
SHM_MEM_SIZE

Thanks,
Himal 

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

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

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

Regards,
Bogdan

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

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


From noreply at sourceforge.net  Mon Jan  4 18:31:36 2010
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 04 Jan 2010 17:31:36 +0000
Subject: [OpenSIPS-Devel] [ opensips-Bugs-2925298 ] tm module socket write
	problems
Message-ID: <E1NRqmG-0006ps-C2@1bkjzd1.ch3.sourceforge.com>

Bugs item #2925298, was opened at 2010-01-03 18:19
Message generated for change (Comment added) made by rrevels
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=2925298&group_id=232389

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: modules
Group: 1.6.x
Status: Open
Resolution: Fixed
Priority: 5
Private: No
Submitted By: Richard Revels (rrevels)
Assigned to: Bogdan-Andrei Iancu (bogdan_iancu)
Summary: tm module socket write problems

Initial Comment:
Found that the documentation refers to function as t_write_fifo but code exports function as t_write_req.

Function fixup_t_write (line 300 in t_fifo.c) checks param_no against 2 but should be checked for 1.

Function t_write_fifo fails with "t_get_trans_ident failed" on line 504 of t_fifo.c.

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

>Comment By: Richard Revels (rrevels)
Date: 2010-01-04 17:31

Message:
Well no.  I wasn't.  For some reason I was thinking that calling
create_dialog() would have the side effect of also creating the
transaction.  Now that I am calling t_newtran() I am no longer getting the
error looking up the transaction.  I am getting a "buffer overflow while
copying command name" now but I need to make sure that isn't being caused
by any code changes I made earlier.  Thank you for your assistance!

Richard
  

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

Comment By: Bogdan-Andrei Iancu (bogdan_iancu)
Date: 2010-01-04 15:11

Message:
Hi Richard,

I fixed the docs t_write_fifo -> t_write_req (the web pages will be
updated over the night)

Also, you are right about the fixup function - it was fixing the wrong
param.

Regarding the "t_get_trans_ident failed" error, do you create the
transaction (from script via t_newtran) before running the t_write_req()
function ?

Thanks and Regards,
Bogdan

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

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


From anca at opensips.org  Mon Jan  4 19:33:29 2010
From: anca at opensips.org (Anca Vamanu)
Date: Mon, 04 Jan 2010 18:33:29 +0000
Subject: [OpenSIPS-Devel] SF.net SVN: opensips:[6500]
	trunk/modules/b2b_entities/dlg.c
Message-ID: <E1NRrk9-0004PU-Uc@3kljzd1.ch3.sourceforge.com>

Revision: 6500
          http://opensips.svn.sourceforge.net/opensips/?rev=6500&view=rev
Author:   anca_vamanu
Date:     2010-01-04 18:33:29 +0000 (Mon, 04 Jan 2010)

Log Message:
-----------
- fixed copy paste error
- fixed not printing the record route in reverse order when learned from reply
- fixed wrong check when matching b2b requests( checked the source ip)

Modified Paths:
--------------
    trunk/modules/b2b_entities/dlg.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 Jan  4 19:51:13 2010
From: anca at opensips.org (Anca Vamanu)
Date: Mon, 04 Jan 2010 18:51:13 +0000
Subject: [OpenSIPS-Devel] SF.net SVN: opensips:[6501]
	branches/1.6/modules/b2b_entities/dlg.c
Message-ID: <E1NRs1J-0004fY-Qo@3kljzd1.ch3.sourceforge.com>

Revision: 6501
          http://opensips.svn.sourceforge.net/opensips/?rev=6501&view=rev
Author:   anca_vamanu
Date:     2010-01-04 18:51:13 +0000 (Mon, 04 Jan 2010)

Log Message:
-----------
- fixed copy paste error
- fixed not printing the record route in reverse order when learned from reply
- fixed wrong check when matching b2b requests( checked the source ip)

Modified Paths:
--------------
    branches/1.6/modules/b2b_entities/dlg.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 Jan  5 15:07:00 2010
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue, 05 Jan 2010 14:07:00 +0000
Subject: [OpenSIPS-Devel] [ opensips-Bugs-2925298 ] tm module socket write
	problems
Message-ID: <E1NSA3o-00017C-Vr@155xhf1.ch3.sourceforge.com>

Bugs item #2925298, was opened at 2010-01-03 20:19
Message generated for change (Comment added) made by bogdan_iancu
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=2925298&group_id=232389

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: modules
Group: 1.6.x
>Status: Closed
Resolution: Fixed
Priority: 5
Private: No
Submitted By: Richard Revels (rrevels)
Assigned to: Bogdan-Andrei Iancu (bogdan_iancu)
Summary: tm module socket write problems

Initial Comment:
Found that the documentation refers to function as t_write_fifo but code exports function as t_write_req.

Function fixup_t_write (line 300 in t_fifo.c) checks param_no against 2 but should be checked for 1.

Function t_write_fifo fails with "t_get_trans_ident failed" on line 504 of t_fifo.c.

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

>Comment By: Bogdan-Andrei Iancu (bogdan_iancu)
Date: 2010-01-05 16:07

Message:
OK - if there any other related issues, please reopen the report or create
a new one.

Thanks and regards,
Bogdan

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

Comment By: Richard Revels (rrevels)
Date: 2010-01-04 19:31

Message:
Well no.  I wasn't.  For some reason I was thinking that calling
create_dialog() would have the side effect of also creating the
transaction.  Now that I am calling t_newtran() I am no longer getting the
error looking up the transaction.  I am getting a "buffer overflow while
copying command name" now but I need to make sure that isn't being caused
by any code changes I made earlier.  Thank you for your assistance!

Richard
  

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

Comment By: Bogdan-Andrei Iancu (bogdan_iancu)
Date: 2010-01-04 17:11

Message:
Hi Richard,

I fixed the docs t_write_fifo -> t_write_req (the web pages will be
updated over the night)

Also, you are right about the fixup function - it was fixing the wrong
param.

Regarding the "t_get_trans_ident failed" error, do you create the
transaction (from script via t_newtran) before running the t_write_req()
function ?

Thanks and Regards,
Bogdan

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

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


From noreply at sourceforge.net  Tue Jan  5 15:07:47 2010
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue, 05 Jan 2010 14:07:47 +0000
Subject: [OpenSIPS-Devel] [ opensips-Bugs-2889312 ] is_dlg_flag_set does not
	really checking the flag (ver1.5.3)
Message-ID: <E1NSA4Z-0000X8-9o@665xhf1.ch3.sourceforge.com>

Bugs item #2889312, was opened at 2009-10-30 11:01
Message generated for change (Settings changed) made by bogdan_iancu
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=2889312&group_id=232389

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: modules
Group: 1.5.x
>Status: Closed
Resolution: Invalid
Priority: 5
Private: No
Submitted By: Alexey Nikolaev (iamthedeath)
Assigned to: Bogdan-Andrei Iancu (bogdan_iancu)
Summary: is_dlg_flag_set does not really checking the flag (ver1.5.3)

Initial Comment:
Hello.

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

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

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

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

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

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

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


Is this my misunderstanding or i should report a bug?

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

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

Message:
Hi Alexey,

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

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

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

Regards,
Bogdan

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

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

Message:
I research the problem again.

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


So i have two questions

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

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

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

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

Regards.
Alexey.

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

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

Message:
Hi, Bogdan.

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

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

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

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

Message:
Hi,

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

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

Regards,
Bogdan

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

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


From bogdan at voice-system.ro  Tue Jan  5 15:11:42 2010
From: bogdan at voice-system.ro (Bogdan-Andrei Iancu)
Date: Tue, 05 Jan 2010 14:11:42 +0000
Subject: [OpenSIPS-Devel] SF.net SVN: opensips:[6502] trunk/modules/stun
Message-ID: <E1NSA8M-0001Gx-BR@dn4whf1.ch3.sourceforge.com>

Revision: 6502
          http://opensips.svn.sourceforge.net/opensips/?rev=6502&view=rev
Author:   bogdan_iancu
Date:     2010-01-05 14:11:40 +0000 (Tue, 05 Jan 2010)

Log Message:
-----------
-fixed bogus example in docs for alternate_ip param.
 Credits go to Ha Do

Modified Paths:
--------------
    trunk/modules/stun/README
    trunk/modules/stun/doc/stun_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 Jan  5 15:12:04 2010
From: bogdan at voice-system.ro (Bogdan-Andrei Iancu)
Date: Tue, 05 Jan 2010 14:12:04 +0000
Subject: [OpenSIPS-Devel] SF.net SVN: opensips:[6503]
	branches/1.6/modules/stun
Message-ID: <E1NSA8i-0001IH-1W@dn4whf1.ch3.sourceforge.com>

Revision: 6503
          http://opensips.svn.sourceforge.net/opensips/?rev=6503&view=rev
Author:   bogdan_iancu
Date:     2010-01-05 14:12:03 +0000 (Tue, 05 Jan 2010)

Log Message:
-----------
backport from trunk (rev 6502):
-fixed bogus example in docs for alternate_ip param.
 Credits go to Ha Do

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

Modified Paths:
--------------
    branches/1.6/modules/stun/README
    branches/1.6/modules/stun/doc/stun_admin.xml


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


From saul at ag-projects.com  Tue Jan  5 20:12:42 2010
From: saul at ag-projects.com (=?UTF-8?B?U2HDumwgSWJhcnJhIENvcnJldGfDqQ==?=)
Date: Tue, 05 Jan 2010 20:12:42 +0100
Subject: [OpenSIPS-Devel] [patch] pseudo-variable support for append_branch
Message-ID: <4B438F2A.4080108@ag-projects.com>

Hi Bogdan and all,

While testing I realized that append_branch function doesn't currently 
support pseudo-variables as the URI parameter.

The attached patch adds support for this. I tested it with OpenSIPS 1.4, 
and AFAIS append_branch function hasn't change since then so it should 
work the same way in trunk (I can test it tomorrow if needed).

If you find the patch appropriate, please consider it for inclusion, I 
thought it could be useful :)


Best regards,



-- 
Sa?l Ibarra Corretg?
AG Projects
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: append_branches-pv.patch
Url: http://lists.opensips.org/pipermail/devel/attachments/20100105/1ec39099/attachment.txt 

From bogdan at voice-system.ro  Wed Jan  6 13:44:08 2010
From: bogdan at voice-system.ro (Bogdan-Andrei Iancu)
Date: Wed, 06 Jan 2010 14:44:08 +0200
Subject: [OpenSIPS-Devel] [patch] pseudo-variable support for
	append_branch
In-Reply-To: <4B438F2A.4080108@ag-projects.com>
References: <4B438F2A.4080108@ag-projects.com>
Message-ID: <4B448598.1080503@voice-system.ro>

Hi Sa?l,

The reason why the function does not accept variables as params is 
because you can do the same op (adding new branch) using other 
functions/vars:

1) avp_pushto()
          
http://www.opensips.org/html/docs/modules/devel/avpops.html#id271214

2) $branch
          http://www.opensips.org/Resources/DocsCoreVar16#toc13

Options 1) is available in 1.4 also.

Regards,
Bogdan

Sa?l Ibarra Corretg? wrote:
> Hi Bogdan and all,
>
> While testing I realized that append_branch function doesn't currently 
> support pseudo-variables as the URI parameter.
>
> The attached patch adds support for this. I tested it with OpenSIPS 
> 1.4, and AFAIS append_branch function hasn't change since then so it 
> should work the same way in trunk (I can test it tomorrow if needed).
>
> If you find the patch appropriate, please consider it for inclusion, I 
> thought it could be useful :)
>
>
> Best regards,
>
>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> Devel mailing list
> Devel at lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/devel


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



From saul at ag-projects.com  Wed Jan  6 14:46:37 2010
From: saul at ag-projects.com (=?UTF-8?B?U2HDumwgSWJhcnJhIENvcnJldGfDqQ==?=)
Date: Wed, 06 Jan 2010 14:46:37 +0100
Subject: [OpenSIPS-Devel] [patch] pseudo-variable support
	for	append_branch
In-Reply-To: <4B448598.1080503@voice-system.ro>
References: <4B438F2A.4080108@ag-projects.com>
	<4B448598.1080503@voice-system.ro>
Message-ID: <4B44943D.7080603@ag-projects.com>

Hi Bogdan,

On 6/1/10 1:44 PM, Bogdan-Andrei Iancu wrote:
> Hi Sa?l,
>
> The reason why the function does not accept variables as params is
> because you can do the same op (adding new branch) using other
> functions/vars:
>
> 1) avp_pushto()
>
> http://www.opensips.org/html/docs/modules/devel/avpops.html#id271214
>
> 2) $branch
>            http://www.opensips.org/Resources/DocsCoreVar16#toc13
>
> Options 1) is available in 1.4 also.
>

Thanks for the pointers, I didn't know about this other ways of doing it. :)


Regards,

-- 
Sa?l Ibarra Corretg?
AG Projects


From noreply at sourceforge.net  Thu Jan  7 03:29:52 2010
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 07 Jan 2010 02:29:52 +0000
Subject: [OpenSIPS-Devel] [ opensips-Bugs-2927295 ] tm module socket write
	problems
Message-ID: <E1NSi8G-0003XU-PD@h45xhf1.ch3.sourceforge.com>

Bugs item #2927295, was opened at 2010-01-07 02:29
Message generated for change (Tracker Item Submitted) made by rrevels
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=2927295&group_id=232389

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: modules
Group: 1.6.x
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Richard Revels (rrevels)
Assigned to: Nobody/Anonymous (nobody)
Summary: tm module socket write problems

Initial Comment:
Yes there is still a problem in t_fifo.c but I couldn't figure out how to re-open the last tracker.  The parameters declared for t_write_req are vm_fifo and info but the pointers passed to the function are reversed.  It looks like t_write_unix has the same problem.  I fixed the this by swapping the variable names passed to assemble_msg and write_to_fifo but I suspect this isn't the best way to resolve the problem.

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

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


From anca at opensips.org  Thu Jan  7 16:57:47 2010
From: anca at opensips.org (Anca Vamanu)
Date: Thu, 07 Jan 2010 15:57:47 +0000
Subject: [OpenSIPS-Devel] SF.net SVN: opensips:[6504] trunk/modules
Message-ID: <E1NSuk7-0000Bd-12@c3vjzd1.ch3.sourceforge.com>

Revision: 6504
          http://opensips.svn.sourceforge.net/opensips/?rev=6504&view=rev
Author:   anca_vamanu
Date:     2010-01-07 15:57:46 +0000 (Thu, 07 Jan 2010)

Log Message:
-----------
- removed the URI encoding mechanism from the XMPP gateway(now the gateway is transparent)
- added a parameter: sip_domain representing the SIP domain advertised in XMPP)

Modified Paths:
--------------
    trunk/modules/pua_xmpp/pua_xmpp.c
    trunk/modules/pua_xmpp/pua_xmpp.h
    trunk/modules/pua_xmpp/simple2xmpp.c
    trunk/modules/pua_xmpp/xmpp2simple.c
    trunk/modules/xmpp/README
    trunk/modules/xmpp/doc/xmpp_admin.xml
    trunk/modules/xmpp/util.c
    trunk/modules/xmpp/xmpp.c
    trunk/modules/xmpp/xmpp.h
    trunk/modules/xmpp/xmpp_api.c
    trunk/modules/xmpp/xmpp_api.h
    trunk/modules/xmpp/xmpp_component.c
    trunk/modules/xmpp/xmpp_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 Jan  8 10:51:24 2010
From: bogdan at voice-system.ro (Bogdan-Andrei Iancu)
Date: Fri, 08 Jan 2010 09:51:24 +0000
Subject: [OpenSIPS-Devel] SF.net SVN: opensips:[6505] trunk/modules/tm
Message-ID: <E1NTBV6-0003nK-Kn@3kljzd1.ch3.sourceforge.com>

Revision: 6505
          http://opensips.svn.sourceforge.net/opensips/?rev=6505&view=rev
Author:   bogdan_iancu
Date:     2010-01-08 09:51:24 +0000 (Fri, 08 Jan 2010)

Log Message:
-----------
- fixed wrong order of param for t_write_req() and t_write_unix()
  Credits go to Richard Revels 
  Closes bug #2927295

Modified Paths:
--------------
    trunk/modules/tm/t_fifo.c
    trunk/modules/tm/t_fifo.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 Jan  8 10:52:59 2010
From: bogdan at voice-system.ro (Bogdan-Andrei Iancu)
Date: Fri, 08 Jan 2010 09:52:59 +0000
Subject: [OpenSIPS-Devel] SF.net SVN: opensips:[6506] branches/1.6/modules/tm
Message-ID: <E1NTBWd-0003nu-Fh@3kljzd1.ch3.sourceforge.com>

Revision: 6506
          http://opensips.svn.sourceforge.net/opensips/?rev=6506&view=rev
Author:   bogdan_iancu
Date:     2010-01-08 09:52:59 +0000 (Fri, 08 Jan 2010)

Log Message:
-----------
backport from trunk (rev #6505):
- fixed wrong order of param for t_write_req() and t_write_unix()
  Credits go to Richard Revels 
  Closes bug #2927295

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

Modified Paths:
--------------
    branches/1.6/modules/tm/t_fifo.c
    branches/1.6/modules/tm/t_fifo.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 Jan  8 10:53:01 2010
From: bogdan at voice-system.ro (Bogdan-Andrei Iancu)
Date: Fri, 08 Jan 2010 09:53:01 +0000
Subject: [OpenSIPS-Devel] SF.net SVN: opensips:[6507] branches/1.5/modules/tm
Message-ID: <E1NTBWf-0003o8-NB@3kljzd1.ch3.sourceforge.com>

Revision: 6507
          http://opensips.svn.sourceforge.net/opensips/?rev=6507&view=rev
Author:   bogdan_iancu
Date:     2010-01-08 09:53:01 +0000 (Fri, 08 Jan 2010)

Log Message:
-----------
backport from trunk (rev #6505):
- fixed wrong order of param for t_write_req() and t_write_unix()
  Credits go to Richard Revels
  Closes bug #2927295

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

Modified Paths:
--------------
    branches/1.5/modules/tm/t_fifo.c
    branches/1.5/modules/tm/t_fifo.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 Jan  8 10:54:20 2010
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 08 Jan 2010 09:54:20 +0000
Subject: [OpenSIPS-Devel] [ opensips-Bugs-2927295 ] tm module socket write
	problems
Message-ID: <E1NTBXw-0007uZ-Q8@cdv4jf1.ch3.sourceforge.com>

Bugs item #2927295, was opened at 2010-01-07 04:29
Message generated for change (Settings changed) made by bogdan_iancu
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=2927295&group_id=232389

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: modules
Group: 1.6.x
Status: Open
>Resolution: Fixed
Priority: 5
Private: No
Submitted By: Richard Revels (rrevels)
>Assigned to: Bogdan-Andrei Iancu (bogdan_iancu)
Summary: tm module socket write problems

Initial Comment:
Yes there is still a problem in t_fifo.c but I couldn't figure out how to re-open the last tracker.  The parameters declared for t_write_req are vm_fifo and info but the pointers passed to the function are reversed.  It looks like t_write_unix has the same problem.  I fixed the this by swapping the variable names passed to assemble_msg and write_to_fifo but I suspect this isn't the best way to resolve the problem.

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

>Comment By: Bogdan-Andrei Iancu (bogdan_iancu)
Date: 2010-01-08 11:53

Message:
Indeed the two params were swapped . I fixed this on SVN - could you please
test it to see if it works now ?

Thanks and regards,
Bogdan

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

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


From noreply at sourceforge.net  Fri Jan  8 14:33:09 2010
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 08 Jan 2010 13:33:09 +0000
Subject: [OpenSIPS-Devel] [ opensips-Bugs-2928267 ] infloop due to bad
	linkedlist traversal
Message-ID: <E1NTExh-0000K9-M9@1bkjzd1.ch3.sourceforge.com>

Bugs item #2928267, was opened at 2010-01-08 14:33
Message generated for change (Tracker Item Submitted) made by wdoekes
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=2928267&group_id=232389

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: core
Group: 1.6.x
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Walter Doekes (wdoekes)
Assigned to: Nobody/Anonymous (nobody)
Summary: infloop due to bad linkedlist traversal

Initial Comment:
Due to a cause unknown to me, opensips 1.6.0/1 hangs.

Gdb tells me:
0x0808292a <pv_get_hdr+1242>:	lea    0x0(%esi),%esi
0x08082930 <pv_get_hdr+1248>:	jmp    0x808292a <pv_get_hdr+1242>

1966				/* it is an un-known header -> use name to find it */
1967				for (hf0=hf->next; hf0; hf=hf0->next) {
1968					if (hf0->type==HDR_OTHER_T && hf0->name.len==tv.rs.len

That hf=hf0->next should probably be hf0=hf0->next.

Patch attached.

Regards,
Walter Doekes
OSSO B.V.

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

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


From bogdan at voice-system.ro  Fri Jan  8 18:44:23 2010
From: bogdan at voice-system.ro (Bogdan-Andrei Iancu)
Date: Fri, 08 Jan 2010 17:44:23 +0000
Subject: [OpenSIPS-Devel] SF.net SVN: opensips:[6508] trunk/pvar.c
Message-ID: <E1NTIsp-00087N-Jv@c3vjzd1.ch3.sourceforge.com>

Revision: 6508
          http://opensips.svn.sourceforge.net/opensips/?rev=6508&view=rev
Author:   bogdan_iancu
Date:     2010-01-08 17:44:21 +0000 (Fri, 08 Jan 2010)

Log Message:
-----------
-fixed infinit loop doe bogus iteration.
 Credits go to Walter Doekes
 Closes bug #2928267.

Modified Paths:
--------------
    trunk/pvar.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 Jan  8 18:46:55 2010
From: bogdan at voice-system.ro (Bogdan-Andrei Iancu)
Date: Fri, 08 Jan 2010 17:46:55 +0000
Subject: [OpenSIPS-Devel] SF.net SVN: opensips:[6509] branches/1.6/pvar.c
Message-ID: <E1NTIvH-0008Bq-Ey@c3vjzd1.ch3.sourceforge.com>

Revision: 6509
          http://opensips.svn.sourceforge.net/opensips/?rev=6509&view=rev
Author:   bogdan_iancu
Date:     2010-01-08 17:46:55 +0000 (Fri, 08 Jan 2010)

Log Message:
-----------
backport from trunk (rev #6508)
-fixed infinit loop doe bogus iteration.
 Credits go to Walter Doekes
 Closes bug #2928267.

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

Modified Paths:
--------------
    branches/1.6/pvar.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 Jan  8 18:54:10 2010
From: bogdan at voice-system.ro (Bogdan-Andrei Iancu)
Date: Fri, 08 Jan 2010 17:54:10 +0000
Subject: [OpenSIPS-Devel] SF.net SVN: opensips:[6510] branches/1.5/pvar.c
Message-ID: <E1NTJ2I-0008Lv-8Y@c3vjzd1.ch3.sourceforge.com>

Revision: 6510
          http://opensips.svn.sourceforge.net/opensips/?rev=6510&view=rev
Author:   bogdan_iancu
Date:     2010-01-08 17:54:09 +0000 (Fri, 08 Jan 2010)

Log Message:
-----------
backport from trunk (rev #6508)
-fixed infinit loop doe bogus iteration.
 Credits go to Walter Doekes
 Closes bug #2928267.

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

Modified Paths:
--------------
    branches/1.5/pvar.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 Jan  8 18:54:38 2010
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 08 Jan 2010 17:54:38 +0000
Subject: [OpenSIPS-Devel] [ opensips-Bugs-2928267 ] infloop due to bad
	linkedlist traversal
Message-ID: <E1NTJ2k-0003g2-3m@155xhf1.ch3.sourceforge.com>

Bugs item #2928267, was opened at 2010-01-08 15:33
Message generated for change (Settings changed) made by bogdan_iancu
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=2928267&group_id=232389

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: core
Group: 1.6.x
>Status: Closed
>Resolution: Fixed
Priority: 5
Private: No
Submitted By: Walter Doekes (wdoekes)
>Assigned to: Bogdan-Andrei Iancu (bogdan_iancu)
Summary: infloop due to bad linkedlist traversal

Initial Comment:
Due to a cause unknown to me, opensips 1.6.0/1 hangs.

Gdb tells me:
0x0808292a <pv_get_hdr+1242>:	lea    0x0(%esi),%esi
0x08082930 <pv_get_hdr+1248>:	jmp    0x808292a <pv_get_hdr+1242>

1966				/* it is an un-known header -> use name to find it */
1967				for (hf0=hf->next; hf0; hf=hf0->next) {
1968					if (hf0->type==HDR_OTHER_T && hf0->name.len==tv.rs.len

That hf=hf0->next should probably be hf0=hf0->next.

Patch attached.

Regards,
Walter Doekes
OSSO B.V.

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

>Comment By: Bogdan-Andrei Iancu (bogdan_iancu)
Date: 2010-01-08 19:54

Message:
Hi Walter,

Thanks for catching this ugly bug/typo....I fixed it on 1.5-1.6 releases
and trunk.

Best regards,
Bogdan

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

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


From alex at jajah.com  Mon Jan 11 11:03:38 2010
From: alex at jajah.com (Alex Massover)
Date: Mon, 11 Jan 2010 12:03:38 +0200
Subject: [OpenSIPS-Devel] Debugging crash
Message-ID: <F5B5EF8F78C0BC4BB417E1DBB9D7F7D00B99CBE182@jjex01.jajah.dublin>

Hi!

We're running a stress test and after some time (tens of minutes and hundreds of processes calls) OpenSIPS 1.6.0 crashes.

Below is an output of gdb. OpenSIPS is slightly tuned for performance:


a)      RADIUS accounting is sent in detached thread

b)      Libradius-ng uses shared memory & atomic memory access instead of seqfile

Any tip where/how to dig please?

(gdb) core core.opensips.sig6.11596
[New Thread 30240]
[New Thread 30238]
[New Thread 30231]
[New Thread 30229]
[New Thread 30203]
[New Thread 30191]
[New Thread 30183]
[New Thread 30165]
[New Thread 30159]
[New Thread 30155]
[New Thread 30142]
[New Thread 30130]
[New Thread 30126]
[New Thread 30103]
[New Thread 30070]
[New Thread 30037]
[New Thread 30010]
[New Thread 29966]
[New Thread 29912]
[New Thread 29862]
[New Thread 29818]
[New Thread 29742]
[New Thread 29715]
[New Thread 29682]
[New Thread 29628]
[New Thread 29597]
[New Thread 29586]
[New Thread 29561]
[New Thread 29491]
[New Thread 29396]
[New Thread 29366]
[New Thread 29359]
[New Thread 29316]
[New Thread 29305]
[New Thread 29278]
[New Thread 29264]
[New Thread 29260]
[New Thread 29238]
[New Thread 29235]
[New Thread 29210]
[New Thread 29184]
[New Thread 29136]
[New Thread 29132]
[New Thread 11596]
Core was generated by `/usr/sbin/opensips -P /var/run/opensips/opensips.pid -m 32 -u opensips -g opens'.
Program terminated with signal 6, Aborted.
#0  0xb7fcf424 in __kernel_vsyscall ()

--
Best Regards,
Alex Massover
VoIP R&D TL
Jajah Inc.

This mail was sent via Mail-SeCure System.


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

From alex at jajah.com  Mon Jan 11 11:20:55 2010
From: alex at jajah.com (Alex Massover)
Date: Mon, 11 Jan 2010 12:20:55 +0200
Subject: [OpenSIPS-Devel] Debugging crash
In-Reply-To: <F5B5EF8F78C0BC4BB417E1DBB9D7F7D00B99CBE182@jjex01.jajah.dublin>
References: <F5B5EF8F78C0BC4BB417E1DBB9D7F7D00B99CBE182@jjex01.jajah.dublin>
Message-ID: <F5B5EF8F78C0BC4BB417E1DBB9D7F7D00B99CBE196@jjex01.jajah.dublin>

Here's a backtrace:

#0  0xb7fcf424 in __kernel_vsyscall ()
(gdb) bt
#0  0xb7fcf424 in __kernel_vsyscall ()
#1  0xb7e7c640 in raise () from /lib/i686/cmov/libc.so.6
#2  0xb7e7e018 in abort () from /lib/i686/cmov/libc.so.6
#3  0xb7eb93dd in ?? () from /lib/i686/cmov/libc.so.6
#4  0xb7ebf6b4 in ?? () from /lib/i686/cmov/libc.so.6
#5  0xb7ec18b6 in free () from /lib/i686/cmov/libc.so.6
#6  0xb7ebb69d in _IO_file_seekoff () from /lib/i686/cmov/libc.so.6
#7  0xb7eb1900 in ?? () from /lib/i686/cmov/libc.so.6
#8  0xb7eb7ea8 in rewind () from /lib/i686/cmov/libc.so.6
#9  0xb74c7f2e in ?? () from /lib/i686/cmov/libnss_files.so.2
#10 0xb74c86b8 in _nss_files_gethostbyaddr_r () from /lib/i686/cmov/libnss_files.so.2
#11 0xb7f4a5ec in gethostbyaddr_r () from /lib/i686/cmov/libc.so.6
#12 0xb7f4a3dc in gethostbyaddr () from /lib/i686/cmov/libc.so.6
#13 0xb7ae75f5 in rc_ip_hostname () from /usr/lib/libradiusclient-ng.so.2
#14 0xb7ae3b5f in rc_send_server () from /usr/lib/libradiusclient-ng.so.2
#15 0xb7ae2b3d in rc_acct () from /usr/lib/libradiusclient-ng.so.2
#16 0xb7da60cf in rad_send_message () from /usr/lib/opensips/modules/aaa_radius.so
#17 0xb7ac6fed in thread_rc_acct () from /usr/lib/opensips/modules/acc.so
#18 0xb7ba54c0 in start_thread () from /lib/i686/cmov/libpthread.so.0
#19 0xb7f3161e in clone () from /lib/i686/cmov/libc.so.6

--
Best Regards,
Alex Massover
VoIP R&D TL
Jajah Inc.
From: devel-bounces at lists.opensips.org [mailto:devel-bounces at lists.opensips.org] On Behalf Of Alex Massover
Sent: Monday, January 11, 2010 12:04 PM
To: OpenSIPS devel mailling list
Subject: [OpenSIPS-Devel] Debugging crash

Hi!

We're running a stress test and after some time (tens of minutes and hundreds of processes calls) OpenSIPS 1.6.0 crashes.

Below is an output of gdb. OpenSIPS is slightly tuned for performance:


a)      RADIUS accounting is sent in detached thread

b)      Libradius-ng uses shared memory & atomic memory access instead of seqfile

Any tip where/how to dig please?

(gdb) core core.opensips.sig6.11596
[New Thread 30240]
[New Thread 30238]
[New Thread 30231]
[New Thread 30229]
[New Thread 30203]
[New Thread 30191]
[New Thread 30183]
[New Thread 30165]
[New Thread 30159]
[New Thread 30155]
[New Thread 30142]
[New Thread 30130]
[New Thread 30126]
[New Thread 30103]
[New Thread 30070]
[New Thread 30037]
[New Thread 30010]
[New Thread 29966]
[New Thread 29912]
[New Thread 29862]
[New Thread 29818]
[New Thread 29742]
[New Thread 29715]
[New Thread 29682]
[New Thread 29628]
[New Thread 29597]
[New Thread 29586]
[New Thread 29561]
[New Thread 29491]
[New Thread 29396]
[New Thread 29366]
[New Thread 29359]
[New Thread 29316]
[New Thread 29305]
[New Thread 29278]
[New Thread 29264]
[New Thread 29260]
[New Thread 29238]
[New Thread 29235]
[New Thread 29210]
[New Thread 29184]
[New Thread 29136]
[New Thread 29132]
[New Thread 11596]
Core was generated by `/usr/sbin/opensips -P /var/run/opensips/opensips.pid -m 32 -u opensips -g opens'.
Program terminated with signal 6, Aborted.
#0  0xb7fcf424 in __kernel_vsyscall ()

--
Best Regards,
Alex Massover
VoIP R&D TL
Jajah Inc.


This mail was sent via Mail-SeCure System.


This mail was received via Mail-SeCure System.

This mail was sent via Mail-SeCure System.


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

From noreply at sourceforge.net  Mon Jan 11 12:40:27 2010
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 11 Jan 2010 11:40:27 +0000
Subject: [OpenSIPS-Devel] [ opensips-Bugs-2923461 ] INVITE without Contact
	relayed
Message-ID: <E1NUIdH-0004FM-2h@g45xhf1.ch3.sourceforge.com>

Bugs item #2923461, was opened at 2009-12-30 14:28
Message generated for change (Comment added) made by iamthedeath
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=2923461&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: INVITE without Contact relayed

Initial Comment:
Hello.

I think, thath i have found a bug.

opensips recieve this message:
INVITE sip:1000085110 at 10.254.157.42:5060 SIP/2.0.
Record-Route: <sip:10.2.166.17;lr=on;ftag=861013891;vsf=AAAAAFVXVwMCCXVLWkchVx0BYS5ydQ-->.
Record-Route: <sip:[--IP-HERE--];lr=on;ftag=861013891>.
Via: SIP/2.0/UDP 10.2.166.17;branch=z9hG4bK2874.b998c896.0.
Via: SIP/2.0/UDP [--IP-HERE--];branch=z9hG4bK2874.8f3e33b6.0.
Via: SIP/2.0/UDP 10.254.157.104:5060;received=[--IP-HERE--];branch=z9hG4bK609371529;rport=14259.
Max-Forwards: 68.
From: "1000085253" <sip:dgg321@[--DOMAIN-HERE--]>;tag=861013891.
To: "anonymous" <sip:1000085110@[--DOMAIN-HERE--]>.
Call-ID: 3335133038 at 10.254.157.104.
Server: IMS Server 1.0.
User-Agent: IMS Client v0.001.
sip:[--DOMAIN-HERE--].
Supported: timer,replaces.
Allow: INVITE,ACK,CANCEL,BYE,SUBSCRIBE,NOTIFY,MESSAGE,INFO,UPDATE.
Accept-Contact: *;description="VT";explicit;require.
Session-Expires: 1800;refresher=uac.
CSeq: 2 INVITE.
Content-Type: application/sdp.
Content-Length: 232.
.
[--SDP-CUTTED--]

than this message was relayed to the client pointed in the Request URI, client answer with response:
SIP/2.0 400 Bad Request.
Via: SIP/2.0/UDP [--IP_HERE--];branch=z9hG4bK2874.9f3e33b6.0.
Via: SIP/2.0/UDP 10.2.166.17;branch=z9hG4bK2874.b998c896.0.
Via: SIP/2.0/UDP [--IP_HERE--];branch=z9hG4bK2874.8f3e33b6.0.
Via: SIP/2.0/UDP 10.254.157.104:5060;received=[--IP_HERE--];branch=z9hG4bK609371529;rport=14259.
Max-Forwards: 70.
From: ""1000085253"" <sip:dgg321@[--DOMAIN_HERE--]>;tag=861013891.
To: ""anonymous"" <sip:1000085110@[--DOMAIN_HERE--]>.
Call-ID: 3335133038 at 10.254.157.104.
CSeq: 2 INVITE.
Content-Length: 0.

but opensips still trying to retransmit initial invite to client...

First of all, in accordance with RFC3261 (Section 8.1.1.8) INVITE without "Contact" header must be rejected. 
I see, I can reject such message using configuration to check presentity of this header in INVITE message, but it would be better when it will be done thru the parser/tm modules by opensips.

Second is the question: why opensips try to retransmit initial INVITE when response was already recieved.

version: opensips 1.5.3-notls (x86_64/linux)
flags: STATS: Off, USE_IPV6, USE_TCP, DISABLE_NAGLE, USE_MCAST, SHM_MEM, SHM_MMAP, PKG_MALLOC, F_MALLOC, FAST_LOCK-ADAPTIVE_WAIT
ADAPTIVE_WAIT_LOOPS=1024, MAX_RECV_BUFFER_SIZE 262144, MAX_LISTEN 16, MAX_URI_SIZE 1024, BUF_SIZE 65535
poll method support: poll, epoll_lt, epoll_et, sigio_rt, select.
svnrevision: 4:921M
@(#) $Id: main.c 5887 2009-07-16 11:47:46Z bogdan_iancu $
main.c compiled on 18:10:15 Dec 29 2009 with gcc 4.1.2


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

Comment By: Alexey Nikolaev (iamthedeath)
Date: 2010-01-11 14:40

Message:
Hi, Bogdan.

Sorry for the delay with answer. Happy new year! :)
I'll try to reproduce this with more detailed debug.

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

Comment By: Bogdan-Andrei Iancu (bogdan_iancu)
Date: 2010-01-04 18:22

Message:
Hi Alexey ,

For the first issue, contact related, if you want to do some very advanced
sanity checks, you need to do them explicitly from the script. OpenSIPS is
checking by default just the syntax part and the elements it is interested
in.

Now, about the 400 reply and retransmission...Are you sure OpenSIPS is
receiving the 400 reply? can you run in full debug (debug=6) and post the
part corresponding the reply processing ?

Regards,
Bogdan

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

Comment By: Alexey Nikolaev (iamthedeath)
Date: 2009-12-30 14:29

Message:
Forget to login. This is my issue.

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

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


From alex at jajah.com  Mon Jan 11 13:31:09 2010
From: alex at jajah.com (Alex Massover)
Date: Mon, 11 Jan 2010 14:31:09 +0200
Subject: [OpenSIPS-Devel] Debugging crash
In-Reply-To: <F5B5EF8F78C0BC4BB417E1DBB9D7F7D00B99CBE196@jjex01.jajah.dublin>
References: <F5B5EF8F78C0BC4BB417E1DBB9D7F7D00B99CBE182@jjex01.jajah.dublin>
	<F5B5EF8F78C0BC4BB417E1DBB9D7F7D00B99CBE196@jjex01.jajah.dublin>
Message-ID: <F5B5EF8F78C0BC4BB417E1DBB9D7F7D00B99CBE214@jjex01.jajah.dublin>

Hmmm... -D_REENTRANT supposed to help here?

--
Best Regards,
Alex Massover
VoIP R&D TL
Jajah Inc.
From: devel-bounces at lists.opensips.org [mailto:devel-bounces at lists.opensips.org] On Behalf Of Alex Massover
Sent: Monday, January 11, 2010 12:21 PM
To: OpenSIPS devel mailling list
Subject: Re: [OpenSIPS-Devel] Debugging crash

Here's a backtrace:

#0  0xb7fcf424 in __kernel_vsyscall ()
(gdb) bt
#0  0xb7fcf424 in __kernel_vsyscall ()
#1  0xb7e7c640 in raise () from /lib/i686/cmov/libc.so.6
#2  0xb7e7e018 in abort () from /lib/i686/cmov/libc.so.6
#3  0xb7eb93dd in ?? () from /lib/i686/cmov/libc.so.6
#4  0xb7ebf6b4 in ?? () from /lib/i686/cmov/libc.so.6
#5  0xb7ec18b6 in free () from /lib/i686/cmov/libc.so.6
#6  0xb7ebb69d in _IO_file_seekoff () from /lib/i686/cmov/libc.so.6
#7  0xb7eb1900 in ?? () from /lib/i686/cmov/libc.so.6
#8  0xb7eb7ea8 in rewind () from /lib/i686/cmov/libc.so.6
#9  0xb74c7f2e in ?? () from /lib/i686/cmov/libnss_files.so.2
#10 0xb74c86b8 in _nss_files_gethostbyaddr_r () from /lib/i686/cmov/libnss_files.so.2
#11 0xb7f4a5ec in gethostbyaddr_r () from /lib/i686/cmov/libc.so.6
#12 0xb7f4a3dc in gethostbyaddr () from /lib/i686/cmov/libc.so.6
#13 0xb7ae75f5 in rc_ip_hostname () from /usr/lib/libradiusclient-ng.so.2
#14 0xb7ae3b5f in rc_send_server () from /usr/lib/libradiusclient-ng.so.2
#15 0xb7ae2b3d in rc_acct () from /usr/lib/libradiusclient-ng.so.2
#16 0xb7da60cf in rad_send_message () from /usr/lib/opensips/modules/aaa_radius.so
#17 0xb7ac6fed in thread_rc_acct () from /usr/lib/opensips/modules/acc.so
#18 0xb7ba54c0 in start_thread () from /lib/i686/cmov/libpthread.so.0
#19 0xb7f3161e in clone () from /lib/i686/cmov/libc.so.6

--
Best Regards,
Alex Massover
VoIP R&D TL
Jajah Inc.
From: devel-bounces at lists.opensips.org [mailto:devel-bounces at lists.opensips.org] On Behalf Of Alex Massover
Sent: Monday, January 11, 2010 12:04 PM
To: OpenSIPS devel mailling list
Subject: [OpenSIPS-Devel] Debugging crash

Hi!

We're running a stress test and after some time (tens of minutes and hundreds of processes calls) OpenSIPS 1.6.0 crashes.

Below is an output of gdb. OpenSIPS is slightly tuned for performance:


a)      RADIUS accounting is sent in detached thread

b)      Libradius-ng uses shared memory & atomic memory access instead of seqfile

Any tip where/how to dig please?

(gdb) core core.opensips.sig6.11596
[New Thread 30240]
[New Thread 30238]
[New Thread 30231]
[New Thread 30229]
[New Thread 30203]
[New Thread 30191]
[New Thread 30183]
[New Thread 30165]
[New Thread 30159]
[New Thread 30155]
[New Thread 30142]
[New Thread 30130]
[New Thread 30126]
[New Thread 30103]
[New Thread 30070]
[New Thread 30037]
[New Thread 30010]
[New Thread 29966]
[New Thread 29912]
[New Thread 29862]
[New Thread 29818]
[New Thread 29742]
[New Thread 29715]
[New Thread 29682]
[New Thread 29628]
[New Thread 29597]
[New Thread 29586]
[New Thread 29561]
[New Thread 29491]
[New Thread 29396]
[New Thread 29366]
[New Thread 29359]
[New Thread 29316]
[New Thread 29305]
[New Thread 29278]
[New Thread 29264]
[New Thread 29260]
[New Thread 29238]
[New Thread 29235]
[New Thread 29210]
[New Thread 29184]
[New Thread 29136]
[New Thread 29132]
[New Thread 11596]
Core was generated by `/usr/sbin/opensips -P /var/run/opensips/opensips.pid -m 32 -u opensips -g opens'.
Program terminated with signal 6, Aborted.
#0  0xb7fcf424 in __kernel_vsyscall ()

--
Best Regards,
Alex Massover
VoIP R&D TL
Jajah Inc.


This mail was sent via Mail-SeCure System.


This mail was received via Mail-SeCure System.


This mail was sent via Mail-SeCure System.


This mail was received via Mail-SeCure System.

This mail was sent via Mail-SeCure System.


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

From chino540off+kamailio at gmail.com  Thu Jan 14 17:46:53 2010
From: chino540off+kamailio at gmail.com (=?ISO-8859-1?Q?Olivier_D=E9tour?=)
Date: Thu, 14 Jan 2010 17:46:53 +0100
Subject: [OpenSIPS-Devel] Share SIP Messages between 2 processes
In-Reply-To: <99667a341001140845o46de7f0awa9194b66894cf4a7@mail.gmail.com>
References: <99667a341001140845o46de7f0awa9194b66894cf4a7@mail.gmail.com>
Message-ID: <99667a341001140846g50a5cac6i3a9f844145937f83@mail.gmail.com>

Hi,

I'm writing a B2B module for the B2B_entities module (like B2B_logic).
In my initialisation,
I create an extra process to poll on an extra FD to receive order to
create UAC part.
I would like to know how to share a SIP message between the module and
the extra process
(I'm using OpenSIPs in fork mode ...) ? I tried to shm_malloc it but I
get an out of memory error
on the second Communication.

Thanks for your response,

Regards,

--
Olivier D?tour



-- 
Olivier D?tour
Sent from Paris, ?le-de-France, France


From bogdan at voice-system.ro  Thu Jan 14 18:55:13 2010
From: bogdan at voice-system.ro (Bogdan-Andrei Iancu)
Date: Thu, 14 Jan 2010 19:55:13 +0200
Subject: [OpenSIPS-Devel] Share SIP Messages between 2 processes
In-Reply-To: <99667a341001140846g50a5cac6i3a9f844145937f83@mail.gmail.com>
References: <99667a341001140845o46de7f0awa9194b66894cf4a7@mail.gmail.com>
	<99667a341001140846g50a5cac6i3a9f844145937f83@mail.gmail.com>
Message-ID: <4B4F5A81.6030809@voice-system.ro>

Hi Olivier,

Olivier D?tour wrote:
> Hi,
>
> I'm writing a B2B module for the B2B_entities module (like B2B_logic).
> In my initialisation,
> I create an extra process to poll on an extra FD to receive order to
> create UAC part.
>   
Why don't you use the MI stuff for this? you can trigger an action / 
event by sending an MI command to the server -> you module just has to 
export a new MI function.
> I would like to know how to share a SIP message between the module and
> the extra process
> (I'm using OpenSIPs in fork mode ...) ? I tried to shm_malloc it but I
> get an out of memory error
> on the second Communication.
>   

normally using shm_malloc is the trick, but depends of where you fork 
your process (if the shm is inherited) and who you use it for 
transferring data from from A to B.

Regards,
Bogdan
> Thanks for your response,
>
> Regards,
>
> --
> Olivier D?tour
>
>
>
>   


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



From bogdan at voice-system.ro  Thu Jan 14 19:06:17 2010
From: bogdan at voice-system.ro (Bogdan-Andrei Iancu)
Date: Thu, 14 Jan 2010 20:06:17 +0200
Subject: [OpenSIPS-Devel] Debugging crash
In-Reply-To: <F5B5EF8F78C0BC4BB417E1DBB9D7F7D00B99CBE214@jjex01.jajah.dublin>
References: <F5B5EF8F78C0BC4BB417E1DBB9D7F7D00B99CBE182@jjex01.jajah.dublin>	<F5B5EF8F78C0BC4BB417E1DBB9D7F7D00B99CBE196@jjex01.jajah.dublin>
	<F5B5EF8F78C0BC4BB417E1DBB9D7F7D00B99CBE214@jjex01.jajah.dublin>
Message-ID: <4B4F5D19.20005@voice-system.ro>

Hi Alex,

The crash looks to be in the libradiusclient stuff....and not in the 
opensips part.

Looking at the backtrace, it seams the lib tries to resolve the name of 
the acc server - do you use DNS or IP for it?

Regards,
Bogdan

Alex Massover wrote:
>
> Hmmm? -D_REENTRANT supposed to help here?
>
> --
>
> Best Regards,
>
> Alex Massover
>
> VoIP R&D TL
>
> Jajah Inc.
>
> *From:* devel-bounces at lists.opensips.org 
> [mailto:devel-bounces at lists.opensips.org] *On Behalf Of *Alex Massover
> *Sent:* Monday, January 11, 2010 12:21 PM
> *To:* OpenSIPS devel mailling list
> *Subject:* Re: [OpenSIPS-Devel] Debugging crash
>
> Here?s a backtrace:
>
> #0 0xb7fcf424 in __kernel_vsyscall ()
>
> (gdb) bt
>
> #0 0xb7fcf424 in __kernel_vsyscall ()
>
> #1 0xb7e7c640 in raise () from /lib/i686/cmov/libc.so.6
>
> #2 0xb7e7e018 in abort () from /lib/i686/cmov/libc.so.6
>
> #3 0xb7eb93dd in ?? () from /lib/i686/cmov/libc.so.6
>
> #4 0xb7ebf6b4 in ?? () from /lib/i686/cmov/libc.so.6
>
> #5 0xb7ec18b6 in free () from /lib/i686/cmov/libc.so.6
>
> #6 0xb7ebb69d in _IO_file_seekoff () from /lib/i686/cmov/libc.so.6
>
> #7 0xb7eb1900 in ?? () from /lib/i686/cmov/libc.so.6
>
> #8 0xb7eb7ea8 in rewind () from /lib/i686/cmov/libc.so.6
>
> #9 0xb74c7f2e in ?? () from /lib/i686/cmov/libnss_files.so.2
>
> #10 0xb74c86b8 in _nss_files_gethostbyaddr_r () from 
> /lib/i686/cmov/libnss_files.so.2
>
> #11 0xb7f4a5ec in gethostbyaddr_r () from /lib/i686/cmov/libc.so.6
>
> #12 0xb7f4a3dc in gethostbyaddr () from /lib/i686/cmov/libc.so.6
>
> #13 0xb7ae75f5 in rc_ip_hostname () from /usr/lib/libradiusclient-ng.so.2
>
> #14 0xb7ae3b5f in rc_send_server () from /usr/lib/libradiusclient-ng.so.2
>
> #15 0xb7ae2b3d in rc_acct () from /usr/lib/libradiusclient-ng.so.2
>
> #16 0xb7da60cf in rad_send_message () from 
> /usr/lib/opensips/modules/aaa_radius.so
>
> #17 0xb7ac6fed in thread_rc_acct () from /usr/lib/opensips/modules/acc.so
>
> #18 0xb7ba54c0 in start_thread () from /lib/i686/cmov/libpthread.so.0
>
> #19 0xb7f3161e in clone () from /lib/i686/cmov/libc.so.6
>
> --
>
> Best Regards,
>
> Alex Massover
>
> VoIP R&D TL
>
> Jajah Inc.
>
> *From:* devel-bounces at lists.opensips.org 
> [mailto:devel-bounces at lists.opensips.org] *On Behalf Of *Alex Massover
> *Sent:* Monday, January 11, 2010 12:04 PM
> *To:* OpenSIPS devel mailling list
> *Subject:* [OpenSIPS-Devel] Debugging crash
>
> Hi!
>
> We?re running a stress test and after some time (tens of minutes and 
> hundreds of processes calls) OpenSIPS 1.6.0 crashes.
>
> Below is an output of gdb. OpenSIPS is slightly tuned for performance:
>
> a) RADIUS accounting is sent in detached thread
>
> b) Libradius-ng uses shared memory & atomic memory access instead of 
> seqfile
>
> Any tip where/how to dig please?
>
> (gdb) core core.opensips.sig6.11596
>
> [New Thread 30240]
>
> [New Thread 30238]
>
> [New Thread 30231]
>
> [New Thread 30229]
>
> [New Thread 30203]
>
> [New Thread 30191]
>
> [New Thread 30183]
>
> [New Thread 30165]
>
> [New Thread 30159]
>
> [New Thread 30155]
>
> [New Thread 30142]
>
> [New Thread 30130]
>
> [New Thread 30126]
>
> [New Thread 30103]
>
> [New Thread 30070]
>
> [New Thread 30037]
>
> [New Thread 30010]
>
> [New Thread 29966]
>
> [New Thread 29912]
>
> [New Thread 29862]
>
> [New Thread 29818]
>
> [New Thread 29742]
>
> [New Thread 29715]
>
> [New Thread 29682]
>
> [New Thread 29628]
>
> [New Thread 29597]
>
> [New Thread 29586]
>
> [New Thread 29561]
>
> [New Thread 29491]
>
> [New Thread 29396]
>
> [New Thread 29366]
>
> [New Thread 29359]
>
> [New Thread 29316]
>
> [New Thread 29305]
>
> [New Thread 29278]
>
> [New Thread 29264]
>
> [New Thread 29260]
>
> [New Thread 29238]
>
> [New Thread 29235]
>
> [New Thread 29210]
>
> [New Thread 29184]
>
> [New Thread 29136]
>
> [New Thread 29132]
>
> [New Thread 11596]
>
> Core was generated by `/usr/sbin/opensips -P 
> /var/run/opensips/opensips.pid -m 32 -u opensips -g opens'.
>
> Program terminated with signal 6, Aborted.
>
> #0 0xb7fcf424 in __kernel_vsyscall ()
>
> --
>
> Best Regards,
>
> Alex Massover
>
> VoIP R&D TL
>
> Jajah Inc.
>
>
>
> This mail was sent via Mail-SeCure System.
>
>
> This mail was received via Mail-SeCure System.
>
>
>
> This mail was sent via Mail-SeCure System.
>
>
> This mail was received via Mail-SeCure System.
>
>
>
> This mail was sent via Mail-SeCure System.
> ------------------------------------------------------------------------
>
> _______________________________________________
> Devel mailing list
> Devel at lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
>   


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



From alex at jajah.com  Thu Jan 14 20:23:59 2010
From: alex at jajah.com (Alex Massover)
Date: Thu, 14 Jan 2010 21:23:59 +0200
Subject: [OpenSIPS-Devel] Debugging crash
In-Reply-To: <4B4F5D19.20005@voice-system.ro>
References: <F5B5EF8F78C0BC4BB417E1DBB9D7F7D00B99CBE182@jjex01.jajah.dublin>
	<F5B5EF8F78C0BC4BB417E1DBB9D7F7D00B99CBE196@jjex01.jajah.dublin>
	<F5B5EF8F78C0BC4BB417E1DBB9D7F7D00B99CBE214@jjex01.jajah.dublin>
	<4B4F5D19.20005@voice-system.ro>
Message-ID: <F5B5EF8F78C0BC4BB417E1DBB9D7F7D00BA0E5AA32@jjex01.jajah.dublin>

Hi!

I use DNS. As far as I understand the reason could be that libradiusclient use gethostbyaddr() which is not reentrant and I call to libradiusclient in threads.

So I recompiled libradiusclient with -D_REENTRANT.

Afterwards it crashed also in libradiusclient in free() - no idea meanwhile how it happened. Just to be sure I added one more if() before sending it to free().

The strange thing is that crash happens only after several hours of stress test, after processing thousands of calls.
AFAIU it looks like memory corruption.

Now I recompiled everything with -O0 and run with _MALLOCK_CHECK=1, meanwhile it's ok.

Can you think about any special complication of opening threads to make accounting non-blocking?


--
Sincerely yours,
Alex Massover
VoIP R&D TL
Jajah Inc.

> -----Original Message-----
> From: devel-bounces at lists.opensips.org [mailto:devel-
> bounces at lists.opensips.org] On Behalf Of Bogdan-Andrei Iancu
> Sent: Thursday, January 14, 2010 8:06 PM
> To: OpenSIPS devel mailling list
> Subject: Re: [OpenSIPS-Devel] Debugging crash
> 
> Hi Alex,
> 
> The crash looks to be in the libradiusclient stuff....and not in the
> opensips part.
> 
> Looking at the backtrace, it seams the lib tries to resolve the name of
> the acc server - do you use DNS or IP for it?
> 
> Regards,
> Bogdan
> 
> Alex Massover wrote:
> >
> > Hmmm... -D_REENTRANT supposed to help here?
> >
> > --
> >
> > Best Regards,
> >
> > Alex Massover
> >
> > VoIP R&D TL
> >
> > Jajah Inc.
> >
> > *From:* devel-bounces at lists.opensips.org
> > [mailto:devel-bounces at lists.opensips.org] *On Behalf Of *Alex
> Massover
> > *Sent:* Monday, January 11, 2010 12:21 PM
> > *To:* OpenSIPS devel mailling list
> > *Subject:* Re: [OpenSIPS-Devel] Debugging crash
> >
> > Here's a backtrace:
> >
> > #0 0xb7fcf424 in __kernel_vsyscall ()
> >
> > (gdb) bt
> >
> > #0 0xb7fcf424 in __kernel_vsyscall ()
> >
> > #1 0xb7e7c640 in raise () from /lib/i686/cmov/libc.so.6
> >
> > #2 0xb7e7e018 in abort () from /lib/i686/cmov/libc.so.6
> >
> > #3 0xb7eb93dd in ?? () from /lib/i686/cmov/libc.so.6
> >
> > #4 0xb7ebf6b4 in ?? () from /lib/i686/cmov/libc.so.6
> >
> > #5 0xb7ec18b6 in free () from /lib/i686/cmov/libc.so.6
> >
> > #6 0xb7ebb69d in _IO_file_seekoff () from /lib/i686/cmov/libc.so.6
> >
> > #7 0xb7eb1900 in ?? () from /lib/i686/cmov/libc.so.6
> >
> > #8 0xb7eb7ea8 in rewind () from /lib/i686/cmov/libc.so.6
> >
> > #9 0xb74c7f2e in ?? () from /lib/i686/cmov/libnss_files.so.2
> >
> > #10 0xb74c86b8 in _nss_files_gethostbyaddr_r () from
> > /lib/i686/cmov/libnss_files.so.2
> >
> > #11 0xb7f4a5ec in gethostbyaddr_r () from /lib/i686/cmov/libc.so.6
> >
> > #12 0xb7f4a3dc in gethostbyaddr () from /lib/i686/cmov/libc.so.6
> >
> > #13 0xb7ae75f5 in rc_ip_hostname () from /usr/lib/libradiusclient-
> ng.so.2
> >
> > #14 0xb7ae3b5f in rc_send_server () from /usr/lib/libradiusclient-
> ng.so.2
> >
> > #15 0xb7ae2b3d in rc_acct () from /usr/lib/libradiusclient-ng.so.2
> >
> > #16 0xb7da60cf in rad_send_message () from
> > /usr/lib/opensips/modules/aaa_radius.so
> >
> > #17 0xb7ac6fed in thread_rc_acct () from
> /usr/lib/opensips/modules/acc.so
> >
> > #18 0xb7ba54c0 in start_thread () from /lib/i686/cmov/libpthread.so.0
> >
> > #19 0xb7f3161e in clone () from /lib/i686/cmov/libc.so.6
> >
> > --
> >
> > Best Regards,
> >
> > Alex Massover
> >
> > VoIP R&D TL
> >
> > Jajah Inc.
> >
> > *From:* devel-bounces at lists.opensips.org
> > [mailto:devel-bounces at lists.opensips.org] *On Behalf Of *Alex
> Massover
> > *Sent:* Monday, January 11, 2010 12:04 PM
> > *To:* OpenSIPS devel mailling list
> > *Subject:* [OpenSIPS-Devel] Debugging crash
> >
> > Hi!
> >
> > We're running a stress test and after some time (tens of minutes and
> > hundreds of processes calls) OpenSIPS 1.6.0 crashes.
> >
> > Below is an output of gdb. OpenSIPS is slightly tuned for
> performance:
> >
> > a) RADIUS accounting is sent in detached thread
> >
> > b) Libradius-ng uses shared memory & atomic memory access instead of
> > seqfile
> >
> > Any tip where/how to dig please?
> >
> > (gdb) core core.opensips.sig6.11596
> >
> > [New Thread 30240]
> >
> > [New Thread 30238]
> >
> > [New Thread 30231]
> >
> > [New Thread 30229]
> >
> > [New Thread 30203]
> >
> > [New Thread 30191]
> >
> > [New Thread 30183]
> >
> > [New Thread 30165]
> >
> > [New Thread 30159]
> >
> > [New Thread 30155]
> >
> > [New Thread 30142]
> >
> > [New Thread 30130]
> >
> > [New Thread 30126]
> >
> > [New Thread 30103]
> >
> > [New Thread 30070]
> >
> > [New Thread 30037]
> >
> > [New Thread 30010]
> >
> > [New Thread 29966]
> >
> > [New Thread 29912]
> >
> > [New Thread 29862]
> >
> > [New Thread 29818]
> >
> > [New Thread 29742]
> >
> > [New Thread 29715]
> >
> > [New Thread 29682]
> >
> > [New Thread 29628]
> >
> > [New Thread 29597]
> >
> > [New Thread 29586]
> >
> > [New Thread 29561]
> >
> > [New Thread 29491]
> >
> > [New Thread 29396]
> >
> > [New Thread 29366]
> >
> > [New Thread 29359]
> >
> > [New Thread 29316]
> >
> > [New Thread 29305]
> >
> > [New Thread 29278]
> >
> > [New Thread 29264]
> >
> > [New Thread 29260]
> >
> > [New Thread 29238]
> >
> > [New Thread 29235]
> >
> > [New Thread 29210]
> >
> > [New Thread 29184]
> >
> > [New Thread 29136]
> >
> > [New Thread 29132]
> >
> > [New Thread 11596]
> >
> > Core was generated by `/usr/sbin/opensips -P
> > /var/run/opensips/opensips.pid -m 32 -u opensips -g opens'.
> >
> > Program terminated with signal 6, Aborted.
> >
> > #0 0xb7fcf424 in __kernel_vsyscall ()
> >
> > --
> >
> > Best Regards,
> >
> > Alex Massover
> >
> > VoIP R&D TL
> >
> > Jajah Inc.
> >
> >
> >
> > This mail was sent via Mail-SeCure System.
> >
> >
> > This mail was received via Mail-SeCure System.
> >
> >
> >
> > This mail was sent via Mail-SeCure System.
> >
> >
> > This mail was received via Mail-SeCure System.
> >
> >
> >
> > This mail was sent via Mail-SeCure System.
> > ---------------------------------------------------------------------
> ---
> >
> > _______________________________________________
> > Devel mailing list
> > Devel at lists.opensips.org
> > http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
> >
> 
> 
> --
> Bogdan-Andrei Iancu
> www.voice-system.ro
> 
> 
> _______________________________________________
> Devel mailing list
> Devel at lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
> 
> This mail was received via Mail-SeCure System.
> 


This mail was sent via Mail-SeCure System.




From chino540off+kamailio at gmail.com  Fri Jan 15 08:00:07 2010
From: chino540off+kamailio at gmail.com (=?ISO-8859-1?Q?Olivier_D=E9tour?=)
Date: Fri, 15 Jan 2010 08:00:07 +0100
Subject: [OpenSIPS-Devel] Share SIP Messages between 2 processes
In-Reply-To: <4B4F5A81.6030809@voice-system.ro>
References: <99667a341001140845o46de7f0awa9194b66894cf4a7@mail.gmail.com>
	<99667a341001140846g50a5cac6i3a9f844145937f83@mail.gmail.com>
	<4B4F5A81.6030809@voice-system.ro>
Message-ID: <99667a341001142300h743ba051xd6fda085cab53061@mail.gmail.com>

On Thu, Jan 14, 2010 at 6:55 PM, Bogdan-Andrei Iancu
<bogdan at voice-system.ro> wrote:
> Hi Olivier,
>
> Olivier D?tour wrote:
>> Hi,
>>
>> I'm writing a B2B module for the B2B_entities module (like B2B_logic).
>> In my initialisation,
>> I create an extra process to poll on an extra FD to receive order to
>> create UAC part.
>>
> Why don't you use the MI stuff for this? you can trigger an action /
> event by sending an MI command to the server -> you module just has to
> export a new MI function.
>> I would like to know how to share a SIP message between the module and
>> the extra process
>> (I'm using OpenSIPs in fork mode ...) ? I tried to shm_malloc it but I
>> get an out of memory error
>> on the second Communication.
>>
>
> normally using shm_malloc is the trick, but depends of where you fork
> your process (if the shm is inherited) and who you use it for
> transferring data from from A to B.
>

Forks come from OpenSIPs itself (worker forks + my extra fork (extra
process in module declaration)).
I think I have to use shared memory to share data between different
processes. I tried to find the best and the most optimize way to use
it.

Do you know actually, how much percent of the 32 MB of shared memory,
is used by OpenSIPs ?

Regards

-- 
Olivier D?tour


From noreply at sourceforge.net  Fri Jan 15 10:03:16 2010
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 15 Jan 2010 09:03:16 +0000
Subject: [OpenSIPS-Devel] [ opensips-Bugs-2923461 ] INVITE without Contact
	relayed
Message-ID: <E1NVi5M-00079c-6h@cdv4jf1.ch3.sourceforge.com>

Bugs item #2923461, was opened at 2009-12-30 14:28
Message generated for change (Comment added) made by iamthedeath
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=2923461&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: INVITE without Contact relayed

Initial Comment:
Hello.

I think, thath i have found a bug.

opensips recieve this message:
INVITE sip:1000085110 at 10.254.157.42:5060 SIP/2.0.
Record-Route: <sip:10.2.166.17;lr=on;ftag=861013891;vsf=AAAAAFVXVwMCCXVLWkchVx0BYS5ydQ-->.
Record-Route: <sip:[--IP-HERE--];lr=on;ftag=861013891>.
Via: SIP/2.0/UDP 10.2.166.17;branch=z9hG4bK2874.b998c896.0.
Via: SIP/2.0/UDP [--IP-HERE--];branch=z9hG4bK2874.8f3e33b6.0.
Via: SIP/2.0/UDP 10.254.157.104:5060;received=[--IP-HERE--];branch=z9hG4bK609371529;rport=14259.
Max-Forwards: 68.
From: "1000085253" <sip:dgg321@[--DOMAIN-HERE--]>;tag=861013891.
To: "anonymous" <sip:1000085110@[--DOMAIN-HERE--]>.
Call-ID: 3335133038 at 10.254.157.104.
Server: IMS Server 1.0.
User-Agent: IMS Client v0.001.
sip:[--DOMAIN-HERE--].
Supported: timer,replaces.
Allow: INVITE,ACK,CANCEL,BYE,SUBSCRIBE,NOTIFY,MESSAGE,INFO,UPDATE.
Accept-Contact: *;description="VT";explicit;require.
Session-Expires: 1800;refresher=uac.
CSeq: 2 INVITE.
Content-Type: application/sdp.
Content-Length: 232.
.
[--SDP-CUTTED--]

than this message was relayed to the client pointed in the Request URI, client answer with response:
SIP/2.0 400 Bad Request.
Via: SIP/2.0/UDP [--IP_HERE--];branch=z9hG4bK2874.9f3e33b6.0.
Via: SIP/2.0/UDP 10.2.166.17;branch=z9hG4bK2874.b998c896.0.
Via: SIP/2.0/UDP [--IP_HERE--];branch=z9hG4bK2874.8f3e33b6.0.
Via: SIP/2.0/UDP 10.254.157.104:5060;received=[--IP_HERE--];branch=z9hG4bK609371529;rport=14259.
Max-Forwards: 70.
From: ""1000085253"" <sip:dgg321@[--DOMAIN_HERE--]>;tag=861013891.
To: ""anonymous"" <sip:1000085110@[--DOMAIN_HERE--]>.
Call-ID: 3335133038 at 10.254.157.104.
CSeq: 2 INVITE.
Content-Length: 0.

but opensips still trying to retransmit initial invite to client...

First of all, in accordance with RFC3261 (Section 8.1.1.8) INVITE without "Contact" header must be rejected. 
I see, I can reject such message using configuration to check presentity of this header in INVITE message, but it would be better when it will be done thru the parser/tm modules by opensips.

Second is the question: why opensips try to retransmit initial INVITE when response was already recieved.

version: opensips 1.5.3-notls (x86_64/linux)
flags: STATS: Off, USE_IPV6, USE_TCP, DISABLE_NAGLE, USE_MCAST, SHM_MEM, SHM_MMAP, PKG_MALLOC, F_MALLOC, FAST_LOCK-ADAPTIVE_WAIT
ADAPTIVE_WAIT_LOOPS=1024, MAX_RECV_BUFFER_SIZE 262144, MAX_LISTEN 16, MAX_URI_SIZE 1024, BUF_SIZE 65535
poll method support: poll, epoll_lt, epoll_et, sigio_rt, select.
svnrevision: 4:921M
@(#) $Id: main.c 5887 2009-07-16 11:47:46Z bogdan_iancu $
main.c compiled on 18:10:15 Dec 29 2009 with gcc 4.1.2


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

Comment By: Alexey Nikolaev (iamthedeath)
Date: 2010-01-15 12:03

Message:
Hi, Bogdan.

I have reproduce the problem with 400 reply and have taken logs with
debug=6. Is it possible to share debug privately to you?

Thanks.
Alexey.

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

Comment By: Alexey Nikolaev (iamthedeath)
Date: 2010-01-11 14:40

Message:
Hi, Bogdan.

Sorry for the delay with answer. Happy new year! :)
I'll try to reproduce this with more detailed debug.

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

Comment By: Bogdan-Andrei Iancu (bogdan_iancu)
Date: 2010-01-04 18:22

Message:
Hi Alexey ,

For the first issue, contact related, if you want to do some very advanced
sanity checks, you need to do them explicitly from the script. OpenSIPS is
checking by default just the syntax part and the elements it is interested
in.

Now, about the 400 reply and retransmission...Are you sure OpenSIPS is
receiving the 400 reply? can you run in full debug (debug=6) and post the
part corresponding the reply processing ?

Regards,
Bogdan

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

Comment By: Alexey Nikolaev (iamthedeath)
Date: 2009-12-30 14:29

Message:
Forget to login. This is my issue.

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

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


From noreply at sourceforge.net  Fri Jan 15 12:21:47 2010
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 15 Jan 2010 11:21:47 +0000
Subject: [OpenSIPS-Devel] [ opensips-Bugs-2923461 ] INVITE without Contact
	relayed
Message-ID: <E1NVkFP-0003Q1-PP@d45xhf1.ch3.sourceforge.com>

Bugs item #2923461, was opened at 2009-12-30 13:28
Message generated for change (Comment added) made by bogdan_iancu
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=2923461&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: INVITE without Contact relayed

Initial Comment:
Hello.

I think, thath i have found a bug.

opensips recieve this message:
INVITE sip:1000085110 at 10.254.157.42:5060 SIP/2.0.
Record-Route: <sip:10.2.166.17;lr=on;ftag=861013891;vsf=AAAAAFVXVwMCCXVLWkchVx0BYS5ydQ-->.
Record-Route: <sip:[--IP-HERE--];lr=on;ftag=861013891>.
Via: SIP/2.0/UDP 10.2.166.17;branch=z9hG4bK2874.b998c896.0.
Via: SIP/2.0/UDP [--IP-HERE--];branch=z9hG4bK2874.8f3e33b6.0.
Via: SIP/2.0/UDP 10.254.157.104:5060;received=[--IP-HERE--];branch=z9hG4bK609371529;rport=14259.
Max-Forwards: 68.
From: "1000085253" <sip:dgg321@[--DOMAIN-HERE--]>;tag=861013891.
To: "anonymous" <sip:1000085110@[--DOMAIN-HERE--]>.
Call-ID: 3335133038 at 10.254.157.104.
Server: IMS Server 1.0.
User-Agent: IMS Client v0.001.
sip:[--DOMAIN-HERE--].
Supported: timer,replaces.
Allow: INVITE,ACK,CANCEL,BYE,SUBSCRIBE,NOTIFY,MESSAGE,INFO,UPDATE.
Accept-Contact: *;description="VT";explicit;require.
Session-Expires: 1800;refresher=uac.
CSeq: 2 INVITE.
Content-Type: application/sdp.
Content-Length: 232.
.
[--SDP-CUTTED--]

than this message was relayed to the client pointed in the Request URI, client answer with response:
SIP/2.0 400 Bad Request.
Via: SIP/2.0/UDP [--IP_HERE--];branch=z9hG4bK2874.9f3e33b6.0.
Via: SIP/2.0/UDP 10.2.166.17;branch=z9hG4bK2874.b998c896.0.
Via: SIP/2.0/UDP [--IP_HERE--];branch=z9hG4bK2874.8f3e33b6.0.
Via: SIP/2.0/UDP 10.254.157.104:5060;received=[--IP_HERE--];branch=z9hG4bK609371529;rport=14259.
Max-Forwards: 70.
From: ""1000085253"" <sip:dgg321@[--DOMAIN_HERE--]>;tag=861013891.
To: ""anonymous"" <sip:1000085110@[--DOMAIN_HERE--]>.
Call-ID: 3335133038 at 10.254.157.104.
CSeq: 2 INVITE.
Content-Length: 0.

but opensips still trying to retransmit initial invite to client...

First of all, in accordance with RFC3261 (Section 8.1.1.8) INVITE without "Contact" header must be rejected. 
I see, I can reject such message using configuration to check presentity of this header in INVITE message, but it would be better when it will be done thru the parser/tm modules by opensips.

Second is the question: why opensips try to retransmit initial INVITE when response was already recieved.

version: opensips 1.5.3-notls (x86_64/linux)
flags: STATS: Off, USE_IPV6, USE_TCP, DISABLE_NAGLE, USE_MCAST, SHM_MEM, SHM_MMAP, PKG_MALLOC, F_MALLOC, FAST_LOCK-ADAPTIVE_WAIT
ADAPTIVE_WAIT_LOOPS=1024, MAX_RECV_BUFFER_SIZE 262144, MAX_LISTEN 16, MAX_URI_SIZE 1024, BUF_SIZE 65535
poll method support: poll, epoll_lt, epoll_et, sigio_rt, select.
svnrevision: 4:921M
@(#) $Id: main.c 5887 2009-07-16 11:47:46Z bogdan_iancu $
main.c compiled on 18:10:15 Dec 29 2009 with gcc 4.1.2


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

>Comment By: Bogdan-Andrei Iancu (bogdan_iancu)
Date: 2010-01-15 13:21

Message:
Sure, please send me the stuff on bogdan at voice dash system dot ro

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

Comment By: Alexey Nikolaev (iamthedeath)
Date: 2010-01-15 11:03

Message:
Hi, Bogdan.

I have reproduce the problem with 400 reply and have taken logs with
debug=6. Is it possible to share debug privately to you?

Thanks.
Alexey.

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

Comment By: Alexey Nikolaev (iamthedeath)
Date: 2010-01-11 13:40

Message:
Hi, Bogdan.

Sorry for the delay with answer. Happy new year! :)
I'll try to reproduce this with more detailed debug.

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

Comment By: Bogdan-Andrei Iancu (bogdan_iancu)
Date: 2010-01-04 17:22

Message:
Hi Alexey ,

For the first issue, contact related, if you want to do some very advanced
sanity checks, you need to do them explicitly from the script. OpenSIPS is
checking by default just the syntax part and the elements it is interested
in.

Now, about the 400 reply and retransmission...Are you sure OpenSIPS is
receiving the 400 reply? can you run in full debug (debug=6) and post the
part corresponding the reply processing ?

Regards,
Bogdan

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

Comment By: Alexey Nikolaev (iamthedeath)
Date: 2009-12-30 13:29

Message:
Forget to login. This is my issue.

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

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


From bogdan at voice-system.ro  Fri Jan 15 12:48:16 2010
From: bogdan at voice-system.ro (Bogdan-Andrei Iancu)
Date: Fri, 15 Jan 2010 13:48:16 +0200
Subject: [OpenSIPS-Devel] Debugging crash
In-Reply-To: <F5B5EF8F78C0BC4BB417E1DBB9D7F7D00BA0E5AA32@jjex01.jajah.dublin>
References: <F5B5EF8F78C0BC4BB417E1DBB9D7F7D00B99CBE182@jjex01.jajah.dublin>	<F5B5EF8F78C0BC4BB417E1DBB9D7F7D00B99CBE196@jjex01.jajah.dublin>	<F5B5EF8F78C0BC4BB417E1DBB9D7F7D00B99CBE214@jjex01.jajah.dublin>	<4B4F5D19.20005@voice-system.ro>
	<F5B5EF8F78C0BC4BB417E1DBB9D7F7D00BA0E5AA32@jjex01.jajah.dublin>
Message-ID: <4B505600.1000705@voice-system.ro>

Hi Alex,

I see - I guess you did some extension to simulate non blocking radius 
acc and this triggers the problem in the lib.

Regarding the question - to make the acc non-blocking is something to be 
normally done in the lib radius (like the net functions do allow you to 
use them into a non-blocking way). Trying to emulate non-blocking in 
opensips for blocking function is a kind of ugly and bullsxxt stuff.

Anyhow, we are preparing the new design for opensips - probably it will 
be published next week or so. It will solve all these problems.

Regards,
Bogdan

Regards,
Bogdan

Alex Massover wrote:
> Hi!
>
> I use DNS. As far as I understand the reason could be that libradiusclient use gethostbyaddr() which is not reentrant and I call to libradiusclient in threads.
>
> So I recompiled libradiusclient with -D_REENTRANT.
>
> Afterwards it crashed also in libradiusclient in free() - no idea meanwhile how it happened. Just to be sure I added one more if() before sending it to free().
>
> The strange thing is that crash happens only after several hours of stress test, after processing thousands of calls.
> AFAIU it looks like memory corruption.
>
> Now I recompiled everything with -O0 and run with _MALLOCK_CHECK=1, meanwhile it's ok.
>
> Can you think about any special complication of opening threads to make accounting non-blocking?
>
>
> --
> Sincerely yours,
> Alex Massover
> VoIP R&D TL
> Jajah Inc.
>
>   
>> -----Original Message-----
>> From: devel-bounces at lists.opensips.org [mailto:devel-
>> bounces at lists.opensips.org] On Behalf Of Bogdan-Andrei Iancu
>> Sent: Thursday, January 14, 2010 8:06 PM
>> To: OpenSIPS devel mailling list
>> Subject: Re: [OpenSIPS-Devel] Debugging crash
>>
>> Hi Alex,
>>
>> The crash looks to be in the libradiusclient stuff....and not in the
>> opensips part.
>>
>> Looking at the backtrace, it seams the lib tries to resolve the name of
>> the acc server - do you use DNS or IP for it?
>>
>> Regards,
>> Bogdan
>>
>> Alex Massover wrote:
>>     
>>> Hmmm... -D_REENTRANT supposed to help here?
>>>
>>> --
>>>
>>> Best Regards,
>>>
>>> Alex Massover
>>>
>>> VoIP R&D TL
>>>
>>> Jajah Inc.
>>>
>>> *From:* devel-bounces at lists.opensips.org
>>> [mailto:devel-bounces at lists.opensips.org] *On Behalf Of *Alex
>>>       
>> Massover
>>     
>>> *Sent:* Monday, January 11, 2010 12:21 PM
>>> *To:* OpenSIPS devel mailling list
>>> *Subject:* Re: [OpenSIPS-Devel] Debugging crash
>>>
>>> Here's a backtrace:
>>>
>>> #0 0xb7fcf424 in __kernel_vsyscall ()
>>>
>>> (gdb) bt
>>>
>>> #0 0xb7fcf424 in __kernel_vsyscall ()
>>>
>>> #1 0xb7e7c640 in raise () from /lib/i686/cmov/libc.so.6
>>>
>>> #2 0xb7e7e018 in abort () from /lib/i686/cmov/libc.so.6
>>>
>>> #3 0xb7eb93dd in ?? () from /lib/i686/cmov/libc.so.6
>>>
>>> #4 0xb7ebf6b4 in ?? () from /lib/i686/cmov/libc.so.6
>>>
>>> #5 0xb7ec18b6 in free () from /lib/i686/cmov/libc.so.6
>>>
>>> #6 0xb7ebb69d in _IO_file_seekoff () from /lib/i686/cmov/libc.so.6
>>>
>>> #7 0xb7eb1900 in ?? () from /lib/i686/cmov/libc.so.6
>>>
>>> #8 0xb7eb7ea8 in rewind () from /lib/i686/cmov/libc.so.6
>>>
>>> #9 0xb74c7f2e in ?? () from /lib/i686/cmov/libnss_files.so.2
>>>
>>> #10 0xb74c86b8 in _nss_files_gethostbyaddr_r () from
>>> /lib/i686/cmov/libnss_files.so.2
>>>
>>> #11 0xb7f4a5ec in gethostbyaddr_r () from /lib/i686/cmov/libc.so.6
>>>
>>> #12 0xb7f4a3dc in gethostbyaddr () from /lib/i686/cmov/libc.so.6
>>>
>>> #13 0xb7ae75f5 in rc_ip_hostname () from /usr/lib/libradiusclient-
>>>       
>> ng.so.2
>>     
>>> #14 0xb7ae3b5f in rc_send_server () from /usr/lib/libradiusclient-
>>>       
>> ng.so.2
>>     
>>> #15 0xb7ae2b3d in rc_acct () from /usr/lib/libradiusclient-ng.so.2
>>>
>>> #16 0xb7da60cf in rad_send_message () from
>>> /usr/lib/opensips/modules/aaa_radius.so
>>>
>>> #17 0xb7ac6fed in thread_rc_acct () from
>>>       
>> /usr/lib/opensips/modules/acc.so
>>     
>>> #18 0xb7ba54c0 in start_thread () from /lib/i686/cmov/libpthread.so.0
>>>
>>> #19 0xb7f3161e in clone () from /lib/i686/cmov/libc.so.6
>>>
>>> --
>>>
>>> Best Regards,
>>>
>>> Alex Massover
>>>
>>> VoIP R&D TL
>>>
>>> Jajah Inc.
>>>
>>> *From:* devel-bounces at lists.opensips.org
>>> [mailto:devel-bounces at lists.opensips.org] *On Behalf Of *Alex
>>>       
>> Massover
>>     
>>> *Sent:* Monday, January 11, 2010 12:04 PM
>>> *To:* OpenSIPS devel mailling list
>>> *Subject:* [OpenSIPS-Devel] Debugging crash
>>>
>>> Hi!
>>>
>>> We're running a stress test and after some time (tens of minutes and
>>> hundreds of processes calls) OpenSIPS 1.6.0 crashes.
>>>
>>> Below is an output of gdb. OpenSIPS is slightly tuned for
>>>       
>> performance:
>>     
>>> a) RADIUS accounting is sent in detached thread
>>>
>>> b) Libradius-ng uses shared memory & atomic memory access instead of
>>> seqfile
>>>
>>> Any tip where/how to dig please?
>>>
>>> (gdb) core core.opensips.sig6.11596
>>>
>>> [New Thread 30240]
>>>
>>> [New Thread 30238]
>>>
>>> [New Thread 30231]
>>>
>>> [New Thread 30229]
>>>
>>> [New Thread 30203]
>>>
>>> [New Thread 30191]
>>>
>>> [New Thread 30183]
>>>
>>> [New Thread 30165]
>>>
>>> [New Thread 30159]
>>>
>>> [New Thread 30155]
>>>
>>> [New Thread 30142]
>>>
>>> [New Thread 30130]
>>>
>>> [New Thread 30126]
>>>
>>> [New Thread 30103]
>>>
>>> [New Thread 30070]
>>>
>>> [New Thread 30037]
>>>
>>> [New Thread 30010]
>>>
>>> [New Thread 29966]
>>>
>>> [New Thread 29912]
>>>
>>> [New Thread 29862]
>>>
>>> [New Thread 29818]
>>>
>>> [New Thread 29742]
>>>
>>> [New Thread 29715]
>>>
>>> [New Thread 29682]
>>>
>>> [New Thread 29628]
>>>
>>> [New Thread 29597]
>>>
>>> [New Thread 29586]
>>>
>>> [New Thread 29561]
>>>
>>> [New Thread 29491]
>>>
>>> [New Thread 29396]
>>>
>>> [New Thread 29366]
>>>
>>> [New Thread 29359]
>>>
>>> [New Thread 29316]
>>>
>>> [New Thread 29305]
>>>
>>> [New Thread 29278]
>>>
>>> [New Thread 29264]
>>>
>>> [New Thread 29260]
>>>
>>> [New Thread 29238]
>>>
>>> [New Thread 29235]
>>>
>>> [New Thread 29210]
>>>
>>> [New Thread 29184]
>>>
>>> [New Thread 29136]
>>>
>>> [New Thread 29132]
>>>
>>> [New Thread 11596]
>>>
>>> Core was generated by `/usr/sbin/opensips -P
>>> /var/run/opensips/opensips.pid -m 32 -u opensips -g opens'.
>>>
>>> Program terminated with signal 6, Aborted.
>>>
>>> #0 0xb7fcf424 in __kernel_vsyscall ()
>>>
>>> --
>>>       



From bogdan at voice-system.ro  Fri Jan 15 12:52:37 2010
From: bogdan at voice-system.ro (Bogdan-Andrei Iancu)
Date: Fri, 15 Jan 2010 13:52:37 +0200
Subject: [OpenSIPS-Devel] Share SIP Messages between 2 processes
In-Reply-To: <99667a341001142300h743ba051xd6fda085cab53061@mail.gmail.com>
References: <99667a341001140845o46de7f0awa9194b66894cf4a7@mail.gmail.com>	<99667a341001140846g50a5cac6i3a9f844145937f83@mail.gmail.com>	<4B4F5A81.6030809@voice-system.ro>
	<99667a341001142300h743ba051xd6fda085cab53061@mail.gmail.com>
Message-ID: <4B505705.5040308@voice-system.ro>

Olivier D?tour wrote:
> On Thu, Jan 14, 2010 at 6:55 PM, Bogdan-Andrei Iancu
> <bogdan at voice-system.ro> wrote:
>   
>> Hi Olivier,
>>
>> Olivier D?tour wrote:
>>     
>>> Hi,
>>>
>>> I'm writing a B2B module for the B2B_entities module (like B2B_logic).
>>> In my initialisation,
>>> I create an extra process to poll on an extra FD to receive order to
>>> create UAC part.
>>>
>>>       
>> Why don't you use the MI stuff for this? you can trigger an action /
>> event by sending an MI command to the server -> you module just has to
>> export a new MI function.
>>     
>>> I would like to know how to share a SIP message between the module and
>>> the extra process
>>> (I'm using OpenSIPs in fork mode ...) ? I tried to shm_malloc it but I
>>> get an out of memory error
>>> on the second Communication.
>>>
>>>       
>> normally using shm_malloc is the trick, but depends of where you fork
>> your process (if the shm is inherited) and who you use it for
>> transferring data from from A to B.
>>     
>
> Forks come from OpenSIPs itself (worker forks + my extra fork (extra
> process in module declaration)).
>   
OK, that's correct
> I think I have to use shared memory to share data between different
> processes. I tried to find the best and the most optimize way to use
> it.
>   
yes, you should use the sh mem. But what exactly do faile for you? I 
mean what exactly are you doing and what step fails? is the malloc not 
working? or ?
> Do you know actually, how much percent of the 32 MB of shared memory,
> is used by OpenSIPs ?
>   
Depends of what modules you are using - each module may have some 
internal data structures that are kept in shm mem.
You can check this via MI interface, after starting opensips (with no 
ongoing traffic) : "opensipsctl fifo get_statistics all"

Regards,
Bogdan

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



From alex at jajah.com  Fri Jan 15 13:09:42 2010
From: alex at jajah.com (Alex Massover)
Date: Fri, 15 Jan 2010 14:09:42 +0200
Subject: [OpenSIPS-Devel] Debugging crash
In-Reply-To: <4B505600.1000705@voice-system.ro>
References: <F5B5EF8F78C0BC4BB417E1DBB9D7F7D00B99CBE182@jjex01.jajah.dublin>
	<F5B5EF8F78C0BC4BB417E1DBB9D7F7D00B99CBE196@jjex01.jajah.dublin>
	<F5B5EF8F78C0BC4BB417E1DBB9D7F7D00B99CBE214@jjex01.jajah.dublin>
	<4B4F5D19.20005@voice-system.ro>
	<F5B5EF8F78C0BC4BB417E1DBB9D7F7D00BA0E5AA32@jjex01.jajah.dublin>
	<4B505600.1000705@voice-system.ro>
Message-ID: <F5B5EF8F78C0BC4BB417E1DBB9D7F7D00BA0E5AA56@jjex01.jajah.dublin>

Yes, you right, I should have done it in the libradiusclient rather than hacking acc module.
Now it runs already for 18 hours - so I suppose it's OK for now, before the new design is available.

Thanks and looking forward to switch to the new opensips architecture! :)
--
Sincerely yours,
Alex Massover
VoIP R&D TL
Jajah Inc.

> -----Original Message-----
> From: devel-bounces at lists.opensips.org [mailto:devel-
> bounces at lists.opensips.org] On Behalf Of Bogdan-Andrei Iancu
> Sent: Friday, January 15, 2010 1:48 PM
> To: OpenSIPS devel mailling list
> Subject: Re: [OpenSIPS-Devel] Debugging crash
> 
> Hi Alex,
> 
> I see - I guess you did some extension to simulate non blocking radius
> acc and this triggers the problem in the lib.
> 
> Regarding the question - to make the acc non-blocking is something to
> be
> normally done in the lib radius (like the net functions do allow you to
> use them into a non-blocking way). Trying to emulate non-blocking in
> opensips for blocking function is a kind of ugly and bullsxxt stuff.
> 
> Anyhow, we are preparing the new design for opensips - probably it will
> be published next week or so. It will solve all these problems.
> 
> Regards,
> Bogdan
> 
> Regards,
> Bogdan
> 
> Alex Massover wrote:
> > Hi!
> >
> > I use DNS. As far as I understand the reason could be that
> libradiusclient use gethostbyaddr() which is not reentrant and I call
> to libradiusclient in threads.
> >
> > So I recompiled libradiusclient with -D_REENTRANT.
> >
> > Afterwards it crashed also in libradiusclient in free() - no idea
> meanwhile how it happened. Just to be sure I added one more if() before
> sending it to free().
> >
> > The strange thing is that crash happens only after several hours of
> stress test, after processing thousands of calls.
> > AFAIU it looks like memory corruption.
> >
> > Now I recompiled everything with -O0 and run with _MALLOCK_CHECK=1,
> meanwhile it's ok.
> >
> > Can you think about any special complication of opening threads to
> make accounting non-blocking?
> >
> >
> > --
> > Sincerely yours,
> > Alex Massover
> > VoIP R&D TL
> > Jajah Inc.
> >
> >
> >> -----Original Message-----
> >> From: devel-bounces at lists.opensips.org [mailto:devel-
> >> bounces at lists.opensips.org] On Behalf Of Bogdan-Andrei Iancu
> >> Sent: Thursday, January 14, 2010 8:06 PM
> >> To: OpenSIPS devel mailling list
> >> Subject: Re: [OpenSIPS-Devel] Debugging crash
> >>
> >> Hi Alex,
> >>
> >> The crash looks to be in the libradiusclient stuff....and not in the
> >> opensips part.
> >>
> >> Looking at the backtrace, it seams the lib tries to resolve the name
> of
> >> the acc server - do you use DNS or IP for it?
> >>
> >> Regards,
> >> Bogdan
> >>
> >> Alex Massover wrote:
> >>
> >>> Hmmm... -D_REENTRANT supposed to help here?
> >>>
> >>> --
> >>>
> >>> Best Regards,
> >>>
> >>> Alex Massover
> >>>
> >>> VoIP R&D TL
> >>>
> >>> Jajah Inc.
> >>>
> >>> *From:* devel-bounces at lists.opensips.org
> >>> [mailto:devel-bounces at lists.opensips.org] *On Behalf Of *Alex
> >>>
> >> Massover
> >>
> >>> *Sent:* Monday, January 11, 2010 12:21 PM
> >>> *To:* OpenSIPS devel mailling list
> >>> *Subject:* Re: [OpenSIPS-Devel] Debugging crash
> >>>
> >>> Here's a backtrace:
> >>>
> >>> #0 0xb7fcf424 in __kernel_vsyscall ()
> >>>
> >>> (gdb) bt
> >>>
> >>> #0 0xb7fcf424 in __kernel_vsyscall ()
> >>>
> >>> #1 0xb7e7c640 in raise () from /lib/i686/cmov/libc.so.6
> >>>
> >>> #2 0xb7e7e018 in abort () from /lib/i686/cmov/libc.so.6
> >>>
> >>> #3 0xb7eb93dd in ?? () from /lib/i686/cmov/libc.so.6
> >>>
> >>> #4 0xb7ebf6b4 in ?? () from /lib/i686/cmov/libc.so.6
> >>>
> >>> #5 0xb7ec18b6 in free () from /lib/i686/cmov/libc.so.6
> >>>
> >>> #6 0xb7ebb69d in _IO_file_seekoff () from /lib/i686/cmov/libc.so.6
> >>>
> >>> #7 0xb7eb1900 in ?? () from /lib/i686/cmov/libc.so.6
> >>>
> >>> #8 0xb7eb7ea8 in rewind () from /lib/i686/cmov/libc.so.6
> >>>
> >>> #9 0xb74c7f2e in ?? () from /lib/i686/cmov/libnss_files.so.2
> >>>
> >>> #10 0xb74c86b8 in _nss_files_gethostbyaddr_r () from
> >>> /lib/i686/cmov/libnss_files.so.2
> >>>
> >>> #11 0xb7f4a5ec in gethostbyaddr_r () from /lib/i686/cmov/libc.so.6
> >>>
> >>> #12 0xb7f4a3dc in gethostbyaddr () from /lib/i686/cmov/libc.so.6
> >>>
> >>> #13 0xb7ae75f5 in rc_ip_hostname () from /usr/lib/libradiusclient-
> >>>
> >> ng.so.2
> >>
> >>> #14 0xb7ae3b5f in rc_send_server () from /usr/lib/libradiusclient-
> >>>
> >> ng.so.2
> >>
> >>> #15 0xb7ae2b3d in rc_acct () from /usr/lib/libradiusclient-ng.so.2
> >>>
> >>> #16 0xb7da60cf in rad_send_message () from
> >>> /usr/lib/opensips/modules/aaa_radius.so
> >>>
> >>> #17 0xb7ac6fed in thread_rc_acct () from
> >>>
> >> /usr/lib/opensips/modules/acc.so
> >>
> >>> #18 0xb7ba54c0 in start_thread () from
> /lib/i686/cmov/libpthread.so.0
> >>>
> >>> #19 0xb7f3161e in clone () from /lib/i686/cmov/libc.so.6
> >>>
> >>> --
> >>>
> >>> Best Regards,
> >>>
> >>> Alex Massover
> >>>
> >>> VoIP R&D TL
> >>>
> >>> Jajah Inc.
> >>>
> >>> *From:* devel-bounces at lists.opensips.org
> >>> [mailto:devel-bounces at lists.opensips.org] *On Behalf Of *Alex
> >>>
> >> Massover
> >>
> >>> *Sent:* Monday, January 11, 2010 12:04 PM
> >>> *To:* OpenSIPS devel mailling list
> >>> *Subject:* [OpenSIPS-Devel] Debugging crash
> >>>
> >>> Hi!
> >>>
> >>> We're running a stress test and after some time (tens of minutes
> and
> >>> hundreds of processes calls) OpenSIPS 1.6.0 crashes.
> >>>
> >>> Below is an output of gdb. OpenSIPS is slightly tuned for
> >>>
> >> performance:
> >>
> >>> a) RADIUS accounting is sent in detached thread
> >>>
> >>> b) Libradius-ng uses shared memory & atomic memory access instead
> of
> >>> seqfile
> >>>
> >>> Any tip where/how to dig please?
> >>>
> >>> (gdb) core core.opensips.sig6.11596
> >>>
> >>> [New Thread 30240]
> >>>
> >>> [New Thread 30238]
> >>>
> >>> [New Thread 30231]
> >>>
> >>> [New Thread 30229]
> >>>
> >>> [New Thread 30203]
> >>>
> >>> [New Thread 30191]
> >>>
> >>> [New Thread 30183]
> >>>
> >>> [New Thread 30165]
> >>>
> >>> [New Thread 30159]
> >>>
> >>> [New Thread 30155]
> >>>
> >>> [New Thread 30142]
> >>>
> >>> [New Thread 30130]
> >>>
> >>> [New Thread 30126]
> >>>
> >>> [New Thread 30103]
> >>>
> >>> [New Thread 30070]
> >>>
> >>> [New Thread 30037]
> >>>
> >>> [New Thread 30010]
> >>>
> >>> [New Thread 29966]
> >>>
> >>> [New Thread 29912]
> >>>
> >>> [New Thread 29862]
> >>>
> >>> [New Thread 29818]
> >>>
> >>> [New Thread 29742]
> >>>
> >>> [New Thread 29715]
> >>>
> >>> [New Thread 29682]
> >>>
> >>> [New Thread 29628]
> >>>
> >>> [New Thread 29597]
> >>>
> >>> [New Thread 29586]
> >>>
> >>> [New Thread 29561]
> >>>
> >>> [New Thread 29491]
> >>>
> >>> [New Thread 29396]
> >>>
> >>> [New Thread 29366]
> >>>
> >>> [New Thread 29359]
> >>>
> >>> [New Thread 29316]
> >>>
> >>> [New Thread 29305]
> >>>
> >>> [New Thread 29278]
> >>>
> >>> [New Thread 29264]
> >>>
> >>> [New Thread 29260]
> >>>
> >>> [New Thread 29238]
> >>>
> >>> [New Thread 29235]
> >>>
> >>> [New Thread 29210]
> >>>
> >>> [New Thread 29184]
> >>>
> >>> [New Thread 29136]
> >>>
> >>> [New Thread 29132]
> >>>
> >>> [New Thread 11596]
> >>>
> >>> Core was generated by `/usr/sbin/opensips -P
> >>> /var/run/opensips/opensips.pid -m 32 -u opensips -g opens'.
> >>>
> >>> Program terminated with signal 6, Aborted.
> >>>
> >>> #0 0xb7fcf424 in __kernel_vsyscall ()
> >>>
> >>> --
> >>>
> 
> 
> _______________________________________________
> Devel mailing list
> Devel at lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
> 
> This mail was received via Mail-SeCure System.
> 


This mail was sent via Mail-SeCure System.




From noreply at sourceforge.net  Fri Jan 15 13:45:06 2010
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 15 Jan 2010 12:45:06 +0000
Subject: [OpenSIPS-Devel] [ opensips-Bugs-2927295 ] tm module socket write
	problems
Message-ID: <E1NVlY2-0000T7-Sp@d45xhf1.ch3.sourceforge.com>

Bugs item #2927295, was opened at 2010-01-07 04:29
Message generated for change (Comment added) made by bogdan_iancu
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=2927295&group_id=232389

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: modules
Group: 1.6.x
>Status: Closed
Resolution: Fixed
Priority: 5
Private: No
Submitted By: Richard Revels (rrevels)
Assigned to: Bogdan-Andrei Iancu (bogdan_iancu)
Summary: tm module socket write problems

Initial Comment:
Yes there is still a problem in t_fifo.c but I couldn't figure out how to re-open the last tracker.  The parameters declared for t_write_req are vm_fifo and info but the pointers passed to the function are reversed.  It looks like t_write_unix has the same problem.  I fixed the this by swapping the variable names passed to assemble_msg and write_to_fifo but I suspect this isn't the best way to resolve the problem.

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

>Comment By: Bogdan-Andrei Iancu (bogdan_iancu)
Date: 2010-01-15 14:45

Message:
If something new comes up, please reopen of open a new report.

Thanks.
Bogdan

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

Comment By: Bogdan-Andrei Iancu (bogdan_iancu)
Date: 2010-01-08 11:53

Message:
Indeed the two params were swapped . I fixed this on SVN - could you please
test it to see if it works now ?

Thanks and regards,
Bogdan

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

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


From chino540off+kamailio at gmail.com  Fri Jan 15 13:45:35 2010
From: chino540off+kamailio at gmail.com (=?ISO-8859-1?Q?Olivier_D=E9tour?=)
Date: Fri, 15 Jan 2010 13:45:35 +0100
Subject: [OpenSIPS-Devel] Share SIP Messages between 2 processes
In-Reply-To: <4B505705.5040308@voice-system.ro>
References: <99667a341001140845o46de7f0awa9194b66894cf4a7@mail.gmail.com>
	<99667a341001140846g50a5cac6i3a9f844145937f83@mail.gmail.com>
	<4B4F5A81.6030809@voice-system.ro>
	<99667a341001142300h743ba051xd6fda085cab53061@mail.gmail.com>
	<4B505705.5040308@voice-system.ro>
Message-ID: <99667a341001150445g6cac1e4er82b1b0ab5ba75ddc@mail.gmail.com>

On Fri, Jan 15, 2010 at 12:52 PM, Bogdan-Andrei Iancu
<bogdan at voice-system.ro> wrote:
> Olivier D?tour wrote:
>> On Thu, Jan 14, 2010 at 6:55 PM, Bogdan-Andrei Iancu
>> <bogdan at voice-system.ro> wrote:
>>
>>> Hi Olivier,
>>>
>>> Olivier D?tour wrote:
>>>
>>>> Hi,
>>>>
>>>> I'm writing a B2B module for the B2B_entities module (like B2B_logic).
>>>> In my initialisation,
>>>> I create an extra process to poll on an extra FD to receive order to
>>>> create UAC part.
>>>>
>>>>
>>> Why don't you use the MI stuff for this? you can trigger an action /
>>> event by sending an MI command to the server -> you module just has to
>>> export a new MI function.
>>>
>>>> I would like to know how to share a SIP message between the module and
>>>> the extra process
>>>> (I'm using OpenSIPs in fork mode ...) ? I tried to shm_malloc it but I
>>>> get an out of memory error
>>>> on the second Communication.
>>>>
>>>>
>>> normally using shm_malloc is the trick, but depends of where you fork
>>> your process (if the shm is inherited) and who you use it for
>>> transferring data from from A to B.
>>>
>>
>> Forks come from OpenSIPs itself (worker forks + my extra fork (extra
>> process in module declaration)).
>>
> OK, that's correct
>> I think I have to use shared memory to share data between different
>> processes. I tried to find the best and the most optimize way to use
>> it.
>>
> yes, you should use the sh mem. But what exactly do faile for you? I
> mean what exactly are you doing and what step fails? is the malloc not
> working? or ?

When I use B2B, I have to forward my INVITE in another process, that
is why I have to copy it (body, URIs, ...) in my shm_malloced internal
data structure. It works, but I find it ugly.
Moreover, sometimes I get an internal error because I don't have
enough shared memory,
that's why I want to find a better way.

I'm blocked by OpenSIPs' architecture.

If this is the only way, I could optimize it on my side.

>> Do you know actually, how much percent of the 32 MB of shared memory,
>> is used by OpenSIPs ?
>>
> Depends of what modules you are using - each module may have some
> internal data structures that are kept in shm mem.
> You can check this via MI interface, after starting opensips (with no
> ongoing traffic) : "opensipsctl fifo get_statistics all"
>

Thanks for the tips, it will be helpful to debugging.

> Regards,
> Bogdan
>

Regards,

-- 
Olivier D?tour


From noreply at sourceforge.net  Fri Jan 15 13:49:59 2010
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 15 Jan 2010 12:49:59 +0000
Subject: [OpenSIPS-Devel] [ opensips-Bugs-2932845 ] 180 Ringing not forward
	to B2B_logic
Message-ID: <E1NVlcl-0001Fu-DC@565xhf1.ch3.sourceforge.com>

Bugs item #2932845, was opened at 2010-01-15 12:49
Message generated for change (Tracker Item Submitted) made by nobody
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=2932845&group_id=232389

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: modules
Group: 1.6.x
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: 180 Ringing not forward to B2B_logic

Initial Comment:
When a 180 ringing comes on OpenSIPs, it is not forward to B2B_logic module.

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

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


From noreply at sourceforge.net  Fri Jan 15 14:51:05 2010
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 15 Jan 2010 13:51:05 +0000
Subject: [OpenSIPS-Devel] [ opensips-Bugs-2932845 ] 180 Ringing not forward
	to B2B_logic
Message-ID: <E1NVmZt-0002WS-LZ@565xhf1.ch3.sourceforge.com>

Bugs item #2932845, was opened at 2010-01-15 14:49
Message generated for change (Settings changed) made by anca_vamanu
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=2932845&group_id=232389

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: modules
Group: 1.6.x
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Nobody/Anonymous (nobody)
>Assigned to: Anca Vamanu (anca_vamanu)
Summary: 180 Ringing not forward to B2B_logic

Initial Comment:
When a 180 ringing comes on OpenSIPs, it is not forward to B2B_logic module.

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

>Comment By: Anca Vamanu (anca_vamanu)
Date: 2010-01-15 15:51

Message:
Hi,

Have you set the module parameter in tm:
modparam("tm", "pass_provisional_replies", 1) ?

Regards,
Anca

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

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


From bogdan at voice-system.ro  Fri Jan 15 14:51:51 2010
From: bogdan at voice-system.ro (Bogdan-Andrei Iancu)
Date: Fri, 15 Jan 2010 15:51:51 +0200
Subject: [OpenSIPS-Devel] Share SIP Messages between 2 processes
In-Reply-To: <99667a341001150445g6cac1e4er82b1b0ab5ba75ddc@mail.gmail.com>
References: <99667a341001140845o46de7f0awa9194b66894cf4a7@mail.gmail.com>	<99667a341001140846g50a5cac6i3a9f844145937f83@mail.gmail.com>	<4B4F5A81.6030809@voice-system.ro>	<99667a341001142300h743ba051xd6fda085cab53061@mail.gmail.com>	<4B505705.5040308@voice-system.ro>
	<99667a341001150445g6cac1e4er82b1b0ab5ba75ddc@mail.gmail.com>
Message-ID: <4B5072F7.8080309@voice-system.ro>

Olivier D?tour wrote:
>> yes, you should use the sh mem. But what exactly do faile for you? I
>> mean what exactly are you doing and what step fails? is the malloc not
>> working? or ?
>>     
>
> When I use B2B, I have to forward my INVITE in another process, that
> is why I have to copy it (body, URIs, ...) in my shm_malloced internal
> data structure. It works, but I find it ugly.
> Moreover, sometimes I get an internal error because I don't have
> enough shared memory,
> that's why I want to find a better way.
>
>   
In all case, when you have some data to be shared between processes, you 
need so copied in shm mem. The INVITE you mentioned is one received by 
opensips i script ? Because it matter in what type of mem (pkg or shm) 
the message originally resides.

About the not enough mem -> it might me simply not enough mem or can be 
a leak - see http://www.opensips.org/Resources/DocsTsMem

Regards,
Bogdan

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



From chino540off+kamailio at gmail.com  Fri Jan 15 17:44:40 2010
From: chino540off+kamailio at gmail.com (=?ISO-8859-1?Q?Olivier_D=E9tour?=)
Date: Fri, 15 Jan 2010 17:44:40 +0100
Subject: [OpenSIPS-Devel] [ opensips-Bugs-2932845 ] 180 Ringing not
	forward to B2B_logic
In-Reply-To: <E1NVmZt-0002WS-LZ@565xhf1.ch3.sourceforge.com>
References: <E1NVmZt-0002WS-LZ@565xhf1.ch3.sourceforge.com>
Message-ID: <99667a341001150844x4233570fqd8dc4ef37e82c670@mail.gmail.com>

On Fri, Jan 15, 2010 at 2:51 PM, SourceForge.net
<noreply at sourceforge.net> wrote:
> Bugs item #2932845, was opened at 2010-01-15 14:49
> Message generated for change (Settings changed) made by anca_vamanu
> You can respond by visiting:
> https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=2932845&group_id=232389
>
> Please note that this message will contain a full copy of the comment thread,
> including the initial issue submission, for this request,
> not just the latest update.
> Category: modules
> Group: 1.6.x
> Status: Open
> Resolution: None
> Priority: 5
> Private: No
> Submitted By: Nobody/Anonymous (nobody)
>>Assigned to: Anca Vamanu (anca_vamanu)
> Summary: 180 Ringing not forward to B2B_logic
>
> Initial Comment:
> When a 180 ringing comes on OpenSIPs, it is not forward to B2B_logic module.
>
> ----------------------------------------------------------------------
>
>>Comment By: Anca Vamanu (anca_vamanu)
> Date: 2010-01-15 15:51
>
> Message:
> Hi,
>
> Have you set the module parameter in tm:
> modparam("tm", "pass_provisional_replies", 1) ?

Yes, this parameter is set.

>
> Regards,
> Anca


-- 
Olivier D?tour
Sent from Paris, ?le-de-France, France


From di-shi at transnexus.com  Mon Jan 18 04:00:36 2010
From: di-shi at transnexus.com (Di-Shi Sun)
Date: Mon, 18 Jan 2010 03:00:36 +0000
Subject: [OpenSIPS-Devel] SF.net SVN: opensips:[6511] trunk/modules/osp
Message-ID: <E1NWhr2-0001ti-AQ@dn4whf1.ch3.sourceforge.com>

Revision: 6511
          http://opensips.svn.sourceforge.net/opensips/?rev=6511&view=rev
Author:   di-shi
Date:     2010-01-18 03:00:31 +0000 (Mon, 18 Jan 2010)

Log Message:
-----------
1. Changed configuration option proxy_type to service_type.
2. Added operator name support in AuthReq and AuthRsp.

Modified Paths:
--------------
    trunk/modules/osp/README
    trunk/modules/osp/destination.h
    trunk/modules/osp/doc/osp_admin.xml
    trunk/modules/osp/etc/sample-osp-opensips.cfg
    trunk/modules/osp/globals.c
    trunk/modules/osp/orig_transaction.c
    trunk/modules/osp/osp_mod.c
    trunk/modules/osp/osp_mod.h
    trunk/modules/osp/sipheader.c
    trunk/modules/osp/sipheader.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 Jan 19 00:27:23 2010
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 18 Jan 2010 23:27:23 +0000
Subject: [OpenSIPS-Devel] [ opensips-Bugs-2934618 ] possible memory leak in
	serialize.c
Message-ID: <E1NX10F-0000hI-9Y@155xhf1.ch3.sourceforge.com>

Bugs item #2934618, was opened at 2010-01-18 23:27
Message generated for change (Tracker Item Submitted) made by rrevels
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=2934618&group_id=232389

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: core
Group: 1.6.x
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Richard Revels (rrevels)
Assigned to: Nobody/Anonymous (nobody)
Summary: possible memory leak in serialize.c

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

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

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


From develop2009 at schloh.com  Tue Jan 19 16:28:39 2010
From: develop2009 at schloh.com (Michael Schloh von Bennewitz)
Date: Tue, 19 Jan 2010 16:28:39 +0100
Subject: [OpenSIPS-Devel] New contribution, ISN lookup in ENUM module
Message-ID: <20100119152839.GA18762@debut.europalab.com>


Hello list,

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

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

References:

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

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

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

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

Cheers,
Michael

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


From noreply at sourceforge.net  Tue Jan 19 16:56:53 2010
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue, 19 Jan 2010 15:56:53 +0000
Subject: [OpenSIPS-Devel] [ opensips-Bugs-2934618 ] possible memory leak in
	serialize.c
Message-ID: <E1NXGRp-0003OZ-1G@h45xhf1.ch3.sourceforge.com>

Bugs item #2934618, was opened at 2010-01-18 23:27
Message generated for change (Comment added) made by rrevels
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=2934618&group_id=232389

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: core
Group: 1.6.x
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Richard Revels (rrevels)
Assigned to: Nobody/Anonymous (nobody)
Summary: possible memory leak in serialize.c

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

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

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

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

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

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


From emmanuel.buu at ives.fr  Tue Jan 19 18:52:43 2010
From: emmanuel.buu at ives.fr (Emmanuel BUU)
Date: Tue, 19 Jan 2010 18:52:43 +0100
Subject: [OpenSIPS-Devel] disabling outbound TCP connection for nated UA
In-Reply-To: <20100119152839.GA18762@debut.europalab.com>
References: <20100119152839.GA18762@debut.europalab.com>
Message-ID: <4B55F16B.7000202@ives.fr>

Hello,

Is there a way in the TM module to prevent opensips to open an outbound 
TCP connection in case the destination is nated?

Emmanuel


From develop2009 at schloh.com  Tue Jan 19 19:03:50 2010
From: develop2009 at schloh.com (Michael Schloh von Bennewitz)
Date: Tue, 19 Jan 2010 19:03:50 +0100
Subject: [OpenSIPS-Devel] New contribution, ISN lookup in ENUM module
In-Reply-To: <4B55F16B.7000202@ives.fr>
References: <20100119152839.GA18762@debut.europalab.com>
	<4B55F16B.7000202@ives.fr>
Message-ID: <20100119180350.GB2490@debut.europalab.com>


Hello Emmanuel,

On Tues., Jan 19, 2010, Emmanuel BUU wrote:
>Is there a way in the TM module to prevent opensips to open
>an outbound TCP connection in case the destination is nated?
>
The ISN and ENUM logic does not open TCP connections. I believe
the DNS resolution is all UDP. In any case, there is no dependency
between the ENUM module and anything NAT related such as nathelper
or nat_traversal. Those things are up to you to sort out in the
route script.

Regards,
Michael

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


From noreply at sourceforge.net  Wed Jan 20 00:04:10 2010
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue, 19 Jan 2010 23:04:10 +0000
Subject: [OpenSIPS-Devel] [ opensips-Patches-2935297 ] drouting wildcard '%'
	dr_groups username support
Message-ID: <E1NXN7K-0003rc-RQ@b55xhf1.ch3.sourceforge.com>

Patches item #2935297, was opened at 2010-01-19 17:04
Message generated for change (Tracker Item Submitted) made by jarrodpy
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086412&aid=2935297&group_id=232389

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: modules
Group: 1.6.x
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Jarrod Baumann (jarrodpy)
Assigned to: Nobody/Anonymous (nobody)
Summary: drouting wildcard '%' dr_groups username support

Initial Comment:
When routing traffic for numerous gateways, the username field may sometimes be various values or omitted altogether.  Also, without domain support, a wildcard/catchall username may be used for a "default" route.  This *ugly* patch makes this possible by using '%' for the username in dr_groups.

The patch moves the matching pattern off of sql and into drouting.c which should not impact the speed.

# patch -p1 opensips-1.6.1-tls/modules/drouting/drouting.c < drouting.patch

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

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


From develop2009 at schloh.com  Wed Jan 20 11:17:02 2010
From: develop2009 at schloh.com (Michael Schloh von Bennewitz)
Date: Wed, 20 Jan 2010 11:17:02 +0100
Subject: [OpenSIPS-Devel] Possible bug in dbt_lib.c with suggested correction
Message-ID: <20100120101701.GA26836@debut.europalab.com>


Hello list,

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

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


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

Regards,
Michael

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


From bogdan at voice-system.ro  Wed Jan 20 14:04:36 2010
From: bogdan at voice-system.ro (Bogdan-Andrei Iancu)
Date: Wed, 20 Jan 2010 13:04:36 +0000
Subject: [OpenSIPS-Devel] SF.net SVN: opensips:[6512] trunk/modules/tm
Message-ID: <E1NXaEe-00067V-Ea@3kljzd1.ch3.sourceforge.com>

Revision: 6512
          http://opensips.svn.sourceforge.net/opensips/?rev=6512&view=rev
Author:   bogdan_iancu
Date:     2010-01-20 13:04:36 +0000 (Wed, 20 Jan 2010)

Log Message:
-----------
new TM API function new_auto_dlg_uac() - an extension of new_dlg_uac() that takes care by itself to generate callid, from_tag, and cseq

Modified Paths:
--------------
    trunk/modules/tm/dlg.c
    trunk/modules/tm/dlg.h
    trunk/modules/tm/tm.c
    trunk/modules/tm/tm_load.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  Wed Jan 20 14:13:23 2010
From: bogdan at voice-system.ro (Bogdan-Andrei Iancu)
Date: Wed, 20 Jan 2010 13:13:23 +0000
Subject: [OpenSIPS-Devel] SF.net SVN: opensips:[6513]
	trunk/modules/dispatcher
Message-ID: <E1NXaN9-0006GR-Sn@3kljzd1.ch3.sourceforge.com>

Revision: 6513
          http://opensips.svn.sourceforge.net/opensips/?rev=6513&view=rev
Author:   bogdan_iancu
Date:     2010-01-20 13:13:23 +0000 (Wed, 20 Jan 2010)

Log Message:
-----------
- new parameter added "ds_probing_sock" to allow setting a specific socket to be used for sending the probing requests.

Modified Paths:
--------------
    trunk/modules/dispatcher/README
    trunk/modules/dispatcher/dispatch.c
    trunk/modules/dispatcher/dispatcher.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  Wed Jan 20 15:43:46 2010
From: bogdan at voice-system.ro (Bogdan-Andrei Iancu)
Date: Wed, 20 Jan 2010 16:43:46 +0200
Subject: [OpenSIPS-Devel] Possible bug in dbt_lib.c with suggested
	correction
In-Reply-To: <20100120101701.GA26836@debut.europalab.com>
References: <20100120101701.GA26836@debut.europalab.com>
Message-ID: <4B5716A2.3030209@voice-system.ro>

Hi Michael,

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

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

Regards,
Bogdan

Michael Schloh von Bennewitz wrote:
> Hello list,
>
> It would seem that Bogdan's recent correction relating to the BLOB
> datatype support was not complete.
>
> Index: modules/db_text/dbt_lib.c
> diff -Nau modules/db_text/dbt_lib.c.orig modules/db_text/dbt_lib.c
> --- modules/db_text/dbt_lib.c.orig	2010-01-20 11:10:07.967990871 +0100
> +++ modules/db_text/dbt_lib.c	2010-01-20 11:10:21.649138475 +0100
> @@ -440,7 +440,7 @@
>  		case DB_DOUBLE:
>  			break;
>  		case DB_STRING:
> -			if(_t0==DB_STR)
> +			if(_t0==DB_STR || _t0==DB_BLOB)
>  				return 0;
>  		case DB_STR:
>  			if(_t0==DB_STRING || _t0==DB_BLOB)
>
>
> The '-' and '+' indicate my suggested correction, keeping in line
> with Bogdans recent change SVN revision 6382.
>
> Regards,
> Michael
>
>   


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



From develop2009 at schloh.com  Wed Jan 20 16:06:07 2010
From: develop2009 at schloh.com (Michael Schloh von Bennewitz)
Date: Wed, 20 Jan 2010 16:06:07 +0100
Subject: [OpenSIPS-Devel] Possible bug in dbt_lib.c with
	suggested	correction
In-Reply-To: <4B5716A2.3030209@voice-system.ro>
References: <20100120101701.GA26836@debut.europalab.com>
	<4B5716A2.3030209@voice-system.ro>
Message-ID: <20100120150607.GB8374@debut.europalab.com>


Hello Bogdan,

On Tues., Jan 20, 2010, Bogdan-Andrei Iancu wrote:
>Michael Schloh von Bennewitz wrote:
>> Hello list,
>>
>> It would seem that Bogdan's recent correction relating to the BLOB
>> datatype support was not complete.
>>
>> Index: modules/db_text/dbt_lib.c
>> diff -Nau modules/db_text/dbt_lib.c.orig modules/db_text/dbt_lib.c
>> --- modules/db_text/dbt_lib.c.orig	2010-01-20 11:10:07.967990871 +0100
>> +++ modules/db_text/dbt_lib.c	2010-01-20 11:10:21.649138475 +0100
>> @@ -440,7 +440,7 @@
>>  		case DB_DOUBLE:
>>  			break;
>>  		case DB_STRING:
>> -			if(_t0==DB_STR)
>> +			if(_t0==DB_STR || _t0==DB_BLOB)
>>  				return 0;
>>  		case DB_STR:
>>  			if(_t0==DB_STRING || _t0==DB_BLOB)
>>
>>
>> The '-' and '+' indicate my suggested correction, keeping in line
>> with Bogdan's recent change SVN revision 6382.
>>
>Have this fix resulted from troubleshooting some error ? or it is a
>logical fix ?
>
Your own comment for checkin 6382 is 'fixed incomatibility between
BLOB data type and string format for columns' and your change is:

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

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

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

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

>Because the STRING and BLOB times are not really compatible. STRING
>is zero terminated data while BLOB contains data (including 0), if
>you get my point.
>
Just how different are DB_STRING and DB_STR? Is one zero terminated
and the other not? If that's right, then maybe the best thing is to
return 0 when comparing DB_BLOB with whichever [DB_STR|DB_STRING] is
most similar (in which zero termination plays a role in deciding.)

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

Regards,
Michael

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


From chino540off+kamailio at gmail.com  Wed Jan 20 16:06:54 2010
From: chino540off+kamailio at gmail.com (=?ISO-8859-1?Q?Olivier_D=E9tour?=)
Date: Wed, 20 Jan 2010 16:06:54 +0100
Subject: [OpenSIPS-Devel] [ opensips-Bugs-2932845 ] 180 Ringing not
	forward to B2B_logic
In-Reply-To: <99667a341001150844x4233570fqd8dc4ef37e82c670@mail.gmail.com>
References: <E1NVmZt-0002WS-LZ@565xhf1.ch3.sourceforge.com>
	<99667a341001150844x4233570fqd8dc4ef37e82c670@mail.gmail.com>
Message-ID: <99667a341001200706j64566f56u3f64dbc728211fb4@mail.gmail.com>

2010/1/15 Olivier D?tour <chino540off+kamailio at gmail.com>:
> On Fri, Jan 15, 2010 at 2:51 PM, SourceForge.net
> <noreply at sourceforge.net> wrote:
>> Bugs item #2932845, was opened at 2010-01-15 14:49
>> Message generated for change (Settings changed) made by anca_vamanu
>> You can respond by visiting:
>> https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=2932845&group_id=232389
>>
>> Please note that this message will contain a full copy of the comment thread,
>> including the initial issue submission, for this request,
>> not just the latest update.
>> Category: modules
>> Group: 1.6.x
>> Status: Open
>> Resolution: None
>> Priority: 5
>> Private: No
>> Submitted By: Nobody/Anonymous (nobody)
>>>Assigned to: Anca Vamanu (anca_vamanu)
>> Summary: 180 Ringing not forward to B2B_logic
>>
>> Initial Comment:
>> When a 180 ringing comes on OpenSIPs, it is not forward to B2B_logic module.
>>
>> ----------------------------------------------------------------------
>>
>>>Comment By: Anca Vamanu (anca_vamanu)
>> Date: 2010-01-15 15:51
>>
>> Message:
>> Hi,
>>
>> Have you set the module parameter in tm:
>> modparam("tm", "pass_provisional_replies", 1) ?
>
> Yes, this parameter is set.
>
>>
>> Regards,
>> Anca
>
>

As the precedent problem, why ACK request is not forward to the client module ?
I would like to get ACK after sending a 4xx reply to remove my context.
If I remove it after sending 4xx, ACK is received by B2B_entities but
there is no dialogue
for my key.

How I could do something ?

Regards,

-- 
Olivier D?tour
Sent from Paris, ?le-de-France, France


From bogdan at voice-system.ro  Wed Jan 20 16:19:55 2010
From: bogdan at voice-system.ro (Bogdan-Andrei Iancu)
Date: Wed, 20 Jan 2010 15:19:55 +0000
Subject: [OpenSIPS-Devel] SF.net SVN: opensips:[6514]
	trunk/parser/parse_multipart.c
Message-ID: <E1NXcLb-0004wW-D4@c3vjzd1.ch3.sourceforge.com>

Revision: 6514
          http://opensips.svn.sourceforge.net/opensips/?rev=6514&view=rev
Author:   bogdan_iancu
Date:     2010-01-20 15:19:29 +0000 (Wed, 20 Jan 2010)

Log Message:
-----------
- fixed memory leak in multibody parser

Modified Paths:
--------------
    trunk/parser/parse_multipart.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 Jan 20 16:23:01 2010
From: bogdan at voice-system.ro (Bogdan-Andrei Iancu)
Date: Wed, 20 Jan 2010 15:23:01 +0000
Subject: [OpenSIPS-Devel] SF.net SVN: opensips:[6515]
	branches/1.6/parser/parse_multipart.c
Message-ID: <E1NXcOb-00051P-L5@c3vjzd1.ch3.sourceforge.com>

Revision: 6515
          http://opensips.svn.sourceforge.net/opensips/?rev=6515&view=rev
Author:   bogdan_iancu
Date:     2010-01-20 15:22:56 +0000 (Wed, 20 Jan 2010)

Log Message:
-----------
backport from trunk (rev #6514)
- fixed memory leak in multibody parser

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

Modified Paths:
--------------
    branches/1.6/parser/parse_multipart.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 Jan 21 11:01:09 2010
From: bogdan at voice-system.ro (Bogdan-Andrei Iancu)
Date: Thu, 21 Jan 2010 12:01:09 +0200
Subject: [OpenSIPS-Devel] Building Telephony Systems with OpenSIPS
Message-ID: <4B5825E5.60201@voice-system.ro>

Thanks to Flavio E. Goncalves, a new edition of "Building Telephony 
Systems with OpenSIPS" is now available.

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

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

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

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

Regards,
Bogdan

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


From noreply at sourceforge.net  Thu Jan 21 14:51:28 2010
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 21 Jan 2010 13:51:28 +0000
Subject: [OpenSIPS-Devel] [ opensips-Bugs-2936343 ] 'opensipsctl fifo
	get_statistics all' crashes opensips
Message-ID: <E1NXxRY-0007C0-Pu@3bkjzd1.ch3.sourceforge.com>

Bugs item #2936343, was opened at 2010-01-21 15:51
Message generated for change (Tracker Item Submitted) made by cupotka2008
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=2936343&group_id=232389

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: modules
Group: 1.6.x
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Alex Massover (cupotka2008)
Assigned to: Nobody/Anonymous (nobody)
Summary: 'opensipsctl fifo get_statistics all' crashes opensips

Initial Comment:
Hi!

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

Here's a strace of parent process:

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


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

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


From noreply at sourceforge.net  Thu Jan 21 16:01:37 2010
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 21 Jan 2010 15:01:37 +0000
Subject: [OpenSIPS-Devel] [ opensips-Bugs-2934618 ] possible memory leak in
	serialize.c
Message-ID: <E1NXyXR-0005Yb-Tf@d55xhf1.ch3.sourceforge.com>

Bugs item #2934618, was opened at 2010-01-19 01:27
Message generated for change (Settings changed) made by bogdan_iancu
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=2934618&group_id=232389

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: core
Group: 1.6.x
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Richard Revels (rrevels)
>Assigned to: Bogdan-Andrei Iancu (bogdan_iancu)
Summary: possible memory leak in serialize.c

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

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

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

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

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

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


From noreply at sourceforge.net  Thu Jan 21 16:56:10 2010
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 21 Jan 2010 15:56:10 +0000
Subject: [OpenSIPS-Devel] [ opensips-Bugs-2936420 ] typo in load balancer
	documentation
Message-ID: <E1NXzOE-0006he-B0@d45xhf1.ch3.sourceforge.com>

Bugs item #2936420, was opened at 2010-01-21 15:56
Message generated for change (Tracker Item Submitted) made by nobody
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=2936420&group_id=232389

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: docs
Group: trunk
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: typo in load balancer documentation

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

Example 1.7. set_dlg_profile usage

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

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

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

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

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


From chino540off+kamailio at gmail.com  Thu Jan 21 17:53:46 2010
From: chino540off+kamailio at gmail.com (=?ISO-8859-1?Q?Olivier_D=E9tour?=)
Date: Thu, 21 Jan 2010 17:53:46 +0100
Subject: [OpenSIPS-Devel] [B2B_ENTITIES] ACK Strategy
Message-ID: <99667a341001210853l2ee98f1arff8d277aa77488d8@mail.gmail.com>

Hi,

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

Thanks,

Regards,

-- 
Olivier D?tour


From noreply at sourceforge.net  Thu Jan 21 18:34:48 2010
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 21 Jan 2010 17:34:48 +0000
Subject: [OpenSIPS-Devel] [ opensips-Bugs-2934618 ] possible memory leak in
	serialize.c
Message-ID: <E1NY0vg-00007f-1O@565xhf1.ch3.sourceforge.com>

Bugs item #2934618, was opened at 2010-01-19 01:27
Message generated for change (Comment added) made by bogdan_iancu
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=2934618&group_id=232389

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: core
Group: 1.6.x
Status: Open
>Resolution: Fixed
Priority: 5
Private: No
Submitted By: Richard Revels (rrevels)
Assigned to: Bogdan-Andrei Iancu (bogdan_iancu)
Summary: possible memory leak in serialize.c

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

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

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

Message:
Hi Richard,

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

Thanks and regards,
Bogdan

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

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

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

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

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


From bogdan at voice-system.ro  Thu Jan 21 18:39:34 2010
From: bogdan at voice-system.ro (Bogdan-Andrei Iancu)
Date: Thu, 21 Jan 2010 17:39:34 +0000
Subject: [OpenSIPS-Devel] SF.net SVN: opensips:[6516]
	branches/1.6/modules/load_balancer
Message-ID: <E1NY10I-0002u1-5n@3kljzd1.ch3.sourceforge.com>

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

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

Modified Paths:
--------------
    branches/1.6/modules/load_balancer/README
    branches/1.6/modules/load_balancer/doc/load_balancer_admin.xml


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


From bogdan at voice-system.ro  Thu Jan 21 18:39:42 2010
From: bogdan at voice-system.ro (Bogdan-Andrei Iancu)
Date: Thu, 21 Jan 2010 17:39:42 +0000
Subject: [OpenSIPS-Devel] SF.net SVN: opensips:[6517]
	branches/1.5/modules/load_balancer
Message-ID: <E1NY10Q-0002uc-Ec@3kljzd1.ch3.sourceforge.com>

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

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

Modified Paths:
--------------
    branches/1.5/modules/load_balancer/README
    branches/1.5/modules/load_balancer/doc/load_balancer_admin.xml


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


From bogdan at voice-system.ro  Thu Jan 21 18:40:05 2010
From: bogdan at voice-system.ro (Bogdan-Andrei Iancu)
Date: Thu, 21 Jan 2010 17:40:05 +0000
Subject: [OpenSIPS-Devel] SF.net SVN: opensips:[6518]
	trunk/modules/load_balancer
Message-ID: <E1NY10n-0002vP-DL@3kljzd1.ch3.sourceforge.com>

Revision: 6518
          http://opensips.svn.sourceforge.net/opensips/?rev=6518&view=rev
Author:   bogdan_iancu
Date:     2010-01-21 17:40:05 +0000 (Thu, 21 Jan 2010)

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

Modified Paths:
--------------
    trunk/modules/load_balancer/README
    trunk/modules/load_balancer/doc/load_balancer_admin.xml


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


From noreply at sourceforge.net  Thu Jan 21 18:40:27 2010
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 21 Jan 2010 17:40:27 +0000
Subject: [OpenSIPS-Devel] [ opensips-Bugs-2936420 ] typo in load balancer
	documentation
Message-ID: <E1NY119-0000UT-5K@d55xhf1.ch3.sourceforge.com>

Bugs item #2936420, was opened at 2010-01-21 17:56
Message generated for change (Settings changed) made by bogdan_iancu
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=2936420&group_id=232389

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: docs
Group: trunk
>Status: Closed
>Resolution: Fixed
Priority: 5
Private: No
Submitted By: Nobody/Anonymous (nobody)
>Assigned to: Bogdan-Andrei Iancu (bogdan_iancu)
Summary: typo in load balancer documentation

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

Example 1.7. set_dlg_profile usage

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

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

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

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

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

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

Regards,
Bogdan

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

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


From noreply at sourceforge.net  Thu Jan 21 18:51:12 2010
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 21 Jan 2010 17:51:12 +0000
Subject: [OpenSIPS-Devel] [ opensips-Bugs-2936343 ] 'opensipsctl fifo
	get_statistics all' crashes opensips
Message-ID: <E1NY1BY-0006x4-Qr@155xhf1.ch3.sourceforge.com>

Bugs item #2936343, was opened at 2010-01-21 15:51
Message generated for change (Comment added) made by bogdan_iancu
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=2936343&group_id=232389

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: modules
Group: 1.6.x
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Alex Massover (cupotka2008)
>Assigned to: Bogdan-Andrei Iancu (bogdan_iancu)
Summary: 'opensipsctl fifo get_statistics all' crashes opensips

Initial Comment:
Hi!

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

Here's a strace of parent process:

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


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

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

Message:
Hi Alex,

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

Regards,
Bogdan

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

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


From bogdan at voice-system.ro  Thu Jan 21 18:56:51 2010
From: bogdan at voice-system.ro (Bogdan-Andrei Iancu)
Date: Thu, 21 Jan 2010 19:56:51 +0200
Subject: [OpenSIPS-Devel] Possible bug in dbt_lib.c
	with	suggested	correction
In-Reply-To: <20100120150607.GB8374@debut.europalab.com>
References: <20100120101701.GA26836@debut.europalab.com>	<4B5716A2.3030209@voice-system.ro>
	<20100120150607.GB8374@debut.europalab.com>
Message-ID: <4B589563.6060108@voice-system.ro>

Hi Michael,

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

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

Regards,
Bogdan

Michael Schloh von Bennewitz wrote:
> Hello Bogdan,
>
> On Tues., Jan 20, 2010, Bogdan-Andrei Iancu wrote:
>   
>> Michael Schloh von Bennewitz wrote:
>>     
>>> Hello list,
>>>
>>> It would seem that Bogdan's recent correction relating to the BLOB
>>> datatype support was not complete.
>>>
>>> Index: modules/db_text/dbt_lib.c
>>> diff -Nau modules/db_text/dbt_lib.c.orig modules/db_text/dbt_lib.c
>>> --- modules/db_text/dbt_lib.c.orig	2010-01-20 11:10:07.967990871 +0100
>>> +++ modules/db_text/dbt_lib.c	2010-01-20 11:10:21.649138475 +0100
>>> @@ -440,7 +440,7 @@
>>>  		case DB_DOUBLE:
>>>  			break;
>>>  		case DB_STRING:
>>> -			if(_t0==DB_STR)
>>> +			if(_t0==DB_STR || _t0==DB_BLOB)
>>>  				return 0;
>>>  		case DB_STR:
>>>  			if(_t0==DB_STRING || _t0==DB_BLOB)
>>>
>>>
>>> The '-' and '+' indicate my suggested correction, keeping in line
>>> with Bogdan's recent change SVN revision 6382.
>>>
>>>       
>> Have this fix resulted from troubleshooting some error ? or it is a
>> logical fix ?
>>
>>     
> Your own comment for checkin 6382 is 'fixed incomatibility between
> BLOB data type and string format for columns' and your change is:
>
> --- trunk/modules/db_text/dbt_lib.c	2009/07/21 07:45:05	5901
> +++ trunk/modules/db_text/dbt_lib.c	2009/12/09 16:33:12	6382
> @@ -446,7 +446,7 @@
>  			if(_t0==DB_STRING || _t0==DB_BLOB)
>  				return 0;
>  		case DB_BLOB:
> -			if(_t0==DB_STR)
> +			if(_t0==DB_STR || _t0==DB_STRING)
>  				return 0;
>  		case DB_BITMAP:
>  			if (_t0==DB_INT)
>
> That fixed a nondocumented bug in which the sip_trace module could
> not write to its table when the database is dbtext.
>
> Then I looked at the code block and saw that DB_STR and DB_STRING
> are logically equal. See 'case DB_STRING: if(_t0==DB_STR) return 0;'
> above.
>
> ...so I assume that if comparing DB_STR and DB_BLOB should return
> 0, then comparing DB_STRING and DB_BLOB should return 0 as well.
> It's a long winded way of saying 'my suggestion is a logical fix.'
> I've found no runtime failure to motivate this correction, although
> there could be one hiding.
>
>   
>> Because the STRING and BLOB times are not really compatible. STRING
>> is zero terminated data while BLOB contains data (including 0), if
>> you get my point.
>>
>>     
> Just how different are DB_STRING and DB_STR? Is one zero terminated
> and the other not? If that's right, then maybe the best thing is to
> return 0 when comparing DB_BLOB with whichever [DB_STR|DB_STRING] is
> most similar (in which zero termination plays a role in deciding.)
>
> ...and if that's how the code was in the first place, then just
> disregard my patch suggestion.
>
> Regards,
> Michael
>
>   


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



From bogdan at voice-system.ro  Thu Jan 21 19:00:01 2010
From: bogdan at voice-system.ro (Bogdan-Andrei Iancu)
Date: Thu, 21 Jan 2010 20:00:01 +0200
Subject: [OpenSIPS-Devel] New contribution, ISN lookup in ENUM module
In-Reply-To: <20100119152839.GA18762@debut.europalab.com>
References: <20100119152839.GA18762@debut.europalab.com>
Message-ID: <4B589621.6070003@voice-system.ro>

Hello Michael,

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

Thanks and regards,
Bogdan

Michael Schloh von Bennewitz wrote:
> Hello list,
>
> I see from http://www.opensips.org/Development/Development that the
> ENUM module is 'commonly maintained.' Whoever has commit authority
> might like to take a look at the new ISN lookup integration that
> we are using with freenum.org and DNS delegation of our ITAD:
>
>   http://scm.europalab.com/contrib/file/tip/opensips/
>   http://scm.europalab.com/contrib/file/tip/opensips/enum-isn.txt
>   http://scm.europalab.com/contrib/file/tip/opensips/enum-isn.diff
>
> References:
>
>   http://www.freenum.org/
>   ftp://ftp.ietf.org/rfc/rfc3872.txt
>   ftp://ftp.ietf.org/rfc/rfc2871.txt
>   http://www.iana.org/assignments/trip-parameters/
>
> Basically, files (both code and documentation) in modules/enum of
> SVN trunk revision 6511 were modified to allow ISN formatting and
> lookup to succeed. This was broken in all distributions, because
> ISN and ENUM URLs must be formatted differently when looking up
> their NAPTR entries.
>
> A new function is exported by the ENUM module called 'isn_query()'
> as well as the supporting variable isn_suffix. I didn't provide
> code to handle the idea of draft-haberler-carrier-enum-01.txt or
> a function 'is_from_user_isn()' but that can come later if it's
> necessary.
>
> I recommend that this or similar logic be integrated into the
> next OpenSIPS distribution, partly because the distributed and
> online documentation already implies that ISN lookups succeed
> Search with grep(1) for 'freenum.org' in the ENUM module docs.
>
> Cheers,
> Michael
>
>   


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



From noreply at sourceforge.net  Thu Jan 21 19:01:17 2010
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 21 Jan 2010 18:01:17 +0000
Subject: [OpenSIPS-Devel] [ opensips-Patches-2935297 ] drouting wildcard '%'
	dr_groups username support
Message-ID: <E1NY1LJ-0007A4-G5@155xhf1.ch3.sourceforge.com>

Patches item #2935297, was opened at 2010-01-20 01:04
Message generated for change (Settings changed) made by bogdan_iancu
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086412&aid=2935297&group_id=232389

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: modules
Group: 1.6.x
Status: Open
Resolution: None
>Priority: 7
Private: No
Submitted By: Jarrod Baumann (jarrodpy)
>Assigned to: Bogdan-Andrei Iancu (bogdan_iancu)
Summary: drouting wildcard '%' dr_groups username support

Initial Comment:
When routing traffic for numerous gateways, the username field may sometimes be various values or omitted altogether.  Also, without domain support, a wildcard/catchall username may be used for a "default" route.  This *ugly* patch makes this possible by using '%' for the username in dr_groups.

The patch moves the matching pattern off of sql and into drouting.c which should not impact the speed.

# patch -p1 opensips-1.6.1-tls/modules/drouting/drouting.c < drouting.patch

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

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


From rrevels at bandwidth.com  Thu Jan 21 19:16:48 2010
From: rrevels at bandwidth.com (Richard Revels)
Date: Thu, 21 Jan 2010 13:16:48 -0500
Subject: [OpenSIPS-Devel] [ opensips-Bugs-2936343 ] 'opensipsctl fifo
	get_statistics all' crashes opensips
In-Reply-To: <E1NY1BY-0006x4-Qr@155xhf1.ch3.sourceforge.com>
References: <E1NY1BY-0006x4-Qr@155xhf1.ch3.sourceforge.com>
Message-ID: <5A45449D-F31B-4E51-94A1-FFD78EA61EE2@bandwidth.com>

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

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

Richard Revels


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

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



From noreply at sourceforge.net  Thu Jan 21 19:38:17 2010
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 21 Jan 2010 18:38:17 +0000
Subject: [OpenSIPS-Devel] [ opensips-Bugs-2936343 ] 'opensipsctl fifo
	get_statistics all' crashes opensips
Message-ID: <E1NY1v7-0003pV-WE@3bkjzd1.ch3.sourceforge.com>

Bugs item #2936343, was opened at 2010-01-21 15:51
Message generated for change (Comment added) made by cupotka2008
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=2936343&group_id=232389

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: modules
Group: 1.6.x
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Alex Massover (cupotka2008)
Assigned to: Bogdan-Andrei Iancu (bogdan_iancu)
Summary: 'opensipsctl fifo get_statistics all' crashes opensips

Initial Comment:
Hi!

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

Here's a strace of parent process:

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


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

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

Message:
Hi!

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

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

BR,
Alex.

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

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

Message:
Hi Alex,

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

Regards,
Bogdan

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

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


From develop2009 at schloh.com  Thu Jan 21 20:33:12 2010
From: develop2009 at schloh.com (Michael Schloh von Bennewitz)
Date: Thu, 21 Jan 2010 20:33:12 +0100
Subject: [OpenSIPS-Devel] New contribution, ISN lookup in ENUM module
In-Reply-To: <4B589621.6070003@voice-system.ro>
References: <20100119152839.GA18762@debut.europalab.com>
	<4B589621.6070003@voice-system.ro>
Message-ID: <20100121193312.GA29419@debut.europalab.com>


Hello Bogdan,

An jeu., janv 21, 2010, Bogdan-Andrei Iancu schrieb:
>Michael Schloh von Bennewitz wrote:
>> I see from http://www.opensips.org/Development/Development that the
>> ENUM module is 'commonly maintained.' Whoever has commit authority
>> might like to take a look at the new ISN lookup integration that
>> we are using with freenum.org and DNS delegation of our ITAD:
>>
>Thanks for your contribution - I will take a quick look over the
>patch to see if everything is ok and I will upload it on SVN. BTW,
>are you interested in activly maintaining that code? I can grant
>you SVN access for the enum part.
>
That's good, I'm glad if the ISN code gets in. I'll maintain the
ENUM module. If your SVN repository authenticates over SSH, then
here's my key:

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

Regards,
Michael

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


From noreply at sourceforge.net  Fri Jan 22 04:22:34 2010
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 22 Jan 2010 03:22:34 +0000
Subject: [OpenSIPS-Devel] [ opensips-Bugs-2936843 ] db_check_from fails if
	From header contains double quotes.
Message-ID: <E1NYA6U-0007Wl-6S@665xhf1.ch3.sourceforge.com>

Bugs item #2936843, was opened at 2010-01-21 22:22
Message generated for change (Tracker Item Submitted) made by seadweller
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=2936843&group_id=232389

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: modules
Group: 1.6.x
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: seadweller (seadweller)
Assigned to: Nobody/Anonymous (nobody)
Summary: db_check_from fails if From header contains double quotes.

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

From: ""Test User"" <sip:testuser at 10.1.1.1>;tag=as4b4ca259 

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

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

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


From noreply at sourceforge.net  Fri Jan 22 10:11:54 2010
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 22 Jan 2010 09:11:54 +0000
Subject: [OpenSIPS-Devel] [ opensips-Bugs-2936843 ] db_check_from fails if
	From header contains double quotes.
Message-ID: <E1NYFYY-0002Yu-Uv@d45xhf1.ch3.sourceforge.com>

Bugs item #2936843, was opened at 2010-01-22 04:22
Message generated for change (Comment added) made by ibc_sf
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=2936843&group_id=232389

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: modules
Group: 1.6.x
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: seadweller (seadweller)
Assigned to: Nobody/Anonymous (nobody)
Summary: db_check_from fails if From header contains double quotes.

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

From: ""Test User"" <sip:testuser at 10.1.1.1>;tag=as4b4ca259 

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

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

Comment By: I?aki Baz Castillo (ibc_sf)
Date: 2010-01-22 10:11

Message:
This bug report is invalid as RFC 3261 BNF grammar doesn't a llow a
display-name with double quotes inside. I've tested it.

This is, the display-name in a From/To/Contact URI can be enclosed between
double quotes, but it cannot contain double quotes inside.

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

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


From adragus at opensips.org  Fri Jan 22 11:27:22 2010
From: adragus at opensips.org (Andrei Dragus)
Date: Fri, 22 Jan 2010 10:27:22 +0000
Subject: [OpenSIPS-Devel] SF.net SVN: opensips:[6519] trunk/mem
Message-ID: <E1NYGja-0003lB-VJ@dn4whf1.ch3.sourceforge.com>

Revision: 6519
          http://opensips.svn.sourceforge.net/opensips/?rev=6519&view=rev
Author:   andreidragus
Date:     2010-01-22 10:27:22 +0000 (Fri, 22 Jan 2010)

Log Message:
-----------
Added warning before defrag starts

Modified Paths:
--------------
    trunk/mem/f_malloc.c
    trunk/mem/mem.h


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


From adragus at opensips.org  Fri Jan 22 11:34:54 2010
From: adragus at opensips.org (Andrei Dragus)
Date: Fri, 22 Jan 2010 10:34:54 +0000
Subject: [OpenSIPS-Devel] SF.net SVN: opensips:[6520] branches/1.6/mem
Message-ID: <E1NYGqs-0003yU-H8@dn4whf1.ch3.sourceforge.com>

Revision: 6520
          http://opensips.svn.sourceforge.net/opensips/?rev=6520&view=rev
Author:   andreidragus
Date:     2010-01-22 10:34:54 +0000 (Fri, 22 Jan 2010)

Log Message:
-----------
Backported warning to f_malloc

Modified Paths:
--------------
    branches/1.6/mem/f_malloc.c
    branches/1.6/mem/mem.h


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


From adragus at opensips.org  Fri Jan 22 11:41:55 2010
From: adragus at opensips.org (Andrei Dragus)
Date: Fri, 22 Jan 2010 10:41:55 +0000
Subject: [OpenSIPS-Devel] SF.net SVN: opensips:[6521] trunk/mem/f_malloc.c
Message-ID: <E1NYGxf-0004Au-ED@dn4whf1.ch3.sourceforge.com>

Revision: 6521
          http://opensips.svn.sourceforge.net/opensips/?rev=6521&view=rev
Author:   andreidragus
Date:     2010-01-22 10:41:55 +0000 (Fri, 22 Jan 2010)

Log Message:
-----------
Fixed potential overflow

Modified Paths:
--------------
    trunk/mem/f_malloc.c


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


From adragus at opensips.org  Fri Jan 22 11:46:09 2010
From: adragus at opensips.org (Andrei Dragus)
Date: Fri, 22 Jan 2010 10:46:09 +0000
Subject: [OpenSIPS-Devel] SF.net SVN: opensips:[6522]
	branches/1.6/mem/f_malloc.c
Message-ID: <E1NYH1l-0004JI-5t@dn4whf1.ch3.sourceforge.com>

Revision: 6522
          http://opensips.svn.sourceforge.net/opensips/?rev=6522&view=rev
Author:   andreidragus
Date:     2010-01-22 10:46:08 +0000 (Fri, 22 Jan 2010)

Log Message:
-----------
 backport from trunk

Modified Paths:
--------------
    branches/1.6/mem/f_malloc.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 Jan 22 13:42:58 2010
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 22 Jan 2010 12:42:58 +0000
Subject: [OpenSIPS-Devel] [ opensips-Bugs-2936843 ] db_check_from fails if
	From header contains double quotes.
Message-ID: <E1NYIqo-0003Xx-KL@h45xhf1.ch3.sourceforge.com>

Bugs item #2936843, was opened at 2010-01-22 05:22
Message generated for change (Comment added) made by bogdan_iancu
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=2936843&group_id=232389

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: modules
Group: 1.6.x
>Status: Closed
>Resolution: Invalid
Priority: 5
Private: No
Submitted By: seadweller (seadweller)
Assigned to: Nobody/Anonymous (nobody)
Summary: db_check_from fails if From header contains double quotes.

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

From: ""Test User"" <sip:testuser at 10.1.1.1>;tag=as4b4ca259 

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

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

>Comment By: Bogdan-Andrei Iancu (bogdan_iancu)
Date: 2010-01-22 14:42

Message:
I agree with Inaki: display ""Test User"" is invalid from SIP grammar point
of view . The correct format should be "\"Test User\"'

Regards,
Bogdan

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

Comment By: I?aki Baz Castillo (ibc_sf)
Date: 2010-01-22 11:11

Message:
This bug report is invalid as RFC 3261 BNF grammar doesn't a llow a
display-name with double quotes inside. I've tested it.

This is, the display-name in a From/To/Contact URI can be enclosed between
double quotes, but it cannot contain double quotes inside.

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

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


From chino540off+kamailio at gmail.com  Fri Jan 22 14:55:37 2010
From: chino540off+kamailio at gmail.com (=?ISO-8859-1?Q?Olivier_D=E9tour?=)
Date: Fri, 22 Jan 2010 14:55:37 +0100
Subject: [OpenSIPS-Devel] [B2B_ENTITIES] ACK Strategy
In-Reply-To: <99667a341001210853l2ee98f1arff8d277aa77488d8@mail.gmail.com>
References: <99667a341001210853l2ee98f1arff8d277aa77488d8@mail.gmail.com>
Message-ID: <99667a341001220555n5bde9b56he32b48b7ddb912d9@mail.gmail.com>

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

Sorry about that, configuration problems,
thanks,

-- 
Olivier D?tour


From bogdan at voice-system.ro  Fri Jan 22 15:24:50 2010
From: bogdan at voice-system.ro (Bogdan-Andrei Iancu)
Date: Fri, 22 Jan 2010 16:24:50 +0200
Subject: [OpenSIPS-Devel] "SIP introduction" is the next webinar
Message-ID: <4B59B532.5000405@voice-system.ro>


Next webinar is scheduled for 28th of January 2010.

The topic is "SIP Introduction" - detailed explanation and examples of 
SIP fundamentals: Requests and Replies, Initial and sequential requests, 
SIP transactions, SIP dialogs, SIP and RTP; A good understanding of SIP 
protocol is essential for working with OpenSIPS.

Free registration - http://www.opensips.org/Training/Webinars#toc5


The list with all the next scheduled webinars is available under 
http://www.opensips.org/Training/Webinars#toc4


Best regards,
Bogdan

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



From noreply at sourceforge.net  Fri Jan 22 15:51:35 2010
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 22 Jan 2010 14:51:35 +0000
Subject: [OpenSIPS-Devel] [ opensips-Bugs-2936343 ] 'opensipsctl fifo
	get_statistics all' crashes opensips
Message-ID: <E1NYKrH-0006jX-Ha@1bkjzd1.ch3.sourceforge.com>

Bugs item #2936343, was opened at 2010-01-21 15:51
Message generated for change (Comment added) made by cupotka2008
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=2936343&group_id=232389

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: modules
Group: 1.6.x
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Alex Massover (cupotka2008)
Assigned to: Bogdan-Andrei Iancu (bogdan_iancu)
Summary: 'opensipsctl fifo get_statistics all' crashes opensips

Initial Comment:
Hi!

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

Here's a strace of parent process:

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


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

>Comment By: Alex Massover (cupotka2008)
Date: 2010-01-22 16:51

Message:
I just discovered 'fifo ps' command :)

read(7, ":get_statistics:opensips_receiver"..., 4096) = 45
open("/tmp/opensips_receiver_18361", O_WRONLY|O_NONBLOCK) = 10
fstat64(10, {st_mode=S_IFIFO|0666, st_size=0, ...}) = 0
lstat64("/tmp/opensips_receiver_18361", {st_mode=S_IFIFO|0666, st_size=0,
...}) = 0
fcntl64(10, F_GETFL)                    = 0x801 (flags
O_WRONLY|O_NONBLOCK)
fcntl64(10, F_SETFL, O_WRONLY)          = 0
fcntl64(10, F_GETFL)                    = 0x1 (flags O_WRONLY)
fstat64(10, {st_mode=S_IFIFO|0666, st_size=0, ...}) = 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0)
= 0xb7252000
_llseek(10, 0, 0xbfd1c5d8, SEEK_CUR)    = -1 ESPIPE (Illegal seek)
open("/proc/net/udp", O_RDONLY)         = 11
fstat64(11, {st_mode=S_IFREG|0444, st_size=0, ...}) = 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0)
= 0xb7251000
read(11, "  sl  local_address rem_address  "..., 1024) = 1024
read(11, "  67: 0100007F:0035 00000000:0000"..., 1024) = 640
read(11, ""..., 1024)                   = 0
close(11)                               = 0
munmap(0xb7251000, 4096)                = 0
time(NULL)                              = 1264171687
kill(17997, SIGUSR2)                    = 0
nanosleep({0, 20000}, NULL)             = 0
time(NULL)                              = 1264171687
time(NULL)                              = 1264171687
time(NULL)                              = 1264171687
time(NULL)                              = 1264171687
time(NULL)                              = 1264171687
time(NULL)                              = 1264171687
kill(17998, SIGUSR2)                    = 0
nanosleep({0, 20000}, NULL)             = 0
time(NULL)                              = 1264171687
time(NULL)                              = 1264171687
time(NULL)                              = 1264171687
time(NULL)                              = 1264171687
time(NULL)                              = 1264171687
time(NULL)                              = 1264171687
kill(17999, SIGUSR2)                    = 0
nanosleep({0, 20000}, NULL)             = 0
time(NULL)                              = 1264171687
time(NULL)                              = 1264171687
time(NULL)                              = 1264171687
time(NULL)                              = 1264171687
time(NULL)                              = 1264171687
time(NULL)                              = 1264171687
kill(18000, SIGUSR2)                    = 0
nanosleep({0, 20000}, NULL)             = 0
time(NULL)                              = 1264171687
time(NULL)                              = 1264171687
time(NULL)                              = 1264171687
time(NULL)                              = 1264171687
time(NULL)                              = 1264171687
time(NULL)                              = 1264171687
kill(18001, SIGUSR2)                    = 0
nanosleep({0, 20000}, NULL)             = 0
time(NULL)                              = 1264171687
time(NULL)                              = 1264171687
time(NULL)                              = 1264171687
time(NULL)                              = 1264171687
time(NULL)                              = 1264171687
time(NULL)                              = 1264171687
kill(18002, SIGUSR2)                    = 0
nanosleep({0, 20000}, NULL)             = 0
time(NULL)                              = 1264171687
time(NULL)                              = 1264171687
time(NULL)                              = 1264171687
time(NULL)                              = 1264171687
time(NULL)                              = 1264171687
time(NULL)                              = 1264171687
kill(18003, SIGUSR2)                    = 0
nanosleep({0, 20000}, NULL)             = 0
time(NULL)                              = 1264171687
time(NULL)                              = 1264171687
time(NULL)                              = 1264171687
time(NULL)                              = 1264171687
time(NULL)                              = 1264171687
time(NULL)                              = 1264171687
kill(18004, SIGUSR2)                    = 0
nanosleep({0, 20000}, NULL)             = 0
--- SIGTERM (Terminated) @ 0 (0) ---
exit_group(0)                           = ?
Process 18009 detached


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

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

Message:
Hi!

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

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

BR,
Alex.

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

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

Message:
Hi Alex,

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

Regards,
Bogdan

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

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


From noreply at sourceforge.net  Fri Jan 22 16:35:23 2010
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 22 Jan 2010 15:35:23 +0000
Subject: [OpenSIPS-Devel] [ opensips-Bugs-2936343 ] 'opensipsctl fifo
	get_statistics all' crashes opensips
Message-ID: <E1NYLXf-0002H3-KT@565xhf1.ch3.sourceforge.com>

Bugs item #2936343, was opened at 2010-01-21 15:51
Message generated for change (Comment added) made by bogdan_iancu
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=2936343&group_id=232389

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: modules
Group: 1.6.x
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Alex Massover (cupotka2008)
Assigned to: Bogdan-Andrei Iancu (bogdan_iancu)
Summary: 'opensipsctl fifo get_statistics all' crashes opensips

Initial Comment:
Hi!

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

Here's a strace of parent process:

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


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

>Comment By: Bogdan-Andrei Iancu (bogdan_iancu)
Date: 2010-01-22 17:35

Message:
Alex, I'm investigating some possibilities....Could you apply the patch I
just uploaded here? Just to see if my suspicion is right. BTW, what modules
are you loading ?

Thanks and regards,
Bogdan

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

Comment By: Alex Massover (cupotka2008)
Date: 2010-01-22 16:51

Message:
I just discovered 'fifo ps' command :)

read(7, ":get_statistics:opensips_receiver"..., 4096) = 45
open("/tmp/opensips_receiver_18361", O_WRONLY|O_NONBLOCK) = 10
fstat64(10, {st_mode=S_IFIFO|0666, st_size=0, ...}) = 0
lstat64("/tmp/opensips_receiver_18361", {st_mode=S_IFIFO|0666, st_size=0,
...}) = 0
fcntl64(10, F_GETFL)                    = 0x801 (flags
O_WRONLY|O_NONBLOCK)
fcntl64(10, F_SETFL, O_WRONLY)          = 0
fcntl64(10, F_GETFL)                    = 0x1 (flags O_WRONLY)
fstat64(10, {st_mode=S_IFIFO|0666, st_size=0, ...}) = 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0)
= 0xb7252000
_llseek(10, 0, 0xbfd1c5d8, SEEK_CUR)    = -1 ESPIPE (Illegal seek)
open("/proc/net/udp", O_RDONLY)         = 11
fstat64(11, {st_mode=S_IFREG|0444, st_size=0, ...}) = 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0)
= 0xb7251000
read(11, "  sl  local_address rem_address  "..., 1024) = 1024
read(11, "  67: 0100007F:0035 00000000:0000"..., 1024) = 640
read(11, ""..., 1024)                   = 0
close(11)                               = 0
munmap(0xb7251000, 4096)                = 0
time(NULL)                              = 1264171687
kill(17997, SIGUSR2)                    = 0
nanosleep({0, 20000}, NULL)             = 0
time(NULL)                              = 1264171687
time(NULL)                              = 1264171687
time(NULL)                              = 1264171687
time(NULL)                              = 1264171687
time(NULL)                              = 1264171687
time(NULL)                              = 1264171687
kill(17998, SIGUSR2)                    = 0
nanosleep({0, 20000}, NULL)             = 0
time(NULL)                              = 1264171687
time(NULL)                              = 1264171687
time(NULL)                              = 1264171687
time(NULL)                              = 1264171687
time(NULL)                              = 1264171687
time(NULL)                              = 1264171687
kill(17999, SIGUSR2)                    = 0
nanosleep({0, 20000}, NULL)             = 0
time(NULL)                              = 1264171687
time(NULL)                              = 1264171687
time(NULL)                              = 1264171687
time(NULL)                              = 1264171687
time(NULL)                              = 1264171687
time(NULL)                              = 1264171687
kill(18000, SIGUSR2)                    = 0
nanosleep({0, 20000}, NULL)             = 0
time(NULL)                              = 1264171687
time(NULL)                              = 1264171687
time(NULL)                              = 1264171687
time(NULL)                              = 1264171687
time(NULL)                              = 1264171687
time(NULL)                              = 1264171687
kill(18001, SIGUSR2)                    = 0
nanosleep({0, 20000}, NULL)             = 0
time(NULL)                              = 1264171687
time(NULL)                              = 1264171687
time(NULL)                              = 1264171687
time(NULL)                              = 1264171687
time(NULL)                              = 1264171687
time(NULL)                              = 1264171687
kill(18002, SIGUSR2)                    = 0
nanosleep({0, 20000}, NULL)             = 0
time(NULL)                              = 1264171687
time(NULL)                              = 1264171687
time(NULL)                              = 1264171687
time(NULL)                              = 1264171687
time(NULL)                              = 1264171687
time(NULL)                              = 1264171687
kill(18003, SIGUSR2)                    = 0
nanosleep({0, 20000}, NULL)             = 0
time(NULL)                              = 1264171687
time(NULL)                              = 1264171687
time(NULL)                              = 1264171687
time(NULL)                              = 1264171687
time(NULL)                              = 1264171687
time(NULL)                              = 1264171687
kill(18004, SIGUSR2)                    = 0
nanosleep({0, 20000}, NULL)             = 0
--- SIGTERM (Terminated) @ 0 (0) ---
exit_group(0)                           = ?
Process 18009 detached


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

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

Message:
Hi!

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

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

BR,
Alex.

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

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

Message:
Hi Alex,

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

Regards,
Bogdan

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

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


From rrevels at bandwidth.com  Fri Jan 22 16:36:09 2010
From: rrevels at bandwidth.com (Richard Revels)
Date: Fri, 22 Jan 2010 10:36:09 -0500
Subject: [OpenSIPS-Devel] [ opensips-Bugs-2936343 ] 'opensipsctl fifo
	get_statistics all' crashes opensips
In-Reply-To: <E1NYKrH-0006jX-Ha@1bkjzd1.ch3.sourceforge.com>
References: <E1NYKrH-0006jX-Ha@1bkjzd1.ch3.sourceforge.com>
Message-ID: <0791E53E-BD51-4B56-A41F-7528926B68F5@bandwidth.com>

I have found that taking the snmp module out of the config allows the command to complete without crashing opensips.  This hasn't always been the case but I don't know what revision the problem started with.

I also don't have the opensips snmp config completely set up on this server.  Everything is in place except the agentXSocket listen parameter being set for the snmpstats module.  I'll try to test this again with that in place before the end of the day.

Richard


On Jan 22, 2010, at 9:51 AM, SourceForge.net wrote:

> Bugs item #2936343, was opened at 2010-01-21 15:51
> Message generated for change (Comment added) made by cupotka2008
> You can respond by visiting: 
> https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=2936343&group_id=232389
> 
> Please note that this message will contain a full copy of the comment thread,
> including the initial issue submission, for this request,
> not just the latest update.
> Category: modules
> Group: 1.6.x
> Status: Open
> Resolution: None
> Priority: 5
> Private: No
> Submitted By: Alex Massover (cupotka2008)
> Assigned to: Bogdan-Andrei Iancu (bogdan_iancu)
> Summary: 'opensipsctl fifo get_statistics all' crashes opensips
> 
> Initial Comment:
> Hi!
> 
> 'opensipsctl fifo get_statistics all' always crashes opensips. Core is somehow not produced.
> Always reproducible for me on 1.6.1.
> 
> Here's a strace of parent process:
> 
> Process 9509 attached - interrupt to quit
> pause()                                 = ? ERESTARTNOHAND (To be restarted)
> --- SIGUSR2 (User defined signal 2) @ 0 (0) ---
> sigreturn()                             = ? (mask now [])
> pause()                                 = ? ERESTARTNOHAND (To be restarted)
> --- SIGCHLD (Child exited) @ 0 (0) ---
> sigreturn()                             = ? (mask now [])
> waitpid(-1, [{WIFSIGNALED(s) && WTERMSIG(s) == SIGUSR2}], WNOHANG) = 9520
> waitpid(-1, 0xbf84b4c8, WNOHANG)        = 0
> kill(0, SIGTERM)                        = 0
> --- SIGTERM (Terminated) @ 0 (0) ---
> --- SIGCHLD (Child exited) @ 0 (0) ---
> sigreturn()                             = ? (mask now [TERM])
> sigreturn()                             = ? (mask now [])
> rt_sigaction(SIGALRM, {0x8065920, [ALRM], SA_RESTART}, {SIG_DFL}, 8) = 0
> alarm(60)                               = 0
> wait4(-1, NULL, 0, NULL)                = 9514
> wait4(-1, NULL, 0, NULL)                = 9519
> wait4(-1, NULL, 0, NULL)                = 9521
> wait4(-1, NULL, 0, NULL)                = 9522
> wait4(-1, NULL, 0, NULL)                = 9512
> --- SIGCHLD (Child exited) @ 0 (0) ---
> sigreturn()                             = ? (mask now [])
> --- SIGCHLD (Child exited) @ 0 (0) ---
> sigreturn()                             = ? (mask now [])
> wait4(-1, NULL, 0, NULL)                = 9510
> wait4(-1, NULL, 0, NULL)                = 9516
> --- SIGCHLD (Child exited) @ 0 (0) ---
> sigreturn()                             = ? (mask now [])
> --- SIGCHLD (Child exited) @ 0 (0) ---
> sigreturn()                             = ? (mask now [])
> wait4(-1, NULL, 0, NULL)                = 9515
> wait4(-1, NULL, 0, NULL)                = 9517
> wait4(-1, NULL, 0, NULL)                = 9524
> wait4(-1, NULL, 0, NULL)                = 9525
> --- SIGCHLD (Child exited) @ 0 (0) ---
> sigreturn()                             = ? (mask now [])
> --- SIGCHLD (Child exited) @ 0 (0) ---
> sigreturn()                             = ? (mask now [])
> --- SIGCHLD (Child exited) @ 0 (0) ---
> sigreturn()                             = ? (mask now [])
> --- SIGCHLD (Child exited) @ 0 (0) ---
> sigreturn()                             = ? (mask now [])
> wait4(-1, NULL, 0, NULL)                = 9511
> wait4(-1, NULL, 0, NULL)                = 9513
> wait4(-1, NULL, 0, NULL)                = 9518
> wait4(-1, NULL, 0, NULL)                = 9523
> wait4(-1, NULL, 0, NULL)                = -1 ECHILD (No child processes)
> rt_sigaction(SIGALRM, {0x8066080, [ALRM], SA_RESTART}, {0x8065920, [ALRM], SA_RESTART}, 8) = 0 stat64("/tmp/opensips_fifo", {st_mode=S_IFIFO|0660, st_size=0, ...}) = 0
> unlink("/tmp/opensips_fifo")            = 0
> munmap(0xaed25000, 134217728)           = 0
> unlink("/var/run/opensips/opensips.pid") = 0
> alarm(0)                                = 60
> rt_sigaction(SIGALRM, {SIG_IGN}, {0x8066080, [ALRM], SA_RESTART}, 8) = 0
> exit_group(0)                           = ?
> Process 9509 detached
> 
> 
> ----------------------------------------------------------------------
> 
>> Comment By: Alex Massover (cupotka2008)
> Date: 2010-01-22 16:51
> 
> Message:
> I just discovered 'fifo ps' command :)
> 
> read(7, ":get_statistics:opensips_receiver"..., 4096) = 45
> open("/tmp/opensips_receiver_18361", O_WRONLY|O_NONBLOCK) = 10
> fstat64(10, {st_mode=S_IFIFO|0666, st_size=0, ...}) = 0
> lstat64("/tmp/opensips_receiver_18361", {st_mode=S_IFIFO|0666, st_size=0,
> ...}) = 0
> fcntl64(10, F_GETFL)                    = 0x801 (flags
> O_WRONLY|O_NONBLOCK)
> fcntl64(10, F_SETFL, O_WRONLY)          = 0
> fcntl64(10, F_GETFL)                    = 0x1 (flags O_WRONLY)
> fstat64(10, {st_mode=S_IFIFO|0666, st_size=0, ...}) = 0
> mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0)
> = 0xb7252000
> _llseek(10, 0, 0xbfd1c5d8, SEEK_CUR)    = -1 ESPIPE (Illegal seek)
> open("/proc/net/udp", O_RDONLY)         = 11
> fstat64(11, {st_mode=S_IFREG|0444, st_size=0, ...}) = 0
> mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0)
> = 0xb7251000
> read(11, "  sl  local_address rem_address  "..., 1024) = 1024
> read(11, "  67: 0100007F:0035 00000000:0000"..., 1024) = 640
> read(11, ""..., 1024)                   = 0
> close(11)                               = 0
> munmap(0xb7251000, 4096)                = 0
> time(NULL)                              = 1264171687
> kill(17997, SIGUSR2)                    = 0
> nanosleep({0, 20000}, NULL)             = 0
> time(NULL)                              = 1264171687
> time(NULL)                              = 1264171687
> time(NULL)                              = 1264171687
> time(NULL)                              = 1264171687
> time(NULL)                              = 1264171687
> time(NULL)                              = 1264171687
> kill(17998, SIGUSR2)                    = 0
> nanosleep({0, 20000}, NULL)             = 0
> time(NULL)                              = 1264171687
> time(NULL)                              = 1264171687
> time(NULL)                              = 1264171687
> time(NULL)                              = 1264171687
> time(NULL)                              = 1264171687
> time(NULL)                              = 1264171687
> kill(17999, SIGUSR2)                    = 0
> nanosleep({0, 20000}, NULL)             = 0
> time(NULL)                              = 1264171687
> time(NULL)                              = 1264171687
> time(NULL)                              = 1264171687
> time(NULL)                              = 1264171687
> time(NULL)                              = 1264171687
> time(NULL)                              = 1264171687
> kill(18000, SIGUSR2)                    = 0
> nanosleep({0, 20000}, NULL)             = 0
> time(NULL)                              = 1264171687
> time(NULL)                              = 1264171687
> time(NULL)                              = 1264171687
> time(NULL)                              = 1264171687
> time(NULL)                              = 1264171687
> time(NULL)                              = 1264171687
> kill(18001, SIGUSR2)                    = 0
> nanosleep({0, 20000}, NULL)             = 0
> time(NULL)                              = 1264171687
> time(NULL)                              = 1264171687
> time(NULL)                              = 1264171687
> time(NULL)                              = 1264171687
> time(NULL)                              = 1264171687
> time(NULL)                              = 1264171687
> kill(18002, SIGUSR2)                    = 0
> nanosleep({0, 20000}, NULL)             = 0
> time(NULL)                              = 1264171687
> time(NULL)                              = 1264171687
> time(NULL)                              = 1264171687
> time(NULL)                              = 1264171687
> time(NULL)                              = 1264171687
> time(NULL)                              = 1264171687
> kill(18003, SIGUSR2)                    = 0
> nanosleep({0, 20000}, NULL)             = 0
> time(NULL)                              = 1264171687
> time(NULL)                              = 1264171687
> time(NULL)                              = 1264171687
> time(NULL)                              = 1264171687
> time(NULL)                              = 1264171687
> time(NULL)                              = 1264171687
> kill(18004, SIGUSR2)                    = 0
> nanosleep({0, 20000}, NULL)             = 0
> --- SIGTERM (Terminated) @ 0 (0) ---
> exit_group(0)                           = ?
> Process 18009 detached
> 
> 
> ----------------------------------------------------------------------
> 
> Comment By: Alex Massover (cupotka2008)
> Date: 2010-01-21 20:38
> 
> Message:
> Hi!
> 
> I use fifo.
> Is there any intelligent way to recognize which process do FIFO? Or only
> stracing all of them?
> 
> (On Sunday I back to work and will bring the strace.)
> 
> BR,
> Alex.
> 
> ----------------------------------------------------------------------
> 
> Comment By: Bogdan-Andrei Iancu (bogdan_iancu)
> Date: 2010-01-21 19:51
> 
> Message:
> Hi Alex,
> 
> The strace of the main proc is irrelevant here - what is important is the
> bt or strace of the FIFO/xmlrpc process. BTW, what MI backend do you use ?
> 
> Regards,
> Bogdan
> 
> ----------------------------------------------------------------------
> 
> You can respond by visiting: 
> https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=2936343&group_id=232389
> 
> _______________________________________________
> Devel mailing list
> Devel at lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/devel



From noreply at sourceforge.net  Fri Jan 22 17:11:09 2010
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 22 Jan 2010 16:11:09 +0000
Subject: [OpenSIPS-Devel] [ opensips-Bugs-2934618 ] possible memory leak in
	serialize.c
Message-ID: <E1NYM6H-00037I-8f@d55xhf1.ch3.sourceforge.com>

Bugs item #2934618, was opened at 2010-01-18 23:27
Message generated for change (Comment added) made by nobody
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=2934618&group_id=232389

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: core
Group: 1.6.x
Status: Open
Resolution: Fixed
Priority: 5
Private: No
Submitted By: Richard Revels (rrevels)
Assigned to: Bogdan-Andrei Iancu (bogdan_iancu)
Summary: possible memory leak in serialize.c

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

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

Comment By: Nobody/Anonymous (nobody)
Date: 2010-01-22 16:11

Message:
The patch has fixed the issue for us.  We are no longer able to detect any
memory leakage at all. 

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

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

Message:
Hi Richard,

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

Thanks and regards,
Bogdan

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

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

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

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

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


From bogdan at voice-system.ro  Fri Jan 22 17:33:56 2010
From: bogdan at voice-system.ro (Bogdan-Andrei Iancu)
Date: Fri, 22 Jan 2010 16:33:56 +0000
Subject: [OpenSIPS-Devel] SF.net SVN: opensips:[6523] trunk/serialize.c
Message-ID: <E1NYMSK-0005To-5s@3kljzd1.ch3.sourceforge.com>

Revision: 6523
          http://opensips.svn.sourceforge.net/opensips/?rev=6523&view=rev
Author:   bogdan_iancu
Date:     2010-01-22 16:33:55 +0000 (Fri, 22 Jan 2010)

Log Message:
-----------
- fixed memory leak in serialize function.
  Reported by Richard Revels
  Closes bug 2934618

Modified Paths:
--------------
    trunk/serialize.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 Jan 22 17:35:07 2010
From: bogdan at voice-system.ro (Bogdan-Andrei Iancu)
Date: Fri, 22 Jan 2010 16:35:07 +0000
Subject: [OpenSIPS-Devel] SF.net SVN: opensips:[6524]
	branches/1.6/serialize.c
Message-ID: <E1NYMTT-0005VK-9L@3kljzd1.ch3.sourceforge.com>

Revision: 6524
          http://opensips.svn.sourceforge.net/opensips/?rev=6524&view=rev
Author:   bogdan_iancu
Date:     2010-01-22 16:35:07 +0000 (Fri, 22 Jan 2010)

Log Message:
-----------
backport from trunk (rev 6523):
- fixed memory leak in serialize function.
  Reported by Richard Revels
  Closes bug 2934618

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

Modified Paths:
--------------
    branches/1.6/serialize.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 Jan 22 17:35:34 2010
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 22 Jan 2010 16:35:34 +0000
Subject: [OpenSIPS-Devel] [ opensips-Bugs-2934618 ] possible memory leak in
	serialize.c
Message-ID: <E1NYMTu-00013r-Nk@g45xhf1.ch3.sourceforge.com>

Bugs item #2934618, was opened at 2010-01-19 01:27
Message generated for change (Settings changed) made by bogdan_iancu
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=2934618&group_id=232389

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: core
Group: 1.6.x
>Status: Closed
Resolution: Fixed
Priority: 5
Private: No
Submitted By: Richard Revels (rrevels)
Assigned to: Bogdan-Andrei Iancu (bogdan_iancu)
Summary: possible memory leak in serialize.c

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

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

>Comment By: Bogdan-Andrei Iancu (bogdan_iancu)
Date: 2010-01-22 18:35

Message:
patch uploaded on SVN

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

Comment By: Nobody/Anonymous (nobody)
Date: 2010-01-22 18:11

Message:
The patch has fixed the issue for us.  We are no longer able to detect any
memory leakage at all. 

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

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

Message:
Hi Richard,

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

Thanks and regards,
Bogdan

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

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

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

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

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


From bogdan at voice-system.ro  Fri Jan 22 17:46:03 2010
From: bogdan at voice-system.ro (Bogdan-Andrei Iancu)
Date: Fri, 22 Jan 2010 16:46:03 +0000
Subject: [OpenSIPS-Devel] SF.net SVN: opensips:[6525]
	trunk/modules/snmpstats/sub_agent.c
Message-ID: <E1NYMe3-0005hk-FJ@3kljzd1.ch3.sourceforge.com>

Revision: 6525
          http://opensips.svn.sourceforge.net/opensips/?rev=6525&view=rev
Author:   bogdan_iancu
Date:     2010-01-22 16:46:03 +0000 (Fri, 22 Jan 2010)

Log Message:
-----------
- fixed bug in signal handler -> the extra proc must use the SIGUSR2 handler from the core, otherwise it will die when core will try to collect pkg mem stats (via SIGUSR2). NOTE the SIGUSR2 terminates the proc if not handled.
  Reported by Alex Massover.
  Thanks to Richard Revels for the hints
  Closes bug 2936343.

Modified Paths:
--------------
    trunk/modules/snmpstats/sub_agent.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 Jan 22 17:47:24 2010
From: bogdan at voice-system.ro (Bogdan-Andrei Iancu)
Date: Fri, 22 Jan 2010 16:47:24 +0000
Subject: [OpenSIPS-Devel] SF.net SVN: opensips:[6526]
	branches/1.6/modules/snmpstats/sub_agent.c
Message-ID: <E1NYMfM-0005jm-M7@3kljzd1.ch3.sourceforge.com>

Revision: 6526
          http://opensips.svn.sourceforge.net/opensips/?rev=6526&view=rev
Author:   bogdan_iancu
Date:     2010-01-22 16:47:24 +0000 (Fri, 22 Jan 2010)

Log Message:
-----------
backport from trunk (rev #6525):
- fixed bug in signal handler -> the extra proc must use the SIGUSR2 handler from the core, otherwise it will die when core will try to collect pkg mem stats (via SIGUSR2). NOTE the SIGUSR2 terminates the proc if not handled.
  Reported by Alex Massover.
  Thanks to Richard Revels for the hints
  Closes bug 2936343

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

Modified Paths:
--------------
    branches/1.6/modules/snmpstats/sub_agent.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 Jan 22 17:48:46 2010
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 22 Jan 2010 16:48:46 +0000
Subject: [OpenSIPS-Devel] [ opensips-Bugs-2936343 ] 'opensipsctl fifo
	get_statistics all' crashes opensips
Message-ID: <E1NYMgg-0000TY-Bc@1bkjzd1.ch3.sourceforge.com>

Bugs item #2936343, was opened at 2010-01-21 15:51
Message generated for change (Comment added) made by bogdan_iancu
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=2936343&group_id=232389

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: modules
Group: 1.6.x
>Status: Closed
>Resolution: Fixed
Priority: 5
Private: No
Submitted By: Alex Massover (cupotka2008)
Assigned to: Bogdan-Andrei Iancu (bogdan_iancu)
Summary: 'opensipsctl fifo get_statistics all' crashes opensips

Initial Comment:
Hi!

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

Here's a strace of parent process:

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


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

>Comment By: Bogdan-Andrei Iancu (bogdan_iancu)
Date: 2010-01-22 18:48

Message:
Thanks to Richard Revels about the hint on snmp module...Indeed, the bug
was in that module as it was overriding the SIGUSR2 handler which was
installed by core.

Fix is on SVN.

Thanks to all,
Bogdan

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

Comment By: Bogdan-Andrei Iancu (bogdan_iancu)
Date: 2010-01-22 17:35

Message:
Alex, I'm investigating some possibilities....Could you apply the patch I
just uploaded here? Just to see if my suspicion is right. BTW, what modules
are you loading ?

Thanks and regards,
Bogdan

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

Comment By: Alex Massover (cupotka2008)
Date: 2010-01-22 16:51

Message:
I just discovered 'fifo ps' command :)

read(7, ":get_statistics:opensips_receiver"..., 4096) = 45
open("/tmp/opensips_receiver_18361", O_WRONLY|O_NONBLOCK) = 10
fstat64(10, {st_mode=S_IFIFO|0666, st_size=0, ...}) = 0
lstat64("/tmp/opensips_receiver_18361", {st_mode=S_IFIFO|0666, st_size=0,
...}) = 0
fcntl64(10, F_GETFL)                    = 0x801 (flags
O_WRONLY|O_NONBLOCK)
fcntl64(10, F_SETFL, O_WRONLY)          = 0
fcntl64(10, F_GETFL)                    = 0x1 (flags O_WRONLY)
fstat64(10, {st_mode=S_IFIFO|0666, st_size=0, ...}) = 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0)
= 0xb7252000
_llseek(10, 0, 0xbfd1c5d8, SEEK_CUR)    = -1 ESPIPE (Illegal seek)
open("/proc/net/udp", O_RDONLY)         = 11
fstat64(11, {st_mode=S_IFREG|0444, st_size=0, ...}) = 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0)
= 0xb7251000
read(11, "  sl  local_address rem_address  "..., 1024) = 1024
read(11, "  67: 0100007F:0035 00000000:0000"..., 1024) = 640
read(11, ""..., 1024)                   = 0
close(11)                               = 0
munmap(0xb7251000, 4096)                = 0
time(NULL)                              = 1264171687
kill(17997, SIGUSR2)                    = 0
nanosleep({0, 20000}, NULL)             = 0
time(NULL)                              = 1264171687
time(NULL)                              = 1264171687
time(NULL)                              = 1264171687
time(NULL)                              = 1264171687
time(NULL)                              = 1264171687
time(NULL)                              = 1264171687
kill(17998, SIGUSR2)                    = 0
nanosleep({0, 20000}, NULL)             = 0
time(NULL)                              = 1264171687
time(NULL)                              = 1264171687
time(NULL)                              = 1264171687
time(NULL)                              = 1264171687
time(NULL)                              = 1264171687
time(NULL)                              = 1264171687
kill(17999, SIGUSR2)                    = 0
nanosleep({0, 20000}, NULL)             = 0
time(NULL)                              = 1264171687
time(NULL)                              = 1264171687
time(NULL)                              = 1264171687
time(NULL)                              = 1264171687
time(NULL)                              = 1264171687
time(NULL)                              = 1264171687
kill(18000, SIGUSR2)                    = 0
nanosleep({0, 20000}, NULL)             = 0
time(NULL)                              = 1264171687
time(NULL)                              = 1264171687
time(NULL)                              = 1264171687
time(NULL)                              = 1264171687
time(NULL)                              = 1264171687
time(NULL)                              = 1264171687
kill(18001, SIGUSR2)                    = 0
nanosleep({0, 20000}, NULL)             = 0
time(NULL)                              = 1264171687
time(NULL)                              = 1264171687
time(NULL)                              = 1264171687
time(NULL)                              = 1264171687
time(NULL)                              = 1264171687
time(NULL)                              = 1264171687
kill(18002, SIGUSR2)                    = 0
nanosleep({0, 20000}, NULL)             = 0
time(NULL)                              = 1264171687
time(NULL)                              = 1264171687
time(NULL)                              = 1264171687
time(NULL)                              = 1264171687
time(NULL)                              = 1264171687
time(NULL)                              = 1264171687
kill(18003, SIGUSR2)                    = 0
nanosleep({0, 20000}, NULL)             = 0
time(NULL)                              = 1264171687
time(NULL)                              = 1264171687
time(NULL)                              = 1264171687
time(NULL)                              = 1264171687
time(NULL)                              = 1264171687
time(NULL)                              = 1264171687
kill(18004, SIGUSR2)                    = 0
nanosleep({0, 20000}, NULL)             = 0
--- SIGTERM (Terminated) @ 0 (0) ---
exit_group(0)                           = ?
Process 18009 detached


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

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

Message:
Hi!

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

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

BR,
Alex.

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

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

Message:
Hi Alex,

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

Regards,
Bogdan

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

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


From chino540off+kamailio at gmail.com  Fri Jan 22 18:55:21 2010
From: chino540off+kamailio at gmail.com (=?ISO-8859-1?Q?Olivier_D=E9tour?=)
Date: Fri, 22 Jan 2010 18:55:21 +0100
Subject: [OpenSIPS-Devel] [B2B_ENTITIES] Difference between sending CANCEL
	and BYE
Message-ID: <99667a341001220955x5bf3b86tc84b79e9f947701f@mail.gmail.com>

Hi,

I would like to break a SIP communication during a call or a
proceeding SIP session...

If the call is in progress (Caller can speak to Callee), I can send a
BYE to caller and callee each with send_request function;
Here is my Wireshark trace:

BYE sip:sa at 1.1.12.3 SIP/2.0
Via: SIP/2.0/UDP 2.2.22.2;branch=z9hG4bKda73.5742b3a7.0
From: <sip:11 at 2.2.22.2>;tag=934c0604001f8a49c065a1707fbb682d-59cf
To: <sip:21 at 1.1.12.3>;tag=B2B.333.0.1264181639
CSeq: 4 BYE
Call-ID: B2B.269.0.1264181639
Content-Length: 0
User-Agent: OpenSIPS (1.6.1-notls (i386/linux))
Contact: <sip:sa at 2.2.22.2>

If the sip session is proceeding (Caller send INVITE but he hasn't
receive 200 OK yet), I send a CANCEL
like I sent the BYE (send_request);
But here is my Wireshark trace:

CANCEL sip:22 at 1.1.12.3 SIP/2.0
Via: SIP/2.0/UDP 2.2.22.2;branch=z9hG4bK5161.0ab21263.0
From: <sip:11 at 2.2.22.2>;tag=934c0604001f8a49c065a1707fbb682d-ac1f
To: sip:22 at 1.1.12.3
CSeq: 2 CANCEL
Call-ID: B2B.134.0.1264181129
User-Agent: OpenSIPS (1.6.1-notls (i386/linux))
Contact: <sip:sa at 2.2.22.2>

Why is the Request Line not for sip:sa at 1.1.12.3 as for the BYE?

Regards,

-- 
Olivier D?tour
Sent from Paris, ?le-de-France, France


From bogdan at voice-system.ro  Fri Jan 22 19:03:30 2010
From: bogdan at voice-system.ro (Bogdan-Andrei Iancu)
Date: Fri, 22 Jan 2010 20:03:30 +0200
Subject: [OpenSIPS-Devel] [B2B_ENTITIES] Difference between sending
 CANCEL and BYE
In-Reply-To: <99667a341001220955x5bf3b86tc84b79e9f947701f@mail.gmail.com>
References: <99667a341001220955x5bf3b86tc84b79e9f947701f@mail.gmail.com>
Message-ID: <4B59E872.2040906@voice-system.ro>

Hi Oliver,

BYE is a sequential request and id built based on the 200 OK from 
INVITE, while CANCEL is special request that is send before getting the 
200 OK -> there are different contexts and the 2 requests are build in 
different ways.

I strongly suggest to read the RFC3261 about building CANCEL and 
sequential request - it the best source.

Regards,
Bogdan

Olivier D?tour wrote:
> Hi,
>
> I would like to break a SIP communication during a call or a
> proceeding SIP session...
>
> If the call is in progress (Caller can speak to Callee), I can send a
> BYE to caller and callee each with send_request function;
> Here is my Wireshark trace:
>
> BYE sip:sa at 1.1.12.3 SIP/2.0
> Via: SIP/2.0/UDP 2.2.22.2;branch=z9hG4bKda73.5742b3a7.0
> From: <sip:11 at 2.2.22.2>;tag=934c0604001f8a49c065a1707fbb682d-59cf
> To: <sip:21 at 1.1.12.3>;tag=B2B.333.0.1264181639
> CSeq: 4 BYE
> Call-ID: B2B.269.0.1264181639
> Content-Length: 0
> User-Agent: OpenSIPS (1.6.1-notls (i386/linux))
> Contact: <sip:sa at 2.2.22.2>
>
> If the sip session is proceeding (Caller send INVITE but he hasn't
> receive 200 OK yet), I send a CANCEL
> like I sent the BYE (send_request);
> But here is my Wireshark trace:
>
> CANCEL sip:22 at 1.1.12.3 SIP/2.0
> Via: SIP/2.0/UDP 2.2.22.2;branch=z9hG4bK5161.0ab21263.0
> From: <sip:11 at 2.2.22.2>;tag=934c0604001f8a49c065a1707fbb682d-ac1f
> To: sip:22 at 1.1.12.3
> CSeq: 2 CANCEL
> Call-ID: B2B.134.0.1264181129
> User-Agent: OpenSIPS (1.6.1-notls (i386/linux))
> Contact: <sip:sa at 2.2.22.2>
>
> Why is the Request Line not for sip:sa at 1.1.12.3 as for the BYE?
>
> Regards,
>
>   


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



From abalashov at evaristesys.com  Fri Jan 22 19:11:26 2010
From: abalashov at evaristesys.com (Alex Balashov)
Date: Fri, 22 Jan 2010 13:11:26 -0500
Subject: [OpenSIPS-Devel] [B2B_ENTITIES] Difference between sending
	CANCEL and BYE
In-Reply-To: <99667a341001220955x5bf3b86tc84b79e9f947701f@mail.gmail.com>
References: <99667a341001220955x5bf3b86tc84b79e9f947701f@mail.gmail.com>
Message-ID: <7A70DB8B-3FD8-4059-8FE1-CF5FEA7FD3BD@evaristesys.com>

BYEs are sequential (in-dialog) requests that go to the RURI that is  
the Contact returned in the final 2xx reply.

CANCELs are sent to the proximate endpoint - same RURI as initial  
INVITE request.  They are not sequential requests, are not loose- 
routed, etc.

So, the behaviour you are seeing is normal.

--
Sent from mobile device

On Jan 22, 2010, at 12:55 PM, Olivier D?tour <chino540off+kamailio at gmail.co 
m> wrote:

> Hi,
>
> I would like to break a SIP communication during a call or a
> proceeding SIP session...
>
> If the call is in progress (Caller can speak to Callee), I can send a
> BYE to caller and callee each with send_request function;
> Here is my Wireshark trace:
>
> BYE sip:sa at 1.1.12.3 SIP/2.0
> Via: SIP/2.0/UDP 2.2.22.2;branch=z9hG4bKda73.5742b3a7.0
> From: <sip:11 at 2.2.22.2>;tag=934c0604001f8a49c065a1707fbb682d-59cf
> To: <sip:21 at 1.1.12.3>;tag=B2B.333.0.1264181639
> CSeq: 4 BYE
> Call-ID: B2B.269.0.1264181639
> Content-Length: 0
> User-Agent: OpenSIPS (1.6.1-notls (i386/linux))
> Contact: <sip:sa at 2.2.22.2>
>
> If the sip session is proceeding (Caller send INVITE but he hasn't
> receive 200 OK yet), I send a CANCEL
> like I sent the BYE (send_request);
> But here is my Wireshark trace:
>
> CANCEL sip:22 at 1.1.12.3 SIP/2.0
> Via: SIP/2.0/UDP 2.2.22.2;branch=z9hG4bK5161.0ab21263.0
> From: <sip:11 at 2.2.22.2>;tag=934c0604001f8a49c065a1707fbb682d-ac1f
> To: sip:22 at 1.1.12.3
> CSeq: 2 CANCEL
> Call-ID: B2B.134.0.1264181129
> User-Agent: OpenSIPS (1.6.1-notls (i386/linux))
> Contact: <sip:sa at 2.2.22.2>
>
> Why is the Request Line not for sip:sa at 1.1.12.3 as for the BYE?
>
> Regards,
>
> -- 
> Olivier D?tour
> Sent from Paris, ?le-de-France, France
>
> _______________________________________________
> Devel mailing list
> Devel at lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/devel


From chino540off+kamailio at gmail.com  Fri Jan 22 20:31:07 2010
From: chino540off+kamailio at gmail.com (=?ISO-8859-1?Q?Olivier_D=E9tour?=)
Date: Fri, 22 Jan 2010 20:31:07 +0100
Subject: [OpenSIPS-Devel] [B2B_ENTITIES] Difference between sending
	CANCEL and BYE
In-Reply-To: <7A70DB8B-3FD8-4059-8FE1-CF5FEA7FD3BD@evaristesys.com>
References: <99667a341001220955x5bf3b86tc84b79e9f947701f@mail.gmail.com>
	<7A70DB8B-3FD8-4059-8FE1-CF5FEA7FD3BD@evaristesys.com>
Message-ID: <99667a341001221131w7d02442bydb544456368f20ce@mail.gmail.com>

Hi,

I understand the problem, but I would like to explain you my topology:

                      Broker1             Broker2
                          |                       |
Tel(10) ---------- B2BUA1 ---------- B2BUA2 ---------- Tel(20)

My problem is when 10 calls 20, 20 is ringing (so B2BUAs create their
UAS and UAC).
I want to be able to brake the current SIP session at this moment.
So I send the CANCEL to UAC side on B2BUA1. But B2BUA2 doesn't want to
receive it,
because It is not send to sip:sa at 1.1.12.3. So message could not be
transmit to B2BUA2 ...

Maybe, I don't understand something here, but b2b_entities API could
be able to manage
this situation ?

Regards,

-- 
Olivier D?tour
Sent from Paris, Ile-de-France, France


From noreply at sourceforge.net  Fri Jan 22 21:06:16 2010
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 22 Jan 2010 20:06:16 +0000
Subject: [OpenSIPS-Devel] [ opensips-Bugs-2937441 ] opensips crashes on
	reply recieved to b2bua
Message-ID: <E1NYPlo-0003yS-Tq@1bkjzd1.ch3.sourceforge.com>

Bugs item #2937441, was opened at 2010-01-22 20:06
Message generated for change (Tracker Item Submitted) made by rrevels
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=2937441&group_id=232389

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: modules
Group: 1.6.x
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Richard Revels (rrevels)
Assigned to: Nobody/Anonymous (nobody)
Summary: opensips crashes on reply recieved to b2bua

Initial Comment:
using opensips 1.6 revision 6526

Here are a couple of backtraces from two core files.  I am seeing this on every call using top hiding in b2bua.  If is simply route the calls without b2bua opensips doesn't crash.

Crash with two processing threads.  Using media proxy on outbound leg.

[New process 29632]
#0  __dialog_confirmed (dlg=0x2af97535b6b0, type=<value optimized out>, _params=0x2af9709346a0) at nat_traversal.c:968
968	    snprintf(uri, 64, "sip:%s:%d", ip_addr2a(&msg->rcv.src_ip), msg->rcv.src_port);
(gdb) bt
#0  __dialog_confirmed (dlg=0x2af97535b6b0, type=<value optimized out>, _params=0x2af9709346a0) at nat_traversal.c:968
#1  0x00002af970708e44 in run_dlg_callbacks (type=8, dlg=0x2af97535b6b0, msg=<value optimized out>, dir=1966453448, dlg_data=0x0) at dlg_cb.c:253
#2  0x00002af97071683a in dlg_onreply (t=0x2af97535bc78, type=<value optimized out>, param=<value optimized out>) at dlg_handlers.c:407
#3  0x00002af96e3ea02b in run_trans_callbacks (type=128, trans=0x2af97535bc78, req=0x2af97535d628, rpl=0xffffffffffffffff, code=<value optimized out>) at t_hooks.c:208
#4  0x00002af96e40333b in _reply_light (trans=0x2af97535bc78, 
    buf=0x862bf8 "SIP/2.0 200 OK\r\nVia: SIP/2.0/UDP 10.1.71.226:53239;rport=4609;branch=z9hG4bKPjufub93nobQZJjltsV8VEofSrwBOh3qDb;received=192.168.230.200\r\nFrom: \"Richard Revels\" <sip:+19195551212 at 59.229.150.203.sta.inet.co.th>;t"..., len=824, code=200, to_tag=<value optimized out>, to_tag_len=<value optimized out>, lock=1, bm=0x7fff7ccec800) at t_reply.c:384
#5  0x00002af96e4035a3 in t_reply_with_body (trans=0x2af97535bc78, code=200, text=0x860e70, body=<value optimized out>, new_header=<value optimized out>, to_tag=0x2af9753611d0) at t_reply.c:1607
#6  0x00002af97471369e in b2b_send_reply (et=<value optimized out>, b2b_key=0x2af9753611d0, code=200, text=0x860e70, body=0x7fff7ccecb00, extra_headers=0x7fff7ccecaf0) at dlg.c:803
#7  0x00002af974926803 in b2b_logic_notify (src=1, msg=0x860e40, key=0x2af97535f4e8, type=1, param=<value optimized out>) at logic.c:444
#8  0x00002af9747150e0 in b2b_tm_cback (htable=0x2af97533e928, ps=<value optimized out>) at dlg.c:1515
#9  0x00002af96e3ea02b in run_trans_callbacks (type=512, trans=0x2af97535f528, req=0x0, rpl=0x860e40, code=<value optimized out>) at t_hooks.c:208
#10 0x00002af96e4026e9 in local_reply (t=0x2af97535f528, p_msg=0x2af96e626d38, branch=<value optimized out>, msg_status=<value optimized out>, cancel_bitmap=0x2af975311f48) at t_reply.c:1339
#11 0x00002af96e405009 in reply_received (p_msg=0x860e40) at t_reply.c:1484
#12 0x00000000004213f8 in forward_reply (msg=0x860e40) at forward.c:559
#13 0x0000000000456202 in receive_msg (
    buf=0x754f40 "SIP/2.0 200 OK\r\nVia: SIP/2.0/UDP 203.150.229.59;branch=z9hG4bK25c3.26e79485.0\r\nRecord-Route: <sip:192.168.225.202;lr;ftag=5e133d1dcbcfa06f788b415da1ea9e73-f19a>,<sip:203.150.229.59;lr;ftag=5e133d1dcbcfa06f788b"..., len=1007, rcv_info=0x7fff7cced080) at receive.c:200
#14 0x000000000049a2d4 in udp_rcv_loop () at udp_server.c:492
#15 0x0000000000429bbd in main (argc=9, argv=<value optimized out>) at main.c:818

Crash with two processing threads and stun on client - no media proxy.

[New process 30101]
#0  b2b_send_reply (et=<value optimized out>, b2b_key=0x2ad29f4fa058, code=183, text=0x860938, body=0x7fffe9fc4fd0, extra_headers=0x7fffe9fc4fc0) at dlg.c:762
762		to_tag = &get_to(msg)->tag_value;
(gdb) bt
#0  b2b_send_reply (et=<value optimized out>, b2b_key=0x2ad29f4fa058, code=183, text=0x860938, body=0x7fffe9fc4fd0, extra_headers=0x7fffe9fc4fc0) at dlg.c:762
#1  0x00002ad29eabf803 in b2b_logic_notify (src=1, msg=0x860908, key=0x2ad29f4f8368, type=1, param=<value optimized out>) at logic.c:444
#2  0x00002ad29e8ae0e0 in b2b_tm_cback (htable=0x2ad29f4d7928, ps=<value optimized out>) at dlg.c:1515
#3  0x00002ad29858302b in run_trans_callbacks (type=1024, trans=0x2ad29f4f83a8, req=0x0, rpl=0x860908, code=<value optimized out>) at t_hooks.c:208
#4  0x00002ad29859b4ee in local_reply (t=0x2ad29f4f83a8, p_msg=0x860908, branch=<value optimized out>, msg_status=<value optimized out>, cancel_bitmap=0x7fffe9fc5468)
    at t_reply.c:1333
#5  0x00002ad29859e009 in reply_received (p_msg=0x860908) at t_reply.c:1484
#6  0x00000000004213f8 in forward_reply (msg=0x860908) at forward.c:559
#7  0x0000000000456202 in receive_msg (
    buf=0x754f40 "SIP/2.0 183 Session Progress\r\nVia: SIP/2.0/UDP 203.150.229.59;branch=z9hG4bK58dc.5578968.0\r\nRecord-Route: <sip:192.168.225.202;lr;ftag=5e133d1dcbcfa06f788b415da1ea9e73-fe8b>,<sip:203.150.229.59;lr;ftag=5e133d1"..., len=921, rcv_info=0x7fffe9fc5550) at receive.c:200
#8  0x000000000049a2d4 in udp_rcv_loop () at udp_server.c:492
#9  0x0000000000429bbd in main (argc=9, argv=<value optimized out>) at main.c:818


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

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


From chino540off+kamailio at gmail.com  Sat Jan 23 14:40:00 2010
From: chino540off+kamailio at gmail.com (=?ISO-8859-1?Q?Olivier_D=E9tour?=)
Date: Sat, 23 Jan 2010 14:40:00 +0100
Subject: [OpenSIPS-Devel] [B2B_ENTITIES] Difference between sending
	CANCEL and BYE
In-Reply-To: <99667a341001221131w7d02442bydb544456368f20ce@mail.gmail.com>
References: <99667a341001220955x5bf3b86tc84b79e9f947701f@mail.gmail.com>
	<7A70DB8B-3FD8-4059-8FE1-CF5FEA7FD3BD@evaristesys.com>
	<99667a341001221131w7d02442bydb544456368f20ce@mail.gmail.com>
Message-ID: <99667a341001230540m2926f72cu4442a0c8715ba28c@mail.gmail.com>

2010/1/22 Olivier D?tour <chino540off+kamailio at gmail.com>:
> Hi,
>
> I understand the problem, but I would like to explain you my topology:
>
> ? ? ? ? ? ? ? ? ? ? ?Broker1 ? ? ? ? ? ? Broker2
> ? ? ? ? ? ? ? ? ? ? ? ? ?| ? ? ? ? ? ? ? ? ? ? ? |
> Tel(10) ---------- B2BUA1 ---------- B2BUA2 ---------- Tel(20)
>
> My problem is when 10 calls 20, 20 is ringing (so B2BUAs create their
> UAS and UAC).
> I want to be able to brake the current SIP session at this moment.
> So I send the CANCEL to UAC side on B2BUA1. But B2BUA2 doesn't want to
> receive it,
> because It is not send to sip:sa at 1.1.12.3. So message could not be
> transmit to B2BUA2 ...
>
> Maybe, I don't understand something here, but b2b_entities API could
> be able to manage
> this situation ?
>
> Regards,
>

Hi,

I went through the source code of B2B_entities, and I don't understand
when you search the dlg in int b2b_prescript_f(struct sip_msg *msg,
void *uparam) in dlg.c:

  357 		while(dlg)
  358 		{
  359 			if(ruri.len == dlg->ruri.len && strncmp(ruri.s, dlg->ruri.s,
ruri.len)== 0
  360 					&& dlg->callid.len == callid.len &&
  361 					strncmp(dlg->callid.s, callid.s, callid.len)== 0 &&
  362 					dlg->tag[CALLER_LEG].len == from_tag.len &&
  363 					strncmp(dlg->tag[CALLER_LEG].s, from_tag.s, from_tag.len)== 0)

You check CALLID, FROM_TAG and the REQUEST_URI. If you create the UAS
with B2BUA_entities,
Requests send by caller will change Request URI to speaks directly with UAS.

Why is the RURI in your search?

When I remove the RURI check, it works as my understanding of the RFC.

Regards,

-- 
Olivier D?tour


From chino540off+kamailio at gmail.com  Sat Jan 23 20:22:28 2010
From: chino540off+kamailio at gmail.com (=?ISO-8859-1?Q?Olivier_D=E9tour?=)
Date: Sat, 23 Jan 2010 20:22:28 +0100
Subject: [OpenSIPS-Devel] [B2B_ENTITIES] bug in prescript
Message-ID: <99667a341001231122t3e8803e8tb19f7db2efe97ea@mail.gmail.com>

Hi,

There is a bug in prescript function when you compare RURI with server_addr:

  296         if (method_value!= METHOD_CANCEL &&
  297             !((msg->first_line.u.request.uri.len ==
server_address.len ) &&
  298             strncmp(msg->first_line.u.request.uri.s, server_address.s,
  299             server_address.len)== 0))
  300         {
  301                 LM_DBG("RURI does not point to me\n");
  302                 return 1;
  303         }

with opensips.cfg:

modparam("b2b_entities", "server_address", "sip:sa at 10.10.10.10")

Imagine if the peer change RURI with adding the default port at the
end of the string,
or remove it: the strncmp is not sufficient.

I am working with a Cisco, and it happens.

-- 
Olivier D?tour


From bogdan at voice-system.ro  Mon Jan 25 15:35:05 2010
From: bogdan at voice-system.ro (Bogdan-Andrei Iancu)
Date: Mon, 25 Jan 2010 14:35:05 +0000
Subject: [OpenSIPS-Devel] SF.net SVN: opensips:[6527] trunk/modules/registrar
Message-ID: <E1NZQ1x-0000ZC-GO@dn4whf1.ch3.sourceforge.com>

Revision: 6527
          http://opensips.svn.sourceforge.net/opensips/?rev=6527&view=rev
Author:   bogdan_iancu
Date:     2010-01-25 14:35:05 +0000 (Mon, 25 Jan 2010)

Log Message:
-----------
- new "f" flag added to save() to force overwriting of old contacts with the new ones when max_contacts is reached.

Modified Paths:
--------------
    trunk/modules/registrar/README
    trunk/modules/registrar/doc/registrar_admin.xml
    trunk/modules/registrar/reg_mod.h
    trunk/modules/registrar/save.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 Jan 25 16:03:06 2010
From: bogdan at voice-system.ro (Bogdan-Andrei Iancu)
Date: Mon, 25 Jan 2010 15:03:06 +0000
Subject: [OpenSIPS-Devel] SF.net SVN: opensips:[6528] trunk/modules/tm/mi.c
Message-ID: <E1NZQT4-0001zX-Pp@74yxhf1.ch3.sourceforge.com>

Revision: 6528
          http://opensips.svn.sourceforge.net/opensips/?rev=6528&view=rev
Author:   bogdan_iancu
Date:     2010-01-25 15:03:06 +0000 (Mon, 25 Jan 2010)

Log Message:
-----------
- fixed extraction of URI and display part of FROM / TO headers in t_uac_dlg() MI function.
  Reported by Chris Maciejewski.

Modified Paths:
--------------
    trunk/modules/tm/mi.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 Jan 25 16:06:38 2010
From: bogdan at voice-system.ro (Bogdan-Andrei Iancu)
Date: Mon, 25 Jan 2010 15:06:38 +0000
Subject: [OpenSIPS-Devel] SF.net SVN: opensips:[6529]
	branches/1.6/modules/tm/mi.c
Message-ID: <E1NZQWU-00024a-GC@74yxhf1.ch3.sourceforge.com>

Revision: 6529
          http://opensips.svn.sourceforge.net/opensips/?rev=6529&view=rev
Author:   bogdan_iancu
Date:     2010-01-25 15:06:37 +0000 (Mon, 25 Jan 2010)

Log Message:
-----------
backport from trunk (rev #6528)
- fixed extraction of URI and display part of FROM / TO headers in t_uac_dlg() MI function.
  Reported by Chris Maciejewski.

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

Modified Paths:
--------------
    branches/1.6/modules/tm/mi.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 Jan 25 16:08:15 2010
From: bogdan at voice-system.ro (Bogdan-Andrei Iancu)
Date: Mon, 25 Jan 2010 15:08:15 +0000
Subject: [OpenSIPS-Devel] SF.net SVN: opensips:[6530]
	branches/1.5/modules/tm/mi.c
Message-ID: <E1NZQY3-00026K-05@74yxhf1.ch3.sourceforge.com>

Revision: 6530
          http://opensips.svn.sourceforge.net/opensips/?rev=6530&view=rev
Author:   bogdan_iancu
Date:     2010-01-25 15:08:14 +0000 (Mon, 25 Jan 2010)

Log Message:
-----------
backport from trunk (rev #6528)
- fixed extraction of URI and display part of FROM / TO headers in t_uac_dlg() MI function.
  Reported by Chris Maciejewski.

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

Modified Paths:
--------------
    branches/1.5/modules/tm/mi.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 Jan 25 17:05:26 2010
From: bogdan at voice-system.ro (Bogdan-Andrei Iancu)
Date: Mon, 25 Jan 2010 16:05:26 +0000
Subject: [OpenSIPS-Devel] SF.net SVN: opensips:[6531] trunk/modules/db_mysql
Message-ID: <E1NZRRO-0003Ew-VA@74yxhf1.ch3.sourceforge.com>

Revision: 6531
          http://opensips.svn.sourceforge.net/opensips/?rev=6531&view=rev
Author:   bogdan_iancu
Date:     2010-01-25 16:05:26 +0000 (Mon, 25 Jan 2010)

Log Message:
-----------
- fixed bogus handling of NULL flag in return data after queries.
  Reported by Alan Frisch

Modified Paths:
--------------
    trunk/modules/db_mysql/my_con.h
    trunk/modules/db_mysql/row.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 Jan 25 17:07:20 2010
From: bogdan at voice-system.ro (Bogdan-Andrei Iancu)
Date: Mon, 25 Jan 2010 16:07:20 +0000
Subject: [OpenSIPS-Devel] SF.net SVN: opensips:[6532]
	branches/1.6/modules/db_mysql
Message-ID: <E1NZRTE-0003HZ-8D@74yxhf1.ch3.sourceforge.com>

Revision: 6532
          http://opensips.svn.sourceforge.net/opensips/?rev=6532&view=rev
Author:   bogdan_iancu
Date:     2010-01-25 16:07:14 +0000 (Mon, 25 Jan 2010)

Log Message:
-----------
backport from truk (rev #6531):
- fixed bogus handling of NULL flag in return data after queries.
  Reported by Alan Frisch

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

Modified Paths:
--------------
    branches/1.6/modules/db_mysql/my_con.h
    branches/1.6/modules/db_mysql/row.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 Jan 25 17:08:58 2010
From: bogdan at voice-system.ro (Bogdan-Andrei Iancu)
Date: Mon, 25 Jan 2010 16:08:58 +0000
Subject: [OpenSIPS-Devel] SF.net SVN: opensips:[6533]
	branches/1.5/modules/db_mysql
Message-ID: <E1NZRUo-0003Jr-5p@74yxhf1.ch3.sourceforge.com>

Revision: 6533
          http://opensips.svn.sourceforge.net/opensips/?rev=6533&view=rev
Author:   bogdan_iancu
Date:     2010-01-25 16:08:51 +0000 (Mon, 25 Jan 2010)

Log Message:
-----------
backport from truk (rev #6531):
- fixed bogus handling of NULL flag in return data after queries.
  Reported by Alan Frisch

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

Modified Paths:
--------------
    branches/1.5/modules/db_mysql/my_con.h
    branches/1.5/modules/db_mysql/row.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 Jan 25 19:26:00 2010
From: bogdan at voice-system.ro (Bogdan-Andrei Iancu)
Date: Mon, 25 Jan 2010 18:26:00 +0000
Subject: [OpenSIPS-Devel] SF.net SVN: opensips:[6534]
	trunk/modules/permissions
Message-ID: <E1NZTdQ-0005WR-PN@3kljzd1.ch3.sourceforge.com>

Revision: 6534
          http://opensips.svn.sourceforge.net/opensips/?rev=6534&view=rev
Author:   bogdan_iancu
Date:     2010-01-25 18:26:00 +0000 (Mon, 25 Jan 2010)

Log Message:
-----------
- fixed DB_STR / DB_STRING incompatibility when loading from DB
  Reported by Leonid

Modified Paths:
--------------
    trunk/modules/permissions/address.c
    trunk/modules/permissions/hash.c
    trunk/modules/permissions/hash.h


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


From ag at ag-projects.com  Mon Jan 25 19:26:06 2010
From: ag at ag-projects.com (Adrian Georgescu)
Date: Mon, 25 Jan 2010 19:26:06 +0100
Subject: [OpenSIPS-Devel] New SIP SIMPLE client SDK release 0.12.0
Message-ID: <669EFD26-70E5-443B-8BFD-1584E9FA1D52@ag-projects.com>

Hello,

A new release for SIP SIMPLE client SDK is available.

SIP SIMPLE client is a Software Development Kit for easy development  
of Real Time Applications based on SIP and related protocols for  
Presence, Audio, Instant Messaging (IM), File Transfers and Desktop  
Sharing. Other media types can be easily added by using an extensible  
high-level API. The presence related features have been developed in  
combination with OpenSIPS Presence Agent and OpenXCAP.

The software is available as a tar archive, darcs repository or as a  
Debian package for Debian unstable distribution.

Installation instructions are available at:

http://sipsimpleclient.com/wiki/SipInstallation

The changelog is attached:

python-sipsimple (0.12.0) unstable; urgency=low

   * Removed obsolete desktopsharing.py file
   * Use OMA standard auids for icon and directory applications
   * Added slot property to AudioStream
   * Refactored DNS lookup implementation
   * Don't bit-shift g722 audio samples
   * Updated installation procedures
   * Added IVirtualAudioDevice interface and support for it in  
AudioStream
   * Modified DNSLookup to offer both a synchronous and an  
asynchronous API
   * Improved logging in DNSLookup.lookup_service
   * Added the request URI to the SIPEngineGotMessage notification data
   * Added CIPID (RFC4482) application
   * Added check in MSRPStreamBase for transport mismatch in settings
   * Added checks for SDP media stream transport for incoming sessions
   * Made Registration always communicate via notifications
   * Added capabilities application (RFC5196)
   * Added conference XML application (RFC4575)
   * Added message summary application (RFC3842)
   * Modified AudioStream to support changing the rtp port in reINVITEs
   * Pass code and reason of SIP MESSAGE response to its notification
   * Added dialog-info application (RFC4235)
   * Added call_in_(twisted|green)_thread utility functions
   * Added limit utility function
   * Refactored sipsimple.account using a green model
   * Restrucutred SIPApplication to simplify the code
   * Added support for detecting default IP address changes
   * Added redirect_identities attribute to SIPSessionDidFail  
notifications
   * Modified Account to re-register when some settings change
   * Removed sip.ip_address and rtp.ip_address global settings
   * Removed msrp.port global setting
   * Reorganized account registration notifications
   * Reorganized settings
   * Patched dns.entropy module which is not thread-safe
   * Modified SilenceableWaveFile to use a green model
   * Made Account.credentials a property
   * Reorganized the contents of the sipsimple.util module
   * Modified MSRPStreamBase to stop other operations when an end is  
requested
   * Added support for SystemDidWakeUpFromSleep notification in  
registration
   * Moved Timestamp from sipsimple.applications.util to sipsimple.util
   * Removed sipclients related modules, scripts and data from the  
project
   * Reorganized packages and modules
   * Numerous bug fixes

Kind regards,
Adrian Georgescu



From ag at ag-projects.com  Mon Jan 25 19:27:26 2010
From: ag at ag-projects.com (Adrian Georgescu)
Date: Mon, 25 Jan 2010 19:27:26 +0100
Subject: [OpenSIPS-Devel] New SIP SIMPLE Clients release 0.12.0
Message-ID: <2AA0EEF7-C883-475A-BFDB-7E2EE695D47C@ag-projects.com>

Hello,

A new release for SIP SIMPLE Clients is available.

SIP SIMPLE Clients can be used for setting up Audio, Instant Messaging  
(IM) and File Transfer sessions, Publish and Subscribe for presence or  
other events. The clients can be used in a Unix terminal on Linux and  
MacOSX operating systems.

The software is available as a tar archive, darcs repository or as a  
Debian package for Debian unstable distribution. Installation  
instructions are available at:

http://sipsimpleclient.com/wiki/SipInstallation

The following clients are available:

  * sip-settings - Manage the settings used by all clients
  * sip-register - REGISTER a SIP end-point with a SIP Registrar
  * sip-session - Supports multiple Audio, IM and File Transfers  
sessions
  * sip-audio-session - Setup an Audio session
  * sip-message - Exchange text in page mode using SIP MESSAGE method
  * sip-publish-presence - Publish presence event to a SIP Presence  
Agent
  * sip-subscribe-winfo - SUBSCRIBE to watcher list on a SIP Presence  
Agent
  * sip-subscribe-presence - SUBSCRIBE to presence event
  * sip-auto-publish-presence - Publish randomly generated presence  
event
  * sip-subscribe-rls - SUBSCRIBE to lists managed by a SIP Resource  
List Server
  * sip-subscribe-xcap-diff - SUBSCRIBE to XCAP resources changes
  * sip-subscribe-mwi - SUBSCRIBE to Message Waiting Indication on a  
Voicemail server
  * xcap-directory - List documents stored on a XCAP server for a  
given user
  * xcap-pres-rules - Manage the content of a pres-rules XCAP document
  * xcap-dialog-rules - Manage the content of a dialog-rules XCAP  
document
  * xcap-icon - Manage an icon document stored on the XCAP server
  * xcap-rls-services - Manage the content of a rls-services XCAP  
document

For how to setup and use the clients visit:

http://sipsimpleclient.com/wiki/SipTesting

Kind regards,
Adrian Georgescu



From bogdan at voice-system.ro  Tue Jan 26 09:20:45 2010
From: bogdan at voice-system.ro (Bogdan-Andrei Iancu)
Date: Tue, 26 Jan 2010 08:20:45 +0000
Subject: [OpenSIPS-Devel] SF.net SVN: opensips:[6535]
	trunk/modules/tm/t_msgbuilder.c
Message-ID: <E1NZgfF-0004xu-LP@74yxhf1.ch3.sourceforge.com>

Revision: 6535
          http://opensips.svn.sourceforge.net/opensips/?rev=6535&view=rev
Author:   bogdan_iancu
Date:     2010-01-26 08:20:45 +0000 (Tue, 26 Jan 2010)

Log Message:
-----------
- added an extra space between the display name and URI name in t_uac_dlg.

Modified Paths:
--------------
    trunk/modules/tm/t_msgbuilder.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 Jan 26 09:22:21 2010
From: bogdan at voice-system.ro (Bogdan-Andrei Iancu)
Date: Tue, 26 Jan 2010 08:22:21 +0000
Subject: [OpenSIPS-Devel] SF.net SVN: opensips:[6536]
	branches/1.6/modules/tm/t_msgbuilder.c
Message-ID: <E1NZggn-00050A-VO@74yxhf1.ch3.sourceforge.com>

Revision: 6536
          http://opensips.svn.sourceforge.net/opensips/?rev=6536&view=rev
Author:   bogdan_iancu
Date:     2010-01-26 08:22:21 +0000 (Tue, 26 Jan 2010)

Log Message:
-----------
backport from trunk (rev #6535):
- added an extra space between the display name and URI name in t_uac_dlg.

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

Modified Paths:
--------------
    branches/1.6/modules/tm/t_msgbuilder.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 Jan 26 09:23:10 2010
From: bogdan at voice-system.ro (Bogdan-Andrei Iancu)
Date: Tue, 26 Jan 2010 08:23:10 +0000
Subject: [OpenSIPS-Devel] SF.net SVN: opensips:[6537]
	branches/1.5/modules/tm/t_msgbuilder.c
Message-ID: <E1NZgha-00051N-Aj@74yxhf1.ch3.sourceforge.com>

Revision: 6537
          http://opensips.svn.sourceforge.net/opensips/?rev=6537&view=rev
Author:   bogdan_iancu
Date:     2010-01-26 08:23:10 +0000 (Tue, 26 Jan 2010)

Log Message:
-----------
backport from trunk (rev #6535):
- added an extra space between the display name and URI name in t_uac_dlg.

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

Modified Paths:
--------------
    branches/1.5/modules/tm/t_msgbuilder.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 Jan 26 10:19:05 2010
From: bogdan at voice-system.ro (Bogdan-Andrei Iancu)
Date: Tue, 26 Jan 2010 09:19:05 +0000
Subject: [OpenSIPS-Devel] SF.net SVN: opensips:[6538]
	trunk/modules/permissions/address.c
Message-ID: <E1NZhZh-00089c-G8@dn4whf1.ch3.sourceforge.com>

Revision: 6538
          http://opensips.svn.sourceforge.net/opensips/?rev=6538&view=rev
Author:   bogdan_iancu
Date:     2010-01-26 09:19:05 +0000 (Tue, 26 Jan 2010)

Log Message:
-----------
- accept "" emotry string as "any" protocol.
- fixed check in IP validity

Modified Paths:
--------------
    trunk/modules/permissions/address.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 Jan 26 10:29:38 2010
From: bogdan at voice-system.ro (Bogdan-Andrei Iancu)
Date: Tue, 26 Jan 2010 09:29:38 +0000
Subject: [OpenSIPS-Devel] SF.net SVN: opensips:[6539]
	branches/1.6/modules/permissions
Message-ID: <E1NZhju-0008V6-H1@dn4whf1.ch3.sourceforge.com>

Revision: 6539
          http://opensips.svn.sourceforge.net/opensips/?rev=6539&view=rev
Author:   bogdan_iancu
Date:     2010-01-26 09:29:34 +0000 (Tue, 26 Jan 2010)

Log Message:
-----------
backport from trunk (#6534 + #6538):
- fixed DB_STR / DB_STRING incompatibility when loading from DB
  Reported by Leonid
- accept "" emotry string as "any" protocol.
- fixed check in IP validity

Modified Paths:
--------------
    branches/1.6/modules/permissions/address.c
    branches/1.6/modules/permissions/hash.c
    branches/1.6/modules/permissions/hash.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 Jan 26 12:05:28 2010
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue, 26 Jan 2010 11:05:28 +0000
Subject: [OpenSIPS-Devel] [ opensips-Bugs-2937441 ] opensips crashes on
	reply recieved to b2bua
Message-ID: <E1NZjEe-0003hN-Ug@665xhf1.ch3.sourceforge.com>

Bugs item #2937441, was opened at 2010-01-22 21:06
Message generated for change (Comment added) made by elitas
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=2937441&group_id=232389

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: modules
Group: 1.6.x
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Richard Revels (rrevels)
Assigned to: Nobody/Anonymous (nobody)
Summary: opensips crashes on reply recieved to b2bua

Initial Comment:
using opensips 1.6 revision 6526

Here are a couple of backtraces from two core files.  I am seeing this on every call using top hiding in b2bua.  If is simply route the calls without b2bua opensips doesn't crash.

Crash with two processing threads.  Using media proxy on outbound leg.

[New process 29632]
#0  __dialog_confirmed (dlg=0x2af97535b6b0, type=<value optimized out>, _params=0x2af9709346a0) at nat_traversal.c:968
968	    snprintf(uri, 64, "sip:%s:%d", ip_addr2a(&msg->rcv.src_ip), msg->rcv.src_port);
(gdb) bt
#0  __dialog_confirmed (dlg=0x2af97535b6b0, type=<value optimized out>, _params=0x2af9709346a0) at nat_traversal.c:968
#1  0x00002af970708e44 in run_dlg_callbacks (type=8, dlg=0x2af97535b6b0, msg=<value optimized out>, dir=1966453448, dlg_data=0x0) at dlg_cb.c:253
#2  0x00002af97071683a in dlg_onreply (t=0x2af97535bc78, type=<value optimized out>, param=<value optimized out>) at dlg_handlers.c:407
#3  0x00002af96e3ea02b in run_trans_callbacks (type=128, trans=0x2af97535bc78, req=0x2af97535d628, rpl=0xffffffffffffffff, code=<value optimized out>) at t_hooks.c:208
#4  0x00002af96e40333b in _reply_light (trans=0x2af97535bc78, 
    buf=0x862bf8 "SIP/2.0 200 OK\r\nVia: SIP/2.0/UDP 10.1.71.226:53239;rport=4609;branch=z9hG4bKPjufub93nobQZJjltsV8VEofSrwBOh3qDb;received=192.168.230.200\r\nFrom: \"Richard Revels\" <sip:+19195551212 at 59.229.150.203.sta.inet.co.th>;t"..., len=824, code=200, to_tag=<value optimized out>, to_tag_len=<value optimized out>, lock=1, bm=0x7fff7ccec800) at t_reply.c:384
#5  0x00002af96e4035a3 in t_reply_with_body (trans=0x2af97535bc78, code=200, text=0x860e70, body=<value optimized out>, new_header=<value optimized out>, to_tag=0x2af9753611d0) at t_reply.c:1607
#6  0x00002af97471369e in b2b_send_reply (et=<value optimized out>, b2b_key=0x2af9753611d0, code=200, text=0x860e70, body=0x7fff7ccecb00, extra_headers=0x7fff7ccecaf0) at dlg.c:803
#7  0x00002af974926803 in b2b_logic_notify (src=1, msg=0x860e40, key=0x2af97535f4e8, type=1, param=<value optimized out>) at logic.c:444
#8  0x00002af9747150e0 in b2b_tm_cback (htable=0x2af97533e928, ps=<value optimized out>) at dlg.c:1515
#9  0x00002af96e3ea02b in run_trans_callbacks (type=512, trans=0x2af97535f528, req=0x0, rpl=0x860e40, code=<value optimized out>) at t_hooks.c:208
#10 0x00002af96e4026e9 in local_reply (t=0x2af97535f528, p_msg=0x2af96e626d38, branch=<value optimized out>, msg_status=<value optimized out>, cancel_bitmap=0x2af975311f48) at t_reply.c:1339
#11 0x00002af96e405009 in reply_received (p_msg=0x860e40) at t_reply.c:1484
#12 0x00000000004213f8 in forward_reply (msg=0x860e40) at forward.c:559
#13 0x0000000000456202 in receive_msg (
    buf=0x754f40 "SIP/2.0 200 OK\r\nVia: SIP/2.0/UDP 203.150.229.59;branch=z9hG4bK25c3.26e79485.0\r\nRecord-Route: <sip:192.168.225.202;lr;ftag=5e133d1dcbcfa06f788b415da1ea9e73-f19a>,<sip:203.150.229.59;lr;ftag=5e133d1dcbcfa06f788b"..., len=1007, rcv_info=0x7fff7cced080) at receive.c:200
#14 0x000000000049a2d4 in udp_rcv_loop () at udp_server.c:492
#15 0x0000000000429bbd in main (argc=9, argv=<value optimized out>) at main.c:818

Crash with two processing threads and stun on client - no media proxy.

[New process 30101]
#0  b2b_send_reply (et=<value optimized out>, b2b_key=0x2ad29f4fa058, code=183, text=0x860938, body=0x7fffe9fc4fd0, extra_headers=0x7fffe9fc4fc0) at dlg.c:762
762		to_tag = &get_to(msg)->tag_value;
(gdb) bt
#0  b2b_send_reply (et=<value optimized out>, b2b_key=0x2ad29f4fa058, code=183, text=0x860938, body=0x7fffe9fc4fd0, extra_headers=0x7fffe9fc4fc0) at dlg.c:762
#1  0x00002ad29eabf803 in b2b_logic_notify (src=1, msg=0x860908, key=0x2ad29f4f8368, type=1, param=<value optimized out>) at logic.c:444
#2  0x00002ad29e8ae0e0 in b2b_tm_cback (htable=0x2ad29f4d7928, ps=<value optimized out>) at dlg.c:1515
#3  0x00002ad29858302b in run_trans_callbacks (type=1024, trans=0x2ad29f4f83a8, req=0x0, rpl=0x860908, code=<value optimized out>) at t_hooks.c:208
#4  0x00002ad29859b4ee in local_reply (t=0x2ad29f4f83a8, p_msg=0x860908, branch=<value optimized out>, msg_status=<value optimized out>, cancel_bitmap=0x7fffe9fc5468)
    at t_reply.c:1333
#5  0x00002ad29859e009 in reply_received (p_msg=0x860908) at t_reply.c:1484
#6  0x00000000004213f8 in forward_reply (msg=0x860908) at forward.c:559
#7  0x0000000000456202 in receive_msg (
    buf=0x754f40 "SIP/2.0 183 Session Progress\r\nVia: SIP/2.0/UDP 203.150.229.59;branch=z9hG4bK58dc.5578968.0\r\nRecord-Route: <sip:192.168.225.202;lr;ftag=5e133d1dcbcfa06f788b415da1ea9e73-fe8b>,<sip:203.150.229.59;lr;ftag=5e133d1"..., len=921, rcv_info=0x7fffe9fc5550) at receive.c:200
#8  0x000000000049a2d4 in udp_rcv_loop () at udp_server.c:492
#9  0x0000000000429bbd in main (argc=9, argv=<value optimized out>) at main.c:818


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

Comment By: elitas (elitas)
Date: 2010-01-26 12:05

Message:
Opensips: 1.6.1-notls

Same problem for me. 
It goes into top hiding scenario then opensips seems to hang, crashes
after a few seconds and a coredump is created. I thought this was a problem
of misconfiguration but it seems to be an issue with opensips --> although
i am wondering why most people dont seem to experience this problem?

#0  fm_status (qm=0xa7809000) at mem/f_malloc.c:606
#1  0x0806a602 in cleanup (show_status=1) at main.c:367
#2  0x0806b061 in handle_sigs () at main.c:533
#3  0x0806e05e in main (argc=9, argv=0xbfbc2ed4) at main.c:913


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

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


From bogdan at voice-system.ro  Tue Jan 26 12:16:46 2010
From: bogdan at voice-system.ro (Bogdan-Andrei Iancu)
Date: Tue, 26 Jan 2010 11:16:46 +0000
Subject: [OpenSIPS-Devel] SF.net SVN: opensips:[6540]
	trunk/modules/mmgeoip/mmgeoip.c
Message-ID: <E1NZjPa-0002mf-Uo@c3vjzd1.ch3.sourceforge.com>

Revision: 6540
          http://opensips.svn.sourceforge.net/opensips/?rev=6540&view=rev
Author:   bogdan_iancu
Date:     2010-01-26 11:16:46 +0000 (Tue, 26 Jan 2010)

Log Message:
-----------
- fixed bogus addition of AVP - the value must be marked as STR
- remove extr log info - the module and function names are automatically added by opensips logging function

Modified Paths:
--------------
    trunk/modules/mmgeoip/mmgeoip.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 Jan 26 12:46:32 2010
From: bogdan at voice-system.ro (Bogdan-Andrei Iancu)
Date: Tue, 26 Jan 2010 11:46:32 +0000
Subject: [OpenSIPS-Devel] SF.net SVN: opensips:[6541]
	branches/1.6/modules/mmgeoip/mmgeoip.c
Message-ID: <E1NZjsO-0000IF-Q7@74yxhf1.ch3.sourceforge.com>

Revision: 6541
          http://opensips.svn.sourceforge.net/opensips/?rev=6541&view=rev
Author:   bogdan_iancu
Date:     2010-01-26 11:46:32 +0000 (Tue, 26 Jan 2010)

Log Message:
-----------
backport from trunk (rev #6540):
- fixed bogus addition of AVP - the value must be marked as STR
- remove extr log info - the module and function names are automatically added by opensips logging function

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

Modified Paths:
--------------
    branches/1.6/modules/mmgeoip/mmgeoip.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 Jan 26 12:47:42 2010
From: bogdan at voice-system.ro (Bogdan-Andrei Iancu)
Date: Tue, 26 Jan 2010 11:47:42 +0000
Subject: [OpenSIPS-Devel] SF.net SVN: opensips:[6542]
	branches/1.5/modules/mmgeoip/mmgeoip.c
Message-ID: <E1NZjtW-0000Jj-Lj@74yxhf1.ch3.sourceforge.com>

Revision: 6542
          http://opensips.svn.sourceforge.net/opensips/?rev=6542&view=rev
Author:   bogdan_iancu
Date:     2010-01-26 11:47:42 +0000 (Tue, 26 Jan 2010)

Log Message:
-----------
backport from trunk (rev #6540):
- fixed bogus addition of AVP - the value must be marked as STR
- remove extr log info - the module and function names are automatically added by opensips logging function

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

Modified Paths:
--------------
    branches/1.5/modules/mmgeoip/mmgeoip.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 Jan 26 14:37:46 2010
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue, 26 Jan 2010 13:37:46 +0000
Subject: [OpenSIPS-Devel] [ opensips-Bugs-2940213 ] [B2B_ENTITIES]
	b2b_parse_key
Message-ID: <E1NZlc2-0003fX-Ar@d55xhf1.ch3.sourceforge.com>

Bugs item #2940213, was opened at 2010-01-26 13:37
Message generated for change (Tracker Item Submitted) made by nobody
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=2940213&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: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: [B2B_ENTITIES] b2b_parse_key

Initial Comment:
Hi,

This function returns -1 on an error and 0 if it's OK.
But you use it like that:
if(b2b_parse_key(&callid, &hash_index, &local_index) >= 0)
{
// Error
}

Regards,

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

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


From noreply at sourceforge.net  Tue Jan 26 15:54:49 2010
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue, 26 Jan 2010 14:54:49 +0000
Subject: [OpenSIPS-Devel] [ opensips-Bugs-2940274 ] [B2B_ENTITIES]
	b2b_parse_key
Message-ID: <E1NZmob-0001a4-Mi@cdv4jf1.ch3.sourceforge.com>

Bugs item #2940274, was opened at 2010-01-26 14:54
Message generated for change (Tracker Item Submitted) made by nobody
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=2940274&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: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: [B2B_ENTITIES] b2b_parse_key

Initial Comment:
Hi,

This function returns -1 on an error and 0 if it's OK.
But you use it like that:
if(b2b_parse_key(&callid, &hash_index, &local_index) >= 0)
{
// Error
}

Regards,

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

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


From develop2009 at schloh.com  Tue Jan 26 17:53:49 2010
From: develop2009 at schloh.com (Michael Schloh von Bennewitz)
Date: Tue, 26 Jan 2010 17:53:49 +0100
Subject: [OpenSIPS-Devel] Misplaced radius error problem
In-Reply-To: <20091222175038.GA6619@debut.europalab.com>
References: <20091222175038.GA6619@debut.europalab.com>
Message-ID: <20100126165349.GA25596@debut.europalab.com>


Hello list,

On Tues, Dec 22, 2009, Michael Schloh von Bennewitz wrote:
>In revision 6377 rad.c from aaa_radius got changed for the better,
>but introduced a new bug as well. The block of code in question
>returns LM_ERR when the call to rc_auth(3) returns anything but
>OK_RC. As you see from radiusclient-ng.h, other values exist:
>
>  /* 	Define return codes from "SendServer" utility */
>  #define BADRESP_RC	-2
>  #define ERROR_RC	-1
>  #define OK_RC		0
>  #define TIMEOUT_RC	1
>  #define REJECT_RC	2
>
>The only return values leading to failure (and thus validating
>the LM_ERR choice) are negative. So here's the correction:
>
>Index: modules/aaa_radius/rad.c
>diff -Nau modules/aaa_radius/rad.c.orig modules/aaa_radius/rad.c
>--- modules/aaa_radius/rad.c.orig	2009-12-10 19:57:33.000000000 +0100
>+++ modules/aaa_radius/rad.c	2009-12-22 13:28:05.852461686 +0100
>@@ -273,9 +273,14 @@
> 				return -1;
> 			}
> 		}
>-
>-		LM_ERR("rc_auth function failed\n");
>-		return -1;
>+		else if (result == TIMEOUT_RC || result == REJECT_RC) {
>+			LM_DBG("rc_auth function succeeded with result %d\n", result);
>+			return result;
>+		}
>+		else /* if (result == ERROR_RC || result == BADRESP_RC) */ {
>+			LM_ERR("rc_auth function failed with result %d\n", result);
>+			return -1;
>+		}
> 	}
> 
> 	if (request->type == AAA_ACCT) {
>
>What it does is correct the false negative condition in which a
>properly functioning OpenSIPS 1.6.1 reports radius errors in the
>log. Without the correction, every call to aaa_is_user_in() for users
>which do not belong to the group in question produces an error in
>the OpenSIPS log. Try it:
>
>    route {                                  # produces an error
>        aaa_is_user_in("From", "suspened");  # for all users not
>    }                                        # in group 'suspended'
>
>I'm assuming that the 'REJECT' returned from a radius server for
>such calls is correct, although I'm not a radius expert.
>
Was this patch rejected? I see that no correction has been made
to the flawed logic in rad.c.

Regards,
Michael

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


From noreply at sourceforge.net  Tue Jan 26 20:36:59 2010
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue, 26 Jan 2010 19:36:59 +0000
Subject: [OpenSIPS-Devel] [ opensips-Bugs-2940418 ] stale dialog after using
	call hold
Message-ID: <E1NZrDf-00068p-IH@665xhf1.ch3.sourceforge.com>

Bugs item #2940418, was opened at 2010-01-26 21:36
Message generated for change (Tracker Item Submitted) made by apogrebennyk
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=2940418&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: Andrew Pogrebennyk (apogrebennyk)
Assigned to: Nobody/Anonymous (nobody)
Summary: stale dialog after using call hold

Initial Comment:
I've found that if I call the other SIP account, put the call on and off hold (necessarily as a caller - if callee uses call hold this doesn't happen) and then end the call, OpenSIPS keeps thinking this is an active dialog and it just hangs there forever. I am attaching the tcpdump trace of just one problematic call made right on the opensips server and the opensips.log with debug level 3 (it's useful only in the sense that it shows there were no errors in dialog module, but if in increase debug level to 4 there are tons of useless info). This is the output of profile_list_dlgs command obtained after the call was ended.

# opensipsctl fifo profile_list_dlgs caller
dialog::  hash=3718:1395615021
        state:: 4
        user_flags:: 0
        timestart:: 1264533523
        timeout:: 60019
        callid:: ZTkwOGQxYjdlZGYwMDljODE1ODQ3MmRmY2I5MjI0YzM.
        from_uri:: sip:000100 at 68.166.6.122
        from_tag:: ae344d3e
        caller_contact:: sip:000100 at 77.122.227.73:6370
        caller_cseq:: 3
        caller_route_set::
        caller_bind_addr:: udp:68.166.6.122:5060
        to_uri:: sip:000101 at 68.166.6.122
        to_tag:: 2135014f
        callee_contact:: sip:000101 at 77.122.227.73:27436;rinstance=8c6d4f852faa42eb
        callee_cseq:: 2
        callee_route_set::
        callee_bind_addr:: udp:68.166.6.122:5060


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

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


From noreply at sourceforge.net  Tue Jan 26 20:48:16 2010
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue, 26 Jan 2010 19:48:16 +0000
Subject: [OpenSIPS-Devel] [ opensips-Bugs-2940418 ] stale dialog after using
	call hold
Message-ID: <E1NZrOa-0006dT-6e@cdv4jf1.ch3.sourceforge.com>

Bugs item #2940418, was opened at 2010-01-26 21:36
Message generated for change (Comment added) made by apogrebennyk
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=2940418&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: Andrew Pogrebennyk (apogrebennyk)
Assigned to: Nobody/Anonymous (nobody)
Summary: stale dialog after using call hold

Initial Comment:
I've found that if I call the other SIP account, put the call on and off hold (necessarily as a caller - if callee uses call hold this doesn't happen) and then end the call, OpenSIPS keeps thinking this is an active dialog and it just hangs there forever. I am attaching the tcpdump trace of just one problematic call made right on the opensips server and the opensips.log with debug level 3 (it's useful only in the sense that it shows there were no errors in dialog module, but if in increase debug level to 4 there are tons of useless info). This is the output of profile_list_dlgs command obtained after the call was ended.

# opensipsctl fifo profile_list_dlgs caller
dialog::  hash=3718:1395615021
        state:: 4
        user_flags:: 0
        timestart:: 1264533523
        timeout:: 60019
        callid:: ZTkwOGQxYjdlZGYwMDljODE1ODQ3MmRmY2I5MjI0YzM.
        from_uri:: sip:000100 at 68.166.6.122
        from_tag:: ae344d3e
        caller_contact:: sip:000100 at 77.122.227.73:6370
        caller_cseq:: 3
        caller_route_set::
        caller_bind_addr:: udp:68.166.6.122:5060
        to_uri:: sip:000101 at 68.166.6.122
        to_tag:: 2135014f
        callee_contact:: sip:000101 at 77.122.227.73:27436;rinstance=8c6d4f852faa42eb
        callee_cseq:: 2
        callee_route_set::
        callee_bind_addr:: udp:68.166.6.122:5060


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

>Comment By: Andrew Pogrebennyk (apogrebennyk)
Date: 2010-01-26 21:48

Message:
I'm attaching below one the opensips log for another call, this time with
debug=4.

This is the stale dialog after after the call end:
dialog::  hash=3558:842134357
        state:: 4
        user_flags:: 0
        timestart:: 1264534993
        timeout:: 61487
        callid:: YTQ3YjRjNTVjYWQwYWRmOTQ5ZDE3MmZjOTlhMGIyY2M.
        from_uri:: sip:000100 at 68.166.6.122
        from_tag:: 9673d152
        caller_contact:: sip:000100 at 77.122.227.73:6370
        caller_cseq:: 3
        caller_route_set::
        caller_bind_addr:: udp:68.166.6.122:5060
        to_uri:: sip:000101 at 68.166.6.122
        to_tag:: b542cf1c
        callee_contact::
sip:000101 at 77.122.227.73:27436;rinstance=8c6d4f852faa42eb
        callee_cseq:: 2
        callee_route_set::
        callee_bind_addr:: udp:68.166.6.122:5060

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

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


From noreply at sourceforge.net  Tue Jan 26 20:52:33 2010
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue, 26 Jan 2010 19:52:33 +0000
Subject: [OpenSIPS-Devel] [ opensips-Bugs-2940418 ] stale dialog after using
	call hold
Message-ID: <E1NZrSj-00072M-FT@h45xhf1.ch3.sourceforge.com>

Bugs item #2940418, was opened at 2010-01-26 21:36
Message generated for change (Comment added) made by apogrebennyk
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=2940418&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: Andrew Pogrebennyk (apogrebennyk)
Assigned to: Nobody/Anonymous (nobody)
Summary: stale dialog after using call hold

Initial Comment:
I've found that if I call the other SIP account, put the call on and off hold (necessarily as a caller - if callee uses call hold this doesn't happen) and then end the call, OpenSIPS keeps thinking this is an active dialog and it just hangs there forever. I am attaching the tcpdump trace of just one problematic call made right on the opensips server and the opensips.log with debug level 3 (it's useful only in the sense that it shows there were no errors in dialog module, but if in increase debug level to 4 there are tons of useless info). This is the output of profile_list_dlgs command obtained after the call was ended.

# opensipsctl fifo profile_list_dlgs caller
dialog::  hash=3718:1395615021
        state:: 4
        user_flags:: 0
        timestart:: 1264533523
        timeout:: 60019
        callid:: ZTkwOGQxYjdlZGYwMDljODE1ODQ3MmRmY2I5MjI0YzM.
        from_uri:: sip:000100 at 68.166.6.122
        from_tag:: ae344d3e
        caller_contact:: sip:000100 at 77.122.227.73:6370
        caller_cseq:: 3
        caller_route_set::
        caller_bind_addr:: udp:68.166.6.122:5060
        to_uri:: sip:000101 at 68.166.6.122
        to_tag:: 2135014f
        callee_contact:: sip:000101 at 77.122.227.73:27436;rinstance=8c6d4f852faa42eb
        callee_cseq:: 2
        callee_route_set::
        callee_bind_addr:: udp:68.166.6.122:5060


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

>Comment By: Andrew Pogrebennyk (apogrebennyk)
Date: 2010-01-26 21:52

Message:
Oh and I'm using version 1.5.3
As for configuration script, I'm doing basically create_dialog() and then
set_dlg_profile() to insert dialog onto caller profile.

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

Comment By: Andrew Pogrebennyk (apogrebennyk)
Date: 2010-01-26 21:48

Message:
I'm attaching below one the opensips log for another call, this time with
debug=4.

This is the stale dialog after after the call end:
dialog::  hash=3558:842134357
        state:: 4
        user_flags:: 0
        timestart:: 1264534993
        timeout:: 61487
        callid:: YTQ3YjRjNTVjYWQwYWRmOTQ5ZDE3MmZjOTlhMGIyY2M.
        from_uri:: sip:000100 at 68.166.6.122
        from_tag:: 9673d152
        caller_contact:: sip:000100 at 77.122.227.73:6370
        caller_cseq:: 3
        caller_route_set::
        caller_bind_addr:: udp:68.166.6.122:5060
        to_uri:: sip:000101 at 68.166.6.122
        to_tag:: b542cf1c
        callee_contact::
sip:000101 at 77.122.227.73:27436;rinstance=8c6d4f852faa42eb
        callee_cseq:: 2
        callee_route_set::
        callee_bind_addr:: udp:68.166.6.122:5060

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

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


From noreply at sourceforge.net  Tue Jan 26 23:34:36 2010
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue, 26 Jan 2010 22:34:36 +0000
Subject: [OpenSIPS-Devel] [ opensips-Bugs-2940556 ] Timer bug in TM handler
Message-ID: <E1NZtzY-0006h6-PY@1bkjzd1.ch3.sourceforge.com>

Bugs item #2940556, was opened at 2010-01-27 00:34
Message generated for change (Tracker Item Submitted) made by apogrebennyk
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=2940556&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: Andrew Pogrebennyk (apogrebennyk)
Assigned to: Nobody/Anonymous (nobody)
Summary: Timer bug in TM handler

Initial Comment:
I have got stuck trying to implement a sort of serial forking (forwarding) scenario with OpenSIPS. The thing is that when fr_inv_timer hits, OpenSIPS 
(prematurely) sends INVITE on the next branch and only after that CANCELs the previous one. (And if the gateway receives different branch on transaction to which no final reply has been sent yet - it can merge the requests.) It can be clearly seen in the attached trace that contains messages from the OpenSIPS to the b2bua on the same machine port 5061. I've found this behavior to be consistent in the versions 1.3.2 - 1.5.3, but the logs that follow are from OpenSER 1.3.2. Similar bug has been reported for Kamailio: http://lists.kamailio.org/pipermail/devel/2009-May/018982.html

Another thing I've found is that OpenSIPS resets the fr_timer in retransmission_handler() if no provisional response to INVITE has been received. So if the fr_timer hits OpenSIPS silently fails over to the next forwarding destination without sending CANCEL to this branch (again 1.5.3 is affected). Here we see that it forwards the INVITE and sets FR_TIMER as per script:

Jan 27 05:04:14 sip2 /usr/local/sbin/openser[48744]: Request leaving server, D-URI='<null>' - M=INVITE RURI=sip:40084956288253 at 195.128.80.211:5061 F=sip:000100 at sip2.d-tel.ru T=sip:000101 at sip2.d-tel.ru IP=77.122.227.73 ID=YmM1NGE4NWQ1ZWZhZjVjNDBkNzljODZjYTk5MDVlN2Q.
[...skipped...]
Jan 27 05:04:14 sip2 /usr/local/sbin/openser[48744]: DBG:tm:_set_fr_retr: FR_TIMER = 10
Jan 27 05:04:14 sip2 /usr/local/sbin/openser[48744]: DBG:tm:set_timer: relative timeout is 10
Jan 27 05:04:14 sip2 /usr/local/sbin/openser[48744]: DBG:tm:set_timer: calling insert_timer_unsafe: timeout=10, final value=46
...
Here it hits the retransmission_handler() - and this "relative timeout 
is 1000000" messages appears:

Jan 27 05:04:14 sip2 /usr/local/sbin/openser[48744]: DBG:tm:retransmission_handler: retransmission_handler : request resending (t=0x28701ad0, INVITE si ... )
Jan 27 05:04:14 sip2 /usr/local/sbin/openser[48744]: DBG:tm:set_timer: relative timeout is 1000000
Jan 27 05:04:14 sip2 /usr/local/sbin/openser[48744]: DBG:tm:set_timer: calling insert_timer_unsafe: timeout=1000000, final value=37500000
Jan 27 05:04:14 sip2 /usr/local/sbin/openser[48744]: DBG:tm:insert_timer_unsafe: [5]: 0x28701d30 (37500000)
Jan 27 05:04:14 sip2 /usr/local/sbin/openser[48744]: DBG:tm:retransmission_handler: retransmission_handler : done

I think this timeout somehow interferes with fr_timer because when fr_timer hits in 20 seconds, OpenSIPS _silently_ fails over to the next 
forwarding destination without sending CANCEL to _this_ branch. This occurs only when no provisional response has been got so I tend to think 
this is somehow related to the timeout thing.

I have added extra debug print to insert_timer_unsafe() like:
  LM_DBG("calling insert_timer_unsafe: timeout=%lld, final value=%lld\n",timeout,timeout + get_ticks());

so you could see the sequence of timer updates:
Jan 27 05:04:15 sip2 /usr/local/sbin/openser[48744]: DBG:tm:set_timer: calling insert_timer_unsafe: timeout=2000000, final value=39500000
Jan 27 05:04:17 sip2 /usr/local/sbin/openser[48744]: DBG:tm:set_timer: calling insert_timer_unsafe: timeout=4000000, final value=43500000
Jan 27 05:04:21 sip2 /usr/local/sbin/openser[48744]: DBG:tm:set_timer: calling insert_timer_unsafe: timeout=4000000, final value=47500000

Then OpenSIPS fails over to the next forwarding destination on locally generated 408 - but note there is no real "sending cancel..." message 
from cancel_branch() between these messages:

Jan 27 05:04:24 sip2 /usr/local/sbin/openser[48744]: DBG:tm:insert_timer_unsafe: [0]: 0x28701e60 (56)
Jan 27 05:04:24 sip2 /usr/local/sbin/openser[48744]: DBG:tm:relay_reply: branch=1, save=1, relay=-1
Jan 27 05:04:24 sip2 /usr/local/sbin/openser[48744]: DBG:tm:final_response_handler: done

Please check.

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

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


From noreply at sourceforge.net  Tue Jan 26 23:39:28 2010
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue, 26 Jan 2010 22:39:28 +0000
Subject: [OpenSIPS-Devel] [ opensips-Bugs-2940556 ] Timer bug in TM handler
Message-ID: <E1NZu4G-0001iX-LY@665xhf1.ch3.sourceforge.com>

Bugs item #2940556, was opened at 2010-01-27 00:34
Message generated for change (Comment added) made by apogrebennyk
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=2940556&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: Andrew Pogrebennyk (apogrebennyk)
Assigned to: Nobody/Anonymous (nobody)
Summary: Timer bug in TM handler

Initial Comment:
I have got stuck trying to implement a sort of serial forking (forwarding) scenario with OpenSIPS. The thing is that when fr_inv_timer hits, OpenSIPS 
(prematurely) sends INVITE on the next branch and only after that CANCELs the previous one. (And if the gateway receives different branch on transaction to which no final reply has been sent yet - it can merge the requests.) It can be clearly seen in the attached trace that contains messages from the OpenSIPS to the b2bua on the same machine port 5061. I've found this behavior to be consistent in the versions 1.3.2 - 1.5.3, but the logs that follow are from OpenSER 1.3.2. Similar bug has been reported for Kamailio: http://lists.kamailio.org/pipermail/devel/2009-May/018982.html

Another thing I've found is that OpenSIPS resets the fr_timer in retransmission_handler() if no provisional response to INVITE has been received. So if the fr_timer hits OpenSIPS silently fails over to the next forwarding destination without sending CANCEL to this branch (again 1.5.3 is affected). Here we see that it forwards the INVITE and sets FR_TIMER as per script:

Jan 27 05:04:14 sip2 /usr/local/sbin/openser[48744]: Request leaving server, D-URI='<null>' - M=INVITE RURI=sip:40084956288253 at 195.128.80.211:5061 F=sip:000100 at sip2.d-tel.ru T=sip:000101 at sip2.d-tel.ru IP=77.122.227.73 ID=YmM1NGE4NWQ1ZWZhZjVjNDBkNzljODZjYTk5MDVlN2Q.
[...skipped...]
Jan 27 05:04:14 sip2 /usr/local/sbin/openser[48744]: DBG:tm:_set_fr_retr: FR_TIMER = 10
Jan 27 05:04:14 sip2 /usr/local/sbin/openser[48744]: DBG:tm:set_timer: relative timeout is 10
Jan 27 05:04:14 sip2 /usr/local/sbin/openser[48744]: DBG:tm:set_timer: calling insert_timer_unsafe: timeout=10, final value=46
...
Here it hits the retransmission_handler() - and this "relative timeout 
is 1000000" messages appears:

Jan 27 05:04:14 sip2 /usr/local/sbin/openser[48744]: DBG:tm:retransmission_handler: retransmission_handler : request resending (t=0x28701ad0, INVITE si ... )
Jan 27 05:04:14 sip2 /usr/local/sbin/openser[48744]: DBG:tm:set_timer: relative timeout is 1000000
Jan 27 05:04:14 sip2 /usr/local/sbin/openser[48744]: DBG:tm:set_timer: calling insert_timer_unsafe: timeout=1000000, final value=37500000
Jan 27 05:04:14 sip2 /usr/local/sbin/openser[48744]: DBG:tm:insert_timer_unsafe: [5]: 0x28701d30 (37500000)
Jan 27 05:04:14 sip2 /usr/local/sbin/openser[48744]: DBG:tm:retransmission_handler: retransmission_handler : done

I think this timeout somehow interferes with fr_timer because when fr_timer hits in 20 seconds, OpenSIPS _silently_ fails over to the next 
forwarding destination without sending CANCEL to _this_ branch. This occurs only when no provisional response has been got so I tend to think 
this is somehow related to the timeout thing.

I have added extra debug print to insert_timer_unsafe() like:
  LM_DBG("calling insert_timer_unsafe: timeout=%lld, final value=%lld\n",timeout,timeout + get_ticks());

so you could see the sequence of timer updates:
Jan 27 05:04:15 sip2 /usr/local/sbin/openser[48744]: DBG:tm:set_timer: calling insert_timer_unsafe: timeout=2000000, final value=39500000
Jan 27 05:04:17 sip2 /usr/local/sbin/openser[48744]: DBG:tm:set_timer: calling insert_timer_unsafe: timeout=4000000, final value=43500000
Jan 27 05:04:21 sip2 /usr/local/sbin/openser[48744]: DBG:tm:set_timer: calling insert_timer_unsafe: timeout=4000000, final value=47500000

Then OpenSIPS fails over to the next forwarding destination on locally generated 408 - but note there is no real "sending cancel..." message 
from cancel_branch() between these messages:

Jan 27 05:04:24 sip2 /usr/local/sbin/openser[48744]: DBG:tm:insert_timer_unsafe: [0]: 0x28701e60 (56)
Jan 27 05:04:24 sip2 /usr/local/sbin/openser[48744]: DBG:tm:relay_reply: branch=1, save=1, relay=-1
Jan 27 05:04:24 sip2 /usr/local/sbin/openser[48744]: DBG:tm:final_response_handler: done

Please check.

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

>Comment By: Andrew Pogrebennyk (apogrebennyk)
Date: 2010-01-27 00:39

Message:
Things to note in the ngrep trace: INVITE for branch 1 comes at
05:04:14.173313 - before the CANCEL for branch 0 which comes at
05:04:14.173572.
Then there's INVITE for branch 2 at 05:04:24.274084, but no CANCEL for the
previous branch (fr_timer in action - my b2bua kept retransmitting 183
Session Progress with branch 0, so there was no response for branch 1 at
all).

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

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


From adi at postpi.com  Wed Jan 27 03:46:18 2010
From: adi at postpi.com (adi)
Date: Wed, 27 Jan 2010 09:46:18 +0700
Subject: [OpenSIPS-Devel] ERROR:core:udp_send: sendto(): Operation not
	permitted(1)
Message-ID: 1NZxv8-0005Md-0A@son.postpi.com

Tried stracing and got this:

[pid 20418] sendto(6, "SIP/2.0 100 Giving a try\r\nCSeq: "..., 308, 0, {sa_family=AF_INET, sin_port=htons(5061), sin_addr=inet_addr("10.0.22.1")}, 16) = 308
[pid 20418] write(2, "new branch at sip:100 at 10.0.22.30"..., 38new branch at sip:100 at 10.0.22.30:5062
) = 38
[pid 20418] sendto(6, "INVITE sip:100 at 10.0.22.30:5062 S"..., 1297, 0, {sa_family=AF_INET, sin_port=htons(5062), sin_addr=inet_addr("10.0.22.30")}, 16) = -1 EPERM (Operation not permitted)


What would be the cause? I have no firewall enabled.
BTW, I use latest opensips_1_6 brach.

Thanks.

Regards,

P.Y. Adi Prasaja



From noreply at sourceforge.net  Wed Jan 27 12:08:40 2010
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed, 27 Jan 2010 11:08:40 +0000
Subject: [OpenSIPS-Devel] [ opensips-Feature Requests-2940905 ] per-module
	use_domain
Message-ID: <E1Na5lI-0002NJ-GV@1bkjzd1.ch3.sourceforge.com>

Feature Requests item #2940905, was opened at 2010-01-27 12:08
Message generated for change (Tracker Item Submitted) made by viraptor
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086413&aid=2940905&group_id=232389

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: modules
Group: None
Status: Open
Priority: 5
Private: No
Submitted By: Stanislaw Pitucha (viraptor)
Assigned to: Nobody/Anonymous (nobody)
Summary: per-module use_domain

Initial Comment:
I'd like to use a use_domain setting which works per-module instead of globally. An example scenario where this is useful is:

SIP provider has resellers with many custom domains, yet all users share the namespace so usernames are unique. use_domain is turned off to support that.
Provider wants to support aliases on customer domains, which will be checked before registrations - that allows 123 at provider and 123 at customer-alias to coexist. But without use_domain for aliases alone, it's not possible to easily route allow both 123 at customer1-alias and 123 at customer2-alias.

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

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


From noreply at sourceforge.net  Wed Jan 27 19:22:22 2010
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed, 27 Jan 2010 18:22:22 +0000
Subject: [OpenSIPS-Devel] [ opensips-Feature Requests-2941170 ] Dynamic
	Pipes for Rate Limit Module
Message-ID: <E1NaCX0-0005Gh-6g@565xhf1.ch3.sourceforge.com>

Feature Requests item #2941170, was opened at 2010-01-27 18:22
Message generated for change (Tracker Item Submitted) made by nobody
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086413&aid=2941170&group_id=232389

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: modules
Group: None
Status: Open
Priority: 5
Private: No
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: Dynamic Pipes for Rate Limit Module

Initial Comment:
Are there any plans to make the pipes defined in the rate limit module dynamic. Right now they are statically defined in the config, so it makes it difficult to assign these to customers real time. An implementation similar to the Dialog module would be preferred.

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

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


From noreply at sourceforge.net  Wed Jan 27 21:05:02 2010
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed, 27 Jan 2010 20:05:02 +0000
Subject: [OpenSIPS-Devel] [ opensips-Feature Requests-2941212 ] Dynamic
	Pipes for Rate Limit Module
Message-ID: <E1NaE8M-0003MC-Qd@1bkjzd1.ch3.sourceforge.com>

Feature Requests item #2941212, was opened at 2010-01-27 20:05
Message generated for change (Tracker Item Submitted) made by nobody
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086413&aid=2941212&group_id=232389

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: modules
Group: None
Status: Open
Priority: 5
Private: No
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: Dynamic Pipes for Rate Limit Module

Initial Comment:
Are there any plans to make the pipes defined in the rate limit module dynamic. Right now they are statically defined in the config, so it makes it difficult to assign these to customers real time. An implementation similar to the Dialog module would be preferred.

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

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


From noreply at sourceforge.net  Wed Jan 27 21:50:22 2010
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed, 27 Jan 2010 20:50:22 +0000
Subject: [OpenSIPS-Devel] [ opensips-Feature Requests-2941212 ] Dynamic
	Pipes for Rate Limit Module
Message-ID: <E1NaEqE-0004K4-0w@h45xhf1.ch3.sourceforge.com>

Feature Requests item #2941212, was opened at 2010-01-27 15:05
Message generated for change (Comment added) made by osas
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086413&aid=2941212&group_id=232389

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: modules
Group: None
Status: Open
Priority: 5
Private: No
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: Dynamic Pipes for Rate Limit Module

Initial Comment:
Are there any plans to make the pipes defined in the rate limit module dynamic. Right now they are statically defined in the config, so it makes it difficult to assign these to customers real time. An implementation similar to the Dialog module would be preferred.

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

Comment By: Ovidiu Sas (osas)
Date: 2010-01-27 15:50

Message:
Each pipe can be modified in realtime via the mi interface:
http://www.opensips.org/html/docs/modules/devel/ratelimit.html#id228609
Is this what you were looking for?

Also, a pipe can be chosen dynamically via a pseudovariable:
http://www.opensips.org/html/docs/modules/devel/ratelimit.html#id228351 

It is true that on server restart, the pipe topology will be restored to
the one predefined in the config file.

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

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


From noreply at sourceforge.net  Thu Jan 28 09:17:34 2010
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 28 Jan 2010 08:17:34 +0000
Subject: [OpenSIPS-Devel] [ opensips-Bugs-2940213 ] [B2B_ENTITIES]
	b2b_parse_key
Message-ID: <E1NaPZG-0001Vi-05@b55xhf1.ch3.sourceforge.com>

Bugs item #2940213, was opened at 2010-01-26 15:37
Message generated for change (Settings changed) made by bogdan_iancu
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=2940213&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: Deleted
>Resolution: Duplicate
Priority: 5
Private: No
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: [B2B_ENTITIES] b2b_parse_key

Initial Comment:
Hi,

This function returns -1 on an error and 0 if it's OK.
But you use it like that:
if(b2b_parse_key(&callid, &hash_index, &local_index) >= 0)
{
// Error
}

Regards,

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

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


From noreply at sourceforge.net  Thu Jan 28 09:18:34 2010
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 28 Jan 2010 08:18:34 +0000
Subject: [OpenSIPS-Devel] [ opensips-Bugs-2940556 ] Timer bug in TM handler
Message-ID: <E1NaPaE-0001YN-Me@b55xhf1.ch3.sourceforge.com>

Bugs item #2940556, was opened at 2010-01-27 00:34
Message generated for change (Settings changed) made by bogdan_iancu
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=2940556&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: Andrew Pogrebennyk (apogrebennyk)
>Assigned to: Bogdan-Andrei Iancu (bogdan_iancu)
Summary: Timer bug in TM handler

Initial Comment:
I have got stuck trying to implement a sort of serial forking (forwarding) scenario with OpenSIPS. The thing is that when fr_inv_timer hits, OpenSIPS 
(prematurely) sends INVITE on the next branch and only after that CANCELs the previous one. (And if the gateway receives different branch on transaction to which no final reply has been sent yet - it can merge the requests.) It can be clearly seen in the attached trace that contains messages from the OpenSIPS to the b2bua on the same machine port 5061. I've found this behavior to be consistent in the versions 1.3.2 - 1.5.3, but the logs that follow are from OpenSER 1.3.2. Similar bug has been reported for Kamailio: http://lists.kamailio.org/pipermail/devel/2009-May/018982.html

Another thing I've found is that OpenSIPS resets the fr_timer in retransmission_handler() if no provisional response to INVITE has been received. So if the fr_timer hits OpenSIPS silently fails over to the next forwarding destination without sending CANCEL to this branch (again 1.5.3 is affected). Here we see that it forwards the INVITE and sets FR_TIMER as per script:

Jan 27 05:04:14 sip2 /usr/local/sbin/openser[48744]: Request leaving server, D-URI='<null>' - M=INVITE RURI=sip:40084956288253 at 195.128.80.211:5061 F=sip:000100 at sip2.d-tel.ru T=sip:000101 at sip2.d-tel.ru IP=77.122.227.73 ID=YmM1NGE4NWQ1ZWZhZjVjNDBkNzljODZjYTk5MDVlN2Q.
[...skipped...]
Jan 27 05:04:14 sip2 /usr/local/sbin/openser[48744]: DBG:tm:_set_fr_retr: FR_TIMER = 10
Jan 27 05:04:14 sip2 /usr/local/sbin/openser[48744]: DBG:tm:set_timer: relative timeout is 10
Jan 27 05:04:14 sip2 /usr/local/sbin/openser[48744]: DBG:tm:set_timer: calling insert_timer_unsafe: timeout=10, final value=46
...
Here it hits the retransmission_handler() - and this "relative timeout 
is 1000000" messages appears:

Jan 27 05:04:14 sip2 /usr/local/sbin/openser[48744]: DBG:tm:retransmission_handler: retransmission_handler : request resending (t=0x28701ad0, INVITE si ... )
Jan 27 05:04:14 sip2 /usr/local/sbin/openser[48744]: DBG:tm:set_timer: relative timeout is 1000000
Jan 27 05:04:14 sip2 /usr/local/sbin/openser[48744]: DBG:tm:set_timer: calling insert_timer_unsafe: timeout=1000000, final value=37500000
Jan 27 05:04:14 sip2 /usr/local/sbin/openser[48744]: DBG:tm:insert_timer_unsafe: [5]: 0x28701d30 (37500000)
Jan 27 05:04:14 sip2 /usr/local/sbin/openser[48744]: DBG:tm:retransmission_handler: retransmission_handler : done

I think this timeout somehow interferes with fr_timer because when fr_timer hits in 20 seconds, OpenSIPS _silently_ fails over to the next 
forwarding destination without sending CANCEL to _this_ branch. This occurs only when no provisional response has been got so I tend to think 
this is somehow related to the timeout thing.

I have added extra debug print to insert_timer_unsafe() like:
  LM_DBG("calling insert_timer_unsafe: timeout=%lld, final value=%lld\n",timeout,timeout + get_ticks());

so you could see the sequence of timer updates:
Jan 27 05:04:15 sip2 /usr/local/sbin/openser[48744]: DBG:tm:set_timer: calling insert_timer_unsafe: timeout=2000000, final value=39500000
Jan 27 05:04:17 sip2 /usr/local/sbin/openser[48744]: DBG:tm:set_timer: calling insert_timer_unsafe: timeout=4000000, final value=43500000
Jan 27 05:04:21 sip2 /usr/local/sbin/openser[48744]: DBG:tm:set_timer: calling insert_timer_unsafe: timeout=4000000, final value=47500000

Then OpenSIPS fails over to the next forwarding destination on locally generated 408 - but note there is no real "sending cancel..." message 
from cancel_branch() between these messages:

Jan 27 05:04:24 sip2 /usr/local/sbin/openser[48744]: DBG:tm:insert_timer_unsafe: [0]: 0x28701e60 (56)
Jan 27 05:04:24 sip2 /usr/local/sbin/openser[48744]: DBG:tm:relay_reply: branch=1, save=1, relay=-1
Jan 27 05:04:24 sip2 /usr/local/sbin/openser[48744]: DBG:tm:final_response_handler: done

Please check.

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

Comment By: Andrew Pogrebennyk (apogrebennyk)
Date: 2010-01-27 00:39

Message:
Things to note in the ngrep trace: INVITE for branch 1 comes at
05:04:14.173313 - before the CANCEL for branch 0 which comes at
05:04:14.173572.
Then there's INVITE for branch 2 at 05:04:24.274084, but no CANCEL for the
previous branch (fr_timer in action - my b2bua kept retransmitting 183
Session Progress with branch 0, so there was no response for branch 1 at
all).

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

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


From noreply at sourceforge.net  Thu Jan 28 09:18:44 2010
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 28 Jan 2010 08:18:44 +0000
Subject: [OpenSIPS-Devel] [ opensips-Bugs-2940418 ] stale dialog after using
	call hold
Message-ID: <E1NaPaO-0001ZG-Vv@b55xhf1.ch3.sourceforge.com>

Bugs item #2940418, was opened at 2010-01-26 21:36
Message generated for change (Settings changed) made by bogdan_iancu
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=2940418&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: Andrew Pogrebennyk (apogrebennyk)
>Assigned to: Bogdan-Andrei Iancu (bogdan_iancu)
Summary: stale dialog after using call hold

Initial Comment:
I've found that if I call the other SIP account, put the call on and off hold (necessarily as a caller - if callee uses call hold this doesn't happen) and then end the call, OpenSIPS keeps thinking this is an active dialog and it just hangs there forever. I am attaching the tcpdump trace of just one problematic call made right on the opensips server and the opensips.log with debug level 3 (it's useful only in the sense that it shows there were no errors in dialog module, but if in increase debug level to 4 there are tons of useless info). This is the output of profile_list_dlgs command obtained after the call was ended.

# opensipsctl fifo profile_list_dlgs caller
dialog::  hash=3718:1395615021
        state:: 4
        user_flags:: 0
        timestart:: 1264533523
        timeout:: 60019
        callid:: ZTkwOGQxYjdlZGYwMDljODE1ODQ3MmRmY2I5MjI0YzM.
        from_uri:: sip:000100 at 68.166.6.122
        from_tag:: ae344d3e
        caller_contact:: sip:000100 at 77.122.227.73:6370
        caller_cseq:: 3
        caller_route_set::
        caller_bind_addr:: udp:68.166.6.122:5060
        to_uri:: sip:000101 at 68.166.6.122
        to_tag:: 2135014f
        callee_contact:: sip:000101 at 77.122.227.73:27436;rinstance=8c6d4f852faa42eb
        callee_cseq:: 2
        callee_route_set::
        callee_bind_addr:: udp:68.166.6.122:5060


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

Comment By: Andrew Pogrebennyk (apogrebennyk)
Date: 2010-01-26 21:52

Message:
Oh and I'm using version 1.5.3
As for configuration script, I'm doing basically create_dialog() and then
set_dlg_profile() to insert dialog onto caller profile.

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

Comment By: Andrew Pogrebennyk (apogrebennyk)
Date: 2010-01-26 21:48

Message:
I'm attaching below one the opensips log for another call, this time with
debug=4.

This is the stale dialog after after the call end:
dialog::  hash=3558:842134357
        state:: 4
        user_flags:: 0
        timestart:: 1264534993
        timeout:: 61487
        callid:: YTQ3YjRjNTVjYWQwYWRmOTQ5ZDE3MmZjOTlhMGIyY2M.
        from_uri:: sip:000100 at 68.166.6.122
        from_tag:: 9673d152
        caller_contact:: sip:000100 at 77.122.227.73:6370
        caller_cseq:: 3
        caller_route_set::
        caller_bind_addr:: udp:68.166.6.122:5060
        to_uri:: sip:000101 at 68.166.6.122
        to_tag:: b542cf1c
        callee_contact::
sip:000101 at 77.122.227.73:27436;rinstance=8c6d4f852faa42eb
        callee_cseq:: 2
        callee_route_set::
        callee_bind_addr:: udp:68.166.6.122:5060

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

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


From noreply at sourceforge.net  Thu Jan 28 10:24:16 2010
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 28 Jan 2010 09:24:16 +0000
Subject: [OpenSIPS-Devel] [ opensips-Bugs-2941492 ] the second transaction
	is not linked with the dialog
Message-ID: <E1NaQbo-00039r-CY@665xhf1.ch3.sourceforge.com>

Bugs item #2941492, was opened at 2010-01-28 12:24
Message generated for change (Tracker Item Submitted) made by aap061
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=2941492&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: Alexey Popov (aap061)
Assigned to: Nobody/Anonymous (nobody)
Summary: the second transaction is not linked with the dialog

Initial Comment:
If we have multiple transactions within one dialog, all of them must be linked to the dialog.
Overwise, reply route can't use dialog flags for the second and all the following transactions.

This situation can be easily reproduced for re-INVITE case

Proposal solution is attached

Thanks,
Alexey

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

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


From anca at opensips.org  Thu Jan 28 12:50:44 2010
From: anca at opensips.org (Anca Vamanu)
Date: Thu, 28 Jan 2010 11:50:44 +0000
Subject: [OpenSIPS-Devel] SF.net SVN: opensips:[6543]
	trunk/modules/b2b_entities/dlg.c
Message-ID: <E1NaStY-000098-02@d5vjzd1.ch3.sourceforge.com>

Revision: 6543
          http://opensips.svn.sourceforge.net/opensips/?rev=6543&view=rev
Author:   anca_vamanu
Date:     2010-01-28 11:50:43 +0000 (Thu, 28 Jan 2010)

Log Message:
-----------
- fixed wrong strncmp of ruri with server address ( the port must be ignored if one is 5060 and the other not set), reported by Olivier Detour)

Modified Paths:
--------------
    trunk/modules/b2b_entities/dlg.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 Jan 28 12:59:08 2010
From: anca at opensips.org (Anca Vamanu)
Date: Thu, 28 Jan 2010 11:59:08 +0000
Subject: [OpenSIPS-Devel] SF.net SVN: opensips:[6544]
	branches/1.6/modules/b2b_entities/dlg.c
Message-ID: <E1NaT1g-0000Lf-Sf@d5vjzd1.ch3.sourceforge.com>

Revision: 6544
          http://opensips.svn.sourceforge.net/opensips/?rev=6544&view=rev
Author:   anca_vamanu
Date:     2010-01-28 11:59:08 +0000 (Thu, 28 Jan 2010)

Log Message:
-----------
- fixed wrong strncmp of ruri with server address ( the port must be ignored if one is 5060 and the other not set), reported by Olivier Detour)

Modified Paths:
--------------
    branches/1.6/modules/b2b_entities/dlg.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 Jan 28 12:59:53 2010
From: anca at opensips.org (Anca Vamanu)
Date: Thu, 28 Jan 2010 13:59:53 +0200
Subject: [OpenSIPS-Devel] [B2B_ENTITIES] bug in prescript
In-Reply-To: <99667a341001231122t3e8803e8tb19f7db2efe97ea@mail.gmail.com>
References: <99667a341001231122t3e8803e8tb19f7db2efe97ea@mail.gmail.com>
Message-ID: <4B617C39.3070608@opensips.org>

Hi Olivier,

Thank you for the exact report.
I have committed the fix - rev 6544.

Regards,

-- 
Anca Vamanu
www.voice-system.ro


Olivier D?tour wrote:
> Hi,
>
> There is a bug in prescript function when you compare RURI with server_addr:
>
>   296         if (method_value!= METHOD_CANCEL &&
>   297             !((msg->first_line.u.request.uri.len ==
> server_address.len ) &&
>   298             strncmp(msg->first_line.u.request.uri.s, server_address.s,
>   299             server_address.len)== 0))
>   300         {
>   301                 LM_DBG("RURI does not point to me\n");
>   302                 return 1;
>   303         }
>
> with opensips.cfg:
>
> modparam("b2b_entities", "server_address", "sip:sa at 10.10.10.10")
>
> Imagine if the peer change RURI with adding the default port at the
> end of the string,
> or remove it: the strncmp is not sufficient.
>
> I am working with a Cisco, and it happens.
>
>   


From anca at opensips.org  Thu Jan 28 13:05:57 2010
From: anca at opensips.org (Anca Vamanu)
Date: Thu, 28 Jan 2010 14:05:57 +0200
Subject: [OpenSIPS-Devel] [B2B_ENTITIES] Difference between
 sending	CANCEL and BYE
In-Reply-To: <99667a341001230540m2926f72cu4442a0c8715ba28c@mail.gmail.com>
References: <99667a341001220955x5bf3b86tc84b79e9f947701f@mail.gmail.com>	<7A70DB8B-3FD8-4059-8FE1-CF5FEA7FD3BD@evaristesys.com>	<99667a341001221131w7d02442bydb544456368f20ce@mail.gmail.com>
	<99667a341001230540m2926f72cu4442a0c8715ba28c@mail.gmail.com>
Message-ID: <4B617DA5.2070406@opensips.org>

Hi Olivier,

Olivier D?tour wrote:
> 2010/1/22 Olivier D?tour <chino540off+kamailio at gmail.com>:
>   
>> Hi,
>>
>> I understand the problem, but I would like to explain you my topology:
>>
>>                      Broker1             Broker2
>>                          |                       |
>> Tel(10) ---------- B2BUA1 ---------- B2BUA2 ---------- Tel(20)
>>
>> My problem is when 10 calls 20, 20 is ringing (so B2BUAs create their
>> UAS and UAC).
>> I want to be able to brake the current SIP session at this moment.
>> So I send the CANCEL to UAC side on B2BUA1. But B2BUA2 doesn't want to
>> receive it,
>> because It is not send to sip:sa at 1.1.12.3. So message could not be
>> transmit to B2BUA2 ...
>>
>> Maybe, I don't understand something here, but b2b_entities API could
>> be able to manage
>> this situation ?
>>
>> Regards,
>>
>>     
>
> Hi,
>
> I went through the source code of B2B_entities, and I don't understand
> when you search the dlg in int b2b_prescript_f(struct sip_msg *msg,
> void *uparam) in dlg.c:
>
>   357 		while(dlg)
>   358 		{
>   359 			if(ruri.len == dlg->ruri.len && strncmp(ruri.s, dlg->ruri.s,
> ruri.len)== 0
>   360 					&& dlg->callid.len == callid.len &&
>   361 					strncmp(dlg->callid.s, callid.s, callid.len)== 0 &&
>   362 					dlg->tag[CALLER_LEG].len == from_tag.len &&
>   363 					strncmp(dlg->tag[CALLER_LEG].s, from_tag.s, from_tag.len)== 0)
>
> You check CALLID, FROM_TAG and the REQUEST_URI. If you create the UAS
> with B2BUA_entities,
> Requests send by caller will change Request URI to speaks directly with UAS.
>
> Why is the RURI in your search?
>
> When I remove the RURI check, it works as my understanding of the RFC.
>
> Regards,
>
>   
The RURI check was added exactly because the RFC says that the RURI in 
CANCEL must be exactly the same as the RURI in INVITE:

The following procedures are used to construct a CANCEL request.  The
   Request-URI, Call-ID, To, the numeric part of CSeq, and From header
   fields in the CANCEL request MUST be identical to those in the
   request being cancelled, including tags.


Regards,

-- 
Anca Vamanu
www.voice-system.ro



From anca at opensips.org  Thu Jan 28 13:15:00 2010
From: anca at opensips.org (Anca Vamanu)
Date: Thu, 28 Jan 2010 12:15:00 +0000
Subject: [OpenSIPS-Devel] SF.net SVN: opensips:[6545]
	branches/1.6/modules/b2b_entities/dlg.c
Message-ID: <E1NaTH2-0000hI-Sj@d5vjzd1.ch3.sourceforge.com>

Revision: 6545
          http://opensips.svn.sourceforge.net/opensips/?rev=6545&view=rev
Author:   anca_vamanu
Date:     2010-01-28 12:15:00 +0000 (Thu, 28 Jan 2010)

Log Message:
-----------
- changed >= with == for return code checking (bug #2940274)

Modified Paths:
--------------
    branches/1.6/modules/b2b_entities/dlg.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 Jan 28 13:15:09 2010
From: anca at opensips.org (Anca Vamanu)
Date: Thu, 28 Jan 2010 12:15:09 +0000
Subject: [OpenSIPS-Devel] SF.net SVN: opensips:[6546]
	trunk/modules/b2b_entities/dlg.c
Message-ID: <E1NaTHB-0000hy-0Y@d5vjzd1.ch3.sourceforge.com>

Revision: 6546
          http://opensips.svn.sourceforge.net/opensips/?rev=6546&view=rev
Author:   anca_vamanu
Date:     2010-01-28 12:15:08 +0000 (Thu, 28 Jan 2010)

Log Message:
-----------
- changed >= with == for return code checking (bug #2940274)

Modified Paths:
--------------
    trunk/modules/b2b_entities/dlg.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 Jan 28 13:15:48 2010
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 28 Jan 2010 12:15:48 +0000
Subject: [OpenSIPS-Devel] [ opensips-Bugs-2940274 ] [B2B_ENTITIES]
	b2b_parse_key
Message-ID: <E1NaTHo-0007Yd-4v@155xhf1.ch3.sourceforge.com>

Bugs item #2940274, was opened at 2010-01-26 16:54
Message generated for change (Comment added) made by anca_vamanu
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=2940274&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: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: [B2B_ENTITIES] b2b_parse_key

Initial Comment:
Hi,

This function returns -1 on an error and 0 if it's OK.
But you use it like that:
if(b2b_parse_key(&callid, &hash_index, &local_index) >= 0)
{
// Error
}

Regards,

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

>Comment By: Anca Vamanu (anca_vamanu)
Date: 2010-01-28 14:15

Message:
Hi,

Really a very minor thing.. But if you like the strict checking instead, I
put that - see revision 6546.

Regards,
Anca

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

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


From anca at opensips.org  Thu Jan 28 13:39:09 2010
From: anca at opensips.org (Anca Vamanu)
Date: Thu, 28 Jan 2010 14:39:09 +0200
Subject: [OpenSIPS-Devel] [B2B_ENTITIES] Difference between sending
 CANCEL and BYE
In-Reply-To: <99667a341001280423g32f5437esc832a2db0fa51d59@mail.gmail.com>
References: <99667a341001220955x5bf3b86tc84b79e9f947701f@mail.gmail.com>	
	<7A70DB8B-3FD8-4059-8FE1-CF5FEA7FD3BD@evaristesys.com>	
	<99667a341001221131w7d02442bydb544456368f20ce@mail.gmail.com>	
	<99667a341001230540m2926f72cu4442a0c8715ba28c@mail.gmail.com>	
	<4B617DA5.2070406@opensips.org>
	<99667a341001280423g32f5437esc832a2db0fa51d59@mail.gmail.com>
Message-ID: <4B61856D.6040001@opensips.org>

Hi Olivier,

First, please do not send email to me privately ( use reply all).
You are saying that the CANCEL send by b2b_entities does not have the 
exact ruri as INVITE?

Can you catch an INVITE and the corresponding CANCEL (send by 
b2b_entities) and send them in an e-mail?

Regards,

-- 
Anca Vamanu
www.voice-system.ro



Olivier D?tour wrote:
> On Thu, Jan 28, 2010 at 1:05 PM, Anca Vamanu <anca at opensips.org> wrote:
>   
>> Hi Olivier,
>>
>> Olivier D?tour wrote:
>>     
>>> 2010/1/22 Olivier D?tour <chino540off+kamailio at gmail.com>:
>>>
>>>       
>>>> Hi,
>>>>
>>>> I understand the problem, but I would like to explain you my topology:
>>>>
>>>>                     Broker1             Broker2
>>>>                         |                       |
>>>> Tel(10) ---------- B2BUA1 ---------- B2BUA2 ---------- Tel(20)
>>>>
>>>> My problem is when 10 calls 20, 20 is ringing (so B2BUAs create their
>>>> UAS and UAC).
>>>> I want to be able to brake the current SIP session at this moment.
>>>> So I send the CANCEL to UAC side on B2BUA1. But B2BUA2 doesn't want to
>>>> receive it,
>>>> because It is not send to sip:sa at 1.1.12.3. So message could not be
>>>> transmit to B2BUA2 ...
>>>>
>>>> Maybe, I don't understand something here, but b2b_entities API could
>>>> be able to manage
>>>> this situation ?
>>>>
>>>> Regards,
>>>>
>>>>
>>>>         
>>> Hi,
>>>
>>> I went through the source code of B2B_entities, and I don't understand
>>> when you search the dlg in int b2b_prescript_f(struct sip_msg *msg,
>>> void *uparam) in dlg.c:
>>>
>>>  357           while(dlg)
>>>  358           {
>>>  359                   if(ruri.len == dlg->ruri.len && strncmp(ruri.s,
>>> dlg->ruri.s,
>>> ruri.len)== 0
>>>  360                                   && dlg->callid.len == callid.len &&
>>>  361                                   strncmp(dlg->callid.s, callid.s,
>>> callid.len)== 0 &&
>>>  362                                   dlg->tag[CALLER_LEG].len ==
>>> from_tag.len &&
>>>  363                                   strncmp(dlg->tag[CALLER_LEG].s,
>>> from_tag.s, from_tag.len)== 0)
>>>
>>> You check CALLID, FROM_TAG and the REQUEST_URI. If you create the UAS
>>> with B2BUA_entities,
>>> Requests send by caller will change Request URI to speaks directly with
>>> UAS.
>>>
>>> Why is the RURI in your search?
>>>
>>> When I remove the RURI check, it works as my understanding of the RFC.
>>>
>>> Regards,
>>>
>>>
>>>       
>> The RURI check was added exactly because the RFC says that the RURI in
>> CANCEL must be exactly the same as the RURI in INVITE:
>>
>> The following procedures are used to construct a CANCEL request.  The
>>  Request-URI, Call-ID, To, the numeric part of CSeq, and From header
>>  fields in the CANCEL request MUST be identical to those in the
>>  request being cancelled, including tags.
>>
>>
>> Regards,
>>
>>     
>
> I understand the RFC, but I think B2B_Entities is not able to send a
> CANCEL to another
> B2B_Entities and receive it.
>
> So There is a problem, I try to make the architecture with 2 B2B, and
> CANCEL is my last problem.
> I would like to understand how to send and receive CANCEL from and to B2B.
>
> Regards,
>
>   


From chino540off+kamailio at gmail.com  Thu Jan 28 23:30:36 2010
From: chino540off+kamailio at gmail.com (=?ISO-8859-1?Q?Olivier_D=E9tour?=)
Date: Thu, 28 Jan 2010 23:30:36 +0100
Subject: [OpenSIPS-Devel] [B2B_ENTITIES] Difference between sending
	CANCEL and BYE
In-Reply-To: <4B61856D.6040001@opensips.org>
References: <99667a341001220955x5bf3b86tc84b79e9f947701f@mail.gmail.com>
	<7A70DB8B-3FD8-4059-8FE1-CF5FEA7FD3BD@evaristesys.com>
	<99667a341001221131w7d02442bydb544456368f20ce@mail.gmail.com>
	<99667a341001230540m2926f72cu4442a0c8715ba28c@mail.gmail.com>
	<4B617DA5.2070406@opensips.org>
	<99667a341001280423g32f5437esc832a2db0fa51d59@mail.gmail.com>
	<4B61856D.6040001@opensips.org>
Message-ID: <99667a341001281430s491474dau5da0481eb357f78a@mail.gmail.com>

2010/1/28 Anca Vamanu <anca at opensips.org>:
> Hi Olivier,
>
> First, please do not send email to me privately ( use reply all).

Sorry about that, I did not see CC list,

> You are saying that the CANCEL send by b2b_entities does not have the exact
> ruri as INVITE?
>

No I'm saying exactly the opposite, I know sip's RFC about CANCEL
construction with INVITE header. But there a case, if B2B_entities
communicates with another one, CANCEL is correctly
sent to the second B2B_entities. Did you make some tests with 2 B2B
face to face and try to:
 - CANCEL from a phone and propagate it correctly;

 - CANCEL from a B2B and propagate it to the callee phone;
in this case, what is the best way: Send CANCEL on a side and send a
487 on the other side; or send CANCEL and wait 487 from the callee
phone and propagate it to the caller phone ?

> Can you catch an INVITE and the corresponding CANCEL (send by b2b_entities)
> and send them in an e-mail?
>

I don't have time to send it before after next week. I will come back
to you after that and I will give you more information about SIP
transmission, and what I am expected for my project.

Regards,

-- 
Olivier D?tour


From anca at opensips.org  Fri Jan 29 11:25:05 2010
From: anca at opensips.org (Anca Vamanu)
Date: Fri, 29 Jan 2010 10:25:05 +0000
Subject: [OpenSIPS-Devel] SF.net SVN: opensips:[6547]
	trunk/modules/b2b_entities/dlg.c
Message-ID: <E1Nao2D-0003Ee-29@74yxhf1.ch3.sourceforge.com>

Revision: 6547
          http://opensips.svn.sourceforge.net/opensips/?rev=6547&view=rev
Author:   anca_vamanu
Date:     2010-01-29 10:25:04 +0000 (Fri, 29 Jan 2010)

Log Message:
-----------
- fix for the crash reported in bug #2937441

Modified Paths:
--------------
    trunk/modules/b2b_entities/dlg.c


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


From anca at opensips.org  Fri Jan 29 11:26:42 2010
From: anca at opensips.org (Anca Vamanu)
Date: Fri, 29 Jan 2010 10:26:42 +0000
Subject: [OpenSIPS-Devel] SF.net SVN: opensips:[6548]
	branches/1.6/modules/b2b_entities/dlg.c
Message-ID: <E1Nao3m-0003G5-8i@74yxhf1.ch3.sourceforge.com>

Revision: 6548
          http://opensips.svn.sourceforge.net/opensips/?rev=6548&view=rev
Author:   anca_vamanu
Date:     2010-01-29 10:26:42 +0000 (Fri, 29 Jan 2010)

Log Message:
-----------
- fix for the crash reported in bug #2937441

Modified Paths:
--------------
    branches/1.6/modules/b2b_entities/dlg.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 Jan 29 11:29:09 2010
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 29 Jan 2010 10:29:09 +0000
Subject: [OpenSIPS-Devel] [ opensips-Bugs-2937441 ] opensips crashes on
	reply recieved to b2bua
Message-ID: <E1Nao69-0002CS-Al@155xhf1.ch3.sourceforge.com>

Bugs item #2937441, was opened at 2010-01-22 22:06
Message generated for change (Settings changed) made by anca_vamanu
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=2937441&group_id=232389

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: modules
Group: 1.6.x
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Richard Revels (rrevels)
>Assigned to: Anca Vamanu (anca_vamanu)
Summary: opensips crashes on reply recieved to b2bua

Initial Comment:
using opensips 1.6 revision 6526

Here are a couple of backtraces from two core files.  I am seeing this on every call using top hiding in b2bua.  If is simply route the calls without b2bua opensips doesn't crash.

Crash with two processing threads.  Using media proxy on outbound leg.

[New process 29632]
#0  __dialog_confirmed (dlg=0x2af97535b6b0, type=<value optimized out>, _params=0x2af9709346a0) at nat_traversal.c:968
968	    snprintf(uri, 64, "sip:%s:%d", ip_addr2a(&msg->rcv.src_ip), msg->rcv.src_port);
(gdb) bt
#0  __dialog_confirmed (dlg=0x2af97535b6b0, type=<value optimized out>, _params=0x2af9709346a0) at nat_traversal.c:968
#1  0x00002af970708e44 in run_dlg_callbacks (type=8, dlg=0x2af97535b6b0, msg=<value optimized out>, dir=1966453448, dlg_data=0x0) at dlg_cb.c:253
#2  0x00002af97071683a in dlg_onreply (t=0x2af97535bc78, type=<value optimized out>, param=<value optimized out>) at dlg_handlers.c:407
#3  0x00002af96e3ea02b in run_trans_callbacks (type=128, trans=0x2af97535bc78, req=0x2af97535d628, rpl=0xffffffffffffffff, code=<value optimized out>) at t_hooks.c:208
#4  0x00002af96e40333b in _reply_light (trans=0x2af97535bc78, 
    buf=0x862bf8 "SIP/2.0 200 OK\r\nVia: SIP/2.0/UDP 10.1.71.226:53239;rport=4609;branch=z9hG4bKPjufub93nobQZJjltsV8VEofSrwBOh3qDb;received=192.168.230.200\r\nFrom: \"Richard Revels\" <sip:+19195551212 at 59.229.150.203.sta.inet.co.th>;t"..., len=824, code=200, to_tag=<value optimized out>, to_tag_len=<value optimized out>, lock=1, bm=0x7fff7ccec800) at t_reply.c:384
#5  0x00002af96e4035a3 in t_reply_with_body (trans=0x2af97535bc78, code=200, text=0x860e70, body=<value optimized out>, new_header=<value optimized out>, to_tag=0x2af9753611d0) at t_reply.c:1607
#6  0x00002af97471369e in b2b_send_reply (et=<value optimized out>, b2b_key=0x2af9753611d0, code=200, text=0x860e70, body=0x7fff7ccecb00, extra_headers=0x7fff7ccecaf0) at dlg.c:803
#7  0x00002af974926803 in b2b_logic_notify (src=1, msg=0x860e40, key=0x2af97535f4e8, type=1, param=<value optimized out>) at logic.c:444
#8  0x00002af9747150e0 in b2b_tm_cback (htable=0x2af97533e928, ps=<value optimized out>) at dlg.c:1515
#9  0x00002af96e3ea02b in run_trans_callbacks (type=512, trans=0x2af97535f528, req=0x0, rpl=0x860e40, code=<value optimized out>) at t_hooks.c:208
#10 0x00002af96e4026e9 in local_reply (t=0x2af97535f528, p_msg=0x2af96e626d38, branch=<value optimized out>, msg_status=<value optimized out>, cancel_bitmap=0x2af975311f48) at t_reply.c:1339
#11 0x00002af96e405009 in reply_received (p_msg=0x860e40) at t_reply.c:1484
#12 0x00000000004213f8 in forward_reply (msg=0x860e40) at forward.c:559
#13 0x0000000000456202 in receive_msg (
    buf=0x754f40 "SIP/2.0 200 OK\r\nVia: SIP/2.0/UDP 203.150.229.59;branch=z9hG4bK25c3.26e79485.0\r\nRecord-Route: <sip:192.168.225.202;lr;ftag=5e133d1dcbcfa06f788b415da1ea9e73-f19a>,<sip:203.150.229.59;lr;ftag=5e133d1dcbcfa06f788b"..., len=1007, rcv_info=0x7fff7cced080) at receive.c:200
#14 0x000000000049a2d4 in udp_rcv_loop () at udp_server.c:492
#15 0x0000000000429bbd in main (argc=9, argv=<value optimized out>) at main.c:818

Crash with two processing threads and stun on client - no media proxy.

[New process 30101]
#0  b2b_send_reply (et=<value optimized out>, b2b_key=0x2ad29f4fa058, code=183, text=0x860938, body=0x7fffe9fc4fd0, extra_headers=0x7fffe9fc4fc0) at dlg.c:762
762		to_tag = &get_to(msg)->tag_value;
(gdb) bt
#0  b2b_send_reply (et=<value optimized out>, b2b_key=0x2ad29f4fa058, code=183, text=0x860938, body=0x7fffe9fc4fd0, extra_headers=0x7fffe9fc4fc0) at dlg.c:762
#1  0x00002ad29eabf803 in b2b_logic_notify (src=1, msg=0x860908, key=0x2ad29f4f8368, type=1, param=<value optimized out>) at logic.c:444
#2  0x00002ad29e8ae0e0 in b2b_tm_cback (htable=0x2ad29f4d7928, ps=<value optimized out>) at dlg.c:1515
#3  0x00002ad29858302b in run_trans_callbacks (type=1024, trans=0x2ad29f4f83a8, req=0x0, rpl=0x860908, code=<value optimized out>) at t_hooks.c:208
#4  0x00002ad29859b4ee in local_reply (t=0x2ad29f4f83a8, p_msg=0x860908, branch=<value optimized out>, msg_status=<value optimized out>, cancel_bitmap=0x7fffe9fc5468)
    at t_reply.c:1333
#5  0x00002ad29859e009 in reply_received (p_msg=0x860908) at t_reply.c:1484
#6  0x00000000004213f8 in forward_reply (msg=0x860908) at forward.c:559
#7  0x0000000000456202 in receive_msg (
    buf=0x754f40 "SIP/2.0 183 Session Progress\r\nVia: SIP/2.0/UDP 203.150.229.59;branch=z9hG4bK58dc.5578968.0\r\nRecord-Route: <sip:192.168.225.202;lr;ftag=5e133d1dcbcfa06f788b415da1ea9e73-fe8b>,<sip:203.150.229.59;lr;ftag=5e133d1"..., len=921, rcv_info=0x7fffe9fc5550) at receive.c:200
#8  0x000000000049a2d4 in udp_rcv_loop () at udp_server.c:492
#9  0x0000000000429bbd in main (argc=9, argv=<value optimized out>) at main.c:818


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

>Comment By: Anca Vamanu (anca_vamanu)
Date: 2010-01-29 12:29

Message:
Hi Richard,

I can not realize from the trace that you sent the exact problem for the
crash. If you still have the core file can you please run 'print *msg' in
frame 1 and print here the output?
I have analyzed the code, and found a possible cause for the crash, but I
am not sure it is the right one. I have committed a fix for it, so you can
update and try with the new version.

Regards,
Anca

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

Comment By: elitas (elitas)
Date: 2010-01-26 13:05

Message:
Opensips: 1.6.1-notls

Same problem for me. 
It goes into top hiding scenario then opensips seems to hang, crashes
after a few seconds and a coredump is created. I thought this was a problem
of misconfiguration but it seems to be an issue with opensips --> although
i am wondering why most people dont seem to experience this problem?

#0  fm_status (qm=0xa7809000) at mem/f_malloc.c:606
#1  0x0806a602 in cleanup (show_status=1) at main.c:367
#2  0x0806b061 in handle_sigs () at main.c:533
#3  0x0806e05e in main (argc=9, argv=0xbfbc2ed4) at main.c:913


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

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


From anca at opensips.org  Fri Jan 29 12:05:17 2010
From: anca at opensips.org (Anca Vamanu)
Date: Fri, 29 Jan 2010 11:05:17 +0000
Subject: [OpenSIPS-Devel] SF.net SVN: opensips:[6549]
	branches/1.6/modules/b2b_logic
Message-ID: <E1Naof7-00049x-Ld@dn4whf1.ch3.sourceforge.com>

Revision: 6549
          http://opensips.svn.sourceforge.net/opensips/?rev=6549&view=rev
Author:   anca_vamanu
Date:     2010-01-29 11:05:17 +0000 (Fri, 29 Jan 2010)

Log Message:
-----------
- fixed the name for the exported parameter - "cleanup_period" (reported by Jayesh Nambiar)

Modified Paths:
--------------
    branches/1.6/modules/b2b_logic/README
    branches/1.6/modules/b2b_logic/b2b_logic.c


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


