Re: [OpenSIPS-Devel] [RFC] NAT pinging

Bogdan-Andrei Iancu wrote: A) contact info versus network info When considering a REGISTER request, you have two sets of information: I - registered contact ; II - network info (source IP/port, proto, local socket where the request was received on). When comes to determine the destination

[OpenSIPS-Devel] SF.net SVN: opensips:[5099] trunk/modules/nathelper/nathelper.c

Revision: 5099 http://opensips.svn.sourceforge.net/opensips/?rev=5099view=rev Author: sobomax Date: 2008-12-25 05:45:54 + (Thu, 25 Dec 2008) Log Message: --- Don't modify strings allocated in the shared memory pool, this can cause race conditions. Obtained from:

[OpenSIPS-Devel] SF.net SVN: opensips:[6369] trunk/cfg.y

Revision: 6369 http://opensips.svn.sourceforge.net/opensips/?rev=6369view=rev Author: sobomax Date: 2009-12-04 07:51:05 + (Fri, 04 Dec 2009) Log Message: --- Fix error message: bad forwardargument - bad forward argument. Modified Paths: -- trunk/cfg.y

[OpenSIPS-Devel] SF.net SVN: opensips:[6430] trunk

Revision: 6430 http://opensips.svn.sourceforge.net/opensips/?rev=6430view=rev Author: sobomax Date: 2009-12-14 09:20:19 + (Mon, 14 Dec 2009) Log Message: --- Add python module, which allows extending opensips.cfg using full-fleged Python code. For now only few basic

[OpenSIPS-Devel] SF.net SVN: opensips:[6431] trunk/modules/python/Makefile

Revision: 6431 http://opensips.svn.sourceforge.net/opensips/?rev=6431view=rev Author: sobomax Date: 2009-12-14 09:39:32 + (Mon, 14 Dec 2009) Log Message: --- Use generic name of python interpreter and put a note about which versions are supported. Modified Paths:

[OpenSIPS-Devel] SF.net SVN: opensips:[6432] trunk/modules/python/python_msgobj.c

Revision: 6432 http://opensips.svn.sourceforge.net/opensips/?rev=6432view=rev Author: sobomax Date: 2009-12-14 09:50:49 + (Mon, 14 Dec 2009) Log Message: --- Fix description of the call_function() method. Modified Paths: --

[OpenSIPS-Devel] SF.net SVN: opensips:[6487] trunk/modules/python/python_msgobj.c

Revision: 6487 http://opensips.svn.sourceforge.net/opensips/?rev=6487view=rev Author: sobomax Date: 2010-01-04 12:26:41 + (Mon, 04 Jan 2010) Log Message: --- Add dst_address property to the message object. It returns destination address (ip, port) of the packet in

[OpenSIPS-Devel] SF.net SVN: opensips:[6745] trunk/modules/nathelper/nathelper.c

Revision: 6745 http://opensips.svn.sourceforge.net/opensips/?rev=6745view=rev Author: sobomax Date: 2010-03-31 22:51:13 + (Wed, 31 Mar 2010) Log Message: --- o Improve buffer management by using dynamicly allocated buffers instead of static ones; o Rework fix for the

[OpenSIPS-Devel] RFC: adding new callback mechanism into core API

Gang, We have some new functionality for the nathelper planned that would need to know final destination URI for the message to work properly. Currently this means that we have to require script writer to invoke this function only after all URI transformations have been applied, which might

Re: [OpenSIPS-Devel] RFC: adding new callback mechanism into core API

Here is the pre-final patch along those lines: http://sobomax.sippysoft.com/opensips_rtpproxy_multihome.diff Any comments or suggestions are welcome. Maxim Sobolev wrote: Gang, We have some new functionality for the nathelper planned that would need to know final destination URI

[OpenSIPS-Devel] SF.net SVN: opensips:[6818] trunk

Revision: 6818 http://opensips.svn.sourceforge.net/opensips/?rev=6818view=rev Author: sobomax Date: 2010-04-26 07:00:34 + (Mon, 26 Apr 2010) Log Message: --- This is a mechanism to register per-message callback handlers to be called at certain points of the message

Re: [OpenSIPS-Devel] RFC: adding new callback mechanism into core API

Bogdan-Andrei Iancu wrote: Hi Maxim, So, the nathelper is interested in the destination IP or in the destination URI ? May I ask what is the nathelper extension that require this feature ? because depending on what the purpose is, maybe other solutions are available. Hi Bogdan, We

[OpenSIPS-Devel] SF.net SVN: opensips:[6819] trunk/modules/nathelper

Revision: 6819 http://opensips.svn.sourceforge.net/opensips/?rev=6819view=rev Author: sobomax Date: 2010-04-26 07:10:51 + (Mon, 26 Apr 2010) Log Message: --- Support auto-bridging feature found in the latest RTPproxy (trunk code at the moment, 1.3 when released).

