Popping in late, maybe I missed some parts, but I want to clarify that all these cases discussed here were not tested with rtpproxy application, right?
For the archive, default config file destroys the rtp relaying session in failure_route, when all branches are completed, doing it in onreply route exposes to a lot of troubles. It is how I use it for many years (actually I haven't used something else in my deployments) and all seems fine, no relevant troubles with rtpproxy
Cheers, Daniel
On 10/19/12 6:07 PM, Juha Heinanen wrote:
Richard Fuchs writes:
There's two timeouts, configurable through command line options, one is for active calls and defaults to 60 seconds, the other one is for silenced and not fully established calls and defaults to 1 hour. Calls will be cleared if no RTP traffic nor any re-invite has been detected for this amount of time.
one hour's worth of calls for which L command has not been received sounds like a long period which does open door for DoS attacks. perhaps there should be a separate timer for clearing those incomplete calls much sooner.
Yes it would, which is one of those undesired side effects that I mentioned :) and it's probably why the current implementation behaves the way it does, and it's also why those cases should really be handled on SIP proxy side.
yes, but there is no way currently to handle those cases properly on sip proxy side. it could be possible if in U command branch value would be taken from outgoing message instead of incoming message, which is common to all outgoing branches and thus cannot separate them.
or have i totally misunderstood this because it feels like i am the first beta tester of rtpproxy module?
-- juha
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users