From noreply at sourceforge.net  Thu Nov  1 10:46:46 2012
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 01 Nov 2012 02:46:46 -0700
Subject: [OpenSIPS-Devel] [ opensips-Bugs-3417856 ] BYE not processed
	correctly when using B2BUA module
Message-ID: <mailman.1150.1351763212.13469.devel@lists.opensips.org>

Bugs item #3417856, was opened at 2011-10-03 05:44
Message generated for change (Comment added) made by anca_vamanu
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=3417856&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: Morten Tryfoss (mtryfoss)
Assigned to: Nobody/Anonymous (nobody)
Summary: BYE not processed correctly when using B2BUA module

Initial Comment:
Hi!

I use a simple b2bua-setup for top hiding. The call is set up correctly, but when I hang it up from the callee-side, Opensips tries to forward the BYE to my client's internal ip-adress (behind nat).

Trace between opensips and end-user (end-user is initiating the call):
INVITE sip:48485858 at 85.19.212.36;transport=tcp SIP/2.0
To: <sip:48485858 at 10.3.8.20:5060>
From: "Unknown" <sip:38531300 at dialer2.krs>;tag=209566
Via: SIP/2.0/TCP 10.3.8.20:5060;branch=z9hG4bK34022d4918236c6b79e8bc8e6, SIP/2.0/TCP 10.3.8.19:5062;branch=z9hG4bK536e622d0c249aa3042893620
Call-ID: b0ca7cda89995eb8f605efbb1df30a59 at 10.3.8.19
CSeq: 1 INVITE
Contact: <sip:38531300 at 10.3.8.19:5062;transport=tcp>
Max-Forwards: 69
x-inin-crn: 1001102458;loc=Kristiansand;ms=NECIC4
Supported: join, replaces
User-Agent: ININ-TsServer/3.11.11.12100
Allow: ACK, BYE, CANCEL, INFO, INVITE, NOTIFY, OPTIONS, PRACK, REFER, SUBSCRIBE
Accept: application/sdp
Accept-Encoding: identity
Content-Type: application/sdp
Content-Length: 197
Record-Route: <sip:10.3.8.20:5060;lr;transport=tcp>

v=0
o=ININ 2715879025 2715879026 IN IP4 10.3.8.19
s=Interaction
c=IN IP4 10.3.8.20
t=0 0
m=audio 21568 RTP/AVP 8 101
a=rtpmap:8 PCMA/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15

SIP/2.0 100 Trying
To: <sip:48485858 at 10.3.8.20:5060>
From: "Unknown" <sip:38531300 at dialer2.krs>;tag=209566
Via: SIP/2.0/TCP 10.3.8.20:5060;received=80.239.13.209;rport=1321;branch=z9hG4bK34022d4918236c6b79e8bc8e6, SIP/2.0/TCP 10.3.8.19:5062;branch=z9hG4bK536e622d0c249aa3042893620
Call-ID: b0ca7cda89995eb8f605efbb1df30a59 at 10.3.8.19
CSeq: 1 INVITE
Server: OpenSIPS (1.6.4-2-notls (x86_64/linux))
Content-Length: 0


SIP/2.0 183 Session Progress
To: <sip:48485858 at 10.3.8.20:5060>;tag=B2B.494.491
From: "Unknown" <sip:38531300 at dialer2.krs>;tag=209566
Via: SIP/2.0/TCP 10.3.8.20:5060;received=80.239.13.209;rport=1321;branch=z9hG4bK34022d4918236c6b79e8bc8e6, SIP/2.0/TCP 10.3.8.19:5062;branch=z9hG4bK536e622d0c249aa3042893620
Call-ID: b0ca7cda89995eb8f605efbb1df30a59 at 10.3.8.19
CSeq: 1 INVITE
Record-Route: <sip:10.3.8.20:5060;lr;transport=tcp>
Content-Type: application/sdp
Supported: replaces, timer
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO
Contact: <sip:85.19.212.36:5060;transport=tcp>
Server: OpenSIPS (1.6.4-2-notls (x86_64/linux))
Content-Length: 264

v=0
o=root 2131121205 2131121205 IN IP4 85.19.212.13
s=Asterisk PBX 1.6.1.20
c=IN IP4 85.19.212.13
t=0 0
m=audio 18016 RTP/AVP 8 101
a=rtpmap:8 PCMA/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=silenceSupp:off - - - -
a=ptime:20
a=sendrecv

SIP/2.0 180 Ringing
To: <sip:48485858 at 10.3.8.20:5060>;tag=B2B.494.491
From: "Unknown" <sip:38531300 at dialer2.krs>;tag=209566
Via: SIP/2.0/TCP 10.3.8.20:5060;received=80.239.13.209;rport=1321;branch=z9hG4bK34022d4918236c6b79e8bc8e6, SIP/2.0/TCP 10.3.8.19:5062;branch=z9hG4bK536e622d0c249aa3042893620
Call-ID: b0ca7cda89995eb8f605efbb1df30a59 at 10.3.8.19
CSeq: 1 INVITE
Record-Route: <sip:10.3.8.20:5060;lr;transport=tcp>
Supported: replaces, timer
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO
Contact: <sip:85.19.212.36:5060;transport=tcp>
Server: OpenSIPS (1.6.4-2-notls (x86_64/linux))
Content-Length: 0


SIP/2.0 200 OK
To: <sip:48485858 at 10.3.8.20:5060>;tag=B2B.494.491
From: "Unknown" <sip:38531300 at dialer2.krs>;tag=209566
Via: SIP/2.0/TCP 10.3.8.20:5060;received=80.239.13.209;rport=1321;branch=z9hG4bK34022d4918236c6b79e8bc8e6, SIP/2.0/TCP 10.3.8.19:5062;branch=z9hG4bK536e622d0c249aa3042893620
Call-ID: b0ca7cda89995eb8f605efbb1df30a59 at 10.3.8.19
CSeq: 1 INVITE
Record-Route: <sip:10.3.8.20:5060;lr;transport=tcp>
Content-Type: application/sdp
Supported: replaces, timer
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO
Contact: <sip:85.19.212.36:5060;transport=tcp>
Server: OpenSIPS (1.6.4-2-notls (x86_64/linux))
Content-Length: 264

v=0
o=root 2131121205 2131121206 IN IP4 85.19.212.13
s=Asterisk PBX 1.6.1.20
c=IN IP4 85.19.212.13
t=0 0
m=audio 18016 RTP/AVP 8 101
a=rtpmap:8 PCMA/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=silenceSupp:off - - - -
a=ptime:20
a=sendrecv

ACK sip:85.19.212.36:5060;transport=tcp SIP/2.0
To: <sip:48485858 at 10.3.8.20:5060>;tag=B2B.494.491
From: "Unknown" <sip:38531300 at dialer2.krs>;tag=209566
Call-ID: b0ca7cda89995eb8f605efbb1df30a59 at 10.3.8.19
CSeq: 1 ACK
Via: SIP/2.0/TCP 10.3.8.20:5060;branch=z9hG4bK9a21c71e601ee5f92b7457b36, SIP/2.0/TCP 10.3.8.19:5062;branch=z9hG4bKeb12274eeb5844f08483257d5
Max-Forwards: 69
x-inin-crn: 1001102458;loc=Kristiansand;ms=NECIC4
Supported: join, replaces
User-Agent: ININ-TsServer/3.11.11.12100
Content-Length: 0
Record-Route: <sip:10.3.8.20:5060;lr;transport=tcp>

Trace between opensips and gateway:
INVITE sip:48485858 at 85.19.212.13;transport=tcp SIP/2.0
Via: SIP/2.0/TCP 85.19.212.36;branch=z9hG4bKa186.3ab03a12.0
To: sip:48485858 at 85.19.212.13
From: <sip:38531300 at dialer2.krs>;tag=b30b1ac3712d673c2b813c152c4aced8
CSeq: 2 INVITE
Call-ID: B2B.245.1697878
Content-Length: 197
User-Agent: OpenSIPS (1.6.4-2-notls (x86_64/linux))
Content-Type: application/sdp
Supported: join, replaces
Allow: ACK, BYE, CANCEL, INFO, INVITE, NOTIFY, OPTIONS, PRACK, REFER, SUBSCRIBE
Max-Forwards: 68
Contact: <sip:85.19.212.36:5060;transport=tcp>

v=0
o=ININ 2715879025 2715879026 IN IP4 10.3.8.19
s=Interaction
c=IN IP4 10.3.8.20
t=0 0
m=audio 21568 RTP/AVP 8 101
a=rtpmap:8 PCMA/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15

SIP/2.0 100 Trying
Via: SIP/2.0/TCP 85.19.212.36;branch=z9hG4bKa186.3ab03a12.0;received=85.19.212.36
From: <sip:38531300 at dialer2.krs>;tag=b30b1ac3712d673c2b813c152c4aced8
To: sip:48485858 at 85.19.212.13
Call-ID: B2B.245.1697878
CSeq: 2 INVITE
Server: Asterisk PBX 1.6.1.20
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO
Supported: replaces, timer
Contact: <sip:48485858 at 85.19.212.13;transport=TCP>
Content-Length: 0


SIP/2.0 100 Trying
Via: SIP/2.0/TCP 85.19.212.36;branch=z9hG4bKa186.3ab03a12.0;received=85.19.212.36
From: <sip:38531300 at dialer2.krs>;tag=b30b1ac3712d673c2b813c152c4aced8
To: sip:48485858 at 85.19.212.13
Call-ID: B2B.245.1697878
CSeq: 2 INVITE
Server: Asterisk PBX 1.6.1.20
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO
Supported: replaces, timer
Contact: <sip:48485858 at 85.19.212.13;transport=TCP>
Content-Length: 0


SIP/2.0 183 Session Progress
Via: SIP/2.0/TCP 85.19.212.36;branch=z9hG4bKa186.3ab03a12.0;received=85.19.212.36
From: <sip:38531300 at dialer2.krs>;tag=b30b1ac3712d673c2b813c152c4aced8
To: sip:48485858 at 85.19.212.13;tag=as70550b35
Call-ID: B2B.245.1697878
CSeq: 2 INVITE
Server: Asterisk PBX 1.6.1.20
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO
Supported: replaces, timer
Contact: <sip:48485858 at 85.19.212.13;transport=TCP>
Content-Type: application/sdp
Content-Length: 264

v=0
o=root 2131121205 2131121205 IN IP4 85.19.212.13
s=Asterisk PBX 1.6.1.20
c=IN IP4 85.19.212.13
t=0 0
m=audio 18016 RTP/AVP 8 101
a=rtpmap:8 PCMA/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=silenceSupp:off - - - -
a=ptime:20
a=sendrecv

SIP/2.0 180 Ringing
Via: SIP/2.0/TCP 85.19.212.36;branch=z9hG4bKa186.3ab03a12.0;received=85.19.212.36
From: <sip:38531300 at dialer2.krs>;tag=b30b1ac3712d673c2b813c152c4aced8
To: sip:48485858 at 85.19.212.13;tag=as70550b35
Call-ID: B2B.245.1697878
CSeq: 2 INVITE
Server: Asterisk PBX 1.6.1.20
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO
Supported: replaces, timer
Contact: <sip:48485858 at 85.19.212.13;transport=TCP>
Content-Length: 0


SIP/2.0 200 OK
Via: SIP/2.0/TCP 85.19.212.36;branch=z9hG4bKa186.3ab03a12.0;received=85.19.212.36
From: <sip:38531300 at dialer2.krs>;tag=b30b1ac3712d673c2b813c152c4aced8
To: sip:48485858 at 85.19.212.13;tag=as70550b35
Call-ID: B2B.245.1697878
CSeq: 2 INVITE
Server: Asterisk PBX 1.6.1.20
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO
Supported: replaces, timer
Contact: <sip:48485858 at 85.19.212.13;transport=TCP>
Content-Type: application/sdp
Content-Length: 264

v=0
o=root 2131121205 2131121206 IN IP4 85.19.212.13
s=Asterisk PBX 1.6.1.20
c=IN IP4 85.19.212.13
t=0 0
m=audio 18016 RTP/AVP 8 101
a=rtpmap:8 PCMA/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=silenceSupp:off - - - -
a=ptime:20
a=sendrecv

ACK sip:48485858 at 85.19.212.13;transport=TCP SIP/2.0
Via: SIP/2.0/TCP 85.19.212.36;branch=z9hG4bKa186.4ab03a12.0
To: <sip:48485858 at 85.19.212.13>;tag=as70550b35
From: <sip:38531300 at dialer2.krs>;tag=b30b1ac3712d673c2b813c152c4aced8
CSeq: 2 ACK
Call-ID: B2B.245.1697878
Content-Length: 0
User-Agent: OpenSIPS (1.6.4-2-notls (x86_64/linux))
Supported: join, replaces
Max-Forwards: 69
Contact: <sip:85.19.212.36:5060;transport=tcp>


BYE sip:85.19.212.36:5060;transport=tcp SIP/2.0
Via: SIP/2.0/TCP 85.19.212.13:5060;branch=z9hG4bK7fd3a255;rport
Max-Forwards: 70
From: sip:48485858 at 85.19.212.13;tag=as70550b35
To: <sip:38531300 at dialer2.krs>;tag=b30b1ac3712d673c2b813c152c4aced8
Call-ID: B2B.245.1697878
CSeq: 102 BYE
User-Agent: Asterisk PBX 1.6.1.20
X-Asterisk-HangupCause: Normal Clearing
X-Asterisk-HangupCauseCode: 16
Content-Length: 0


SIP/2.0 408 Timeout
Via: SIP/2.0/TCP 85.19.212.13:5060;branch=z9hG4bK7fd3a255;rport=5060
From: sip:48485858 at 85.19.212.13;tag=as70550b35
To: <sip:38531300 at dialer2.krs>;tag=b30b1ac3712d673c2b813c152c4aced8
Call-ID: B2B.245.1697878
CSeq: 102 BYE
Contact: <sip:85.19.212.36:5060;transport=tcp>
Server: OpenSIPS (1.6.4-2-notls (x86_64/linux))
Content-Length: 0

Error on opensips-server when BYE arrives:
Oct  3 14:31:57 sip3 /usr/sbin/opensips[13442]: ERROR:core:tcp_blocking_connect: timeout 10 s elapsed from 10 s
Oct  3 14:31:57 sip3 /usr/sbin/opensips[13442]: ERROR:core:tcpconn_connect: tcp_blocking_connect failed
Oct  3 14:31:57 sip3 /usr/sbin/opensips[13442]: ERROR:core:tcp_send: connect failed
Oct  3 14:31:57 sip3 /usr/sbin/opensips[13442]: ERROR:tm:msg_send: tcp_send failed
Oct  3 14:31:57 sip3 /usr/sbin/opensips[13442]: ERROR:tm:t_uac: attempt to send to 'sip:10.3.8.20:5060;lr;transport=tcp' failed

It seems like opensips/b2bua-module is trying to forward the message to the destination in the record-route header, which normaly is ok when end-user is not behind nat. 

Best regards,
Morten Tryfoss


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

Comment By: Anca Vamanu (anca_vamanu)
Date: 2012-11-01 02:46

Message:
Hi Morten,

You would have the same problem even if you were not using B2BUA.

It seems like you have an equipment between the end user and OpenSIPS that
adds that Record-Route header with a private IP, and also a Via header.

Via: SIP/2.0/TCP 10.3.8.20:5060;branch=z9hG4bK34022d4918236c6b79e8bc8e6, 
Record-Route: <sip:10.3.8.20:5060;lr;transport=tcp>

So your problem seems like a setup problem on that equipment.

Regards,
Anca



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

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


From bogdan at opensips.org  Thu Nov  1 11:29:35 2012
From: bogdan at opensips.org (Bogdan-Andrei Iancu)
Date: Thu, 01 Nov 2012 10:29:35 +0000
Subject: [OpenSIPS-Devel] SF.net SVN: opensips:[9410]
	trunk/modules/path/path.c
Message-ID: <E1TTs1n-0001aK-Ev@sfp-svn-1.v30.ch3.sourceforge.com>

Revision: 9410
          http://opensips.svn.sourceforge.net/opensips/?rev=9410&view=rev
Author:   bogdan_iancu
Date:     2012-11-01 10:29:34 +0000 (Thu, 01 Nov 2012)
Log Message:
-----------
- one more memory leak (in private mem) fixed
  Credits go to Nick Altmann

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

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



From bogdan at opensips.org  Thu Nov  1 11:31:11 2012
From: bogdan at opensips.org (Bogdan-Andrei Iancu)
Date: Thu, 01 Nov 2012 10:31:11 +0000
Subject: [OpenSIPS-Devel] SF.net SVN: opensips:[9411]
	branches/1.8/modules/path/path.c
Message-ID: <E1TTs3L-0001gs-K4@sfp-svn-1.v30.ch3.sourceforge.com>

Revision: 9411
          http://opensips.svn.sourceforge.net/opensips/?rev=9411&view=rev
Author:   bogdan_iancu
Date:     2012-11-01 10:31:11 +0000 (Thu, 01 Nov 2012)
Log Message:
-----------
backport from trunk (rev #9410):
- one more memory leak (in private mem) fixed
  Credits go to Nick Altmann

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

Modified Paths:
--------------
    branches/1.8/modules/path/path.c

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



From bogdan at opensips.org  Thu Nov  1 11:31:21 2012
From: bogdan at opensips.org (Bogdan-Andrei Iancu)
Date: Thu, 01 Nov 2012 10:31:21 +0000
Subject: [OpenSIPS-Devel] SF.net SVN: opensips:[9412]
	branches/1.7/modules/path/path.c
Message-ID: <E1TTs3V-0001hD-Bw@sfp-svn-1.v30.ch3.sourceforge.com>

Revision: 9412
          http://opensips.svn.sourceforge.net/opensips/?rev=9412&view=rev
Author:   bogdan_iancu
Date:     2012-11-01 10:31:20 +0000 (Thu, 01 Nov 2012)
Log Message:
-----------
backport from trunk (rev #9410):
- one more memory leak (in private mem) fixed
  Credits go to Nick Altmann

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

Modified Paths:
--------------
    branches/1.7/modules/path/path.c

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



From bogdan at opensips.org  Thu Nov  1 12:02:19 2012
From: bogdan at opensips.org (Bogdan-Andrei Iancu)
Date: Thu, 01 Nov 2012 13:02:19 +0200
Subject: [OpenSIPS-Devel] [OpenSIPS-Users] [RELEASES] Planing OpenSIPS
 1.9.0 major release
In-Reply-To: <AC1BB636-DC7E-4A06-913F-B446AE847A27@ag-projects.com>
References: <508AAA59.7070107@opensips.org>	<20049EB2-1E5C-438B-9F8A-CCF7566A2F46@ag-projects.com>	<508E564B.4060106@opensips.org>
	<AC1BB636-DC7E-4A06-913F-B446AE847A27@ag-projects.com>
Message-ID: <509256BB.9090403@opensips.org>

Hi Dan,

Well, as Ovidiu said, it is prone. BUT, this is not something particular 
to re-INVITE, but to whatever in-dialog pinging you may have from a 
mid-proxy.

On the other hand, as Ryan pointed out here, the need to check the 
dialog health from proxy side, without relying on special end-UA 
features (like SST), is really critical.

So, I see two approaches:
     1) either simply live with the fact that races may occure and calls 
may be dropped during a re-INVITE, but at least is a clear drop /cut
     2) theoretically we can try to address the race at dialog modules 
level : (a) If you have ongoing in-dialog transaction, do not do your 
ping , (b) if you have an ongoing in-dialog ping and receive another 
in-dilog request from end point, try to delay it until your pinging is 
done.....just some ideas....


Regards,

Bogdan-Andrei Iancu
OpenSIPS Founder and Developer
http://www.opensips-solutions.com


On 10/31/2012 09:03 PM, Dan Pascu wrote:
> On 29 Oct 2012, at 12:11, Bogdan-Andrei Iancu wrote:
>
>> Hi Saul,
>>
>> We were thinking at re-INVITE pinging from OpenSIPs level towards the caller and callee. There will be 2 modes (at least this is the current plan).
>>     1) remember all the time the last SDPs from each side and re-use them when pining the other sides (just to trick the SDP negotiation)
>>     2) start with a lateSDP negotiation on one side and do normal SDP on the other side (to avoid SDP storing), but this means at least one of the parties should support late SDP negotiations
>>     3) open to other suggestions....
> I think this invites trouble as it is prone to race conditions. If any of the clients send a re-INVIVITE of their own while OpenSIPs does it's pinging, it will fail as there is already an active unanswered re-INVITE in progress. The client will be confused as it didn't send another re-INVITE itself and the negative reply to its own re-INVITE will probably just prompt the client to terminate the session thinking there is some issue with it.
>
> I cannot see this working without a full B2BUA, where OpenSIPs would queue the client requests if there is a ping in progress and only forward them after it has finished the ping transaction.
>
>> About the GRUU stuff, could you detail a bit :D ?
>>
>> Regards,
>>
>> Bogdan-Andrei Iancu
>> OpenSIPS Founder and Developer
>> http://www.opensips-solutions.com
>>
>>
>> On 10/26/2012 06:51 PM, Sa?l Ibarra Corretg? wrote:
>>> Hi,
>>>
>>> On Oct 26, 2012, at 5:20 PM, Bogdan-Andrei Iancu wrote:
>>>
>>>> Hi all,
>>>>
>>>> I would like to start a discussion about the next OpenSIPS major release - and in this discussion anyone is welcomed with options, ideas, critics and other. Your feedback is important to drive the project into a direction that reflects the user's needs!.
>>>>
>>>> So, I will here the starting points, for both release planing and release content.
>>>>
>>>>
>>>> Content
>>>> -------
>>>> What was done:
>>>>         http://www.opensips.org/Main/Ver190#toc2
>>>> What is planned:
>>>>         http://www.opensips.org/Main/Ver190#toc9
>>>> Planned items have priorities (for being addressed); it is a must to have all items done for the next release, as we need to fit into a time frame. Whatever is not done, will be left for the next release (1.10)
>>>>
>>>>
>>>> Planing
>>>> -------
>>>> Release candidate:
>>>>     second half of January 2012, depending on the progress with the items to be done.
>>>> Testing phase:
>>>>     1 month allocated (it may be extended if critical problems show up)
>>>> Stable release:
>>>>     second half of February (after the testing phase is done).
>>>>
>>>>
>>>> Once again, your feedback on these matters is important to us.
>>>>
>>> I'll edit the wiki with the items we've been working on for presence.
>>>
>>> Can you give a bit more detail on the dialog ping with re-INVITEs? re-INVITEs are particularly troublesome, because there can only be one of them at a time.
>>>
>>> Also, can we add the in-dialog requests when using GRUU bug to the wishlist? :-)
>>>
>>> Keep up the good work guys!
>>>
>>>
>>> Regards,
>>>
>>> --
>>> Sa?l Ibarra Corretg?
>>> AG Projects
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> Devel mailing list
>>> Devel at lists.opensips.org
>>> http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
>>>
>> _______________________________________________
>> Users mailing list
>> Users at lists.opensips.org
>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>
>
> --
> Dan
>
>
>
>
>
> _______________________________________________
> Users mailing list
> Users at lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>


From noreply at sourceforge.net  Thu Nov  1 12:55:37 2012
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 01 Nov 2012 04:55:37 -0700
Subject: [OpenSIPS-Devel] [ opensips-Patches-3580526 ] NATHELPER and OPTIONS
	ping for tcp proto
Message-ID: <mailman.1151.1351770942.13469.devel@lists.opensips.org>

Patches item #3580526, was opened at 2012-10-26 05:52
Message generated for change (Settings changed) made by vladut-paiu
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086412&aid=3580526&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.8.x
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Nick Altmann (nikbyte)
Assigned to: Nobody/Anonymous (nobody)
Summary: NATHELPER and OPTIONS ping for tcp proto

Initial Comment:
nathelper don't want to ping abonents with TCP transport.

Here is a small patch:


Index: modules/nathelper/nathelper.c
===================================================================
--- modules/nathelper/nathelper.c       (revision 9391)
+++ modules/nathelper/nathelper.c       (working copy)
@@ -1228,8 +1228,6 @@
                                continue;
                        }
                }
-               if (curi.proto != PROTO_UDP && curi.proto != PROTO_NONE)
-                       continue;
                if (curi.port_no == 0)
                        curi.port_no = SIP_PORT;
                proto = curi.proto;


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

Comment By: Nick Altmann (nikbyte)
Date: 2012-10-29 23:29

Message:
Uploaded patch to add sipping_tcp option.

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

Comment By: Nick Altmann (nikbyte)
Date: 2012-10-29 01:00

Message:
I think you disable OPTIONS because we can use tcp keepalives. But
sometimes we need exactly OPTIONS pings via tcp protocol. I suggest to add
a module option to enable/disable OPTIONS pings via tcp.

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

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


From noreply at sourceforge.net  Thu Nov  1 13:34:30 2012
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 01 Nov 2012 05:34:30 -0700
Subject: [OpenSIPS-Devel] [ opensips-Patches-3580526 ] NATHELPER and OPTIONS
	ping for tcp proto
Message-ID: <mailman.1152.1351773274.13469.devel@lists.opensips.org>

Patches item #3580526, was opened at 2012-10-26 05:52
Message generated for change (Comment added) made by vladut-paiu
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086412&aid=3580526&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.8.x
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Nick Altmann (nikbyte)
Assigned to: Nobody/Anonymous (nobody)
Summary: NATHELPER and OPTIONS ping for tcp proto

Initial Comment:
nathelper don't want to ping abonents with TCP transport.

Here is a small patch:


Index: modules/nathelper/nathelper.c
===================================================================
--- modules/nathelper/nathelper.c       (revision 9391)
+++ modules/nathelper/nathelper.c       (working copy)
@@ -1228,8 +1228,6 @@
                                continue;
                        }
                }
-               if (curi.proto != PROTO_UDP && curi.proto != PROTO_NONE)
-                       continue;
                if (curi.port_no == 0)
                        curi.port_no = SIP_PORT;
                proto = curi.proto;


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

>Comment By: Vladut-Stefan Paiu (vladut-paiu)
Date: 2012-11-01 05:34

Message:
Hello,

Seems a little dangerous to start ping-ing TCP clients with Options. First
thing that would need to be added is the tcp_no_new_conn_bflag , in order
not to open a new connection if the old one is down.

But still, couldn't we just use the tcp_keepalive param ( see [1] ) ?

Can you give some examples of cases where you need explicit SIP Option
pings over TCP ?

[1] http://www.opensips.org/Resources/DocsCoreFcn18#toc84

Regards,
Vlad

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

Comment By: Nick Altmann (nikbyte)
Date: 2012-10-29 23:29

Message:
Uploaded patch to add sipping_tcp option.

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

Comment By: Nick Altmann (nikbyte)
Date: 2012-10-29 01:00

Message:
I think you disable OPTIONS because we can use tcp keepalives. But
sometimes we need exactly OPTIONS pings via tcp protocol. I suggest to add
a module option to enable/disable OPTIONS pings via tcp.

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

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


From noreply at sourceforge.net  Thu Nov  1 14:36:50 2012
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 01 Nov 2012 06:36:50 -0700
Subject: [OpenSIPS-Devel] [ opensips-Bugs-3579200 ] OpenSIP B2BUA core dump
Message-ID: <mailman.1153.1351777016.13469.devel@lists.opensips.org>

Bugs item #3579200, was opened at 2012-10-22 12:01
Message generated for change (Comment added) made by bogdan_iancu
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=3579200&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.8.x
Status: Open
Resolution: Accepted
>Priority: 4
Private: No
Submitted By: apsaras (apsaras)
Assigned to: Bogdan-Andrei Iancu (bogdan_iancu)
Summary: OpenSIP B2BUA core dump

Initial Comment:
We have the following setup.

OpenSIPs 1.8.1 does permission checking, drouding, nat and sends requests to an other OpenSIPs on the same box running on port 5080 as B2BUA. For small numer of calls per sec works fine. if we load the system with SIPp with 10 calls per sec, B2BUA is crashing.

System is CentOS 5.8 64bit with the latest updates but have same issues with debian 6.

that is the gdb bt

(gdb) bt
#0  0x00000033d2630285 in raise () from /lib64/libc.so.6
#1  0x00000033d2631d30 in abort () from /lib64/libc.so.6
#2  0x00000000004218c7 in del_lump (msg=0x7fff8ee7c050, offset=273, len=50, type=HDR_OTHER_T) at data_lump.c:336
#3  0x00002af2377a07a7 in subst_f (msg=0x7fff8ee7c050, subst=<value optimized out>, ignored=<value optimized out>) at textops.c:489
#4  0x00000000004118c1 in do_action (a=0x2af2375a69d8, msg=0x7fff8ee7c050) at action.c:1483
#5  0x0000000000416905 in run_action_list (a=<value optimized out>, msg=0x7fff8ee7c050) at action.c:143
#6  0x00000000004731a0 in eval_elem (e=0x2af2375a6ab0, msg=0x7fff8ee7c050, val=0x0) at route.c:1438
#7  0x000000000047594a in eval_expr (e=0x7fd7, msg=0x7fff8ee7c050, val=0x0) at route.c:1783
#8  0x000000000047583b in eval_expr (e=0x2af2375a6b00, msg=0x7fff8ee7c050, val=0x0) at route.c:1804
#9  0x0000000000411bfd in do_action (a=0x2af2375a6cc0, msg=0x7fff8ee7c050) at action.c:899
#10 0x0000000000416905 in run_action_list (a=<value optimized out>, msg=0x7fff8ee7c050) at action.c:143
#11 0x0000000000416c69 in run_actions (a=0x2af2375a67d0, msg=0x7fff8ee7c050) at action.c:123
#12 run_top_route (a=0x2af2375a67d0, msg=0x7fff8ee7c050) at action.c:189
#13 0x00002af23864a376 in b2b_tm_cback (t=0x2af239182988, htable=0x2af23913cca0, ps=<value optimized out>) at dlg.c:2624
#14 0x00002af2381f0ce1 in run_trans_callbacks (type=256, trans=0x2af239182988, req=0x0, rpl=0xffffffffffffffff, code=408) at t_hooks.c:212
#15 0x00002af23820ade9 in local_reply (t=0x2af239182988, p_msg=0xffffffffffffffff, branch=<value optimized out>, msg_status=<value optimized out>,
    cancel_bitmap=0x2af238eb9f90) at t_reply.c:1385
#16 0x00002af2381f41f7 in final_response_handler (ticks=<value optimized out>, attr=<value optimized out>) at timer.c:253
#17 timer_routine (ticks=<value optimized out>, attr=<value optimized out>) at timer.c:1011
#18 0x000000000049c44b in run_timer_process () at timer.c:360
#19 start_timer_processes () at timer.c:527
#20 0x000000000043006c in main_loop (argc=<value optimized out>, argv=0x7fff8ee7d368) at main.c:945
#21 main (argc=<value optimized out>, argv=0x7fff8ee7d368) at main.c:1541


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

>Comment By: Bogdan-Andrei Iancu (bogdan_iancu)
Date: 2012-11-01 06:36

Message:
Hi,

Bug located, working on the fix, I will upload a patch in the next days !

Regards,
Bogdan

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

Comment By: apsaras (apsaras)
Date: 2012-10-29 08:27

Message:
Hi

The problem detected by Bogdan which was a 408 message sent from B2BUA. I
had a header manipulation on reply b2bua route so avoiding manipulation for
408 messages resolved the issue.

Thank you bogdan for your help.

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

Comment By: apsaras (apsaras)
Date: 2012-10-26 07:19

Message:
No problem with 1. Can you please send me an IP to allow it on our
firewall? Can we connect on Skype for any further communication?

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

Comment By: Bogdan-Andrei Iancu (bogdan_iancu)
Date: 2012-10-26 07:17

Message:
The core file without the binaries and OS specific lib is more or less
useless.

We have 2 options here :

1) me getting access to the machine the core was generated

2) I will instruct you do to remote core investigation, step by step.

Of course 2) is much much slower than 1) .

Regards,
Bogdan

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

Comment By: apsaras (apsaras)
Date: 2012-10-26 05:56

Message:
Yes I have the file (http://www.microbase.gr/downloads/core.1263.bz2)

Do you need the conf files for proxy and b2bua ?

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

Comment By: Bogdan-Andrei Iancu (bogdan_iancu)
Date: 2012-10-26 04:27

Message:
Hi Anthony,

Do you still have the core file for investigation ?

It is not load related, but rather scenario related - it looks like you
have local 408  (from timer) which goes into b2b, which calls a reply route
where you do some changes which are not valid....

Investigating the corefile will give more info on how to prevent this.

Regards,
Bogdan

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

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


From vladpaiu at opensips.org  Thu Nov  1 16:36:14 2012
From: vladpaiu at opensips.org (Vlad Paiu)
Date: Thu, 01 Nov 2012 15:36:14 +0000
Subject: [OpenSIPS-Devel] SF.net SVN: opensips:[9413] trunk/modules/dialog
Message-ID: <E1TTwoY-0003Hm-Hj@sfp-svn-2.v30.ch3.sourceforge.com>

Revision: 9413
          http://opensips.svn.sourceforge.net/opensips/?rev=9413&view=rev
Author:   vladut-paiu
Date:     2012-11-01 15:36:13 +0000 (Thu, 01 Nov 2012)
Log Message:
-----------
match_dialog() is now able to do DID matching in the case of topology hiding

Modified Paths:
--------------
    trunk/modules/dialog/dialog.c
    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 vladpaiu at opensips.org  Thu Nov  1 16:40:19 2012
From: vladpaiu at opensips.org (Vlad Paiu)
Date: Thu, 01 Nov 2012 15:40:19 +0000
Subject: [OpenSIPS-Devel] SF.net SVN: opensips:[9414]
	branches/1.8/modules/dialog
Message-ID: <E1TTwsV-0003V1-OV@sfp-svn-2.v30.ch3.sourceforge.com>

Revision: 9414
          http://opensips.svn.sourceforge.net/opensips/?rev=9414&view=rev
Author:   vladut-paiu
Date:     2012-11-01 15:40:19 +0000 (Thu, 01 Nov 2012)
Log Message:
-----------
backport from trunk (rev #9413)

match_dialog() is now able to do DID matching in the case of topology hiding

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

Modified Paths:
--------------
    branches/1.8/modules/dialog/dialog.c
    branches/1.8/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 opensips.org  Thu Nov  1 16:51:46 2012
From: bogdan at opensips.org (Bogdan-Andrei Iancu)
Date: Thu, 01 Nov 2012 15:51:46 +0000
Subject: [OpenSIPS-Devel] SF.net SVN: opensips:[9415]
	branches/1.8/modules/dispatcher/dispatch.c
Message-ID: <E1TTx3a-00048z-Hx@sfp-svn-2.v30.ch3.sourceforge.com>

Revision: 9415
          http://opensips.svn.sourceforge.net/opensips/?rev=9415&view=rev
Author:   bogdan_iancu
Date:     2012-11-01 15:51:46 +0000 (Thu, 01 Nov 2012)
Log Message:
-----------
-fixed how the IPs (behind the destinations) are learned - use SIP wise dns lookup instead of simple A record lookup.
 Reported by Ryan Revels

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

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



From razvan at opensips.org  Thu Nov  1 17:12:31 2012
From: razvan at opensips.org (Razvan Crainea)
Date: Thu, 01 Nov 2012 16:12:31 +0000
Subject: [OpenSIPS-Devel] SF.net SVN: opensips:[9416] branches/1.8
Message-ID: <E1TTxNf-0005GF-CT@sfp-svn-2.v30.ch3.sourceforge.com>

Revision: 9416
          http://opensips.svn.sourceforge.net/opensips/?rev=9416&view=rev
Author:   razvancrainea
Date:     2012-11-01 16:12:30 +0000 (Thu, 01 Nov 2012)
Log Message:
-----------
Updated version, changelog and credits for 1.8.2

Modified Paths:
--------------
    branches/1.8/CREDITS
    branches/1.8/ChangeLog
    branches/1.8/packaging/debian/changelog
    branches/1.8/packaging/debian-lenny/changelog
    branches/1.8/packaging/fedora/opensips.spec
    branches/1.8/packaging/freebsd/Makefile
    branches/1.8/packaging/netbsd/Makefile
    branches/1.8/packaging/openbsd/Makefile
    branches/1.8/packaging/rpm/opensips.spec.CentOS
    branches/1.8/packaging/rpm/opensips.spec.SuSE
    branches/1.8/packaging/solaris/base-pkginfo
    branches/1.8/packaging/solaris/berkeley-pkginfo
    branches/1.8/packaging/solaris/carrierroute-pkginfo
    branches/1.8/packaging/solaris/identity-pkginfo
    branches/1.8/packaging/solaris/ldap-pkginfo
    branches/1.8/packaging/solaris/mmgeoip-pkginfo
    branches/1.8/packaging/solaris/mysql-pkginfo
    branches/1.8/packaging/solaris/perl-pkginfo
    branches/1.8/packaging/solaris/pgsql-pkginfo
    branches/1.8/packaging/solaris/regex-pkginfo
    branches/1.8/packaging/solaris/snmp-pkginfo
    branches/1.8/packaging/solaris/tls-pkginfo
    branches/1.8/packaging/solaris/xmlrpc-pkginfo

Added Paths:
-----------
    branches/1.8/packaging/gentoo/opensips-1.8.2.ebuild

Removed Paths:
-------------
    branches/1.8/packaging/gentoo/opensips-1.8.0.ebuild

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



From razvan at opensips.org  Thu Nov  1 17:17:52 2012
From: razvan at opensips.org (Razvan Crainea)
Date: Thu, 01 Nov 2012 16:17:52 +0000
Subject: [OpenSIPS-Devel] SF.net SVN: opensips:[9417]
	branches/1.8/Makefile.defs
Message-ID: <E1TTxSq-0005a8-1A@sfp-svn-2.v30.ch3.sourceforge.com>

Revision: 9417
          http://opensips.svn.sourceforge.net/opensips/?rev=9417&view=rev
Author:   razvancrainea
Date:     2012-11-01 16:17:51 +0000 (Thu, 01 Nov 2012)
Log Message:
-----------
Updated minor version to 2 in Makefile.defs

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

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



From razvan at opensips.org  Thu Nov  1 18:35:16 2012
From: razvan at opensips.org (Razvan Crainea)
Date: Thu, 01 Nov 2012 17:35:16 +0000
Subject: [OpenSIPS-Devel] SF.net SVN: opensips:[9418] branches/1.8
Message-ID: <E1TTyfk-0004P6-Tj@sfp-svn-1.v30.ch3.sourceforge.com>

Revision: 9418
          http://opensips.svn.sourceforge.net/opensips/?rev=9418&view=rev
Author:   razvancrainea
Date:     2012-11-01 17:35:16 +0000 (Thu, 01 Nov 2012)
Log Message:
-----------
Revised ChangeLog and Credits

Modified Paths:
--------------
    branches/1.8/CREDITS
    branches/1.8/ChangeLog

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



From razvan at opensips.org  Thu Nov  1 19:10:11 2012
From: razvan at opensips.org (Razvan Crainea)
Date: Thu, 01 Nov 2012 18:10:11 +0000
Subject: [OpenSIPS-Devel] SF.net SVN: opensips:[9419] tags/1.8.2/
Message-ID: <E1TTzDX-0007PP-2r@sfp-svn-1.v30.ch3.sourceforge.com>

Revision: 9419
          http://opensips.svn.sourceforge.net/opensips/?rev=9419&view=rev
Author:   razvancrainea
Date:     2012-11-01 18:10:10 +0000 (Thu, 01 Nov 2012)
Log Message:
-----------
Created 1.8.2 tag

Added Paths:
-----------
    tags/1.8.2/

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



From bogdan at opensips.org  Thu Nov  1 19:41:43 2012
From: bogdan at opensips.org (Bogdan-Andrei Iancu)
Date: Thu, 01 Nov 2012 20:41:43 +0200
Subject: [OpenSIPS-Devel] [RELEASE] OpenSIPS 1.8.2 Minor Stable Release
Message-ID: <5092C267.8040303@opensips.org>

Hi all,

OpenSIPS 1.8.2 is the second minor release of the 1.8 branch, bringing 
even a more stable version of 1.8 branch with more fixes - crashes, 
malfunctions and compliance (but no functionality, scripting or 
interfacing were changed).

OpenSIPS 1.8.2 brings important fixes in:

    * TLS / TCP engine
    * Dialog module
    * Presence and RLS support
    * Dispatcher module
    * SIP parser
    * scripting (startup and timer routes)
    * Dynamic Routing module
    * Statistics reporting (for PKG and SHM memory)
    * B2B module - requests handing, script routes triggering.

It is highly recommended to upgrade - *OpenSIPS 1.8.2* is now available 
for download on project web site and SF download system.

Many thanks to all people contributing to this release:
     
http://opensips.svn.sourceforge.net/viewvc/opensips/branches/1.8/CREDITS?revision=9418&view=markup

The full Changelog is available here :
     http://opensips.org/pub/opensips/1.8.2/src/ChangeLog

To get the *OpenSIPS 1.8.2* version, see:
     http://www.opensips.org/Resources/Downloads

Enjoy,
Bogdan

-- 
Bogdan-Andrei Iancu
OpenSIPS Founder and Developer
http://www.opensips-solutions.com

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/devel/attachments/20121101/8c78dfaa/attachment.htm>

From noreply at sourceforge.net  Thu Nov  1 19:59:03 2012
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 01 Nov 2012 11:59:03 -0700
Subject: [OpenSIPS-Devel] [ opensips-Bugs-3582533 ] sipcapture segfault
Message-ID: <mailman.1154.1351796347.13469.devel@lists.opensips.org>

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

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: 1.8.x
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: https://www.google.com/accounts ()
Assigned to: Nobody/Anonymous (nobody)
Summary: sipcapture segfault

Initial Comment:
The server is doing only sip_capture where packets are getting to it from captagent.
I've used opensips 1.8.0 and 1.8.1 on multiple servers all with the same result.
Also used older captagent and current captagent.
Attached back trace, opensips config, startup cmd, system info, and debug logs tail. All IPs replaced with private IPs. All original IPs were public IPs.




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

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


From bogdan at opensips.org  Fri Nov  2 07:24:22 2012
From: bogdan at opensips.org (Bogdan-Andrei Iancu)
Date: Fri, 02 Nov 2012 08:24:22 +0200
Subject: [OpenSIPS-Devel] [OpenSIPS-Users] [RELEASES] Planing
	OpenSIPS	1.9.0 major release
Message-ID: <ktjac9x4xndlsvsnil722ad6.1351837462673@email.android.com>

Hi Binan,

Yes the patch is there, we need to review it. Also Inaki sugested some tunings in the PATH module (to fully support websocket).

Thanks and regards,
Bogdan


Sent from Samsung MobileBinan AL Halabi <binanalhalabi at yahoo.com> wrote:
Hi All,

If oversip uses Path extension OpenSIPS must support it.

1- Sending Path header values in 200 ok REGISTER response 
2- Path header files syntax must confom to Route syntax
3- When look up the opensips must copies the stored path header fileds into Route header fileds - preloaded route. 
Reference: RFC 3327 ? 


Here i think adding one Route header pointing to OverSIP (second Path URI) is enough in simple case (UA ---- OverSIP--- OpenSIPS).
OverSIP removes the Route header and route the request based on RURI (first Path URI).? 
?


OpenSIPs support this http://www.opensips.org/html/docs/modules/devel/registrar.html#id248705? 
flag "px" (path support) of save function in Registrar module.

So still parsing VIA header is required to add WS and WSS. I think this patch is already posted.


Binan.

Fr?n: I?aki Baz Castillo <ibc at aliax.net>
Till: Bogdan-Andrei Iancu <bogdan at opensips.org> 
Kopia: OpenSIPS users mailling list <users at lists.opensips.org> 
Skickat: torsdag, 1 november 2012 20:36
?mne: Re: [OpenSIPS-Users] [OpenSIPS-Devel] [RELEASES] Planing OpenSIPS 1.9.0 major release

2012/11/1 Bogdan-Andrei Iancu <bogdan at opensips.org>
>
> Hi Inaki,
>
> Please correct me if I'm wrong, but reading the draft and listing you guys all, I would say the right approach is to : (1) use OverSIP as gw (to extract SIP traffic from WebSocket) and (2) make OpenSIPS to support SIP traffic resulted from websocket extraction.
>
> If so, OpenSIPS has nothing to do with the WebSocket protocol itself, but only to support the extensions from the draft (like new protocols and eventually the SIP server location).

Right. As Saul pointed out, this scenario (which is a pure RFC 5626
"Outbound" scenario with a Edge Proxy in front of the
registrar/authentication-proxy) requires:

- Path support in OpenSIPS for storing the Path URI(s). Note: It's
important to increase the "path" column size in the location table.
The current value is to small and cannot store two URI's (OverSIP adds
double Path headers).

- OpenSIPS should improve the parser of the Via transport field since
currently it only accepts UDP, TCP, TLS and SCTP. It should also
accept WS and WSS, but better if it accepts any token (as the RFC 3261
BNF grammar states). Otherwise OpenSIPS will discard SIP requests
coming from OverSIP (since the non top Via header, that created by the
SIP WebSocket client, has "WS" as transport protocol).

And nothing else at all, but the above two points are important.

Regards.





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

_______________________________________________
Users mailing list
Users at lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/devel/attachments/20121102/243f420a/attachment-0001.htm>

From vladpaiu at opensips.org  Fri Nov  2 08:59:39 2012
From: vladpaiu at opensips.org (Vlad Paiu)
Date: Fri, 02 Nov 2012 07:59:39 +0000
Subject: [OpenSIPS-Devel] SF.net SVN: opensips:[9420]
	trunk/modules/dialog/dlg_handlers.c
Message-ID: <E1TUCAF-0005du-3v@sfp-svn-1.v30.ch3.sourceforge.com>

Revision: 9420
          http://opensips.svn.sourceforge.net/opensips/?rev=9420&view=rev
Author:   vladut-paiu
Date:     2012-11-02 07:59:38 +0000 (Fri, 02 Nov 2012)
Log Message:
-----------
fixed bug introduced in earlier dialog fix :|

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 vladpaiu at opensips.org  Fri Nov  2 09:02:36 2012
From: vladpaiu at opensips.org (Vlad Paiu)
Date: Fri, 02 Nov 2012 08:02:36 +0000
Subject: [OpenSIPS-Devel] SF.net SVN: opensips:[9421]
	branches/1.8/modules/dialog/dlg_handlers.c
Message-ID: <E1TUCD6-0005vU-EC@sfp-svn-1.v30.ch3.sourceforge.com>

Revision: 9421
          http://opensips.svn.sourceforge.net/opensips/?rev=9421&view=rev
Author:   vladut-paiu
Date:     2012-11-02 08:02:36 +0000 (Fri, 02 Nov 2012)
Log Message:
-----------
backport from trunk (rev #9420)

fixed bug introduced in earlier dialog fix :|

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

Modified Paths:
--------------
    branches/1.8/modules/dialog/dlg_handlers.c

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



From ibc at aliax.net  Fri Nov  2 13:16:10 2012
From: ibc at aliax.net (=?UTF-8?Q?I=C3=B1aki_Baz_Castillo?=)
Date: Fri, 2 Nov 2012 13:16:10 +0100
Subject: [OpenSIPS-Devel] [OpenSIPS-Users] [RELEASES] Planing OpenSIPS
 1.9.0 major release
In-Reply-To: <1351820619.2124.YahooMailNeo@web122602.mail.ne1.yahoo.com>
References: <508AAA59.7070107@opensips.org>
	<CAND0Lkt5HBOga5+P7WWC2oh5XFtQAw03YKdMwCEi+gtd-kdVzw@mail.gmail.com>
	<CAFcM1Eq7VnxNmNJx5AEnt=oCkEnu9+t_yZ0Aoy05wi+f4a8ULg@mail.gmail.com>
	<B5527242-3B09-4E3E-9C18-C42D7A080760@ag-projects.com>
	<CA+q4kR+G4O8F3ZanE1m+Rw+T-55qr3rwGohS0iO19C+3SJn2VA@mail.gmail.com>
	<508E59E1.9050206@opensips.org>
	<3E4434C0-F580-47DE-8450-8F968C629D70@ag-projects.com>
	<509110FE.7010106@opensips.org>
	<8B3FCB90-4065-439B-A7E2-857F74C237AC@ag-projects.com>
	<CA+q4kR+80_=wgzymDLoTY4y0sK2Ypz5QTLpq2zgfBq3gVRj2Jg@mail.gmail.com>
	<CALiegf=jRfmcaT9-G-sBH0gE028G2jEQUPaNnwk5LxbNPqr1SA@mail.gmail.com>
	<50925120.4040008@opensips.org>
	<CALiegfn9-LNiOZgWbxMPwz7Amdqs+d7kgExb7FXQ0Y+U1hZCgw@mail.gmail.com>
	<1351820619.2124.YahooMailNeo@web122602.mail.ne1.yahoo.com>
Message-ID: <CALiegfmt3cOMhN1UTyx9=vociBhC-J8NBNpiZUu-OMMzOxsJRQ@mail.gmail.com>

2012/11/2 Binan AL Halabi <binanalhalabi at yahoo.com>:
>
> Hi All,
>
> If oversip uses Path extension OpenSIPS must support it.
>
> 1- Sending Path header values in 200 ok REGISTER response

Even if this is required by RFC, the fact is that it's not needed at
all for this stuff to work.


> 2- Path header files syntax must confom to Route syntax

Right.


> 3- When look up the opensips must copies the stored path header fileds into
> Route header fileds - preloaded route.
> Reference: RFC 3327

Right.



> Here i think adding one Route header pointing to OverSIP (second Path URI)
> is enough in simple case (UA ---- OverSIP--- OpenSIPS).
> OverSIP removes the Route header and route the request based on RURI (first
> Path URI).

Also right, but due the design of OverSIP (basically an Outbound EDGE
proxy) it was easier for me to always use double Record-Route and
double Path header. In Outbound (RFC 5626) the Record-Route header
added by the EDGE proxy contains a username in the URI that identifies
the client connection. For some reasons it was easier always to use
double Path.

Anyhow, consider also the case in which there are two proxies between
clients and OpenSIPS, so increasing the size of the "path" column is
required.




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


From ibc at aliax.net  Fri Nov  2 13:17:17 2012
From: ibc at aliax.net (=?UTF-8?Q?I=C3=B1aki_Baz_Castillo?=)
Date: Fri, 2 Nov 2012 13:17:17 +0100
Subject: [OpenSIPS-Devel] [OpenSIPS-Users] [RELEASES] Planing OpenSIPS
 1.9.0 major release
In-Reply-To: <ktjac9x4xndlsvsnil722ad6.1351837462673@email.android.com>
References: <ktjac9x4xndlsvsnil722ad6.1351837462673@email.android.com>
Message-ID: <CALiegfmkjCKFtzVX59qXWXkHUnu9wp0xjZY89BAzJDqB9TMOrQ@mail.gmail.com>

2012/11/2 Bogdan-Andrei Iancu <bogdan at opensips.org>:
> Yes the patch is there, we need to review it. Also Inaki sugested some
> tunings in the PATH module (to fully support websocket).

Well, there is no special needs for the PATH module to support
WebSocket. In fact, nothing must be done if it already works ok (but
just increasing the path column size to be able to store two URIs).

Regards.

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


From noreply at sourceforge.net  Fri Nov  2 14:46:19 2012
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 02 Nov 2012 06:46:19 -0700
Subject: [OpenSIPS-Devel] [ opensips-Bugs-3563203 ] do_routing function
	crash without group id parameter
Message-ID: <mailman.1155.1351863989.13469.devel@lists.opensips.org>

Bugs item #3563203, was opened at 2012-08-30 01:34
Message generated for change (Comment added) made by red02
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=3563203&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.7.x
Status: Open
Resolution: Accepted
Priority: 5
Private: No
Submitted By: piero ferraresso (red02)
Assigned to: Bogdan-Andrei Iancu (bogdan_iancu)
Summary: do_routing function crash without group id parameter

Initial Comment:
I\'m using opensips v. 1.7.2-TLS on a Debian 6.04 machine. 
If I call the function do_routing without specifing the group id parameter - do_routing(\"\",\"1\") for example - opensips crah (segfault at 0 ip 081399d8 sp bfed0480 error 4 in opensips[8048000+150000]).
If I insert the group id - do_routing(\"0\",\"1\") for example - all works fine.
Where do I wrong? 
 
Thanks in advance 

     Piero Ferraresso 

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

>Comment By: piero ferraresso (red02)
Date: 2012-11-02 06:46

Message:
I've just installed the latest version (1.8.2). This time I get this error
on the syslog: "CRITICAL:db_mysql:wrapper_single_mysql_real_query: driver
error (1064): You have an error in your SQL syntax; check the manual that
corresponds to your MySQL server version for the right syntax to use near
'#017 where username='prove'' at line 1
Nov  2 14:30:07 proxysiptest /sbin/opensips[28858]: ERROR:core:db_do_query:
error while submitting query - [select groupid from #017 where
username='prove']".
I've also executed the comands in GDB as you sugget, but after the "frame
0" and "p _h" commands I get: "No symbol "_h" in current context"

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

Comment By: Bogdan-Andrei Iancu (bogdan_iancu)
Date: 2012-10-12 06:48

Message:
Hi Piero,

in GDB, in frame 0, could you do:

p _h
p *_h
p _h->table->s

Thanks and regards,
Bogdan

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

Comment By: piero ferraresso (red02)
Date: 2012-10-11 06:37

Message:
I've got the some problem also with the latest stable release (1.8.1.-TLS).

Piero 

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

Comment By: Bogdan-Andrei Iancu (bogdan_iancu)
Date: 2012-09-18 03:51

Message:
Post the opensips logs (with debug 6) corresponding to the INVITE
processing.

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

Comment By: Bogdan-Andrei Iancu (bogdan_iancu)
Date: 2012-09-18 03:50

Message:
Still working (even if db_virtual):

Sep 18 14:49:33 [12557] DBG:core:parse_to_param: tag=fuzyi
Sep 18 14:49:33 [12557] DBG:core:parse_to: end of header reached, state=29
Sep 18 14:49:33 [12557] DBG:core:parse_to: display={"bogdan"},
ruri={sip:bogdan at opensips.org}
Sep 18 14:49:33 [12557] DBG:db_virtual:db_virtual_query: f call 
Sep 18 14:49:33 [12557] DBG:db_virtual:db_virtual_query: f call handle size
= 2
Sep 18 14:49:33 [12557] DBG:db_virtual:try_reconnect: try reconnect
Sep 18 14:49:33 [12557] DBG:db_virtual:db_virtual_query: flags1 = 3
Sep 18 14:49:33 [12557] DBG:core:db_new_result: allocate 48 bytes for
result set at 0x7cf908
Sep 18 14:49:33 [12557] DBG:db_mysql:db_mysql_get_columns: 1 columns
returned from the query
Sep 18 14:49:33 [12557] DBG:core:db_allocate_columns: allocate 28 bytes for
result columns at 0x7cfb88
Sep 18 14:49:33 [12557] DBG:db_mysql:db_mysql_get_columns:
RES_NAMES(0x7cfb90)[0]=[groupid]
Sep 18 14:49:33 [12557] DBG:db_mysql:db_mysql_get_columns: use DB_INT
result type
Sep 18 14:49:33 [12557] DBG:db_mysql:db_mysql_convert_rows: no rows
returned from the query
Sep 18 14:49:33 [12557] DBG:db_virtual:db_virtual_query: curent_con = 0
Sep 18 14:49:33 [12557] ERROR:drouting:get_group_id: no group for user
"bogdan"@"opensips.org"
Sep 18 14:49:33 [12557] DBG:db_virtual:db_virtual_free_result: f call 
Sep 18 14:49:33 [12557] DBG:db_virtual:db_virtual_free_result: f call
handle size = 2
Sep 18 14:49:33 [12557] DBG:db_virtual:try_reconnect: try reconnect
Sep 18 14:49:33 [12557] DBG:db_virtual:db_virtual_free_result: flags1 = 3
Sep 18 14:49:33 [12557] DBG:core:db_free_columns: freeing result columns at
0x7cfb88
Sep 18 14:49:33 [12557] DBG:core:db_free_rows: freeing 0 rows
Sep 18 14:49:33 [12557] DBG:core:db_free_result: freeing result set at
0x7cf908
Sep 18 14:49:33 [12557] DBG:db_virtual:db_virtual_free_result: curent_con =
0
Sep 18 14:49:33 [12557] ERROR:drouting:do_routing: failed to get group id
Sep 18 14:49:33 [12557] DBG:core:buf_init: initializing...
----DR failed !!
Sep 18 14:49:33 [12557] DBG:core:destroy_avp_list: destroying list (nil)


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

Comment By: piero ferraresso (red02)
Date: 2012-09-18 02:34

Message:
This is my actual configuration:

#db_default_url="virtual://set1"  # parallel
db_default_url="virtual://set2"   # failover
#db_default_url="virtual://set3"  # round

#Setting module-specific parameters 

# DB_virtual
modparam("db_virtual", "db_probe_time", 10)#default 10 sec
modparam("db_virtual", "db_max_consec_retrys", 3)#default 10 consecutive
times

modparam("db_virtual", "db_urls", "define set1 PARALLEL")
modparam("db_virtual", "db_urls",
"mysql://opensips:xxx at sqlnode1/opensips17")
modparam("db_virtual", "db_urls",
"mysql://opensips:xxx at sqlnode2/opensips17")

modparam("db_virtual", "db_urls", "define set2 FAILOVER")
modparam("db_virtual", "db_urls",
"mysql://opensips:xxx at localhost/opensips17")
modparam("db_virtual", "db_urls",
"mysql://opensips:xxx at sqlnode1/opensips17")
modparam("db_virtual", "db_urls",
"mysql://opensips:xxx at sqlnode2/opensips17")

modparam("db_virtual", "db_urls", "define set3 ROUND")
modparam("db_virtual", "db_urls",
"mysql://opensips:xx at sqlnode1/opensips17")
modparam("db_virtual", "db_urls",
"mysql://opensips:xx at sqlnode2/opensips17")


# Dynamic Routing + Load Balancer

modparam("drouting", "use_domain", 0)
modparam("drouting", "probing_interval", 60)
modparam("drouting", "probing_from", "sip:pinger at si.unimib.it")
modparam("drouting", "probing_method", "OPTIONS")
modparam("drouting", "probing_reply_codes", "501, 403, 404")

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

Comment By: Bogdan-Andrei Iancu (bogdan_iancu)
Date: 2012-09-18 00:13

Message:
Please post the db virtual configuration you are using for the DR module.
And one again, if you get a core file, extract please the backtrace from
it.

Regards,
Bogdan

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

Comment By: piero ferraresso (red02)
Date: 2012-09-17 05:14

Message:
Yes, It seems to depend on using the virtual db module. 

Piero

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

Comment By: Bogdan-Andrei Iancu (bogdan_iancu)
Date: 2012-09-17 01:39

Message:
I tried to reproduce this, using 1.7 :

	if (!do_routing("","1")) {
		xlog("----DR failed !!\n");
		exit;
	}

But with no success - I get error messages with no crash:

Sep 17 12:34:54 [6354] DBG:core:parse_to_param: tag=fuzyi
Sep 17 12:34:54 [6354] DBG:core:parse_to: end of header reached, state=29
Sep 17 12:34:54 [6354] DBG:core:parse_to: display={"bogdan"},
ruri={sip:bogdan at opensips.org}
Sep 17 12:34:54 [6354] DBG:core:db_new_result: allocate 48 bytes for result
set at 0x7cc598
Sep 17 12:34:54 [6354] DBG:db_mysql:db_mysql_get_columns: 1 columns
returned from the query
Sep 17 12:34:54 [6354] DBG:core:db_allocate_columns: allocate 28 bytes for
result columns at 0x7cc5e0
Sep 17 12:34:54 [6354] DBG:db_mysql:db_mysql_get_columns:
RES_NAMES(0x7cc5e8)[0]=[groupid]
Sep 17 12:34:54 [6354] DBG:db_mysql:db_mysql_get_columns: use DB_INT result
type
Sep 17 12:34:54 [6354] DBG:db_mysql:db_mysql_convert_rows: no rows returned
from the query
Sep 17 12:34:54 [6354] ERROR:drouting:get_group_id: no group for user
"bogdan"@"opensips.org"
Sep 17 12:34:54 [6354] DBG:core:db_free_columns: freeing result columns at
0x7cc5e0
Sep 17 12:34:54 [6354] DBG:core:db_free_rows: freeing 0 rows
Sep 17 12:34:54 [6354] DBG:core:db_free_result: freeing result set at
0x7cc598
Sep 17 12:34:54 [6354] ERROR:drouting:do_routing: failed to get group id
Sep 17 12:34:54 [6354] DBG:core:buf_init: initializing...
----DR failed !!


Maybe it is something particular to your case, so please provide an
backtrace.

Regards,
Bogdan

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

Comment By: Bogdan-Andrei Iancu (bogdan_iancu)
Date: 2012-09-11 02:51

Message:
Hi Piero,

Could you try without the db_virtual module (direct query to mysql) to see
if you still have this issue ?

Thanks and regards,
Bogdan

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

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


From bogdan at opensips.org  Fri Nov  2 14:55:13 2012
From: bogdan at opensips.org (Bogdan-Andrei Iancu)
Date: Fri, 02 Nov 2012 15:55:13 +0200
Subject: [OpenSIPS-Devel] [OpenSIPS-Users] [RELEASES] Planing OpenSIPS
 1.9.0 major release
In-Reply-To: <CALiegfmkjCKFtzVX59qXWXkHUnu9wp0xjZY89BAzJDqB9TMOrQ@mail.gmail.com>
References: <ktjac9x4xndlsvsnil722ad6.1351837462673@email.android.com>
	<CALiegfmkjCKFtzVX59qXWXkHUnu9wp0xjZY89BAzJDqB9TMOrQ@mail.gmail.com>
Message-ID: <5093D0C1.6090602@opensips.org>


On 11/02/2012 02:17 PM, I?aki Baz Castillo wrote:
> 2012/11/2 Bogdan-Andrei Iancu<bogdan at opensips.org>:
>> Yes the patch is there, we need to review it. Also Inaki sugested some
>> tunings in the PATH module (to fully support websocket).
> Well, there is no special needs for the PATH module to support
> WebSocket. In fact, nothing must be done if it already works ok (but
> just increasing the path column size to be able to store two URIs).
>
Yes, that's the kind of things I was referring at. Also looking in the 
patch module code, there are several things that can be improved there 
(how path is built, mem usag, etc). There are still some faulty things 
also there  - there was recently a fix on TCP handling (proto changing) 
in PATH hdr.

Regards,
Bogdan


From noreply at sourceforge.net  Fri Nov  2 16:58:41 2012
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 02 Nov 2012 08:58:41 -0700
Subject: [OpenSIPS-Devel] [ opensips-Bugs-3582691 ] Mem Leak in msg callbacks
Message-ID: <mailman.1156.1351871927.13469.devel@lists.opensips.org>

Bugs item #3582691, was opened at 2012-11-02 08:58
Message generated for change (Tracker Item Submitted) made by bogdan_iancu
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=3582691&group_id=232389

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: core
Group: trunk
Status: Open
Resolution: None
Priority: 7
Private: No
Submitted By: Bogdan-Andrei Iancu (bogdan_iancu)
Assigned to: Nobody/Anonymous (nobody)
Summary: Mem Leak in msg callbacks

Initial Comment:
msg callbacks + params are not freed in call cases

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

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


From noreply at sourceforge.net  Fri Nov  2 16:58:57 2012
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 02 Nov 2012 08:58:57 -0700
Subject: [OpenSIPS-Devel] [ opensips-Bugs-3582691 ] Mem Leak in msg callbacks
Message-ID: <mailman.1157.1351871942.13469.devel@lists.opensips.org>

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

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: core
Group: trunk
Status: Open
Resolution: None
Priority: 7
Private: No
Submitted By: Bogdan-Andrei Iancu (bogdan_iancu)
>Assigned to: Bogdan-Andrei Iancu (bogdan_iancu)
Summary: Mem Leak in msg callbacks

Initial Comment:
msg callbacks + params are not freed in call cases

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

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


From binanalhalabi at yahoo.com  Sat Nov  3 06:40:03 2012
From: binanalhalabi at yahoo.com (Binan AL Halabi)
Date: Fri, 2 Nov 2012 22:40:03 -0700 (PDT)
Subject: [OpenSIPS-Devel] VB: [OpenSIPS-Users] [RELEASES] Planing OpenSIPS
	1.9.0 major release
In-Reply-To: <1351921162.14227.YahooMailNeo@web122605.mail.ne1.yahoo.com>
References: <508AAA59.7070107@opensips.org>
	<20049EB2-1E5C-438B-9F8A-CCF7566A2F46@ag-projects.com>
	<508E564B.4060106@opensips.org>
	<AC1BB636-DC7E-4A06-913F-B446AE847A27@ag-projects.com>
	<509256BB.9090403@opensips.org>
	<1351921162.14227.YahooMailNeo@web122605.mail.ne1.yahoo.com>
Message-ID: <1351921203.41425.YahooMailNeo@web122604.mail.ne1.yahoo.com>

Hi ALL,


According to 14.1 and 14.2 of RFC 3261 after receiving 491 the UAC will retry again after 2.1-4.0 seconds if it owns the CALL-ID or 0.0.-2.0 if not.

So 
If UAS have an ongoing in-dialog ping and receive another one let it send 491 and drop the request (the end point will retry it later).

// Binan.



________________________________
 Fr?n: Bogdan-Andrei Iancu <bogdan at opensips.org>
Till: OpenSIPS users mailling list <users at lists.opensips.org> 
Kopia: OpenSIPS devel mailling list <devel at lists.opensips.org> 
Skickat: torsdag, 1 november 2012 12:02
?mne: Re: [OpenSIPS-Users] [OpenSIPS-Devel] [RELEASES] Planing OpenSIPS 1.9.0 major release
 
Hi Dan,

Well, as Ovidiu said, it is prone. BUT, this is not something particular 
to re-INVITE, but to whatever in-dialog pinging you may have from a 
mid-proxy.

On the other hand, as Ryan pointed out here, the need to check the 
dialog health from proxy side, without relying on special end-UA 
features (like SST), is really critical.

So, I see two approaches:
? ?  1) either simply live with the fact that races may occure and calls 
may be dropped during a re-INVITE, but at least is a clear drop /cut
? ?  2) theoretically we can try to address the race at dialog modules 
level : (a) If you have ongoing in-dialog transaction, do not do your 
ping , (b) if you have an ongoing in-dialog ping and receive another 
in-dilog request from end point, try to delay it until your pinging is 
done.....just some ideas....


Regards,

Bogdan-Andrei Iancu
OpenSIPS Founder and
 Developer
http://www.opensips-solutions.com


On 10/31/2012 09:03 PM, Dan Pascu wrote:
> On 29 Oct 2012, at 12:11, Bogdan-Andrei Iancu wrote:
>
>> Hi Saul,
>>
>> We were thinking at re-INVITE pinging from OpenSIPs level towards the caller and callee. There will be 2 modes (at least this is the current plan).
>>? ?  1) remember all the time the last SDPs from each side and re-use them when pining the other sides (just to trick the SDP negotiation)
>>? ?  2) start with a lateSDP negotiation on one side and do normal SDP on the other side (to avoid SDP storing), but this means at least one of the parties should support late SDP negotiations
>>? ?  3) open to other suggestions....
> I think this invites trouble as it is prone to race conditions. If any of the clients send a re-INVIVITE of their own while OpenSIPs does it's pinging, it will fail
 as there is already an active unanswered re-INVITE in progress. The client will be confused as it didn't send another re-INVITE itself and the negative reply to its own re-INVITE will probably just prompt the client to terminate the session thinking there is some issue with it.
>
> I cannot see this working without a full B2BUA, where OpenSIPs would queue the client requests if there is a ping in progress and only forward them after it has finished the ping transaction.
>
>> About the GRUU stuff, could you detail a bit :D ?
>>
>> Regards,
>>
>> Bogdan-Andrei Iancu
>> OpenSIPS Founder and Developer
>> http://www.opensips-solutions.com
>>
>>
>> On 10/26/2012 06:51 PM, Sa?l Ibarra Corretg? wrote:
>>> Hi,
>>>
>>> On Oct 26, 2012, at 5:20 PM,
 Bogdan-Andrei Iancu wrote:
>>>
>>>> Hi all,
>>>>
>>>> I would like to start a discussion about the next OpenSIPS major release - and in this discussion anyone is welcomed with options, ideas, critics and other. Your feedback is important to drive the project into a direction that reflects the user's needs!.
>>>>
>>>> So, I will here the starting points, for both release planing and release content.
>>>>
>>>>
>>>> Content
>>>> -------
>>>> What was done:
>>>>? ? ? ?  http://www.opensips.org/Main/Ver190#toc2
>>>> What is planned:
>>>>? ? ? ?  http://www.opensips.org/Main/Ver190#toc9
>>>> Planned items have priorities (for being addressed); it is a must to have all items done for the next release,
 as we need to fit into a time frame. Whatever is not done, will be left for the next release (1.10)
>>>>
>>>>
>>>> Planing
>>>> -------
>>>> Release candidate:
>>>>? ?  second half of January 2012, depending on the progress with the items to be done.
>>>> Testing phase:
>>>>? ?  1 month allocated (it may be extended if critical problems show up)
>>>> Stable release:
>>>>? ?  second half of February (after the testing phase is done).
>>>>
>>>>
>>>> Once again, your feedback on these matters is important to us.
>>>>
>>> I'll edit the wiki with the items we've been working on for presence.
>>>
>>> Can you give a bit more detail on the dialog ping with re-INVITEs? re-INVITEs are
 particularly troublesome, because there can only be one of them at a time.
>>>
>>> Also, can we add the in-dialog requests when using GRUU bug to the wishlist? :-)
>>>
>>> Keep up the good work guys!
>>>
>>>
>>> Regards,
>>>
>>> --
>>> Sa?l Ibarra Corretg?
>>> AG Projects
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> Devel mailing list
>>> Devel at lists.opensips.org
>>> http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
>>>
>> _______________________________________________
>> Users mailing
 list
>> Users at lists.opensips.org
>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>
>
> --
> Dan
>
>
>
>
>
> _______________________________________________
> Users mailing list
> Users at lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>

_______________________________________________
Users mailing list
Users at lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/devel/attachments/20121102/e4373197/attachment-0001.htm>

From bogdan at opensips.org  Sat Nov  3 08:50:42 2012
From: bogdan at opensips.org (Bogdan-Andrei Iancu)
Date: Sat, 03 Nov 2012 09:50:42 +0200
Subject: [OpenSIPS-Devel] VB: [OpenSIPS-Users] [RELEASES] Planing
 OpenSIPS	1.9.0 major release
Message-ID: <kc8q3v0nevjtekucp0mvwi5f.1351929042144@email.android.com>

Hi Binan,

That's in theory and it will be wonderfull if all devices will follow that. But in real world, as Ryan pointed out, just a few UAC implementations do properly handle a 491 to a reINVITE.

Regards,
Bogdan


Sent from Samsung MobileBinan AL Halabi <binanalhalabi at yahoo.com> wrote:Hi ALL,

According to 14.1 and 14.2 of RFC 3261 after receiving 491 the UAC will retry again after 2.1-4.0 seconds if it owns the CALL-ID or 0.0.-2.0 if not.

So 
If UAS have an ongoing in-dialog ping and receive another one let it send 491 and drop the request (the end point will retry it later).

// Binan.

Fr?n: Bogdan-Andrei Iancu <bogdan at opensips.org>
Till: OpenSIPS users mailling list <users at lists.opensips.org> 
Kopia: OpenSIPS devel mailling list <devel at lists.opensips.org> 
Skickat: torsdag, 1 november 2012 12:02
?mne: Re: [OpenSIPS-Users] [OpenSIPS-Devel] [RELEASES] Planing OpenSIPS 1.9.0 major release

Hi Dan,

Well, as Ovidiu said, it is prone. BUT, this is not something particular 
to re-INVITE, but to whatever in-dialog pinging you may have from a 
mid-proxy.

On the other hand, as Ryan pointed out here, the need to check the 
dialog health from proxy side, without relying on special end-UA 
features (like SST), is really critical.

So, I see two approaches:
? ? 1) either simply live with the fact that races may occure and calls 
may be dropped during a re-INVITE, but at least is a clear drop /cut
? ? 2) theoretically we can try to address the race at dialog modules 
level : (a) If you have ongoing in-dialog transaction, do not do your 
ping , (b) if you have an ongoing in-dialog ping and receive another 
in-dilog request from end point, try to delay it until your pinging is 
done.....just some ideas....


Regards,

Bogdan-Andrei Iancu
OpenSIPS Founder and Developer
http://www.opensips-solutions.com


On 10/31/2012 09:03 PM, Dan Pascu wrote:
> On 29 Oct 2012, at 12:11, Bogdan-Andrei Iancu wrote:
>
>> Hi Saul,
>>
>> We were thinking at re-INVITE pinging from OpenSIPs level towards the caller and callee. There will be 2 modes (at least this is the current plan).
>>? ? 1) remember all the time the last SDPs from each side and re-use them when pining the other sides (just to trick the SDP negotiation)
>>? ? 2) start with a lateSDP negotiation on one side and do normal SDP on the other side (to avoid SDP storing), but this means at least one of the parties should support late SDP negotiations
>>? ? 3) open to other suggestions....
> I think this invites trouble as it is prone to race conditions. If any of the clients send a re-INVIVITE of their own while OpenSIPs does it's pinging, it will fail as there is already an active unanswered re-INVITE in progress. The client will be confused as it didn't send another re-INVITE itself and the negative reply to its own re-INVITE will probably just prompt the client to terminate the session thinking there is some issue with it.
>
> I cannot see this working without a full B2BUA, where OpenSIPs would queue the client requests if there is a ping in progress and only forward them after it has finished the ping transaction.
>
>> About the GRUU stuff, could you detail a bit :D ?
>>
>> Regards,
>>
>> Bogdan-Andrei Iancu
>> OpenSIPS Founder and Developer
>> http://www.opensips-solutions.com
>>
>>
>> On 10/26/2012 06:51 PM, Sa?l Ibarra Corretg? wrote:
>>> Hi,
>>>
>>> On Oct 26, 2012, at 5:20 PM, Bogdan-Andrei Iancu wrote:
>>>
>>>> Hi all,
>>>>
>>>> I would like to start a discussion about the next OpenSIPS major release - and in this discussion anyone is welcomed with options, ideas, critics and other. Your feedback is important to drive the project into a direction that reflects the user's needs!.
>>>>
>>>> So, I will here the starting points, for both release planing and release content.
>>>>
>>>>
>>>> Content
>>>> -------
>>>> What was done:
>>>>? ? ? ? http://www.opensips.org/Main/Ver190#toc2
>>>> What is planned:
>>>>? ? ? ? http://www.opensips.org/Main/Ver190#toc9
>>>> Planned items have priorities (for being addressed); it is a must to have all items done for the next release, as we need to fit into a time frame. Whatever is not done, will be left for the next release (1.10)
>>>>
>>>>
>>>> Planing
>>>> -------
>>>> Release candidate:
>>>>? ? second half of January 2012, depending on the progress with the items to be done.
>>>> Testing phase:
>>>>? ? 1 month allocated (it may be extended if critical problems show up)
>>>> Stable release:
>>>>? ? second half of February (after the testing phase is done).
>>>>
>>>>
>>>> Once again, your feedback on these matters is important to us.
>>>>
>>> I'll edit the wiki with the items we've been working on for presence.
>>>
>>> Can you give a bit more detail on the dialog ping with re-INVITEs? re-INVITEs are particularly troublesome, because there can only be one of them at a time.
>>>
>>> Also, can we add the in-dialog requests when using GRUU bug to the wishlist? :-)
>>>
>>> Keep up the good work guys!
>>>
>>>
>>> Regards,
>>>
>>> --
>>> Sa?l Ibarra Corretg?
>>> AG Projects
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> Devel mailing list
>>> Devel at lists.opensips.org
>>> http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
>>>
>> _______________________________________________
>> Users mailing list
>> Users at lists.opensips.org
>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>
>
> --
> Dan
>
>
>
>
>
> _______________________________________________
> Users mailing list
> Users at lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>

_______________________________________________
Users mailing list
Users at lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users




-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/devel/attachments/20121103/c5b64362/attachment.htm>

From noreply at sourceforge.net  Sat Nov  3 17:45:54 2012
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat, 03 Nov 2012 09:45:54 -0700
Subject: [OpenSIPS-Devel] [ opensips-Bugs-3576387 ] segfault on
	dlg_ping_routine
Message-ID: <mailman.1158.1351961160.13469.devel@lists.opensips.org>

Bugs item #3576387, was opened at 2012-10-11 10:18
Message generated for change (Comment added) made by flaviogoncalves
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=3576387&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.8.x
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Flavio Goncalves (flaviogoncalves)
Assigned to: Vladut-Stefan Paiu (vladut-paiu)
Summary: segfault on dlg_ping_routine

Initial Comment:
I'm reopening the case, It happened again after the patch. 

Program terminated with signal 11, Segmentation fault.
#0  dlg_ping_routine (ticks=<value optimized out>, attr=<value optimized out>) at dlg_timer.c:525

525                     dlg->pl = 0;
(gdb) bt full
#0  dlg_ping_routine (ticks=<value optimized out>, attr=<value optimized out>) at dlg_timer.c:525
        expired = <value optimized out>
        it = <value optimized out>
        curr = 0x7fba18391c18
        dlg = 0x5d
        __FUNCTION__ = "dlg_ping_routine"
#1  0x00000000004b53dc in timer_ticker () at timer.c:360
        t = 0x7fba5e562d58
#2  run_timer_process () at timer.c:430
        multiple = 10
        cnt = <value optimized out>
        tv = {tv_sec = 0, tv_usec = 0}
#3  start_timer_processes () at timer.c:527
        tpl = 0x7fba5e5614d0
        pid = <value optimized out>
        __FUNCTION__ = "start_timer_processes"
#4  0x00000000004327d3 in main_loop (argc=<value optimized out>, argv=<value optimized out>) at main.c:933
        i = 8
        pid = 24
        si = 0x0
        startup_done = 0x7fba16a1f598
        chd_rank = 16
        load_p = 0x7fba16a1f8e8
#5  main (argc=<value optimized out>, argv=<value optimized out>) at main.c:1520
        cfg_log_stderr = 8
        cfg_stream = <value optimized out>
        c = <value optimized out>
        r = <value optimized out>
        tmp = 0x7fff5461eea0 ""
        tmp_len = <value optimized out>
        port = <value optimized out>
        proto = <value optimized out>
        ret = <value optimized out>
        seed = 2170505229
        rfd = <value optimized out>
        __FUNCTION__ = "main"

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

Comment By: Flavio Goncalves (flaviogoncalves)
Date: 2012-11-03 09:45

Message:
(gdb) f 0 
#0  dlg_ping_routine (ticks=<value optimized out>, attr=<value optimized
out>) at dlg_timer.c:525
525			dlg->pl = 0;
(gdb) p dlg
$1 = (struct dlg_cell *) 0x5d
(gdb) p *dlg
Cannot access memory at address 0x5d

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

Comment By: Vladut-Stefan Paiu (vladut-paiu)
Date: 2012-10-30 07:11

Message:
Hello,

Could you please run, in GDB, the following, and post here the output ?

f 0
p dlg
p *dlg

Regards,
Vlad

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

Comment By: Dragos Oancea (dragosoancea)
Date: 2012-10-12 04:41

Message:
Hi


This did not happened to me after I applied the patches ( tls_init.c patch
and dialog module patch - see bug ID 3570495  ) .
I use :
modparam("dialog", "ping_interval", 40)
modparam("tm", "fr_timer", 15)

Cheers,
Dragos



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

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


From vladpaiu at opensips.org  Mon Nov  5 11:56:27 2012
From: vladpaiu at opensips.org (Vlad Paiu)
Date: Mon, 05 Nov 2012 10:56:27 +0000
Subject: [OpenSIPS-Devel] SF.net SVN: opensips:[9422]
	trunk/modules/cachedb_redis
Message-ID: <E1TVKLz-0007xD-3Z@sfp-svn-1.v30.ch3.sourceforge.com>

Revision: 9422
          http://opensips.svn.sourceforge.net/opensips/?rev=9422&view=rev
Author:   vladut-paiu
Date:     2012-11-05 10:56:26 +0000 (Mon, 05 Nov 2012)
Log Message:
-----------
fixed memory corruption

Modified Paths:
--------------
    trunk/modules/cachedb_redis/cachedb_redis_dbase.c
    trunk/modules/cachedb_redis/cachedb_redis_utils.c

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



From vladpaiu at opensips.org  Mon Nov  5 12:02:22 2012
From: vladpaiu at opensips.org (Vlad Paiu)
Date: Mon, 05 Nov 2012 11:02:22 +0000
Subject: [OpenSIPS-Devel] SF.net SVN: opensips:[9423]
	branches/1.8/modules/cachedb_redis
Message-ID: <E1TVKRi-00027n-Hi@sfp-svn-3.v30.ch3.sourceforge.com>

Revision: 9423
          http://opensips.svn.sourceforge.net/opensips/?rev=9423&view=rev
Author:   vladut-paiu
Date:     2012-11-05 11:02:22 +0000 (Mon, 05 Nov 2012)
Log Message:
-----------
backport from trunk (rev #9422)

fixed memory corruption

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

Modified Paths:
--------------
    branches/1.8/modules/cachedb_redis/cachedb_redis_dbase.c
    branches/1.8/modules/cachedb_redis/cachedb_redis_utils.c

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



From dan at ag-projects.com  Mon Nov  5 16:40:05 2012
From: dan at ag-projects.com (Dan Pascu)
Date: Mon, 5 Nov 2012 17:40:05 +0200
Subject: [OpenSIPS-Devel] [OpenSIPS-Users] [RELEASES] Planing OpenSIPS
	1.9.0 major release
In-Reply-To: <CAAcj4gUtXj15Pr4hMfrvG5q-7wKZvLjp8kaSjyxfkQqPKsYa5g@mail.gmail.com>
References: <508AAA59.7070107@opensips.org>
	<20049EB2-1E5C-438B-9F8A-CCF7566A2F46@ag-projects.com>
	<508E564B.4060106@opensips.org>
	<AC1BB636-DC7E-4A06-913F-B446AE847A27@ag-projects.com>
	<CAND0LkvfFpEv5x+UvPwcogzPjMk7X7_xyAxhcsqsxQNGNbd3rQ@mail.gmail.com>
	<CAAcj4gUtXj15Pr4hMfrvG5q-7wKZvLjp8kaSjyxfkQqPKsYa5g@mail.gmail.com>
Message-ID: <3E77CAA7-7714-4CFF-96ED-1CF3DB47C2E5@ag-projects.com>


On 31 Oct 2012, at 21:59, Ryan Bullock wrote:

> These would make pinging a bit more complicated but may help avoid races:
> 
> 1.  Have the ping aware of when the last INVITE was seen in the dialog (sent from anyone) and only issue its own re-INVITE if it has not seen an INVITE for X seconds in the dialog. Perhaps X could be a lower value if the previous re-INVITE had a negative reply (many clients locally end the call when they receive a negative reply to an INVITE, but may not issue a BYE). Add a little session timer awareness and you may be able to avoid most races.

This will not solve anything. Client behavior is unpredictable from the server point of view. You cannot estimate when the client will send the next re-INVITE in order to avoid the race.

> 
> 2. Combine 1 with OPTIONS between INVITES. For example, send an OPTION ping every minute, but you also want to see a re-INVITE every 15 minutes. This could allow quick detection for clients that support OPTION properly and the re-INVITE would help detect dead calls when the client is a bit buggy.

It doesn't matter if you send in-dialog OPTIONs or INVITEs. Two in-dialog requests cannot overlap, no matter if it's an OPTION or an INVITE. The issue is the same regardless of the method you use.

--
Dan






From dan at ag-projects.com  Mon Nov  5 16:57:13 2012
From: dan at ag-projects.com (Dan Pascu)
Date: Mon, 5 Nov 2012 17:57:13 +0200
Subject: [OpenSIPS-Devel] [OpenSIPS-Users] [RELEASES] Planing OpenSIPS
	1.9.0 major release
In-Reply-To: <509256BB.9090403@opensips.org>
References: <508AAA59.7070107@opensips.org>	<20049EB2-1E5C-438B-9F8A-CCF7566A2F46@ag-projects.com>	<508E564B.4060106@opensips.org>
	<AC1BB636-DC7E-4A06-913F-B446AE847A27@ag-projects.com>
	<509256BB.9090403@opensips.org>
Message-ID: <1F81E619-1DC7-49BC-BEE9-C15DE23C71C2@ag-projects.com>


On 1 Nov 2012, at 13:02, Bogdan-Andrei Iancu wrote:

> Hi Dan,
> 
> Well, as Ovidiu said, it is prone. BUT, this is not something particular to re-INVITE, but to whatever
> in-dialog pinging you may have from a mid-proxy.

I never said otherwise.

> On the other hand, as Ryan pointed out here, the need to check the dialog health from proxy side, without relying on special end-UA features (like SST), is really critical.

While it may be useful (I would not call it exactly critical), this doesn't mean that the implementation should introduce new issues. I'm not arguing against the idea of having a keep-alive mechanism here, but against particular implementations that introduce new issues.

> So, I see two approaches:
>    1) either simply live with the fact that races may occure and calls may be dropped during a re-INVITE, but at least is a clear drop /cut

I'm not sure you can explain your customers that their calls are being dropped because you have a race condition in your implementation which you are willing to live with...

>    2) theoretically we can try to address the race at dialog modules level : (a) If you have ongoing in-dialog transaction, do not do your ping ,

This was never the issue. You can always avoid this.

> (b) if you have an ongoing in-dialog ping and receive another in-dilog request from end point, try to delay it until your pinging is done.....

This should work, but I don't see it working without a proper async reactor model. How do you plan to delay it, without blocking the worker?

On another note, I also believe that a re-INVITE based keep-alive is also problematic because it has to implement the whole stream selection mechanism in the clients in order to know what streams to propose in the re-INVITE. Even so, triggering a SDP renegotiation every now and then is not very nice, regardless of it changing nothing in the streams.

--
Dan






From noreply at sourceforge.net  Mon Nov  5 19:07:22 2012
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 05 Nov 2012 10:07:22 -0800
Subject: [OpenSIPS-Devel] [ opensips-Bugs-3584278 ] regression in snmpstats
	module
Message-ID: <mailman.1159.1352138850.13469.devel@lists.opensips.org>

Bugs item #3584278, was opened at 2012-11-05 10:07
Message generated for change (Tracker Item Submitted) made by ledda
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=3584278&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.8.x
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: ledda (ledda)
Assigned to: Nobody/Anonymous (nobody)
Summary: regression in snmpstats module

Initial Comment:
Unable to browse SNMP information.

snmpwalk -v 1 -c public 127.0.0.1 OPENSER-REG-MIB::openser
OPENSER-SIP-COMMON-MIB::openserSIPProtocolVersion.0 = STRING: SIP/2.0
Error in packet.
Reason: (genError) A general failure occured
Failed object: OPENSER-SIP-COMMON-MIB::openserSIPProtocolVersion.0

When the code changed back to the way how it was in v1.6.4 it works fine.


opensips-1.6.4-2-tls/modules/snmpstats/openserSIPCommonObjects.c
fgets(buffer, SNMPGET_MAX_BUFFER, theFile);

opensips-1.8.2-tls/modules/snmpstats/openserSIPCommonObjects.c
if (fgets(buffer, SNMPGET_MAX_BUFFER, theFile)==NULL)
			return SNMP_ERR_GENERR;


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

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


From noreply at sourceforge.net  Mon Nov  5 19:23:13 2012
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 05 Nov 2012 10:23:13 -0800
Subject: [OpenSIPS-Devel] [ opensips-Bugs-3584278 ] regression in snmpstats
	module
Message-ID: <mailman.1160.1352139801.13469.devel@lists.opensips.org>

Bugs item #3584278, was opened at 2012-11-05 10:07
Message generated for change (Settings changed) made by bogdan_iancu
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=3584278&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.8.x
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: ledda (ledda)
>Assigned to: Bogdan-Andrei Iancu (bogdan_iancu)
Summary: regression in snmpstats module

Initial Comment:
Unable to browse SNMP information.

snmpwalk -v 1 -c public 127.0.0.1 OPENSER-REG-MIB::openser
OPENSER-SIP-COMMON-MIB::openserSIPProtocolVersion.0 = STRING: SIP/2.0
Error in packet.
Reason: (genError) A general failure occured
Failed object: OPENSER-SIP-COMMON-MIB::openserSIPProtocolVersion.0

When the code changed back to the way how it was in v1.6.4 it works fine.


opensips-1.6.4-2-tls/modules/snmpstats/openserSIPCommonObjects.c
fgets(buffer, SNMPGET_MAX_BUFFER, theFile);

opensips-1.8.2-tls/modules/snmpstats/openserSIPCommonObjects.c
if (fgets(buffer, SNMPGET_MAX_BUFFER, theFile)==NULL)
			return SNMP_ERR_GENERR;


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

>Comment By: Bogdan-Andrei Iancu (bogdan_iancu)
Date: 2012-11-05 10:23

Message:
Hi Ledda,

According to man::

       gets() and fgets() return s on success, and NULL on error or  when 
end
       of file occurs while no characters have been read.

So, the test added on fgets seems to be valid to me. Now, the question is
if you have the file it tries to read from:
    /tmp/openSER_SNMPAgent.txt

Is there any valid data in there ?

Regards,
Bogdan

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

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


From bogdan at opensips.org  Mon Nov  5 19:48:57 2012
From: bogdan at opensips.org (Bogdan-Andrei Iancu)
Date: Mon, 05 Nov 2012 20:48:57 +0200
Subject: [OpenSIPS-Devel] [OpenSIPS-Users] [RELEASES] Planing OpenSIPS
 1.9.0 major release
In-Reply-To: <1F81E619-1DC7-49BC-BEE9-C15DE23C71C2@ag-projects.com>
References: <508AAA59.7070107@opensips.org>	<20049EB2-1E5C-438B-9F8A-CCF7566A2F46@ag-projects.com>	<508E564B.4060106@opensips.org>
	<AC1BB636-DC7E-4A06-913F-B446AE847A27@ag-projects.com>
	<509256BB.9090403@opensips.org>
	<1F81E619-1DC7-49BC-BEE9-C15DE23C71C2@ag-projects.com>
Message-ID: <50980A19.8030703@opensips.org>

Hi Dan,

I agree it is not a easy thing to do, neither bullet proofed, but the 
big question is : does it do more good than harm ? also, what are the 
other options we have here ?

Regards,

Bogdan-Andrei Iancu
OpenSIPS Founder and Developer
http://www.opensips-solutions.com


On 11/05/2012 05:57 PM, Dan Pascu wrote:
> On 1 Nov 2012, at 13:02, Bogdan-Andrei Iancu wrote:
>
>> Hi Dan,
>>
>> Well, as Ovidiu said, it is prone. BUT, this is not something particular to re-INVITE, but to whatever
>> in-dialog pinging you may have from a mid-proxy.
> I never said otherwise.
>
>> On the other hand, as Ryan pointed out here, the need to check the dialog health from proxy side, without relying on special end-UA features (like SST), is really critical.
> While it may be useful (I would not call it exactly critical), this doesn't mean that the implementation should introduce new issues. I'm not arguing against the idea of having a keep-alive mechanism here, but against particular implementations that introduce new issues.
>
>> So, I see two approaches:
>>     1) either simply live with the fact that races may occure and calls may be dropped during a re-INVITE, but at least is a clear drop /cut
> I'm not sure you can explain your customers that their calls are being dropped because you have a race condition in your implementation which you are willing to live with...
>
>>     2) theoretically we can try to address the race at dialog modules level : (a) If you have ongoing in-dialog transaction, do not do your ping ,
> This was never the issue. You can always avoid this.
>
>> (b) if you have an ongoing in-dialog ping and receive another in-dilog request from end point, try to delay it until your pinging is done.....
> This should work, but I don't see it working without a proper async reactor model. How do you plan to delay it, without blocking the worker?
>
> On another note, I also believe that a re-INVITE based keep-alive is also problematic because it has to implement the whole stream selection mechanism in the clients in order to know what streams to propose in the re-INVITE. Even so, triggering a SDP renegotiation every now and then is not very nice, regardless of it changing nothing in the streams.
>
> --
> Dan
>
>
>
>


From noreply at sourceforge.net  Mon Nov  5 19:49:33 2012
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 05 Nov 2012 10:49:33 -0800
Subject: [OpenSIPS-Devel] [ opensips-Bugs-3584278 ] regression in snmpstats
	module
Message-ID: <mailman.1161.1352141383.13469.devel@lists.opensips.org>

Bugs item #3584278, was opened at 2012-11-05 10:07
Message generated for change (Comment added) made by ledda
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=3584278&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.8.x
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: ledda (ledda)
Assigned to: Bogdan-Andrei Iancu (bogdan_iancu)
Summary: regression in snmpstats module

Initial Comment:
Unable to browse SNMP information.

snmpwalk -v 1 -c public 127.0.0.1 OPENSER-REG-MIB::openser
OPENSER-SIP-COMMON-MIB::openserSIPProtocolVersion.0 = STRING: SIP/2.0
Error in packet.
Reason: (genError) A general failure occured
Failed object: OPENSER-SIP-COMMON-MIB::openserSIPProtocolVersion.0

When the code changed back to the way how it was in v1.6.4 it works fine.


opensips-1.6.4-2-tls/modules/snmpstats/openserSIPCommonObjects.c
fgets(buffer, SNMPGET_MAX_BUFFER, theFile);

opensips-1.8.2-tls/modules/snmpstats/openserSIPCommonObjects.c
if (fgets(buffer, SNMPGET_MAX_BUFFER, theFile)==NULL)
			return SNMP_ERR_GENERR;


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

Comment By: ledda (ledda)
Date: 2012-11-05 10:49

Message:
The file exists. But it is zero size in both cases.

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

Comment By: Bogdan-Andrei Iancu (bogdan_iancu)
Date: 2012-11-05 10:23

Message:
Hi Ledda,

According to man::

       gets() and fgets() return s on success, and NULL on error or  when 
end
       of file occurs while no characters have been read.

So, the test added on fgets seems to be valid to me. Now, the question is
if you have the file it tries to read from:
    /tmp/openSER_SNMPAgent.txt

Is there any valid data in there ?

Regards,
Bogdan

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

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


From razvan at opensips.org  Mon Nov  5 19:58:54 2012
From: razvan at opensips.org (Razvan Crainea)
Date: Mon, 05 Nov 2012 18:58:54 +0000
Subject: [OpenSIPS-Devel] SF.net SVN: opensips:[9424] trunk/modules
Message-ID: <E1TVRss-0002jJ-8w@sfp-svn-3.v30.ch3.sourceforge.com>

Revision: 9424
          http://opensips.svn.sourceforge.net/opensips/?rev=9424&view=rev
Author:   razvancrainea
Date:     2012-11-05 18:58:53 +0000 (Mon, 05 Nov 2012)
Log Message:
-----------
Fixed exported parameter bug in event_* modules documentation

Modified Paths:
--------------
    trunk/modules/event_datagram/README
    trunk/modules/event_datagram/doc/event_datagram_admin.xml
    trunk/modules/event_rabbitmq/README
    trunk/modules/event_rabbitmq/doc/event_rabbitmq_admin.xml
    trunk/modules/event_xmlrpc/README
    trunk/modules/event_xmlrpc/doc/event_xmlrpc_admin.xml

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



From razvan at opensips.org  Mon Nov  5 20:01:08 2012
From: razvan at opensips.org (Razvan Crainea)
Date: Mon, 05 Nov 2012 19:01:08 +0000
Subject: [OpenSIPS-Devel] SF.net SVN: opensips:[9425] branches/1.8/modules
Message-ID: <E1TVRv2-0001pH-81@sfp-svn-4.v30.ch3.sourceforge.com>

Revision: 9425
          http://opensips.svn.sourceforge.net/opensips/?rev=9425&view=rev
Author:   razvancrainea
Date:     2012-11-05 19:01:07 +0000 (Mon, 05 Nov 2012)
Log Message:
-----------
Backported from trunk (rev# 9424):
Fixed exported parameter bug in event_* modules documentation

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

Modified Paths:
--------------
    branches/1.8/modules/event_datagram/README
    branches/1.8/modules/event_datagram/doc/event_datagram_admin.xml
    branches/1.8/modules/event_rabbitmq/README
    branches/1.8/modules/event_rabbitmq/doc/event_rabbitmq_admin.xml

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



From razvan at opensips.org  Mon Nov  5 20:11:41 2012
From: razvan at opensips.org (Razvan Crainea)
Date: Mon, 05 Nov 2012 19:11:41 +0000
Subject: [OpenSIPS-Devel] SF.net SVN: opensips:[9426]
	branches/1.7/modules/event_datagram
Message-ID: <E1TVS5E-0002iG-W1@sfp-svn-4.v30.ch3.sourceforge.com>

Revision: 9426
          http://opensips.svn.sourceforge.net/opensips/?rev=9426&view=rev
Author:   razvancrainea
Date:     2012-11-05 19:11:40 +0000 (Mon, 05 Nov 2012)
Log Message:
-----------
Backported from trunk (rev# 9424):
Fixed exported parameter bug in event_* modules documentation

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

Modified Paths:
--------------
    branches/1.7/modules/event_datagram/README
    branches/1.7/modules/event_datagram/doc/event_datagram_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  Mon Nov  5 21:42:15 2012
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 05 Nov 2012 12:42:15 -0800
Subject: [OpenSIPS-Devel] [ opensips-Bugs-3584278 ] regression in snmpstats
	module
Message-ID: <mailman.1162.1352148140.13469.devel@lists.opensips.org>

Bugs item #3584278, was opened at 2012-11-05 10:07
Message generated for change (Comment added) made by bogdan_iancu
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=3584278&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.8.x
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: ledda (ledda)
Assigned to: Bogdan-Andrei Iancu (bogdan_iancu)
Summary: regression in snmpstats module

Initial Comment:
Unable to browse SNMP information.

snmpwalk -v 1 -c public 127.0.0.1 OPENSER-REG-MIB::openser
OPENSER-SIP-COMMON-MIB::openserSIPProtocolVersion.0 = STRING: SIP/2.0
Error in packet.
Reason: (genError) A general failure occured
Failed object: OPENSER-SIP-COMMON-MIB::openserSIPProtocolVersion.0

When the code changed back to the way how it was in v1.6.4 it works fine.


opensips-1.6.4-2-tls/modules/snmpstats/openserSIPCommonObjects.c
fgets(buffer, SNMPGET_MAX_BUFFER, theFile);

opensips-1.8.2-tls/modules/snmpstats/openserSIPCommonObjects.c
if (fgets(buffer, SNMPGET_MAX_BUFFER, theFile)==NULL)
			return SNMP_ERR_GENERR;


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

>Comment By: Bogdan-Andrei Iancu (bogdan_iancu)
Date: 2012-11-05 12:42

Message:
So the code is correct and the problem may be related to the creation of
the file. Could you confirm the file has some content right after the
opensips start?

Thanks.

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

Comment By: ledda (ledda)
Date: 2012-11-05 10:49

Message:
The file exists. But it is zero size in both cases.

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

Comment By: Bogdan-Andrei Iancu (bogdan_iancu)
Date: 2012-11-05 10:23

Message:
Hi Ledda,

According to man::

       gets() and fgets() return s on success, and NULL on error or  when 
end
       of file occurs while no characters have been read.

So, the test added on fgets seems to be valid to me. Now, the question is
if you have the file it tries to read from:
    /tmp/openSER_SNMPAgent.txt

Is there any valid data in there ?

Regards,
Bogdan

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

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


From noreply at sourceforge.net  Mon Nov  5 23:04:35 2012
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 05 Nov 2012 14:04:35 -0800
Subject: [OpenSIPS-Devel] [ opensips-Bugs-3584278 ] regression in snmpstats
	module
Message-ID: <mailman.1163.1352153081.13469.devel@lists.opensips.org>

Bugs item #3584278, was opened at 2012-11-05 10:07
Message generated for change (Comment added) made by ledda
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=3584278&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.8.x
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: ledda (ledda)
Assigned to: Bogdan-Andrei Iancu (bogdan_iancu)
Summary: regression in snmpstats module

Initial Comment:
Unable to browse SNMP information.

snmpwalk -v 1 -c public 127.0.0.1 OPENSER-REG-MIB::openser
OPENSER-SIP-COMMON-MIB::openserSIPProtocolVersion.0 = STRING: SIP/2.0
Error in packet.
Reason: (genError) A general failure occured
Failed object: OPENSER-SIP-COMMON-MIB::openserSIPProtocolVersion.0

When the code changed back to the way how it was in v1.6.4 it works fine.


opensips-1.6.4-2-tls/modules/snmpstats/openserSIPCommonObjects.c
fgets(buffer, SNMPGET_MAX_BUFFER, theFile);

opensips-1.8.2-tls/modules/snmpstats/openserSIPCommonObjects.c
if (fgets(buffer, SNMPGET_MAX_BUFFER, theFile)==NULL)
			return SNMP_ERR_GENERR;


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

Comment By: ledda (ledda)
Date: 2012-11-05 14:04

Message:
The file /tmp/openSER_SNMPAgent.txt  exists, and it is empty.

I don't see any snmpget related errors in the logs.

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

Comment By: Bogdan-Andrei Iancu (bogdan_iancu)
Date: 2012-11-05 12:42

Message:
So the code is correct and the problem may be related to the creation of
the file. Could you confirm the file has some content right after the
opensips start?

Thanks.

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

Comment By: ledda (ledda)
Date: 2012-11-05 10:49

Message:
The file exists. But it is zero size in both cases.

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

Comment By: Bogdan-Andrei Iancu (bogdan_iancu)
Date: 2012-11-05 10:23

Message:
Hi Ledda,

According to man::

       gets() and fgets() return s on success, and NULL on error or  when 
end
       of file occurs while no characters have been read.

So, the test added on fgets seems to be valid to me. Now, the question is
if you have the file it tries to read from:
    /tmp/openSER_SNMPAgent.txt

Is there any valid data in there ?

Regards,
Bogdan

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

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


From rrb3942 at gmail.com  Tue Nov  6 09:49:50 2012
From: rrb3942 at gmail.com (Ryan Bullock)
Date: Tue, 6 Nov 2012 00:49:50 -0800
Subject: [OpenSIPS-Devel] [OpenSIPS-Users] [RELEASES] Planing OpenSIPS
 1.9.0 major release
In-Reply-To: <3E77CAA7-7714-4CFF-96ED-1CF3DB47C2E5@ag-projects.com>
References: <508AAA59.7070107@opensips.org>
	<20049EB2-1E5C-438B-9F8A-CCF7566A2F46@ag-projects.com>
	<508E564B.4060106@opensips.org>
	<AC1BB636-DC7E-4A06-913F-B446AE847A27@ag-projects.com>
	<CAND0LkvfFpEv5x+UvPwcogzPjMk7X7_xyAxhcsqsxQNGNbd3rQ@mail.gmail.com>
	<CAAcj4gUtXj15Pr4hMfrvG5q-7wKZvLjp8kaSjyxfkQqPKsYa5g@mail.gmail.com>
	<3E77CAA7-7714-4CFF-96ED-1CF3DB47C2E5@ag-projects.com>
Message-ID: <CAAcj4gVyRUHKRYUKeL18vFYE-FSNnx2C=7UWmfPtb-jgNJ2Caw@mail.gmail.com>

On Mon, Nov 5, 2012 at 7:40 AM, Dan Pascu <dan at ag-projects.com> wrote:

>
> On 31 Oct 2012, at 21:59, Ryan Bullock wrote:
>
> > These would make pinging a bit more complicated but may help avoid races:
> >
> > 1.  Have the ping aware of when the last INVITE was seen in the dialog
> (sent from anyone) and only issue its own re-INVITE if it has not seen an
> INVITE for X seconds in the dialog. Perhaps X could be a lower value if the
> previous re-INVITE had a negative reply (many clients locally end the call
> when they receive a negative reply to an INVITE, but may not issue a BYE).
> Add a little session timer awareness and you may be able to avoid most
> races.
>
> This will not solve anything. Client behavior is unpredictable from the
> server point of view. You cannot estimate when the client will send the
> next re-INVITE in order to avoid the race.
>
>
If session timers are negotiated for the call you actually do have an idea
of how often refresh should be seen. If the timer passes and no refresh has
occurred it should be a safe bet that the call is gone and it is safe to
check its status via a re-INVITE.

What might be nice is if you could use the SST module and set an absolute
duration on the call. I believe the SST module overwrites the dlg timeout
AVP values so you can use one or the other, but not both (someone please
correct me if I am wrong).

>
> > 2. Combine 1 with OPTIONS between INVITES. For example, send an OPTION
> ping every minute, but you also want to see a re-INVITE every 15 minutes.
> This could allow quick detection for clients that support OPTION properly
> and the re-INVITE would help detect dead calls when the client is a bit
> buggy.
>
> It doesn't matter if you send in-dialog OPTIONs or INVITEs. Two in-dialog
> requests cannot overlap, no matter if it's an OPTION or an INVITE. The
> issue is the same regardless of the method you use.
>

Nothing that I am aware of in the SIP RFC restricts parallel in-dialog
transactions. However, since INVITEs (an UPDATEs) can modify the dialog and
session information, it's hard to processes them in parallel. OPTIONs do
not modify the dialog or session and can be processed in parallel. So, by
sending OPTIONS frequently you get a cheaper, safer, but less reliable way
to check the dialog, and then on top of that you do INVITES infrequently
for those clients that don't always properly respond with a 481 for calls
that are gone.

In my opinion the worry about 'breaking' calls is moot, as these clients
are already broken and may have their calls terminated anyways if both
sides attempt re-INVITEs at the same time (I see this all the time). The
only difference is now, instead of Opensips leaving the call up forever
because neither side ever sent a BYE, Opensips would have a more reliable
method for checking if the call actually ended. This is needed to detect
when calls have ended because of the clients already broken behavior.

Currently the only other options are to use Opensips in conjunction with
rtpproxy/mediaproxy and to use media timeouts to determine when calls have
ended, but that's an awful heavy solution compared to re-INVITES.

Buggy implementations will always have problems, but you can only do so
much to work around them.

Regards,

Ryan


>
>
>
>
> _______________________________________________
> Devel mailing list
> Devel at lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/devel/attachments/20121106/a78a4c2b/attachment.htm>

From vladpaiu at opensips.org  Tue Nov  6 11:04:16 2012
From: vladpaiu at opensips.org (Vlad Paiu)
Date: Tue, 06 Nov 2012 10:04:16 +0000
Subject: [OpenSIPS-Devel] SF.net SVN: opensips:[9427]
	branches/1.7/modules/dialog
Message-ID: <E1TVg12-0008VC-Qh@sfp-svn-2.v30.ch3.sourceforge.com>

Revision: 9427
          http://opensips.svn.sourceforge.net/opensips/?rev=9427&view=rev
Author:   vladut-paiu
Date:     2012-11-06 10:04:16 +0000 (Tue, 06 Nov 2012)
Log Message:
-----------
backport from trunk (rev #9413)
	
match_dialog() is now able to do DID matching in the case of topology hiding

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

Modified Paths:
--------------
    branches/1.7/modules/dialog/dialog.c
    branches/1.7/modules/dialog/dlg_handlers.c

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



From noreply at sourceforge.net  Tue Nov  6 12:13:50 2012
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue, 06 Nov 2012 03:13:50 -0800
Subject: [OpenSIPS-Devel] [ opensips-Bugs-3584714 ] RTP Traffic Sent to
	wrong destination
Message-ID: <mailman.1164.1352200444.13469.devel@lists.opensips.org>

Bugs item #3584714, was opened at 2012-11-06 03:13
Message generated for change (Tracker Item Submitted) made by apsaras
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=3584714&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.8.x
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: apsaras (apsaras)
Assigned to: Nobody/Anonymous (nobody)
Summary: RTP Traffic Sent to wrong destination

Initial Comment:
During the negotiation with a carrier SBC where SIP and RTP are running on different IPs, I found out that in some cases - unknown when - the RTP traffic is sent to SIP IP and not to RTP IP. We run 4 RTP Proxies one for each core in order to maximize performance but even if we use just one of them, the problem remains.

That is the initial INVITE sent from our Proxy to the Carrier

INVITE sip:4303030211176XXXX at 194.XXX.XXX.66 SIP/2.0
Record-Route: <sip:91.XXX.XXX.90;lr;nat=yes;did=716.b4738932>
Via: SIP/2.0/UDP 91.XXX.XXX.90;branch=z9hG4bK7e46.ec664a53.0
Max-Forwards: 69
From: "asterisk" <sip:asterisk at 91.XXX.XXX.90>;tag=as0b2df024
To: <sip:30211176XXXX at 91.XXX.XXX.90>
Contact: <sip:91.XXX.XXX.90;did=716.b4738932>
Call-ID: 36cbb21129aa50d82ebaef9764ca8c23 at 192.168.1.15
CSeq: 102 INVITE
User-Agent: OpenSIPs
Privacy: id;header;user
P-Asserted-Identity:  <sip:0 at 91.XXX.XXX.90>
Date: Tue, 06 Nov 2012 10:52:03 GMT
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO
Supported: replaces, timer
Content-Type: application/sdp
Content-Length: 287

v=0
o=root 2009131870 2009131870 IN IP4 91.XXX.XXX.90
s=OpenSIPs
c=IN IP4 91.XXX.XXX.90
t=0 0
m=audio 14034 RTP/AVP 18 101
a=rtpmap:18 G729/8000
a=fmtp:18 annexb=no
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=ptime:20
a=sendrecv
a=direction:active
a=sdpmangled:yes

and this is the OK sent from Carrier

SIP/2.0 200 OK
Session-Expires: 3600;refresher=uas
Require: timer
Via: SIP/2.0/UDP 91.XXX.XXX.90;branch=z9hG4bK7e46.ec664a53.0
Record-Route: <sip:91.XXX.XXX.90;lr;nat=yes;did=716.b4738932>
To: <sip:30211176XXXX at 91.XXX.XXX.90>;tag=3561187924-714596
From: "asterisk" <sip:asterisk at 91.XXX.XXX.90>;tag=as0b2df024
Call-ID: 36cbb21129aa50d82ebaef9764ca8c23 at 192.168.1.15
CSeq: 102 INVITE
Allow: INVITE, BYE, OPTIONS, CANCEL, ACK, REGISTER, NOTIFY, INFO, REFER, SUBSCRIBE, PRACK, UPDATE, MESSAGE, PUBLISH
Contact: <sip:4303030211176XXXX at 194.XXX.XXX.66:5060>
Call-Info: <sip:194.XXX.XXX.66>;method="NOTIFY;Event=telephone-event;Duration=1000"
Content-Type: application/sdp
Content-Length: 333

v=0
o=root 188 1 IN IP4 194.XXX.XXX.66
s=sip call
c=IN IP4 194.XXX.XXX.76
t=0 0
m=audio 44924 RTP/AVP 18 101
a=rtpmap:18 G729/8000
a=fmtp:18 annexb=no
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
a=ptime:20
a=X-vrzcap:vbd Ver=0 Mode=FaxPr ModemRtpRed=0
a=X-vrzcap:identification bin=DSR1e814 Prot=mgcp App=MG

But RTP traffic sent to .66 instead of .76

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

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


From flavio at asteriskguide.com  Tue Nov  6 12:17:25 2012
From: flavio at asteriskguide.com (Flavio Goncalves)
Date: Tue, 6 Nov 2012 09:17:25 -0200
Subject: [OpenSIPS-Devel] [OpenSIPS-Users] [RELEASES] Planing OpenSIPS
	1.9.0 major release
In-Reply-To: <508AAA59.7070107@opensips.org>
References: <508AAA59.7070107@opensips.org>
Message-ID: <CAJkFROwtVeQH0uaRvt1QJeHhaA2sKcde0mj4hCjuKmpkH=w6xw@mail.gmail.com>

Hi Bogdan,

I would have two suggestions for the next releases.

1. Support for attended transfers on B2BUA
2. Support for the RFC6140 Registration for Multiple Phone Numbers in
the Session Initiation Protocol (SIP) (Part of the SIpConnect 1.1
specification).

Flavio E. Goncalves
CEO - SipPulse



2012/10/26 Bogdan-Andrei Iancu <bogdan at opensips.org>:
> Hi all,
>
> I would like to start a discussion about the next OpenSIPS major release -
> and in this discussion anyone is welcomed with options, ideas, critics and
> other. Your feedback is important to drive the project into a direction that
> reflects the user's needs!.
>
> So, I will here the starting points, for both release planing and release
> content.
>
>
> Content
> -------
> What was done:
>         http://www.opensips.org/Main/Ver190#toc2
> What is planned:
>         http://www.opensips.org/Main/Ver190#toc9
> Planned items have priorities (for being addressed); it is a must to have
> all items done for the next release, as we need to fit into a time frame.
> Whatever is not done, will be left for the next release (1.10)
>
>
> Planing
> -------
> Release candidate:
>     second half of January 2012, depending on the progress with the items to
> be done.
> Testing phase:
>     1 month allocated (it may be extended if critical problems show up)
> Stable release:
>     second half of February (after the testing phase is done).
>
>
> Once again, your feedback on these matters is important to us.
>
>
> Best regards,
>
> --
> Bogdan-Andrei Iancu
> OpenSIPS Founder and Developer
> http://www.opensips-solutions.com
>
>
> _______________________________________________
> Users mailing list
> Users at lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users


From vladpaiu at opensips.org  Tue Nov  6 13:57:46 2012
From: vladpaiu at opensips.org (Vlad Paiu)
Date: Tue, 06 Nov 2012 12:57:46 +0000
Subject: [OpenSIPS-Devel] SF.net SVN: opensips:[9428]
	trunk/modules/dialog/dlg_db_handler.c
Message-ID: <E1TViiw-0002hC-97@sfp-svn-3.v30.ch3.sourceforge.com>

Revision: 9428
          http://opensips.svn.sourceforge.net/opensips/?rev=9428&view=rev
Author:   vladut-paiu
Date:     2012-11-06 12:57:45 +0000 (Tue, 06 Nov 2012)
Log Message:
-----------
removed timer debugging polluting the logs ( introduced with the previous dlg enhancements )

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

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



From noreply at sourceforge.net  Tue Nov  6 14:36:55 2012
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue, 06 Nov 2012 05:36:55 -0800
Subject: [OpenSIPS-Devel] [ opensips-Bugs-3581600 ] TLS: "failed to accept:
	rejected by client"
Message-ID: <mailman.1165.1352209024.13469.devel@lists.opensips.org>

Bugs item #3581600, was opened at 2012-10-29 04:56
Message generated for change (Comment added) made by dragosoancea
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=3581600&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.8.x
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Dragos Oancea (dragosoancea)
Assigned to: Nobody/Anonymous (nobody)
Summary: TLS:  "failed to accept: rejected by client"

Initial Comment:
Hi

There is a weird behaviour in opensips-tls. It happened to me a 4 or 5 times in the last 3 months.
Sometimes I get a lot of messages like this in the logs:
"ERROR:core:tls_accept: New TLS connection from ip:port failed to accept: rejected by client"
This usually means that some TLS client which is not under my control is hammering on the SSL port, never completing a full SSL/TLS handshake. 
But whithin few minutes after these appear, nothing works on opensips anymore, you send an INVITE and it does not get relay-ed, nothing hapends , it's just stuck. Then I firewall the IP from where the connection requests come from, and everything starts to work fine again.


Regards,
Dragos

PS: Vlad, thx for fixing bug #3570495. It does not crash anymore. 

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

>Comment By: Dragos Oancea (dragosoancea)
Date: 2012-11-06 05:36

Message:
Hi 

If I run this against my opensips-1.8.2-tls it will stop relay-ing INIVITEs
after less than 1 minute:

-------
#!/bin/bash 

count=1
while [[ $count -le 1000 ]]
do
    echo "$count"
    echo "giberish" | nc X.X.X.X 5061     
    sleep 1
    (( count++ ))       

done
-------

I have:
open_files_limit=81920
tcp_max_connections=40960

It happens under VMWare with only two registered TLS clients on a test box.


Regards,
Dragos

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

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


From noreply at sourceforge.net  Tue Nov  6 14:40:15 2012
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue, 06 Nov 2012 05:40:15 -0800
Subject: [OpenSIPS-Devel] [ opensips-Bugs-3576351 ] sip_trace module bug
Message-ID: <mailman.1166.1352209223.13469.devel@lists.opensips.org>

Bugs item #3576351, was opened at 2012-10-11 07:53
Message generated for change (Comment added) made by dragosoancea
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=3576351&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.8.x
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Dragos Oancea (dragosoancea)
Assigned to: Bogdan-Andrei Iancu (bogdan_iancu)
Summary: sip_trace module bug

Initial Comment:
Hi

The siptrace module reports a wrong value in the `fromip` field of the sip_trace table. 

For example , for this INVITE, coming from tls:80.187.x.x:62510 , I would expect the value "tls:80.187.x.x:62510" to be added in the `fromip` field,
but it's adding "tls:80.187.x.x:625" instead . It's missing two digits from the port value.
Also , sometimes it would put its local port (in my case 5061) instead of the remote port in the `fromip` or `toip` fields.


INVITE sips:+49170738xxxx at sip.domain.com SIP/2.0
Call-Id: c64e6615c79ab23501ad13f2e1a58918 at 10.77.26.75
CSeq: 1 INVITE
Via: SIP/2.0/TLS 10.77.26.75:59076;branch=z9hG4bK127109c14cd3b59c9ef9909b737982ab
Max-Forwards: 70
From: "+491713xxxxx" <sips:username at sip.domain.com>;tag=yRkyOWfbq
To: <sips:+4917073xxxxx at sip.domain.com>
Contact: <sips:00xxxx at 80.187.x.x:62510;transport=tls>
Allow: ACK,BYE
User-Agent: SomeUserAgent
Content-Type: application/sdp
Content-Length: 138

v=0
o=- 1349965870484 1349965870484 IN IP4 10.77.26.75
s=-
c=IN IP4 10.77.26.75
t=0 0
m=audio 37566 RTP/AVP 0
a=rtpmap:0 PCMU/8000



The problem was observed with opensips 1.8.1-tls and opensips-1.7.2-tls . 

Cheers,
Dragos



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

>Comment By: Dragos Oancea (dragosoancea)
Date: 2012-11-06 05:40

Message:
will do. but funny thing , I did not see the problem again in the last
week... I'm running the absolutely same opensips binary and config as when
it happened. 

Regards,
Dragos

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

Comment By: Razvan Crainea (razvancrainea)
Date: 2012-10-31 08:26

Message:
Hi!

I've attached a patch that disables the Prepared Statements. Please apply
it and check if you still find any bogus fields in your db.

Regards,
R?zvan

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

Comment By: David Sanders (dmsanders)
Date: 2012-10-22 08:52

Message:
I believe it occurs for both requests and replies for me as well.

- David

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

Comment By: Dragos Oancea (dragosoancea)
Date: 2012-10-22 08:17

Message:
I see the error for `fromip` , direction `in`  for both requests and
replies. 22 characters.
I never saw a space in that field, but maybe my IPs are longer.

Cheers,
Dragos

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

Comment By: Bogdan-Andrei Iancu (bogdan_iancu)
Date: 2012-10-20 01:00

Message:
What about the type of SIP requests - do you see the err for requests or
for replies (or both ?) ?

Regards,
Bogdan

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

Comment By: David Sanders (dmsanders)
Date: 2012-10-19 16:24

Message:
I only see it occurring on direction = 'in'.

In addition, it only affects the fromip field. It seems to be truncated to
22 characters.

If there is a space in the port number it is only if the fromip was less
than 22 characters. For example "udp:xx.xxx.x.xx:5060 1" is a pattern I see
a lot. 1 seems to be the most common extra character, but I also see 0, 4,
7, 9, etc.

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

Comment By: Bogdan-Andrei Iancu (bogdan_iancu)
Date: 2012-10-19 09:08

Message:
Ok, last question - have you noticed a pattern on what kind of records have
bogus port values ? like request, in or out, ? or maybe for replies ? It
will help me to dig into the right code.

Regards,
Bogdan

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

Comment By: David Sanders (dmsanders)
Date: 2012-10-19 00:31

Message:
I've also encountered this issue as described, with opensips 1.8.0-tls.

In addition to the described case, I've seen times where the field will
look like "sip:80.187.x.x:625 1", with a space present in the port number.
This seems to suggest it isn't truncation.

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

Comment By: Dragos Oancea (dragosoancea)
Date: 2012-10-17 01:35

Message:
Hi Bogdan,

No , I am not using that feature.

Regards,
Dragos

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

Comment By: Bogdan-Andrei Iancu (bogdan_iancu)
Date: 2012-10-16 10:40

Message:
Are you using buffering and merging for multiple INSERTs ?
      http://www.opensips.org/Resources/DocsCoreFcn18#toc69

Regards,
Bogdan

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

Comment By: Dragos Oancea (dragosoancea)
Date: 2012-10-15 05:32

Message:

mysql> desc sip_trace ;
+-------------+------------------+------+-----+---------------------+----------------+
| Field       | Type             | Null | Key | Default             | Extra
         |
+-------------+------------------+------+-----+---------------------+----------------+
| id          | int(10) unsigned | NO   | PRI | NULL                |
auto_increment |
| date        | datetime         | NO   | MUL | 1900-01-01 00:00:01 |      
         |
| callid      | varchar(255)     | NO   | MUL |                     |      
         |
| traced_user | varchar(128)     | NO   | MUL |                     |      
         |
| msg         | text             | NO   |     | NULL                |      
         |
| method      | varchar(50)      | NO   |     |                     |      
         |
| status      | varchar(128)     | NO   |     |                     |      
         |
| fromip      | varchar(50)      | NO   | MUL |                     |      
         |
| toip        | varchar(50)      | NO   |     |                     |      
         |
| fromtag     | varchar(64)      | NO   |     |                     |      
         |
| direction   | varchar(4)       | NO   |     |                     |      
         |
| time_stamp  | timestamp        | NO   |     | CURRENT_TIMESTAMP   |      
         |
+-------------+------------------+------+-----+---------------------+----------------+
12 rows in set (0.01 sec)

They are varchar(50) , there should be enough space.
Also , sometimes the same ip:port pair is inserted correctly - for example
it could we wrong for the received INVITE, but it could be correct for the
relayed BYE .

 


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

Comment By: Bogdan-Andrei Iancu (bogdan_iancu)
Date: 2012-10-15 05:04

Message:
Could you check the table format ? Do "desc siptrace" and see what are the
sizes of the fromip and toip fields in the table - maybe the truncating is
done by db.

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

Comment By: Dragos Oancea (dragosoancea)
Date: 2012-10-15 04:27

Message:
Hi Bogdan,


INVITE sips:+4917133xxxxx at sip.domain.com SIP/2.0
Call-Id: 6484f90259156c8d702a1cae0eb49f27 at 10.208.83.156
CSeq: 1 INVITE
Via: SIP/2.0/TLS
10.208.83.156:53912;branch=z9hG4bK2929012bef3d8abb931df26bd8fa498c
Max-Forwards: 70
From: "+4917073xxxxx" <sips:xxxxx at sis.secusmart.com>;tag=IhJICbbyh
To: <sips:+4917133xxxxx at sip.domain.com>
Contact: <sips:xxxxxx at 80.187.x.x:52316;transport=tls>
Allow: ACK,BYE
User-Agent: SomeUserAgent
Content-Type: application/sdp
Content-Length: 142

v=0
o=- 1350298945023 1350298945023 IN IP4 10.208.83.156
s=-
c=IN IP4 10.208.83.156
t=0 0
m=audio 58639 RTP/AVP 0
a=rtpmap:0 PCMU/8000

| INVITE   |        | tls:80.187.x.x:5231 | tls:212.162.x.x:5061   |
IhJICbbyh | in        | 2012-10-15 13:02:24 |



CRITICAL:siptrace:sip_trace: xXx to ip is [tls:212.162.x.x:5061]
CRITICAL:siptrace:sip_trace: xXx from ip is [tls:80.187.x.x:52316]


The log entries (printed with the patch you provided) look correct, the
`fromip` and `toip` fields are showing truncated values in the sip_trace
table for most of the request and replies.

Cheers,
Dragos


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

Comment By: Bogdan-Andrei Iancu (bogdan_iancu)
Date: 2012-10-12 06:30

Message:
Dragos, apply this patch -> it will print to logs (on critical level) the
calculated FROMIP and TOIP values. When you find bogus entries in siptrace,
you can try to correlate with the log to see if the values from logs are
also truncated.

Thanks and regards,
Bogdan

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

Comment By: Dragos Oancea (dragosoancea)
Date: 2012-10-12 04:51

Message:
Hi

Yes, it happens very often,I don't know why . Sometime it puts the correct
values into the fields (for messages within the same dialog I could see
some entries  -requests or replies - added with the correct port , but 
some are missing one or two digits ),

If you provide the patch I'll apply it.

Cheers,
Dragos

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

Comment By: Bogdan-Andrei Iancu (bogdan_iancu)
Date: 2012-10-12 04:22

Message:
Can you reproduce that? if so, I will provide a small patch to print some
extra logs - the idea is to see if the truncation comes from the siptrace
or the mysql module 

Regards,
Bogdan

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

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


From noreply at sourceforge.net  Tue Nov  6 15:21:07 2012
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue, 06 Nov 2012 06:21:07 -0800
Subject: [OpenSIPS-Devel] [ opensips-Bugs-3581600 ] TLS: "failed to accept:
	rejected by client"
Message-ID: <mailman.1167.1352211674.13469.devel@lists.opensips.org>

Bugs item #3581600, was opened at 2012-10-29 04:56
Message generated for change (Comment added) made by dragosoancea
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=3581600&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.8.x
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Dragos Oancea (dragosoancea)
Assigned to: Nobody/Anonymous (nobody)
Summary: TLS:  "failed to accept: rejected by client"

Initial Comment:
Hi

There is a weird behaviour in opensips-tls. It happened to me a 4 or 5 times in the last 3 months.
Sometimes I get a lot of messages like this in the logs:
"ERROR:core:tls_accept: New TLS connection from ip:port failed to accept: rejected by client"
This usually means that some TLS client which is not under my control is hammering on the SSL port, never completing a full SSL/TLS handshake. 
But whithin few minutes after these appear, nothing works on opensips anymore, you send an INVITE and it does not get relay-ed, nothing hapends , it's just stuck. Then I firewall the IP from where the connection requests come from, and everything starts to work fine again.


Regards,
Dragos

PS: Vlad, thx for fixing bug #3570495. It does not crash anymore. 

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

>Comment By: Dragos Oancea (dragosoancea)
Date: 2012-11-06 06:21

Message:
Hi

Some more info: 

After opening 10 ssl connections and sending junk instead of an SSL
handshake, things start to go wrong. 
A legitimate TLS client  (already REGISTERed) would try to send an INVITE. 
This is what opensips shows in the logs instead  of just relay-ing the
INVITE :

Nov  6 15:05:10 [25062] DBG:core:send2child: to tcp child 0 0(25030),
0x7f39127846c0
Nov  6 15:05:10 [25030] DBG:core:handle_io: received n=8
con=0x7f39127846c0, fd=27
Nov  6 15:05:10 [25030] DBG:core:io_watch_add: io_watch_add(0x74a0a0, 27,
2, 0x7f39127846c0), fd_no=1
Nov  6 15:05:10 [25030] DBG:core:tls_update_fd: New fd is 27
Nov  6 15:05:10 [25030] ERROR:core:_tls_read: TLS connection to
80.187.x.x:39337 read failed
Nov  6 15:05:10 [25030] ERROR:core:_tls_read: TLS read error: 1
Nov  6 15:05:10 [25030] ERROR:core:tls_print_errstack: TLS errstack:
error:1408F10B:SSL routines:SSL3_GET_RECORD:wrong version number
Nov  6 15:05:10 [25030] ERROR:core:tcp_read_req: failed to read 
Nov  6 15:05:10 [25030] DBG:core:io_watch_del: io_watch_del (0x74a0a0, 27,
-1, 0x10) fd_no=2 called
Nov  6 15:05:10 [25030] DBG:core:release_tcpconn:  releasing con
0x7f39127846c0, state -2, fd=27, id=1343
Nov  6 15:05:10 [25030] DBG:core:release_tcpconn:  extra_data
0x7f39127f0010
Nov  6 15:05:10 [25062] DBG:core:handle_tcp_child: reader response=
7f39127846c0, -2 from 0 
Nov  6 15:05:10 [25062] DBG:core:tcpconn_destroy: destroying connection
0x7f39127846c0, flags 0002
Nov  6 15:05:10 [25062] DBG:core:tls_close: closing TLS connection
Nov  6 15:05:10 [25062] DBG:core:tls_update_fd: New fd is 83
Nov  6 15:05:10 [25062] DBG:core:tls_shutdown: first phase of 2-way
handshake completed succesfuly
Nov  6 15:05:10 [25062] DBG:core:tls_tcpconn_clean: entered

Looks like the TCP/TLS connection gets closed. Why ? It's the same client
that completed the SSL handshake and it was registered just before this
"attack" . The problem is easily reproduce-able with the small bash script
in my previous comment.  

Regards,
Dragos  

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

Comment By: Dragos Oancea (dragosoancea)
Date: 2012-11-06 05:36

Message:
Hi 

If I run this against my opensips-1.8.2-tls it will stop relay-ing INIVITEs
after less than 1 minute:

-------
#!/bin/bash 

count=1
while [[ $count -le 1000 ]]
do
    echo "$count"
    echo "giberish" | nc X.X.X.X 5061     
    sleep 1
    (( count++ ))       

done
-------

I have:
open_files_limit=81920
tcp_max_connections=40960

It happens under VMWare with only two registered TLS clients on a test box.


Regards,
Dragos

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

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


From noreply at sourceforge.net  Tue Nov  6 17:02:34 2012
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue, 06 Nov 2012 08:02:34 -0800
Subject: [OpenSIPS-Devel] [ opensips-Bugs-3584714 ] RTP Traffic Sent to
	wrong destination
Message-ID: <mailman.1168.1352217763.13469.devel@lists.opensips.org>

Bugs item #3584714, was opened at 2012-11-06 03:13
Message generated for change (Comment added) made by apsaras
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=3584714&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.8.x
>Status: Closed
Resolution: None
Priority: 5
Private: No
Submitted By: apsaras (apsaras)
Assigned to: Nobody/Anonymous (nobody)
Summary: RTP Traffic Sent to wrong destination

Initial Comment:
During the negotiation with a carrier SBC where SIP and RTP are running on different IPs, I found out that in some cases - unknown when - the RTP traffic is sent to SIP IP and not to RTP IP. We run 4 RTP Proxies one for each core in order to maximize performance but even if we use just one of them, the problem remains.

That is the initial INVITE sent from our Proxy to the Carrier

INVITE sip:4303030211176XXXX at 194.XXX.XXX.66 SIP/2.0
Record-Route: <sip:91.XXX.XXX.90;lr;nat=yes;did=716.b4738932>
Via: SIP/2.0/UDP 91.XXX.XXX.90;branch=z9hG4bK7e46.ec664a53.0
Max-Forwards: 69
From: "asterisk" <sip:asterisk at 91.XXX.XXX.90>;tag=as0b2df024
To: <sip:30211176XXXX at 91.XXX.XXX.90>
Contact: <sip:91.XXX.XXX.90;did=716.b4738932>
Call-ID: 36cbb21129aa50d82ebaef9764ca8c23 at 192.168.1.15
CSeq: 102 INVITE
User-Agent: OpenSIPs
Privacy: id;header;user
P-Asserted-Identity:  <sip:0 at 91.XXX.XXX.90>
Date: Tue, 06 Nov 2012 10:52:03 GMT
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO
Supported: replaces, timer
Content-Type: application/sdp
Content-Length: 287

v=0
o=root 2009131870 2009131870 IN IP4 91.XXX.XXX.90
s=OpenSIPs
c=IN IP4 91.XXX.XXX.90
t=0 0
m=audio 14034 RTP/AVP 18 101
a=rtpmap:18 G729/8000
a=fmtp:18 annexb=no
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=ptime:20
a=sendrecv
a=direction:active
a=sdpmangled:yes

and this is the OK sent from Carrier

SIP/2.0 200 OK
Session-Expires: 3600;refresher=uas
Require: timer
Via: SIP/2.0/UDP 91.XXX.XXX.90;branch=z9hG4bK7e46.ec664a53.0
Record-Route: <sip:91.XXX.XXX.90;lr;nat=yes;did=716.b4738932>
To: <sip:30211176XXXX at 91.XXX.XXX.90>;tag=3561187924-714596
From: "asterisk" <sip:asterisk at 91.XXX.XXX.90>;tag=as0b2df024
Call-ID: 36cbb21129aa50d82ebaef9764ca8c23 at 192.168.1.15
CSeq: 102 INVITE
Allow: INVITE, BYE, OPTIONS, CANCEL, ACK, REGISTER, NOTIFY, INFO, REFER, SUBSCRIBE, PRACK, UPDATE, MESSAGE, PUBLISH
Contact: <sip:4303030211176XXXX at 194.XXX.XXX.66:5060>
Call-Info: <sip:194.XXX.XXX.66>;method="NOTIFY;Event=telephone-event;Duration=1000"
Content-Type: application/sdp
Content-Length: 333

v=0
o=root 188 1 IN IP4 194.XXX.XXX.66
s=sip call
c=IN IP4 194.XXX.XXX.76
t=0 0
m=audio 44924 RTP/AVP 18 101
a=rtpmap:18 G729/8000
a=fmtp:18 annexb=no
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
a=ptime:20
a=X-vrzcap:vbd Ver=0 Mode=FaxPr ModemRtpRed=0
a=X-vrzcap:identification bin=DSR1e814 Prot=mgcp App=MG

But RTP traffic sent to .66 instead of .76

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

>Comment By: apsaras (apsaras)
Date: 2012-11-06 08:02

Message:
Problem solved.

Need to put r flag to engage_rtp_proxy command.

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

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


From noreply at sourceforge.net  Tue Nov  6 17:08:29 2012
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue, 06 Nov 2012 08:08:29 -0800
Subject: [OpenSIPS-Devel] [ opensips-Bugs-3584714 ] RTP Traffic Sent to
	wrong destination
Message-ID: <mailman.1169.1352218113.13469.devel@lists.opensips.org>

Bugs item #3584714, was opened at 2012-11-06 03:13
Message generated for change (Comment added) made by bogdan_iancu
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=3584714&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.8.x
>Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: apsaras (apsaras)
Assigned to: Nobody/Anonymous (nobody)
Summary: RTP Traffic Sent to wrong destination

Initial Comment:
During the negotiation with a carrier SBC where SIP and RTP are running on different IPs, I found out that in some cases - unknown when - the RTP traffic is sent to SIP IP and not to RTP IP. We run 4 RTP Proxies one for each core in order to maximize performance but even if we use just one of them, the problem remains.

That is the initial INVITE sent from our Proxy to the Carrier

INVITE sip:4303030211176XXXX at 194.XXX.XXX.66 SIP/2.0
Record-Route: <sip:91.XXX.XXX.90;lr;nat=yes;did=716.b4738932>
Via: SIP/2.0/UDP 91.XXX.XXX.90;branch=z9hG4bK7e46.ec664a53.0
Max-Forwards: 69
From: "asterisk" <sip:asterisk at 91.XXX.XXX.90>;tag=as0b2df024
To: <sip:30211176XXXX at 91.XXX.XXX.90>
Contact: <sip:91.XXX.XXX.90;did=716.b4738932>
Call-ID: 36cbb21129aa50d82ebaef9764ca8c23 at 192.168.1.15
CSeq: 102 INVITE
User-Agent: OpenSIPs
Privacy: id;header;user
P-Asserted-Identity:  <sip:0 at 91.XXX.XXX.90>
Date: Tue, 06 Nov 2012 10:52:03 GMT
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO
Supported: replaces, timer
Content-Type: application/sdp
Content-Length: 287

v=0
o=root 2009131870 2009131870 IN IP4 91.XXX.XXX.90
s=OpenSIPs
c=IN IP4 91.XXX.XXX.90
t=0 0
m=audio 14034 RTP/AVP 18 101
a=rtpmap:18 G729/8000
a=fmtp:18 annexb=no
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=ptime:20
a=sendrecv
a=direction:active
a=sdpmangled:yes

and this is the OK sent from Carrier

SIP/2.0 200 OK
Session-Expires: 3600;refresher=uas
Require: timer
Via: SIP/2.0/UDP 91.XXX.XXX.90;branch=z9hG4bK7e46.ec664a53.0
Record-Route: <sip:91.XXX.XXX.90;lr;nat=yes;did=716.b4738932>
To: <sip:30211176XXXX at 91.XXX.XXX.90>;tag=3561187924-714596
From: "asterisk" <sip:asterisk at 91.XXX.XXX.90>;tag=as0b2df024
Call-ID: 36cbb21129aa50d82ebaef9764ca8c23 at 192.168.1.15
CSeq: 102 INVITE
Allow: INVITE, BYE, OPTIONS, CANCEL, ACK, REGISTER, NOTIFY, INFO, REFER, SUBSCRIBE, PRACK, UPDATE, MESSAGE, PUBLISH
Contact: <sip:4303030211176XXXX at 194.XXX.XXX.66:5060>
Call-Info: <sip:194.XXX.XXX.66>;method="NOTIFY;Event=telephone-event;Duration=1000"
Content-Type: application/sdp
Content-Length: 333

v=0
o=root 188 1 IN IP4 194.XXX.XXX.66
s=sip call
c=IN IP4 194.XXX.XXX.76
t=0 0
m=audio 44924 RTP/AVP 18 101
a=rtpmap:18 G729/8000
a=fmtp:18 annexb=no
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
a=ptime:20
a=X-vrzcap:vbd Ver=0 Mode=FaxPr ModemRtpRed=0
a=X-vrzcap:identification bin=DSR1e814 Prot=mgcp App=MG

But RTP traffic sent to .66 instead of .76

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

>Comment By: Bogdan-Andrei Iancu (bogdan_iancu)
Date: 2012-11-06 08:08

Message:
Hi,

Hard to tell without knowing:
   what flags do you pass to rtpproxy_xxxx() 
   a full capture of RTP received on that call - rtpproxy learns
destination based on the incoming traffic.

Regards,
Bogdan

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

Comment By: apsaras (apsaras)
Date: 2012-11-06 08:02

Message:
Problem solved.

Need to put r flag to engage_rtp_proxy command.

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

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


From noreply at sourceforge.net  Tue Nov  6 17:09:14 2012
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue, 06 Nov 2012 08:09:14 -0800
Subject: [OpenSIPS-Devel] [ opensips-Bugs-3584714 ] RTP Traffic Sent to
	wrong destination
Message-ID: <mailman.1170.1352218163.13469.devel@lists.opensips.org>

Bugs item #3584714, was opened at 2012-11-06 03:13
Message generated for change (Comment added) made by bogdan_iancu
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=3584714&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.8.x
>Status: Closed
>Resolution: Invalid
Priority: 5
Private: No
Submitted By: apsaras (apsaras)
Assigned to: Nobody/Anonymous (nobody)
Summary: RTP Traffic Sent to wrong destination

Initial Comment:
During the negotiation with a carrier SBC where SIP and RTP are running on different IPs, I found out that in some cases - unknown when - the RTP traffic is sent to SIP IP and not to RTP IP. We run 4 RTP Proxies one for each core in order to maximize performance but even if we use just one of them, the problem remains.

That is the initial INVITE sent from our Proxy to the Carrier

INVITE sip:4303030211176XXXX at 194.XXX.XXX.66 SIP/2.0
Record-Route: <sip:91.XXX.XXX.90;lr;nat=yes;did=716.b4738932>
Via: SIP/2.0/UDP 91.XXX.XXX.90;branch=z9hG4bK7e46.ec664a53.0
Max-Forwards: 69
From: "asterisk" <sip:asterisk at 91.XXX.XXX.90>;tag=as0b2df024
To: <sip:30211176XXXX at 91.XXX.XXX.90>
Contact: <sip:91.XXX.XXX.90;did=716.b4738932>
Call-ID: 36cbb21129aa50d82ebaef9764ca8c23 at 192.168.1.15
CSeq: 102 INVITE
User-Agent: OpenSIPs
Privacy: id;header;user
P-Asserted-Identity:  <sip:0 at 91.XXX.XXX.90>
Date: Tue, 06 Nov 2012 10:52:03 GMT
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO
Supported: replaces, timer
Content-Type: application/sdp
Content-Length: 287

v=0
o=root 2009131870 2009131870 IN IP4 91.XXX.XXX.90
s=OpenSIPs
c=IN IP4 91.XXX.XXX.90
t=0 0
m=audio 14034 RTP/AVP 18 101
a=rtpmap:18 G729/8000
a=fmtp:18 annexb=no
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=ptime:20
a=sendrecv
a=direction:active
a=sdpmangled:yes

and this is the OK sent from Carrier

SIP/2.0 200 OK
Session-Expires: 3600;refresher=uas
Require: timer
Via: SIP/2.0/UDP 91.XXX.XXX.90;branch=z9hG4bK7e46.ec664a53.0
Record-Route: <sip:91.XXX.XXX.90;lr;nat=yes;did=716.b4738932>
To: <sip:30211176XXXX at 91.XXX.XXX.90>;tag=3561187924-714596
From: "asterisk" <sip:asterisk at 91.XXX.XXX.90>;tag=as0b2df024
Call-ID: 36cbb21129aa50d82ebaef9764ca8c23 at 192.168.1.15
CSeq: 102 INVITE
Allow: INVITE, BYE, OPTIONS, CANCEL, ACK, REGISTER, NOTIFY, INFO, REFER, SUBSCRIBE, PRACK, UPDATE, MESSAGE, PUBLISH
Contact: <sip:4303030211176XXXX at 194.XXX.XXX.66:5060>
Call-Info: <sip:194.XXX.XXX.66>;method="NOTIFY;Event=telephone-event;Duration=1000"
Content-Type: application/sdp
Content-Length: 333

v=0
o=root 188 1 IN IP4 194.XXX.XXX.66
s=sip call
c=IN IP4 194.XXX.XXX.76
t=0 0
m=audio 44924 RTP/AVP 18 101
a=rtpmap:18 G729/8000
a=fmtp:18 annexb=no
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
a=ptime:20
a=X-vrzcap:vbd Ver=0 Mode=FaxPr ModemRtpRed=0
a=X-vrzcap:identification bin=DSR1e814 Prot=mgcp App=MG

But RTP traffic sent to .66 instead of .76

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

>Comment By: Bogdan-Andrei Iancu (bogdan_iancu)
Date: 2012-11-06 08:09

Message:
Ah..I see your update on flags :) Closing this ticket.

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

Comment By: Bogdan-Andrei Iancu (bogdan_iancu)
Date: 2012-11-06 08:08

Message:
Hi,

Hard to tell without knowing:
   what flags do you pass to rtpproxy_xxxx() 
   a full capture of RTP received on that call - rtpproxy learns
destination based on the incoming traffic.

Regards,
Bogdan

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

Comment By: apsaras (apsaras)
Date: 2012-11-06 08:02

Message:
Problem solved.

Need to put r flag to engage_rtp_proxy command.

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

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


From noreply at sourceforge.net  Tue Nov  6 17:48:34 2012
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue, 06 Nov 2012 08:48:34 -0800
Subject: [OpenSIPS-Devel] [ opensips-Bugs-3581600 ] TLS: "failed to accept:
	rejected by client"
Message-ID: <mailman.1171.1352220522.13469.devel@lists.opensips.org>

Bugs item #3581600, was opened at 2012-10-29 04:56
Message generated for change (Comment added) made by dragosoancea
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=3581600&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.8.x
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Dragos Oancea (dragosoancea)
Assigned to: Nobody/Anonymous (nobody)
Summary: TLS:  "failed to accept: rejected by client"

Initial Comment:
Hi

There is a weird behaviour in opensips-tls. It happened to me a 4 or 5 times in the last 3 months.
Sometimes I get a lot of messages like this in the logs:
"ERROR:core:tls_accept: New TLS connection from ip:port failed to accept: rejected by client"
This usually means that some TLS client which is not under my control is hammering on the SSL port, never completing a full SSL/TLS handshake. 
But whithin few minutes after these appear, nothing works on opensips anymore, you send an INVITE and it does not get relay-ed, nothing hapends , it's just stuck. Then I firewall the IP from where the connection requests come from, and everything starts to work fine again.


Regards,
Dragos

PS: Vlad, thx for fixing bug #3570495. It does not crash anymore. 

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

>Comment By: Dragos Oancea (dragosoancea)
Date: 2012-11-06 08:48

Message:
some info from /proc (not sure if it helps) :

http://pastebin.com/KULvTY8x

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

Comment By: Dragos Oancea (dragosoancea)
Date: 2012-11-06 06:21

Message:
Hi

Some more info: 

After opening 10 ssl connections and sending junk instead of an SSL
handshake, things start to go wrong. 
A legitimate TLS client  (already REGISTERed) would try to send an INVITE. 
This is what opensips shows in the logs instead  of just relay-ing the
INVITE :

Nov  6 15:05:10 [25062] DBG:core:send2child: to tcp child 0 0(25030),
0x7f39127846c0
Nov  6 15:05:10 [25030] DBG:core:handle_io: received n=8
con=0x7f39127846c0, fd=27
Nov  6 15:05:10 [25030] DBG:core:io_watch_add: io_watch_add(0x74a0a0, 27,
2, 0x7f39127846c0), fd_no=1
Nov  6 15:05:10 [25030] DBG:core:tls_update_fd: New fd is 27
Nov  6 15:05:10 [25030] ERROR:core:_tls_read: TLS connection to
80.187.x.x:39337 read failed
Nov  6 15:05:10 [25030] ERROR:core:_tls_read: TLS read error: 1
Nov  6 15:05:10 [25030] ERROR:core:tls_print_errstack: TLS errstack:
error:1408F10B:SSL routines:SSL3_GET_RECORD:wrong version number
Nov  6 15:05:10 [25030] ERROR:core:tcp_read_req: failed to read 
Nov  6 15:05:10 [25030] DBG:core:io_watch_del: io_watch_del (0x74a0a0, 27,
-1, 0x10) fd_no=2 called
Nov  6 15:05:10 [25030] DBG:core:release_tcpconn:  releasing con
0x7f39127846c0, state -2, fd=27, id=1343
Nov  6 15:05:10 [25030] DBG:core:release_tcpconn:  extra_data
0x7f39127f0010
Nov  6 15:05:10 [25062] DBG:core:handle_tcp_child: reader response=
7f39127846c0, -2 from 0 
Nov  6 15:05:10 [25062] DBG:core:tcpconn_destroy: destroying connection
0x7f39127846c0, flags 0002
Nov  6 15:05:10 [25062] DBG:core:tls_close: closing TLS connection
Nov  6 15:05:10 [25062] DBG:core:tls_update_fd: New fd is 83
Nov  6 15:05:10 [25062] DBG:core:tls_shutdown: first phase of 2-way
handshake completed succesfuly
Nov  6 15:05:10 [25062] DBG:core:tls_tcpconn_clean: entered

Looks like the TCP/TLS connection gets closed. Why ? It's the same client
that completed the SSL handshake and it was registered just before this
"attack" . The problem is easily reproduce-able with the small bash script
in my previous comment.  

Regards,
Dragos  

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

Comment By: Dragos Oancea (dragosoancea)
Date: 2012-11-06 05:36

Message:
Hi 

If I run this against my opensips-1.8.2-tls it will stop relay-ing INIVITEs
after less than 1 minute:

-------
#!/bin/bash 

count=1
while [[ $count -le 1000 ]]
do
    echo "$count"
    echo "giberish" | nc X.X.X.X 5061     
    sleep 1
    (( count++ ))       

done
-------

I have:
open_files_limit=81920
tcp_max_connections=40960

It happens under VMWare with only two registered TLS clients on a test box.


Regards,
Dragos

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

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


From bogdan at opensips.org  Tue Nov  6 22:50:16 2012
From: bogdan at opensips.org (Bogdan-Andrei Iancu)
Date: Tue, 06 Nov 2012 21:50:16 +0000
Subject: [OpenSIPS-Devel] SF.net SVN: opensips:[9429] trunk
Message-ID: <E1TVr2F-0001B0-WA@sfp-svn-2.v30.ch3.sourceforge.com>

Revision: 9429
          http://opensips.svn.sourceforge.net/opensips/?rev=9429&view=rev
Author:   bogdan_iancu
Date:     2012-11-06 21:50:15 +0000 (Tue, 06 Nov 2012)
Log Message:
-----------
-fixed the version and definition of the "aliases" table
 Reported by John Quick.

Modified Paths:
--------------
    trunk/db/schema/aliases.xml
    trunk/scripts/db_berkeley/opensips/aliases
    trunk/scripts/db_berkeley/opensips/version
    trunk/scripts/dbtext/opensips/aliases
    trunk/scripts/dbtext/opensips/version
    trunk/scripts/mysql/registrar-create.sql
    trunk/scripts/oracle/registrar-create.sql
    trunk/scripts/postgres/registrar-create.sql

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



From bogdan at opensips.org  Tue Nov  6 22:53:42 2012
From: bogdan at opensips.org (Bogdan-Andrei Iancu)
Date: Tue, 06 Nov 2012 21:53:42 +0000
Subject: [OpenSIPS-Devel] SF.net SVN: opensips:[9430] branches/1.8
Message-ID: <E1TVr5a-0001Rg-1X@sfp-svn-2.v30.ch3.sourceforge.com>

Revision: 9430
          http://opensips.svn.sourceforge.net/opensips/?rev=9430&view=rev
Author:   bogdan_iancu
Date:     2012-11-06 21:53:41 +0000 (Tue, 06 Nov 2012)
Log Message:
-----------
backport from trunk (rev #9429):
-fixed the version and definition of the "aliases" table
 Reported by John Quick.

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

Modified Paths:
--------------
    branches/1.8/db/schema/aliases.xml
    branches/1.8/scripts/db_berkeley/opensips/aliases
    branches/1.8/scripts/db_berkeley/opensips/version
    branches/1.8/scripts/dbtext/opensips/aliases
    branches/1.8/scripts/dbtext/opensips/version
    branches/1.8/scripts/mysql/registrar-create.sql
    branches/1.8/scripts/oracle/registrar-create.sql
    branches/1.8/scripts/postgres/registrar-create.sql

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



From bogdan at opensips.org  Tue Nov  6 22:55:32 2012
From: bogdan at opensips.org (Bogdan-Andrei Iancu)
Date: Tue, 06 Nov 2012 21:55:32 +0000
Subject: [OpenSIPS-Devel] SF.net SVN: opensips:[9431] branches/1.7
Message-ID: <E1TVr7M-0001cn-8x@sfp-svn-2.v30.ch3.sourceforge.com>

Revision: 9431
          http://opensips.svn.sourceforge.net/opensips/?rev=9431&view=rev
Author:   bogdan_iancu
Date:     2012-11-06 21:55:31 +0000 (Tue, 06 Nov 2012)
Log Message:
-----------
backport from trunk (rev #9429):
-fixed the version and definition of the "aliases" table
 Reported by John Quick.

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

Modified Paths:
--------------
    branches/1.7/db/schema/aliases.xml
    branches/1.7/scripts/db_berkeley/opensips/aliases
    branches/1.7/scripts/db_berkeley/opensips/version
    branches/1.7/scripts/dbtext/opensips/aliases
    branches/1.7/scripts/dbtext/opensips/version
    branches/1.7/scripts/mysql/registrar-create.sql
    branches/1.7/scripts/oracle/registrar-create.sql
    branches/1.7/scripts/postgres/registrar-create.sql

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



From anca at opensips.org  Wed Nov  7 16:44:04 2012
From: anca at opensips.org (Anca Vamanu)
Date: Wed, 07 Nov 2012 15:44:04 +0000
Subject: [OpenSIPS-Devel] SF.net SVN: opensips:[9432]
	trunk/modules/b2b_logic/records.c
Message-ID: <E1TW7nQ-0006tv-1c@sfp-svn-3.v30.ch3.sourceforge.com>

Revision: 9432
          http://opensips.svn.sourceforge.net/opensips/?rev=9432&view=rev
Author:   anca_vamanu
Date:     2012-11-07 15:44:03 +0000 (Wed, 07 Nov 2012)
Log Message:
-----------
Aplied patch #3515749 submitted by Nick Altmann (with small changes).
Feature implemented: insert_hf/append_hf are working before b2b_request_init and in b2b_request/b2b_reply routes.

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

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



From noreply at sourceforge.net  Wed Nov  7 16:47:37 2012
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed, 07 Nov 2012 07:47:37 -0800
Subject: [OpenSIPS-Devel] [ opensips-Patches-3515749 ] B2B_LOGIC -
	possibility to add headers from script
Message-ID: <mailman.1172.1352303267.13469.devel@lists.opensips.org>

Patches item #3515749, was opened at 2012-04-07 12:52
Message generated for change (Comment added) made by anca_vamanu
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086412&aid=3515749&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_LOGIC - possibility to add headers from script

Initial Comment:
Based on feature request #3514222.
With this patch insert_hf/append_hf are working before b2b_request_init and in b2b_request/b2b_reply routes.

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

Comment By: Anca Vamanu (anca_vamanu)
Date: 2012-11-07 07:47

Message:
Hi Nick,

Thank you for sending this patch (sorry for the long delay). I have
committed it now in the trunk with small changes - rev 9432.
So now it is possible to add headers to the initial Invite(from request
route before calling b2b_init_request) or for replies (from
b2b_reply_route) or sequential requests (from b2b_request_route).

Regards,
Anca

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

Comment By: a719719 (a719719)
Date: 2012-10-24 13:54

Message:
I would like to do the following:

route[b2b_reply] {
  xlog("b2b_reply ($ci)\n");

                if(remove_hf("Allow"))
                {
                        append_hf("Allow: INVITE, ACK, CANCEL, OPTIONS,
BYE, INFO\r\n");
                }
}

The remove_hf return true but the 180 ringing reply still has the same
Allow header.

Will this patch make this happen? Thanks!

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

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


From noreply at sourceforge.net  Wed Nov  7 16:51:36 2012
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed, 07 Nov 2012 07:51:36 -0800
Subject: [OpenSIPS-Devel] [ opensips-Patches-3515749 ] B2B_LOGIC -
	possibility to add headers from script
Message-ID: <mailman.1173.1352303504.13469.devel@lists.opensips.org>

Patches item #3515749, was opened at 2012-04-07 12:52
Message generated for change (Comment added) made by anca_vamanu
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086412&aid=3515749&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_LOGIC - possibility to add headers from script

Initial Comment:
Based on feature request #3514222.
With this patch insert_hf/append_hf are working before b2b_request_init and in b2b_request/b2b_reply routes.

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

Comment By: Anca Vamanu (anca_vamanu)
Date: 2012-11-07 07:51

Message:
Hi a719719,

Unfortunately this patch only implements the possibility to add headers,
not also to remove them.
But indeed for it to be consistent, the possibility to also remove a header
should be available. I will try to implement this in the next period.

Regards,
Anca

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

Comment By: Anca Vamanu (anca_vamanu)
Date: 2012-11-07 07:47

Message:
Hi Nick,

Thank you for sending this patch (sorry for the long delay). I have
committed it now in the trunk with small changes - rev 9432.
So now it is possible to add headers to the initial Invite(from request
route before calling b2b_init_request) or for replies (from
b2b_reply_route) or sequential requests (from b2b_request_route).

Regards,
Anca

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

Comment By: a719719 (a719719)
Date: 2012-10-24 13:54

Message:
I would like to do the following:

route[b2b_reply] {
  xlog("b2b_reply ($ci)\n");

                if(remove_hf("Allow"))
                {
                        append_hf("Allow: INVITE, ACK, CANCEL, OPTIONS,
BYE, INFO\r\n");
                }
}

The remove_hf return true but the 180 ringing reply still has the same
Allow header.

Will this patch make this happen? Thanks!

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

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


From saul at ag-projects.com  Thu Nov  8 11:05:31 2012
From: saul at ag-projects.com (=?iso-8859-1?Q?Sa=FAl_Ibarra_Corretg=E9?=)
Date: Thu, 8 Nov 2012 11:05:31 +0100
Subject: [OpenSIPS-Devel] [OpenSIPS 1.9] Winter cleanup: XCAP
Message-ID: <DA1A936B-B96B-4808-919E-0E590D78548E@ag-projects.com>

Hi all,

I've been working for quite a while now in adding external references to RLS and pres-rules documents following IETF and OMA specifications respectively. And it works! \o/ In the process I noticed there is common behavior that can be factored out of rls and presence_xml modules. So, my plan is to create a new module called "xcap" (surprise surprise!) which encapsulates XCAP related stuff and then both rls and presence_xml would use it in conjunction with xcap_client.

These are the main things that would go into the new xcap module:

	- xcap_table: table where documents are stored
	- integrated_xcap_server: boolean flag indicating if a integrated server (as OpenXCAP) is in use or xcap_client should be used instead
	- xcap_server: list of local XCAP servers
	- functions to load arbitrary XCAP documents from DB
	- functions to load an arbitrary node from a document using XPath
	- XCAP URI parsing

Note that this change implies that the same table is used for XCAP documents for both Presence and RLS. I see no reason to keep separated parameters in RLS and Presence modules, so if anyone has a good reason for it, please speak up so I can convince you otherwise :-)


OMA pres-rules related changes:

Currently the pres_rules_auid and pres_rules_filename options are only used in non-integrated XCAP mode, and pres_rules_auid may take any value. The value for pres_rules_auid will be constrained to "pres-rules" or "org.openmobilealliance.pres-rules" and will also be used in integrated mode. The chosen AUID defines how the policy is applied, either following IETF rules or OMA rules. After this implementation is complete, a way for choosing the policy type per subscriber will be researched.

Right now both IETF and OMA pres-rules documents are stored with the same "doc_type" thus overriding each other. This will no longer be the case. Users will be able to store both types of documents and the proxy will apply the rules according to the configured AUID. OpenXCAP will also be modified accordingly.


About xcap_server configuration option:

Currently it's only used in non-integrated mode, but it's also needed in integrated mode on order to know if a reference is local or not and thus if it should be followed or not.


You made it this far! Great, what is your take on this?

Regards,

--
Sa?l Ibarra Corretg?
AG Projects





From noreply at sourceforge.net  Thu Nov  8 14:53:50 2012
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 08 Nov 2012 05:53:50 -0800
Subject: [OpenSIPS-Devel] [ opensips-Bugs-3581600 ] TLS: "failed to accept:
	rejected by client"
Message-ID: <mailman.1174.1352382841.13469.devel@lists.opensips.org>

Bugs item #3581600, was opened at 2012-10-29 04:56
Message generated for change (Comment added) made by dragosoancea
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=3581600&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.8.x
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Dragos Oancea (dragosoancea)
Assigned to: Nobody/Anonymous (nobody)
Summary: TLS:  "failed to accept: rejected by client"

Initial Comment:
Hi

There is a weird behaviour in opensips-tls. It happened to me a 4 or 5 times in the last 3 months.
Sometimes I get a lot of messages like this in the logs:
"ERROR:core:tls_accept: New TLS connection from ip:port failed to accept: rejected by client"
This usually means that some TLS client which is not under my control is hammering on the SSL port, never completing a full SSL/TLS handshake. 
But whithin few minutes after these appear, nothing works on opensips anymore, you send an INVITE and it does not get relay-ed, nothing hapends , it's just stuck. Then I firewall the IP from where the connection requests come from, and everything starts to work fine again.


Regards,
Dragos

PS: Vlad, thx for fixing bug #3570495. It does not crash anymore. 

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

>Comment By: Dragos Oancea (dragosoancea)
Date: 2012-11-08 05:53

Message:
anyone else experiencing this bad DoS ? 
I only have TLS phones, and some of them are under development, so a single
TLS phone that goes crazy and cannot perform the SSL handshake for some
reason can put down the whole SIP proxy. 

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

Comment By: Dragos Oancea (dragosoancea)
Date: 2012-11-06 08:48

Message:
some info from /proc (not sure if it helps) :

http://pastebin.com/KULvTY8x

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

Comment By: Dragos Oancea (dragosoancea)
Date: 2012-11-06 06:21

Message:
Hi

Some more info: 

After opening 10 ssl connections and sending junk instead of an SSL
handshake, things start to go wrong. 
A legitimate TLS client  (already REGISTERed) would try to send an INVITE. 
This is what opensips shows in the logs instead  of just relay-ing the
INVITE :

Nov  6 15:05:10 [25062] DBG:core:send2child: to tcp child 0 0(25030),
0x7f39127846c0
Nov  6 15:05:10 [25030] DBG:core:handle_io: received n=8
con=0x7f39127846c0, fd=27
Nov  6 15:05:10 [25030] DBG:core:io_watch_add: io_watch_add(0x74a0a0, 27,
2, 0x7f39127846c0), fd_no=1
Nov  6 15:05:10 [25030] DBG:core:tls_update_fd: New fd is 27
Nov  6 15:05:10 [25030] ERROR:core:_tls_read: TLS connection to
80.187.x.x:39337 read failed
Nov  6 15:05:10 [25030] ERROR:core:_tls_read: TLS read error: 1
Nov  6 15:05:10 [25030] ERROR:core:tls_print_errstack: TLS errstack:
error:1408F10B:SSL routines:SSL3_GET_RECORD:wrong version number
Nov  6 15:05:10 [25030] ERROR:core:tcp_read_req: failed to read 
Nov  6 15:05:10 [25030] DBG:core:io_watch_del: io_watch_del (0x74a0a0, 27,
-1, 0x10) fd_no=2 called
Nov  6 15:05:10 [25030] DBG:core:release_tcpconn:  releasing con
0x7f39127846c0, state -2, fd=27, id=1343
Nov  6 15:05:10 [25030] DBG:core:release_tcpconn:  extra_data
0x7f39127f0010
Nov  6 15:05:10 [25062] DBG:core:handle_tcp_child: reader response=
7f39127846c0, -2 from 0 
Nov  6 15:05:10 [25062] DBG:core:tcpconn_destroy: destroying connection
0x7f39127846c0, flags 0002
Nov  6 15:05:10 [25062] DBG:core:tls_close: closing TLS connection
Nov  6 15:05:10 [25062] DBG:core:tls_update_fd: New fd is 83
Nov  6 15:05:10 [25062] DBG:core:tls_shutdown: first phase of 2-way
handshake completed succesfuly
Nov  6 15:05:10 [25062] DBG:core:tls_tcpconn_clean: entered

Looks like the TCP/TLS connection gets closed. Why ? It's the same client
that completed the SSL handshake and it was registered just before this
"attack" . The problem is easily reproduce-able with the small bash script
in my previous comment.  

Regards,
Dragos  

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

Comment By: Dragos Oancea (dragosoancea)
Date: 2012-11-06 05:36

Message:
Hi 

If I run this against my opensips-1.8.2-tls it will stop relay-ing INIVITEs
after less than 1 minute:

-------
#!/bin/bash 

count=1
while [[ $count -le 1000 ]]
do
    echo "$count"
    echo "giberish" | nc X.X.X.X 5061     
    sleep 1
    (( count++ ))       

done
-------

I have:
open_files_limit=81920
tcp_max_connections=40960

It happens under VMWare with only two registered TLS clients on a test box.


Regards,
Dragos

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

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


From noreply at sourceforge.net  Thu Nov  8 15:15:20 2012
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 08 Nov 2012 06:15:20 -0800
Subject: [OpenSIPS-Devel] [ opensips-Bugs-3581600 ] TLS: "failed to accept:
	rejected by client"
Message-ID: <mailman.1175.1352384127.13469.devel@lists.opensips.org>

Bugs item #3581600, was opened at 2012-10-29 04:56
Message generated for change (Comment added) made by saghul
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=3581600&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.8.x
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Dragos Oancea (dragosoancea)
Assigned to: Nobody/Anonymous (nobody)
Summary: TLS:  "failed to accept: rejected by client"

Initial Comment:
Hi

There is a weird behaviour in opensips-tls. It happened to me a 4 or 5 times in the last 3 months.
Sometimes I get a lot of messages like this in the logs:
"ERROR:core:tls_accept: New TLS connection from ip:port failed to accept: rejected by client"
This usually means that some TLS client which is not under my control is hammering on the SSL port, never completing a full SSL/TLS handshake. 
But whithin few minutes after these appear, nothing works on opensips anymore, you send an INVITE and it does not get relay-ed, nothing hapends , it's just stuck. Then I firewall the IP from where the connection requests come from, and everything starts to work fine again.


Regards,
Dragos

PS: Vlad, thx for fixing bug #3570495. It does not crash anymore. 

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

Comment By: saghul (saghul)
Date: 2012-11-08 06:15

Message:
Hi Dragos,

FWIW, we have also seen this when running the sip2sip.info service and had
to turn it off because even if it doesn't crash, if a single client sends
bogus data the proxy just stops working (on TLS) as you described.

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

Comment By: Dragos Oancea (dragosoancea)
Date: 2012-11-08 05:53

Message:
anyone else experiencing this bad DoS ? 
I only have TLS phones, and some of them are under development, so a single
TLS phone that goes crazy and cannot perform the SSL handshake for some
reason can put down the whole SIP proxy. 

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

Comment By: Dragos Oancea (dragosoancea)
Date: 2012-11-06 08:48

Message:
some info from /proc (not sure if it helps) :

http://pastebin.com/KULvTY8x

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

Comment By: Dragos Oancea (dragosoancea)
Date: 2012-11-06 06:21

Message:
Hi

Some more info: 

After opening 10 ssl connections and sending junk instead of an SSL
handshake, things start to go wrong. 
A legitimate TLS client  (already REGISTERed) would try to send an INVITE. 
This is what opensips shows in the logs instead  of just relay-ing the
INVITE :

Nov  6 15:05:10 [25062] DBG:core:send2child: to tcp child 0 0(25030),
0x7f39127846c0
Nov  6 15:05:10 [25030] DBG:core:handle_io: received n=8
con=0x7f39127846c0, fd=27
Nov  6 15:05:10 [25030] DBG:core:io_watch_add: io_watch_add(0x74a0a0, 27,
2, 0x7f39127846c0), fd_no=1
Nov  6 15:05:10 [25030] DBG:core:tls_update_fd: New fd is 27
Nov  6 15:05:10 [25030] ERROR:core:_tls_read: TLS connection to
80.187.x.x:39337 read failed
Nov  6 15:05:10 [25030] ERROR:core:_tls_read: TLS read error: 1
Nov  6 15:05:10 [25030] ERROR:core:tls_print_errstack: TLS errstack:
error:1408F10B:SSL routines:SSL3_GET_RECORD:wrong version number
Nov  6 15:05:10 [25030] ERROR:core:tcp_read_req: failed to read 
Nov  6 15:05:10 [25030] DBG:core:io_watch_del: io_watch_del (0x74a0a0, 27,
-1, 0x10) fd_no=2 called
Nov  6 15:05:10 [25030] DBG:core:release_tcpconn:  releasing con
0x7f39127846c0, state -2, fd=27, id=1343
Nov  6 15:05:10 [25030] DBG:core:release_tcpconn:  extra_data
0x7f39127f0010
Nov  6 15:05:10 [25062] DBG:core:handle_tcp_child: reader response=
7f39127846c0, -2 from 0 
Nov  6 15:05:10 [25062] DBG:core:tcpconn_destroy: destroying connection
0x7f39127846c0, flags 0002
Nov  6 15:05:10 [25062] DBG:core:tls_close: closing TLS connection
Nov  6 15:05:10 [25062] DBG:core:tls_update_fd: New fd is 83
Nov  6 15:05:10 [25062] DBG:core:tls_shutdown: first phase of 2-way
handshake completed succesfuly
Nov  6 15:05:10 [25062] DBG:core:tls_tcpconn_clean: entered

Looks like the TCP/TLS connection gets closed. Why ? It's the same client
that completed the SSL handshake and it was registered just before this
"attack" . The problem is easily reproduce-able with the small bash script
in my previous comment.  

Regards,
Dragos  

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

Comment By: Dragos Oancea (dragosoancea)
Date: 2012-11-06 05:36

Message:
Hi 

If I run this against my opensips-1.8.2-tls it will stop relay-ing INIVITEs
after less than 1 minute:

-------
#!/bin/bash 

count=1
while [[ $count -le 1000 ]]
do
    echo "$count"
    echo "giberish" | nc X.X.X.X 5061     
    sleep 1
    (( count++ ))       

done
-------

I have:
open_files_limit=81920
tcp_max_connections=40960

It happens under VMWare with only two registered TLS clients on a test box.


Regards,
Dragos

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

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


From saghul at users.sourceforge.net  Thu Nov  8 18:27:24 2012
From: saghul at users.sourceforge.net (saghul at users.sourceforge.net)
Date: Thu, 08 Nov 2012 17:27:24 +0000
Subject: [OpenSIPS-Devel] SF.net SVN: opensips:[9433]
	trunk/modules/rls/notify.c
Message-ID: <E1TWVsy-0000yy-Kw@sfp-svn-4.v30.ch3.sourceforge.com>

Revision: 9433
          http://opensips.svn.sourceforge.net/opensips/?rev=9433&view=rev
Author:   saghul
Date:     2012-11-08 17:27:24 +0000 (Thu, 08 Nov 2012)
Log Message:
-----------
Don't use strcat when calculating RLS selector path

Modified Paths:
--------------
    trunk/modules/rls/notify.c

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



From saghul at users.sourceforge.net  Thu Nov  8 18:33:53 2012
From: saghul at users.sourceforge.net (saghul at users.sourceforge.net)
Date: Thu, 08 Nov 2012 17:33:53 +0000
Subject: [OpenSIPS-Devel] SF.net SVN: opensips:[9434]
	trunk/modules/rls/notify.c
Message-ID: <E1TWVzF-0001Kj-A2@sfp-svn-4.v30.ch3.sourceforge.com>

Revision: 9434
          http://opensips.svn.sourceforge.net/opensips/?rev=9434&view=rev
Author:   saghul
Date:     2012-11-08 17:33:53 +0000 (Thu, 08 Nov 2012)
Log Message:
-----------
Fixed normalizing SIP URIs in RLS

Modified Paths:
--------------
    trunk/modules/rls/notify.c

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



From noreply at sourceforge.net  Thu Nov  8 19:46:35 2012
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 08 Nov 2012 10:46:35 -0800
Subject: [OpenSIPS-Devel] [ opensips-Bugs-2993623 ] Multipart/mixed messages
	with textops and mediaproxy
Message-ID: <mailman.1176.1352400403.13469.devel@lists.opensips.org>

Bugs item #2993623, was opened at 2010-04-28 07:36
Message generated for change (Comment added) made by denodaeus
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=2993623&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: Jim Fitzgerald (agelmar)
Assigned to: Dan (dan_pascu)
Summary: Multipart/mixed messages with textops and mediaproxy

Initial Comment:
I have a server sending INVITE messages with a multipart/mixed body. There are 2 misbehaviours I had to correct because of a special constellation:
the content-Type header of my server looks like this:

> Content-Type: multipart/mixed;boundary=unique-boundary-1

saying that the parsing string is "unique-boundary-1". In the textops.c the string is hardcoded and checks for "-Boundary". So if I use the filter_body("application/sdp") function it fails. So Textops should read the delimiter string from Content-Type header dynamically. The hardcoded delimiter is in textops.c line 908.

Filtering works after correcting textops.c, but still mediaproxy module has a problem. After calling filter_body() I will route the call over mediaproxy, so I call use_media_proxy() from mediaproxy.c. But this function works with the uncorrected INVITE pakage again. So if it searches application/sdp it only finds multipart/mixed and no mediaproxy channel is created. Best solution would be to get mediaproxy to work with the previously corrected pakage. I am using a workaround now, replacing "status = get_sdp_message(msg, &sdp);" on line 1445 in mediaproxy.c with "status = 1;". 

regards


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

Comment By: Robert Smith (denodaeus)
Date: 2012-11-08 10:46

Message:
I'm actually encountering this now with a callmanager setup using SIP-T to
communicate over, and I want to get rid of the mixed multipart content and
retain the sdp.

In the SDP body, we have:
Content-Type:
multipart/mixed;boundary=uniqueBoundary#015#012Content-Length:
478#015#012#015#012--uniqueBoundary#015#01

But it's hard coded to match on "--Boundary" only.

This bug is quite old, but wanting to bring up that we'd also like to see
the ability to honor the boundary= param here to specify a dynamic
multipart boundary token.


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

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


From noreply at sourceforge.net  Fri Nov  9 05:47:29 2012
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 08 Nov 2012 20:47:29 -0800
Subject: [OpenSIPS-Devel] [ opensips-Bugs-3585606 ] TCP Deadlock
Message-ID: <mailman.1177.1352436453.13469.devel@lists.opensips.org>

Bugs item #3585606, was opened at 2012-11-08 20:47
Message generated for change (Tracker Item Submitted) made by dmsanders
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=3585606&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.8.x
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: David Sanders (dmsanders)
Assigned to: Nobody/Anonymous (nobody)
Summary: TCP Deadlock

Initial Comment:
There is a serious deadlock issue when using TCP with OpenSIPS (1.8.0-tls). I found this paper which has the same conclusion (but is discussing OpenSER circa 2008): http://www.cs.rice.edu/CS/Architecture/docs/ram-ispass08.pdf

I'll quote the relevant part of Section 6:

This can lead to deadlock in the following situation. When a
worker process requests a connection from
the supervisor process, it then blocks waiting to receive that
?le descriptor. If, at the same time, the supervisor process
blocks waiting to send a new connection to the same worker
(since the buffer at the receiver is full), the two processes
will deadlock. Once the supervisor process deadlocks, no
other worker can make progress either, as they will quickly
need their own connections from the supervisor process.
Similarly, no new connections will be accepted. This clearly
illustrates that in an event-driven server, one must be careful
to only read from sockets when the event mechanism says
there is something to read and only write to sockets when
the event mechanism says there is space to write.

I can reliably reproduce this deadlock with any number of TCP children. Interestingly it seems to happen faster with a larger number of children. Under constant load, once the main TCP process deadlocks, all the children will as well.

It seems to be rate related. Using SIPp to drive TCP traffic to an OpenSIPS server, 50 registers/second do not encounter the deadlock issue. However, if increase the traffic load a deadlock will occur within 30 seconds. My theory is that if the TCP children can't process a message and reply faster than they are coming in (in this case faster than 20ms) then the deadlock will occur.

For completeness the GDB backtrace output of the deadlocked processes when running two TCP children are attached.

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

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


From noreply at sourceforge.net  Fri Nov  9 05:49:01 2012
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 08 Nov 2012 20:49:01 -0800
Subject: [OpenSIPS-Devel] [ opensips-Bugs-3585606 ] TCP Deadlock
Message-ID: <mailman.1178.1352436545.13469.devel@lists.opensips.org>

Bugs item #3585606, was opened at 2012-11-08 20:47
Message generated for change (Settings changed) made by dmsanders
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=3585606&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.8.x
Status: Open
Resolution: None
>Priority: 7
Private: No
Submitted By: David Sanders (dmsanders)
Assigned to: Nobody/Anonymous (nobody)
Summary: TCP Deadlock

Initial Comment:
There is a serious deadlock issue when using TCP with OpenSIPS (1.8.0-tls). I found this paper which has the same conclusion (but is discussing OpenSER circa 2008): http://www.cs.rice.edu/CS/Architecture/docs/ram-ispass08.pdf

I'll quote the relevant part of Section 6:

This can lead to deadlock in the following situation. When a
worker process requests a connection from
the supervisor process, it then blocks waiting to receive that
?le descriptor. If, at the same time, the supervisor process
blocks waiting to send a new connection to the same worker
(since the buffer at the receiver is full), the two processes
will deadlock. Once the supervisor process deadlocks, no
other worker can make progress either, as they will quickly
need their own connections from the supervisor process.
Similarly, no new connections will be accepted. This clearly
illustrates that in an event-driven server, one must be careful
to only read from sockets when the event mechanism says
there is something to read and only write to sockets when
the event mechanism says there is space to write.

I can reliably reproduce this deadlock with any number of TCP children. Interestingly it seems to happen faster with a larger number of children. Under constant load, once the main TCP process deadlocks, all the children will as well.

It seems to be rate related. Using SIPp to drive TCP traffic to an OpenSIPS server, 50 registers/second do not encounter the deadlock issue. However, if increase the traffic load a deadlock will occur within 30 seconds. My theory is that if the TCP children can't process a message and reply faster than they are coming in (in this case faster than 20ms) then the deadlock will occur.

For completeness the GDB backtrace output of the deadlocked processes when running two TCP children are attached.

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

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


From noreply at sourceforge.net  Fri Nov  9 05:49:43 2012
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 08 Nov 2012 20:49:43 -0800
Subject: [OpenSIPS-Devel] [ opensips-Bugs-3585606 ] TCP Deadlock
Message-ID: <mailman.1179.1352436587.13469.devel@lists.opensips.org>

Bugs item #3585606, was opened at 2012-11-08 20:47
Message generated for change (Comment added) made by dmsanders
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=3585606&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.8.x
Status: Open
Resolution: None
Priority: 7
Private: No
Submitted By: David Sanders (dmsanders)
Assigned to: Nobody/Anonymous (nobody)
Summary: TCP Deadlock

Initial Comment:
There is a serious deadlock issue when using TCP with OpenSIPS (1.8.0-tls). I found this paper which has the same conclusion (but is discussing OpenSER circa 2008): http://www.cs.rice.edu/CS/Architecture/docs/ram-ispass08.pdf

I'll quote the relevant part of Section 6:

This can lead to deadlock in the following situation. When a
worker process requests a connection from
the supervisor process, it then blocks waiting to receive that
?le descriptor. If, at the same time, the supervisor process
blocks waiting to send a new connection to the same worker
(since the buffer at the receiver is full), the two processes
will deadlock. Once the supervisor process deadlocks, no
other worker can make progress either, as they will quickly
need their own connections from the supervisor process.
Similarly, no new connections will be accepted. This clearly
illustrates that in an event-driven server, one must be careful
to only read from sockets when the event mechanism says
there is something to read and only write to sockets when
the event mechanism says there is space to write.

I can reliably reproduce this deadlock with any number of TCP children. Interestingly it seems to happen faster with a larger number of children. Under constant load, once the main TCP process deadlocks, all the children will as well.

It seems to be rate related. Using SIPp to drive TCP traffic to an OpenSIPS server, 50 registers/second do not encounter the deadlock issue. However, if increase the traffic load a deadlock will occur within 30 seconds. My theory is that if the TCP children can't process a message and reply faster than they are coming in (in this case faster than 20ms) then the deadlock will occur.

For completeness the GDB backtrace output of the deadlocked processes when running two TCP children are attached.

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

>Comment By: David Sanders (dmsanders)
Date: 2012-11-08 20:49

Message:
I took the liberty of upgrading this to a higher priority bug since it can
completely deadlock TCP traffic for a server if the call rate gets too
high.

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

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


From noreply at sourceforge.net  Fri Nov  9 12:39:32 2012
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 09 Nov 2012 03:39:32 -0800
Subject: [OpenSIPS-Devel] [ opensips-Bugs-3585696 ] Crash due to mi commands
Message-ID: <mailman.1180.1352461179.13469.devel@lists.opensips.org>

Bugs item #3585696, was opened at 2012-11-09 03:39
Message generated for change (Tracker Item Submitted) made by digipigeon
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=3585696&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: Digipigeon (digipigeon)
Assigned to: Nobody/Anonymous (nobody)
Summary: Crash due to mi commands

Initial Comment:
I am getting repeated crashing on my three X 1.8.2 opensips servers, also some crashing on my 1.7.1.

The problem appears to be more noticeable when the profile_get_values is called frequently (every few seconds), however I cant confirm isolation of this command causes the crash.

Please see attached (gdb) bt full

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

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


From noreply at sourceforge.net  Fri Nov  9 15:22:52 2012
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 09 Nov 2012 06:22:52 -0800
Subject: [OpenSIPS-Devel] [ opensips-Bugs-3585696 ] Crash due to mi commands
Message-ID: <mailman.1181.1352470983.13469.devel@lists.opensips.org>

Bugs item #3585696, was opened at 2012-11-09 03:39
Message generated for change (Comment added) made by razvancrainea
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=3585696&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: Digipigeon (digipigeon)
Assigned to: Nobody/Anonymous (nobody)
Summary: Crash due to mi commands

Initial Comment:
I am getting repeated crashing on my three X 1.8.2 opensips servers, also some crashing on my 1.7.1.

The problem appears to be more noticeable when the profile_get_values is called frequently (every few seconds), however I cant confirm isolation of this command causes the crash.

Please see attached (gdb) bt full

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

>Comment By: Razvan Crainea (razvancrainea)
Date: 2012-11-09 06:22

Message:
Hi!

The core you attached does not contain any indications that the cause of
the crash are the dialog profiles, but rather some statistics you are
fetching through MI. Can you provide us the exact MI command you are
running?

Best regards,
R?zvan

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

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


From noreply at sourceforge.net  Fri Nov  9 16:09:44 2012
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 09 Nov 2012 07:09:44 -0800
Subject: [OpenSIPS-Devel] [ opensips-Bugs-3585696 ] Crash due to mi commands
Message-ID: <mailman.1182.1352473794.13469.devel@lists.opensips.org>

Bugs item #3585696, was opened at 2012-11-09 03:39
Message generated for change (Comment added) made by digipigeon
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=3585696&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: Digipigeon (digipigeon)
Assigned to: Nobody/Anonymous (nobody)
Summary: Crash due to mi commands

Initial Comment:
I am getting repeated crashing on my three X 1.8.2 opensips servers, also some crashing on my 1.7.1.

The problem appears to be more noticeable when the profile_get_values is called frequently (every few seconds), however I cant confirm isolation of this command causes the crash.

Please see attached (gdb) bt full

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

Comment By: Digipigeon (digipigeon)
Date: 2012-11-09 07:09

Message:
The only parameter that I have programmed in for get_statistics is the
parameter "all", this is ran through xmlrpc

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

Comment By: Razvan Crainea (razvancrainea)
Date: 2012-11-09 06:22

Message:
Hi!

The core you attached does not contain any indications that the cause of
the crash are the dialog profiles, but rather some statistics you are
fetching through MI. Can you provide us the exact MI command you are
running?

Best regards,
R?zvan

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

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


From liviu at opensips.org  Fri Nov  9 18:28:29 2012
From: liviu at opensips.org (Liviu Chircu)
Date: Fri, 09 Nov 2012 17:28:29 +0000
Subject: [OpenSIPS-Devel] SF.net SVN: opensips:[9435] trunk/modules/sipmsgops
Message-ID: <E1TWsNZ-0004W3-7m@sfp-svn-3.v30.ch3.sourceforge.com>

Revision: 9435
          http://opensips.svn.sourceforge.net/opensips/?rev=9435&view=rev
Author:   liviuchircu
Date:     2012-11-09 17:28:28 +0000 (Fri, 09 Nov 2012)
Log Message:
-----------
is_present_hf() and remove_hf() functions now receive string pseudo-variables as parameters

Modified Paths:
--------------
    trunk/modules/sipmsgops/README
    trunk/modules/sipmsgops/doc/sipmsgops_admin.xml
    trunk/modules/sipmsgops/sipmsgops.c

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



From noreply at sourceforge.net  Fri Nov  9 18:32:46 2012
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 09 Nov 2012 09:32:46 -0800
Subject: [OpenSIPS-Devel] [ opensips-Bugs-3585696 ] Crash due to mi commands
Message-ID: <mailman.1183.1352482371.13469.devel@lists.opensips.org>

Bugs item #3585696, was opened at 2012-11-09 03:39
Message generated for change (Comment added) made by bogdan_iancu
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=3585696&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: Digipigeon (digipigeon)
Assigned to: Nobody/Anonymous (nobody)
Summary: Crash due to mi commands

Initial Comment:
I am getting repeated crashing on my three X 1.8.2 opensips servers, also some crashing on my 1.7.1.

The problem appears to be more noticeable when the profile_get_values is called frequently (every few seconds), however I cant confirm isolation of this command causes the crash.

Please see attached (gdb) bt full

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

>Comment By: Bogdan-Andrei Iancu (bogdan_iancu)
Date: 2012-11-09 09:32

Message:
Hi,

1) do you see in the logs any err message before the crash (from the same
process) ?

2) in gdb, frame 0, please print : brother, *brother, name, value,
*brother->next .

Thanks and regards,
Bogdan

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

Comment By: Digipigeon (digipigeon)
Date: 2012-11-09 07:09

Message:
The only parameter that I have programmed in for get_statistics is the
parameter "all", this is ran through xmlrpc

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

Comment By: Razvan Crainea (razvancrainea)
Date: 2012-11-09 06:22

Message:
Hi!

The core you attached does not contain any indications that the cause of
the crash are the dialog profiles, but rather some statistics you are
fetching through MI. Can you provide us the exact MI command you are
running?

Best regards,
R?zvan

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

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


From noreply at sourceforge.net  Fri Nov  9 18:40:13 2012
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 09 Nov 2012 09:40:13 -0800
Subject: [OpenSIPS-Devel] [ opensips-Bugs-3585606 ] TCP Deadlock
Message-ID: <mailman.1184.1352482821.13469.devel@lists.opensips.org>

Bugs item #3585606, was opened at 2012-11-08 20:47
Message generated for change (Settings changed) made by bogdan_iancu
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=3585606&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.8.x
Status: Open
Resolution: None
>Priority: 9
Private: No
Submitted By: David Sanders (dmsanders)
>Assigned to: Bogdan-Andrei Iancu (bogdan_iancu)
Summary: TCP Deadlock

Initial Comment:
There is a serious deadlock issue when using TCP with OpenSIPS (1.8.0-tls). I found this paper which has the same conclusion (but is discussing OpenSER circa 2008): http://www.cs.rice.edu/CS/Architecture/docs/ram-ispass08.pdf

I'll quote the relevant part of Section 6:

This can lead to deadlock in the following situation. When a
worker process requests a connection from
the supervisor process, it then blocks waiting to receive that
?le descriptor. If, at the same time, the supervisor process
blocks waiting to send a new connection to the same worker
(since the buffer at the receiver is full), the two processes
will deadlock. Once the supervisor process deadlocks, no
other worker can make progress either, as they will quickly
need their own connections from the supervisor process.
Similarly, no new connections will be accepted. This clearly
illustrates that in an event-driven server, one must be careful
to only read from sockets when the event mechanism says
there is something to read and only write to sockets when
the event mechanism says there is space to write.

I can reliably reproduce this deadlock with any number of TCP children. Interestingly it seems to happen faster with a larger number of children. Under constant load, once the main TCP process deadlocks, all the children will as well.

It seems to be rate related. Using SIPp to drive TCP traffic to an OpenSIPS server, 50 registers/second do not encounter the deadlock issue. However, if increase the traffic load a deadlock will occur within 30 seconds. My theory is that if the TCP children can't process a message and reply faster than they are coming in (in this case faster than 20ms) then the deadlock will occur.

For completeness the GDB backtrace output of the deadlocked processes when running two TCP children are attached.

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

>Comment By: Bogdan-Andrei Iancu (bogdan_iancu)
Date: 2012-11-09 09:40

Message:
Hi David - thank you for the report - I will look into it asap !

Regards,
Bogdan

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

Comment By: David Sanders (dmsanders)
Date: 2012-11-08 20:49

Message:
I took the liberty of upgrading this to a higher priority bug since it can
completely deadlock TCP traffic for a server if the call rate gets too
high.

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

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


From liviu at opensips.org  Fri Nov  9 19:03:18 2012
From: liviu at opensips.org (Liviu Chircu)
Date: Fri, 09 Nov 2012 18:03:18 +0000
Subject: [OpenSIPS-Devel] SF.net SVN: opensips:[9436]
	trunk/modules/sipmsgops/sipmsgops.c
Message-ID: <E1TWsvG-0006Sl-Bu@sfp-svn-3.v30.ch3.sourceforge.com>

Revision: 9436
          http://opensips.svn.sourceforge.net/opensips/?rev=9436&view=rev
Author:   liviuchircu
Date:     2012-11-09 18:03:18 +0000 (Fri, 09 Nov 2012)
Log Message:
-----------
fixed buffer reallocating too often in previous commit

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

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



From osas at voipembedded.com  Fri Nov  9 19:37:40 2012
From: osas at voipembedded.com (Ovidiu Sas)
Date: Fri, 09 Nov 2012 18:37:40 +0000
Subject: [OpenSIPS-Devel] SF.net SVN: opensips:[9437]
	trunk/modules/drouting/prefix_tree.h
Message-ID: <E1TWtSW-0003dt-Om@sfp-svn-1.v30.ch3.sourceforge.com>

Revision: 9437
          http://opensips.svn.sourceforge.net/opensips/?rev=9437&view=rev
Author:   osas
Date:     2012-11-09 18:37:40 +0000 (Fri, 09 Nov 2012)
Log Message:
-----------
drouting: remove bogus semicolon in structure declaration
          (most likely a copy/paste error)

Modified Paths:
--------------
    trunk/modules/drouting/prefix_tree.h

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



From osas at voipembedded.com  Fri Nov  9 19:44:45 2012
From: osas at voipembedded.com (Ovidiu Sas)
Date: Fri, 09 Nov 2012 18:44:45 +0000
Subject: [OpenSIPS-Devel] SF.net SVN: opensips:[9438]
	branches/1.8/modules/drouting/prefix_tree.h
Message-ID: <E1TWtZN-0000PS-D0@sfp-svn-3.v30.ch3.sourceforge.com>

Revision: 9438
          http://opensips.svn.sourceforge.net/opensips/?rev=9438&view=rev
Author:   osas
Date:     2012-11-09 18:44:45 +0000 (Fri, 09 Nov 2012)
Log Message:
-----------
drouting: remove bogus semicolon in structure declaration
          (most likely a copy/paste error)
           backport from trunk (rev 9437)

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

Modified Paths:
--------------
    branches/1.8/modules/drouting/prefix_tree.h

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



From osas at voipembedded.com  Fri Nov  9 20:08:52 2012
From: osas at voipembedded.com (Ovidiu Sas)
Date: Fri, 09 Nov 2012 19:08:52 +0000
Subject: [OpenSIPS-Devel] SF.net SVN: opensips:[9439]
	trunk/menuconfig/Makefile
Message-ID: <E1TWtwi-0001lb-Er@sfp-svn-3.v30.ch3.sourceforge.com>

Revision: 9439
          http://opensips.svn.sourceforge.net/opensips/?rev=9439&view=rev
Author:   osas
Date:     2012-11-09 19:08:52 +0000 (Fri, 09 Nov 2012)
Log Message:
-----------
menuconfig: pass extra options to enable proper cross compilation

Modified Paths:
--------------
    trunk/menuconfig/Makefile

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



From noreply at sourceforge.net  Fri Nov  9 20:40:57 2012
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 09 Nov 2012 11:40:57 -0800
Subject: [OpenSIPS-Devel] [ opensips-Bugs-3585696 ] Crash due to mi commands
Message-ID: <mailman.1185.1352490062.13469.devel@lists.opensips.org>

Bugs item #3585696, was opened at 2012-11-09 03:39
Message generated for change (Comment added) made by digipigeon
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=3585696&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: Digipigeon (digipigeon)
Assigned to: Nobody/Anonymous (nobody)
Summary: Crash due to mi commands

Initial Comment:
I am getting repeated crashing on my three X 1.8.2 opensips servers, also some crashing on my 1.7.1.

The problem appears to be more noticeable when the profile_get_values is called frequently (every few seconds), however I cant confirm isolation of this command causes the crash.

Please see attached (gdb) bt full

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

>Comment By: Digipigeon (digipigeon)
Date: 2012-11-09 11:40

Message:
Hi Bogdan,

There was nothing in the log files relevant, it just crashes without any
response.

I am not sure if I have correctly ran the commands, but I get the
following:

(gdb) f 0 brother
#0  0x7663723a65726f63 in ?? ()

(gdb) f 0 *brother
Cannot access memory at address 0x7663723a65726f63

(gdb) f 0 name
value has been optimised out

(gdb) f 0 value
value has been optimised out

(gdb) f 0 *brother->next
Cannot access memory at address 0x7663723a65726f93

Sorry if this is not correct.

Kind Regards

Jonathan

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

Comment By: Bogdan-Andrei Iancu (bogdan_iancu)
Date: 2012-11-09 09:32

Message:
Hi,

1) do you see in the logs any err message before the crash (from the same
process) ?

2) in gdb, frame 0, please print : brother, *brother, name, value,
*brother->next .

Thanks and regards,
Bogdan

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

Comment By: Digipigeon (digipigeon)
Date: 2012-11-09 07:09

Message:
The only parameter that I have programmed in for get_statistics is the
parameter "all", this is ran through xmlrpc

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

Comment By: Razvan Crainea (razvancrainea)
Date: 2012-11-09 06:22

Message:
Hi!

The core you attached does not contain any indications that the cause of
the crash are the dialog profiles, but rather some statistics you are
fetching through MI. Can you provide us the exact MI command you are
running?

Best regards,
R?zvan

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

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


From noreply at sourceforge.net  Fri Nov  9 21:42:08 2012
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 09 Nov 2012 12:42:08 -0800
Subject: [OpenSIPS-Devel] [ opensips-Bugs-3585696 ] Crash due to mi commands
Message-ID: <mailman.1186.1352493733.13469.devel@lists.opensips.org>

Bugs item #3585696, was opened at 2012-11-09 03:39
Message generated for change (Comment added) made by bogdan_iancu
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=3585696&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: Digipigeon (digipigeon)
Assigned to: Nobody/Anonymous (nobody)
Summary: Crash due to mi commands

Initial Comment:
I am getting repeated crashing on my three X 1.8.2 opensips servers, also some crashing on my 1.7.1.

The problem appears to be more noticeable when the profile_get_values is called frequently (every few seconds), however I cant confirm isolation of this command causes the crash.

Please see attached (gdb) bt full

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

>Comment By: Bogdan-Andrei Iancu (bogdan_iancu)
Date: 2012-11-09 12:42

Message:
Jonathan,

Once you are in gdb, run the commands:

f 0
p brother
p *brother
p name
p value
p *brother->name 

Regards,
Bogdan

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

Comment By: Digipigeon (digipigeon)
Date: 2012-11-09 11:40

Message:
Hi Bogdan,

There was nothing in the log files relevant, it just crashes without any
response.

I am not sure if I have correctly ran the commands, but I get the
following:

(gdb) f 0 brother
#0  0x7663723a65726f63 in ?? ()

(gdb) f 0 *brother
Cannot access memory at address 0x7663723a65726f63

(gdb) f 0 name
value has been optimised out

(gdb) f 0 value
value has been optimised out

(gdb) f 0 *brother->next
Cannot access memory at address 0x7663723a65726f93

Sorry if this is not correct.

Kind Regards

Jonathan

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

Comment By: Bogdan-Andrei Iancu (bogdan_iancu)
Date: 2012-11-09 09:32

Message:
Hi,

1) do you see in the logs any err message before the crash (from the same
process) ?

2) in gdb, frame 0, please print : brother, *brother, name, value,
*brother->next .

Thanks and regards,
Bogdan

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

Comment By: Digipigeon (digipigeon)
Date: 2012-11-09 07:09

Message:
The only parameter that I have programmed in for get_statistics is the
parameter "all", this is ran through xmlrpc

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

Comment By: Razvan Crainea (razvancrainea)
Date: 2012-11-09 06:22

Message:
Hi!

The core you attached does not contain any indications that the cause of
the crash are the dialog profiles, but rather some statistics you are
fetching through MI. Can you provide us the exact MI command you are
running?

Best regards,
R?zvan

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

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


From noreply at sourceforge.net  Fri Nov  9 22:12:15 2012
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 09 Nov 2012 13:12:15 -0800
Subject: [OpenSIPS-Devel] [ opensips-Bugs-3585696 ] Crash due to mi commands
Message-ID: <mailman.1187.1352495541.13469.devel@lists.opensips.org>

Bugs item #3585696, was opened at 2012-11-09 03:39
Message generated for change (Comment added) made by digipigeon
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=3585696&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: Digipigeon (digipigeon)
Assigned to: Nobody/Anonymous (nobody)
Summary: Crash due to mi commands

Initial Comment:
I am getting repeated crashing on my three X 1.8.2 opensips servers, also some crashing on my 1.7.1.

The problem appears to be more noticeable when the profile_get_values is called frequently (every few seconds), however I cant confirm isolation of this command causes the crash.

Please see attached (gdb) bt full

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

>Comment By: Digipigeon (digipigeon)
Date: 2012-11-09 13:12

Message:
Hi Bogdan,

Thanks for the explanation. Please see the following output:

(gdb) f 0
#0  add_next (flags=2, value_len=26, value=<optimised out>,
name_len=<optimised out>, name=<optimised out>, brother=0x7663723a65726f63)
at mi/tree.c:184
184             brother->last->next = new;
(gdb) p brother
$1 = (struct mi_node *) 0x7663723a65726f63
(gdb) p *brother
Cannot access memory at address 0x7663723a65726f63
(gdb) p name
$2 = <optimised out>
(gdb) p value
$3 = <optimised out>
(gdb) p *brother->name
Structure has no component named operator*.

Kind Regards

Jonathan.

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

Comment By: Bogdan-Andrei Iancu (bogdan_iancu)
Date: 2012-11-09 12:42

Message:
Jonathan,

Once you are in gdb, run the commands:

f 0
p brother
p *brother
p name
p value
p *brother->name 

Regards,
Bogdan

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

Comment By: Digipigeon (digipigeon)
Date: 2012-11-09 11:40

Message:
Hi Bogdan,

There was nothing in the log files relevant, it just crashes without any
response.

I am not sure if I have correctly ran the commands, but I get the
following:

(gdb) f 0 brother
#0  0x7663723a65726f63 in ?? ()

(gdb) f 0 *brother
Cannot access memory at address 0x7663723a65726f63

(gdb) f 0 name
value has been optimised out

(gdb) f 0 value
value has been optimised out

(gdb) f 0 *brother->next
Cannot access memory at address 0x7663723a65726f93

Sorry if this is not correct.

Kind Regards

Jonathan

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

Comment By: Bogdan-Andrei Iancu (bogdan_iancu)
Date: 2012-11-09 09:32

Message:
Hi,

1) do you see in the logs any err message before the crash (from the same
process) ?

2) in gdb, frame 0, please print : brother, *brother, name, value,
*brother->next .

Thanks and regards,
Bogdan

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

Comment By: Digipigeon (digipigeon)
Date: 2012-11-09 07:09

Message:
The only parameter that I have programmed in for get_statistics is the
parameter "all", this is ran through xmlrpc

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

Comment By: Razvan Crainea (razvancrainea)
Date: 2012-11-09 06:22

Message:
Hi!

The core you attached does not contain any indications that the cause of
the crash are the dialog profiles, but rather some statistics you are
fetching through MI. Can you provide us the exact MI command you are
running?

Best regards,
R?zvan

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

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


From noreply at sourceforge.net  Fri Nov  9 22:34:38 2012
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 09 Nov 2012 13:34:38 -0800
Subject: [OpenSIPS-Devel] [ opensips-Bugs-3585696 ] Crash due to mi commands
Message-ID: <mailman.1188.1352496882.13469.devel@lists.opensips.org>

Bugs item #3585696, was opened at 2012-11-09 03:39
Message generated for change (Comment added) made by bogdan_iancu
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=3585696&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: Digipigeon (digipigeon)
Assigned to: Nobody/Anonymous (nobody)
Summary: Crash due to mi commands

Initial Comment:
I am getting repeated crashing on my three X 1.8.2 opensips servers, also some crashing on my 1.7.1.

The problem appears to be more noticeable when the profile_get_values is called frequently (every few seconds), however I cant confirm isolation of this command causes the crash.

Please see attached (gdb) bt full

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

>Comment By: Bogdan-Andrei Iancu (bogdan_iancu)
Date: 2012-11-09 13:34

Message:
Ok, it seems the "brother" pointer is overwritten - the pointer is not a
valid mem addrs, but decoded as hexa is "core:rcv" which is a statistic
name.
Please try more:

f 1
p parent
p *parent
f 4
p *rpl

Also is there any why to get access to the core to speed up the debugging
?

Regards,

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

Comment By: Digipigeon (digipigeon)
Date: 2012-11-09 13:12

Message:
Hi Bogdan,

Thanks for the explanation. Please see the following output:

(gdb) f 0
#0  add_next (flags=2, value_len=26, value=<optimised out>,
name_len=<optimised out>, name=<optimised out>, brother=0x7663723a65726f63)
at mi/tree.c:184
184             brother->last->next = new;
(gdb) p brother
$1 = (struct mi_node *) 0x7663723a65726f63
(gdb) p *brother
Cannot access memory at address 0x7663723a65726f63
(gdb) p name
$2 = <optimised out>
(gdb) p value
$3 = <optimised out>
(gdb) p *brother->name
Structure has no component named operator*.

Kind Regards

Jonathan.

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

Comment By: Bogdan-Andrei Iancu (bogdan_iancu)
Date: 2012-11-09 12:42

Message:
Jonathan,

Once you are in gdb, run the commands:

f 0
p brother
p *brother
p name
p value
p *brother->name 

Regards,
Bogdan

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

Comment By: Digipigeon (digipigeon)
Date: 2012-11-09 11:40

Message:
Hi Bogdan,

There was nothing in the log files relevant, it just crashes without any
response.

I am not sure if I have correctly ran the commands, but I get the
following:

(gdb) f 0 brother
#0  0x7663723a65726f63 in ?? ()

(gdb) f 0 *brother
Cannot access memory at address 0x7663723a65726f63

(gdb) f 0 name
value has been optimised out

(gdb) f 0 value
value has been optimised out

(gdb) f 0 *brother->next
Cannot access memory at address 0x7663723a65726f93

Sorry if this is not correct.

Kind Regards

Jonathan

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

Comment By: Bogdan-Andrei Iancu (bogdan_iancu)
Date: 2012-11-09 09:32

Message:
Hi,

1) do you see in the logs any err message before the crash (from the same
process) ?

2) in gdb, frame 0, please print : brother, *brother, name, value,
*brother->next .

Thanks and regards,
Bogdan

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

Comment By: Digipigeon (digipigeon)
Date: 2012-11-09 07:09

Message:
The only parameter that I have programmed in for get_statistics is the
parameter "all", this is ran through xmlrpc

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

Comment By: Razvan Crainea (razvancrainea)
Date: 2012-11-09 06:22

Message:
Hi!

The core you attached does not contain any indications that the cause of
the crash are the dialog profiles, but rather some statistics you are
fetching through MI. Can you provide us the exact MI command you are
running?

Best regards,
R?zvan

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

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


From noreply at sourceforge.net  Fri Nov  9 22:52:17 2012
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 09 Nov 2012 13:52:17 -0800
Subject: [OpenSIPS-Devel] [ opensips-Bugs-3585696 ] Crash due to mi commands
Message-ID: <mailman.1189.1352497942.13469.devel@lists.opensips.org>

Bugs item #3585696, was opened at 2012-11-09 03:39
Message generated for change (Comment added) made by digipigeon
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=3585696&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: Digipigeon (digipigeon)
Assigned to: Nobody/Anonymous (nobody)
Summary: Crash due to mi commands

Initial Comment:
I am getting repeated crashing on my three X 1.8.2 opensips servers, also some crashing on my 1.7.1.

The problem appears to be more noticeable when the profile_get_values is called frequently (every few seconds), however I cant confirm isolation of this command causes the crash.

Please see attached (gdb) bt full

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

>Comment By: Digipigeon (digipigeon)
Date: 2012-11-09 13:52

Message:
Hi Bogdan,

The results of your requested commands is as follows:

(gdb) f 1
#1  add_mi_node_child (value_len=26, value=<optimised out>,
name_len=<optimised out>, name=<optimised out>, flags=2, parent=<optimised
out>) at mi/tree.c:219
219                     return add_next(parent->kids, name, name_len,
value, value_len, flags);
(gdb) p parent
$1 = <optimised out>
(gdb) p *parent
value has been optimised out
(gdb) f 4
#4  mi_get_stats (cmd=<optimised out>, param=<optimised out>) at
statistics.c:535
535                                     if (mi_add_module_stats( rpl,
&collector->amodules[i] )!=0)
(gdb) p *rpl
$2 = {value = {s = 0x2 <Address 0x2 out of bounds>, len = 0}, name = {s =
0x0, len = -840856056}, flags = 0, kids = 0x7663723a65726f63, next =
0x7365696c7065725f,
  last = 0x3730393134203d20, attributes = 0x33}

The dump is 2.1GB, I will get this somewhere you can access it.

Kind Regards

Jonathan

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

Comment By: Bogdan-Andrei Iancu (bogdan_iancu)
Date: 2012-11-09 13:34

Message:
Ok, it seems the "brother" pointer is overwritten - the pointer is not a
valid mem addrs, but decoded as hexa is "core:rcv" which is a statistic
name.
Please try more:

f 1
p parent
p *parent
f 4
p *rpl

Also is there any why to get access to the core to speed up the debugging
?

Regards,

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

Comment By: Digipigeon (digipigeon)
Date: 2012-11-09 13:12

Message:
Hi Bogdan,

Thanks for the explanation. Please see the following output:

(gdb) f 0
#0  add_next (flags=2, value_len=26, value=<optimised out>,
name_len=<optimised out>, name=<optimised out>, brother=0x7663723a65726f63)
at mi/tree.c:184
184             brother->last->next = new;
(gdb) p brother
$1 = (struct mi_node *) 0x7663723a65726f63
(gdb) p *brother
Cannot access memory at address 0x7663723a65726f63
(gdb) p name
$2 = <optimised out>
(gdb) p value
$3 = <optimised out>
(gdb) p *brother->name
Structure has no component named operator*.

Kind Regards

Jonathan.

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

Comment By: Bogdan-Andrei Iancu (bogdan_iancu)
Date: 2012-11-09 12:42

Message:
Jonathan,

Once you are in gdb, run the commands:

f 0
p brother
p *brother
p name
p value
p *brother->name 

Regards,
Bogdan

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

Comment By: Digipigeon (digipigeon)
Date: 2012-11-09 11:40

Message:
Hi Bogdan,

There was nothing in the log files relevant, it just crashes without any
response.

I am not sure if I have correctly ran the commands, but I get the
following:

(gdb) f 0 brother
#0  0x7663723a65726f63 in ?? ()

(gdb) f 0 *brother
Cannot access memory at address 0x7663723a65726f63

(gdb) f 0 name
value has been optimised out

(gdb) f 0 value
value has been optimised out

(gdb) f 0 *brother->next
Cannot access memory at address 0x7663723a65726f93

Sorry if this is not correct.

Kind Regards

Jonathan

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

Comment By: Bogdan-Andrei Iancu (bogdan_iancu)
Date: 2012-11-09 09:32

Message:
Hi,

1) do you see in the logs any err message before the crash (from the same
process) ?

2) in gdb, frame 0, please print : brother, *brother, name, value,
*brother->next .

Thanks and regards,
Bogdan

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

Comment By: Digipigeon (digipigeon)
Date: 2012-11-09 07:09

Message:
The only parameter that I have programmed in for get_statistics is the
parameter "all", this is ran through xmlrpc

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

Comment By: Razvan Crainea (razvancrainea)
Date: 2012-11-09 06:22

Message:
Hi!

The core you attached does not contain any indications that the cause of
the crash are the dialog profiles, but rather some statistics you are
fetching through MI. Can you provide us the exact MI command you are
running?

Best regards,
R?zvan

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

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


From saghul at users.sourceforge.net  Mon Nov 12 11:05:24 2012
From: saghul at users.sourceforge.net (saghul at users.sourceforge.net)
Date: Mon, 12 Nov 2012 10:05:24 +0000
Subject: [OpenSIPS-Devel] SF.net SVN: opensips:[9440]
	trunk/modules/rls/resource_notify.c
Message-ID: <E1TXqtQ-0002HK-OX@sfp-svn-3.v30.ch3.sourceforge.com>

Revision: 9440
          http://opensips.svn.sourceforge.net/opensips/?rev=9440&view=rev
Author:   saghul
Date:     2012-11-12 10:05:24 +0000 (Mon, 12 Nov 2012)
Log Message:
-----------
Fixed possible infinite loop when parsing Subscription-State expires value

Modified Paths:
--------------
    trunk/modules/rls/resource_notify.c

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



From noreply at sourceforge.net  Tue Nov 13 01:42:15 2012
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 12 Nov 2012 16:42:15 -0800
Subject: [OpenSIPS-Devel] [ opensips-Bugs-3586532 ] [avpops] avp_print()
	Doesn't Print AVP Name
Message-ID: <mailman.1190.1352767338.13469.devel@lists.opensips.org>

Bugs item #3586532, was opened at 2012-11-12 16:42
Message generated for change (Tracker Item Submitted) made by dmsanders
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=3586532&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.8.x
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: David Sanders (dmsanders)
Assigned to: Nobody/Anonymous (nobody)
Summary: [avpops] avp_print() Doesn't Print AVP Name

Initial Comment:
If using named AVPs in a script, using avp_print() from avpops to try to debug does not provide the names, only the IDs used internally. This makes it hard to match up the script AVPs with the output.

Here's some example output from two named AVPs:

osips[8196]: INFO:avpops:ops_print_avp:                     id=<27> 
osips[8196]: INFO:avpops:ops_print_avp:                     val_str=<1919XXXXXXX / 11> 
osips[8196]: INFO:avpops:ops_print_avp: p=0x2b8c825daa18, flags=0x0002 
osips[8196]: INFO:avpops:ops_print_avp:                     id=<18> 
osips[8196]: INFO:avpops:ops_print_avp:                     val_str=<1831XXXXXXX / 11> 

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

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


From noreply at sourceforge.net  Tue Nov 13 16:03:11 2012
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue, 13 Nov 2012 07:03:11 -0800
Subject: [OpenSIPS-Devel] [ opensips-Bugs-3586730 ] $var variables cleanup
	on new request
Message-ID: <mailman.1192.1352818995.13469.devel@lists.opensips.org>

Bugs item #3586730, was opened at 2012-11-13 07:03
Message generated for change (Tracker Item Submitted) made by nikbyte
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=3586730&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.8.x
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Nick Altmann (nikbyte)
Assigned to: Nobody/Anonymous (nobody)
Summary: $var variables cleanup on new request

Initial Comment:
I found that in my script I do something like (the same tail of every log message is because of m4 macros):

route {
    xlog("L_INFO", "[MAIN] log message [$var(info)]");
    $var(info) = "blablabla";
    xlog("L_INFO", "[MAIN] another message [$var(info)]");
}

Interesting that in first xlog the $var(info) is not null ! 
And instead of "null" I see there something interesting values from other client's requests.

I think we should clean up all $var variables before request, shouldn't we?


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

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


From noreply at sourceforge.net  Tue Nov 13 16:44:54 2012
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue, 13 Nov 2012 07:44:54 -0800
Subject: [OpenSIPS-Devel] [ opensips-Bugs-3586730 ] $var variables cleanup
	on new request
Message-ID: <mailman.1193.1352821502.13469.devel@lists.opensips.org>

Bugs item #3586730, was opened at 2012-11-13 07:03
Message generated for change (Comment added) made by denodaeus
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=3586730&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.8.x
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Nick Altmann (nikbyte)
Assigned to: Nobody/Anonymous (nobody)
Summary: $var variables cleanup on new request

Initial Comment:
I found that in my script I do something like (the same tail of every log message is because of m4 macros):

route {
    xlog("L_INFO", "[MAIN] log message [$var(info)]");
    $var(info) = "blablabla";
    xlog("L_INFO", "[MAIN] another message [$var(info)]");
}

Interesting that in first xlog the $var(info) is not null ! 
And instead of "null" I see there something interesting values from other client's requests.

I think we should clean up all $var variables before request, shouldn't we?


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

Comment By: Robert Smith (denodaeus)
Date: 2012-11-13 07:44

Message:
I've been bitten by this before, but it's intentional.  From the docs:

http://www.opensips.org/Resources/DocsCoreVar18#varscript

1.  if you want to start using a script variable in a route, better
initialize it with same value (or reset it), otherwise you may inherit a
value from a previous route that was executed by the same process.
3. the value of script variables persists over a OpenSIPS process.

So you can either initialize it to the same default value every time, or
you can use something transactional instead (like avp's).



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

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


From noreply at sourceforge.net  Tue Nov 13 20:03:34 2012
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue, 13 Nov 2012 11:03:34 -0800
Subject: [OpenSIPS-Devel] [ opensips-Bugs-3586775 ] Dialog Ping
Message-ID: <mailman.1194.1352833419.13469.devel@lists.opensips.org>

Bugs item #3586775, was opened at 2012-11-13 11:03
Message generated for change (Tracker Item Submitted) made by kaduww
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=3586775&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.8.x
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Carlos Eduardo Wagner (kaduww)
Assigned to: Nobody/Anonymous (nobody)
Summary: Dialog Ping

Initial Comment:
I'm having some problems with the Dialog Ping when using another port different from the 5060.
My opensips is listening on both ports, 5060 and 5062 and, as the trace attached, when the client is sending requests to the port 5062 and the dialog is created, the Dialog Ping sends the OPTIONS packet from the port 5060. Because of this, my client's NAT is blocking the packet, because its mapped to the port 5062 and not the 5060.

Follow the dialog information:
root at sipstage:/home/suporte# opensipsctl fifo dlg_list
dialog::  hash=2536:1633827324
	state:: 4
	user_flags:: 0
	timestart:: 1352831188
	timeout:: 1352838388
	callid:: a4e155f4320d43b9be48fde6457150ee
	from_uri:: sip:P0000000001 at sipstage.pligg.com.br
	to_uri:: sip:05130227701 at sipstage.pligg.com.br
	caller_tag:: 6fe6c313c92742a392fd75740f8867d7
	caller_contact:: sip:P0000000001 at 177.97.125.92:4057;ob
	callee_cseq:: 0
	caller_route_set:: 
	caller_bind_addr:: udp:177.129.74.30:5062
	callee_tag:: a94c095b773be1dd6e8d668a785a9c8470442779
	callee_contact:: sip:05130227701 at 201.56.167.2:5060
	caller_cseq:: 31678
	callee_route_set:: <sip:201.33.209.42;lr;did=8e96.0e1aebe1>,<sip:201.33.209.194;lr=on;did=8e9.c48a6f3>
	callee_bind_addr:: udp:177.129.74.30:5062

Here follows the OPTIONS part of the Trace:
U 2012/11/13 16:28:59.522813 177.129.74.30:5060 -> 177.97.125.92:4050
OPTIONS sip:P0000000025 at 177.97.125.92:4050;ob SIP/2.0.
Via: SIP/2.0/UDP 177.129.74.30:5062;branch=z9hG4bKf915.ddfebd02.0.
To: <sip:P0000000025 at sipstage.pligg.com.br>;tag=6caf1d8cdc4645719b25a6e120c90679.
From: <sip:05130227701 at sipstage.pligg.com.br>;tag=a94c095b773be1dd6e8d668a785a9c849cb5c894.
CSeq: 1 OPTIONS.
Call-ID: 433b8548a3944c2ea03a4a9cf2ce0bc4.
Max-Forwards: 70.
Content-Length: 0.
User-Agent: OpenSIPS (1.8.2-notls (x86_64/linux)).

* The SIP Trace attached was made while using the Opensips 1.8.1, but I did the test with the newest 1.8.x version e the problem was the same.

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

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


From noreply at sourceforge.net  Wed Nov 14 17:43:47 2012
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed, 14 Nov 2012 08:43:47 -0800
Subject: [OpenSIPS-Devel] [ opensips-Bugs-3587163 ] Commit #9295 breaks AVP
Message-ID: <mailman.1195.1352911432.13469.devel@lists.opensips.org>

Bugs item #3587163, was opened at 2012-11-14 08:43
Message generated for change (Tracker Item Submitted) made by dpacket
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=3587163&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.8.x
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Dynamic Packet (dpacket)
Assigned to: Nobody/Anonymous (nobody)
Summary: Commit #9295 breaks AVP

Initial Comment:
It seems commit #9295 on 1.8 branch breaks AVP in certain cases. Opensips starts fine and some avp related stuff works, but certain scenarios cause this: 

Nov 14 11:13:40 ip-10-173-81-249 /usr/sbin/opensips[1042]: ERROR:core:new_avp: invalid AVP name!
Nov 14 11:13:40 ip-10-173-81-249 /usr/sbin/opensips[1042]: ERROR:core:add_avp: Failed to create new avp structure

Script now does not execute as it should and in the end cause failures in call processing.  Its possible this also effects trunk (commit #9294) . I have tested by reverting this single commit (#9295) in most resent stable 1.8 and issue is resolved.

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

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


From saghul at users.sourceforge.net  Wed Nov 14 17:46:11 2012
From: saghul at users.sourceforge.net (saghul at users.sourceforge.net)
Date: Wed, 14 Nov 2012 16:46:11 +0000
Subject: [OpenSIPS-Devel] SF.net SVN: opensips:[9441] trunk
Message-ID: <E1TYg6N-00018J-7b@sfp-svn-3.v30.ch3.sourceforge.com>

Revision: 9441
          http://opensips.svn.sourceforge.net/opensips/?rev=9441&view=rev
Author:   saghul
Date:     2012-11-14 16:46:10 +0000 (Wed, 14 Nov 2012)
Log Message:
-----------
Added new XCAP module

It contains common XCAP settings and functions, the presence_xml, rls
and xcap_client modules have been adapted to use this new module and
thus depend on it.

Modified Paths:
--------------
    trunk/Makefile.conf
    trunk/modules/presence_xml/presence_xml.c
    trunk/modules/rls/notify.c
    trunk/modules/rls/rls.c
    trunk/modules/rls/rls.h
    trunk/modules/xcap_client/xcap_client.c
    trunk/modules/xcap_client/xcap_functions.c
    trunk/modules/xcap_client/xcap_functions.h
    trunk/packaging/debian/rules
    trunk/packaging/debian-lenny/rules
    trunk/packaging/fedora/opensips.spec
    trunk/packaging/gentoo/opensips-1.8.0.ebuild
    trunk/packaging/rpm/opensips.spec.CentOS
    trunk/packaging/rpm/opensips.spec.SuSE

Added Paths:
-----------
    trunk/modules/xcap/
    trunk/modules/xcap/Makefile
    trunk/modules/xcap/api.c
    trunk/modules/xcap/api.h
    trunk/modules/xcap/doc/
    trunk/modules/xcap/doc/xcap.xml
    trunk/modules/xcap/doc/xcap_admin.xml
    trunk/modules/xcap/doc/xcap_devel.xml
    trunk/modules/xcap/uri.c
    trunk/modules/xcap/uri.h
    trunk/modules/xcap/xcap_mod.c
    trunk/modules/xcap/xcap_mod.h

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



From saghul at users.sourceforge.net  Wed Nov 14 17:46:37 2012
From: saghul at users.sourceforge.net (saghul at users.sourceforge.net)
Date: Wed, 14 Nov 2012 16:46:37 +0000
Subject: [OpenSIPS-Devel] SF.net SVN: opensips:[9442] trunk/modules
Message-ID: <E1TYg6n-0001B3-Ow@sfp-svn-3.v30.ch3.sourceforge.com>

Revision: 9442
          http://opensips.svn.sourceforge.net/opensips/?rev=9442&view=rev
Author:   saghul
Date:     2012-11-14 16:46:37 +0000 (Wed, 14 Nov 2012)
Log Message:
-----------
Updated documentation with API changes

presence_xml, rls and xcap_client modules

Modified Paths:
--------------
    trunk/modules/presence_xml/doc/presence_xml_admin.xml
    trunk/modules/rls/doc/rls_admin.xml
    trunk/modules/xcap_client/doc/xcap_client.xml
    trunk/modules/xcap_client/doc/xcap_client_admin.xml
    trunk/modules/xcap_client/doc/xcap_client_devel.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  Wed Nov 14 17:52:33 2012
From: saul at ag-projects.com (=?iso-8859-1?Q?Sa=FAl_Ibarra_Corretg=E9?=)
Date: Wed, 14 Nov 2012 17:52:33 +0100
Subject: [OpenSIPS-Devel] [OpenSIPS 1.9] Winter cleanup: XCAP
In-Reply-To: <DA1A936B-B96B-4808-919E-0E590D78548E@ag-projects.com>
References: <DA1A936B-B96B-4808-919E-0E590D78548E@ag-projects.com>
Message-ID: <BBE6C382-E67C-4C3F-871D-DA7D80788FA9@ag-projects.com>

Hi all,

Sorry for the late response, I've been busy with the overwhelming amount of replies ;-)

So, I just committed the first part of this, the new 'xcap' module. It exports the db_url, xcap_table and intergrated_server parameters and a single function (for now) parse_xcap_uri. I modified presence_xml, rls and xcap_client to make use of these.

Next step will be to merge my OMA external references support code and move some more common code to this new xcap module.

This is only present in trunk, but if anyone runs into issues related to this please let me know.


Regards,

On Nov 8, 2012, at 11:05 AM, Sa?l Ibarra Corretg? wrote:

> Hi all,
> 
> I've been working for quite a while now in adding external references to RLS and pres-rules documents following IETF and OMA specifications respectively. And it works! \o/ In the process I noticed there is common behavior that can be factored out of rls and presence_xml modules. So, my plan is to create a new module called "xcap" (surprise surprise!) which encapsulates XCAP related stuff and then both rls and presence_xml would use it in conjunction with xcap_client.
> 
> These are the main things that would go into the new xcap module:
> 
> 	- xcap_table: table where documents are stored
> 	- integrated_xcap_server: boolean flag indicating if a integrated server (as OpenXCAP) is in use or xcap_client should be used instead
> 	- xcap_server: list of local XCAP servers
> 	- functions to load arbitrary XCAP documents from DB
> 	- functions to load an arbitrary node from a document using XPath
> 	- XCAP URI parsing
> 
> Note that this change implies that the same table is used for XCAP documents for both Presence and RLS. I see no reason to keep separated parameters in RLS and Presence modules, so if anyone has a good reason for it, please speak up so I can convince you otherwise :-)
> 
> 
> OMA pres-rules related changes:
> 
> Currently the pres_rules_auid and pres_rules_filename options are only used in non-integrated XCAP mode, and pres_rules_auid may take any value. The value for pres_rules_auid will be constrained to "pres-rules" or "org.openmobilealliance.pres-rules" and will also be used in integrated mode. The chosen AUID defines how the policy is applied, either following IETF rules or OMA rules. After this implementation is complete, a way for choosing the policy type per subscriber will be researched.
> 
> Right now both IETF and OMA pres-rules documents are stored with the same "doc_type" thus overriding each other. This will no longer be the case. Users will be able to store both types of documents and the proxy will apply the rules according to the configured AUID. OpenXCAP will also be modified accordingly.
> 
> 
> About xcap_server configuration option:
> 
> Currently it's only used in non-integrated mode, but it's also needed in integrated mode on order to know if a reference is local or not and thus if it should be followed or not.
> 
> 
> You made it this far! Great, what is your take on this?
> 
> Regards,
> 
> --
> Sa?l Ibarra Corretg?
> AG Projects
> 
> 
> 
> 
> _______________________________________________
> Devel mailing list
> Devel at lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/devel

--
Sa?l Ibarra Corretg?
AG Projects





From noreply at sourceforge.net  Wed Nov 14 17:55:46 2012
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed, 14 Nov 2012 08:55:46 -0800
Subject: [OpenSIPS-Devel] [ opensips-Bugs-3587163 ] Commit #9295 breaks AVP
Message-ID: <mailman.1196.1352912151.13469.devel@lists.opensips.org>

Bugs item #3587163, was opened at 2012-11-14 08:43
Message generated for change (Comment added) made by razvancrainea
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=3587163&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.8.x
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Dynamic Packet (dpacket)
Assigned to: Nobody/Anonymous (nobody)
Summary: Commit #9295 breaks AVP

Initial Comment:
It seems commit #9295 on 1.8 branch breaks AVP in certain cases. Opensips starts fine and some avp related stuff works, but certain scenarios cause this: 

Nov 14 11:13:40 ip-10-173-81-249 /usr/sbin/opensips[1042]: ERROR:core:new_avp: invalid AVP name!
Nov 14 11:13:40 ip-10-173-81-249 /usr/sbin/opensips[1042]: ERROR:core:add_avp: Failed to create new avp structure

Script now does not execute as it should and in the end cause failures in call processing.  Its possible this also effects trunk (commit #9294) . I have tested by reverting this single commit (#9295) in most resent stable 1.8 and issue is resolved.

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

>Comment By: Razvan Crainea (razvancrainea)
Date: 2012-11-14 08:55

Message:
Hi!

Can you tell us when do you receive those errors? Is it a certain function
that uses AVPs and cannot find them?

Regards,
R?zvan

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

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


From noreply at sourceforge.net  Wed Nov 14 18:01:53 2012
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed, 14 Nov 2012 09:01:53 -0800
Subject: [OpenSIPS-Devel] [ opensips-Bugs-3587163 ] Commit #9295 breaks AVP
Message-ID: <mailman.1197.1352912517.13469.devel@lists.opensips.org>

Bugs item #3587163, was opened at 2012-11-14 08:43
Message generated for change (Comment added) made by dpacket
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=3587163&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.8.x
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Dynamic Packet (dpacket)
Assigned to: Nobody/Anonymous (nobody)
Summary: Commit #9295 breaks AVP

Initial Comment:
It seems commit #9295 on 1.8 branch breaks AVP in certain cases. Opensips starts fine and some avp related stuff works, but certain scenarios cause this: 

Nov 14 11:13:40 ip-10-173-81-249 /usr/sbin/opensips[1042]: ERROR:core:new_avp: invalid AVP name!
Nov 14 11:13:40 ip-10-173-81-249 /usr/sbin/opensips[1042]: ERROR:core:add_avp: Failed to create new avp structure

Script now does not execute as it should and in the end cause failures in call processing.  Its possible this also effects trunk (commit #9294) . I have tested by reverting this single commit (#9295) in most resent stable 1.8 and issue is resolved.

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

>Comment By: Dynamic Packet (dpacket)
Date: 2012-11-14 09:01

Message:
Hi Razvan,

I'm not 100% sure what function and I am unable to test at the moment. But
looking at the area of the script it occurs in, it could be ds_select_ds,
append_hf, xlog or least likely script comparisons/assignments.

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

Comment By: Razvan Crainea (razvancrainea)
Date: 2012-11-14 08:55

Message:
Hi!

Can you tell us when do you receive those errors? Is it a certain function
that uses AVPs and cannot find them?

Regards,
R?zvan

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

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


From saghul at users.sourceforge.net  Wed Nov 14 18:06:03 2012
From: saghul at users.sourceforge.net (saghul at users.sourceforge.net)
Date: Wed, 14 Nov 2012 17:06:03 +0000
Subject: [OpenSIPS-Devel] SF.net SVN: opensips:[9443] trunk/modules
Message-ID: <E1TYgPb-0004lp-Qh@sfp-svn-4.v30.ch3.sourceforge.com>

Revision: 9443
          http://opensips.svn.sourceforge.net/opensips/?rev=9443&view=rev
Author:   saghul
Date:     2012-11-14 17:06:03 +0000 (Wed, 14 Nov 2012)
Log Message:
-----------
Regenerated README files for presence_xml, rls, xcap and xcap_client modules

Modified Paths:
--------------
    trunk/modules/presence_xml/README
    trunk/modules/rls/README
    trunk/modules/xcap/doc/xcap_admin.xml
    trunk/modules/xcap/doc/xcap_devel.xml
    trunk/modules/xcap_client/README

Added Paths:
-----------
    trunk/modules/xcap/README

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



From noreply at sourceforge.net  Wed Nov 14 19:29:17 2012
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed, 14 Nov 2012 10:29:17 -0800
Subject: [OpenSIPS-Devel] [ opensips-Bugs-3587163 ] Commit #9295 breaks
	dispatcher
Message-ID: <mailman.1198.1352917760.13469.devel@lists.opensips.org>

Bugs item #3587163, was opened at 2012-11-14 08:43
Message generated for change (Comment added) made by dpacket
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=3587163&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.8.x
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Dynamic Packet (dpacket)
Assigned to: Nobody/Anonymous (nobody)
>Summary: Commit #9295 breaks dispatcher

Initial Comment:
It seems commit #9295 on 1.8 branch breaks AVP in certain cases. Opensips starts fine and some avp related stuff works, but certain scenarios cause this: 

Nov 14 11:13:40 ip-10-173-81-249 /usr/sbin/opensips[1042]: ERROR:core:new_avp: invalid AVP name!
Nov 14 11:13:40 ip-10-173-81-249 /usr/sbin/opensips[1042]: ERROR:core:add_avp: Failed to create new avp structure

Script now does not execute as it should and in the end cause failures in call processing.  Its possible this also effects trunk (commit #9294) . I have tested by reverting this single commit (#9295) in most resent stable 1.8 and issue is resolved.

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

>Comment By: Dynamic Packet (dpacket)
Date: 2012-11-14 10:29

Message:
This is a bug in dispatcher module. If you fail to set attrs_avp in script,
you get errors on ds_select_dst().  Default, per docs, should be null. But
ds_select_dst fails in this case after commit #9295. Setting attrs_avp in
config, seemingly fixes the issue.

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

Comment By: Dynamic Packet (dpacket)
Date: 2012-11-14 09:01

Message:
Hi Razvan,

I'm not 100% sure what function and I am unable to test at the moment. But
looking at the area of the script it occurs in, it could be ds_select_ds,
append_hf, xlog or least likely script comparisons/assignments.

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

Comment By: Razvan Crainea (razvancrainea)
Date: 2012-11-14 08:55

Message:
Hi!

Can you tell us when do you receive those errors? Is it a certain function
that uses AVPs and cannot find them?

Regards,
R?zvan

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

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


From noreply at sourceforge.net  Wed Nov 14 22:19:53 2012
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed, 14 Nov 2012 13:19:53 -0800
Subject: [OpenSIPS-Devel] [ opensips-Patches-3587231 ] b2b_entities: reply
	to Proxy-Authenticate
Message-ID: <mailman.1199.1352927998.13469.devel@lists.opensips.org>

Patches item #3587231, was opened at 2012-11-14 13:19
Message generated for change (Tracker Item Submitted) made by shimaore
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086412&aid=3587231&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.8.x
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: shimaore (shimaore)
Assigned to: Nobody/Anonymous (nobody)
Summary: b2b_entities: reply to Proxy-Authenticate

Initial Comment:
b2b_entities combined with uac module allows to authenticate outbound INVITE messages. However it currently only supports responses to the Authenticate headers.
This patch adds support for Proxy-Authenticate header on 407 reply.

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

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


From noreply at sourceforge.net  Thu Nov 15 14:56:29 2012
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 15 Nov 2012 05:56:29 -0800
Subject: [OpenSIPS-Devel] [ opensips-Bugs-3587515 ] Drouting rule fallback
	problem
Message-ID: <mailman.1200.1352987798.13469.devel@lists.opensips.org>

Bugs item #3587515, was opened at 2012-11-15 05:56
Message generated for change (Tracker Item Submitted) made by rico29600
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=3587515&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.8.x
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Rico (rico29600)
Assigned to: Nobody/Anonymous (nobody)
Summary: Drouting rule fallback problem

Initial Comment:
I've got a problem with rule fallback in drouting module. Rulle fallback does not work as expected.
When my higher priority GW is not reachable, I've got a message " All the gateways are disabled"


See the config here, and the opensips log in attachment (debug level 6)
Running opensips 1.8.2


Hope somebody will be able to help me...

best regards

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


#opensips.log
Nov  7 14:09:51 opensips1 /sbin/opensips[14026]: [from sip:067364xxxx at 91.213.a.b / to sip:0970559999 at 91.213.a.b:5060 ]
Nov  7 14:09:51 opensips1 /sbin/opensips[14026]: Entering route[4]
Nov  7 14:09:51 opensips1 /sbin/opensips[14026]: ERROR:drouting:do_routing: All the gateways are disabled




##################################################################
#opensipsctl dr gw_status
ID:: 11 IP=46.226.x.y Enabled=no 
ID:: 12 IP=46.226.x.z Enabled=yes




##################################################################
#opensipsctl dr show
dr gateways
+----+------+------+----------------+-------+------------+-------+------------+------------------------------+
| id | gwid | type | address        | strip | pri_prefix | attrs | probe_mode | description                  |
+----+------+------+----------------+-------+------------+-------+------------+------------------------------+
|  5 | 11   |    1 | 46.226.x.y |     0 | NULL       | NULL  |          2 | OXO ASTI 1                   |
|  6 | 12   |    1 | 46.226.x.z |     0 | NULL       | NULL  |          2 | OXO ASTI 2                   |
+----+------+------+----------------+-------+------------+-------+------------+------------------------------+



##################################################################
dr rules
+--------+---------+------------+---------+----------+---------+--------+-------+---------------------------------------+
| ruleid | groupid | prefix     | timerec | priority | routeid | gwlist | attrs | description                           |
+--------+---------+------------+---------+----------+---------+--------+-------+---------------------------------------+
|     64 | 1       | 0970559999 |         |        1 |         | 11     | NULL  | SDA Test                       |
|     68 | 1       | 0970559999 |         |        0 |         | 12     | NULL  | SDA Test                       |

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

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


From noreply at sourceforge.net  Sat Nov 17 11:19:10 2012
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat, 17 Nov 2012 02:19:10 -0800
Subject: [OpenSIPS-Devel] [ opensips-Bugs-3588141 ] 1.8.2 pua_dialoginfo
	regression
Message-ID: <mailman.1201.1353147556.13469.devel@lists.opensips.org>

Bugs item #3588141, was opened at 2012-11-17 02:19
Message generated for change (Tracker Item Submitted) made by dsandras
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=3588141&group_id=232389

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Damien Sandras (dsandras)
Assigned to: Nobody/Anonymous (nobody)
Summary: 1.8.2 pua_dialoginfo regression

Initial Comment:
Release 1.8.2 with the various dialog patches probably breaks pua_dialog_info.

When a call is terminated, OpenSIPS does not send a NOTIFY anymore, even though the presentity table looks correct (the dialog info event document corresponding to the call is correctly removed from the table).

We had things working fine with 1.8.1 (except a few ghost dialogs which had been CANCELled), but in 1.8.2, our phones
receive a NOTIFY to indicate early/established state, but not terminated state.


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

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


From noreply at sourceforge.net  Sat Nov 17 11:19:41 2012
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat, 17 Nov 2012 02:19:41 -0800
Subject: [OpenSIPS-Devel] [ opensips-Bugs-3588141 ] 1.8.2 pua_dialoginfo
	regression
Message-ID: <mailman.1202.1353147586.13469.devel@lists.opensips.org>

Bugs item #3588141, was opened at 2012-11-17 02:19
Message generated for change (Settings changed) made by dsandras
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=3588141&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.8.x
Status: Open
Resolution: None
>Priority: 7
Private: No
Submitted By: Damien Sandras (dsandras)
Assigned to: Nobody/Anonymous (nobody)
Summary: 1.8.2 pua_dialoginfo regression

Initial Comment:
Release 1.8.2 with the various dialog patches probably breaks pua_dialog_info.

When a call is terminated, OpenSIPS does not send a NOTIFY anymore, even though the presentity table looks correct (the dialog info event document corresponding to the call is correctly removed from the table).

We had things working fine with 1.8.1 (except a few ghost dialogs which had been CANCELled), but in 1.8.2, our phones
receive a NOTIFY to indicate early/established state, but not terminated state.


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

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


From binanalhalabi at yahoo.com  Mon Nov 19 19:50:34 2012
From: binanalhalabi at yahoo.com (Binan AL Halabi)
Date: Mon, 19 Nov 2012 10:50:34 -0800 (PST)
Subject: [OpenSIPS-Devel] OpenSIPS Provisioning
Message-ID: <1353351034.7260.YahooMailNeo@web122602.mail.ne1.yahoo.com>

Hi all,


Is there a way to provision OpenSIPS using JSON format instead of XML and REST instead of XML-RPC ?
I think there should be new module named like? MI_JSONREST or something like that.



Thanks.

// Binan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/devel/attachments/20121119/2b30908b/attachment.htm>

From shaheryarkh at gmail.com  Mon Nov 19 19:53:56 2012
From: shaheryarkh at gmail.com (Muhammad Shahzad)
Date: Mon, 19 Nov 2012 19:53:56 +0100
Subject: [OpenSIPS-Devel] [OpenSIPS-Users] OpenSIPS Provisioning
In-Reply-To: <1353351034.7260.YahooMailNeo@web122602.mail.ne1.yahoo.com>
References: <1353351034.7260.YahooMailNeo@web122602.mail.ne1.yahoo.com>
Message-ID: <CAFZQphx1UNOJrhdFTW6mD-2cGDdhMWsHoUN2vER0WR_jn11Yxw@mail.gmail.com>

Good idea. However, for now, you can use some language binding e.g. PERL or
LUA to write up your own opensips module for this support.

Thank you.


On Mon, Nov 19, 2012 at 7:50 PM, Binan AL Halabi <binanalhalabi at yahoo.com>wrote:

> Hi all,
>
> Is there a way to provision OpenSIPS using JSON format instead of XML and
> REST instead of XML-RPC ?
> I think there should be new module named like  MI_JSONREST or something
> like that.
>
>
> Thanks.
>
> // Binan
>
> _______________________________________________
> Users mailing list
> Users at lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/devel/attachments/20121119/7f2b55ce/attachment.htm>

From osas at voipembedded.com  Mon Nov 19 20:50:46 2012
From: osas at voipembedded.com (Ovidiu Sas)
Date: Mon, 19 Nov 2012 14:50:46 -0500
Subject: [OpenSIPS-Devel] [OpenSIPS-Users] OpenSIPS Provisioning
In-Reply-To: <1353351034.7260.YahooMailNeo@web122602.mail.ne1.yahoo.com>
References: <1353351034.7260.YahooMailNeo@web122602.mail.ne1.yahoo.com>
Message-ID: <CAND0LktsckaORJyDD_jw3s6fxnE_YB0E+NoQSfD_dzUjh1YSjw@mail.gmail.com>

What are you looking for: to provision or to manage opensips?
The MI interface is for management, not for provisioning.
Provisioning is a simple matter of filling up opensips tables and you
can do that externally (outside opensips).

Regards,
Ovidiu Sas

-- 
VoIP Embedded, Inc.
http://www.voipembedded.com

On Mon, Nov 19, 2012 at 1:50 PM, Binan AL Halabi
<binanalhalabi at yahoo.com> wrote:
> Hi all,
>
> Is there a way to provision OpenSIPS using JSON format instead of XML and
> REST instead of XML-RPC ?
> I think there should be new module named like  MI_JSONREST or something like
> that.
>
>
> Thanks.
>
> // Binan


From binanalhalabi at yahoo.com  Mon Nov 19 21:43:12 2012
From: binanalhalabi at yahoo.com (Binan AL Halabi)
Date: Mon, 19 Nov 2012 12:43:12 -0800 (PST)
Subject: [OpenSIPS-Devel] [OpenSIPS-Users] OpenSIPS Provisioning
In-Reply-To: <CAND0LktsckaORJyDD_jw3s6fxnE_YB0E+NoQSfD_dzUjh1YSjw@mail.gmail.com>
References: <1353351034.7260.YahooMailNeo@web122602.mail.ne1.yahoo.com>
	<CAND0LktsckaORJyDD_jw3s6fxnE_YB0E+NoQSfD_dzUjh1YSjw@mail.gmail.com>
Message-ID: <1353357792.45707.YahooMailNeo@web122602.mail.ne1.yahoo.com>

Hi Ovidiu, Thank you for your response.

I see your thread here : http://lists.opensips.org/pipermail/users/2012-October/023390.html for web based provisioning:
I mean something like that but based on JSON and REST. 

But at the same time there is need for MI functions (reconfigure on the fly). 


// Binan



________________________________
 Fr?n: Ovidiu Sas <osas at voipembedded.com>
Till: Binan AL Halabi <binanalhalabi at yahoo.com>; OpenSIPS users mailling list <users at lists.opensips.org> 
Kopia: OpenSIPS mailling list <devel at lists.opensips.org> 
Skickat: m?ndag, 19 november 2012 20:50
?mne: Re: [OpenSIPS-Users] OpenSIPS Provisioning
 
What are you looking for: to provision or to manage opensips?
The MI interface is for management, not for provisioning.
Provisioning is a simple matter of filling up opensips tables and you
can do that externally (outside opensips).

Regards,
Ovidiu Sas

-- 
VoIP Embedded, Inc.
http://www.voipembedded.com

On Mon, Nov 19, 2012 at 1:50 PM, Binan AL Halabi
<binanalhalabi at yahoo.com> wrote:
> Hi all,
>
> Is there a way to provision OpenSIPS using JSON format instead of XML and
> REST instead of XML-RPC ?
> I think there should be new module named like? MI_JSONREST or something like
> that.
>
>
> Thanks.
>
> // Binan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/devel/attachments/20121119/b92af6b6/attachment.htm>

From osas at voipembedded.com  Tue Nov 20 00:10:11 2012
From: osas at voipembedded.com (Ovidiu Sas)
Date: Mon, 19 Nov 2012 18:10:11 -0500
Subject: [OpenSIPS-Devel] [OpenSIPS-Users] OpenSIPS Provisioning
In-Reply-To: <1353357792.45707.YahooMailNeo@web122602.mail.ne1.yahoo.com>
References: <1353351034.7260.YahooMailNeo@web122602.mail.ne1.yahoo.com>
	<CAND0LktsckaORJyDD_jw3s6fxnE_YB0E+NoQSfD_dzUjh1YSjw@mail.gmail.com>
	<1353357792.45707.YahooMailNeo@web122602.mail.ne1.yahoo.com>
Message-ID: <CAND0LktcTE4y=UFR=3MVG+UhYmD5Y2-PLirzJfUkv6VZ=4gO1w@mail.gmail.com>

So you are looking for two new things:
 - a new transport for MI interface;
 - a new way to access the opensips db API (similar to pi_http module).

Regards,
Ovidiu Sas

-- 
VoIP Embedded, Inc.
http://www.voipembedded.com

On Mon, Nov 19, 2012 at 3:43 PM, Binan AL Halabi
<binanalhalabi at yahoo.com> wrote:
> Hi Ovidiu, Thank you for your response.
>
> I see your thread here :
> http://lists.opensips.org/pipermail/users/2012-October/023390.html for web
> based provisioning:
> I mean something like that but based on JSON and REST.
>
> But at the same time there is need for MI functions (reconfigure on the
> fly).
>
> // Binan
>
> ________________________________
> Fr?n: Ovidiu Sas <osas at voipembedded.com>
> Till: Binan AL Halabi <binanalhalabi at yahoo.com>; OpenSIPS users mailling
> list <users at lists.opensips.org>
> Kopia: OpenSIPS mailling list <devel at lists.opensips.org>
> Skickat: m?ndag, 19 november 2012 20:50
> ?mne: Re: [OpenSIPS-Users] OpenSIPS Provisioning
>
> What are you looking for: to provision or to manage opensips?
> The MI interface is for management, not for provisioning.
> Provisioning is a simple matter of filling up opensips tables and you
> can do that externally (outside opensips).
>
> Regards,
> Ovidiu Sas
>
> --
> VoIP Embedded, Inc.
> http://www.voipembedded.com
>
> On Mon, Nov 19, 2012 at 1:50 PM, Binan AL Halabi
> <binanalhalabi at yahoo.com> wrote:
>> Hi all,
>>
>> Is there a way to provision OpenSIPS using JSON format instead of XML and
>> REST instead of XML-RPC ?
>> I think there should be new module named like  MI_JSONREST or something
>> like
>> that.
>>
>>
>> Thanks.
>>
>> // Binan


From osas at voipembedded.com  Tue Nov 20 00:38:11 2012
From: osas at voipembedded.com (Ovidiu Sas)
Date: Mon, 19 Nov 2012 18:38:11 -0500
Subject: [OpenSIPS-Devel] [OpenSIPS-Users] OpenSIPS Provisioning
In-Reply-To: <CAND0LktcTE4y=UFR=3MVG+UhYmD5Y2-PLirzJfUkv6VZ=4gO1w@mail.gmail.com>
References: <1353351034.7260.YahooMailNeo@web122602.mail.ne1.yahoo.com>
	<CAND0LktsckaORJyDD_jw3s6fxnE_YB0E+NoQSfD_dzUjh1YSjw@mail.gmail.com>
	<1353357792.45707.YahooMailNeo@web122602.mail.ne1.yahoo.com>
	<CAND0LktcTE4y=UFR=3MVG+UhYmD5Y2-PLirzJfUkv6VZ=4gO1w@mail.gmail.com>
Message-ID: <CAND0LktJVXkGfmz09itv4AuyLJkzT5Ug1B_sSPFrLKLVC1ru9g@mail.gmail.com>

Actually, what you really need is only a new transport for MI interface.
For a json API for MySQL, take a look here:
http://rackerhacker.com/2012/03/28/mysql-json-bridge-a-simple-json-api-for-mysql/

Regards,
Ovidiu Sas

-- 
VoIP Embedded, Inc.
http://www.voipembedded.com

On Mon, Nov 19, 2012 at 6:10 PM, Ovidiu Sas <osas at voipembedded.com> wrote:
> So you are looking for two new things:
>  - a new transport for MI interface;
>  - a new way to access the opensips db API (similar to pi_http module).
>
> Regards,
> Ovidiu Sas
>
> --
> VoIP Embedded, Inc.
> http://www.voipembedded.com
>
> On Mon, Nov 19, 2012 at 3:43 PM, Binan AL Halabi
> <binanalhalabi at yahoo.com> wrote:
>> Hi Ovidiu, Thank you for your response.
>>
>> I see your thread here :
>> http://lists.opensips.org/pipermail/users/2012-October/023390.html for web
>> based provisioning:
>> I mean something like that but based on JSON and REST.
>>
>> But at the same time there is need for MI functions (reconfigure on the
>> fly).
>>
>> // Binan
>>
>> ________________________________
>> Fr?n: Ovidiu Sas <osas at voipembedded.com>
>> Till: Binan AL Halabi <binanalhalabi at yahoo.com>; OpenSIPS users mailling
>> list <users at lists.opensips.org>
>> Kopia: OpenSIPS mailling list <devel at lists.opensips.org>
>> Skickat: m?ndag, 19 november 2012 20:50
>> ?mne: Re: [OpenSIPS-Users] OpenSIPS Provisioning
>>
>> What are you looking for: to provision or to manage opensips?
>> The MI interface is for management, not for provisioning.
>> Provisioning is a simple matter of filling up opensips tables and you
>> can do that externally (outside opensips).
>>
>> Regards,
>> Ovidiu Sas
>>
>> --
>> VoIP Embedded, Inc.
>> http://www.voipembedded.com
>>
>> On Mon, Nov 19, 2012 at 1:50 PM, Binan AL Halabi
>> <binanalhalabi at yahoo.com> wrote:
>>> Hi all,
>>>
>>> Is there a way to provision OpenSIPS using JSON format instead of XML and
>>> REST instead of XML-RPC ?
>>> I think there should be new module named like  MI_JSONREST or something
>>> like
>>> that.
>>>
>>>
>>> Thanks.
>>>
>>> // Binan


From liviu at opensips.org  Wed Nov 21 16:22:30 2012
From: liviu at opensips.org (Liviu Chircu)
Date: Wed, 21 Nov 2012 15:22:30 +0000
Subject: [OpenSIPS-Devel] SF.net SVN: opensips:[9444] trunk/modules/cfgutils
Message-ID: <E1TbC8E-0003HG-2Y@sfp-svn-2.v30.ch3.sourceforge.com>

Revision: 9444
          http://opensips.svn.sourceforge.net/opensips/?rev=9444&view=rev
Author:   liviuchircu
Date:     2012-11-21 15:22:29 +0000 (Wed, 21 Nov 2012)
Log Message:
-----------
- NEW! Added scripting locks in the cfgutils module. They come in two flavors:
- "static locks" are manipulated with the {get,release}_static_lock functions.         
- "dynamic locks", which are bound to the {get,release}_dynamic_lock set of functions.   

Each class of locks has its own scenario of use. Refer to the updated module documentation for details.

Modified Paths:
--------------
    trunk/modules/cfgutils/README
    trunk/modules/cfgutils/cfgutils.c
    trunk/modules/cfgutils/doc/cfgutils_admin.xml

Added Paths:
-----------
    trunk/modules/cfgutils/script_locks.c
    trunk/modules/cfgutils/script_locks.h

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



From noreply at sourceforge.net  Wed Nov 21 17:30:57 2012
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed, 21 Nov 2012 08:30:57 -0800
Subject: [OpenSIPS-Devel] [ opensips-Bugs-3586532 ] [avpops] avp_print()
	Doesn't Print AVP Name
Message-ID: <mailman.1203.1353515465.13469.devel@lists.opensips.org>

Bugs item #3586532, was opened at 2012-11-12 16:42
Message generated for change (Settings changed) made by bogdan_iancu
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=3586532&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.8.x
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: David Sanders (dmsanders)
>Assigned to: Razvan Crainea (razvancrainea)
Summary: [avpops] avp_print() Doesn't Print AVP Name

Initial Comment:
If using named AVPs in a script, using avp_print() from avpops to try to debug does not provide the names, only the IDs used internally. This makes it hard to match up the script AVPs with the output.

Here's some example output from two named AVPs:

osips[8196]: INFO:avpops:ops_print_avp:                     id=<27> 
osips[8196]: INFO:avpops:ops_print_avp:                     val_str=<1919XXXXXXX / 11> 
osips[8196]: INFO:avpops:ops_print_avp: p=0x2b8c825daa18, flags=0x0002 
osips[8196]: INFO:avpops:ops_print_avp:                     id=<18> 
osips[8196]: INFO:avpops:ops_print_avp:                     val_str=<1831XXXXXXX / 11> 

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

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


From noreply at sourceforge.net  Wed Nov 21 17:31:03 2012
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed, 21 Nov 2012 08:31:03 -0800
Subject: [OpenSIPS-Devel] [ opensips-Bugs-3585696 ] Crash due to mi commands
Message-ID: <mailman.1204.1353515472.13469.devel@lists.opensips.org>

Bugs item #3585696, was opened at 2012-11-09 03:39
Message generated for change (Settings changed) made by bogdan_iancu
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=3585696&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: Digipigeon (digipigeon)
>Assigned to: Bogdan-Andrei Iancu (bogdan_iancu)
Summary: Crash due to mi commands

Initial Comment:
I am getting repeated crashing on my three X 1.8.2 opensips servers, also some crashing on my 1.7.1.

The problem appears to be more noticeable when the profile_get_values is called frequently (every few seconds), however I cant confirm isolation of this command causes the crash.

Please see attached (gdb) bt full

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

Comment By: Digipigeon (digipigeon)
Date: 2012-11-09 13:52

Message:
Hi Bogdan,

The results of your requested commands is as follows:

(gdb) f 1
#1  add_mi_node_child (value_len=26, value=<optimised out>,
name_len=<optimised out>, name=<optimised out>, flags=2, parent=<optimised
out>) at mi/tree.c:219
219                     return add_next(parent->kids, name, name_len,
value, value_len, flags);
(gdb) p parent
$1 = <optimised out>
(gdb) p *parent
value has been optimised out
(gdb) f 4
#4  mi_get_stats (cmd=<optimised out>, param=<optimised out>) at
statistics.c:535
535                                     if (mi_add_module_stats( rpl,
&collector->amodules[i] )!=0)
(gdb) p *rpl
$2 = {value = {s = 0x2 <Address 0x2 out of bounds>, len = 0}, name = {s =
0x0, len = -840856056}, flags = 0, kids = 0x7663723a65726f63, next =
0x7365696c7065725f,
  last = 0x3730393134203d20, attributes = 0x33}

The dump is 2.1GB, I will get this somewhere you can access it.

Kind Regards

Jonathan

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

Comment By: Bogdan-Andrei Iancu (bogdan_iancu)
Date: 2012-11-09 13:34

Message:
Ok, it seems the "brother" pointer is overwritten - the pointer is not a
valid mem addrs, but decoded as hexa is "core:rcv" which is a statistic
name.
Please try more:

f 1
p parent
p *parent
f 4
p *rpl

Also is there any why to get access to the core to speed up the debugging
?

Regards,

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

Comment By: Digipigeon (digipigeon)
Date: 2012-11-09 13:12

Message:
Hi Bogdan,

Thanks for the explanation. Please see the following output:

(gdb) f 0
#0  add_next (flags=2, value_len=26, value=<optimised out>,
name_len=<optimised out>, name=<optimised out>, brother=0x7663723a65726f63)
at mi/tree.c:184
184             brother->last->next = new;
(gdb) p brother
$1 = (struct mi_node *) 0x7663723a65726f63
(gdb) p *brother
Cannot access memory at address 0x7663723a65726f63
(gdb) p name
$2 = <optimised out>
(gdb) p value
$3 = <optimised out>
(gdb) p *brother->name
Structure has no component named operator*.

Kind Regards

Jonathan.

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

Comment By: Bogdan-Andrei Iancu (bogdan_iancu)
Date: 2012-11-09 12:42

Message:
Jonathan,

Once you are in gdb, run the commands:

f 0
p brother
p *brother
p name
p value
p *brother->name 

Regards,
Bogdan

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

Comment By: Digipigeon (digipigeon)
Date: 2012-11-09 11:40

Message:
Hi Bogdan,

There was nothing in the log files relevant, it just crashes without any
response.

I am not sure if I have correctly ran the commands, but I get the
following:

(gdb) f 0 brother
#0  0x7663723a65726f63 in ?? ()

(gdb) f 0 *brother
Cannot access memory at address 0x7663723a65726f63

(gdb) f 0 name
value has been optimised out

(gdb) f 0 value
value has been optimised out

(gdb) f 0 *brother->next
Cannot access memory at address 0x7663723a65726f93

Sorry if this is not correct.

Kind Regards

Jonathan

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

Comment By: Bogdan-Andrei Iancu (bogdan_iancu)
Date: 2012-11-09 09:32

Message:
Hi,

1) do you see in the logs any err message before the crash (from the same
process) ?

2) in gdb, frame 0, please print : brother, *brother, name, value,
*brother->next .

Thanks and regards,
Bogdan

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

Comment By: Digipigeon (digipigeon)
Date: 2012-11-09 07:09

Message:
The only parameter that I have programmed in for get_statistics is the
parameter "all", this is ran through xmlrpc

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

Comment By: Razvan Crainea (razvancrainea)
Date: 2012-11-09 06:22

Message:
Hi!

The core you attached does not contain any indications that the cause of
the crash are the dialog profiles, but rather some statistics you are
fetching through MI. Can you provide us the exact MI command you are
running?

Best regards,
R?zvan

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

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


From noreply at sourceforge.net  Wed Nov 21 17:33:24 2012
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed, 21 Nov 2012 08:33:24 -0800
Subject: [OpenSIPS-Devel] [ opensips-Bugs-3586730 ] $var variables cleanup
	on new request
Message-ID: <mailman.1205.1353515609.13469.devel@lists.opensips.org>

Bugs item #3586730, was opened at 2012-11-13 07:03
Message generated for change (Comment added) made by bogdan_iancu
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=3586730&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.8.x
Status: Open
>Resolution: Invalid
Priority: 5
Private: No
Submitted By: Nick Altmann (nikbyte)
>Assigned to: Bogdan-Andrei Iancu (bogdan_iancu)
Summary: $var variables cleanup on new request

Initial Comment:
I found that in my script I do something like (the same tail of every log message is because of m4 macros):

route {
    xlog("L_INFO", "[MAIN] log message [$var(info)]");
    $var(info) = "blablabla";
    xlog("L_INFO", "[MAIN] another message [$var(info)]");
}

Interesting that in first xlog the $var(info) is not null ! 
And instead of "null" I see there something interesting values from other client's requests.

I think we should clean up all $var variables before request, shouldn't we?


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

>Comment By: Bogdan-Andrei Iancu (bogdan_iancu)
Date: 2012-11-21 08:33

Message:
Hi Nick,

The $var() are on purpose process persistent - they are not ever reset. You
need to take care in script and reset it before using it.

The fact they are process persistent may help you to pass values between
different routes (like requests and branch route) when the routes are
triggered in the same process (in a row, like onreply + failure)

Regards,
Bogdan

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

Comment By: Robert Smith (denodaeus)
Date: 2012-11-13 07:44

Message:
I've been bitten by this before, but it's intentional.  From the docs:

http://www.opensips.org/Resources/DocsCoreVar18#varscript

1.  if you want to start using a script variable in a route, better
initialize it with same value (or reset it), otherwise you may inherit a
value from a previous route that was executed by the same process.
3. the value of script variables persists over a OpenSIPS process.

So you can either initialize it to the same default value every time, or
you can use something transactional instead (like avp's).



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

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


From noreply at sourceforge.net  Wed Nov 21 17:37:33 2012
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed, 21 Nov 2012 08:37:33 -0800
Subject: [OpenSIPS-Devel] [ opensips-Bugs-3586775 ] Dialog Ping
Message-ID: <mailman.1206.1353515862.13469.devel@lists.opensips.org>

Bugs item #3586775, was opened at 2012-11-13 11:03
Message generated for change (Settings changed) made by bogdan_iancu
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=3586775&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.8.x
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Carlos Eduardo Wagner (kaduww)
>Assigned to: Vladut-Stefan Paiu (vladut-paiu)
Summary: Dialog Ping

Initial Comment:
I'm having some problems with the Dialog Ping when using another port different from the 5060.
My opensips is listening on both ports, 5060 and 5062 and, as the trace attached, when the client is sending requests to the port 5062 and the dialog is created, the Dialog Ping sends the OPTIONS packet from the port 5060. Because of this, my client's NAT is blocking the packet, because its mapped to the port 5062 and not the 5060.

Follow the dialog information:
root at sipstage:/home/suporte# opensipsctl fifo dlg_list
dialog::  hash=2536:1633827324
	state:: 4
	user_flags:: 0
	timestart:: 1352831188
	timeout:: 1352838388
	callid:: a4e155f4320d43b9be48fde6457150ee
	from_uri:: sip:P0000000001 at sipstage.pligg.com.br
	to_uri:: sip:05130227701 at sipstage.pligg.com.br
	caller_tag:: 6fe6c313c92742a392fd75740f8867d7
	caller_contact:: sip:P0000000001 at 177.97.125.92:4057;ob
	callee_cseq:: 0
	caller_route_set:: 
	caller_bind_addr:: udp:177.129.74.30:5062
	callee_tag:: a94c095b773be1dd6e8d668a785a9c8470442779
	callee_contact:: sip:05130227701 at 201.56.167.2:5060
	caller_cseq:: 31678
	callee_route_set:: <sip:201.33.209.42;lr;did=8e96.0e1aebe1>,<sip:201.33.209.194;lr=on;did=8e9.c48a6f3>
	callee_bind_addr:: udp:177.129.74.30:5062

Here follows the OPTIONS part of the Trace:
U 2012/11/13 16:28:59.522813 177.129.74.30:5060 -> 177.97.125.92:4050
OPTIONS sip:P0000000025 at 177.97.125.92:4050;ob SIP/2.0.
Via: SIP/2.0/UDP 177.129.74.30:5062;branch=z9hG4bKf915.ddfebd02.0.
To: <sip:P0000000025 at sipstage.pligg.com.br>;tag=6caf1d8cdc4645719b25a6e120c90679.
From: <sip:05130227701 at sipstage.pligg.com.br>;tag=a94c095b773be1dd6e8d668a785a9c849cb5c894.
CSeq: 1 OPTIONS.
Call-ID: 433b8548a3944c2ea03a4a9cf2ce0bc4.
Max-Forwards: 70.
Content-Length: 0.
User-Agent: OpenSIPS (1.8.2-notls (x86_64/linux)).

* The SIP Trace attached was made while using the Opensips 1.8.1, but I did the test with the newest 1.8.x version e the problem was the same.

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

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


From noreply at sourceforge.net  Wed Nov 21 17:39:11 2012
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed, 21 Nov 2012 08:39:11 -0800
Subject: [OpenSIPS-Devel] [ opensips-Bugs-3587163 ] Commit #9295 breaks
	dispatcher
Message-ID: <mailman.1207.1353515961.13469.devel@lists.opensips.org>

Bugs item #3587163, was opened at 2012-11-14 08:43
Message generated for change (Comment added) made by bogdan_iancu
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=3587163&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.8.x
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Dynamic Packet (dpacket)
>Assigned to: Bogdan-Andrei Iancu (bogdan_iancu)
Summary: Commit #9295 breaks dispatcher

Initial Comment:
It seems commit #9295 on 1.8 branch breaks AVP in certain cases. Opensips starts fine and some avp related stuff works, but certain scenarios cause this: 

Nov 14 11:13:40 ip-10-173-81-249 /usr/sbin/opensips[1042]: ERROR:core:new_avp: invalid AVP name!
Nov 14 11:13:40 ip-10-173-81-249 /usr/sbin/opensips[1042]: ERROR:core:add_avp: Failed to create new avp structure

Script now does not execute as it should and in the end cause failures in call processing.  Its possible this also effects trunk (commit #9294) . I have tested by reverting this single commit (#9295) in most resent stable 1.8 and issue is resolved.

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

>Comment By: Bogdan-Andrei Iancu (bogdan_iancu)
Date: 2012-11-21 08:39

Message:
I remember fixing this - I will check the backports

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

Comment By: Dynamic Packet (dpacket)
Date: 2012-11-14 10:29

Message:
This is a bug in dispatcher module. If you fail to set attrs_avp in script,
you get errors on ds_select_dst().  Default, per docs, should be null. But
ds_select_dst fails in this case after commit #9295. Setting attrs_avp in
config, seemingly fixes the issue.

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

Comment By: Dynamic Packet (dpacket)
Date: 2012-11-14 09:01

Message:
Hi Razvan,

I'm not 100% sure what function and I am unable to test at the moment. But
looking at the area of the script it occurs in, it could be ds_select_ds,
append_hf, xlog or least likely script comparisons/assignments.

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

Comment By: Razvan Crainea (razvancrainea)
Date: 2012-11-14 08:55

Message:
Hi!

Can you tell us when do you receive those errors? Is it a certain function
that uses AVPs and cannot find them?

Regards,
R?zvan

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

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


From noreply at sourceforge.net  Wed Nov 21 17:40:35 2012
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed, 21 Nov 2012 08:40:35 -0800
Subject: [OpenSIPS-Devel] [ opensips-Bugs-3587515 ] Drouting rule fallback
	problem
Message-ID: <mailman.1208.1353516044.13469.devel@lists.opensips.org>

Bugs item #3587515, was opened at 2012-11-15 05:56
Message generated for change (Comment added) made by bogdan_iancu
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=3587515&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.8.x
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Rico (rico29600)
>Assigned to: Bogdan-Andrei Iancu (bogdan_iancu)
Summary: Drouting rule fallback problem

Initial Comment:
I've got a problem with rule fallback in drouting module. Rulle fallback does not work as expected.
When my higher priority GW is not reachable, I've got a message " All the gateways are disabled"


See the config here, and the opensips log in attachment (debug level 6)
Running opensips 1.8.2


Hope somebody will be able to help me...

best regards

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


#opensips.log
Nov  7 14:09:51 opensips1 /sbin/opensips[14026]: [from sip:067364xxxx at 91.213.a.b / to sip:0970559999 at 91.213.a.b:5060 ]
Nov  7 14:09:51 opensips1 /sbin/opensips[14026]: Entering route[4]
Nov  7 14:09:51 opensips1 /sbin/opensips[14026]: ERROR:drouting:do_routing: All the gateways are disabled




##################################################################
#opensipsctl dr gw_status
ID:: 11 IP=46.226.x.y Enabled=no 
ID:: 12 IP=46.226.x.z Enabled=yes




##################################################################
#opensipsctl dr show
dr gateways
+----+------+------+----------------+-------+------------+-------+------------+------------------------------+
| id | gwid | type | address        | strip | pri_prefix | attrs | probe_mode | description                  |
+----+------+------+----------------+-------+------------+-------+------------+------------------------------+
|  5 | 11   |    1 | 46.226.x.y |     0 | NULL       | NULL  |          2 | OXO ASTI 1                   |
|  6 | 12   |    1 | 46.226.x.z |     0 | NULL       | NULL  |          2 | OXO ASTI 2                   |
+----+------+------+----------------+-------+------------+-------+------------+------------------------------+



##################################################################
dr rules
+--------+---------+------------+---------+----------+---------+--------+-------+---------------------------------------+
| ruleid | groupid | prefix     | timerec | priority | routeid | gwlist | attrs | description                           |
+--------+---------+------------+---------+----------+---------+--------+-------+---------------------------------------+
|     64 | 1       | 0970559999 |         |        1 |         | 11     | NULL  | SDA Test                       |
|     68 | 1       | 0970559999 |         |        0 |         | 12     | NULL  | SDA Test                       |

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

>Comment By: Bogdan-Andrei Iancu (bogdan_iancu)
Date: 2012-11-21 08:40

Message:
Trying to reproduce this locally. Indeed, it seems to be bug as
do_routing() internally cannot do fallback to a different rule . Currently
the fallback can be done only by calling use_next_gw().

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

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


From noreply at sourceforge.net  Wed Nov 21 17:41:14 2012
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed, 21 Nov 2012 08:41:14 -0800
Subject: [OpenSIPS-Devel] [ opensips-Bugs-3588141 ] 1.8.2 pua_dialoginfo
	regression
Message-ID: <mailman.1209.1353516083.13469.devel@lists.opensips.org>

Bugs item #3588141, was opened at 2012-11-17 02:19
Message generated for change (Settings changed) made by bogdan_iancu
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=3588141&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.8.x
Status: Open
Resolution: None
Priority: 7
Private: No
Submitted By: Damien Sandras (dsandras)
>Assigned to: Bogdan-Andrei Iancu (bogdan_iancu)
Summary: 1.8.2 pua_dialoginfo regression

Initial Comment:
Release 1.8.2 with the various dialog patches probably breaks pua_dialog_info.

When a call is terminated, OpenSIPS does not send a NOTIFY anymore, even though the presentity table looks correct (the dialog info event document corresponding to the call is correctly removed from the table).

We had things working fine with 1.8.1 (except a few ghost dialogs which had been CANCELled), but in 1.8.2, our phones
receive a NOTIFY to indicate early/established state, but not terminated state.


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

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


From bogdan at opensips.org  Thu Nov 22 11:34:36 2012
From: bogdan at opensips.org (Bogdan-Andrei Iancu)
Date: Thu, 22 Nov 2012 12:34:36 +0200
Subject: [OpenSIPS-Devel] [RFC] New Release Policy for OpenSIPS project
Message-ID: <50ADFFBC.800@opensips.org>

Hi all,

I want to bring to public discussion the changing of the release policy 
of the project. Why, because I had an interesting feedback from the 
community after the email on shaping the 1.9 release and I felt the need 
of straighting some things up.

First of all, what this change should target? It should make the release 
process :
     - *more open* - anyone from community (and not only developers) 
should be able to
         contribute to roadmap of the next release (on what should be done)
     - *more predictable* - everyone should know when and how the next 
release will be
         available, so they can rely and sync their own private 
schedules (for using opensips)
         with the project scheduling. You will know when the next 
release will be available
         as RC, as GA, etc, you will know what features will contain, 
you will know when to
         get involved for bringing in discussion some new features for 
the next release.
     - *more transparent* - the entire releasing process to be generally 
known in details, so
         we can achieve a better collaboration and interfacing between 
community and developers
         (we should avoid a separation between these two entities and 
rather put them together
         to work)


Now, I'm listing here what I see as a starting point and I'm eager to 
hear your comments, suggestions, improvements or any other ideas related 
to this topic.

Release cycles
===============
     - instead of a feature driven release cycle, I would prefer a time 
driven release cycle - because it is more predictable and being feature 
driven may actually escalate the time to the next release (the snowball 
effect) - see the timing for 1.7, 1.8 versions
     - have a 5-7 months release cycle (depending on the required volume 
of work)
     - smaller steps in releases will be more friendly to users as there 
are no big gaps between releases, easier and more appealing to upgrade ; 
also shorter release cycles will make new features available in stable 
versions much faster.

Next Release TODO
==================
     - on a new cycle, we should start with a brainstorming on what the 
next release should contain (or focus on). This will open up the 
development and roadmap of the project to the entire community.
     - maintain a web page with the TODO features that will be updated 
(this process is to be continuous); also the items that where address to 
be documented and listed as new available features (see 
http://www.opensips.org/Main/Ver190)
     - as the release is time driven, the next release will contain only 
the features (from TODO list, based on priorities) that can be done in 
that time frame; the remaining list will be inherited by the next release.

Steps inside a Cycle
====================
     - brainstorming on TODO list
     - estimating the release time (T) based on the volume of work 
(between 5-7 months)
     - actual work on implementing the items on TODO list ; it is 
critical important to have a
         better description / documentation / examples on the newly 
added feature -> it will help
         people to understand and use them from day 0 (an undocumented 
super feature is an
         inexistent feature)
     - SVN freeze (no more new stuff) at T - 1 months ; at this point 
the SVN trunk code
         is moved in a new separate SVN branch (dedicated to that 
release)-> Release Candidate
         (or beta release) ; this will make the trunk free and available 
for new work in the
         mean while (we overlap the testing on release N with the start 
of release N+1)
     - testing, debugging - 1 month -> at T we have the GA release (full 
stable release)

Version Management
==================
     - at any moment, officially we will support only the last 2 stable 
release (by support I mean
         troubleshooting, fixing bugs, backporting, etc)
     - whatever is older than 2 stable release (like older than 1.7 now) 
is unsupported (no fixing,
         no packing, no new tarballs)
     - when a new release gets to a full stable state, the window of 2 
supported versions is shifted
         (like when 1.9 will become stable, 1.7 will become obsolete and 
unsupported).



Regards,

-- 
Bogdan-Andrei Iancu
OpenSIPS Founder and Developer
http://www.opensips-solutions.com

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/devel/attachments/20121122/743378d0/attachment.htm>

From saul at ag-projects.com  Thu Nov 22 11:46:20 2012
From: saul at ag-projects.com (=?iso-8859-1?Q?Sa=FAl_Ibarra_Corretg=E9?=)
Date: Thu, 22 Nov 2012 11:46:20 +0100
Subject: [OpenSIPS-Devel] [OpenSIPS-Users] [RFC] New Release Policy for
	OpenSIPS project
In-Reply-To: <50ADFFBC.800@opensips.org>
References: <50ADFFBC.800@opensips.org>
Message-ID: <8FDA43EA-EFAD-4B95-AD48-C83422A176F1@ag-projects.com>

Hi Bogdan,

It's great to see this. See some comments inline.

On Nov 22, 2012, at 11:34 AM, Bogdan-Andrei Iancu wrote:

> Hi all,
> 
> I want to bring to public discussion the changing of the release policy of the project. Why, because I had an interesting feedback from the community after the email on shaping the 1.9 release and I felt the need of straighting some things up.
> 
> First of all, what this change should target? It should make the release process :
>     - more open - anyone from community (and not only developers) should be able to 
>         contribute to roadmap of the next release (on what should be done)
>     - more predictable - everyone should know when and how the next release will be 
>         available, so they can rely and sync their own private schedules (for using opensips)
>         with the project scheduling. You will know when the next release will be available 
>         as RC, as GA, etc, you will know what features will contain, you will know when to 
>         get involved for bringing in discussion some new features for the next release.
>     - more transparent - the entire releasing process to be generally known in details, so
>         we can achieve a better collaboration and interfacing between community and developers
>         (we should avoid a separation between these two entities and rather put them together 
>         to work)
> 
> 
> Now, I'm listing here what I see as a starting point and I'm eager to hear your comments, suggestions, improvements or any other ideas related to this topic.
> 
> Release cycles
> ===============
>     - instead of a feature driven release cycle, I would prefer a time driven release cycle - because it is more predictable and being feature driven may actually escalate the time to the next release (the snowball effect) - see the timing for 1.7, 1.8 versions
>     - have a 5-7 months release cycle (depending on the required volume of work)
>     - smaller steps in releases will be more friendly to users as there are no big gaps between releases, easier and more appealing to upgrade ; also shorter release cycles will make new features available in stable versions much faster.
> 

While a time-based release cycle sounds good to me for minor releases (1.8.1, 1.8.2, ...) I'm not sure if it can also be applied to major releases. What if feature X takes longer than expected to develop? Things may be inadvertently rushed and that's not good. For major releases I'd go with the Debian-ish policy: it's ready when it's ready :-)

> Next Release TODO
> ==================
>     - on a new cycle, we should start with a brainstorming on what the next release should contain (or focus on). This will open up the development and roadmap of the project to the entire community.
>     - maintain a web page with the TODO features that will be updated (this process is to be continuous); also the items that where address to be documented and listed as new available features (see http://www.opensips.org/Main/Ver190)
>     - as the release is time driven, the next release will contain only the features (from TODO list, based on priorities) that can be done in that time frame; the remaining list will be inherited by the next release.
> 
> Steps inside a Cycle
> ====================
>     - brainstorming on TODO list
>     - estimating the release time (T) based on the volume of work (between 5-7 months)
>     - actual work on implementing the items on TODO list ; it is critical important to have a 
>         better description / documentation / examples on the newly added feature -> it will help
>         people to understand and use them from day 0 (an undocumented super feature is an 
>         inexistent feature)
>     - SVN freeze (no more new stuff) at T - 1 months ; at this point the SVN trunk code 
>         is moved in a new separate SVN branch (dedicated to that release)-> Release Candidate 
>         (or beta release) ; this will make the trunk free and available for new work in the 
>         mean while (we overlap the testing on release N with the start of release N+1)
>     - testing, debugging - 1 month -> at T we have the GA release (full stable release)
> 
> Version Management
> ==================
>     - at any moment, officially we will support only the last 2 stable release (by support I mean 
>         troubleshooting, fixing bugs, backporting, etc)
>     - whatever is older than 2 stable release (like older than 1.7 now) is unsupported (no fixing,
>         no packing, no new tarballs)
>     - when a new release gets to a full stable state, the window of 2 supported versions is shifted
>         (like when 1.9 will become stable, 1.7 will become obsolete and unsupported).
> 

What about security fixes? I can understand that when 1.9 is released 1.7 goes to EOL (sort of), but what if there is a bug in the parser (for example) which can cause a crash just by using a stupid script? IMHO there should be a security-fixes-only period, since migrating to a new OpenSIPS version is not  a task to be taken lightly.

Those are my 2 cents.


Kind regards,

--
Sa?l Ibarra Corretg?
AG Projects





From bogdan at opensips.org  Thu Nov 22 14:22:41 2012
From: bogdan at opensips.org (Bogdan-Andrei Iancu)
Date: Thu, 22 Nov 2012 15:22:41 +0200
Subject: [OpenSIPS-Devel] [OpenSIPS-Users] [RFC] New Release Policy for
	OpenSIPS project
In-Reply-To: <8FDA43EA-EFAD-4B95-AD48-C83422A176F1@ag-projects.com>
References: <50ADFFBC.800@opensips.org>
	<8FDA43EA-EFAD-4B95-AD48-C83422A176F1@ag-projects.com>
Message-ID: <50AE2721.9090701@opensips.org>

Hi Saul,

On 11/22/2012 12:46 PM, Sa?l Ibarra Corretg? wrote:
>> Release cycles
>> ===============
>>      - instead of a feature driven release cycle, I would prefer a time driven release cycle - because it is more predictable and being feature driven may actually escalate the time to the next release (the snowball effect) - see the timing for 1.7, 1.8 versions
>>      - have a 5-7 months release cycle (depending on the required volume of work)
>>      - smaller steps in releases will be more friendly to users as there are no big gaps between releases, easier and more appealing to upgrade ; also shorter release cycles will make new features available in stable versions much faster.
>>
> While a time-based release cycle sounds good to me for minor releases (1.8.1, 1.8.2, ...) I'm not sure if it can also be applied to major releases. What if feature X takes longer than expected to develop? Things may be inadvertently rushed and that's not good. For major releases I'd go with the Debian-ish policy: it's ready when it's ready :-)
[bogdan]
The problem I see with the features-based release cycle is that they are 
unpredictable as time - some features may not be properly (or 
impossible) time evaluated -> it may stretch the interval between 
releases ; IMHO, for a project to reliable it is a must to be 
predictable. The best examples are what is happening now with OpenSIPS 
(the interval between releases is keep growing) and Debian (lack of 
predictability and huge intervals between release ended up in the Ubuntu 
alternative).
Being able to predict the releases (as time) without huge differences 
between versions (to make an upgrade something easy you are not scared 
like hell to do it) should be some key-feature of the project.

The time-based releases should not be affected by how long a feature 
takes to be implemented - 6 months of development for a feature is 
really more than enough, IMHO.


PS: let me ask you: how many OpenSIPS installations do you still have 
running old versions because upgrade is really painful ? ;)

>> Next Release TODO
>> ==================
>>      - on a new cycle, we should start with a brainstorming on what the next release should contain (or focus on). This will open up the development and roadmap of the project to the entire community.
>>      - maintain a web page with the TODO features that will be updated (this process is to be continuous); also the items that where address to be documented and listed as new available features (see http://www.opensips.org/Main/Ver190)
>>      - as the release is time driven, the next release will contain only the features (from TODO list, based on priorities) that can be done in that time frame; the remaining list will be inherited by the next release.
>>
>> Steps inside a Cycle
>> ====================
>>      - brainstorming on TODO list
>>      - estimating the release time (T) based on the volume of work (between 5-7 months)
>>      - actual work on implementing the items on TODO list ; it is critical important to have a
>>          better description / documentation / examples on the newly added feature ->  it will help
>>          people to understand and use them from day 0 (an undocumented super feature is an
>>          inexistent feature)
>>      - SVN freeze (no more new stuff) at T - 1 months ; at this point the SVN trunk code
>>          is moved in a new separate SVN branch (dedicated to that release)->  Release Candidate
>>          (or beta release) ; this will make the trunk free and available for new work in the
>>          mean while (we overlap the testing on release N with the start of release N+1)
>>      - testing, debugging - 1 month ->  at T we have the GA release (full stable release)
>>
>> Version Management
>> ==================
>>      - at any moment, officially we will support only the last 2 stable release (by support I mean
>>          troubleshooting, fixing bugs, backporting, etc)
>>      - whatever is older than 2 stable release (like older than 1.7 now) is unsupported (no fixing,
>>          no packing, no new tarballs)
>>      - when a new release gets to a full stable state, the window of 2 supported versions is shifted
>>          (like when 1.9 will become stable, 1.7 will become obsolete and unsupported).
>>
> What about security fixes? I can understand that when 1.9 is released 1.7 goes to EOL (sort of), but what if there is a bug in the parser (for example) which can cause a crash just by using a stupid script? IMHO there should be a security-fixes-only period, since migrating to a new OpenSIPS version is not  a task to be taken lightly.
[bogdan]
That is true problem that may have as solutions:
     1) simply upgrade (most common way to go in open source world) , 
considering that upgrades should become easier.
     2) try to define what is really critical (based on what??) and 
still do backporting - but at the end of the day we need to encourage 
people to use the new versions - keep patching and supporting really old 
versions (consider 1.6 at this point) is a waist of effort. Taking your 
example: debian is not supporting something older than 1 release :D....

But I'm open to solutions here.

Regards,
Bogdan


From noreply at sourceforge.net  Thu Nov 22 14:41:13 2012
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 22 Nov 2012 05:41:13 -0800
Subject: [OpenSIPS-Devel] [ opensips-Bugs-3589142 ] B2B: crash when CANCEL
	without from_tag
Message-ID: <mailman.1210.1353591682.13469.devel@lists.opensips.org>

Bugs item #3589142, was opened at 2012-11-22 05:41
Message generated for change (Tracker Item Submitted) made by nikbyte
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=3589142&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: Nick Altmann (nikbyte)
Assigned to: Nobody/Anonymous (nobody)
Summary: B2B: crash when CANCEL without from_tag

Initial Comment:
Sometimes buggy UACs send in-b2b-dialog CANCEL without from_tag.
b2b_entities module crashes in dlg.c on line 645:
hash_index = core_hash(&callid, &from_tag, server_hsize);

because from_tag is empty.


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

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


From bogdan at opensips.org  Thu Nov 22 14:53:11 2012
From: bogdan at opensips.org (Bogdan-Andrei Iancu)
Date: Thu, 22 Nov 2012 13:53:11 +0000
Subject: [OpenSIPS-Devel] SF.net SVN: opensips:[9445]
	trunk/modules/drouting/drouting.c
Message-ID: <E1TbXDL-0006Hs-Js@sfp-svn-3.v30.ch3.sourceforge.com>

Revision: 9445
          http://opensips.svn.sourceforge.net/opensips/?rev=9445&view=rev
Author:   bogdan_iancu
Date:     2012-11-22 13:53:10 +0000 (Thu, 22 Nov 2012)
Log Message:
-----------
- fixed internal fallback (inside of do_routing() function) if a rule has no GWs or all GWs are disabled.
	Reported by Rico (SF ID)
	Closes bug #3587515

Modified Paths:
--------------
    trunk/modules/drouting/drouting.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 Nov 22 14:54:23 2012
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 22 Nov 2012 05:54:23 -0800
Subject: [OpenSIPS-Devel] [ opensips-Bugs-3587515 ] Drouting rule fallback
	problem
Message-ID: <mailman.1211.1353592467.13469.devel@lists.opensips.org>

Bugs item #3587515, was opened at 2012-11-15 05:56
Message generated for change (Comment added) made by bogdan_iancu
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=3587515&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.8.x
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Rico (rico29600)
Assigned to: Bogdan-Andrei Iancu (bogdan_iancu)
Summary: Drouting rule fallback problem

Initial Comment:
I've got a problem with rule fallback in drouting module. Rulle fallback does not work as expected.
When my higher priority GW is not reachable, I've got a message " All the gateways are disabled"


See the config here, and the opensips log in attachment (debug level 6)
Running opensips 1.8.2


Hope somebody will be able to help me...

best regards

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


#opensips.log
Nov  7 14:09:51 opensips1 /sbin/opensips[14026]: [from sip:067364xxxx at 91.213.a.b / to sip:0970559999 at 91.213.a.b:5060 ]
Nov  7 14:09:51 opensips1 /sbin/opensips[14026]: Entering route[4]
Nov  7 14:09:51 opensips1 /sbin/opensips[14026]: ERROR:drouting:do_routing: All the gateways are disabled




##################################################################
#opensipsctl dr gw_status
ID:: 11 IP=46.226.x.y Enabled=no 
ID:: 12 IP=46.226.x.z Enabled=yes




##################################################################
#opensipsctl dr show
dr gateways
+----+------+------+----------------+-------+------------+-------+------------+------------------------------+
| id | gwid | type | address        | strip | pri_prefix | attrs | probe_mode | description                  |
+----+------+------+----------------+-------+------------+-------+------------+------------------------------+
|  5 | 11   |    1 | 46.226.x.y |     0 | NULL       | NULL  |          2 | OXO ASTI 1                   |
|  6 | 12   |    1 | 46.226.x.z |     0 | NULL       | NULL  |          2 | OXO ASTI 2                   |
+----+------+------+----------------+-------+------------+-------+------------+------------------------------+



##################################################################
dr rules
+--------+---------+------------+---------+----------+---------+--------+-------+---------------------------------------+
| ruleid | groupid | prefix     | timerec | priority | routeid | gwlist | attrs | description                           |
+--------+---------+------------+---------+----------+---------+--------+-------+---------------------------------------+
|     64 | 1       | 0970559999 |         |        1 |         | 11     | NULL  | SDA Test                       |
|     68 | 1       | 0970559999 |         |        0 |         | 12     | NULL  | SDA Test                       |

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

>Comment By: Bogdan-Andrei Iancu (bogdan_iancu)
Date: 2012-11-22 05:54

Message:
Hi Rico,

Find attached the patch to fix the issue you have. Simply do now:
    if ( !do_routing("1","F") ) {}

Test the patch and let me know if you see any problems. I also uploaded the
patch on trunk SVN.

Thanks and regards,
Bogdan

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

Comment By: Bogdan-Andrei Iancu (bogdan_iancu)
Date: 2012-11-21 08:40

Message:
Trying to reproduce this locally. Indeed, it seems to be bug as
do_routing() internally cannot do fallback to a different rule . Currently
the fallback can be done only by calling use_next_gw().

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

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


From noreply at sourceforge.net  Thu Nov 22 14:54:45 2012
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 22 Nov 2012 05:54:45 -0800
Subject: [OpenSIPS-Devel] [ opensips-Bugs-3587515 ] Drouting rule fallback
	problem
Message-ID: <mailman.1212.1353592493.13469.devel@lists.opensips.org>

Bugs item #3587515, was opened at 2012-11-15 05: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=3587515&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.8.x
Status: Open
>Resolution: Fixed
Priority: 5
Private: No
Submitted By: Rico (rico29600)
Assigned to: Bogdan-Andrei Iancu (bogdan_iancu)
Summary: Drouting rule fallback problem

Initial Comment:
I've got a problem with rule fallback in drouting module. Rulle fallback does not work as expected.
When my higher priority GW is not reachable, I've got a message " All the gateways are disabled"


See the config here, and the opensips log in attachment (debug level 6)
Running opensips 1.8.2


Hope somebody will be able to help me...

best regards

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


#opensips.log
Nov  7 14:09:51 opensips1 /sbin/opensips[14026]: [from sip:067364xxxx at 91.213.a.b / to sip:0970559999 at 91.213.a.b:5060 ]
Nov  7 14:09:51 opensips1 /sbin/opensips[14026]: Entering route[4]
Nov  7 14:09:51 opensips1 /sbin/opensips[14026]: ERROR:drouting:do_routing: All the gateways are disabled




##################################################################
#opensipsctl dr gw_status
ID:: 11 IP=46.226.x.y Enabled=no 
ID:: 12 IP=46.226.x.z Enabled=yes




##################################################################
#opensipsctl dr show
dr gateways
+----+------+------+----------------+-------+------------+-------+------------+------------------------------+
| id | gwid | type | address        | strip | pri_prefix | attrs | probe_mode | description                  |
+----+------+------+----------------+-------+------------+-------+------------+------------------------------+
|  5 | 11   |    1 | 46.226.x.y |     0 | NULL       | NULL  |          2 | OXO ASTI 1                   |
|  6 | 12   |    1 | 46.226.x.z |     0 | NULL       | NULL  |          2 | OXO ASTI 2                   |
+----+------+------+----------------+-------+------------+-------+------------+------------------------------+



##################################################################
dr rules
+--------+---------+------------+---------+----------+---------+--------+-------+---------------------------------------+
| ruleid | groupid | prefix     | timerec | priority | routeid | gwlist | attrs | description                           |
+--------+---------+------------+---------+----------+---------+--------+-------+---------------------------------------+
|     64 | 1       | 0970559999 |         |        1 |         | 11     | NULL  | SDA Test                       |
|     68 | 1       | 0970559999 |         |        0 |         | 12     | NULL  | SDA Test                       |

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

Comment By: Bogdan-Andrei Iancu (bogdan_iancu)
Date: 2012-11-22 05:54

Message:
Hi Rico,

Find attached the patch to fix the issue you have. Simply do now:
    if ( !do_routing("1","F") ) {}

Test the patch and let me know if you see any problems. I also uploaded the
patch on trunk SVN.

Thanks and regards,
Bogdan

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

Comment By: Bogdan-Andrei Iancu (bogdan_iancu)
Date: 2012-11-21 08:40

Message:
Trying to reproduce this locally. Indeed, it seems to be bug as
do_routing() internally cannot do fallback to a different rule . Currently
the fallback can be done only by calling use_next_gw().

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

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


From noreply at sourceforge.net  Thu Nov 22 15:04:32 2012
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 22 Nov 2012 06:04:32 -0800
Subject: [OpenSIPS-Devel] [ opensips-Bugs-3587163 ] Commit #9295 breaks
	dispatcher
Message-ID: <mailman.1213.1353593084.13469.devel@lists.opensips.org>

Bugs item #3587163, was opened at 2012-11-14 08:43
Message generated for change (Comment added) made by bogdan_iancu
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=3587163&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.8.x
Status: Open
>Resolution: Invalid
Priority: 5
Private: No
Submitted By: Dynamic Packet (dpacket)
Assigned to: Bogdan-Andrei Iancu (bogdan_iancu)
Summary: Commit #9295 breaks dispatcher

Initial Comment:
It seems commit #9295 on 1.8 branch breaks AVP in certain cases. Opensips starts fine and some avp related stuff works, but certain scenarios cause this: 

Nov 14 11:13:40 ip-10-173-81-249 /usr/sbin/opensips[1042]: ERROR:core:new_avp: invalid AVP name!
Nov 14 11:13:40 ip-10-173-81-249 /usr/sbin/opensips[1042]: ERROR:core:add_avp: Failed to create new avp structure

Script now does not execute as it should and in the end cause failures in call processing.  Its possible this also effects trunk (commit #9294) . I have tested by reverting this single commit (#9295) in most resent stable 1.8 and issue is resolved.

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

>Comment By: Bogdan-Andrei Iancu (bogdan_iancu)
Date: 2012-11-22 06:04

Message:
I checked the code (trunk + 1,8) and I see the fix there. Are you sure you
are using the latest 1.8 version ? maybe you do not have the fix in your
checkout.

Regards,
Bogdan

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

Comment By: Bogdan-Andrei Iancu (bogdan_iancu)
Date: 2012-11-21 08:39

Message:
I remember fixing this - I will check the backports

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

Comment By: Dynamic Packet (dpacket)
Date: 2012-11-14 10:29

Message:
This is a bug in dispatcher module. If you fail to set attrs_avp in script,
you get errors on ds_select_dst().  Default, per docs, should be null. But
ds_select_dst fails in this case after commit #9295. Setting attrs_avp in
config, seemingly fixes the issue.

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

Comment By: Dynamic Packet (dpacket)
Date: 2012-11-14 09:01

Message:
Hi Razvan,

I'm not 100% sure what function and I am unable to test at the moment. But
looking at the area of the script it occurs in, it could be ds_select_ds,
append_hf, xlog or least likely script comparisons/assignments.

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

Comment By: Razvan Crainea (razvancrainea)
Date: 2012-11-14 08:55

Message:
Hi!

Can you tell us when do you receive those errors? Is it a certain function
that uses AVPs and cannot find them?

Regards,
R?zvan

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

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


From noreply at sourceforge.net  Thu Nov 22 15:51:45 2012
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 22 Nov 2012 06:51:45 -0800
Subject: [OpenSIPS-Devel] [ opensips-Bugs-3587515 ] Drouting rule fallback
	problem
Message-ID: <mailman.1214.1353595911.13469.devel@lists.opensips.org>

Bugs item #3587515, was opened at 2012-11-15 05:56
Message generated for change (Comment added) made by rico29600
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=3587515&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.8.x
Status: Open
Resolution: Fixed
Priority: 5
Private: No
Submitted By: Rico (rico29600)
Assigned to: Bogdan-Andrei Iancu (bogdan_iancu)
Summary: Drouting rule fallback problem

Initial Comment:
I've got a problem with rule fallback in drouting module. Rulle fallback does not work as expected.
When my higher priority GW is not reachable, I've got a message " All the gateways are disabled"


See the config here, and the opensips log in attachment (debug level 6)
Running opensips 1.8.2


Hope somebody will be able to help me...

best regards

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


#opensips.log
Nov  7 14:09:51 opensips1 /sbin/opensips[14026]: [from sip:067364xxxx at 91.213.a.b / to sip:0970559999 at 91.213.a.b:5060 ]
Nov  7 14:09:51 opensips1 /sbin/opensips[14026]: Entering route[4]
Nov  7 14:09:51 opensips1 /sbin/opensips[14026]: ERROR:drouting:do_routing: All the gateways are disabled




##################################################################
#opensipsctl dr gw_status
ID:: 11 IP=46.226.x.y Enabled=no 
ID:: 12 IP=46.226.x.z Enabled=yes




##################################################################
#opensipsctl dr show
dr gateways
+----+------+------+----------------+-------+------------+-------+------------+------------------------------+
| id | gwid | type | address        | strip | pri_prefix | attrs | probe_mode | description                  |
+----+------+------+----------------+-------+------------+-------+------------+------------------------------+
|  5 | 11   |    1 | 46.226.x.y |     0 | NULL       | NULL  |          2 | OXO ASTI 1                   |
|  6 | 12   |    1 | 46.226.x.z |     0 | NULL       | NULL  |          2 | OXO ASTI 2                   |
+----+------+------+----------------+-------+------------+-------+------------+------------------------------+



##################################################################
dr rules
+--------+---------+------------+---------+----------+---------+--------+-------+---------------------------------------+
| ruleid | groupid | prefix     | timerec | priority | routeid | gwlist | attrs | description                           |
+--------+---------+------------+---------+----------+---------+--------+-------+---------------------------------------+
|     64 | 1       | 0970559999 |         |        1 |         | 11     | NULL  | SDA Test                       |
|     68 | 1       | 0970559999 |         |        0 |         | 12     | NULL  | SDA Test                       |

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

>Comment By: Rico (rico29600)
Date: 2012-11-22 06:51

Message:
Thanks Bogdan, will do the test as soon as possible

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

Comment By: Bogdan-Andrei Iancu (bogdan_iancu)
Date: 2012-11-22 05:54

Message:
Hi Rico,

Find attached the patch to fix the issue you have. Simply do now:
    if ( !do_routing("1","F") ) {}

Test the patch and let me know if you see any problems. I also uploaded the
patch on trunk SVN.

Thanks and regards,
Bogdan

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

Comment By: Bogdan-Andrei Iancu (bogdan_iancu)
Date: 2012-11-21 08:40

Message:
Trying to reproduce this locally. Indeed, it seems to be bug as
do_routing() internally cannot do fallback to a different rule . Currently
the fallback can be done only by calling use_next_gw().

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

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


From noreply at sourceforge.net  Thu Nov 22 15:56:06 2012
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 22 Nov 2012 06:56:06 -0800
Subject: [OpenSIPS-Devel] [ opensips-Bugs-3588141 ] 1.8.2 pua_dialoginfo
	regression
Message-ID: <mailman.1215.1353596173.13469.devel@lists.opensips.org>

Bugs item #3588141, was opened at 2012-11-17 02: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=3588141&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.8.x
Status: Open
Resolution: None
Priority: 7
Private: No
Submitted By: Damien Sandras (dsandras)
Assigned to: Bogdan-Andrei Iancu (bogdan_iancu)
Summary: 1.8.2 pua_dialoginfo regression

Initial Comment:
Release 1.8.2 with the various dialog patches probably breaks pua_dialog_info.

When a call is terminated, OpenSIPS does not send a NOTIFY anymore, even though the presentity table looks correct (the dialog info event document corresponding to the call is correctly removed from the table).

We had things working fine with 1.8.1 (except a few ghost dialogs which had been CANCELled), but in 1.8.2, our phones
receive a NOTIFY to indicate early/established state, but not terminated state.


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

>Comment By: Bogdan-Andrei Iancu (bogdan_iancu)
Date: 2012-11-22 06:56

Message:
Hi Damien,

Trying to reproduce here - the "terminated" state is done via BYE, MI or
Expire ?

Regards,
Bogdan

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

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


From noreply at sourceforge.net  Thu Nov 22 16:05:52 2012
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 22 Nov 2012 07:05:52 -0800
Subject: [OpenSIPS-Devel] [ opensips-Bugs-3588141 ] 1.8.2 pua_dialoginfo
	regression
Message-ID: <mailman.1216.1353596763.13469.devel@lists.opensips.org>

Bugs item #3588141, was opened at 2012-11-17 02:19
Message generated for change (Comment added) made by 
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=3588141&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.8.x
Status: Open
Resolution: None
Priority: 7
Private: No
Submitted By: Damien Sandras (dsandras)
Assigned to: Bogdan-Andrei Iancu (bogdan_iancu)
Summary: 1.8.2 pua_dialoginfo regression

Initial Comment:
Release 1.8.2 with the various dialog patches probably breaks pua_dialog_info.

When a call is terminated, OpenSIPS does not send a NOTIFY anymore, even though the presentity table looks correct (the dialog info event document corresponding to the call is correctly removed from the table).

We had things working fine with 1.8.1 (except a few ghost dialogs which had been CANCELled), but in 1.8.2, our phones
receive a NOTIFY to indicate early/established state, but not terminated state.


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

Comment By: https://www.google.com/accounts ()
Date: 2012-11-22 07:05

Message:
BYE
(but it could be any other message corresponding to the dialog end)

I'm using  dialoginfo_set("B"); and       dialoginfo_set("A");

I sent you a mail with more details on the infrastructure.

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

Comment By: Bogdan-Andrei Iancu (bogdan_iancu)
Date: 2012-11-22 06:56

Message:
Hi Damien,

Trying to reproduce here - the "terminated" state is done via BYE, MI or
Expire ?

Regards,
Bogdan

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

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


From vladpaiu at opensips.org  Thu Nov 22 18:39:58 2012
From: vladpaiu at opensips.org (Vlad Paiu)
Date: Thu, 22 Nov 2012 17:39:58 +0000
Subject: [OpenSIPS-Devel] SF.net SVN: opensips:[9446] branches/1.8
Message-ID: <E1Tbako-0008UM-63@sfp-svn-1.v30.ch3.sourceforge.com>

Revision: 9446
          http://opensips.svn.sourceforge.net/opensips/?rev=9446&view=rev
Author:   vladut-paiu
Date:     2012-11-22 17:39:57 +0000 (Thu, 22 Nov 2012)
Log Message:
-----------
fixed outgoing interface selection for locally generated messages

Modified Paths:
--------------
    branches/1.8/modules/tm/uac.c
    branches/1.8/msg_translator.c
    branches/1.8/msg_translator.h

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



From vladpaiu at opensips.org  Thu Nov 22 19:14:30 2012
From: vladpaiu at opensips.org (Vlad Paiu)
Date: Thu, 22 Nov 2012 18:14:30 +0000
Subject: [OpenSIPS-Devel] SF.net SVN: opensips:[9447] branches/1.8/forward.c
Message-ID: <E1TbbIE-0003C8-RT@sfp-svn-4.v30.ch3.sourceforge.com>

Revision: 9447
          http://opensips.svn.sourceforge.net/opensips/?rev=9447&view=rev
Author:   vladut-paiu
Date:     2012-11-22 18:14:30 +0000 (Thu, 22 Nov 2012)
Log Message:
-----------
backport from trunk (rev #9366)

- bug fixed: if no interface explicitly set, select as outbound interface the interface the message was received rather than the interface served by the process.

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

Modified Paths:
--------------
    branches/1.8/forward.c

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



From vladpaiu at opensips.org  Thu Nov 22 19:19:15 2012
From: vladpaiu at opensips.org (Vlad Paiu)
Date: Thu, 22 Nov 2012 18:19:15 +0000
Subject: [OpenSIPS-Devel] SF.net SVN: opensips:[9448] trunk
Message-ID: <E1TbbMp-0003da-7q@sfp-svn-4.v30.ch3.sourceforge.com>

Revision: 9448
          http://opensips.svn.sourceforge.net/opensips/?rev=9448&view=rev
Author:   vladut-paiu
Date:     2012-11-22 18:19:15 +0000 (Thu, 22 Nov 2012)
Log Message:
-----------
backport from 1.8 (rev #9446)

fixed outgoing interface selection for locally generated messages

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

Modified Paths:
--------------
    trunk/modules/tm/uac.c
    trunk/msg_translator.c
    trunk/msg_translator.h

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



From noreply at sourceforge.net  Thu Nov 22 19:19:58 2012
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 22 Nov 2012 10:19:58 -0800
Subject: [OpenSIPS-Devel] [ opensips-Bugs-3586775 ] Dialog Ping
Message-ID: <mailman.1217.1353608403.13469.devel@lists.opensips.org>

Bugs item #3586775, was opened at 2012-11-13 11:03
Message generated for change (Comment added) made by vladut-paiu
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=3586775&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.8.x
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Carlos Eduardo Wagner (kaduww)
Assigned to: Vladut-Stefan Paiu (vladut-paiu)
Summary: Dialog Ping

Initial Comment:
I'm having some problems with the Dialog Ping when using another port different from the 5060.
My opensips is listening on both ports, 5060 and 5062 and, as the trace attached, when the client is sending requests to the port 5062 and the dialog is created, the Dialog Ping sends the OPTIONS packet from the port 5060. Because of this, my client's NAT is blocking the packet, because its mapped to the port 5062 and not the 5060.

Follow the dialog information:
root at sipstage:/home/suporte# opensipsctl fifo dlg_list
dialog::  hash=2536:1633827324
	state:: 4
	user_flags:: 0
	timestart:: 1352831188
	timeout:: 1352838388
	callid:: a4e155f4320d43b9be48fde6457150ee
	from_uri:: sip:P0000000001 at sipstage.pligg.com.br
	to_uri:: sip:05130227701 at sipstage.pligg.com.br
	caller_tag:: 6fe6c313c92742a392fd75740f8867d7
	caller_contact:: sip:P0000000001 at 177.97.125.92:4057;ob
	callee_cseq:: 0
	caller_route_set:: 
	caller_bind_addr:: udp:177.129.74.30:5062
	callee_tag:: a94c095b773be1dd6e8d668a785a9c8470442779
	callee_contact:: sip:05130227701 at 201.56.167.2:5060
	caller_cseq:: 31678
	callee_route_set:: <sip:201.33.209.42;lr;did=8e96.0e1aebe1>,<sip:201.33.209.194;lr=on;did=8e9.c48a6f3>
	callee_bind_addr:: udp:177.129.74.30:5062

Here follows the OPTIONS part of the Trace:
U 2012/11/13 16:28:59.522813 177.129.74.30:5060 -> 177.97.125.92:4050
OPTIONS sip:P0000000025 at 177.97.125.92:4050;ob SIP/2.0.
Via: SIP/2.0/UDP 177.129.74.30:5062;branch=z9hG4bKf915.ddfebd02.0.
To: <sip:P0000000025 at sipstage.pligg.com.br>;tag=6caf1d8cdc4645719b25a6e120c90679.
From: <sip:05130227701 at sipstage.pligg.com.br>;tag=a94c095b773be1dd6e8d668a785a9c849cb5c894.
CSeq: 1 OPTIONS.
Call-ID: 433b8548a3944c2ea03a4a9cf2ce0bc4.
Max-Forwards: 70.
Content-Length: 0.
User-Agent: OpenSIPS (1.8.2-notls (x86_64/linux)).

* The SIP Trace attached was made while using the Opensips 1.8.1, but I did the test with the newest 1.8.x version e the problem was the same.

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

>Comment By: Vladut-Stefan Paiu (vladut-paiu)
Date: 2012-11-22 10:19

Message:
Hello,

I have committed a fix for this in the 1.8 branch and trunk.
Could you please update your sources and try again ?

Best Regards,
Vlad

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

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


From noreply at sourceforge.net  Thu Nov 22 19:25:21 2012
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 22 Nov 2012 10:25:21 -0800
Subject: [OpenSIPS-Devel] [ opensips-Bugs-3586775 ] Dialog Ping
Message-ID: <mailman.1218.1353608725.13469.devel@lists.opensips.org>

Bugs item #3586775, was opened at 2012-11-13 11:03
Message generated for change (Settings changed) made by vladut-paiu
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=3586775&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.8.x
Status: Open
>Resolution: Fixed
Priority: 5
Private: No
Submitted By: Carlos Eduardo Wagner (kaduww)
Assigned to: Vladut-Stefan Paiu (vladut-paiu)
Summary: Dialog Ping

Initial Comment:
I'm having some problems with the Dialog Ping when using another port different from the 5060.
My opensips is listening on both ports, 5060 and 5062 and, as the trace attached, when the client is sending requests to the port 5062 and the dialog is created, the Dialog Ping sends the OPTIONS packet from the port 5060. Because of this, my client's NAT is blocking the packet, because its mapped to the port 5062 and not the 5060.

Follow the dialog information:
root at sipstage:/home/suporte# opensipsctl fifo dlg_list
dialog::  hash=2536:1633827324
	state:: 4
	user_flags:: 0
	timestart:: 1352831188
	timeout:: 1352838388
	callid:: a4e155f4320d43b9be48fde6457150ee
	from_uri:: sip:P0000000001 at sipstage.pligg.com.br
	to_uri:: sip:05130227701 at sipstage.pligg.com.br
	caller_tag:: 6fe6c313c92742a392fd75740f8867d7
	caller_contact:: sip:P0000000001 at 177.97.125.92:4057;ob
	callee_cseq:: 0
	caller_route_set:: 
	caller_bind_addr:: udp:177.129.74.30:5062
	callee_tag:: a94c095b773be1dd6e8d668a785a9c8470442779
	callee_contact:: sip:05130227701 at 201.56.167.2:5060
	caller_cseq:: 31678
	callee_route_set:: <sip:201.33.209.42;lr;did=8e96.0e1aebe1>,<sip:201.33.209.194;lr=on;did=8e9.c48a6f3>
	callee_bind_addr:: udp:177.129.74.30:5062

Here follows the OPTIONS part of the Trace:
U 2012/11/13 16:28:59.522813 177.129.74.30:5060 -> 177.97.125.92:4050
OPTIONS sip:P0000000025 at 177.97.125.92:4050;ob SIP/2.0.
Via: SIP/2.0/UDP 177.129.74.30:5062;branch=z9hG4bKf915.ddfebd02.0.
To: <sip:P0000000025 at sipstage.pligg.com.br>;tag=6caf1d8cdc4645719b25a6e120c90679.
From: <sip:05130227701 at sipstage.pligg.com.br>;tag=a94c095b773be1dd6e8d668a785a9c849cb5c894.
CSeq: 1 OPTIONS.
Call-ID: 433b8548a3944c2ea03a4a9cf2ce0bc4.
Max-Forwards: 70.
Content-Length: 0.
User-Agent: OpenSIPS (1.8.2-notls (x86_64/linux)).

* The SIP Trace attached was made while using the Opensips 1.8.1, but I did the test with the newest 1.8.x version e the problem was the same.

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

Comment By: Vladut-Stefan Paiu (vladut-paiu)
Date: 2012-11-22 10:19

Message:
Hello,

I have committed a fix for this in the 1.8 branch and trunk.
Could you please update your sources and try again ?

Best Regards,
Vlad

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

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


From noreply at sourceforge.net  Fri Nov 23 10:22:10 2012
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 23 Nov 2012 01:22:10 -0800
Subject: [OpenSIPS-Devel] [ opensips-Bugs-3582533 ] sipcapture segfault
Message-ID: <mailman.1219.1353662535.13469.devel@lists.opensips.org>

Bugs item #3582533, was opened at 2012-11-01 11: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=3582533&group_id=232389

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: 1.8.x
Status: Open
>Resolution: Accepted
Priority: 5
Private: No
Submitted By: https://www.google.com/accounts ()
>Assigned to: Bogdan-Andrei Iancu (bogdan_iancu)
Summary: sipcapture segfault

Initial Comment:
The server is doing only sip_capture where packets are getting to it from captagent.
I've used opensips 1.8.0 and 1.8.1 on multiple servers all with the same result.
Also used older captagent and current captagent.
Attached back trace, opensips config, startup cmd, system info, and debug logs tail. All IPs replaced with private IPs. All original IPs were public IPs.




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

>Comment By: Bogdan-Andrei Iancu (bogdan_iancu)
Date: 2012-11-23 01:22

Message:
Bug was identified, in progress to be fixed.

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

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


From saul at ag-projects.com  Fri Nov 23 10:36:54 2012
From: saul at ag-projects.com (=?iso-8859-1?Q?Sa=FAl_Ibarra_Corretg=E9?=)
Date: Fri, 23 Nov 2012 10:36:54 +0100
Subject: [OpenSIPS-Devel] [OpenSIPS-Users] [RFC] New Release Policy for
	OpenSIPS project
In-Reply-To: <50AE2721.9090701@opensips.org>
References: <50ADFFBC.800@opensips.org>
	<8FDA43EA-EFAD-4B95-AD48-C83422A176F1@ag-projects.com>
	<50AE2721.9090701@opensips.org>
Message-ID: <C46E70EB-F392-4EB5-84FA-0643B313F447@ag-projects.com>

Hi,

> The problem I see with the features-based release cycle is that they are unpredictable as time - some features may not be properly (or impossible) time evaluated -> it may stretch the interval between releases ; IMHO, for a project to reliable it is a must to be predictable. The best examples are what is happening now with OpenSIPS (the interval between releases is keep growing) and Debian (lack of predictability and huge intervals between release ended up in the Ubuntu alternative).
> Being able to predict the releases (as time) without huge differences between versions (to make an upgrade something easy you are not scared like hell to do it) should be some key-feature of the project.
> 
> The time-based releases should not be affected by how long a feature takes to be implemented - 6 months of development for a feature is really more than enough, IMHO.
> 

I agree that is good for bugfix releases. However, when planning the next release (lets say 1.10) I guess you'd plan what features are to be implemented. Then of course time needs to be weighted in the equation, but IMHO the time constraint should be a bit more loose for major releases.

> 
> PS: let me ask you: how many OpenSIPS installations do you still have running old versions because upgrade is really painful ? ;)

Fortunately not many :-) I had to migrate from 1.4 to 1.8 and, well, things can get complicated. Of course the gap is big and wouldn't be so big between 1.7 and 1.8 or between 1.8 and 1.9, but updating requires time and a reason. If a customer has a working OpenSIPS version and I update it just for the sake of it, new bugs can be introduced, and he'll probably not see any of the new features because he doesn't need them, for example. This is what I mean by not taking it lightly.

[snip]

>> What about security fixes? I can understand that when 1.9 is released 1.7 goes to EOL (sort of), but what if there is a bug in the parser (for example) which can cause a crash just by using a stupid script? IMHO there should be a security-fixes-only period, since migrating to a new OpenSIPS version is not  a task to be taken lightly.
> [bogdan]
> That is true problem that may have as solutions:
>    1) simply upgrade (most common way to go in open source world) , considering that upgrades should become easier.

New versions have new features and new bugs. So updating may get you trouble for little gain, in case you are not using any of the new stuff.

>    2) try to define what is really critical (based on what??) and still do backporting - but at the end of the day we need to encourage people to use the new versions - keep patching and supporting really old versions (consider 1.6 at this point) is a waist of effort. Taking your example: debian is not supporting something older than 1 release :D....
> 

Not 100% accurate: -) "The security team tries to support a stable distribution for about one year after the next stable distribution has been released". So Debian "oldstable" still gets security updates a year after "stable" has been out.

We can try to see how a similar approach can work out for us. Instead of a year, say 6 months. What's important is to define what a security fix is and what it's not. An error in the software that can be consistently triggered from the outside (ie, with SIP traffic) and cause any kind of outage could be considered a security fix. This is from the top of my head, it would need to be refined :-)


Regards,

--
Sa?l Ibarra Corretg?
AG Projects





From bogdan at opensips.org  Fri Nov 23 13:38:42 2012
From: bogdan at opensips.org (Bogdan-Andrei Iancu)
Date: Fri, 23 Nov 2012 12:38:42 +0000
Subject: [OpenSIPS-Devel] SF.net SVN: opensips:[9449]
	branches/1.8/modules/drouting/drouting.c
Message-ID: <E1TbsWo-00075Y-7K@sfp-svn-1.v30.ch3.sourceforge.com>

Revision: 9449
          http://opensips.svn.sourceforge.net/opensips/?rev=9449&view=rev
Author:   bogdan_iancu
Date:     2012-11-23 12:38:41 +0000 (Fri, 23 Nov 2012)
Log Message:
-----------
- fix bug in port matching (side effect of the fix for doing SIP-wise DNS lookup on destination). This affects only goes_to_gw() function.

Modified Paths:
--------------
    branches/1.8/modules/drouting/drouting.c

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



From noreply at sourceforge.net  Fri Nov 23 14:15:56 2012
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 23 Nov 2012 05:15:56 -0800
Subject: [OpenSIPS-Devel] [ opensips-Bugs-3589398 ] db_mysql crash
Message-ID: <mailman.1220.1353676565.13469.devel@lists.opensips.org>

Bugs item #3589398, was opened at 2012-11-23 05:15
Message generated for change (Tracker Item Submitted) made by dragosoancea
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=3589398&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.8.x
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Dragos Oancea (dragosoancea)
Assigned to: Nobody/Anonymous (nobody)
Summary: db_mysql crash

Initial Comment:
Hi

I just found a core file generated by opensips on one of our servers which used to be pretty stable.

Core was generated by `/usr/sbin/opensips -P /var/run/opensips.pid -f /etc/opensips/opensips.cfg'.
Program terminated with signal 11, Segmentation fault.
#0  0x00007fbf502448de in vfprintf () from /lib64/libc.so.6
Missing separate debuginfos, use: debuginfo-install opensips-1.8.1-4.debug.el6.x86_64
(gdb) bt
#0  0x00007fbf502448de in vfprintf () from /lib64/libc.so.6
#1  0x00007fbf502fc2c0 in __vsnprintf_chk () from /lib64/libc.so.6
#2  0x00007fbf502fc1fa in __snprintf_chk () from /lib64/libc.so.6
#3  0x00000000004c44e9 in db_print_where ()
#4  0x00000000004c27f6 in db_do_delete ()
#5  0x00007fbf4ea32f54 in db_mysql_delete (_h=0x7fbf4ecf1558, _k=0x7fff682eaa20, _o=0x7fff682eaa10, _v=0x7fff682ea9d0, _n=2) at dbase.c:1061
#6  0x00007fbf4d18825d in db_timer_udomain (_d=0x7fbf28946f88) at udomain.c:612
#7  0x00007fbf4d1830e1 in synchronize_all_udomains () at dlist.c:591
#8  0x00007fbf4d18e408 in timer (ticks=<value optimized out>, param=<value optimized out>) at ul_mod.c:387
#9  0x000000000047d73a in start_timer_processes ()
#10 0x000000000042aa84 in main ()
(gdb) bt full 
#0  0x00007fbf502448de in vfprintf () from /lib64/libc.so.6
No symbol table info available.
#1  0x00007fbf502fc2c0 in __vsnprintf_chk () from /lib64/libc.so.6
No symbol table info available.
#2  0x00007fbf502fc1fa in __snprintf_chk () from /lib64/libc.so.6
No symbol table info available.
#3  0x00000000004c44e9 in db_print_where ()
No symbol table info available.
#4  0x00000000004c27f6 in db_do_delete ()
No symbol table info available.
#5  0x00007fbf4ea32f54 in db_mysql_delete (_h=0x7fbf4ecf1558, _k=0x7fff682eaa20, _o=0x7fff682eaa10, _v=0x7fff682ea9d0, _n=2) at dbase.c:1061
        ret = <value optimized out>
#6  0x00007fbf4d18825d in db_timer_udomain (_d=0x7fbf28946f88) at udomain.c:612
        my_ps = 0x7fbf4ecf42f0
        keys = {0x7fff682eaac0, 0x7fbf5029915d}
        ops = {0x0, 0x7fbf4ecc77e8 "\001"}
        vals = {{type = DB_DATETIME, nul = 0, free = 0, val = {int_val = 1353067975, bigint_val = 1353067975, double_val = 6.6850440293548263e-315, time_val = 1353067975, string_val = 0x50a62dc7 <Address 0x50a62dc7 out of bounds>, 
              str_val = {s = 0x50a62dc7 <Address 0x50a62dc7 out of bounds>, len = 100000}, blob_val = {s = 0x50a62dc7 <Address 0x50a62dc7 out of bounds>, len = 100000}, bitmap_val = 1353067975}}, {type = DB_DATETIME, nul = 0, 
            free = -10484703, val = {int_val = 0, bigint_val = 0, double_val = 0, time_val = 0, string_val = 0x0, str_val = {s = 0x0, len = 132100}, blob_val = {s = 0x0, len = 132100}, bitmap_val = 0}}}
        __FUNCTION__ = "db_timer_udomain"
#7  0x00007fbf4d1830e1 in synchronize_all_udomains () at dlist.c:591
        res = <value optimized out>
        ptr = 0x7fbf28946f28
#8  0x00007fbf4d18e408 in timer (ticks=<value optimized out>, param=<value optimized out>) at ul_mod.c:387
        __FUNCTION__ = "timer"
#9  0x000000000047d73a in start_timer_processes ()
No symbol table info available.
#10 0x000000000042aa84 in main ()


# opensips -V
version: opensips 1.8.1-tls (x86_64/linux)
flags: STATS: Off, USE_IPV6, USE_TCP, USE_TLS, DISABLE_NAGLE, USE_MCAST, SHM_MEM, SHM_MMAP, PKG_MALLOC, F_MALLOC, FAST_LOCK-ADAPTIVE_WAIT
ADAPTIVE_WAIT_LOOPS=1024, MAX_RECV_BUFFER_SIZE 262144, MAX_LISTEN 16, MAX_URI_SIZE 1024, BUF_SIZE 65535
poll method support: poll, epoll_lt, epoll_et, sigio_rt, select.
svnrevision: unknown
@(#) $Id: main.c 8772 2012-03-08 11:16:13Z bogdan_iancu $
main.c compiled on 15:18:52 Sep 28 2012 with gcc 4.4.6

I have no idea what happened. Maybe someone has a theory.

Regards,
Dragos

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

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


From liviu at opensips.org  Fri Nov 23 14:57:47 2012
From: liviu at opensips.org (Liviu Chircu)
Date: Fri, 23 Nov 2012 13:57:47 +0000
Subject: [OpenSIPS-Devel] SF.net SVN: opensips:[9450] trunk
Message-ID: <E1TbtlL-0000Ek-5g@sfp-svn-2.v30.ch3.sourceforge.com>

Revision: 9450
          http://opensips.svn.sourceforge.net/opensips/?rev=9450&view=rev
Author:   liviuchircu
Date:     2012-11-23 13:57:46 +0000 (Fri, 23 Nov 2012)
Log Message:
-----------
- cfgutils module: added check_time_rec() function, which matches a time recurrence string against the current date.
- moved load_TR_value macro from dr_load.c to time_rec.h

Modified Paths:
--------------
    trunk/modules/cfgutils/README
    trunk/modules/cfgutils/cfgutils.c
    trunk/modules/cfgutils/doc/cfgutils_admin.xml
    trunk/modules/drouting/dr_load.c
    trunk/time_rec.h

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



From vladpaiu at opensips.org  Fri Nov 23 15:13:40 2012
From: vladpaiu at opensips.org (Vlad Paiu)
Date: Fri, 23 Nov 2012 14:13:40 +0000
Subject: [OpenSIPS-Devel] SF.net SVN: opensips:[9451]
	trunk/modules/dialog/dlg_timer.c
Message-ID: <E1Tbu0i-0000a8-Ue@sfp-svn-3.v30.ch3.sourceforge.com>

Revision: 9451
          http://opensips.svn.sourceforge.net/opensips/?rev=9451&view=rev
Author:   vladut-paiu
Date:     2012-11-23 14:13:40 +0000 (Fri, 23 Nov 2012)
Log Message:
-----------
fixed bug where dialog was marked as removed from ping list without having the ping list lock

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

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



From vladpaiu at opensips.org  Fri Nov 23 16:01:17 2012
From: vladpaiu at opensips.org (Vlad Paiu)
Date: Fri, 23 Nov 2012 15:01:17 +0000
Subject: [OpenSIPS-Devel] SF.net SVN: opensips:[9452]
	branches/1.8/modules/dialog/dlg_timer.c
Message-ID: <E1Tbukn-0003Ut-7S@sfp-svn-4.v30.ch3.sourceforge.com>

Revision: 9452
          http://opensips.svn.sourceforge.net/opensips/?rev=9452&view=rev
Author:   vladut-paiu
Date:     2012-11-23 15:01:16 +0000 (Fri, 23 Nov 2012)
Log Message:
-----------
backport from trunk (rev #9451)

fixed bug where dialog was marked as removed from ping list without having the ping list lock

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

Modified Paths:
--------------
    branches/1.8/modules/dialog/dlg_timer.c

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



From osas at voipembedded.com  Fri Nov 23 16:30:46 2012
From: osas at voipembedded.com (Ovidiu Sas)
Date: Fri, 23 Nov 2012 10:30:46 -0500
Subject: [OpenSIPS-Devel] SF.net SVN: opensips:[9450] trunk
In-Reply-To: <E1TbtlL-0000Ek-5g@sfp-svn-2.v30.ch3.sourceforge.com>
References: <E1TbtlL-0000Ek-5g@sfp-svn-2.v30.ch3.sourceforge.com>
Message-ID: <CAND0LksSXaz+R2fM3gWXLGiQqrsj2qZnCdDbg+ZLWU_5P5sXKQ@mail.gmail.com>

Hello Liviu,

The README should specify that the time_string parameter is compatible
with RFC 2445.
Also, RFC 2445 was obsolete by RFC 5545.  I don't know how much of the
RFC 2445 was implemented.  Maybe the code is compatible with the new
rfc.  Here are the differences between the to:
http://tools.ietf.org/html/rfc5545#appendix-A

Thanks for the new addition :)

Regards,
Ovidiu Sas


On Fri, Nov 23, 2012 at 8:57 AM, Liviu Chircu <liviu at opensips.org> wrote:
> Revision: 9450
>           http://opensips.svn.sourceforge.net/opensips/?rev=9450&view=rev
> Author:   liviuchircu
> Date:     2012-11-23 13:57:46 +0000 (Fri, 23 Nov 2012)
> Log Message:
> -----------
> - cfgutils module: added check_time_rec() function, which matches a time recurrence string against the current date.
> - moved load_TR_value macro from dr_load.c to time_rec.h
>
> Modified Paths:
> --------------
>     trunk/modules/cfgutils/README
>     trunk/modules/cfgutils/cfgutils.c
>     trunk/modules/cfgutils/doc/cfgutils_admin.xml
>     trunk/modules/drouting/dr_load.c
>     trunk/time_rec.h
>
> This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site.
>
>
> _______________________________________________
> Devel mailing list
> Devel at lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/devel



-- 
VoIP Embedded, Inc.
http://www.voipembedded.com


From noreply at sourceforge.net  Sat Nov 24 07:21:49 2012
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 23 Nov 2012 22:21:49 -0800
Subject: [OpenSIPS-Devel] [ opensips-Bugs-3585606 ] TCP Deadlock
Message-ID: <mailman.1221.1353738114.13469.devel@lists.opensips.org>

Bugs item #3585606, was opened at 2012-11-08 20:47
Message generated for change (Comment added) made by dmsanders
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=3585606&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.8.x
Status: Open
Resolution: None
Priority: 9
Private: No
Submitted By: David Sanders (dmsanders)
Assigned to: Bogdan-Andrei Iancu (bogdan_iancu)
Summary: TCP Deadlock

Initial Comment:
There is a serious deadlock issue when using TCP with OpenSIPS (1.8.0-tls). I found this paper which has the same conclusion (but is discussing OpenSER circa 2008): http://www.cs.rice.edu/CS/Architecture/docs/ram-ispass08.pdf

I'll quote the relevant part of Section 6:

This can lead to deadlock in the following situation. When a
worker process requests a connection from
the supervisor process, it then blocks waiting to receive that
?le descriptor. If, at the same time, the supervisor process
blocks waiting to send a new connection to the same worker
(since the buffer at the receiver is full), the two processes
will deadlock. Once the supervisor process deadlocks, no
other worker can make progress either, as they will quickly
need their own connections from the supervisor process.
Similarly, no new connections will be accepted. This clearly
illustrates that in an event-driven server, one must be careful
to only read from sockets when the event mechanism says
there is something to read and only write to sockets when
the event mechanism says there is space to write.

I can reliably reproduce this deadlock with any number of TCP children. Interestingly it seems to happen faster with a larger number of children. Under constant load, once the main TCP process deadlocks, all the children will as well.

It seems to be rate related. Using SIPp to drive TCP traffic to an OpenSIPS server, 50 registers/second do not encounter the deadlock issue. However, if increase the traffic load a deadlock will occur within 30 seconds. My theory is that if the TCP children can't process a message and reply faster than they are coming in (in this case faster than 20ms) then the deadlock will occur.

For completeness the GDB backtrace output of the deadlocked processes when running two TCP children are attached.

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

>Comment By: David Sanders (dmsanders)
Date: 2012-11-23 22:21

Message:
Hi Bogdan,

Is there any news on this?

Could you give some kind of prediction on when this could be fixed by?
Before the end of the year, or not until 1.9 or?

Any information on a timeline would help me figure out how to proceed with
my project in a timely manner.

Thanks,
- David 

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

Comment By: Bogdan-Andrei Iancu (bogdan_iancu)
Date: 2012-11-09 09:40

Message:
Hi David - thank you for the report - I will look into it asap !

Regards,
Bogdan

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

Comment By: David Sanders (dmsanders)
Date: 2012-11-08 20:49

Message:
I took the liberty of upgrading this to a higher priority bug since it can
completely deadlock TCP traffic for a server if the call rate gets too
high.

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

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


From alipey at gmail.com  Sun Nov 25 15:22:32 2012
From: alipey at gmail.com (Ali Pey)
Date: Sun, 25 Nov 2012 09:22:32 -0500
Subject: [OpenSIPS-Devel] [OpenSIPS-Users] [RFC] New Release Policy for
	OpenSIPS project
In-Reply-To: <C46E70EB-F392-4EB5-84FA-0643B313F447@ag-projects.com>
References: <50ADFFBC.800@opensips.org>
	<8FDA43EA-EFAD-4B95-AD48-C83422A176F1@ag-projects.com>
	<50AE2721.9090701@opensips.org>
	<C46E70EB-F392-4EB5-84FA-0643B313F447@ag-projects.com>
Message-ID: <CA+q4kRJ_MuWBwEpJop9AcDMhWeiF52bnwgpYVUYG3VQNq24WYQ@mail.gmail.com>

Hi Bogdan,

This is great to see and I quite like the more open, predictable and
transparent approach. I also agree that a time driven release cycle is more
practical than feature driven. There are always grey areas and exceptions
but in practice a time driven release cycle is much better manageable for
real world deployments.

In terms of support for previous releases, as much as it would allow a
deployment to go on for two years before it requires an upgrade I agree.
It's not practical to have more frequent upgrade cycles. Also most people
don't usually upgrade to the latest version. For instance when 1.9 comes
out, we probably will upgrade to 1.8.2.

Again, this is a great step forward for opensips development and thank you
for the great work.

Regards,
Ali Pey



On Fri, Nov 23, 2012 at 4:36 AM, Sa?l Ibarra Corretg?
<saul at ag-projects.com>wrote:

> Hi,
>
> > The problem I see with the features-based release cycle is that they are
> unpredictable as time - some features may not be properly (or impossible)
> time evaluated -> it may stretch the interval between releases ; IMHO, for
> a project to reliable it is a must to be predictable. The best examples are
> what is happening now with OpenSIPS (the interval between releases is keep
> growing) and Debian (lack of predictability and huge intervals between
> release ended up in the Ubuntu alternative).
> > Being able to predict the releases (as time) without huge differences
> between versions (to make an upgrade something easy you are not scared like
> hell to do it) should be some key-feature of the project.
> >
> > The time-based releases should not be affected by how long a feature
> takes to be implemented - 6 months of development for a feature is really
> more than enough, IMHO.
> >
>
> I agree that is good for bugfix releases. However, when planning the next
> release (lets say 1.10) I guess you'd plan what features are to be
> implemented. Then of course time needs to be weighted in the equation, but
> IMHO the time constraint should be a bit more loose for major releases.
>
> >
> > PS: let me ask you: how many OpenSIPS installations do you still have
> running old versions because upgrade is really painful ? ;)
>
> Fortunately not many :-) I had to migrate from 1.4 to 1.8 and, well,
> things can get complicated. Of course the gap is big and wouldn't be so big
> between 1.7 and 1.8 or between 1.8 and 1.9, but updating requires time and
> a reason. If a customer has a working OpenSIPS version and I update it just
> for the sake of it, new bugs can be introduced, and he'll probably not see
> any of the new features because he doesn't need them, for example. This is
> what I mean by not taking it lightly.
>
> [snip]
>
> >> What about security fixes? I can understand that when 1.9 is released
> 1.7 goes to EOL (sort of), but what if there is a bug in the parser (for
> example) which can cause a crash just by using a stupid script? IMHO there
> should be a security-fixes-only period, since migrating to a new OpenSIPS
> version is not  a task to be taken lightly.
> > [bogdan]
> > That is true problem that may have as solutions:
> >    1) simply upgrade (most common way to go in open source world) ,
> considering that upgrades should become easier.
>
> New versions have new features and new bugs. So updating may get you
> trouble for little gain, in case you are not using any of the new stuff.
>
> >    2) try to define what is really critical (based on what??) and still
> do backporting - but at the end of the day we need to encourage people to
> use the new versions - keep patching and supporting really old versions
> (consider 1.6 at this point) is a waist of effort. Taking your example:
> debian is not supporting something older than 1 release :D....
> >
>
> Not 100% accurate: -) "The security team tries to support a stable
> distribution for about one year after the next stable distribution has been
> released". So Debian "oldstable" still gets security updates a year after
> "stable" has been out.
>
> We can try to see how a similar approach can work out for us. Instead of a
> year, say 6 months. What's important is to define what a security fix is
> and what it's not. An error in the software that can be consistently
> triggered from the outside (ie, with SIP traffic) and cause any kind of
> outage could be considered a security fix. This is from the top of my head,
> it would need to be refined :-)
>
>
> Regards,
>
> --
> Sa?l Ibarra Corretg?
> AG Projects
>
>
>
>
> _______________________________________________
> Users mailing list
> Users at lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/devel/attachments/20121125/dcb4b805/attachment.htm>

From noreply at sourceforge.net  Mon Nov 26 08:22:35 2012
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun, 25 Nov 2012 23:22:35 -0800
Subject: [OpenSIPS-Devel] [ opensips-Bugs-3589142 ] B2B: crash when request
	without from_tag or to header
Message-ID: <mailman.1222.1353914560.13469.devel@lists.opensips.org>

Bugs item #3589142, was opened at 2012-11-22 05:41
Message generated for change (Comment added) made by nikbyte
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=3589142&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: Nick Altmann (nikbyte)
Assigned to: Nobody/Anonymous (nobody)
>Summary: B2B: crash when request without from_tag or to header

Initial Comment:
Sometimes buggy UACs send in-b2b-dialog CANCEL without from_tag.
b2b_entities module crashes in dlg.c on line 645:
hash_index = core_hash(&callid, &from_tag, server_hsize);

because from_tag is empty.


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

>Comment By: Nick Altmann (nikbyte)
Date: 2012-11-25 23:22

Message:
I've tested it again. Any packet without from tag or without to header
crashes opensips!

Patch attached.


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

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


From osas at voipembedded.com  Mon Nov 26 19:23:09 2012
From: osas at voipembedded.com (Ovidiu Sas)
Date: Mon, 26 Nov 2012 13:23:09 -0500
Subject: [OpenSIPS-Devel] [OpenSIPS-Users] [RELEASE] OpenSIPS 1.8.2
	Minor Stable Release
In-Reply-To: <5092C267.8040303@opensips.org>
References: <5092C267.8040303@opensips.org>
Message-ID: <CAND0Lkt4CWN0DH1q+VX1kqLwZCWMNKPvzdwgSsRe3dVmo31dvQ@mail.gmail.com>

Hello all,

For those who like running opensips on routers and/or other small
embedded systems, the latest opensips stable is available for
download.
For more info, please check: http://www.nslu2-linux.org/wiki/Optware/HomePage
For a list of supported platforms, please check:
http://www.nslu2-linux.org/wiki/Optware/Platforms

Regards,
Ovidiu Sas

-- 
VoIP Embedded, Inc.
http://www.voipembedded.com

On Thu, Nov 1, 2012 at 2:41 PM, Bogdan-Andrei Iancu <bogdan at opensips.org> wrote:
> Hi all,
>
> OpenSIPS 1.8.2 is the second minor release of the 1.8 branch, bringing even
> a more stable version of 1.8 branch with more fixes - crashes, malfunctions
> and compliance (but no functionality, scripting or interfacing were
> changed).
>
> OpenSIPS 1.8.2 brings important fixes in:
>
> TLS / TCP engine
> Dialog module
> Presence and RLS support
> Dispatcher module
> SIP parser
> scripting (startup and timer routes)
> Dynamic Routing module
> Statistics reporting (for PKG and SHM memory)
> B2B module - requests handing, script routes triggering.
>
> It is highly recommended to upgrade - OpenSIPS 1.8.2 is now available for
> download on project web site and SF download system.
>
> Many thanks to all people contributing to this release:
>
> http://opensips.svn.sourceforge.net/viewvc/opensips/branches/1.8/CREDITS?revision=9418&view=markup
>
> The full Changelog is available here :
>     http://opensips.org/pub/opensips/1.8.2/src/ChangeLog
>
> To get the OpenSIPS 1.8.2 version, see:
>     http://www.opensips.org/Resources/Downloads
>
> Enjoy,
> Bogdan


From noreply at sourceforge.net  Mon Nov 26 19:53:29 2012
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 26 Nov 2012 10:53:29 -0800
Subject: [OpenSIPS-Devel] [ opensips-Bugs-3587163 ] Commit #9295 breaks
	dispatcher
Message-ID: <mailman.1223.1353956018.13469.devel@lists.opensips.org>

Bugs item #3587163, was opened at 2012-11-14 08:43
Message generated for change (Comment added) made by dpacket
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=3587163&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.8.x
Status: Open
Resolution: Invalid
Priority: 5
Private: No
Submitted By: Dynamic Packet (dpacket)
Assigned to: Bogdan-Andrei Iancu (bogdan_iancu)
Summary: Commit #9295 breaks dispatcher

Initial Comment:
It seems commit #9295 on 1.8 branch breaks AVP in certain cases. Opensips starts fine and some avp related stuff works, but certain scenarios cause this: 

Nov 14 11:13:40 ip-10-173-81-249 /usr/sbin/opensips[1042]: ERROR:core:new_avp: invalid AVP name!
Nov 14 11:13:40 ip-10-173-81-249 /usr/sbin/opensips[1042]: ERROR:core:add_avp: Failed to create new avp structure

Script now does not execute as it should and in the end cause failures in call processing.  Its possible this also effects trunk (commit #9294) . I have tested by reverting this single commit (#9295) in most resent stable 1.8 and issue is resolved.

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

>Comment By: Dynamic Packet (dpacket)
Date: 2012-11-26 10:53

Message:
I can assure you that SVN checkout of 1.8 as of 2012-11-14 did not solve
the problem for me. Was the fix committed after this? Otherwise, perhaps
its not working in some case(s) ?

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

Comment By: Bogdan-Andrei Iancu (bogdan_iancu)
Date: 2012-11-22 06:04

Message:
I checked the code (trunk + 1,8) and I see the fix there. Are you sure you
are using the latest 1.8 version ? maybe you do not have the fix in your
checkout.

Regards,
Bogdan

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

Comment By: Bogdan-Andrei Iancu (bogdan_iancu)
Date: 2012-11-21 08:39

Message:
I remember fixing this - I will check the backports

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

Comment By: Dynamic Packet (dpacket)
Date: 2012-11-14 10:29

Message:
This is a bug in dispatcher module. If you fail to set attrs_avp in script,
you get errors on ds_select_dst().  Default, per docs, should be null. But
ds_select_dst fails in this case after commit #9295. Setting attrs_avp in
config, seemingly fixes the issue.

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

Comment By: Dynamic Packet (dpacket)
Date: 2012-11-14 09:01

Message:
Hi Razvan,

I'm not 100% sure what function and I am unable to test at the moment. But
looking at the area of the script it occurs in, it could be ds_select_ds,
append_hf, xlog or least likely script comparisons/assignments.

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

Comment By: Razvan Crainea (razvancrainea)
Date: 2012-11-14 08:55

Message:
Hi!

Can you tell us when do you receive those errors? Is it a certain function
that uses AVPs and cannot find them?

Regards,
R?zvan

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

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


From bogdan at opensips.org  Mon Nov 26 22:43:23 2012
From: bogdan at opensips.org (Bogdan-Andrei Iancu)
Date: Mon, 26 Nov 2012 23:43:23 +0200
Subject: [OpenSIPS-Devel] [OpenSIPS-Users] [RELEASE] OpenSIPS 1.8.2
	Minor Stable Release
In-Reply-To: <CAND0Lkt4CWN0DH1q+VX1kqLwZCWMNKPvzdwgSsRe3dVmo31dvQ@mail.gmail.com>
References: <5092C267.8040303@opensips.org>
	<CAND0Lkt4CWN0DH1q+VX1kqLwZCWMNKPvzdwgSsRe3dVmo31dvQ@mail.gmail.com>
Message-ID: <50B3E27B.40307@opensips.org>

Hi Ovidiu,

Is it ok if I list those two links on the official download page ?

Regards,

Bogdan-Andrei Iancu
OpenSIPS Founder and Developer
http://www.opensips-solutions.com


On 11/26/2012 08:23 PM, Ovidiu Sas wrote:
> Hello all,
>
> For those who like running opensips on routers and/or other small
> embedded systems, the latest opensips stable is available for
> download.
> For more info, please check: http://www.nslu2-linux.org/wiki/Optware/HomePage
> For a list of supported platforms, please check:
> http://www.nslu2-linux.org/wiki/Optware/Platforms
>
> Regards,
> Ovidiu Sas
>


From osas at voipembedded.com  Mon Nov 26 22:48:12 2012
From: osas at voipembedded.com (Ovidiu Sas)
Date: Mon, 26 Nov 2012 16:48:12 -0500
Subject: [OpenSIPS-Devel] [OpenSIPS-Users] [RELEASE] OpenSIPS 1.8.2
	Minor Stable Release
In-Reply-To: <50B3E27B.40307@opensips.org>
References: <5092C267.8040303@opensips.org>
	<CAND0Lkt4CWN0DH1q+VX1kqLwZCWMNKPvzdwgSsRe3dVmo31dvQ@mail.gmail.com>
	<50B3E27B.40307@opensips.org>
Message-ID: <CAND0LktQeeKHLBXGBOwT5HW9m7q=7rjVW2Ec5HsV08U88RyxOg@mail.gmail.com>

Of course :)

-ovidiu

On Mon, Nov 26, 2012 at 4:43 PM, Bogdan-Andrei Iancu
<bogdan at opensips.org> wrote:
> Hi Ovidiu,
>
> Is it ok if I list those two links on the official download page ?
>
> Regards,
>
>
> Bogdan-Andrei Iancu
> OpenSIPS Founder and Developer
> http://www.opensips-solutions.com
>
>
> On 11/26/2012 08:23 PM, Ovidiu Sas wrote:
>>
>> Hello all,
>>
>> For those who like running opensips on routers and/or other small
>> embedded systems, the latest opensips stable is available for
>> download.
>> For more info, please check:
>> http://www.nslu2-linux.org/wiki/Optware/HomePage
>> For a list of supported platforms, please check:
>> http://www.nslu2-linux.org/wiki/Optware/Platforms
>>
>> Regards,
>> Ovidiu Sas
>>


From bogdan at opensips.org  Mon Nov 26 22:57:29 2012
From: bogdan at opensips.org (Bogdan-Andrei Iancu)
Date: Mon, 26 Nov 2012 23:57:29 +0200
Subject: [OpenSIPS-Devel] [OpenSIPS-Users] [RFC] New Release Policy for
	OpenSIPS project
In-Reply-To: <CA+q4kRJ_MuWBwEpJop9AcDMhWeiF52bnwgpYVUYG3VQNq24WYQ@mail.gmail.com>
References: <50ADFFBC.800@opensips.org>	<8FDA43EA-EFAD-4B95-AD48-C83422A176F1@ag-projects.com>	<50AE2721.9090701@opensips.org>	<C46E70EB-F392-4EB5-84FA-0643B313F447@ag-projects.com>
	<CA+q4kRJ_MuWBwEpJop9AcDMhWeiF52bnwgpYVUYG3VQNq24WYQ@mail.gmail.com>
Message-ID: <50B3E5C9.7010006@opensips.org>

Hi Ali,

Thanks for feedback - regarding the support for previous releases, Saul 
raised the same point as you, and I have to admit I didn't do the math - 
2 release ~= 1 year, which indeed is too short - I mean this will force 
an upgrade each year.

So, we need to somehow get to ~ 2 year lifetime for a release. My 
suggestion is to actually set a life span for 2 years.

Regards,

Bogdan-Andrei Iancu
OpenSIPS Founder and Developer
http://www.opensips-solutions.com


On 11/25/2012 04:22 PM, Ali Pey wrote:
> Hi Bogdan,
>
> This is great to see and I quite like the more open, predictable and 
> transparent approach. I also agree that a time driven release cycle is 
> more practical than feature driven. There are always grey areas and 
> exceptions but in practice a time driven release cycle is much better 
> manageable for real world deployments.
>
> In terms of support for previous releases, as much as it would allow a 
> deployment to go on for two years before it requires an upgrade I 
> agree. It's not practical to have more frequent upgrade cycles. Also 
> most people don't usually upgrade to the latest version. For instance 
> when 1.9 comes out, we probably will upgrade to 1.8.2.
>
> Again, this is a great step forward for opensips development and thank 
> you for the great work.
>
> Regards,
> Ali Pey
>
>
> On Fri, Nov 23, 2012 at 4:36 AM, Sa?l Ibarra Corretg? 
> <saul at ag-projects.com <mailto:saul at ag-projects.com>> wrote:
>
>     Hi,
>
>     > The problem I see with the features-based release cycle is that
>     they are unpredictable as time - some features may not be properly
>     (or impossible) time evaluated -> it may stretch the interval
>     between releases ; IMHO, for a project to reliable it is a must to
>     be predictable. The best examples are what is happening now with
>     OpenSIPS (the interval between releases is keep growing) and
>     Debian (lack of predictability and huge intervals between release
>     ended up in the Ubuntu alternative).
>     > Being able to predict the releases (as time) without huge
>     differences between versions (to make an upgrade something easy
>     you are not scared like hell to do it) should be some key-feature
>     of the project.
>     >
>     > The time-based releases should not be affected by how long a
>     feature takes to be implemented - 6 months of development for a
>     feature is really more than enough, IMHO.
>     >
>
>     I agree that is good for bugfix releases. However, when planning
>     the next release (lets say 1.10) I guess you'd plan what features
>     are to be implemented. Then of course time needs to be weighted in
>     the equation, but IMHO the time constraint should be a bit more
>     loose for major releases.
>
>     >
>     > PS: let me ask you: how many OpenSIPS installations do you still
>     have running old versions because upgrade is really painful ? ;)
>
>     Fortunately not many :-) I had to migrate from 1.4 to 1.8 and,
>     well, things can get complicated. Of course the gap is big and
>     wouldn't be so big between 1.7 and 1.8 or between 1.8 and 1.9, but
>     updating requires time and a reason. If a customer has a working
>     OpenSIPS version and I update it just for the sake of it, new bugs
>     can be introduced, and he'll probably not see any of the new
>     features because he doesn't need them, for example. This is what I
>     mean by not taking it lightly.
>
>     [snip]
>
>     >> What about security fixes? I can understand that when 1.9 is
>     released 1.7 goes to EOL (sort of), but what if there is a bug in
>     the parser (for example) which can cause a crash just by using a
>     stupid script? IMHO there should be a security-fixes-only period,
>     since migrating to a new OpenSIPS version is not  a task to be
>     taken lightly.
>     > [bogdan]
>     > That is true problem that may have as solutions:
>     >    1) simply upgrade (most common way to go in open source
>     world) , considering that upgrades should become easier.
>
>     New versions have new features and new bugs. So updating may get
>     you trouble for little gain, in case you are not using any of the
>     new stuff.
>
>     >    2) try to define what is really critical (based on what??)
>     and still do backporting - but at the end of the day we need to
>     encourage people to use the new versions - keep patching and
>     supporting really old versions (consider 1.6 at this point) is a
>     waist of effort. Taking your example: debian is not supporting
>     something older than 1 release :D....
>     >
>
>     Not 100% accurate: -) "The security team tries to support a stable
>     distribution for about one year after the next stable distribution
>     has been released". So Debian "oldstable" still gets security
>     updates a year after "stable" has been out.
>
>     We can try to see how a similar approach can work out for us.
>     Instead of a year, say 6 months. What's important is to define
>     what a security fix is and what it's not. An error in the software
>     that can be consistently triggered from the outside (ie, with SIP
>     traffic) and cause any kind of outage could be considered a
>     security fix. This is from the top of my head, it would need to be
>     refined :-)
>
>
>     Regards,
>
>     --
>     Sa?l Ibarra Corretg?
>     AG Projects
>
>
>
>
>     _______________________________________________
>     Users mailing list
>     Users at lists.opensips.org <mailto:Users at lists.opensips.org>
>     http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/devel/attachments/20121126/cc61ded1/attachment-0001.htm>

From bogdan at opensips.org  Mon Nov 26 23:18:42 2012
From: bogdan at opensips.org (Bogdan-Andrei Iancu)
Date: Tue, 27 Nov 2012 00:18:42 +0200
Subject: [OpenSIPS-Devel] [OpenSIPS-Users] [RELEASE] OpenSIPS 1.8.2
	Minor Stable Release
In-Reply-To: <CAND0LktQeeKHLBXGBOwT5HW9m7q=7rjVW2Ec5HsV08U88RyxOg@mail.gmail.com>
References: <5092C267.8040303@opensips.org>	<CAND0Lkt4CWN0DH1q+VX1kqLwZCWMNKPvzdwgSsRe3dVmo31dvQ@mail.gmail.com>	<50B3E27B.40307@opensips.org>
	<CAND0LktQeeKHLBXGBOwT5HW9m7q=7rjVW2Ec5HsV08U88RyxOg@mail.gmail.com>
Message-ID: <50B3EAC2.6020703@opensips.org>

Done, see:
     http://www.opensips.org/Resources/Downloads#osipmi

Regards,

Bogdan-Andrei Iancu
OpenSIPS Founder and Developer
http://www.opensips-solutions.com


On 11/26/2012 11:48 PM, Ovidiu Sas wrote:
> Of course :)
>
> -ovidiu
>
> On Mon, Nov 26, 2012 at 4:43 PM, Bogdan-Andrei Iancu
> <bogdan at opensips.org>  wrote:
>> Hi Ovidiu,
>>
>> Is it ok if I list those two links on the official download page ?
>>
>> Regards,
>>
>>
>> Bogdan-Andrei Iancu
>> OpenSIPS Founder and Developer
>> http://www.opensips-solutions.com
>>
>>
>> On 11/26/2012 08:23 PM, Ovidiu Sas wrote:
>>> Hello all,
>>>
>>> For those who like running opensips on routers and/or other small
>>> embedded systems, the latest opensips stable is available for
>>> download.
>>> For more info, please check:
>>> http://www.nslu2-linux.org/wiki/Optware/HomePage
>>> For a list of supported platforms, please check:
>>> http://www.nslu2-linux.org/wiki/Optware/Platforms
>>>
>>> Regards,
>>> Ovidiu Sas
>>>


From noreply at sourceforge.net  Tue Nov 27 12:15:00 2012
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue, 27 Nov 2012 03:15:00 -0800
Subject: [OpenSIPS-Devel] [ opensips-Bugs-3590334 ] timeout_avp not callable
	after loose_route
Message-ID: <mailman.1224.1354014910.13469.devel@lists.opensips.org>

Bugs item #3590334, was opened at 2012-11-27 03:15
Message generated for change (Tracker Item Submitted) made by wdoekes
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=3590334&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.7.x
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Walter Doekes (wdoekes)
Assigned to: Nobody/Anonymous (nobody)
Summary: timeout_avp not callable after loose_route

Initial Comment:
Hi, I noticed that setting the dialog timeout_avp after calling loose_route() is a no-op.

I don't know if that's intentional or not, but it isn't documented (where I'd expect it).

Added a patch (against 1.7) that updates the documentation.

Regards,
Walter Doekes
OSSO B.V.

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

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


From noreply at sourceforge.net  Tue Nov 27 12:20:09 2012
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue, 27 Nov 2012 03:20:09 -0800
Subject: [OpenSIPS-Devel] [ opensips-Bugs-3590336 ] sipmsgops has wrong name
	in module_exports
Message-ID: <mailman.1225.1354015218.13469.devel@lists.opensips.org>

Bugs item #3590336, was opened at 2012-11-27 03:20
Message generated for change (Tracker Item Submitted) made by wdoekes
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=3590336&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.8.x
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Walter Doekes (wdoekes)
Assigned to: Nobody/Anonymous (nobody)
Summary: sipmsgops has wrong name in module_exports

Initial Comment:
Hi,

sipmsgsops says it's "textops".

Attached patch against 1.8.x.

Regards,
Walter Doekes
OSSO B.V.

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

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


From razvan at opensips.org  Tue Nov 27 12:28:25 2012
From: razvan at opensips.org (Razvan Crainea)
Date: Tue, 27 Nov 2012 11:28:25 +0000
Subject: [OpenSIPS-Devel] SF.net SVN: opensips:[9453]
	trunk/modules/sipmsgops/sipmsgops.c
Message-ID: <E1TdJKz-0003XA-QV@sfp-svn-3.v30.ch3.sourceforge.com>

Revision: 9453
          http://opensips.svn.sourceforge.net/opensips/?rev=9453&view=rev
Author:   razvancrainea
Date:     2012-11-27 11:28:25 +0000 (Tue, 27 Nov 2012)
Log Message:
-----------
fixed exported name of the sipmsgops module
Patch provided by Walter Doekes (#3590336)

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

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



From razvan at opensips.org  Tue Nov 27 12:29:37 2012
From: razvan at opensips.org (Razvan Crainea)
Date: Tue, 27 Nov 2012 11:29:37 +0000
Subject: [OpenSIPS-Devel] SF.net SVN: opensips:[9454]
	branches/1.8/modules/sipmsgops/sipmsgops.c
Message-ID: <E1TdJM9-0003ft-LW@sfp-svn-3.v30.ch3.sourceforge.com>

Revision: 9454
          http://opensips.svn.sourceforge.net/opensips/?rev=9454&view=rev
Author:   razvancrainea
Date:     2012-11-27 11:29:37 +0000 (Tue, 27 Nov 2012)
Log Message:
-----------
Backported from trunk (rev #9453):
fixed exported name of the sipmsgops module
Patch provided by Walter Doekes (#3590336)

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

Modified Paths:
--------------
    branches/1.8/modules/sipmsgops/sipmsgops.c

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



From noreply at sourceforge.net  Tue Nov 27 12:30:44 2012
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue, 27 Nov 2012 03:30:44 -0800
Subject: [OpenSIPS-Devel] [ opensips-Bugs-3590336 ] sipmsgops has wrong name
	in module_exports
Message-ID: <mailman.1226.1354015853.13469.devel@lists.opensips.org>

Bugs item #3590336, was opened at 2012-11-27 03:20
Message generated for change (Comment added) made by razvancrainea
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=3590336&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.8.x
>Status: Closed
Resolution: None
Priority: 5
Private: No
Submitted By: Walter Doekes (wdoekes)
Assigned to: Nobody/Anonymous (nobody)
Summary: sipmsgops has wrong name in module_exports

Initial Comment:
Hi,

sipmsgsops says it's "textops".

Attached patch against 1.8.x.

Regards,
Walter Doekes
OSSO B.V.

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

>Comment By: Razvan Crainea (razvancrainea)
Date: 2012-11-27 03:30

Message:
Hi, Walter!

I've applied the patch on both trunk and 1.8.

Thank you,
R?zvan

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

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


From noreply at sourceforge.net  Tue Nov 27 15:22:07 2012
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue, 27 Nov 2012 06:22:07 -0800
Subject: [OpenSIPS-Devel] [ opensips-Bugs-3590367 ] DISPATCHER. Commit #9448
	breaks dispatcher pings
Message-ID: <mailman.1227.1354026131.13469.devel@lists.opensips.org>

Bugs item #3590367, was opened at 2012-11-27 06:22
Message generated for change (Tracker Item Submitted) made by nikbyte
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=3590367&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: Nick Altmann (nikbyte)
Assigned to: Nobody/Anonymous (nobody)
Summary: DISPATCHER. Commit #9448 breaks dispatcher pings

Initial Comment:
After this commit dispatcher pings are going from incorrect interface on multihomed opensips.


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

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


From noreply at sourceforge.net  Tue Nov 27 18:05:20 2012
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue, 27 Nov 2012 09:05:20 -0800
Subject: [OpenSIPS-Devel] [ opensips-Bugs-3590401 ] B2B_LOGIC: not correct
	DB save/restore
Message-ID: <mailman.1228.1354035926.13469.devel@lists.opensips.org>

Bugs item #3590401, was opened at 2012-11-27 09:05
Message generated for change (Tracker Item Submitted) made by nikbyte
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=3590401&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: Nick Altmann (nikbyte)
Assigned to: Nobody/Anonymous (nobody)
Summary: B2B_LOGIC: not correct DB save/restore

Initial Comment:
How to reproduce:
1. I setup call (two tuples here).
2. opensipsctl fifo b2b_list >1.log
3. /etc/init.d/opensips restart
4. opensipsctl fifo b2b_list >2.log

When I do diff on these two logs, I see:

--- 1.log	2012-11-27 20:59:30.473122546 +0400
+++ 2.log	2012-11-27 20:59:25.201118940 +0400
@@ -1,26 +1,26 @@
-tuple:: 0 key=2876.0 scenario_state=18446744073709551613 lifetime=86418 db_flag=2
-	servers:: 0 key=b2b.5483.13303 disconnected=0 state=1 no=0 type=0 peer=b2b.2876.2925404
+tuple:: 0 key=2876.0 scenario_state=18446744073709551613 lifetime=86396 db_flag=1
+	servers:: 0 key=b2b.5483.13303 disconnected=0 state=0 no=0 type=0 peer=b2b.2876.2925404
 		to_uri:: sip:71112233445 at domain1.com
 		from_uri:: sip:phone at domain1.com
-	clients:: 0 key=b2b.2876.2925404 disconnected=0 state=1 no=1 type=1 peer=b2b.5483.13303
+	clients:: 0 key=b2b.2876.2925404 disconnected=0 state=0 no=0 type=1 peer=b2b.5483.13303
 		to_uri:: sip:71112233445 at domain1.com
 		from_uri:: sip:phone at domain1.com
-	bridge_entities:: 0 key=b2b.5483.13303 disconnected=0 state=1 no=0 type=0 peer=b2b.2876.2925404
+	bridge_entities:: 0 key=b2b.5483.13303 disconnected=0 state=0 no=0 type=0 peer=b2b.2876.2925404
 		to_uri:: sip:71112233445 at domain1.com
 		from_uri:: sip:phone at domain1.com
-	bridge_entities:: 1 key=b2b.2876.2925404 disconnected=0 state=1 no=1 type=1 peer=b2b.5483.13303
+	bridge_entities:: 1 key=b2b.2876.2925404 disconnected=0 state=0 no=0 type=1 peer=b2b.5483.13303
 		to_uri:: sip:71112233445 at domain1.com
 		from_uri:: sip:phone at domain1.com
-tuple:: 0 key=6514.0 scenario_state=18446744073709551613 lifetime=86418 db_flag=2
-	servers:: 0 key=b2b.13737.6611 disconnected=0 state=1 no=0 type=0 peer=b2b.6514.2038652
+tuple:: 0 key=6514.0 scenario_state=18446744073709551613 lifetime=86396 db_flag=1
+	servers:: 0 key=b2b.13737.6611 disconnected=0 state=0 no=0 type=0 peer=b2b.6514.2038652
 		to_uri:: sip:71112233445 at 8.8.8.8:5060
 		from_uri:: sip:phone at domain1.com
-	clients:: 0 key=b2b.6514.2038652 disconnected=0 state=1 no=1 type=1 peer=b2b.13737.6611
+	clients:: 0 key=b2b.6514.2038652 disconnected=0 state=0 no=0 type=1 peer=b2b.13737.6611
 		to_uri:: sip:71112233445 at 8.8.8.8:5060
 		from_uri:: sip:phone at domain1.com
-	bridge_entities:: 0 key=b2b.13737.6611 disconnected=0 state=1 no=0 type=0 peer=b2b.6514.2038652
+	bridge_entities:: 0 key=b2b.13737.6611 disconnected=0 state=0 no=0 type=0 peer=b2b.6514.2038652
 		to_uri:: sip:71112233445 at 8.8.8.8:5060
 		from_uri:: sip:phone at domain1.com
-	bridge_entities:: 1 key=b2b.6514.2038652 disconnected=0 state=1 no=1 type=1 peer=b2b.13737.6611
+	bridge_entities:: 1 key=b2b.6514.2038652 disconnected=0 state=0 no=0 type=1 peer=b2b.13737.6611
 		to_uri:: sip:71112233445 at 8.8.8.8:5060
 		from_uri:: sip:phone at domain1.com

So, in-memory structures are differ. 
state and are not correctly restored.

Logs attached.


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

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


From noreply at sourceforge.net  Tue Nov 27 18:59:20 2012
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue, 27 Nov 2012 09:59:20 -0800
Subject: [OpenSIPS-Devel] [ opensips-Bugs-3590411 ] HTTP_MI memory leak
Message-ID: <mailman.1229.1354039164.13469.devel@lists.opensips.org>

Bugs item #3590411, was opened at 2012-11-27 09:59
Message generated for change (Tracker Item Submitted) made by digipigeon
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=3590411&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.8.x
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Digipigeon (digipigeon)
Assigned to: Nobody/Anonymous (nobody)
Summary: HTTP_MI memory leak

Initial Comment:
There appears to be a memory leak in the http_mi module, Opensips 1.8.2.

When package memory is set to 4MB the memory leak becomes apparent after a few hours.

When the package memory is set to 64MB after a few days.

The HTTP Requests begin to fail with Error 500 and the log shows "ERROR:core:init_mi_tree: no more pkg mem".

This has only started to happen after switching from xmlrpc to mi_http.

Regards Jonathan

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

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


From noreply at sourceforge.net  Tue Nov 27 19:16:14 2012
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue, 27 Nov 2012 10:16:14 -0800
Subject: [OpenSIPS-Devel] [ opensips-Bugs-3590411 ] HTTP_MI memory leak
Message-ID: <mailman.1230.1354040183.13469.devel@lists.opensips.org>

Bugs item #3590411, was opened at 2012-11-27 09:59
Message generated for change (Comment added) made by osas
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=3590411&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.8.x
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Digipigeon (digipigeon)
Assigned to: Nobody/Anonymous (nobody)
Summary: HTTP_MI memory leak

Initial Comment:
There appears to be a memory leak in the http_mi module, Opensips 1.8.2.

When package memory is set to 4MB the memory leak becomes apparent after a few hours.

When the package memory is set to 64MB after a few days.

The HTTP Requests begin to fail with Error 500 and the log shows "ERROR:core:init_mi_tree: no more pkg mem".

This has only started to happen after switching from xmlrpc to mi_http.

Regards Jonathan

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

Comment By: Ovidiu Sas (osas)
Date: 2012-11-27 10:16

Message:
Hello Jonathan,

Do you run a particular set of commands?
Can you post the HTTP requests that you are using?
How many HTTP requests do you run per minute?

Thanks,
Ovidiu

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

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


From noreply at sourceforge.net  Tue Nov 27 19:57:45 2012
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue, 27 Nov 2012 10:57:45 -0800
Subject: [OpenSIPS-Devel] [ opensips-Bugs-3590418 ] MI DATAGRAM specific
	commands fail
Message-ID: <mailman.1231.1354042669.13469.devel@lists.opensips.org>

Bugs item #3590418, was opened at 2012-11-27 10:57
Message generated for change (Tracker Item Submitted) made by digipigeon
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=3590418&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.8.x
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Digipigeon (digipigeon)
Assigned to: Nobody/Anonymous (nobody)
Summary: MI DATAGRAM specific commands fail

Initial Comment:
Using 1.8.2, applying a different connector to my existing mi methods the following commands that I have issued work over ALL XMLRPC, FIFO, MI_HTTP & MI_DATAGRAM

version - WORKS ALL
uptime - WORKS ALL

However the following commands work on XMLRPC, FIFO, MI_HTTP but FAIL on MI_DATAGRAM 

All Passed with no arguments

dr_gw_status - FAILS ON MI_DATAGRAM
debug - FAILS ON MI_DATAGRAM

Regards Jonathan

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

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


From osas at voipembedded.com  Tue Nov 27 21:47:12 2012
From: osas at voipembedded.com (Ovidiu Sas)
Date: Tue, 27 Nov 2012 20:47:12 +0000
Subject: [OpenSIPS-Devel] SF.net SVN: opensips:[9455]
	trunk/modules/mi_http/http_fnc.c
Message-ID: <E1TdS3k-0003T6-St@sfp-svn-4.v30.ch3.sourceforge.com>

Revision: 9455
          http://opensips.svn.sourceforge.net/opensips/?rev=9455&view=rev
Author:   osas
Date:     2012-11-27 20:47:12 +0000 (Tue, 27 Nov 2012)
Log Message:
-----------
mi_http: fix a few memory leaks
 - related to bug  #3590411

Modified Paths:
--------------
    trunk/modules/mi_http/http_fnc.c

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



From noreply at sourceforge.net  Tue Nov 27 21:48:13 2012
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue, 27 Nov 2012 12:48:13 -0800
Subject: [OpenSIPS-Devel] [ opensips-Bugs-3590411 ] HTTP_MI memory leak
Message-ID: <mailman.1232.1354049302.13469.devel@lists.opensips.org>

Bugs item #3590411, was opened at 2012-11-27 09:59
Message generated for change (Comment added) made by osas
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=3590411&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.8.x
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Digipigeon (digipigeon)
Assigned to: Nobody/Anonymous (nobody)
Summary: HTTP_MI memory leak

Initial Comment:
There appears to be a memory leak in the http_mi module, Opensips 1.8.2.

When package memory is set to 4MB the memory leak becomes apparent after a few hours.

When the package memory is set to 64MB after a few days.

The HTTP Requests begin to fail with Error 500 and the log shows "ERROR:core:init_mi_tree: no more pkg mem".

This has only started to happen after switching from xmlrpc to mi_http.

Regards Jonathan

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

Comment By: Ovidiu Sas (osas)
Date: 2012-11-27 12:48

Message:
Hello Jonathan,

I committed a fix in trunk.
Can you test it and let me know the results?

Thanks,
Ovidiu

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

Comment By: Ovidiu Sas (osas)
Date: 2012-11-27 10:16

Message:
Hello Jonathan,

Do you run a particular set of commands?
Can you post the HTTP requests that you are using?
How many HTTP requests do you run per minute?

Thanks,
Ovidiu

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

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


From noreply at sourceforge.net  Wed Nov 28 11:58:04 2012
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed, 28 Nov 2012 02:58:04 -0800
Subject: [OpenSIPS-Devel] [ opensips-Bugs-3590655 ] Random Crash
Message-ID: <mailman.1233.1354100294.13469.devel@lists.opensips.org>

Bugs item #3590655, was opened at 2012-11-28 02:58
Message generated for change (Tracker Item Submitted) made by nanotiva
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=3590655&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.8.x
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: bruceborrett (nanotiva)
Assigned to: Nobody/Anonymous (nobody)
Summary: Random Crash

Initial Comment:
We experienced a seemingly random crash on our server which has been running for months without a single issue.

The following kernel error was logged:
kernel: [8988656.469074] opensips[18871]: segfault at 0 ip 000000000048c0d9 sp 00007fffd71a92c0 error 6 in opensips[400000+11c000]

Here is the full backtrace:
#0  0x000000000048c0d9 in fm_remove_free (n=<optimized out>, qm=<optimized out>) at mem/f_malloc.c:172
        pf = 0x0
        hash = 1
#1  fm_malloc (qm=0x7f412fdd2000, size=8) at mem/f_malloc.c:378
        frag = 0x7f41302c3300
        n = <optimized out>
        hash = <optimized out>
        __FUNCTION__ = "fm_malloc"
#2  0x00007f4134e9f41c in shm_malloc (size=<optimized out>) at ../../evi/../mem/shm_mem.h:202
        p = <optimized out>
#3  dlg_add_leg_info (dlg=0x7f41302f49d0, tag=0x7f4138515c98, rr=<optimized out>, contact=<optimized out>, cseq=0x7fffd71a9450, sock=<optimized out>,
    mangled_from=0x0, mangled_to=0x0) at dlg_hash.c:343
        leg = 0x7f41300b4c68
        head = 0x0
        rrp = <optimized out>
        __FUNCTION__ = "dlg_add_leg_info"
#4  0x00007f4134e9a8e6 in init_leg_info (dlg=0x7f41302f49d0, msg=0x7f4138504718, t=<optimized out>, tag=<optimized out>, mangled_from=<optimized out>,
    mangled_to=0x0) at dlg_handlers.c:243
        skip_recs = 0
        cseq = {
          s = 0x741f7f "2 INVITE\r\nExpires: 180\r\nFrom: <sip:3226 at 41.73.53.1>;tag=c0a8010a-ba80\r\nMax-Forwards: 69\r\nProxy-Authorization: Digest realm=\"41.73.53.1\", nonce=\"50b4902500005e9c4ceb3b7d9055f4453382581e2965bb0b\", usern"..., len = 1}
        contact = {s = 0x7f4138507c70 "sip:3226 at 196.25.214.82:5060", len = 27}
        rr_set = {s = 0x0, len = 0}
        __FUNCTION__ = "init_leg_info"
#5  0x00007f4134e9b13e in dlg_create_dialog (t=0x0, req=0x7f4138504718, flags=0) at dlg_handlers.c:887
        dlg = <optimized out>
        s = {
          s = 0x741ef3 "call-F113832A-B71A-3010-101F-4232 at 192.168.1.10\r\nContact: <sip:3226 at 192.168.1.10>\r\nContent-Length: 298\r\nContent-Type: application/sdp\r\nCSeq: 2 INVITE\r\nExpires: 180\r\nFrom: <sip:3226 at 41.73.53.1>;tag=c0a8"..., len = 46}
        __FUNCTION__ = "dlg_create_dialog"
#6  0x00007f4134e88306 in w_create_dialog (req=0x7f4138504718) at dialog.c:832
        t = <optimized out>
#7  0x0000000000413bf5 in do_action (a=0x7f41384908e8, msg=0x7f4138504718) at action.c:1483
        val_s = {s = 0x4 <Address 0x4 out of bounds>, len = 7610407}
        increment = <optimized out>
        decrement = <optimized out>
        aux = {s = 0x7f4138504718 "\r\214\002", len = 7610407}
        adv_addr = {s = 0x7423b5 "", len = 4780225}
        ret = <optimized out>
        v = <optimized out>
        to = <optimized out>
        p = <optimized out>
        tmp = <optimized out>
        new_uri = <optimized out>
        end = <optimized out>
        crt = <optimized out>
        len = <optimized out>
        i = <optimized out>
        user = <optimized out>
        expires = <optimized out>
        vals = {{
            s = 0x74223e "39f1e0281836c06018033323236700581303131391301000f0b413032312d303133383633\r\n\r\nv=0\r\no=Quintum 5362 5362 IN IP4 192.168.1.10\r\ns=VoipCall\r\nc=IN IP4 192.168.1.10\r\nt=0 0\r\nm=audio 10412 RTP/AVP 18 8 101 13\r\n"..., len = 7610112}, {s = 0x7fffd71a9a00 "\265#t", len = -1}, {
            s = 0x7f4138512c98  <incomplete sequence \350>, len = 944855384}, {
            s = 0x742164 "branch=z9hG4bK-tenor-c0a8-010a-23383\r\nQuintum: 0c01030b053235353330050100075b1b01010000211b3600040a8090809", '0' <repeats 11 times>, "8300180c818080810000800380000000001e03808183006c08808180803332323600700680813031313"..., len = 7610247}, {s = 0x7423b5 "", len = 4797239}}
        result = {s = 0x2 <Address 0x2 out of bounds>, len = 7610694}
        uri = {user = {s = 0x0, len = 816207616}, passwd = {s = 0x7f4135f1fb48 "acc", len = 3}, host = {s = 0x38506f3e <Address 0x38506f3e out of bounds>,
            len = 2}, port = {s = 0xe <Address 0xe out of bounds>, len = 944785176}, params = {s = 0x7f41301fe1a8 "\002", len = 128}, headers = {
            s = 0x71d5a8 "\b\244\335/A\177", len = 816205752}, port_no = 30936, proto = 12429, type = 32577, transport = {
            s = 0x7f4136fb198a "\351\274\375\377\377\220H\213\005Y\372!", len = -686122836}, ttl = {s = 0x3 <Address 0x3 out of bounds>, len = -686122836},
          user_param = {s = 0x7f4138488c60 "H\201N8A\177", len = -686122912}, maddr = {s = 0x7fffd71a9898 "\254\004C", len = 814577880}, method = {
            s = 0x751ee0 "\270\255\n0A\177", len = 816205752}, lr = {s = 0x7f4138504718 "\r\214\002", len = 200}, r2 = {s = 0x7f41301fe1b8 "",
            len = -686122528}, gr = {s = 0x7f41308d79f0 "\001", len = 944278552}, transport_val = {s = 0x4304ac "H\205\300\017\205X\377\377\377H\213=LH3",
            len = 944785176}, ttl_val = {s = 0x7f41308d78d8 "", len = 814584496}, user_param_val = {s = 0x400 <Address 0x400 out of bounds>, len = 1},
          maddr_val = {s = 0x0, len = 944859768}, method_val = {s = 0x7f4136fb1a90 "L\213\253", <incomplete sequence \360>, len = 814578008}, lr_val = {
            s = 0x33c <Address 0x33c out of bounds>, len = 944859768}, r2_val = {s = 0x7f41308d79f8 "\002", len = 1}, gr_val = {
            s = 0x7fffd71a9918 "\215\326\372\066A\177", len = 944859768}, u_name = {{s = 0x7f4136fad68d "\203\370\377\211\303\017\204P\001", len = 806659848},
            {s = 0x0, len = 814577880}, {s = 0x7f4138504718 "\r\214\002", len = 0}, {s = 0x7f4130882238 "", len = 46717}, {
              s = 0x1 <Address 0x1 out of bounds>, len = 7610463}}, u_val = {{s = 0x7f413850caa0 "\001", len = 7610386}, {
              s = 0x742164 "branch=z9hG4bK-tenor-c0a8-010a-23383\r\nQuintum: 0c01030b053235353330050100075b1b01010000211b3600040a8090809", '0' <repeats 11 times>, "8300180c818080810000800380000000001e03808183006c08808180803332323600700680813031313"..., len = 944818848}, {
              s = 0x4ae3ad "H\205\300H\211D$PD\017\266T$8L\213\\$@\017\204\340\036", len = 29}, {
              s = 0x49ff62 "H\205\300I\211\306L\213T$ D\213\\$(\017\204M\a", len = -686122244}, {s = 0x7f4138504f38 "\220\001", len = 0}}, u_params_no = 22872}
        next_hop = {user = {s = 0x4c4b40 "\211\350A\207\004$\205\300t\036\205\333~\n\203\353\001\353\355\017\037D", len = 376}, passwd = {
            s = 0x71d5a8 "\b\244\335/A\177", len = 944781648}, host = {
            s = 0x7525e0 "insert into dialog (hash_entry,hash_id,callid,from_uri,from_tag,to_uri,to_tag,caller_sock,callee_sock,start_time,mangled_from_uri,mangled_to_uri,state,timeout,caller_cseq,callee_cseq,caller_ping_cseq,"..., len = 942047158}, port = {s = 0x0, len = 25}, params = {s = 0x7fffd71a96b0 "\017",
            len = -686123344}, headers = {s = 0x7f41384e91b0 "\004", len = 816205752}, port_no = 7, proto = 0, type = ERROR_URI_T, transport = {
            s = 0x7f4138504717 "", len = 0}, ttl = {s = 0x7f413850a0e8 "", len = 944781648}, user_param = {s = 0x0, len = 889960096}, maddr = {
            s = 0x7f41385098e8 "\350\240P8A\177", len = 944806184}, method = {s = 0x7fffd71a9680 "\006\220\264P", len = 7}, lr = {
            s = 0x7fffd71a9690 "\030GP8A\177", len = 816205752}, r2 = {s = 0x7f4135f19641 "\205\300t\232H\213\005dq ", len = 1354010630}, gr = {
            s = 0x92a88 <Address 0x92a88 out of bounds>, len = 1354010630}, transport_val = {s = 0x8dd1c <Address 0x8dd1c out of bounds>, len = 944785176},
          ttl_val = {s = 0x0, len = 0}, user_param_val = {s = 0x7f4138503950 "\360C\024\066A\177", len = 15}, maddr_val = {s = 0x7f4136142040 "\004",
            len = 907287904}, method_val = {s = 0x7f4136144300 "", len = 907297472}, lr_val = {s = 0x7f4138269a37 "H\307C\b", len = 907288640}, r2_val = {
            s = 0x7f4136141220 "\300\036t", len = 907288640}, gr_val = {s = 0xf <Address 0xf out of bounds>, len = 816205752}, u_name = {{
              s = 0x7f4135f143b4 "\205\300\017\211\361\376\377\377H\213\005\355\303 ", len = 809199768}, {s = 0xe <Address 0xe out of bounds>,
              len = 944785176}, {s = 0x7fffd71a97f0 "\250\341\037\060A\177", len = 7610111}, {s = 0x7f4130a64fb8 "\267\213\002", len = 907297728}, {
              s = 0x7f41308d78d8 "", len = 944785176}}, u_val = {{s = 0x7f4136120be0 "H\373\361\065A\177", len = 200}, {
              s = 0x7f4135f1b9e2 "\351\270\372\377\377f\017\037\204", len = 807924736}, {s = 0x7f41358fa610 "\017\234o5A\177", len = 39}, {
              s = 0x7f4134e9d19a "H\215H\377H\211\302\061\300H\203\371\375w\323H\213\202\030\032", len = 0}, {
              s = 0x7f41356f38fd "H\205\300H\211\305\017\204\257", len = 39}}, u_params_no = 0}
        u = <optimized out>
        port = <optimized out>
        cmatch = <optimized out>
        aitem = <optimized out>
        adefault = <optimized out>
        spec = <optimized out>
        model = <optimized out>
        val = {rs = {
            s = 0x742029 "55f4453382581e2965bb0b\", username=\"federalmogul\", uri=\"sip:0119810000 at 41.73.53.1\", response=\"626090ba2fd3b2d919f697c330e26f37\"\r\nSession-GUID: 892363316-1633957986-875705136-4\r\nSupported: 100rel\r\nTo: <"..., len = 7610699}, ri = 944795136, flags = 32577}
        pve = <optimized out>
        name_s = {s = 0x7f4138504718 "\r\214\002", len = 7610694}
        start = {tv_sec = 1354010631, tv_usec = 934753}
        end_time = <optimized out>
        __FUNCTION__ = "do_action"
#8  0x00000000004122ab in run_action_list (a=<optimized out>, msg=0x7f4138504718) at action.c:143
        ret = 1
        t = 0x7f41384908e8
        __FUNCTION__ = "run_action_list"
#9  0x0000000000417a30 in run_actions (msg=<optimized out>, a=<optimized out>) at action.c:123
No locals.
#10 run_top_route (a=0x7f413848f098, msg=0x7f4138504718) at action.c:189
        bl_last_msg_id = 166925
        bk_action_flags = 0
        bk_rec_lev = 0
#11 0x000000000044c5c7 in receive_msg (
    buf=0x741ec0 "INVITE sip:0119810000 at 41.73.53.1 SIP/2.0\r\nCall-ID: call-F113832A-B71A-3010-101F-4232 at 192.168.1.10\r\nContact: <sip:3226 at 192.168.1.10>\r\nContent-Length: 298\r\nContent-Type: application/sdp\r\nCSeq: 2 INVITE\r"..., len=1269, rcv_info=0x7fffd71a9c90) at receive.c:165
        msg = 0x7f4138504718
        start = {tv_sec = 1354010631, tv_usec = 934360}
        __FUNCTION__ = "receive_msg"
#12 0x0000000000487083 in udp_rcv_loop () at udp_server.c:424
        len = 1269
        buf = "INVITE sip:0119810000 at 41.73.53.1 SIP/2.0\r\nCall-ID: call-F113832A-B71A-3010-101F-4232 at 192.168.1.10\r\nContact: <sip:3226 at 192.168.1.10>\r\nContent-Length: 298\r\nContent-Type: application/sdp\r\nCSeq: 2 INVITE\r"...
        tmp = <optimized out>
        from = <optimized out>
        fromlen = 16
        ri = {src_ip = {af = 2, len = 4, u = {addrl = {1389763012, 140736802233736}, addr32 = {1389763012, 0, 3608845704, 32767}, addr16 = {6596, 21206, 0, 0,
                40328, 55066, 32767, 0}, addr = "\304\031\326R\000\000\000\000\210\235\032\327\377\177\000"}}, dst_ip = {af = 2, len = 4, u = {addrl = {
                20269353, 0}, addr32 = {20269353, 0, 0, 0}, addr16 = {18729, 309, 0, 0, 0, 0, 0, 0}, addr = ")I5\001", '\000' <repeats 11 times>}},
          src_port = 5060, dst_port = 5060, proto = 1, proto_reserved1 = 0, proto_reserved2 = 0, src_su = {s = {sa_family = 2,
              sa_data = "\023\304\304\031\326R\000\000\000\000\000\000\000"}, sin = {sin_family = 2, sin_port = 50195, sin_addr = {s_addr = 1389763012},
              sin_zero = "\000\000\000\000\000\000\000"}, sin6 = {sin6_family = 2, sin6_port = 50195, sin6_flowinfo = 1389763012, sin6_addr = {__in6_u = {
                  __u6_addr8 = '\000' <repeats 15 times>, __u6_addr16 = {0, 0, 0, 0, 0, 0, 0, 0}, __u6_addr32 = {0, 0, 0, 0}}}, sin6_scope_id = 0}},
          bind_address = 0x7f4138488c18}
        p = 0x4f5
        msg = {
          s = 0x741ec0 "INVITE sip:0119810000 at 41.73.53.1 SIP/2.0\r\nCall-ID: call-F113832A-B71A-3010-101F-4232 at 192.168.1.10\r\nContact: <sip:3226 at 192.168.1.10>\r\nContent-Length: 298\r\nContent-Type: application/sdp\r\nCSeq: 2 INVITE\r"..., len = 1269}
        __FUNCTION__ = "udp_rcv_loop"
#13 0x0000000000429a46 in main_loop () at main.c:876
        i = 3
        pid = <optimized out>
        si = 0x7f4138488c18
        startup_done = 0x0
        chd_rank = 4
        load_p = 0x7f41303d4370
#14 main (argc=<optimized out>, argv=<optimized out>) at main.c:1520
        cfg_log_stderr = <optimized out>
        cfg_stream = <optimized out>
        c = <optimized out>
        r = <optimized out>
        tmp = 0x7fffd71aaf16 ""
        tmp_len = <optimized out>
        port = <optimized out>
        proto = <optimized out>
        ret = <optimized out>
        seed = 2837169747
        rfd = <optimized out>
        __FUNCTION__ = "main"

Version info:

version: opensips 1.8.0-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: 2:9212M
@(#) $Id: main.c 8772 2012-03-08 11:16:13Z bogdan_iancu $
main.c compiled on 07:29:16 Aug 15 2012 with gcc 4.4.5


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

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


From noreply at sourceforge.net  Wed Nov 28 13:18:15 2012
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed, 28 Nov 2012 04:18:15 -0800
Subject: [OpenSIPS-Devel] [ opensips-Bugs-3586775 ] Dialog Ping
Message-ID: <mailman.1234.1354105104.13469.devel@lists.opensips.org>

Bugs item #3586775, was opened at 2012-11-13 11:03
Message generated for change (Comment added) made by kaduww
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=3586775&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.8.x
Status: Open
Resolution: Fixed
Priority: 5
Private: No
Submitted By: Carlos Eduardo Wagner (kaduww)
Assigned to: Vladut-Stefan Paiu (vladut-paiu)
Summary: Dialog Ping

Initial Comment:
I'm having some problems with the Dialog Ping when using another port different from the 5060.
My opensips is listening on both ports, 5060 and 5062 and, as the trace attached, when the client is sending requests to the port 5062 and the dialog is created, the Dialog Ping sends the OPTIONS packet from the port 5060. Because of this, my client's NAT is blocking the packet, because its mapped to the port 5062 and not the 5060.

Follow the dialog information:
root at sipstage:/home/suporte# opensipsctl fifo dlg_list
dialog::  hash=2536:1633827324
	state:: 4
	user_flags:: 0
	timestart:: 1352831188
	timeout:: 1352838388
	callid:: a4e155f4320d43b9be48fde6457150ee
	from_uri:: sip:P0000000001 at sipstage.pligg.com.br
	to_uri:: sip:05130227701 at sipstage.pligg.com.br
	caller_tag:: 6fe6c313c92742a392fd75740f8867d7
	caller_contact:: sip:P0000000001 at 177.97.125.92:4057;ob
	callee_cseq:: 0
	caller_route_set:: 
	caller_bind_addr:: udp:177.129.74.30:5062
	callee_tag:: a94c095b773be1dd6e8d668a785a9c8470442779
	callee_contact:: sip:05130227701 at 201.56.167.2:5060
	caller_cseq:: 31678
	callee_route_set:: <sip:201.33.209.42;lr;did=8e96.0e1aebe1>,<sip:201.33.209.194;lr=on;did=8e9.c48a6f3>
	callee_bind_addr:: udp:177.129.74.30:5062

Here follows the OPTIONS part of the Trace:
U 2012/11/13 16:28:59.522813 177.129.74.30:5060 -> 177.97.125.92:4050
OPTIONS sip:P0000000025 at 177.97.125.92:4050;ob SIP/2.0.
Via: SIP/2.0/UDP 177.129.74.30:5062;branch=z9hG4bKf915.ddfebd02.0.
To: <sip:P0000000025 at sipstage.pligg.com.br>;tag=6caf1d8cdc4645719b25a6e120c90679.
From: <sip:05130227701 at sipstage.pligg.com.br>;tag=a94c095b773be1dd6e8d668a785a9c849cb5c894.
CSeq: 1 OPTIONS.
Call-ID: 433b8548a3944c2ea03a4a9cf2ce0bc4.
Max-Forwards: 70.
Content-Length: 0.
User-Agent: OpenSIPS (1.8.2-notls (x86_64/linux)).

* The SIP Trace attached was made while using the Opensips 1.8.1, but I did the test with the newest 1.8.x version e the problem was the same.

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

>Comment By: Carlos Eduardo Wagner (kaduww)
Date: 2012-11-28 04:18

Message:
Vlad,

Thank's for your quick answer. I tried as you ask and, now, the Dialog Ping
worked fine, the source was 5062, just like it was supposed to be.

Best Regards,
Carlos

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

Comment By: Vladut-Stefan Paiu (vladut-paiu)
Date: 2012-11-22 10:19

Message:
Hello,

I have committed a fix for this in the 1.8 branch and trunk.
Could you please update your sources and try again ?

Best Regards,
Vlad

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

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


From noreply at sourceforge.net  Wed Nov 28 13:22:47 2012
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed, 28 Nov 2012 04:22:47 -0800
Subject: [OpenSIPS-Devel] [ opensips-Bugs-3586775 ] Dialog Ping
Message-ID: <mailman.1235.1354105374.13469.devel@lists.opensips.org>

Bugs item #3586775, was opened at 2012-11-13 11:03
Message generated for change (Comment added) made by vladut-paiu
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=3586775&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.8.x
>Status: Closed
Resolution: Fixed
Priority: 5
Private: No
Submitted By: Carlos Eduardo Wagner (kaduww)
Assigned to: Vladut-Stefan Paiu (vladut-paiu)
Summary: Dialog Ping

Initial Comment:
I'm having some problems with the Dialog Ping when using another port different from the 5060.
My opensips is listening on both ports, 5060 and 5062 and, as the trace attached, when the client is sending requests to the port 5062 and the dialog is created, the Dialog Ping sends the OPTIONS packet from the port 5060. Because of this, my client's NAT is blocking the packet, because its mapped to the port 5062 and not the 5060.

Follow the dialog information:
root at sipstage:/home/suporte# opensipsctl fifo dlg_list
dialog::  hash=2536:1633827324
	state:: 4
	user_flags:: 0
	timestart:: 1352831188
	timeout:: 1352838388
	callid:: a4e155f4320d43b9be48fde6457150ee
	from_uri:: sip:P0000000001 at sipstage.pligg.com.br
	to_uri:: sip:05130227701 at sipstage.pligg.com.br
	caller_tag:: 6fe6c313c92742a392fd75740f8867d7
	caller_contact:: sip:P0000000001 at 177.97.125.92:4057;ob
	callee_cseq:: 0
	caller_route_set:: 
	caller_bind_addr:: udp:177.129.74.30:5062
	callee_tag:: a94c095b773be1dd6e8d668a785a9c8470442779
	callee_contact:: sip:05130227701 at 201.56.167.2:5060
	caller_cseq:: 31678
	callee_route_set:: <sip:201.33.209.42;lr;did=8e96.0e1aebe1>,<sip:201.33.209.194;lr=on;did=8e9.c48a6f3>
	callee_bind_addr:: udp:177.129.74.30:5062

Here follows the OPTIONS part of the Trace:
U 2012/11/13 16:28:59.522813 177.129.74.30:5060 -> 177.97.125.92:4050
OPTIONS sip:P0000000025 at 177.97.125.92:4050;ob SIP/2.0.
Via: SIP/2.0/UDP 177.129.74.30:5062;branch=z9hG4bKf915.ddfebd02.0.
To: <sip:P0000000025 at sipstage.pligg.com.br>;tag=6caf1d8cdc4645719b25a6e120c90679.
From: <sip:05130227701 at sipstage.pligg.com.br>;tag=a94c095b773be1dd6e8d668a785a9c849cb5c894.
CSeq: 1 OPTIONS.
Call-ID: 433b8548a3944c2ea03a4a9cf2ce0bc4.
Max-Forwards: 70.
Content-Length: 0.
User-Agent: OpenSIPS (1.8.2-notls (x86_64/linux)).

* The SIP Trace attached was made while using the Opensips 1.8.1, but I did the test with the newest 1.8.x version e the problem was the same.

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

>Comment By: Vladut-Stefan Paiu (vladut-paiu)
Date: 2012-11-28 04:22

Message:
Hi Carlos,

Ok, glad that it's fixed. Closing.

Best Regards,
Vlad

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

Comment By: Carlos Eduardo Wagner (kaduww)
Date: 2012-11-28 04:18

Message:
Vlad,

Thank's for your quick answer. I tried as you ask and, now, the Dialog Ping
worked fine, the source was 5062, just like it was supposed to be.

Best Regards,
Carlos

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

Comment By: Vladut-Stefan Paiu (vladut-paiu)
Date: 2012-11-22 10:19

Message:
Hello,

I have committed a fix for this in the 1.8 branch and trunk.
Could you please update your sources and try again ?

Best Regards,
Vlad

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

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


From noreply at sourceforge.net  Wed Nov 28 13:30:08 2012
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed, 28 Nov 2012 04:30:08 -0800
Subject: [OpenSIPS-Devel] [ opensips-Bugs-3590667 ] ACC not logging BYE on
	random calls
Message-ID: <mailman.1236.1354105811.13469.devel@lists.opensips.org>

Bugs item #3590667, was opened at 2012-11-28 04:30
Message generated for change (Tracker Item Submitted) made by 
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=3590667&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.8.x
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Daniel ()
Assigned to: Nobody/Anonymous (nobody)
Summary: ACC not logging BYE on random calls

Initial Comment:
Hi

I built a billing system using Opensips. The logic was to log on a mysql table "acc" all INVITEs and BYEs to be removed later. Then within a few seconds, a console would search for BYEs and related INVITES, calculate duration and price, write on the final table and erase those 2 records from this table.
After some time running, I checked that randomly calls, ACC wrote to DB just the INVITEs and not the BYEs. Checked on syslog and happened the same. I got this:

sbin/opensips[2024]: ACC: transaction answered: timestamp=1353582441;method=INVITE;from_tag=as6c53d5bd;to_tag=1c431879610;call_id=c1434b259b666c921e0c67752f09c01 at 2.2.2.2:5060;code=200;reason=OK

But not the "BYE" message.

This seems to be a bug on ACC module because it doesn?t write the data to Mysql neither to syslog, and also doesn't generate any error on syslog.

To make sure that my problem was on the module and not in my logic, I removed almost all functionality of my Opensips and let just the call routing and ACC module... It reduced the problem but still happens on some situations, from 0.5% to 5% of all calls, randomly.

To temporary solve my problem, i forced INSERT on DB using avp_db_query on loose_route function. On 95% calls it generate a duplicated BYE on my table but my algorithm discard these additional BYEs, so it?s fine for now.

I believe this is an urgent issue since it affects the billing system of almost everyone using opensips.

How can I debug this issue?

Thanks


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

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


From liviu at opensips.org  Wed Nov 28 16:02:23 2012
From: liviu at opensips.org (Liviu Chircu)
Date: Wed, 28 Nov 2012 17:02:23 +0200
Subject: [OpenSIPS-Devel] [NEW] OpenSIPS script locks
In-Reply-To: <50B620B7.8040205@opensips.org>
References: <50B620B7.8040205@opensips.org>
Message-ID: <50B6277F.8020201@opensips.org>


The cfgutils module now provides the possibility of defining atomic
test-and-set operations in the OpenSIPS script.
Such need is a result of complex mixing in script of various
functionality / functions from different modules. Like testing
is done based on ratelimit module and the setting is done in
dialog module.

Modules do provide internal locking and synchronization for their
own functionalities, but cannot cover a more complex and various
scenarios of test-and-set scripting scenarios.

Example of scenarios which require atomic test-and-set functionalities:

###########
# Example 1: Counting active outgoing calls with dialog
# The F-URIs of the SIP messages are the same
#
# Suppose there are 0 active calls

get_profile_size("caller", "$fu", "$avp(size)");

if ($avp(size) < 1) {
     xlog("Call allowed!\n");
     set_dlg_profile("caller", "$fu");
     ...
} else {
     xlog("Too many calls!\n");
     ...
}

Possible correct result (profile will have size 1):
Call allowed!
Too many calls!

Possible bad result (profile will have size 2):
Call allowed!
Call allowed!


If two or more processes read the same value from get_profile_size(),
results may be incorrect. By using dynamic script locks, the problem is solved:

get_dynamic_lock("$fu");

get_profile_size("caller", "$fu", "$avp(size)");

if ($avp(size) < 10) {
     xlog("Call allowed!\n");
     set_dlg_profile("caller", "$fu");
     ...
} else {
     xlog("Too many calls!\n");
     ...
}

release_dynamic_lock("$fu");

###########
# Example 2: Counting registered users using cachedb_local
# In this educational example, two users register at the same time
#
# Suppose there are 10 registered users

cache_counter_fetch("local", "registered_users", "$avp(reg_users)");
$avp(reg_users) = $avp(reg_users) + 1;
cache_store("local", "registered_users", "$avp(reg_users)", 1200);

xlog("System has $avp(reg_users) registered users!\n");


Possible correct result:
System has 11 registered users!
System has 12 registered users!

Possible bad result:
System has 11 registered users!
System has 11 registered users!


The same thing as above. A sequence of two operations which should not
be atomic from an internal point of view, but from a logical perspective
it should. In order for the code to work properly, we can use static locks:

get_static_lock("reg_users");

cache_counter_fetch("local", "registered_users", "$avp(reg_users)");
$avp(reg_users) = $avp(reg_users) + 1;
cache_store("local", "registered_users", "$avp(reg_users)", 1200);

release_static_lock("reg_users");

xlog("System has $avp(reg_users) registered users!\n");

-- 
Liviu Chircu
OpenSIPS Dev
http://www.opensips-solutions.com






From osas at voipembedded.com  Wed Nov 28 16:59:18 2012
From: osas at voipembedded.com (Ovidiu Sas)
Date: Wed, 28 Nov 2012 10:59:18 -0500
Subject: [OpenSIPS-Devel] [OpenSIPS-Users] [NEW] OpenSIPS script locks
In-Reply-To: <50B6277F.8020201@opensips.org>
References: <50B620B7.8040205@opensips.org>
	<50B6277F.8020201@opensips.org>
Message-ID: <CAND0Lks7BJox9mpb0xSxYuKzCNXnPtjWMm9RLRhEf-Azx1aP5g@mail.gmail.com>

Hello Liviu,

Thank you for this new feature!

Regards,
Ovidiu Sas

On Wed, Nov 28, 2012 at 10:02 AM, Liviu Chircu <liviu at opensips.org> wrote:
>
> The cfgutils module now provides the possibility of defining atomic
> test-and-set operations in the OpenSIPS script.
> Such need is a result of complex mixing in script of various
> functionality / functions from different modules. Like testing
> is done based on ratelimit module and the setting is done in
> dialog module.
>
> Modules do provide internal locking and synchronization for their
> own functionalities, but cannot cover a more complex and various
> scenarios of test-and-set scripting scenarios.
>
> Example of scenarios which require atomic test-and-set functionalities:
>
> ###########
> # Example 1: Counting active outgoing calls with dialog
> # The F-URIs of the SIP messages are the same
> #
> # Suppose there are 0 active calls
>
> get_profile_size("caller", "$fu", "$avp(size)");
>
> if ($avp(size) < 1) {
>     xlog("Call allowed!\n");
>     set_dlg_profile("caller", "$fu");
>     ...
> } else {
>     xlog("Too many calls!\n");
>     ...
> }
>
> Possible correct result (profile will have size 1):
> Call allowed!
> Too many calls!
>
> Possible bad result (profile will have size 2):
> Call allowed!
> Call allowed!
>
>
> If two or more processes read the same value from get_profile_size(),
> results may be incorrect. By using dynamic script locks, the problem is
> solved:
>
> get_dynamic_lock("$fu");
>
> get_profile_size("caller", "$fu", "$avp(size)");
>
> if ($avp(size) < 10) {
>     xlog("Call allowed!\n");
>     set_dlg_profile("caller", "$fu");
>     ...
> } else {
>     xlog("Too many calls!\n");
>     ...
> }
>
> release_dynamic_lock("$fu");
>
> ###########
> # Example 2: Counting registered users using cachedb_local
> # In this educational example, two users register at the same time
> #
> # Suppose there are 10 registered users
>
> cache_counter_fetch("local", "registered_users", "$avp(reg_users)");
> $avp(reg_users) = $avp(reg_users) + 1;
> cache_store("local", "registered_users", "$avp(reg_users)", 1200);
>
> xlog("System has $avp(reg_users) registered users!\n");
>
>
> Possible correct result:
> System has 11 registered users!
> System has 12 registered users!
>
> Possible bad result:
> System has 11 registered users!
> System has 11 registered users!
>
>
> The same thing as above. A sequence of two operations which should not
> be atomic from an internal point of view, but from a logical perspective
> it should. In order for the code to work properly, we can use static locks:
>
> get_static_lock("reg_users");
>
> cache_counter_fetch("local", "registered_users", "$avp(reg_users)");
> $avp(reg_users) = $avp(reg_users) + 1;
> cache_store("local", "registered_users", "$avp(reg_users)", 1200);
>
> release_static_lock("reg_users");
>
> xlog("System has $avp(reg_users) registered users!\n");
>
> --
> Liviu Chircu
> OpenSIPS Dev
> http://www.opensips-solutions.com
>
>
>
>
>
> _______________________________________________
> Users mailing list
> Users at lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users



-- 
VoIP Embedded, Inc.
http://www.voipembedded.com


From noreply at sourceforge.net  Wed Nov 28 18:35:30 2012
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed, 28 Nov 2012 09:35:30 -0800
Subject: [OpenSIPS-Devel] [ opensips-Bugs-3590667 ] ACC not logging BYE on
	random calls
Message-ID: <mailman.1237.1354124139.13469.devel@lists.opensips.org>

Bugs item #3590667, was opened at 2012-11-28 04:30
Message generated for change (Comment added) made by vladut-paiu
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=3590667&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.8.x
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Daniel ()
>Assigned to: Vladut-Stefan Paiu (vladut-paiu)
Summary: ACC not logging BYE on random calls

Initial Comment:
Hi

I built a billing system using Opensips. The logic was to log on a mysql table "acc" all INVITEs and BYEs to be removed later. Then within a few seconds, a console would search for BYEs and related INVITES, calculate duration and price, write on the final table and erase those 2 records from this table.
After some time running, I checked that randomly calls, ACC wrote to DB just the INVITEs and not the BYEs. Checked on syslog and happened the same. I got this:

sbin/opensips[2024]: ACC: transaction answered: timestamp=1353582441;method=INVITE;from_tag=as6c53d5bd;to_tag=1c431879610;call_id=c1434b259b666c921e0c67752f09c01 at 2.2.2.2:5060;code=200;reason=OK

But not the "BYE" message.

This seems to be a bug on ACC module because it doesn?t write the data to Mysql neither to syslog, and also doesn't generate any error on syslog.

To make sure that my problem was on the module and not in my logic, I removed almost all functionality of my Opensips and let just the call routing and ACC module... It reduced the problem but still happens on some situations, from 0.5% to 5% of all calls, randomly.

To temporary solve my problem, i forced INSERT on DB using avp_db_query on loose_route function. On 95% calls it generate a duplicated BYE on my table but my algorithm discard these additional BYEs, so it?s fine for now.

I believe this is an urgent issue since it affects the billing system of almost everyone using opensips.

How can I debug this issue?

Thanks


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

>Comment By: Vladut-Stefan Paiu (vladut-paiu)
Date: 2012-11-28 09:35

Message:
Hello,

So you cannot replicate this scenario ?
Are you sure that the BYEs that are not accounted for are ok from SIP and
Dialog point of view ? Perhaps they have no route headers, and thus they do
not enter the scripting logic where you set the accounting flag for the BYE
as well.

Could you try to setup more logging in your script, putting some xlog
messages for BYEs , and then search for the missing BYEs in the log file,
to make sure they are hitting your part of the script ?

Regards,
Vlad

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

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


From noreply at sourceforge.net  Wed Nov 28 18:39:34 2012
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed, 28 Nov 2012 09:39:34 -0800
Subject: [OpenSIPS-Devel] [ opensips-Bugs-3590655 ] Random Crash
Message-ID: <mailman.1238.1354124382.13469.devel@lists.opensips.org>

Bugs item #3590655, was opened at 2012-11-28 02:58
Message generated for change (Comment added) made by vladut-paiu
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=3590655&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.8.x
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: bruceborrett (nanotiva)
Assigned to: Nobody/Anonymous (nobody)
Summary: Random Crash

Initial Comment:
We experienced a seemingly random crash on our server which has been running for months without a single issue.

The following kernel error was logged:
kernel: [8988656.469074] opensips[18871]: segfault at 0 ip 000000000048c0d9 sp 00007fffd71a92c0 error 6 in opensips[400000+11c000]

Here is the full backtrace:
#0  0x000000000048c0d9 in fm_remove_free (n=<optimized out>, qm=<optimized out>) at mem/f_malloc.c:172
        pf = 0x0
        hash = 1
#1  fm_malloc (qm=0x7f412fdd2000, size=8) at mem/f_malloc.c:378
        frag = 0x7f41302c3300
        n = <optimized out>
        hash = <optimized out>
        __FUNCTION__ = "fm_malloc"
#2  0x00007f4134e9f41c in shm_malloc (size=<optimized out>) at ../../evi/../mem/shm_mem.h:202
        p = <optimized out>
#3  dlg_add_leg_info (dlg=0x7f41302f49d0, tag=0x7f4138515c98, rr=<optimized out>, contact=<optimized out>, cseq=0x7fffd71a9450, sock=<optimized out>,
    mangled_from=0x0, mangled_to=0x0) at dlg_hash.c:343
        leg = 0x7f41300b4c68
        head = 0x0
        rrp = <optimized out>
        __FUNCTION__ = "dlg_add_leg_info"
#4  0x00007f4134e9a8e6 in init_leg_info (dlg=0x7f41302f49d0, msg=0x7f4138504718, t=<optimized out>, tag=<optimized out>, mangled_from=<optimized out>,
    mangled_to=0x0) at dlg_handlers.c:243
        skip_recs = 0
        cseq = {
          s = 0x741f7f "2 INVITE\r\nExpires: 180\r\nFrom: <sip:3226 at 41.73.53.1>;tag=c0a8010a-ba80\r\nMax-Forwards: 69\r\nProxy-Authorization: Digest realm=\"41.73.53.1\", nonce=\"50b4902500005e9c4ceb3b7d9055f4453382581e2965bb0b\", usern"..., len = 1}
        contact = {s = 0x7f4138507c70 "sip:3226 at 196.25.214.82:5060", len = 27}
        rr_set = {s = 0x0, len = 0}
        __FUNCTION__ = "init_leg_info"
#5  0x00007f4134e9b13e in dlg_create_dialog (t=0x0, req=0x7f4138504718, flags=0) at dlg_handlers.c:887
        dlg = <optimized out>
        s = {
          s = 0x741ef3 "call-F113832A-B71A-3010-101F-4232 at 192.168.1.10\r\nContact: <sip:3226 at 192.168.1.10>\r\nContent-Length: 298\r\nContent-Type: application/sdp\r\nCSeq: 2 INVITE\r\nExpires: 180\r\nFrom: <sip:3226 at 41.73.53.1>;tag=c0a8"..., len = 46}
        __FUNCTION__ = "dlg_create_dialog"
#6  0x00007f4134e88306 in w_create_dialog (req=0x7f4138504718) at dialog.c:832
        t = <optimized out>
#7  0x0000000000413bf5 in do_action (a=0x7f41384908e8, msg=0x7f4138504718) at action.c:1483
        val_s = {s = 0x4 <Address 0x4 out of bounds>, len = 7610407}
        increment = <optimized out>
        decrement = <optimized out>
        aux = {s = 0x7f4138504718 "\r\214\002", len = 7610407}
        adv_addr = {s = 0x7423b5 "", len = 4780225}
        ret = <optimized out>
        v = <optimized out>
        to = <optimized out>
        p = <optimized out>
        tmp = <optimized out>
        new_uri = <optimized out>
        end = <optimized out>
        crt = <optimized out>
        len = <optimized out>
        i = <optimized out>
        user = <optimized out>
        expires = <optimized out>
        vals = {{
            s = 0x74223e "39f1e0281836c06018033323236700581303131391301000f0b413032312d303133383633\r\n\r\nv=0\r\no=Quintum 5362 5362 IN IP4 192.168.1.10\r\ns=VoipCall\r\nc=IN IP4 192.168.1.10\r\nt=0 0\r\nm=audio 10412 RTP/AVP 18 8 101 13\r\n"..., len = 7610112}, {s = 0x7fffd71a9a00 "\265#t", len = -1}, {
            s = 0x7f4138512c98  <incomplete sequence \350>, len = 944855384}, {
            s = 0x742164 "branch=z9hG4bK-tenor-c0a8-010a-23383\r\nQuintum: 0c01030b053235353330050100075b1b01010000211b3600040a8090809", '0' <repeats 11 times>, "8300180c818080810000800380000000001e03808183006c08808180803332323600700680813031313"..., len = 7610247}, {s = 0x7423b5 "", len = 4797239}}
        result = {s = 0x2 <Address 0x2 out of bounds>, len = 7610694}
        uri = {user = {s = 0x0, len = 816207616}, passwd = {s = 0x7f4135f1fb48 "acc", len = 3}, host = {s = 0x38506f3e <Address 0x38506f3e out of bounds>,
            len = 2}, port = {s = 0xe <Address 0xe out of bounds>, len = 944785176}, params = {s = 0x7f41301fe1a8 "\002", len = 128}, headers = {
            s = 0x71d5a8 "\b\244\335/A\177", len = 816205752}, port_no = 30936, proto = 12429, type = 32577, transport = {
            s = 0x7f4136fb198a "\351\274\375\377\377\220H\213\005Y\372!", len = -686122836}, ttl = {s = 0x3 <Address 0x3 out of bounds>, len = -686122836},
          user_param = {s = 0x7f4138488c60 "H\201N8A\177", len = -686122912}, maddr = {s = 0x7fffd71a9898 "\254\004C", len = 814577880}, method = {
            s = 0x751ee0 "\270\255\n0A\177", len = 816205752}, lr = {s = 0x7f4138504718 "\r\214\002", len = 200}, r2 = {s = 0x7f41301fe1b8 "",
            len = -686122528}, gr = {s = 0x7f41308d79f0 "\001", len = 944278552}, transport_val = {s = 0x4304ac "H\205\300\017\205X\377\377\377H\213=LH3",
            len = 944785176}, ttl_val = {s = 0x7f41308d78d8 "", len = 814584496}, user_param_val = {s = 0x400 <Address 0x400 out of bounds>, len = 1},
          maddr_val = {s = 0x0, len = 944859768}, method_val = {s = 0x7f4136fb1a90 "L\213\253", <incomplete sequence \360>, len = 814578008}, lr_val = {
            s = 0x33c <Address 0x33c out of bounds>, len = 944859768}, r2_val = {s = 0x7f41308d79f8 "\002", len = 1}, gr_val = {
            s = 0x7fffd71a9918 "\215\326\372\066A\177", len = 944859768}, u_name = {{s = 0x7f4136fad68d "\203\370\377\211\303\017\204P\001", len = 806659848},
            {s = 0x0, len = 814577880}, {s = 0x7f4138504718 "\r\214\002", len = 0}, {s = 0x7f4130882238 "", len = 46717}, {
              s = 0x1 <Address 0x1 out of bounds>, len = 7610463}}, u_val = {{s = 0x7f413850caa0 "\001", len = 7610386}, {
              s = 0x742164 "branch=z9hG4bK-tenor-c0a8-010a-23383\r\nQuintum: 0c01030b053235353330050100075b1b01010000211b3600040a8090809", '0' <repeats 11 times>, "8300180c818080810000800380000000001e03808183006c08808180803332323600700680813031313"..., len = 944818848}, {
              s = 0x4ae3ad "H\205\300H\211D$PD\017\266T$8L\213\\$@\017\204\340\036", len = 29}, {
              s = 0x49ff62 "H\205\300I\211\306L\213T$ D\213\\$(\017\204M\a", len = -686122244}, {s = 0x7f4138504f38 "\220\001", len = 0}}, u_params_no = 22872}
        next_hop = {user = {s = 0x4c4b40 "\211\350A\207\004$\205\300t\036\205\333~\n\203\353\001\353\355\017\037D", len = 376}, passwd = {
            s = 0x71d5a8 "\b\244\335/A\177", len = 944781648}, host = {
            s = 0x7525e0 "insert into dialog (hash_entry,hash_id,callid,from_uri,from_tag,to_uri,to_tag,caller_sock,callee_sock,start_time,mangled_from_uri,mangled_to_uri,state,timeout,caller_cseq,callee_cseq,caller_ping_cseq,"..., len = 942047158}, port = {s = 0x0, len = 25}, params = {s = 0x7fffd71a96b0 "\017",
            len = -686123344}, headers = {s = 0x7f41384e91b0 "\004", len = 816205752}, port_no = 7, proto = 0, type = ERROR_URI_T, transport = {
            s = 0x7f4138504717 "", len = 0}, ttl = {s = 0x7f413850a0e8 "", len = 944781648}, user_param = {s = 0x0, len = 889960096}, maddr = {
            s = 0x7f41385098e8 "\350\240P8A\177", len = 944806184}, method = {s = 0x7fffd71a9680 "\006\220\264P", len = 7}, lr = {
            s = 0x7fffd71a9690 "\030GP8A\177", len = 816205752}, r2 = {s = 0x7f4135f19641 "\205\300t\232H\213\005dq ", len = 1354010630}, gr = {
            s = 0x92a88 <Address 0x92a88 out of bounds>, len = 1354010630}, transport_val = {s = 0x8dd1c <Address 0x8dd1c out of bounds>, len = 944785176},
          ttl_val = {s = 0x0, len = 0}, user_param_val = {s = 0x7f4138503950 "\360C\024\066A\177", len = 15}, maddr_val = {s = 0x7f4136142040 "\004",
            len = 907287904}, method_val = {s = 0x7f4136144300 "", len = 907297472}, lr_val = {s = 0x7f4138269a37 "H\307C\b", len = 907288640}, r2_val = {
            s = 0x7f4136141220 "\300\036t", len = 907288640}, gr_val = {s = 0xf <Address 0xf out of bounds>, len = 816205752}, u_name = {{
              s = 0x7f4135f143b4 "\205\300\017\211\361\376\377\377H\213\005\355\303 ", len = 809199768}, {s = 0xe <Address 0xe out of bounds>,
              len = 944785176}, {s = 0x7fffd71a97f0 "\250\341\037\060A\177", len = 7610111}, {s = 0x7f4130a64fb8 "\267\213\002", len = 907297728}, {
              s = 0x7f41308d78d8 "", len = 944785176}}, u_val = {{s = 0x7f4136120be0 "H\373\361\065A\177", len = 200}, {
              s = 0x7f4135f1b9e2 "\351\270\372\377\377f\017\037\204", len = 807924736}, {s = 0x7f41358fa610 "\017\234o5A\177", len = 39}, {
              s = 0x7f4134e9d19a "H\215H\377H\211\302\061\300H\203\371\375w\323H\213\202\030\032", len = 0}, {
              s = 0x7f41356f38fd "H\205\300H\211\305\017\204\257", len = 39}}, u_params_no = 0}
        u = <optimized out>
        port = <optimized out>
        cmatch = <optimized out>
        aitem = <optimized out>
        adefault = <optimized out>
        spec = <optimized out>
        model = <optimized out>
        val = {rs = {
            s = 0x742029 "55f4453382581e2965bb0b\", username=\"federalmogul\", uri=\"sip:0119810000 at 41.73.53.1\", response=\"626090ba2fd3b2d919f697c330e26f37\"\r\nSession-GUID: 892363316-1633957986-875705136-4\r\nSupported: 100rel\r\nTo: <"..., len = 7610699}, ri = 944795136, flags = 32577}
        pve = <optimized out>
        name_s = {s = 0x7f4138504718 "\r\214\002", len = 7610694}
        start = {tv_sec = 1354010631, tv_usec = 934753}
        end_time = <optimized out>
        __FUNCTION__ = "do_action"
#8  0x00000000004122ab in run_action_list (a=<optimized out>, msg=0x7f4138504718) at action.c:143
        ret = 1
        t = 0x7f41384908e8
        __FUNCTION__ = "run_action_list"
#9  0x0000000000417a30 in run_actions (msg=<optimized out>, a=<optimized out>) at action.c:123
No locals.
#10 run_top_route (a=0x7f413848f098, msg=0x7f4138504718) at action.c:189
        bl_last_msg_id = 166925
        bk_action_flags = 0
        bk_rec_lev = 0
#11 0x000000000044c5c7 in receive_msg (
    buf=0x741ec0 "INVITE sip:0119810000 at 41.73.53.1 SIP/2.0\r\nCall-ID: call-F113832A-B71A-3010-101F-4232 at 192.168.1.10\r\nContact: <sip:3226 at 192.168.1.10>\r\nContent-Length: 298\r\nContent-Type: application/sdp\r\nCSeq: 2 INVITE\r"..., len=1269, rcv_info=0x7fffd71a9c90) at receive.c:165
        msg = 0x7f4138504718
        start = {tv_sec = 1354010631, tv_usec = 934360}
        __FUNCTION__ = "receive_msg"
#12 0x0000000000487083 in udp_rcv_loop () at udp_server.c:424
        len = 1269
        buf = "INVITE sip:0119810000 at 41.73.53.1 SIP/2.0\r\nCall-ID: call-F113832A-B71A-3010-101F-4232 at 192.168.1.10\r\nContact: <sip:3226 at 192.168.1.10>\r\nContent-Length: 298\r\nContent-Type: application/sdp\r\nCSeq: 2 INVITE\r"...
        tmp = <optimized out>
        from = <optimized out>
        fromlen = 16
        ri = {src_ip = {af = 2, len = 4, u = {addrl = {1389763012, 140736802233736}, addr32 = {1389763012, 0, 3608845704, 32767}, addr16 = {6596, 21206, 0, 0,
                40328, 55066, 32767, 0}, addr = "\304\031\326R\000\000\000\000\210\235\032\327\377\177\000"}}, dst_ip = {af = 2, len = 4, u = {addrl = {
                20269353, 0}, addr32 = {20269353, 0, 0, 0}, addr16 = {18729, 309, 0, 0, 0, 0, 0, 0}, addr = ")I5\001", '\000' <repeats 11 times>}},
          src_port = 5060, dst_port = 5060, proto = 1, proto_reserved1 = 0, proto_reserved2 = 0, src_su = {s = {sa_family = 2,
              sa_data = "\023\304\304\031\326R\000\000\000\000\000\000\000"}, sin = {sin_family = 2, sin_port = 50195, sin_addr = {s_addr = 1389763012},
              sin_zero = "\000\000\000\000\000\000\000"}, sin6 = {sin6_family = 2, sin6_port = 50195, sin6_flowinfo = 1389763012, sin6_addr = {__in6_u = {
                  __u6_addr8 = '\000' <repeats 15 times>, __u6_addr16 = {0, 0, 0, 0, 0, 0, 0, 0}, __u6_addr32 = {0, 0, 0, 0}}}, sin6_scope_id = 0}},
          bind_address = 0x7f4138488c18}
        p = 0x4f5
        msg = {
          s = 0x741ec0 "INVITE sip:0119810000 at 41.73.53.1 SIP/2.0\r\nCall-ID: call-F113832A-B71A-3010-101F-4232 at 192.168.1.10\r\nContact: <sip:3226 at 192.168.1.10>\r\nContent-Length: 298\r\nContent-Type: application/sdp\r\nCSeq: 2 INVITE\r"..., len = 1269}
        __FUNCTION__ = "udp_rcv_loop"
#13 0x0000000000429a46 in main_loop () at main.c:876
        i = 3
        pid = <optimized out>
        si = 0x7f4138488c18
        startup_done = 0x0
        chd_rank = 4
        load_p = 0x7f41303d4370
#14 main (argc=<optimized out>, argv=<optimized out>) at main.c:1520
        cfg_log_stderr = <optimized out>
        cfg_stream = <optimized out>
        c = <optimized out>
        r = <optimized out>
        tmp = 0x7fffd71aaf16 ""
        tmp_len = <optimized out>
        port = <optimized out>
        proto = <optimized out>
        ret = <optimized out>
        seed = 2837169747
        rfd = <optimized out>
        __FUNCTION__ = "main"

Version info:

version: opensips 1.8.0-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: 2:9212M
@(#) $Id: main.c 8772 2012-03-08 11:16:13Z bogdan_iancu $
main.c compiled on 07:29:16 Aug 15 2012 with gcc 4.4.5


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

>Comment By: Vladut-Stefan Paiu (vladut-paiu)
Date: 2012-11-28 09:39

Message:
Hello,

Seems you are having some sort of memory corruption there, related to the
dialog module. 
Could you please update to 1.8.2 ? It should contain many fixes compared to
1.8.0. 

If the issue still replicates with the latest 1.8, then let us know.

Best Regards,
Vlad

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

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


From noreply at sourceforge.net  Wed Nov 28 18:40:47 2012
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed, 28 Nov 2012 09:40:47 -0800
Subject: [OpenSIPS-Devel] [ opensips-Bugs-3590418 ] MI DATAGRAM specific
	commands fail
Message-ID: <mailman.1239.1354124454.13469.devel@lists.opensips.org>

Bugs item #3590418, was opened at 2012-11-27 10:57
Message generated for change (Comment added) made by vladut-paiu
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=3590418&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.8.x
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Digipigeon (digipigeon)
Assigned to: Nobody/Anonymous (nobody)
Summary: MI DATAGRAM specific commands fail

Initial Comment:
Using 1.8.2, applying a different connector to my existing mi methods the following commands that I have issued work over ALL XMLRPC, FIFO, MI_HTTP & MI_DATAGRAM

version - WORKS ALL
uptime - WORKS ALL

However the following commands work on XMLRPC, FIFO, MI_HTTP but FAIL on MI_DATAGRAM 

All Passed with no arguments

dr_gw_status - FAILS ON MI_DATAGRAM
debug - FAILS ON MI_DATAGRAM

Regards Jonathan

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

>Comment By: Vladut-Stefan Paiu (vladut-paiu)
Date: 2012-11-28 09:40

Message:
Hello,

Do you see any specific mi_datagram error messages when you trigger the
dr_gw_status or debug MI commands ? Do those commands fail all the time, or
randomly fail ?

Regards,
Vlad

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

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


From noreply at sourceforge.net  Wed Nov 28 18:41:14 2012
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed, 28 Nov 2012 09:41:14 -0800
Subject: [OpenSIPS-Devel] [ opensips-Bugs-3590411 ] HTTP_MI memory leak
Message-ID: <mailman.1240.1354124481.13469.devel@lists.opensips.org>

Bugs item #3590411, was opened at 2012-11-27 09:59
Message generated for change (Settings changed) made by vladut-paiu
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=3590411&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.8.x
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Digipigeon (digipigeon)
>Assigned to: Ovidiu Sas (osas)
Summary: HTTP_MI memory leak

Initial Comment:
There appears to be a memory leak in the http_mi module, Opensips 1.8.2.

When package memory is set to 4MB the memory leak becomes apparent after a few hours.

When the package memory is set to 64MB after a few days.

The HTTP Requests begin to fail with Error 500 and the log shows "ERROR:core:init_mi_tree: no more pkg mem".

This has only started to happen after switching from xmlrpc to mi_http.

Regards Jonathan

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

Comment By: Ovidiu Sas (osas)
Date: 2012-11-27 12:48

Message:
Hello Jonathan,

I committed a fix in trunk.
Can you test it and let me know the results?

Thanks,
Ovidiu

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

Comment By: Ovidiu Sas (osas)
Date: 2012-11-27 10:16

Message:
Hello Jonathan,

Do you run a particular set of commands?
Can you post the HTTP requests that you are using?
How many HTTP requests do you run per minute?

Thanks,
Ovidiu

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

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


From noreply at sourceforge.net  Wed Nov 28 18:43:36 2012
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed, 28 Nov 2012 09:43:36 -0800
Subject: [OpenSIPS-Devel] [ opensips-Bugs-3590367 ] DISPATCHER. Commit #9448
	breaks dispatcher pings
Message-ID: <mailman.1241.1354124624.13469.devel@lists.opensips.org>

Bugs item #3590367, was opened at 2012-11-27 06:22
Message generated for change (Comment added) made by vladut-paiu
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=3590367&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: Nick Altmann (nikbyte)
>Assigned to: Vladut-Stefan Paiu (vladut-paiu)
Summary: DISPATCHER. Commit #9448 breaks dispatcher pings

Initial Comment:
After this commit dispatcher pings are going from incorrect interface on multihomed opensips.


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

>Comment By: Vladut-Stefan Paiu (vladut-paiu)
Date: 2012-11-28 09:43

Message:
Hello Nick,

Could you please give us a little more information about your setup and
scenario ?

Regards,
Vlad

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

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


From noreply at sourceforge.net  Wed Nov 28 18:46:05 2012
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed, 28 Nov 2012 09:46:05 -0800
Subject: [OpenSIPS-Devel] [ opensips-Bugs-3590367 ] DISPATCHER. Commit #9448
	breaks dispatcher pings
Message-ID: <mailman.1242.1354124773.13469.devel@lists.opensips.org>

Bugs item #3590367, was opened at 2012-11-27 06:22
Message generated for change (Comment added) made by nikbyte
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=3590367&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: Nick Altmann (nikbyte)
Assigned to: Vladut-Stefan Paiu (vladut-paiu)
Summary: DISPATCHER. Commit #9448 breaks dispatcher pings

Initial Comment:
After this commit dispatcher pings are going from incorrect interface on multihomed opensips.


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

>Comment By: Nick Altmann (nikbyte)
Date: 2012-11-28 09:46

Message:
Common setup, dispatcher module with hosts from RFC1918 network and hosts
from external network. Two network interfaces - internal and external.
Before this commit internal gateways pings from internal ip, external pings
from external ip. After commit it tries to send packets to external
gateways from internal interface.

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

Comment By: Vladut-Stefan Paiu (vladut-paiu)
Date: 2012-11-28 09:43

Message:
Hello Nick,

Could you please give us a little more information about your setup and
scenario ?

Regards,
Vlad

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

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


From vladpaiu at opensips.org  Wed Nov 28 18:48:16 2012
From: vladpaiu at opensips.org (Vlad Paiu)
Date: Wed, 28 Nov 2012 17:48:16 +0000
Subject: [OpenSIPS-Devel] SF.net SVN: opensips:[9456]
	branches/1.7/modules/dialog
Message-ID: <E1Tdlk8-0003HH-8o@sfp-svn-1.v30.ch3.sourceforge.com>

Revision: 9456
          http://opensips.svn.sourceforge.net/opensips/?rev=9456&view=rev
Author:   vladut-paiu
Date:     2012-11-28 17:48:15 +0000 (Wed, 28 Nov 2012)
Log Message:
-----------
fixed readme about the timeout_avp behavior
Credits to Walter Doekes

Modified Paths:
--------------
    branches/1.7/modules/dialog/README
    branches/1.7/modules/dialog/doc/dialog_admin.xml

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



From vladpaiu at opensips.org  Wed Nov 28 18:50:54 2012
From: vladpaiu at opensips.org (Vlad Paiu)
Date: Wed, 28 Nov 2012 17:50:54 +0000
Subject: [OpenSIPS-Devel] SF.net SVN: opensips:[9457]
	branches/1.8/modules/dialog
Message-ID: <E1Tdlmg-00074u-JF@sfp-svn-2.v30.ch3.sourceforge.com>

Revision: 9457
          http://opensips.svn.sourceforge.net/opensips/?rev=9457&view=rev
Author:   vladut-paiu
Date:     2012-11-28 17:50:54 +0000 (Wed, 28 Nov 2012)
Log Message:
-----------
backport from 1.7 (rev #9456)

fixed readme about the timeout_avp behavior
Credits to Walter Doekes

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

Modified Paths:
--------------
    branches/1.8/modules/dialog/README
    branches/1.8/modules/dialog/doc/dialog_admin.xml

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



From vladpaiu at opensips.org  Wed Nov 28 18:53:09 2012
From: vladpaiu at opensips.org (Vlad Paiu)
Date: Wed, 28 Nov 2012 17:53:09 +0000
Subject: [OpenSIPS-Devel] SF.net SVN: opensips:[9458] trunk/modules/dialog
Message-ID: <E1Tdlor-0007El-Lw@sfp-svn-2.v30.ch3.sourceforge.com>

Revision: 9458
          http://opensips.svn.sourceforge.net/opensips/?rev=9458&view=rev
Author:   vladut-paiu
Date:     2012-11-28 17:53:09 +0000 (Wed, 28 Nov 2012)
Log Message:
-----------
backport from 1.7 (rev #9456)

fixed readme about the timeout_avp behavior
Credits to Walter Doekes

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

Modified Paths:
--------------
    trunk/modules/dialog/README
    trunk/modules/dialog/doc/dialog_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  Wed Nov 28 18:53:39 2012
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed, 28 Nov 2012 09:53:39 -0800
Subject: [OpenSIPS-Devel] [ opensips-Bugs-3590334 ] timeout_avp not callable
	after loose_route
Message-ID: <mailman.1243.1354125226.13469.devel@lists.opensips.org>

Bugs item #3590334, was opened at 2012-11-27 03:15
Message generated for change (Comment added) made by vladut-paiu
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=3590334&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.7.x
>Status: Closed
>Resolution: Fixed
Priority: 5
Private: No
Submitted By: Walter Doekes (wdoekes)
Assigned to: Nobody/Anonymous (nobody)
Summary: timeout_avp not callable after loose_route

Initial Comment:
Hi, I noticed that setting the dialog timeout_avp after calling loose_route() is a no-op.

I don't know if that's intentional or not, but it isn't documented (where I'd expect it).

Added a patch (against 1.7) that updates the documentation.

Regards,
Walter Doekes
OSSO B.V.

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

>Comment By: Vladut-Stefan Paiu (vladut-paiu)
Date: 2012-11-28 09:53

Message:
Hello Walter,

Thanks for the doc patch. Applied on 1.7, 1.8 and trunk.

Best Regards,
Vlad

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

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


From noreply at sourceforge.net  Wed Nov 28 18:55:20 2012
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed, 28 Nov 2012 09:55:20 -0800
Subject: [OpenSIPS-Devel] [ opensips-Bugs-3586730 ] $var variables cleanup
	on new request
Message-ID: <mailman.1244.1354125329.13469.devel@lists.opensips.org>

Bugs item #3586730, was opened at 2012-11-13 07:03
Message generated for change (Settings changed) made by vladut-paiu
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=3586730&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.8.x
>Status: Closed
Resolution: Invalid
Priority: 5
Private: No
Submitted By: Nick Altmann (nikbyte)
Assigned to: Bogdan-Andrei Iancu (bogdan_iancu)
Summary: $var variables cleanup on new request

Initial Comment:
I found that in my script I do something like (the same tail of every log message is because of m4 macros):

route {
    xlog("L_INFO", "[MAIN] log message [$var(info)]");
    $var(info) = "blablabla";
    xlog("L_INFO", "[MAIN] another message [$var(info)]");
}

Interesting that in first xlog the $var(info) is not null ! 
And instead of "null" I see there something interesting values from other client's requests.

I think we should clean up all $var variables before request, shouldn't we?


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

Comment By: Bogdan-Andrei Iancu (bogdan_iancu)
Date: 2012-11-21 08:33

Message:
Hi Nick,

The $var() are on purpose process persistent - they are not ever reset. You
need to take care in script and reset it before using it.

The fact they are process persistent may help you to pass values between
different routes (like requests and branch route) when the routes are
triggered in the same process (in a row, like onreply + failure)

Regards,
Bogdan

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

Comment By: Robert Smith (denodaeus)
Date: 2012-11-13 07:44

Message:
I've been bitten by this before, but it's intentional.  From the docs:

http://www.opensips.org/Resources/DocsCoreVar18#varscript

1.  if you want to start using a script variable in a route, better
initialize it with same value (or reset it), otherwise you may inherit a
value from a previous route that was executed by the same process.
3. the value of script variables persists over a OpenSIPS process.

So you can either initialize it to the same default value every time, or
you can use something transactional instead (like avp's).



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

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


From noreply at sourceforge.net  Wed Nov 28 18:57:29 2012
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed, 28 Nov 2012 09:57:29 -0800
Subject: [OpenSIPS-Devel] [ opensips-Bugs-3589398 ] db_mysql crash
Message-ID: <mailman.1245.1354125455.13469.devel@lists.opensips.org>

Bugs item #3589398, was opened at 2012-11-23 05:15
Message generated for change (Settings changed) made by vladut-paiu
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=3589398&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.8.x
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Dragos Oancea (dragosoancea)
>Assigned to: Vladut-Stefan Paiu (vladut-paiu)
Summary: db_mysql crash

Initial Comment:
Hi

I just found a core file generated by opensips on one of our servers which used to be pretty stable.

Core was generated by `/usr/sbin/opensips -P /var/run/opensips.pid -f /etc/opensips/opensips.cfg'.
Program terminated with signal 11, Segmentation fault.
#0  0x00007fbf502448de in vfprintf () from /lib64/libc.so.6
Missing separate debuginfos, use: debuginfo-install opensips-1.8.1-4.debug.el6.x86_64
(gdb) bt
#0  0x00007fbf502448de in vfprintf () from /lib64/libc.so.6
#1  0x00007fbf502fc2c0 in __vsnprintf_chk () from /lib64/libc.so.6
#2  0x00007fbf502fc1fa in __snprintf_chk () from /lib64/libc.so.6
#3  0x00000000004c44e9 in db_print_where ()
#4  0x00000000004c27f6 in db_do_delete ()
#5  0x00007fbf4ea32f54 in db_mysql_delete (_h=0x7fbf4ecf1558, _k=0x7fff682eaa20, _o=0x7fff682eaa10, _v=0x7fff682ea9d0, _n=2) at dbase.c:1061
#6  0x00007fbf4d18825d in db_timer_udomain (_d=0x7fbf28946f88) at udomain.c:612
#7  0x00007fbf4d1830e1 in synchronize_all_udomains () at dlist.c:591
#8  0x00007fbf4d18e408 in timer (ticks=<value optimized out>, param=<value optimized out>) at ul_mod.c:387
#9  0x000000000047d73a in start_timer_processes ()
#10 0x000000000042aa84 in main ()
(gdb) bt full 
#0  0x00007fbf502448de in vfprintf () from /lib64/libc.so.6
No symbol table info available.
#1  0x00007fbf502fc2c0 in __vsnprintf_chk () from /lib64/libc.so.6
No symbol table info available.
#2  0x00007fbf502fc1fa in __snprintf_chk () from /lib64/libc.so.6
No symbol table info available.
#3  0x00000000004c44e9 in db_print_where ()
No symbol table info available.
#4  0x00000000004c27f6 in db_do_delete ()
No symbol table info available.
#5  0x00007fbf4ea32f54 in db_mysql_delete (_h=0x7fbf4ecf1558, _k=0x7fff682eaa20, _o=0x7fff682eaa10, _v=0x7fff682ea9d0, _n=2) at dbase.c:1061
        ret = <value optimized out>
#6  0x00007fbf4d18825d in db_timer_udomain (_d=0x7fbf28946f88) at udomain.c:612
        my_ps = 0x7fbf4ecf42f0
        keys = {0x7fff682eaac0, 0x7fbf5029915d}
        ops = {0x0, 0x7fbf4ecc77e8 "\001"}
        vals = {{type = DB_DATETIME, nul = 0, free = 0, val = {int_val = 1353067975, bigint_val = 1353067975, double_val = 6.6850440293548263e-315, time_val = 1353067975, string_val = 0x50a62dc7 <Address 0x50a62dc7 out of bounds>, 
              str_val = {s = 0x50a62dc7 <Address 0x50a62dc7 out of bounds>, len = 100000}, blob_val = {s = 0x50a62dc7 <Address 0x50a62dc7 out of bounds>, len = 100000}, bitmap_val = 1353067975}}, {type = DB_DATETIME, nul = 0, 
            free = -10484703, val = {int_val = 0, bigint_val = 0, double_val = 0, time_val = 0, string_val = 0x0, str_val = {s = 0x0, len = 132100}, blob_val = {s = 0x0, len = 132100}, bitmap_val = 0}}}
        __FUNCTION__ = "db_timer_udomain"
#7  0x00007fbf4d1830e1 in synchronize_all_udomains () at dlist.c:591
        res = <value optimized out>
        ptr = 0x7fbf28946f28
#8  0x00007fbf4d18e408 in timer (ticks=<value optimized out>, param=<value optimized out>) at ul_mod.c:387
        __FUNCTION__ = "timer"
#9  0x000000000047d73a in start_timer_processes ()
No symbol table info available.
#10 0x000000000042aa84 in main ()


# opensips -V
version: opensips 1.8.1-tls (x86_64/linux)
flags: STATS: Off, USE_IPV6, USE_TCP, USE_TLS, DISABLE_NAGLE, USE_MCAST, SHM_MEM, SHM_MMAP, PKG_MALLOC, F_MALLOC, FAST_LOCK-ADAPTIVE_WAIT
ADAPTIVE_WAIT_LOOPS=1024, MAX_RECV_BUFFER_SIZE 262144, MAX_LISTEN 16, MAX_URI_SIZE 1024, BUF_SIZE 65535
poll method support: poll, epoll_lt, epoll_et, sigio_rt, select.
svnrevision: unknown
@(#) $Id: main.c 8772 2012-03-08 11:16:13Z bogdan_iancu $
main.c compiled on 15:18:52 Sep 28 2012 with gcc 4.4.6

I have no idea what happened. Maybe someone has a theory.

Regards,
Dragos

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

>Comment By: Vladut-Stefan Paiu (vladut-paiu)
Date: 2012-11-28 09:57

Message:
Hello,

Seems you had some sort of memory corruption there, as it seems that the
values send to the db_mysql driver are invalid ? 
Could you please give access to that core file, so we can look around
through the memory dump to see what went wrong there ?

Regards,
Vlad

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

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


From noreply at sourceforge.net  Thu Nov 29 10:36:12 2012
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 29 Nov 2012 01:36:12 -0800
Subject: [OpenSIPS-Devel] [ opensips-Bugs-3590953 ] Dialog module:
	dlg_terminate_dlg and register_dlgcb function
Message-ID: <mailman.1246.1354181780.13469.devel@lists.opensips.org>

Bugs item #3590953, was opened at 2012-11-29 01:36
Message generated for change (Tracker Item Submitted) made by 
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=3590953&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: https://www.google.com/accounts ()
Assigned to: Nobody/Anonymous (nobody)
Summary: Dialog module: dlg_terminate_dlg and register_dlgcb function

Initial Comment:
Hello,

On 11/26/12 3:52 PM, Eduardo Lejarreta wrote:
>
> Good evening.
>
>  
>
> I?m a rookie (not a developer), on users mailling list I?ve been forwarded to this. Anyway, this is the case:
>
>  
>
> Dialog, tm, rr and acc: 3.2.1 modules version
>
>  
>
> When you finish externally a dialog, v?a FIFO command with ?dlg_terminate_dlg: callid, from_tag? the callback register function ?register_dlgcb? on ?DLGCB_TERMINATED? event returns a:
>
>  
>
> dlg_cb_params * params->req             with (NIL) value.
the request does not exist in this case, going to be generated locally.

>  
>
> This callback  register function is used by ?acc? module with acc_cdr accounting enabled to track the end of the call.
>
>  
>
> In this scenario acc module can not account the end of the call. -> ERROR: acc [acc_cdr.c:480]: invalid values#012!
>
>  
> If you try this scenario over TCP and with ?RR? module with ?enable_double_rr? enabled you will see that the ?acc? module is able to track the end of the call because a double ?Record-route? header is inserted by proxy.
>  
> Do you think this could be an issue that it can be resolved in future? Or may be we?re forgetting something.
>  
> Any help, any idea?, 
Maybe you can solve it by storing dialog hash and id -- see the $dlg(...) class of variables.

It should be solved in a way or another, to become useful, please open an issue on the tracker not to forget about it. I plan to look a bit at cdr accounting with dialog before the next major release.

Cheers,
Daniel

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

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


From noreply at sourceforge.net  Thu Nov 29 11:05:19 2012
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 29 Nov 2012 02:05:19 -0800
Subject: [OpenSIPS-Devel] [ opensips-Bugs-3590411 ] HTTP_MI memory leak
Message-ID: <mailman.1247.1354183525.13469.devel@lists.opensips.org>

Bugs item #3590411, was opened at 2012-11-27 09:59
Message generated for change (Comment added) made by digipigeon
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=3590411&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.8.x
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Digipigeon (digipigeon)
Assigned to: Ovidiu Sas (osas)
Summary: HTTP_MI memory leak

Initial Comment:
There appears to be a memory leak in the http_mi module, Opensips 1.8.2.

When package memory is set to 4MB the memory leak becomes apparent after a few hours.

When the package memory is set to 64MB after a few days.

The HTTP Requests begin to fail with Error 500 and the log shows "ERROR:core:init_mi_tree: no more pkg mem".

This has only started to happen after switching from xmlrpc to mi_http.

Regards Jonathan

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

>Comment By: Digipigeon (digipigeon)
Date: 2012-11-29 02:05

Message:
I have tested the patched version vs the unpatched version for about 24
hours now.

The patched version does not exhibit the original problem, however I will
let this continue to run for a few more days and update you further.

Regards Jonathan

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

Comment By: Ovidiu Sas (osas)
Date: 2012-11-27 12:48

Message:
Hello Jonathan,

I committed a fix in trunk.
Can you test it and let me know the results?

Thanks,
Ovidiu

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

Comment By: Ovidiu Sas (osas)
Date: 2012-11-27 10:16

Message:
Hello Jonathan,

Do you run a particular set of commands?
Can you post the HTTP requests that you are using?
How many HTTP requests do you run per minute?

Thanks,
Ovidiu

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

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


From noreply at sourceforge.net  Thu Nov 29 11:34:07 2012
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 29 Nov 2012 02:34:07 -0800
Subject: [OpenSIPS-Devel] [ opensips-Bugs-3590978 ] registrar complains of a
	BUG
Message-ID: <mailman.1248.1354185252.13469.devel@lists.opensips.org>

Bugs item #3590978, was opened at 2012-11-29 02:34
Message generated for change (Tracker Item Submitted) made by kisskaroly
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=3590978&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.8.x
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Kiss Karoly (kisskaroly)
Assigned to: Nobody/Anonymous (nobody)
Summary: registrar complains of a BUG

Initial Comment:
I noticed the following in an opensips version 1.8.2 (rev #9429) log:
Nov 29 10:49:14 sip /usr/sbin/opensips[30799]: CRITICAL:registrar:update_contacts: BUG - overflow detected with r=0xa96c1a34 and contacts=(nil)

This happened right after a call to 
save("location", "$avp(rflags)fc$avp(maxregs)", "$var(furi)")
Contents of avp's and variables were:
$avp(rflags) = "";
$avp(maxregs) = 1;
$var(furi) = "sip:username at domain.tld";




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

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


From bogdan at opensips.org  Thu Nov 29 13:27:22 2012
From: bogdan at opensips.org (Bogdan-Andrei Iancu)
Date: Thu, 29 Nov 2012 14:27:22 +0200
Subject: [OpenSIPS-Devel] [OpenSIPS-Users] [NEW] OpenSIPS script locks
In-Reply-To: <CAPwC5wxR2FgnMwaQ6xjhyiOEL=1a6GPuucSYcUgKpoh7bhqv9g@mail.gmail.com>
References: <50B620B7.8040205@opensips.org> <50B6277F.8020201@opensips.org>
	<CAPwC5wxR2FgnMwaQ6xjhyiOEL=1a6GPuucSYcUgKpoh7bhqv9g@mail.gmail.com>
Message-ID: <50B754AA.4080709@opensips.org>

Hi Brett,

no, there is no timeout for the lock. so, if you are not careful in 
releasing the lock, you are a dead man with a dead opensips :).

We plan to add some mechanism to check and cleanup locks after the route 
is ended, but this requires some extra work in the core part (some 
callbacks to give access to executing any kind of route).

Regards,

Bogdan-Andrei Iancu
OpenSIPS Founder and Developer
http://www.opensips-solutions.com


On 11/28/2012 06:55 PM, Brett Nemeroff wrote:
> Liviu,
> This is a good idea. What happens to the child process as it's waiting 
> for a lock to be released? Are there any protections against locks 
> lasting indefinitely?
>
> Thanks,
> Brett
>
>
> On Wed, Nov 28, 2012 at 9:02 AM, Liviu Chircu <liviu at opensips.org 
> <mailto:liviu at opensips.org>> wrote:
>
>
>     The cfgutils module now provides the possibility of defining atomic
>     test-and-set operations in the OpenSIPS script.
>     Such need is a result of complex mixing in script of various
>     functionality / functions from different modules. Like testing
>     is done based on ratelimit module and the setting is done in
>     dialog module.
>
>     Modules do provide internal locking and synchronization for their
>     own functionalities, but cannot cover a more complex and various
>     scenarios of test-and-set scripting scenarios.
>
>
> _______________________________________________
> Users mailing list
> Users at lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/devel/attachments/20121129/6ef385c6/attachment.htm>

From noreply at sourceforge.net  Thu Nov 29 14:13:51 2012
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 29 Nov 2012 05:13:51 -0800
Subject: [OpenSIPS-Devel] [ opensips-Patches-3591017 ] Remove headers by
	wildcard
Message-ID: <mailman.1249.1354194839.13469.devel@lists.opensips.org>

Patches item #3591017, was opened at 2012-11-29 05:13
Message generated for change (Tracker Item Submitted) made by 
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086412&aid=3591017&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: https://www.google.com/accounts ()
Assigned to: Nobody/Anonymous (nobody)
Summary: Remove headers by wildcard

Initial Comment:
changes sipmsgops.c.
uses fnmatch() to remove headers by wildcard. 
usage example:
remove_hf_wc("P-hint*");  // removes all headers that start with P-hint
remove_hf_wc("*orig-ip*"); //removes all headers that that have orig-ip in their name


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

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


From noreply at sourceforge.net  Thu Nov 29 14:14:55 2012
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 29 Nov 2012 05:14:55 -0800
Subject: [OpenSIPS-Devel] [ opensips-Patches-3591017 ] Remove headers by
	wildcard
Message-ID: <mailman.1250.1354194904.13469.devel@lists.opensips.org>

Patches item #3591017, was opened at 2012-11-29 05:13
Message generated for change (Comment added) made by 
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086412&aid=3591017&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: https://www.google.com/accounts ()
Assigned to: Nobody/Anonymous (nobody)
Summary: Remove headers by wildcard

Initial Comment:
changes sipmsgops.c.
uses fnmatch() to remove headers by wildcard. 
usage example:
remove_hf_wc("P-hint*");  // removes all headers that start with P-hint
remove_hf_wc("*orig-ip*"); //removes all headers that that have orig-ip in their name


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

>Comment By: https://www.google.com/accounts ()
Date: 2012-11-29 05:14

Message:
by bratner : ratner2 at gmail.com

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

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


From noreply at sourceforge.net  Thu Nov 29 14:26:18 2012
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 29 Nov 2012 05:26:18 -0800
Subject: [OpenSIPS-Devel] [ opensips-Patches-3591017 ] Remove headers by
	wildcard
Message-ID: <mailman.1251.1354195587.13469.devel@lists.opensips.org>

Patches item #3591017, was opened at 2012-11-29 05:13
Message generated for change (Comment added) made by 
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086412&aid=3591017&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: https://www.google.com/accounts ()
Assigned to: Nobody/Anonymous (nobody)
Summary: Remove headers by wildcard

Initial Comment:
changes sipmsgops.c.
uses fnmatch() to remove headers by wildcard. 
usage example:
remove_hf_wc("P-hint*");  // removes all headers that start with P-hint
remove_hf_wc("*orig-ip*"); //removes all headers that that have orig-ip in their name


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

Comment By: https://www.google.com/accounts ()
Date: 2012-11-29 05:26

Message:
attached a patch agains opensips_1_8 as well as trunk

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

Comment By: https://www.google.com/accounts ()
Date: 2012-11-29 05:14

Message:
by bratner : ratner2 at gmail.com

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

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


From osas at voipembedded.com  Thu Nov 29 15:06:50 2012
From: osas at voipembedded.com (Ovidiu Sas)
Date: Thu, 29 Nov 2012 14:06:50 +0000
Subject: [OpenSIPS-Devel] SF.net SVN: opensips:[9459]
	branches/1.8/modules/mi_http/http_fnc.c
Message-ID: <E1Te4lO-00080k-DB@sfp-svn-1.v30.ch3.sourceforge.com>

Revision: 9459
          http://opensips.svn.sourceforge.net/opensips/?rev=9459&view=rev
Author:   osas
Date:     2012-11-29 14:06:49 +0000 (Thu, 29 Nov 2012)
Log Message:
-----------
mi_http: fix a few memory leaks
 - related to bug  #3590411
 - backport from trunk: rev 9455

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

Modified Paths:
--------------
    branches/1.8/modules/mi_http/http_fnc.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 Nov 29 15:09:27 2012
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 29 Nov 2012 06:09:27 -0800
Subject: [OpenSIPS-Devel] [ opensips-Bugs-3590411 ] HTTP_MI memory leak
Message-ID: <mailman.1252.1354198178.13469.devel@lists.opensips.org>

Bugs item #3590411, was opened at 2012-11-27 09:59
Message generated for change (Comment added) made by osas
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=3590411&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.8.x
>Status: Closed
>Resolution: Fixed
Priority: 5
Private: No
Submitted By: Digipigeon (digipigeon)
Assigned to: Ovidiu Sas (osas)
Summary: HTTP_MI memory leak

Initial Comment:
There appears to be a memory leak in the http_mi module, Opensips 1.8.2.

When package memory is set to 4MB the memory leak becomes apparent after a few hours.

When the package memory is set to 64MB after a few days.

The HTTP Requests begin to fail with Error 500 and the log shows "ERROR:core:init_mi_tree: no more pkg mem".

This has only started to happen after switching from xmlrpc to mi_http.

Regards Jonathan

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

>Comment By: Ovidiu Sas (osas)
Date: 2012-11-29 06:09

Message:
Fixed on Revision: 9459.
Please re-open if still an issue.

Regards,
Ovidiu Sas


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

Comment By: Digipigeon (digipigeon)
Date: 2012-11-29 02:05

Message:
I have tested the patched version vs the unpatched version for about 24
hours now.

The patched version does not exhibit the original problem, however I will
let this continue to run for a few more days and update you further.

Regards Jonathan

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

Comment By: Ovidiu Sas (osas)
Date: 2012-11-27 12:48

Message:
Hello Jonathan,

I committed a fix in trunk.
Can you test it and let me know the results?

Thanks,
Ovidiu

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

Comment By: Ovidiu Sas (osas)
Date: 2012-11-27 10:16

Message:
Hello Jonathan,

Do you run a particular set of commands?
Can you post the HTTP requests that you are using?
How many HTTP requests do you run per minute?

Thanks,
Ovidiu

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

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


From razvan at opensips.org  Thu Nov 29 16:04:07 2012
From: razvan at opensips.org (Razvan Crainea)
Date: Thu, 29 Nov 2012 15:04:07 +0000
Subject: [OpenSIPS-Devel] SF.net SVN: opensips:[9460] trunk/modules/options
Message-ID: <E1Te5ep-000246-Mg@sfp-svn-3.v30.ch3.sourceforge.com>

Revision: 9460
          http://opensips.svn.sourceforge.net/opensips/?rev=9460&view=rev
Author:   razvancrainea
Date:     2012-11-29 15:04:07 +0000 (Thu, 29 Nov 2012)
Log Message:
-----------
Improved the performance of options module by building the reply headers only
once, at startup. Also, if the header's value is empty, the header itself
makes no sense.

Modified Paths:
--------------
    trunk/modules/options/doc/options_admin.xml
    trunk/modules/options/mod_options.c
    trunk/modules/options/mod_options.h

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



From jchavanton at gmail.com  Thu Nov 29 17:56:16 2012
From: jchavanton at gmail.com (Julien Chavanton)
Date: Thu, 29 Nov 2012 17:56:16 +0100
Subject: [OpenSIPS-Devel] Opensips Cassandra module support for failover
	between servers
Message-ID: <CAKmcL2=C62+_oO0nUJEHXJoohDbTPWBD2vLAoLNjRBg=kARs1A@mail.gmail.com>

Hi,

It seems it would be nice to implement support for failover between servers
in the Cassandra module.

If one server is timing out the module would start using the next one in
the "group" and save the state of the server.

This way we do not have to implement DNS failover, virtual IP, or  complex
Opensips routing logic.

There is not plan to implement this right now ?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/devel/attachments/20121129/a9a5e706/attachment-0001.htm>

From noreply at sourceforge.net  Thu Nov 29 18:30:08 2012
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 29 Nov 2012 09:30:08 -0800
Subject: [OpenSIPS-Devel] [ opensips-Bugs-3590418 ] MI DATAGRAM specific
	commands fail
Message-ID: <mailman.1253.1354210221.13469.devel@lists.opensips.org>

Bugs item #3590418, was opened at 2012-11-27 10:57
Message generated for change (Comment added) made by digipigeon
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=3590418&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.8.x
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Digipigeon (digipigeon)
Assigned to: Nobody/Anonymous (nobody)
Summary: MI DATAGRAM specific commands fail

Initial Comment:
Using 1.8.2, applying a different connector to my existing mi methods the following commands that I have issued work over ALL XMLRPC, FIFO, MI_HTTP & MI_DATAGRAM

version - WORKS ALL
uptime - WORKS ALL

However the following commands work on XMLRPC, FIFO, MI_HTTP but FAIL on MI_DATAGRAM 

All Passed with no arguments

dr_gw_status - FAILS ON MI_DATAGRAM
debug - FAILS ON MI_DATAGRAM

Regards Jonathan

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

>Comment By: Digipigeon (digipigeon)
Date: 2012-11-29 09:30

Message:
Here are two examples for the following commands with full debug enabled:

Example with "debug"

Nov 29 17:21:54 gluino /usr/sbin/opensips[15307]:
DBG:mi_datagram:mi_datagram_server: received :debug:#012
Nov 29 17:21:54 gluino /usr/sbin/opensips[15307]:
DBG:mi_datagram:mi_datagram_server: mi_buf is :debug:#012 and we have
received 8 bytes
Nov 29 17:21:54 gluino /usr/sbin/opensips[15307]:
DBG:mi_datagram:identify_command: the command starts here: debug:#012
Nov 29 17:21:54 gluino /usr/sbin/opensips[15307]:
DBG:mi_datagram:identify_command: the command is debug
Nov 29 17:21:54 gluino /usr/sbin/opensips[15307]:
DBG:mi_datagram:identify_command: dtgram->len is 8
Nov 29 17:21:54 gluino /usr/sbin/opensips[15307]:
DBG:mi_datagram:identify_command: dtgram->len is 0
Nov 29 17:21:54 gluino /usr/sbin/opensips[15307]:
DBG:mi_datagram:mi_datagram_server: we have a valid command
Nov 29 17:21:54 gluino /usr/sbin/opensips[15307]:
DBG:mi_datagram:mi_datagram_server: after identifing the command, the
received datagram is
Nov 29 17:21:54 gluino /usr/sbin/opensips[15307]:
DBG:mi_datagram:mi_datagram_server: parsing the command's params
Nov 29 17:21:54 gluino /usr/sbin/opensips[15307]:
ERROR:mi_datagram:mi_datagram_parse_tree: no data in the datagram
Nov 29 17:21:54 gluino /usr/sbin/opensips[15307]:
ERROR:mi_datagram:mi_datagram_server: failed to parse the MI tree

Example with "dr_gw_status"

Nov 29 17:23:09 gluino /usr/sbin/opensips[15307]:
DBG:mi_datagram:mi_datagram_server: received :dr_gw_status:#012
Nov 29 17:23:09 gluino /usr/sbin/opensips[15307]:
DBG:mi_datagram:mi_datagram_server: mi_buf is :dr_gw_status:#012 and we
have received 15 bytes
Nov 29 17:23:09 gluino /usr/sbin/opensips[15307]:
DBG:mi_datagram:identify_command: the command starts here:
dr_gw_status:#012
Nov 29 17:23:09 gluino /usr/sbin/opensips[15307]:
DBG:mi_datagram:identify_command: the command is dr_gw_status
Nov 29 17:23:09 gluino /usr/sbin/opensips[15307]:
DBG:mi_datagram:identify_command: dtgram->len is 15
Nov 29 17:23:09 gluino /usr/sbin/opensips[15307]:
DBG:mi_datagram:identify_command: dtgram->len is 0
Nov 29 17:23:09 gluino /usr/sbin/opensips[15307]:
DBG:mi_datagram:mi_datagram_server: we have a valid command
Nov 29 17:23:09 gluino /usr/sbin/opensips[15307]:
DBG:mi_datagram:mi_datagram_server: after identifing the command, the
received datagram is
Nov 29 17:23:09 gluino /usr/sbin/opensips[15307]:
DBG:mi_datagram:mi_datagram_server: parsing the command's params
Nov 29 17:23:09 gluino /usr/sbin/opensips[15307]:
ERROR:mi_datagram:mi_datagram_parse_tree: no data in the datagram
Nov 29 17:23:09 gluino /usr/sbin/opensips[15307]:
ERROR:mi_datagram:mi_datagram_server: failed to parse the MI tree
Nov 29 17:23:09 gluino /usr/sbin/opensips[15307]:
DBG:mi_datagram:mi_datagram_server: received :dr_gw_status:#012
Nov 29 17:23:09 gluino /usr/sbin/opensips[15307]:
DBG:mi_datagram:mi_datagram_server: mi_buf is :dr_gw_status:#012 and we
have received 15 bytes


I have also included the working example for "version"
Nov 29 17:25:48 gluino /usr/sbin/opensips[15307]:
DBG:mi_datagram:mi_datagram_server: received :version:#012
Nov 29 17:25:48 gluino /usr/sbin/opensips[15307]:
DBG:mi_datagram:mi_datagram_server: mi_buf is :version:#012 and we have
received 10 bytes
Nov 29 17:25:48 gluino /usr/sbin/opensips[15307]:
DBG:mi_datagram:identify_command: the command starts here: version:#012
Nov 29 17:25:48 gluino /usr/sbin/opensips[15307]:
DBG:mi_datagram:identify_command: the command is version
Nov 29 17:25:48 gluino /usr/sbin/opensips[15307]:
DBG:mi_datagram:identify_command: dtgram->len is 10
Nov 29 17:25:48 gluino /usr/sbin/opensips[15307]:
DBG:mi_datagram:identify_command: dtgram->len is 0
Nov 29 17:25:48 gluino /usr/sbin/opensips[15307]:
DBG:mi_datagram:mi_datagram_server: we have a valid command
Nov 29 17:25:48 gluino /usr/sbin/opensips[15307]:
DBG:mi_datagram:mi_datagram_server: after identifing the command, the
received datagram is
Nov 29 17:25:48 gluino /usr/sbin/opensips[15307]:
DBG:mi_datagram:mi_datagram_server: the command has no params
Nov 29 17:25:48 gluino /usr/sbin/opensips[15307]:
DBG:mi_datagram:mi_datagram_server: done parsing the mi tree
Nov 29 17:25:48 gluino /usr/sbin/opensips[15307]:
DBG:mi_datagram:mi_datagram_server: command process (version)succeded
Nov 29 17:25:48 gluino /usr/sbin/opensips[15307]:
DBG:mi_datagram:mi_datagram_write_node: writing the name <Server> and value
<OpenSIPS (1.8.2-notls (x86_64/linux))>
Nov 29 17:25:48 gluino /usr/sbin/opensips[15307]:
DBG:mi_datagram:mi_datagram_server: the response: 200 OK#012Server::
OpenSIPS (1.8.2-notls (x86_64/linux))#012 has been sent in 54 octets
Nov 29 17:25:48 gluino /usr/sbin/opensips[15308]:
DBG:mi_xmlrpc:default_method: starting up.....
Nov 29 17:25:48 gluino /usr/sbin/opensips[15308]:
DBG:mi_xmlrpc:default_method: done looking the mi command.
Nov 29 17:25:48 gluino /usr/sbin/opensips[15308]:
DBG:mi_xmlrpc:default_method: done parsing the mi tree.
Nov 29 17:25:48 gluino /usr/sbin/opensips[15308]:
DBG:mi_xmlrpc:default_method: done running the mi command.
Nov 29 17:25:48 gluino /usr/sbin/opensips[15308]:
DBG:mi_xmlrpc:default_method: done building response.


Regards Jonathan

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

Comment By: Vladut-Stefan Paiu (vladut-paiu)
Date: 2012-11-28 09:40

Message:
Hello,

Do you see any specific mi_datagram error messages when you trigger the
dr_gw_status or debug MI commands ? Do those commands fail all the time, or
randomly fail ?

Regards,
Vlad

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

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


From binanalhalabi at yahoo.com  Fri Nov  2 02:43:48 2012
From: binanalhalabi at yahoo.com (Binan AL Halabi)
Date: Fri, 02 Nov 2012 01:43:48 -0000
Subject: [OpenSIPS-Devel] [OpenSIPS-Users] [RELEASES] Planing OpenSIPS
	1.9.0 major release
In-Reply-To: <CALiegfn9-LNiOZgWbxMPwz7Amdqs+d7kgExb7FXQ0Y+U1hZCgw@mail.gmail.com>
References: <508AAA59.7070107@opensips.org>
	<CAND0Lkt5HBOga5+P7WWC2oh5XFtQAw03YKdMwCEi+gtd-kdVzw@mail.gmail.com>
	<CAFcM1Eq7VnxNmNJx5AEnt=oCkEnu9+t_yZ0Aoy05wi+f4a8ULg@mail.gmail.com>
	<B5527242-3B09-4E3E-9C18-C42D7A080760@ag-projects.com>
	<CA+q4kR+G4O8F3ZanE1m+Rw+T-55qr3rwGohS0iO19C+3SJn2VA@mail.gmail.com>
	<508E59E1.9050206@opensips.org>
	<3E4434C0-F580-47DE-8450-8F968C629D70@ag-projects.com>
	<509110FE.7010106@opensips.org>
	<8B3FCB90-4065-439B-A7E2-857F74C237AC@ag-projects.com>
	<CA+q4kR+80_=wgzymDLoTY4y0sK2Ypz5QTLpq2zgfBq3gVRj2Jg@mail.gmail.com>
	<CALiegf=jRfmcaT9-G-sBH0gE028G2jEQUPaNnwk5LxbNPqr1SA@mail.gmail.com>
	<50925120.4040008@opensips.org>
	<CALiegfn9-LNiOZgWbxMPwz7Amdqs+d7kgExb7FXQ0Y+U1hZCgw@mail.gmail.com>
Message-ID: <1351820619.2124.YahooMailNeo@web122602.mail.ne1.yahoo.com>



Hi All,

If oversip uses Path extension OpenSIPS must support it.

1- Sending Path header values in 200 ok REGISTER response 
2- Path header files syntax must confom to Route syntax
3- When look up the opensips must copies the stored path header fileds into Route header fileds - preloaded route. 
Reference: RFC 3327 ? 


Here
 i think adding one Route header pointing to OverSIP (second Path URI) 
is enough in simple case (UA ---- OverSIP--- OpenSIPS).
OverSIP removes the Route header and route the request based on RURI (first Path URI).? 
?


OpenSIPs support this http://www.opensips.org/html/docs/modules/devel/registrar.html#id248705? 
flag "px" (path support) of save function in Registrar module.

So still parsing VIA header is required to add WS and WSS. I think this patch is already posted.


Binan.




________________________________
 Fr?n: I?aki Baz Castillo <ibc at aliax.net>
Till: Bogdan-Andrei Iancu <bogdan at opensips.org> 
Kopia: OpenSIPS users mailling list <users at lists.opensips.org> 
Skickat: torsdag, 1 november 2012 20:36
?mne: Re: [OpenSIPS-Users] [OpenSIPS-Devel] [RELEASES] Planing OpenSIPS 1.9.0 major release
 
2012/11/1 Bogdan-Andrei Iancu <bogdan at opensips.org>
>
> Hi Inaki,
>
> Please correct me if I'm wrong, but reading the draft and listing you guys all, I would say the right approach is to : (1) use OverSIP as gw (to extract SIP traffic from WebSocket) and (2) make OpenSIPS to support SIP traffic resulted from websocket extraction.
>
> If so, OpenSIPS has nothing to do with the WebSocket protocol itself, but only to support the extensions from the draft (like new protocols and eventually the SIP server location).

Right. As Saul pointed out, this scenario (which is a pure RFC 5626
"Outbound" scenario with a Edge Proxy in front of the
registrar/authentication-proxy) requires:

- Path support in OpenSIPS for storing the Path URI(s). Note: It's
important to increase the "path" column size in the location table.
The current value is to small and cannot store two URI's (OverSIP adds
double Path headers).

- OpenSIPS should improve the parser of the Via transport field since
currently it only accepts UDP, TCP, TLS and SCTP. It should also
accept WS and WSS, but better if it accepts any token (as the RFC 3261
BNF grammar states). Otherwise OpenSIPS will discard SIP requests
coming from OverSIP (since the non top Via header, that created by the
SIP WebSocket client, has "WS" as transport protocol).

And nothing else at all, but the above two points are important.

Regards.





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

_______________________________________________
Users mailing list
Users at lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/devel/attachments/20121102/a80225d6/attachment.htm>

From brett at nemeroff.com  Sun Nov 25 16:32:10 2012
From: brett at nemeroff.com (Brett Nemeroff)
Date: Sun, 25 Nov 2012 09:32:10 -0600
Subject: [OpenSIPS-Devel] [OpenSIPS-Users] [RFC] New Release Policy for
	OpenSIPS project
In-Reply-To: <50ADFFBC.800@opensips.org>
References: <50ADFFBC.800@opensips.org>
Message-ID: <CAPwC5wzu+iZhf+r7U6pKf2zMnx+5ew50-DmYPq3LkVJxmWXcBw@mail.gmail.com>

On Thu, Nov 22, 2012 at 4:34 AM, Bogdan-Andrei Iancu <bogdan at opensips.org>wrote:

> **
>
> Release cycles
> ===============
>     - instead of a feature driven release cycle, I would prefer a time
> driven release cycle - because it is more predictable and being feature
> driven may actually escalate the time to the next release (the snowball
> effect) - see the timing for 1.7, 1.8 versions
>     - have a 5-7 months release cycle (depending on the required volume of
> work)
>     - smaller steps in releases will be more friendly to users as there
> are no big gaps between releases, easier and more appealing to upgrade ;
> also shorter release cycles will make new features available in stable
> versions much faster.
>
>

 Just my two cents here...

With regards to the release cycle... I typically find myself doing
"production" deployments for my clients. What I need is a stable version.
And then hotfixes as bugs are discovered.

I prefer feature driven releases because I can look forward to when feature
X will be available. My production deployments typically run untouched
while in production mode. Upgrades occur when new features are needed AND
available in stable builds. I don't typically upgrade simply because an
upgrade is available. Of course, I'll normally upgrade for critical fixes
or security fixes (which I'd see as a hotfix typically and not a full
release)

If I knew a release was going to be available on a particular date, I would
without question start reviewing that release and it's new capabilities;
but I wouldn't need it for a production build.

If I knew a feature was available on a certain date, I could pitch that to
my clients if it was a feature they might need. Also, I'm afraid that time
based releases may rush features out before they are ready.

That's just my perspective based on my workflow. I'm sure there are others
that feel differently. :)
-Brett
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/devel/attachments/20121125/7a0896e3/attachment-0001.htm>

From brett at nemeroff.com  Wed Nov 28 17:55:16 2012
From: brett at nemeroff.com (Brett Nemeroff)
Date: Wed, 28 Nov 2012 10:55:16 -0600
Subject: [OpenSIPS-Devel] [OpenSIPS-Users] [NEW] OpenSIPS script locks
In-Reply-To: <50B6277F.8020201@opensips.org>
References: <50B620B7.8040205@opensips.org> <50B6277F.8020201@opensips.org>
Message-ID: <CAPwC5wxR2FgnMwaQ6xjhyiOEL=1a6GPuucSYcUgKpoh7bhqv9g@mail.gmail.com>

Liviu,
This is a good idea. What happens to the child process as it's waiting for
a lock to be released? Are there any protections against locks lasting
indefinitely?

Thanks,
Brett


On Wed, Nov 28, 2012 at 9:02 AM, Liviu Chircu <liviu at opensips.org> wrote:

>
> The cfgutils module now provides the possibility of defining atomic
> test-and-set operations in the OpenSIPS script.
> Such need is a result of complex mixing in script of various
> functionality / functions from different modules. Like testing
> is done based on ratelimit module and the setting is done in
> dialog module.
>
> Modules do provide internal locking and synchronization for their
> own functionalities, but cannot cover a more complex and various
> scenarios of test-and-set scripting scenarios.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/devel/attachments/20121128/3c83770b/attachment-0001.htm>

From bogdan at opensips.org  Thu Nov 29 19:13:54 2012
From: bogdan at opensips.org (Bogdan-Andrei Iancu)
Date: Thu, 29 Nov 2012 20:13:54 +0200
Subject: [OpenSIPS-Devel] [OpenSIPS-Users] [RFC] New Release Policy for
	OpenSIPS project
In-Reply-To: <C46E70EB-F392-4EB5-84FA-0643B313F447@ag-projects.com>
References: <50ADFFBC.800@opensips.org>
	<8FDA43EA-EFAD-4B95-AD48-C83422A176F1@ag-projects.com>
	<50AE2721.9090701@opensips.org>
	<C46E70EB-F392-4EB5-84FA-0643B313F447@ag-projects.com>
Message-ID: <50B7A5E2.9050303@opensips.org>

Hi Saul,

On 11/23/2012 11:36 AM, Sa?l Ibarra Corretg? wrote:
> Hi,
>
>> The problem I see with the features-based release cycle is that they are unpredictable as time - some features may not be properly (or impossible) time evaluated ->  it may stretch the interval between releases ; IMHO, for a project to reliable it is a must to be predictable. The best examples are what is happening now with OpenSIPS (the interval between releases is keep growing) and Debian (lack of predictability and huge intervals between release ended up in the Ubuntu alternative).
>> Being able to predict the releases (as time) without huge differences between versions (to make an upgrade something easy you are not scared like hell to do it) should be some key-feature of the project.
>>
>> The time-based releases should not be affected by how long a feature takes to be implemented - 6 months of development for a feature is really more than enough, IMHO.
>>
> I agree that is good for bugfix releases. However, when planning the next release (lets say 1.10) I guess you'd plan what features are to be implemented. Then of course time needs to be weighted in the equation, but IMHO the time constraint should be a bit more loose for major releases.
[bogdan]
copying from another answer of mine: Keep in mind that all the time a 
new release will be a set of new features, so basically all releases are 
also featured driven. But to make it more predictable, we consider some 
time limits (for a release cycle) - limits are quite large 5 to 7 
months, so we have flexibility to fit various sets of features in that 
interval. The main idea with time-based cycles is to try to control how 
long will take for have the next release (more predictable, without 
large gaps between releases) and also to speed up the features delivery 
(having a faster cycle, features will be available in stable versions 
quicker).
>
> What about security fixes? I can understand that when 1.9 is released 1.7 goes to EOL (sort of), but what if there is a bug in the parser (for example) which can cause a crash just by using a stupid script? IMHO there should be a security-fixes-only period, since migrating to a new OpenSIPS version is not  a task to be taken lightly.
>> [bogdan]
>> That is true problem that may have as solutions:
>>     1) simply upgrade (most common way to go in open source world) , considering that upgrades should become easier.
> New versions have new features and new bugs. So updating may get you trouble for little gain, in case you are not using any of the new stuff.
>
>>     2) try to define what is really critical (based on what??) and still do backporting - but at the end of the day we need to encourage people to use the new versions - keep patching and supporting really old versions (consider 1.6 at this point) is a waist of effort. Taking your example: debian is not supporting something older than 1 release :D....
>>
> Not 100% accurate: -) "The security team tries to support a stable distribution for about one year after the next stable distribution has been released". So Debian "oldstable" still gets security updates a year after "stable" has been out.
>
> We can try to see how a similar approach can work out for us. Instead of a year, say 6 months. What's important is to define what a security fix is and what it's not. An error in the software that can be consistently triggered from the outside (ie, with SIP traffic) and cause any kind of outage could be considered a security fix. This is from the top of my head, it would need to be refined :-)
[bogdan]
again, copying from another answer of mine: I have to admit I didn't do 
the math - 2 release ~= 1 year, which indeed is too short - I mean this 
will force an upgrade each year. So, we need to somehow get to ~ 2 year 
lifetime for a release. My suggestion is to actually set a life span for 
2 years.


Regards,
Bogdan


From mrvinaymistry at gmail.com  Thu Nov 29 20:29:20 2012
From: mrvinaymistry at gmail.com (Vinay Mistry)
Date: Thu, 29 Nov 2012 19:29:20 +0000
Subject: [OpenSIPS-Devel] Sylk-server startup error No module named
	application
Message-ID: <CAGXRDbg_XqrnkkMhq+nSP6O7KgWbS96TQTbu_FdNFdME-SPDQg@mail.gmail.com>

Hi,
Im fairly new to Sylkserver so apologies if im asking a daft question.

When trying to start sylkserver with the following,
./sylk-server --no-fork

I get the following error, any ideas what "application" actually refers to?
Traceback (most recent call last):
  File "./sylk-server", line 12, in <module>
    from application import log
ImportError: No module named application
Thanks in advance,
Vinay
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/devel/attachments/20121129/0096a610/attachment.htm>

From saul at ag-projects.com  Thu Nov 29 22:43:57 2012
From: saul at ag-projects.com (=?iso-8859-1?Q?Sa=FAl_Ibarra_Corretg=E9?=)
Date: Thu, 29 Nov 2012 22:43:57 +0100
Subject: [OpenSIPS-Devel] Sylk-server startup error No module named
	application
In-Reply-To: <CAGXRDbg_XqrnkkMhq+nSP6O7KgWbS96TQTbu_FdNFdME-SPDQg@mail.gmail.com>
References: <CAGXRDbg_XqrnkkMhq+nSP6O7KgWbS96TQTbu_FdNFdME-SPDQg@mail.gmail.com>
Message-ID: <27851A08-89DC-4B7B-B9BB-D99ACDE74A00@ag-projects.com>


On Nov 29, 2012, at 8:29 PM, Vinay Mistry wrote:

> Hi,
> Im fairly new to Sylkserver so apologies if im asking a daft question.
>  
> When trying to start sylkserver with the following,
> ./sylk-server --no-fork
>  
> I get the following error, any ideas what "application" actually refers to?
> Traceback (most recent call last):
>   File "./sylk-server", line 12, in <module>
>     from application import log
> ImportError: No module named application
> Thanks in advance,

Apparently you didn't install python-application. Check the dependencies.

Btw, the appropriate place for questions bout SylkServer is the SIP Beyond VoIP mailing list: http://lists.ag-projects.com/mailman/listinfo/sipbeyondvoip

Regards,

--
Sa?l Ibarra Corretg?
AG Projects





From saul at ag-projects.com  Thu Nov 29 22:47:23 2012
From: saul at ag-projects.com (=?iso-8859-1?Q?Sa=FAl_Ibarra_Corretg=E9?=)
Date: Thu, 29 Nov 2012 22:47:23 +0100
Subject: [OpenSIPS-Devel] [OpenSIPS-Users] [RFC] New Release Policy for
	OpenSIPS project
In-Reply-To: <50B7A5E2.9050303@opensips.org>
References: <50ADFFBC.800@opensips.org>
	<8FDA43EA-EFAD-4B95-AD48-C83422A176F1@ag-projects.com>
	<50AE2721.9090701@opensips.org>
	<C46E70EB-F392-4EB5-84FA-0643B313F447@ag-projects.com>
	<50B7A5E2.9050303@opensips.org>
Message-ID: <8EA9E97B-5708-4012-99E8-F36F9B24AD82@ag-projects.com>

Hi Bogdan,

> copying from another answer of mine: Keep in mind that all the time a new release will be a set of new features, so basically all releases are also featured driven. But to make it more predictable, we consider some time limits (for a release cycle) - limits are quite large 5 to 7 months, so we have flexibility to fit various sets of features in that interval. The main idea with time-based cycles is to try to control how long will take for have the next release (more predictable, without large gaps between releases) and also to speed up the features delivery (having a faster cycle, features will be available in stable versions quicker).

Ok, so it's more of a hybrid thing. In that case I'd be k with it, if we allow for some flexibility in case we were a bit too optimistic with the planning ;-)

[snip]

> 
> again, copying from another answer of mine: I have to admit I didn't do the math - 2 release ~= 1 year, which indeed is too short - I mean this will force an upgrade each year. So, we need to somehow get to ~ 2 year lifetime for a release. My suggestion is to actually set a life span for 2 years.
> 

2 years sounds about right.

Thanks for doing this in the Open, Bogdan :-)

Kind regards,

--
Sa?l Ibarra Corretg?
AG Projects





From razvan at opensips.org  Fri Nov 30 10:24:50 2012
From: razvan at opensips.org (Razvan Crainea)
Date: Fri, 30 Nov 2012 09:24:50 +0000
Subject: [OpenSIPS-Devel] SF.net SVN: opensips:[9461] trunk/modules/rtpproxy
Message-ID: <E1TeMq2-00074O-FR@sfp-svn-1.v30.ch3.sourceforge.com>

Revision: 9461
          http://opensips.svn.sourceforge.net/opensips/?rev=9461&view=rev
Author:   razvancrainea
Date:     2012-11-30 09:24:50 +0000 (Fri, 30 Nov 2012)
Log Message:
-----------
* On some Solaris systems, the iov maximum buffers number is 16. However
rtpproxy tries to send more, therefore the communication fails. This fix
prevents these cases by concatenating the last buffers.
 Credits go to Nathaniel L Keeling III for reporting and providing testing
environment

* added -n flag in documentation

Modified Paths:
--------------
    trunk/modules/rtpproxy/doc/rtpproxy_admin.xml
    trunk/modules/rtpproxy/rtpproxy.c

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



From razvan at opensips.org  Fri Nov 30 10:26:03 2012
From: razvan at opensips.org (Razvan Crainea)
Date: Fri, 30 Nov 2012 09:26:03 +0000
Subject: [OpenSIPS-Devel] SF.net SVN: opensips:[9462]
	branches/1.8/modules/rtpproxy
Message-ID: <E1TeMrD-0007AL-PZ@sfp-svn-1.v30.ch3.sourceforge.com>

Revision: 9462
          http://opensips.svn.sourceforge.net/opensips/?rev=9462&view=rev
Author:   razvancrainea
Date:     2012-11-30 09:26:03 +0000 (Fri, 30 Nov 2012)
Log Message:
-----------
Backporting from trunk (rev# 9461):
* On some Solaris systems, the iov maximum buffers number is 16. However
rtpproxy tries to send more, therefore the communication fails. This fix
prevents these cases by concatenating the last buffers.
 Credits go to Nathaniel L Keeling III for reporting and providing testing
environment

* added -n flag in documentation

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

Modified Paths:
--------------
    branches/1.8/modules/rtpproxy/doc/rtpproxy_admin.xml
    branches/1.8/modules/rtpproxy/rtpproxy.c

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



From razvan at opensips.org  Fri Nov 30 10:26:20 2012
From: razvan at opensips.org (Razvan Crainea)
Date: Fri, 30 Nov 2012 09:26:20 +0000
Subject: [OpenSIPS-Devel] SF.net SVN: opensips:[9463]
	branches/1.7/modules/rtpproxy
Message-ID: <E1TeMrU-0007Ao-Iq@sfp-svn-1.v30.ch3.sourceforge.com>

Revision: 9463
          http://opensips.svn.sourceforge.net/opensips/?rev=9463&view=rev
Author:   razvancrainea
Date:     2012-11-30 09:26:20 +0000 (Fri, 30 Nov 2012)
Log Message:
-----------
Backporting from trunk (rev# 9461):
* On some Solaris systems, the iov maximum buffers number is 16. However
rtpproxy tries to send more, therefore the communication fails. This fix
prevents these cases by concatenating the last buffers.
 Credits go to Nathaniel L Keeling III for reporting and providing testing
environment

* added -n flag in documentation

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

Modified Paths:
--------------
    branches/1.7/modules/rtpproxy/doc/rtpproxy_admin.xml
    branches/1.7/modules/rtpproxy/rtpproxy.c

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



From bogdan at opensips.org  Fri Nov 30 14:39:57 2012
From: bogdan at opensips.org (Bogdan-Andrei Iancu)
Date: Fri, 30 Nov 2012 15:39:57 +0200
Subject: [OpenSIPS-Devel] [HELP] Advising on GPL license issue
Message-ID: <50B8B72D.3030508@opensips.org>

Hi all,

As I'm not an expert in this, I'm looking for someone to advise on a 
more complex issue regarding GPLv2 license.

Shortly - developing an opensips module that needs to link to a non-GPL 
(and not compatible) library (available for public in binary format, 
with proprietary license).

For details or whatever feel free to contact me offline, not a problem.

Help will be highly appreciate not only be me, but by the project and 
community (as a really nice feature depends on finding a solution here).

Regards,

-- 
Bogdan-Andrei Iancu
OpenSIPS Founder and Developer
http://www.opensips-solutions.com



From noreply at sourceforge.net  Fri Nov 30 14:48:39 2012
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 30 Nov 2012 05:48:39 -0800
Subject: [OpenSIPS-Devel] [ opensips-Bugs-3590667 ] ACC not logging BYE on
	random calls
Message-ID: <mailman.1254.1354283329.13469.devel@lists.opensips.org>

Bugs item #3590667, was opened at 2012-11-28 04:30
Message generated for change (Comment added) made by 
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=3590667&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.8.x
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Daniel ()
Assigned to: Vladut-Stefan Paiu (vladut-paiu)
Summary: ACC not logging BYE on random calls

Initial Comment:
Hi

I built a billing system using Opensips. The logic was to log on a mysql table "acc" all INVITEs and BYEs to be removed later. Then within a few seconds, a console would search for BYEs and related INVITES, calculate duration and price, write on the final table and erase those 2 records from this table.
After some time running, I checked that randomly calls, ACC wrote to DB just the INVITEs and not the BYEs. Checked on syslog and happened the same. I got this:

sbin/opensips[2024]: ACC: transaction answered: timestamp=1353582441;method=INVITE;from_tag=as6c53d5bd;to_tag=1c431879610;call_id=c1434b259b666c921e0c67752f09c01 at 2.2.2.2:5060;code=200;reason=OK

But not the "BYE" message.

This seems to be a bug on ACC module because it doesn?t write the data to Mysql neither to syslog, and also doesn't generate any error on syslog.

To make sure that my problem was on the module and not in my logic, I removed almost all functionality of my Opensips and let just the call routing and ACC module... It reduced the problem but still happens on some situations, from 0.5% to 5% of all calls, randomly.

To temporary solve my problem, i forced INSERT on DB using avp_db_query on loose_route function. On 95% calls it generate a duplicated BYE on my table but my algorithm discard these additional BYEs, so it?s fine for now.

I believe this is an urgent issue since it affects the billing system of almost everyone using opensips.

How can I debug this issue?

Thanks


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

>Comment By: Daniel ()
Date: 2012-11-30 05:48

Message:
Hi Vlad
Sorry, didn't see your comment earlier.

For testing purpose, i set the db_flag on the first line of the script and
ACC also didn't write it to the DB... I was thinking if the dialogic wasn't
created but, not sure.

I'll set log on everything and try get the full log.

In the mean time, please check my first post about this issue:
https://sourceforge.net/projects/opensips/forums/forum/839860/topic/6253903

Thanks



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

Comment By: Vladut-Stefan Paiu (vladut-paiu)
Date: 2012-11-28 09:35

Message:
Hello,

So you cannot replicate this scenario ?
Are you sure that the BYEs that are not accounted for are ok from SIP and
Dialog point of view ? Perhaps they have no route headers, and thus they do
not enter the scripting logic where you set the accounting flag for the BYE
as well.

Could you try to setup more logging in your script, putting some xlog
messages for BYEs , and then search for the missing BYEs in the log file,
to make sure they are hitting your part of the script ?

Regards,
Vlad

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

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


From noreply at sourceforge.net  Fri Nov 30 14:49:51 2012
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 30 Nov 2012 05:49:51 -0800
Subject: [OpenSIPS-Devel] [ opensips-Bugs-3590667 ] ACC not logging BYE on
	random calls
Message-ID: <mailman.1255.1354283395.13469.devel@lists.opensips.org>

Bugs item #3590667, was opened at 2012-11-28 04:30
Message generated for change (Comment added) made by 
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=3590667&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.8.x
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Daniel ()
Assigned to: Vladut-Stefan Paiu (vladut-paiu)
Summary: ACC not logging BYE on random calls

Initial Comment:
Hi

I built a billing system using Opensips. The logic was to log on a mysql table "acc" all INVITEs and BYEs to be removed later. Then within a few seconds, a console would search for BYEs and related INVITES, calculate duration and price, write on the final table and erase those 2 records from this table.
After some time running, I checked that randomly calls, ACC wrote to DB just the INVITEs and not the BYEs. Checked on syslog and happened the same. I got this:

sbin/opensips[2024]: ACC: transaction answered: timestamp=1353582441;method=INVITE;from_tag=as6c53d5bd;to_tag=1c431879610;call_id=c1434b259b666c921e0c67752f09c01 at 2.2.2.2:5060;code=200;reason=OK

But not the "BYE" message.

This seems to be a bug on ACC module because it doesn?t write the data to Mysql neither to syslog, and also doesn't generate any error on syslog.

To make sure that my problem was on the module and not in my logic, I removed almost all functionality of my Opensips and let just the call routing and ACC module... It reduced the problem but still happens on some situations, from 0.5% to 5% of all calls, randomly.

To temporary solve my problem, i forced INSERT on DB using avp_db_query on loose_route function. On 95% calls it generate a duplicated BYE on my table but my algorithm discard these additional BYEs, so it?s fine for now.

I believe this is an urgent issue since it affects the billing system of almost everyone using opensips.

How can I debug this issue?

Thanks


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

>Comment By: Daniel ()
Date: 2012-11-30 05:49

Message:
Correcting:
** I was thinking if the dialog wasn't created but, not sure. The INVITE
was accounted.

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

Comment By: Daniel ()
Date: 2012-11-30 05:48

Message:
Hi Vlad
Sorry, didn't see your comment earlier.

For testing purpose, i set the db_flag on the first line of the script and
ACC also didn't write it to the DB... I was thinking if the dialogic wasn't
created but, not sure.

I'll set log on everything and try get the full log.

In the mean time, please check my first post about this issue:
https://sourceforge.net/projects/opensips/forums/forum/839860/topic/6253903

Thanks



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

Comment By: Vladut-Stefan Paiu (vladut-paiu)
Date: 2012-11-28 09:35

Message:
Hello,

So you cannot replicate this scenario ?
Are you sure that the BYEs that are not accounted for are ok from SIP and
Dialog point of view ? Perhaps they have no route headers, and thus they do
not enter the scripting logic where you set the accounting flag for the BYE
as well.

Could you try to setup more logging in your script, putting some xlog
messages for BYEs , and then search for the missing BYEs in the log file,
to make sure they are hitting your part of the script ?

Regards,
Vlad

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

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


From binanalhalabi at yahoo.com  Fri Nov 30 17:24:13 2012
From: binanalhalabi at yahoo.com (Binan AL Halabi)
Date: Fri, 30 Nov 2012 08:24:13 -0800 (PST)
Subject: [OpenSIPS-Devel] [HELP] Advising on GPL license issue
In-Reply-To: <50B8B72D.3030508@opensips.org>
References: <50B8B72D.3030508@opensips.org>
Message-ID: <1354292653.97258.YahooMailNeo@web122602.mail.ne1.yahoo.com>

Hi Bogdan,
See this : "GPL-incompatible libraries with GPL software"
http://www.gnu.org/licenses/gpl-faq.html#GPLIncompatibleLibs

// Binan


________________________________
 Fr?n: Bogdan-Andrei Iancu <bogdan at opensips.org>
Till: "users at lists.opensips.org" <users at lists.opensips.org>; "devel at lists.opensips.org" <devel at lists.opensips.org> 
Skickat: fredag, 30 november 2012 14:39
?mne: [OpenSIPS-Devel] [HELP] Advising on GPL license issue
 
Hi all,

As I'm not an expert in this, I'm looking for someone to advise on a more complex issue regarding GPLv2 license.

Shortly - developing an opensips module that needs to link to a non-GPL (and not compatible) library (available for public in binary format, with proprietary license).

For details or whatever feel free to contact me offline, not a problem.

Help will be highly appreciate not only be me, but by the project and community (as a really nice feature depends on finding a solution here).

Regards,

-- Bogdan-Andrei Iancu
OpenSIPS Founder and Developer
http://www.opensips-solutions.com


_______________________________________________
Devel mailing list
Devel at lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/devel/attachments/20121130/18f86a26/attachment.htm>

From rrb3942 at gmail.com  Fri Nov 30 18:24:13 2012
From: rrb3942 at gmail.com (Ryan Bullock)
Date: Fri, 30 Nov 2012 09:24:13 -0800
Subject: [OpenSIPS-Devel] [OpenSIPS-Users] [RFC] New Release Policy for
 OpenSIPS project
In-Reply-To: <50B3E5C9.7010006@opensips.org>
References: <50ADFFBC.800@opensips.org>
	<8FDA43EA-EFAD-4B95-AD48-C83422A176F1@ag-projects.com>
	<50AE2721.9090701@opensips.org>
	<C46E70EB-F392-4EB5-84FA-0643B313F447@ag-projects.com>
	<CA+q4kRJ_MuWBwEpJop9AcDMhWeiF52bnwgpYVUYG3VQNq24WYQ@mail.gmail.com>
	<50B3E5C9.7010006@opensips.org>
Message-ID: <CAAcj4gV9gY0Z_qXc0GZcTsEySwqRtKpueVJnJzVg6Bd7HiZANQ@mail.gmail.com>

On Mon, Nov 26, 2012 at 1:57 PM, Bogdan-Andrei Iancu <bogdan at opensips.org>wrote:

> **
> Hi Ali,
>
> Thanks for feedback - regarding the support for previous releases, Saul
> raised the same point as you, and I have to admit I didn't do the math - 2
> release ~= 1 year, which indeed is too short - I mean this will force an
> upgrade each year.
>
> So, we need to somehow get to ~ 2 year lifetime for a release. My
> suggestion is to actually set a life span for 2 years.
>
> Regards,
>
> Bogdan-Andrei Iancu
> OpenSIPS Founder and Developerhttp://www.opensips-solutions.com
>
> What about adding a long term support branch that is released every two
years and supported for 2 years, and then a release every 6 months for
'standard' releases. Each standard release would be supported for 1 year.

Something like this, assuming 1.10 is the first long term support:
1.10 - Long term support (2 years)
1.11 - Standard release (1 year)
1.12 - Standard release (1 year)
1.13 - Standard release (1 year)
1.14 - Long term support (2 years)

Those wanting new features can go for the standard releases, and those
looking for stability and better support can stick with the long term
support releases. It should strike a decent balance between getting
features out the door and support.

Just a thought.

Regards,

Ryan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/devel/attachments/20121130/ce79f347/attachment.htm>

From vladpaiu at opensips.org  Fri Nov 30 19:20:24 2012
From: vladpaiu at opensips.org (Vlad Paiu)
Date: Fri, 30 Nov 2012 18:20:24 +0000
Subject: [OpenSIPS-Devel] SF.net SVN: opensips:[9464]
 trunk/modules/cachedb_redis/cachedb_redis_dbase .c
Message-ID: <E1TeVCK-0006vB-Fh@sfp-svn-4.v30.ch3.sourceforge.com>

Revision: 9464
          http://opensips.svn.sourceforge.net/opensips/?rev=9464&view=rev
Author:   vladut-paiu
Date:     2012-11-30 18:20:24 +0000 (Fri, 30 Nov 2012)
Log Message:
-----------
fixed mem leak on Redis reconnection

Modified Paths:
--------------
    trunk/modules/cachedb_redis/cachedb_redis_dbase.c

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



From vladpaiu at opensips.org  Fri Nov 30 19:22:17 2012
From: vladpaiu at opensips.org (Vlad Paiu)
Date: Fri, 30 Nov 2012 18:22:17 +0000
Subject: [OpenSIPS-Devel] SF.net SVN: opensips:[9465]
 branches/1.8/modules/cachedb_redis/ cachedb_redis_dbase.c
Message-ID: <E1TeVE9-0007Do-Ks@sfp-svn-4.v30.ch3.sourceforge.com>

Revision: 9465
          http://opensips.svn.sourceforge.net/opensips/?rev=9465&view=rev
Author:   vladut-paiu
Date:     2012-11-30 18:22:17 +0000 (Fri, 30 Nov 2012)
Log Message:
-----------
backport from trunk (rev #9464)

fixed mem leak on Redis reconnection

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

Modified Paths:
--------------
    branches/1.8/modules/cachedb_redis/cachedb_redis_dbase.c

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



From noreply at sourceforge.net  Fri Nov 30 19:41:48 2012
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 30 Nov 2012 10:41:48 -0800
Subject: [OpenSIPS-Devel] [ opensips-Bugs-3591427 ] 'osipsconsole add
	'command fails
Message-ID: <mailman.1256.1354300913.13469.devel@lists.opensips.org>

Bugs item #3591427, was opened at 2012-11-30 10:41
Message generated for change (Tracker Item Submitted) made by bogdan_iancu
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=3591427&group_id=232389

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: tools
Group: 1.6.x
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Bogdan-Andrei Iancu (bogdan_iancu)
Assigned to: Nobody/Anonymous (nobody)
Summary: 'osipsconsole add 'command fails

Initial Comment:
I try to execute following command on the command-line from the "OpenSIPS 1.6" manual" 
   osipsconsole address add 0 192.168.1.192 255.255.255.0 5060 UDP

but always get following error
  "Retrieving data from table failed. You have an error in your SQL syntax;
check the manual that corresponds to your MySQL server version for the
right syntax to use near 'WHERE ip='192.168.1.192'' at line 1"

I have installed  osipsconsole and the required dependencies as well
  apt-get install libdbi-perl libdbd-mysql-perl libfrontier-rpc-perl  libterm-readline-gnu-perl

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

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


From bogdan at opensips.org  Fri Nov 30 21:13:24 2012
From: bogdan at opensips.org (Bogdan-Andrei Iancu)
Date: Fri, 30 Nov 2012 20:13:24 +0000
Subject: [OpenSIPS-Devel] SF.net SVN: opensips:[9466]
	trunk/modules/b2b_entities/dlg.c
Message-ID: <E1TeWxg-00042C-Ag@sfp-svn-3.v30.ch3.sourceforge.com>

Revision: 9466
          http://opensips.svn.sourceforge.net/opensips/?rev=9466&view=rev
Author:   bogdan_iancu
Date:     2012-11-30 20:13:24 +0000 (Fri, 30 Nov 2012)
Log Message:
-----------
- before using be sure that TO hdr and FROM TAG are present.
  Reported by Nick Altmann
  Closes bug #3589142

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 bogdan at opensips.org  Fri Nov 30 21:14:10 2012
From: bogdan at opensips.org (Bogdan-Andrei Iancu)
Date: Fri, 30 Nov 2012 20:14:10 +0000
Subject: [OpenSIPS-Devel] SF.net SVN: opensips:[9467]
	branches/1.8/modules/b2b_entities/dlg.c
Message-ID: <E1TeWyQ-0002HK-K5@sfp-svn-4.v30.ch3.sourceforge.com>

Revision: 9467
          http://opensips.svn.sourceforge.net/opensips/?rev=9467&view=rev
Author:   bogdan_iancu
Date:     2012-11-30 20:14:10 +0000 (Fri, 30 Nov 2012)
Log Message:
-----------
backport from trunk (rev #9466):
- before using be sure that TO hdr and FROM TAG are present.
  Reported by Nick Altmann
  Closes bug #3589142

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

Modified Paths:
--------------
    branches/1.8/modules/b2b_entities/dlg.c

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



From bogdan at opensips.org  Fri Nov 30 21:15:10 2012
From: bogdan at opensips.org (Bogdan-Andrei Iancu)
Date: Fri, 30 Nov 2012 20:15:10 +0000
Subject: [OpenSIPS-Devel] SF.net SVN: opensips:[9468]
	branches/1.7/modules/b2b_entities/dlg.c
Message-ID: <E1TeWzO-0004Ht-Qt@sfp-svn-3.v30.ch3.sourceforge.com>

Revision: 9468
          http://opensips.svn.sourceforge.net/opensips/?rev=9468&view=rev
Author:   bogdan_iancu
Date:     2012-11-30 20:15:10 +0000 (Fri, 30 Nov 2012)
Log Message:
-----------
backport from trunk (rev #9466):
- before using be sure that TO hdr and FROM TAG are present.
  Reported by Nick Altmann
  Closes bug #3589142

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

Modified Paths:
--------------
    branches/1.7/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 Nov 30 21:16:04 2012
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 30 Nov 2012 12:16:04 -0800
Subject: [OpenSIPS-Devel] [ opensips-Bugs-3589142 ] B2B: crash when request
	without from_tag or to header
Message-ID: <mailman.1257.1354306568.13469.devel@lists.opensips.org>

Bugs item #3589142, was opened at 2012-11-22 05:41
Message generated for change (Comment added) made by bogdan_iancu
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=3589142&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: Nick Altmann (nikbyte)
>Assigned to: Bogdan-Andrei Iancu (bogdan_iancu)
Summary: B2B: crash when request without from_tag or to header

Initial Comment:
Sometimes buggy UACs send in-b2b-dialog CANCEL without from_tag.
b2b_entities module crashes in dlg.c on line 645:
hash_index = core_hash(&callid, &from_tag, server_hsize);

because from_tag is empty.


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

>Comment By: Bogdan-Andrei Iancu (bogdan_iancu)
Date: 2012-11-30 12:16

Message:
Hi Nick,

Added the fix on SVN trunk, 1.8 and 1.7 .

Thanks for report,
Bogdan

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

Comment By: Nick Altmann (nikbyte)
Date: 2012-11-25 23:22

Message:
I've tested it again. Any packet without from tag or without to header
crashes opensips!

Patch attached.


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

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


From noreply at sourceforge.net  Fri Nov 30 21:18:30 2012
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 30 Nov 2012 12:18:30 -0800
Subject: [OpenSIPS-Devel] [ opensips-Bugs-3590953 ] Dialog module:
	dlg_terminate_dlg and register_dlgcb function
Message-ID: <mailman.1258.1354306714.13469.devel@lists.opensips.org>

Bugs item #3590953, was opened at 2012-11-29 01:36
Message generated for change (Comment added) made by bogdan_iancu
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=3590953&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: https://www.google.com/accounts ()
Assigned to: Nobody/Anonymous (nobody)
Summary: Dialog module: dlg_terminate_dlg and register_dlgcb function

Initial Comment:
Hello,

On 11/26/12 3:52 PM, Eduardo Lejarreta wrote:
>
> Good evening.
>
>  
>
> I?m a rookie (not a developer), on users mailling list I?ve been forwarded to this. Anyway, this is the case:
>
>  
>
> Dialog, tm, rr and acc: 3.2.1 modules version
>
>  
>
> When you finish externally a dialog, v?a FIFO command with ?dlg_terminate_dlg: callid, from_tag? the callback register function ?register_dlgcb? on ?DLGCB_TERMINATED? event returns a:
>
>  
>
> dlg_cb_params * params->req             with (NIL) value.
the request does not exist in this case, going to be generated locally.

>  
>
> This callback  register function is used by ?acc? module with acc_cdr accounting enabled to track the end of the call.
>
>  
>
> In this scenario acc module can not account the end of the call. -> ERROR: acc [acc_cdr.c:480]: invalid values#012!
>
>  
> If you try this scenario over TCP and with ?RR? module with ?enable_double_rr? enabled you will see that the ?acc? module is able to track the end of the call because a double ?Record-route? header is inserted by proxy.
>  
> Do you think this could be an issue that it can be resolved in future? Or may be we?re forgetting something.
>  
> Any help, any idea?, 
Maybe you can solve it by storing dialog hash and id -- see the $dlg(...) class of variables.

It should be solved in a way or another, to become useful, please open an issue on the tracker not to forget about it. I plan to look a bit at cdr accounting with dialog before the next major release.

Cheers,
Daniel

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

>Comment By: Bogdan-Andrei Iancu (bogdan_iancu)
Date: 2012-11-30 12:18

Message:
Hi Daniel,

What exact version of Opensips do you have ?  you mentioned "Dialog, tm, rr
and acc: 3.2.1 modules version", but there is no 3.2.1 version ...

Regards,
Bogdan

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

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


From noreply at sourceforge.net  Fri Nov 30 21:28:42 2012
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 30 Nov 2012 12:28:42 -0800
Subject: [OpenSIPS-Devel] [ opensips-Bugs-3587163 ] Commit #9295 breaks
	dispatcher
Message-ID: <mailman.1259.1354307326.13469.devel@lists.opensips.org>

Bugs item #3587163, was opened at 2012-11-14 08:43
Message generated for change (Comment added) made by bogdan_iancu
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=3587163&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.8.x
Status: Open
Resolution: Invalid
Priority: 5
Private: No
Submitted By: Dynamic Packet (dpacket)
Assigned to: Bogdan-Andrei Iancu (bogdan_iancu)
Summary: Commit #9295 breaks dispatcher

Initial Comment:
It seems commit #9295 on 1.8 branch breaks AVP in certain cases. Opensips starts fine and some avp related stuff works, but certain scenarios cause this: 

Nov 14 11:13:40 ip-10-173-81-249 /usr/sbin/opensips[1042]: ERROR:core:new_avp: invalid AVP name!
Nov 14 11:13:40 ip-10-173-81-249 /usr/sbin/opensips[1042]: ERROR:core:add_avp: Failed to create new avp structure

Script now does not execute as it should and in the end cause failures in call processing.  Its possible this also effects trunk (commit #9294) . I have tested by reverting this single commit (#9295) in most resent stable 1.8 and issue is resolved.

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

>Comment By: Bogdan-Andrei Iancu (bogdan_iancu)
Date: 2012-11-30 12:28

Message:
I'm not able to reproduce this issue - I tried not to define the attrs_avp
in mod params, but to populate the attrs in DB. There was not error,
neither in ds_select_(), nor in ds_next_dst().

Are you sure your err logs are related to dispatcher module ?  If they are,
the  dispatcher function should return false to script.

If you want, you can privately send me some logs ..or may I get access to
the server where this happens ?

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

Comment By: Dynamic Packet (dpacket)
Date: 2012-11-26 10:53

Message:
I can assure you that SVN checkout of 1.8 as of 2012-11-14 did not solve
the problem for me. Was the fix committed after this? Otherwise, perhaps
its not working in some case(s) ?

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

Comment By: Bogdan-Andrei Iancu (bogdan_iancu)
Date: 2012-11-22 06:04

Message:
I checked the code (trunk + 1,8) and I see the fix there. Are you sure you
are using the latest 1.8 version ? maybe you do not have the fix in your
checkout.

Regards,
Bogdan

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

Comment By: Bogdan-Andrei Iancu (bogdan_iancu)
Date: 2012-11-21 08:39

Message:
I remember fixing this - I will check the backports

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

Comment By: Dynamic Packet (dpacket)
Date: 2012-11-14 10:29

Message:
This is a bug in dispatcher module. If you fail to set attrs_avp in script,
you get errors on ds_select_dst().  Default, per docs, should be null. But
ds_select_dst fails in this case after commit #9295. Setting attrs_avp in
config, seemingly fixes the issue.

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

Comment By: Dynamic Packet (dpacket)
Date: 2012-11-14 09:01

Message:
Hi Razvan,

I'm not 100% sure what function and I am unable to test at the moment. But
looking at the area of the script it occurs in, it could be ds_select_ds,
append_hf, xlog or least likely script comparisons/assignments.

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

Comment By: Razvan Crainea (razvancrainea)
Date: 2012-11-14 08:55

Message:
Hi!

Can you tell us when do you receive those errors? Is it a certain function
that uses AVPs and cannot find them?

Regards,
R?zvan

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

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


From noreply at sourceforge.net  Fri Nov 30 21:49:02 2012
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 30 Nov 2012 12:49:02 -0800
Subject: [OpenSIPS-Devel] [ opensips-Bugs-3590978 ] registrar complains of a
	BUG
Message-ID: <mailman.1260.1354308546.13469.devel@lists.opensips.org>

Bugs item #3590978, was opened at 2012-11-29 02:34
Message generated for change (Comment added) made by bogdan_iancu
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=3590978&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.8.x
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Kiss Karoly (kisskaroly)
>Assigned to: Bogdan-Andrei Iancu (bogdan_iancu)
Summary: registrar complains of a BUG

Initial Comment:
I noticed the following in an opensips version 1.8.2 (rev #9429) log:
Nov 29 10:49:14 sip /usr/sbin/opensips[30799]: CRITICAL:registrar:update_contacts: BUG - overflow detected with r=0xa96c1a34 and contacts=(nil)

This happened right after a call to 
save("location", "$avp(rflags)fc$avp(maxregs)", "$var(furi)")
Contents of avp's and variables were:
$avp(rflags) = "";
$avp(maxregs) = 1;
$var(furi) = "sip:username at domain.tld";




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

>Comment By: Bogdan-Andrei Iancu (bogdan_iancu)
Date: 2012-11-30 12:49

Message:
Is this reproducible ?

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

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