[OpenSIPS-Devel] SF.net SVN: opensips:[7466] trunk/modules/tm/sip_msg.c

Revision: 7466 http://opensips.svn.sourceforge.net/opensips/?rev=7466view=rev Author: sobomax Date: 2010-12-06 21:00:57 + (Mon, 06 Dec 2010) Log Message: --- Initialize new_msg-msg_cb properly, or it could cause crash in the nathelper module later on. Modified Paths:

[OpenSIPS-Devel] SF.net SVN: opensips:[7467] trunk/msg_callbacks.c

Revision: 7467 http://opensips.svn.sourceforge.net/opensips/?rev=7467view=rev Author: sobomax Date: 2010-12-06 21:17:09 + (Mon, 06 Dec 2010) Log Message: --- Fix linked list management. Submitted by: Kennard White, patch #3047314 Modified Paths: --

[OpenSIPS-Devel] SF.net SVN: opensips:[9517] trunk/modules/tm/t_reply.c

Revision: 9517 http://opensips.svn.sourceforge.net/opensips/?rev=9517view=rev Author: sobomax Date: 2012-12-13 18:51:44 + (Thu, 13 Dec 2012) Log Message: --- Also free any callback memory, which is not shared. Bug ID: 3582691 Modified Paths: --

[OpenSIPS-Devel] SF.net SVN: opensips:[9518] branches/1.7/modules/tm/t_reply.c

Revision: 9518 http://opensips.svn.sourceforge.net/opensips/?rev=9518view=rev Author: sobomax Date: 2012-12-13 18:53:04 + (Thu, 13 Dec 2012) Log Message: --- Also free any callback memory, which is not shared. Bug ID: 3582691 Modified Paths: --

[OpenSIPS-Devel] SF.net SVN: opensips:[9519] branches/1.8/modules/tm/t_reply.c

Revision: 9519 http://opensips.svn.sourceforge.net/opensips/?rev=9519view=rev Author: sobomax Date: 2012-12-13 18:54:27 + (Thu, 13 Dec 2012) Log Message: --- Also free any callback memory, which is not shared. Bug ID: 3582691 Modified Paths: --

Re: [OpenSIPS-Devel] [OpenSIPS-Users] Fwd: RTPproxy project

:31 +0300 From: Bogdan-Andrei Iancu To: Maxim Sobolev CC: Razvan Crainea Hello Maxim, Long time, no talks, but I hope everything is fine on your side. I'm reaching you in order to ask about your future plans in regards to the rtpproxy project? We see no much activity around it and other

Re: [OpenSIPS-Devel] One way audio problem

Hi, please also submit relevant call setup logs from the rtpp. They are essential to diagnose the issue. You can grep logs by respective call-id. Thanks! On Jun 18, 2014 7:14 AM, kaushik parmar androidj...@gmail.com wrote: Hello All, I have configured opensips.cfg file and able call extensions

[OpenSIPS-Devel] Announcing rtpproxy v2.0.0

Hi All, I'm happy to announce that we have released rtpproxy v2.0.0. You can review the release notes here: https://github.com/sippy/rtpproxy/releases/tag/v2.0.0 -sobomax ___ Devel mailing list Devel@lists.opensips.org

Re: [OpenSIPS-Devel] [RTPproxy] Re: [OpenSIPS-Users] Announcing rtpproxy v2.0.0

Do you have any particular RFC in mind? On Mar 12, 2015 10:28 AM, John Mathew john.mat...@divoxmedia.com wrote: Hi, Maxim, Is there any plans for rtp header compression in future. I can't see anything in the change log for 2.0.0 On Tuesday, 10 March 2015, Maxim Sobolev sobo

Re: [OpenSIPS-Devel] [RTPproxy] Re: [OpenSIPS-Users] Announcing rtpproxy v2.0.0

, 17 March 2015, Zheng Frank zhengyumingap...@gmail.com wrote: Do you mean ROHC ? 2015-03-14 12:39 GMT+08:00 Maxim Sobolev sobo...@sippysoft.com: Do you have any particular RFC in mind? On Mar 12, 2015 10:28 AM, John Mathew john.mat...@divoxmedia.com wrote: Hi, Maxim, Is there any plans

Re: [OpenSIPS-Devel] May's Public Meeting

Hi Razvan, my only suggestion is to move those meetings either early in the morning or later in the afternoon, so that those of us who are behind UTC by many hours have a chance to take part. 13 UTC is like 5am here. Maybe not this one if it's too much trouble to reschedule, but something to

Re: [OpenSIPS-Devel] [RELEASE] OpenSIPS 2.1.1 is now available

