Oh, sorry, looks like the proper way to check that is via using -V option. [ssp-root@macmini2 /home/ssp]$ rtpproxy -V 2.2.alpha.3794729c-dirty
Let us know if that upgrade helped. Thanks! -Max On Wed, May 6, 2020 at 2:09 AM Miha <[email protected]> wrote: > Hello Maxim > > I removed package via apt and then install it via source/git. > > But from what I see version is still the same: > How would I know for sure that the version is something like 2.1? > > ./rtpproxy -version > Basic version: 20040107 > Extension 20040107: Basic RTP proxy functionality > Extension 20050322: Support for multiple RTP streams and MOH > Extension 20060704: Support for extra parameter in the V command > Extension 20071116: Support for RTP re-packetization > Extension 20071218: Support for forking (copying) RTP stream > Extension 20080403: Support for RTP statistics querying > Extension 20081102: Support for setting codecs in the update/lookup command > Extension 20081224: Support for session timeout notifications > Extension 20090810: Support for automatic bridging > Extension 20140323: Support for tracking/reporting load > Extension 20140617: Support for anchoring session connect time > Extension 20141004: Support for extendable performance counters > Extension 20150330: Support for allocating a new port ("Un"/"Ln" commands) > Extension 20150420: Support for SEQ tracking and new rtpa_ counters; Q > command extended > Extension 20150617: Support for the wildcard %%CC_SELF%% as a disconnect > notify target > Extension 20191015: Support for the && sub-command specifier > Extension 20200226: Support for the N command to stop recording > > > > Maxim Sobolev je 5/6/2020 ob 2:22 AM napisal: > > Hi Miha, sorry to hear about your issues. In order to troubleshoot it > further could you please also provide rtpproxy package version as reported > by the system package manager (apt, rpm etc) if the software has been > installed via that channel or branch name if it's been built from sources? > Unfortunately version reporting of the --version command has been bit > crippled until recently, already improved in latest master and 2.1 I > believe. > > In general performance under virtual environment has not been terrific, > due to some design choices made early in our work. Hovewer I believe it > should be much better in 2.0 and 2.1 vs. 1.x series. Some of it is > inherently due to VM scheduling jitter, some is because we are unwilling to > put it into unsafe domain (i.e. kernel mode). As a rule of thumb, you might > expect 3-5x drop in max pps until jitter becomes an issue as compared to > running on comparable bare metal. Spinning multiple instances might help to > mitigate some of it though, but it also depends on hypervisor version and > even particular CPU generation. > > -Max > > On Tue., May 5, 2020, 6:10 a.m. Miha via Users, <[email protected]> > wrote: > >> Hello >> >> we have virtualized opensips and rtpproxy running on the same server >> which is virtualized in vmware infrastructure. Servers are not old, also >> traffic is not so big (cca 50 simultaneous calls). when there is a peak cca >> 80 simultaneous calls RTP starts to break. >> >> is there any special setting/flag to be set, so that I can optimze this? >> load on VM is very low. >> >> rtpproxy -version >> Basic version: 20040107 >> >> Opensips is 2.1 >> >> >> thank you for help. >> Miha >> _______________________________________________ >> Users mailing list >> [email protected] >> http://lists.opensips.org/cgi-bin/mailman/listinfo/users >> > > -- Maksym Sobolyev Sippy Software, Inc. Internet Telephony (VoIP) Experts Tel (Canada): +1-778-783-0474 Tel (Toll-Free): +1-855-747-7779 Fax: +1-866-857-6942 Web: http://www.sippysoft.com MSN: [email protected] Skype: SippySoft
_______________________________________________ Users mailing list [email protected] http://lists.opensips.org/cgi-bin/mailman/listinfo/users
