Just a little comment on the numbers that I've thrown out earlier today.
Those are probably somewhat pessimistic, with some creative tuneup you can
probably go much higher. But we also constrained by some other
considerations (i.e. running fully redundant network connection with FEC,
full firewall
Arsen, there is no readily-made solution with rtpproxy unfortunately for
that. Some time around 1.0 times circa 2007-2009, somebody submitted a very
rough patch to implement master/hot-standby scenario, but the patch was not
production-ready back then and the contributor was not available to refine
> might not be rtpproxy, but I am wondering if you or anyone else faced same
> issue. Also, if I am not wrong, the person that reported to me said that
> 2.0 didn't revealed the same behaviour.
>
> Cheers,
> Daniel
>
>
> On 19/10/16 09:46, Maxim Sobolev wrote:
>
>
appreciate your followup and clarification, which certainly is
> useful for my own knowledge as well!
>
> My sincere apologies...
>
> -- Alex
>
>
> On October 19, 2016 3:32:24 AM EDT, Maxim Sobolev
> wrote:
> >Alex, with all due respect, things you said about rtpproxy cap
Alex, with all due respect, things you said about rtpproxy capacity is
somewhat outdated and misleading. We have some nodes in the field, that
handle 5,000-6,000 rtp sessions in peak. Those are running 6 rtpproxy
instances, 1,000 sessions each. 2-3 year old CPUs, 12 cores in total.
We also have a
Yes, that's probably it. There should be also some error in the log that
rtpproxy emits, so you might want to check that. I see people run into this
from time to time, perhaps we need to check and put out a big warning in
red if the OS limit appers to be too low?
-Max
On Sun, Jul 17, 2016 at 3:18
We don't support SRTP de/re-encryption at this point, neither in master nor
in 2.0. The work to add it is underway, but we are not quite there yet.
Pass-through mode should be working fine though, we've tested it recently
specifically.
On Jun 7, 2016 12:27 PM, "Albert Petit" wrote:
> Hi ,
>
> Sor
Sergey, these days Rtpproxy can also do ipv4-ipv6 gatewaying, media
pinning/topology hiding, session recording, MOH/prompt injection, media
timeout notification, media accounting generation and stats collection.
As far as original question goes, I suggest you guys check some IPv6
scenarios availa
Well technically there could be SDP in ACK as well, in the body-less INVITE
scenario. I am not sure if it's the case here, though. Other than that,
it's correct, final positive ACK in RFC3261 is end-to-end, so that proxy is
just passive retranslator for that.
On Mar 9, 2016 5:07 PM, "Alex Balashov"
gt;
>
>
> There are no errors like "can't create" or "can't bind".
>
>
>
> I don't find the -L option into the manual. I'm not sure to understand
> what the option is used for?
>
>
>
> Regards,
>
>
>
> Igor.
&g
Try setting some more reasonable FD limit, i.e. say 10,000. Bumping from
1,000 to 500,000 seems somewhat excessive. You can also see if you also
need to use matching -L option, there might be separate soft limit that
application needs to lift by itself. In general, when session creation
fails you s
t was failing?
>
> Daniel
>
>
>
> On 15/10/15 06:32, Maxim Sobolev wrote:
>
> I don't know if it's related, but we noticed that master and 4.3 failed
> out meta testsuite today:
>
> https://travis-ci.org/sippy/voiptests/builds/85453186
>
> The last
I don't know if it's related, but we noticed that master and 4.3 failed out
meta testsuite today:
https://travis-ci.org/sippy/voiptests/builds/85453186
The last build that worked was about 2 months ago, it should be easy to
narrow that down in that range. I've been planning to look into it later
I'd say the most direct method to do it is to extend rtp_cluster to be
geo-aware. If that's not an option then what you can possibly do is to
create multiple views inside rtp_cluster config into the same set of
rtpproxies but with different weights based on location/proximity and use
separate socke
7 March 2015, Zheng Frank wrote:
>
>> Do you mean ROHC ?
>>
>> 2015-03-14 12:39 GMT+08:00 Maxim Sobolev :
>>
>>> Do you have any particular RFC in mind?
>>> On Mar 12, 2015 10:28 AM, "John Mathew"
>>> wrote:
>>>
>>
Do you have any particular RFC in mind?
On Mar 12, 2015 10:28 AM, "John Mathew" 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
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
___
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-us
ot sure.
>
> I see in the latest code that the function is still there. Do you suggest
> to upgrade or there's a patch to make?
>
>
>
> Regards,
>
>
>
> Igor.
>
>
>
> *De :* sr-users [mailto:sr-users-boun...@lists.sip-router.org] *De la
> part d
unction "ts_less" returns FALSE into
> "rtp_resizer.c" because the timestamp between the two packets is > (1 <<
> 31) [for example: 3740425320].
>
> That's result in a drop of any following packets as I can see it into a
> capture.
>
>
>
> Reg
Hi Igor, that's bit strange, since the rtpproxy is not checking any of the
rtp flags including marker bit. It would help if you can post a tcpdump
capture of the streams in question along with the log output of the
rtpproxy running at the "dbug" level. Thanks!
On Mar 5, 2015 5:54 AM, "Igor Potjevle
Hi Sam,
There are two ways to decode I know about:
1. Dump in ad-hoc format, decode with extractaudio tool, which is still
work-in-progress, so we have not really released it yet. Latest code is
available here http://bitbucket.org/sippysoft/rtpproxy/. Subdir
"extractaudio". It might not even comp
21 matches
Mail list logo