From: Maxim Sobolev Date:22/08/2015 18:48 (GMT+02:00) To: OpenSIPS devel mailling list Cc: n...@lists.opensips.org,us...@lists.opensips.org, busin...@lists.opensips.org Subject: Re: [OpenSIPS-Devel] [RELEASE] OpenSIPS 2.1.1 is now available Hi Bogdan, For some reason 2.1.x

Re: [OpenSIPS-Devel] [RELEASE] OpenSIPS 2.1.1 is now available

Hi Bogdan, For some reason 2.1.x is still failing our voiptests travis run with the following error when trying to run in the UDP-only mode: Aug 22 15:32:00 [10854] ERROR:core:fix_all_socket_lists: listeners found for protocol udp, but no module can handle it Aug 22 15:32:00 [10854]

Re: [OpenSIPS-Devel] [RELEASE] OpenSIPS 2.1.1 is now available

modules I've opened a ticket on that (#616). On Mon, Aug 24, 2015 at 12:02 PM, Maxim Sobolev sobo...@sippysoft.com wrote: No, we have not loaded it yet. Is it now always required? As I said my point here is not so much how to fix it, but the fact that Liviu Chircu said that loading such module

[OpenSIPS-Devel] "Early cancel" issue in the tm module

Hi Volks, there seems to be an issue in the way how the tm handles early CANCEL, i.e. when a CANCEL arriving before the downstream UAS gets chance to generate a 100 Trying reply, or that reply is still in flight (or maybe 100 Trying is lost). In that case the OpenSIPS stops outbound INVITE

Re: [OpenSIPS-Devel] "Early cancel" issue in the tm module

point to the RFC section mentioning this behavior ? > - what happens if there is no reply at all from UAS ? > > Best regards, > > Bogdan-Andrei Iancu > OpenSIPS Founder and Developer > http://www.opensips-solutions.com > > > On 13.11.2015 01:41, Maxim Sobolev wrote: > >

Re: [OpenSIPS-Devel] "Early cancel" issue in the tm module

after a local timeout) and it is handled as per RFC. The downside > of your approach is the ambiguity - if the UAC sends a CANCEL, it expects a > 487 or 200 back, but not a timeout > > What do you think ? > > Best regards, > > Bogdan-Andrei Iancu > OpenSIPS Founder a

Re: [OpenSIPS-Devel] "Early cancel" issue in the tm module

gracefully timeouted. On Thu, Dec 10, 2015 at 7:13 AM, Maxim Sobolev <sobo...@sippysoft.com> wrote: > Bogdan, the point here is that the call cannot be considered cancelled by > the proxy until INVITE transaction either timeouts retransmits in 32 seconds > or final response

Re: [OpenSIPS-Devel] "Early cancel" issue in the tm module

TE (see my > demonstration that a 487 or a later 408 are exactly the same in terms of > risk), while the 487 has no delay and reflects the correct state (call was > canceled). > > Regards, > > Bogdan-Andrei Iancu > OpenSIPS Founder and Developerhttp://www.opensips-solutions.com >

Re: [OpenSIPS-Devel] "Early cancel" issue in the tm module

ng, in terms of letting all the time the final > UAS to generate the final reply (if still alive). > > Best regards, > > Bogdan-Andrei Iancu > OpenSIPS Founder and Developer > http://www.opensips-solutions.com > > On 11.12.2015 05:28, Maxim Sobolev wrote: >> >> B

Re: [OpenSIPS-Devel] "Early cancel" issue in the tm module

d it by adding explicit t_reply("100", "Trying"). On the positive note, you patch seems to be working, thanks. Let me know if you want me to open issue wrt that t_newtran's 100 Trying problem. https://github.com/sippy/voiptests/commit/11a6bc6bee1ddfc83eb4acf784ce7aebf8e6815b On Wed

Re: [OpenSIPS-Devel] "Early cancel" issue in the tm module

with the change in question. On Wed, Dec 23, 2015 at 4:20 AM, Maxim Sobolev <sobo...@sippysoft.com> wrote: > Hi Bogdan, that patch is not fully functional. Yes, it did restore > INVITE re-transmits, so that the second 100 Trying is stimulated > properly, but the CANCEL to the

Re: [OpenSIPS-Devel] "Early cancel" issue in the tm module

at 7:07 AM, Maxim Sobolev <sobo...@sippysoft.com> wrote: > OK, further investigation revealed that the lack of the provisional > reply is caused by the usage of the t_newtran() in our routing script, > which then causes different code path in the t_relay(), i.e. > t_forward_nonack(

Re: [OpenSIPS-Devel] "Early cancel" issue in the tm module

dan-Andrei Iancu > OpenSIPS Founder and Developer > http://www.opensips-solutions.com > > On 14.12.2015 22:46, Maxim Sobolev wrote: >> >> Thanks Bogdan, I will be working on test case this week. I'll drop you >> a note when it's ready. >> >> On Fri, Dec 11

[OpenSIPS-Devel] No 100 Trying reply generated by the t_relay() for INVITE after t_newrean() [was: "Early cancel" issue..]

script. > Could you please detail a bit the actual bug ? > > Thanks and regards, > > Bogdan-Andrei Iancu > OpenSIPS Founder and Developer > http://www.opensips-solutions.com > > On 29.12.2015 08:01, Maxim Sobolev wrote: >> >> Hi Bogdan, happy holidays for you an

Re: [OpenSIPS-Devel] [OpenSIPS/opensips] bce530: Fix the sizing of the Async Reactors.

the value of open_files_limit you use ? or if you do not > explicitly set, what is the soft limit for open files for the user you are > using to run opensips ? > > Regards, > > Bogdan-Andrei Iancu > OpenSIPS Founder and Developerhttp://www.opensips-solutions.com > > On 29.01.2016 04:

Re: [OpenSIPS-Devel] [OpenSIPS/opensips] bce530: Fix the sizing of the Async Reactors.

s, > > Bogdan-Andrei Iancu > OpenSIPS Founder and Developerhttp://www.opensips-solutions.com > > On 29.01.2016 22:08, Maxim Sobolev wrote: > > This is just the default Travis linux instance. I don't set any flags to > bump that limit specifically. I think the default there is 4k o

Re: [OpenSIPS-Devel] [OpenSIPS/opensips] bce530: Fix the sizing of the Async Reactors.

I think this broke 2.1: Jan 29 00:43:48 [12422] WARNING:core:main: no fork mode Jan 29 00:43:48 [12422] NOTICE:core:main: version: opensips 2.1.2 (x86_64/linux) Jan 29 00:43:48 [12422] WARNING:core:fm_malloc: Not enough free memory, will attempt defragmentation Jan 29 00:43:48 [12422]

Re: [OpenSIPS-Devel] [opensips] Topology Hiding: missing 100 Trying (#791)

Bogdan, is it the same issue I reported in Jan? Glad if you've fixed it. On Feb 16, 2016 3:02 AM, "arovetto" wrote: > Thank you > > — > Reply to this email directly or view it on GitHub > . > >

Re: [OpenSIPS-Devel] Transactional REGISTER processing with 2.1

ctions. > > Best regards, > > Răzvan Crainea > OpenSIPS Solutionswww.opensips-solutions.com > > On 02/17/2017 09:15 PM, Maxim Sobolev wrote: > > P.S. python_exec("www_authenticate") does not do any magic here, it's > just figures out the right domain to use

[OpenSIPS-Devel] Transactional REGISTER processing with 2.1

Hi guys, We are underway to migrate from ancient SER-2.0.0 to more modern OpenSIPS and one of the question that is still in my TODO list is implementing transactional processing of the REGISTER requests. In the old SER we had something along those lines: route[3] { # Ensure that all

Re: [OpenSIPS-Devel] Transactional REGISTER processing with 2.1

P.S. python_exec("www_authenticate") does not do any magic here, it's just figures out the right domain to use based on some business rules and then calls www_authenticate() with that parameter. On Fri, Feb 17, 2017 at 11:12 AM, Maxim Sobolev <sobo...@sippysoft.com> wrote: &

Re: [OpenSIPS-Devel] [OpenSIPS/opensips] Fix a crash in the python module. (#1050)

Hi Bogdan, thanks for merging this little fix. It turns out there is another mode of failure in this module now. This is in the case when we pass a string argument that is getting converting to uint via fixup_spve_uint(). The string is allocated by the python code, so it fails when fixup_uint() is

[OpenSIPS-Devel] Timeout for INVITE transactions in the tm module should be >= Expires

Hi, Today I've noticed the following failure scenario in the tm module, that I think could be handled better (current.png). Basically what happens there is that UA2 due to some software bug has failed to emit proper provisional replies, but got INVITE transaction properly setup and then

[OpenSIPS-Devel] Branch 1.11 is broken

Apparently the 1.11 branch is broken now. I am seeing the following errror in our test builds here https://travis-ci.org/sippy/voiptests/jobs/165107762 : make[1]: Entering directory `/home/travis/build/sippy/voiptests/dist/opensips/modules/drouting' Compiling dr_bl.c Compiling dr_db_def.c

Re: [OpenSIPS-Devel] Crash in OpenSIPS 2.1.4 (tm?)

Razvan, I've implemented new locking method based around FreeBSD's low-level locking primitives, which are semantically equivalent to Linux's futexes. https://github.com/OpenSIPS/opensips/pull/1069 Would be nice to get it integrated into the future release(s). Thanks!

Re: [OpenSIPS-Devel] Crash in OpenSIPS 2.1.4 (tm?)

, Maxim Sobolev <sobo...@sippysoft.com> wrote: > Hi folks, > > We have observed the following crash in the OpenSIPS: > > $ sudo gdb712 /usr/local/sbin/opensips ~/opensips.27455.core > GNU gdb (GDB) 7.12 [GDB v7.12 for FreeBSD] > Core was generated by `opensips'. >

[OpenSIPS-Devel] Crash in OpenSIPS 2.1.4 (tm?)

Hi folks, We have observed the following crash in the OpenSIPS: $ sudo gdb712 /usr/local/sbin/opensips ~/opensips.27455.core GNU gdb (GDB) 7.12 [GDB v7.12 for FreeBSD] Core was generated by `opensips'. Program terminated with signal SIGABRT, Aborted. #0 0x000800ccf39a in thr_kill () from

Re: [OpenSIPS-Devel] Crash in OpenSIPS 2.1.4 (tm?)

orrect? Can you switch the locking > mechanism to FUTEX and check if it behaves differently? > > Best regards, > > Răzvan Crainea > OpenSIPS Solutionswww.opensips-solutions.com > > On 03/06/2017 06:59 PM, Maxim Sobolev wrote: > > The code leading to a crash is fo

Re: [OpenSIPS-Devel] Crash in OpenSIPS 2.1.4 (tm?)

s one with an abort(). Can you double check? > > Best regards, > > Răzvan Crainea > OpenSIPS Solutionswww.opensips-solutions.com > > On 03/07/2017 03:58 PM, Maxim Sobolev wrote: > > Răzvan, we are on FreeBSD there are no futexes on that OS. What's wrong > with usi

Re: [OpenSIPS-Devel] Crash in OpenSIPS 2.1.4 (tm?)

OpenSIPS Solutionswww.opensips-solutions.com > > On 03/07/2017 03:58 PM, Maxim Sobolev wrote: > > Răzvan, we are on FreeBSD there are no futexes on that OS. What's wrong > with using pthreads? It's been working for us before I think. Thanks! > > -Max > > On Tue, Mar 7, 2017

Re: [OpenSIPS-Devel] msg:len is deprecated in master?

commit/ 9c9252c97b4e641d814320f33d795a43c3ea7b0e On Aug 2, 2017, at 4:29 PM, Maxim Sobolev <sobo...@sippysoft.com> wrote: Hi, is msg_len deprecated in latest master? There are tons of examples in the tree that use it. I am seeing this: +/home/travis/build/sippy/voiptests/dist/opensips/opensips -f

Re: [OpenSIPS-Devel] Can't get 2.3 running with voiptests properly

Hi Bogdan & Co, I think I've narrowed down failure to a specific revision in the 2.3 branch, see https://travis-ci.org/sippy/voiptests/builds/260009545: commit 1eb4ec0f78f43f6ff546de49bc72e513876fb86b Author: Bogdan-Andrei Iancu Date: Thu Mar 9 15:37:01 2017 +0200

Re: [OpenSIPS-Devel] msg:len is deprecated in master?

ons.com > > OpenSIPS Bootcamp 2017, Houston, US > http://opensips.org/training/OpenSIPS_Bootcamp_2017.html > > On 08/03/2017 12:29 AM, Maxim Sobolev wrote: > > Hi, is msg_len deprecated in latest master? There are tons of examples in > the tree that use it. I am seeing this: >

Re: [OpenSIPS-Devel] msg:len is deprecated in master?

egards, > > Bogdan-Andrei Iancu > OpenSIPS Founder and Developer > http://www.opensips-solutions.com > > OpenSIPS Bootcamp 2017, Houston, US > http://opensips.org/training/OpenSIPS_Bootcamp_2017.html > > On 08/03/2017 02:23 AM, Maxim Sobolev wrote: > > Well if

Re: [OpenSIPS-Devel] Can't get 2.3 running with voiptests properly

ndrei Iancu > OpenSIPS Founder and Developer > http://www.opensips-solutions.com > > OpenSIPS Bootcamp 2017, Houston, US > http://opensips.org/training/OpenSIPS_Bootcamp_2017.html > > On 07/27/2017 08:02 PM, Maxim Sobolev wrote: > > Thanks, I'll try that. How

Re: [OpenSIPS-Devel] Can't get 2.3 running with voiptests properly

ght be somehow related to the early CANCEL transaction, I see some pattern of OpenSIPS going mute after receiving that. Any thoughts? I might take that early cancel test out and see if it helps. On Thu, Jul 27, 2017 at 9:46 AM, Maxim Sobolev <sobo...@sippysoft.com> wrote: > Hi folks

Re: [OpenSIPS-Devel] Can't get 2.3 running with voiptests properly

7, Houston, US > http://opensips.org/training/OpenSIPS_Bootcamp_2017.html > > On 07/27/2017 07:46 PM, Maxim Sobolev wrote: > > Hi folks, we are getting some unexpected trouble with getting 2.3 to run > properly with voiptests. The issue is that after brief time after starting &g

[OpenSIPS-Devel] Can't get 2.3 running with voiptests properly

Hi folks, we are getting some unexpected trouble with getting 2.3 to run properly with voiptests. The issue is that after brief time after starting up the proxy stops accepting any new requests/replies. As far as I can tell no error output is produced and the opensips eventually exits normally.

Re: [OpenSIPS-Devel] [OpenSIPS-Users] python module - bug and questions

main process that > can’t get cleared in the child process. > > > > Might be wiser to just start one Python thread and interpreter in each > child process I assume is kicked off via child_init. Then you would still > have the module loaded once per child. Although I am not s

Re: [OpenSIPS-Devel] [OpenSIPS-Users] python module - bug and questions

akefile, or will setting “USE_PTHREAD_MUTEX” and > “USE_POSIX_SEM” via menuconfig do it? > > > > Since openSIPS is not multithread, seems like it would be a lot cleaner to > not use threads at all on C/C++. Then threads could still be used on > Python side if needed. >

Re: [OpenSIPS-Devel] Can't get 2.3 running with voiptests properly

Bogdan, I've added extra debug, the output around stuckage looks like the below. As for getting PCAP capture that is not easy to arrange as TravisCI does not give us direct access to the network capture. However, bot A and B log whatever is being sent/received, so it should not be that difficult

Re: [OpenSIPS-Devel] Can't get 2.3 running with voiptests properly

ot;blocked" could you run several times the "opensipsctl > trap" ? > > Best regards, > > Bogdan-Andrei Iancu > OpenSIPS Founder and Developer > http://www.opensips-solutions.com > > OpenSIPS Bootcamp 2017, Houston, US > http://opensips.org/traini

Re: [OpenSIPS-Devel] Can't get 2.3 running with voiptests properly

Hi Bogdan, any luck looking into this issue? Looks like a serious problem with 2.3 / master to me. Backing out the commit in question fixes it for us. -Max On Mon, Aug 7, 2017 at 12:09 PM, Maxim Sobolev <sobo...@sippysoft.com> wrote: > Bogdan, I've collected some "opensipsctl tra

Re: [OpenSIPS-Devel] Can't get 2.3 running with voiptests properly

. Expect the fix soon. > > Best regards, > > Bogdan-Andrei Iancu > OpenSIPS Founder and Developer > http://www.opensips-solutions.com > > OpenSIPS Bootcamp 2017, Houston, US > http://opensips.org/training/OpenSIPS_Bootcamp_2017.html > > On 08/19/2017 01:39 AM, Maxim

Re: [OpenSIPS-Devel] [OpenSIPS-Users] [RELEASE] OpenSIPS 2.2.7, 2.3.4 and 2.4.1 minor releases

Good job, OpenSIPS team! -Max On Thu, May 24, 2018 at 6:56 PM, Pasan Meemaduma via Users < us...@lists.opensips.org> wrote: > Congratz :) > > > On Thursday, 24 May 2018, 10:48:24 PM GMT+5:30, Bogdan-Andrei Iancu < > bog...@opensips.org> wrote: > > > Greetings again! > > I am glad to announce

Re: [OpenSIPS-Devel] [OpenSIPS/opensips] a45d4d: nathelper: manual backport for 3c39167e333a8801772...

P.S. Build logs are here: https://travis-ci.org/sippy/voiptests/builds/337694673 On Mon, Feb 5, 2018 at 12:06 PM, Maxim Sobolev <sobo...@sippysoft.com> wrote: > That merge broke all of our OpenSIPS test scenarous on voiptests. We are > investigating about the possible cause

Re: [OpenSIPS-Devel] [OpenSIPS/opensips] a45d4d: nathelper: manual backport for 3c39167e333a8801772...

That merge broke all of our OpenSIPS test scenarous on voiptests. We are investigating about the possible cause but I think this change may need to be reverted from the stable branches until it's clear what's going on. -Maxim On Mon, Feb 5, 2018 at 10:04 AM, Ovidiu Sas

Re: [OpenSIPS-Devel] [OpenSIPS/opensips] a45d4d: nathelper: manual backport for 3c39167e333a8801772...

was a confusion between > variable naming: oldpf and newpf refers to protocol format and not the > actual IP. > I will revert the changes! > > -ovidiu > > On Mon, Feb 5, 2018 at 3:06 PM, Maxim Sobolev <sobo...@sippysoft.com> > wrote: > > That merge broke

Re: [OpenSIPS-Devel] [OpenSIPS/opensips] a45d4d: nathelper: manual backport for 3c39167e333a8801772...

0 31 a=rtpmap:97 G726-24/8000 32 a=rtpmap:98 G726-16/8000 33 a=rtpmap:101 telephone-event/8000 34 a=fmtp:101 0-15 35 a=ptime:30 36 a=sendrecv On Mon, Feb 5, 2018 at 12:07 PM, Maxim Sobolev <sobo...@sippysoft.com> wrote: > P.S. Build logs are here: > > ht

Re: [OpenSIPS-Devel] [OpenSIPS-Users] [Release] OpenSIPS 2.4.0 major release, beta version

Hice! I'll add new branch to my voiptests build. We have some patches to fix memory leak in the python module, I will post them soon. Hopefully they can make it into the release. -Max On Wed, Mar 28, 2018, 4:19 PM wrote: > Great work !!! > > volga629 > > On Wed, Mar 28,

Re: [OpenSIPS-Devel] [OpenSIPS/opensips] a58f76: OPS-6: All 3 allocators may now compile together

Hi guys, looks like OpenSIPS/master is broken for 3 days after this particular commit (a58f76c0df66). It would be nice if you can investigate and fix as appropriate. Thanks! https://travis-ci.org/sippy/voiptests/builds/507613725 https://travis-ci.org/sippy/voiptests/builds/507324318

Re: [OpenSIPS-Devel] [OpenSIPS/opensips] a58f76: OPS-6: All 3 allocators may now compile together

t? :) > > Regards, > > [1]: https://travis-ci.org/sippy/voiptests > > Liviu Chircu > OpenSIPS Developerhttp://www.opensips-solutions.com > > On 18.03.2019 23:28, Maxim Sobolev wrote: > > Hi guys, looks like OpenSIPS/master is broken for 3 days after this >

[OpenSIPS-Devel] mf_process_maxfwd_header is possibly broken in latest master

Hi, I noticed that our voiptests suite fails in the last few days with opensips/master. The culprit seems to be mf_process_maxfwd_header(), looks like some semantics has changed: Error code seen: Apr 16 13:59:27 [22582] INFO:textops:mod_init: initializing... Apr 16 13:59:27 [22582]

Re: [OpenSIPS-Devel] [OpenSIPS/opensips] 183072: statistics: alocating enough mem for stat name

cating enough mem for stat name > > Commit bc9423713 broke statistics because it was no longer alocating > space for the name of the statistics. This commit fixes the issue. > > Thanks go to Maxim Sobolev for reporting this and pointing out the issue! > > > > ___

[OpenSIPS-Devel] OpenSIPS/master is broken since 2 days ago

Hi, I've noticed that OpenSIPS/master is now crashing during our voiptests run since about 2 days ago with the following message: Jun 26 23:50:33 [22691] CRITICAL:core:qm_debug_frag: qm_*: prev. fragm. tail overwritten(646573755f78616d, abcdef657a69735f)[0x7f2eb37a3b30:0x7f2eb37a3b60]

[OpenSIPS-Devel] rabbitmq is now mandatory for modules target?

Hi folks, Not sure if it's intentional or not, but since about two weeks stock opensips/master fails to build modules if rabitmq is not installed. I kinda liked that you can build OpenSIPS with very few dependencies, this I think was the proper approach. make -C

Re: [OpenSIPS-Devel] [OpenSIPS/opensips] 525b30: port core script functions to the same interface a...

and regards, > > Bogdan-Andrei Iancu > > OpenSIPS Founder and Developer > https://www.opensips-solutions.com > OpenSIPS Summit 2019 > https://www.opensips.org/events/Summit-2019Amsterdam/ > > On 08/01/2019 08:13 PM, Maxim Sobolev wrote: > > Hi Vlad, this is rather in

Re: [OpenSIPS-Devel] [OpenSIPS/opensips] 525b30: port core script functions to the same interface a...

at 9:57 AM Maxim Sobolev wrote: > Thanks, Bogdan, much appreciated! We are on the right track now. > > https://travis-ci.org/sippy/voiptests/builds/567030834 > > -Max > > On Fri, Aug 2, 2019 at 12:41 AM Bogdan-Andrei Iancu > wrote: > >> Hi Maxim, >&

Re: [OpenSIPS-Devel] [OpenSIPS/opensips] 525b30: port core script functions to the same interface a...

Hi Vlad, this is rather invasive change which is going to affect lot (most?) of OpenSIPS users. While understanding the value of re-organization I am having troubles now what needs to be done to get those functions (such as rewriteport() for example) to work properly. Please supply some

Re: [OpenSIPS-Devel] [OpenSIPS-Users] [BLOG] Call control using DTMF codes in OpenSIPS 3.1 LTS

Thanks Razvan for contributing a great feature that has been asked for many times over the last few years! I plan to merge it into the master branch by May. -Max On Thu., Mar. 12, 2020, 5:58 a.m. Антон Ершов, wrote: > this is great news > > чт, 12 мар. 2020 г. в 15:50, Răzvan Crainea : > >>

Re: [OpenSIPS-Devel] Labels in OpenSIPS - is it possible?

Idea sounds interesting, IMHO. -Max On Fri., Apr. 17, 2020, 1:37 a.m. Donat Zenichev, wrote: > Good day! > I wasn't sure if my question relates more to users mailing list, or to dev > mailing list. > Please move it to users mailing if my question relates more to it. > > So, basically my

Re: [OpenSIPS-Devel] OpenSIPS News - OpenSIPS 3.1 - interim update

Sounds good, Bogdan! Just in case, we are also planning to branch and release RTPProxy 2.2 in April-May to include the following: o New recording stop commands contributed by Razvan; o New catch_dtmf module developed in co-operation with the OpenSIPS team; o New acct_rtcp_hep module sponsored by

[OpenSIPS-Devel] RTPProxy's catch_dtmf module progress and bridge_srtp module RFC/plans

Hey Razvan & OpenSIPS folks, This is quick update on what's going on with the DTMF intercept functionality and some ideas as to where we go from there to allow SRTP<->RTP bridging. The very good question that has been brought up by Razvan last Saturday on our SIPChronicles show. Basically the

[OpenSIPS-Devel] Thanks for the great online event!

Hey folks, just wanted my gratitude to everyone who made OpenSIPS Distributed Summit 2020 such a great event! Org team, presenters, viewers: without any of you it won't be possible!! I look forward to seeing you all in person eventually, but also I hope we now be able to continue doing this more

[OpenSIPS-Devel] Re-organizing and de-duplicating digest code (related to the RFC8760 work)

Hey folks, I am making good progress on implementing RFC8760 (SHA-XXX for digest auth), basically the UAS side is functional and tested against our Sippy Python implementation*. Trying to organize and clean the code as I go. Thanks to Liviu by the way for his help flushing some code cleanups and

[OpenSIPS-Devel] Is anyone working on the RFC8760 (SHA256/512 for digest auth) implemtation?

Hi OpenSIPS Developers, This is a quick check/heads-up to see if anyone has been looking into adding SHA256/512 as supported authentication algorithms or interested to collaborate? Let me know if so, to avoid reinventing the wheel. I am working on a prototype implementation in python for our

Re: [OpenSIPS-Devel] OpenSIPS Summit 2020 Distributed is set!

Thumbs up! Let's get distributed. :) -Max On Thu., Jul. 16, 2020, 9:09 a.m. Bogdan-Andrei Iancu, wrote: > > Bye-Bye Amsterdam, welcome Online – the "OpenSIPS Summit 2020" becomes > the "OpenSIPS Summit Distributed 2020", a free, live and interactive > online event. > > 5th - 11th of September

Re: [OpenSIPS-Devel] [OpenSIPS/opensips] e229e1: Revert "packaging: We no longer have atomic.h"

Just for the record: that fix for obscure compiler broke ongoing effort to make OpenSIPS portable to anything but x86. Now ARM and MIPS builds are down: :( https://travis-ci.org/github/OpenSIPS/opensips/builds/748559450 I am sorry to say that Liviu, but in the day and edge when Apple popping

Re: [OpenSIPS-Devel] [OpenSIPS/opensips] e229e1: Revert "packaging: We no longer have atomic.h"

Good to hear, thanks Liviu for taking care of it! I was not criticizing you acting in a particular situation, but criticizing the approach taken to deal with the issue at hand. :) With regards to the old compilers I suggest OpenSIPS take some stance on that issue perhaps as soon as 3.2 is out. In

Re: [OpenSIPS-Devel] OpenSIPS News - Introducing OpenSIPS 3.2

Great news, Bogdan. Few items from Sippy team: + Full RFC8760 (sha-256 & sha-512/256) both UAC & UAS) I hope. The work is done I just need some time to read the diff and merge. +(maybe) unit / basic functional test as part of CI run & coverage report. Happy holidays everyone! 2021 is going to

Re: [OpenSIPS-Devel] SIP Chronicles, recap and upcoming episode on Friday @ 7pm UTC

OOPS, typo, the link to Sandro's episode is below: https://youtu.be/6EKVDyAx2Yo -Max On Thu, Nov 5, 2020 at 11:01 AM Maxim Sobolev wrote: > Hey SipTubies, > > Just a quick recap: if you missed any of latest episodes of SIP Chronicles > here we go: > > Very interesting