i made more tests on deleting rtpprxy session when 480 is received. in this test there is only one uas registered for AoR test(a)test.fi. when it times out and replies with 480, sip proxy makes exactly same call rtpproxy_manage("FROW3"); first in onreply route and then i failure route. this i what i get to syslog: Oct 19 17:08:40 siika /usr/sbin/sip-proxy[20799]: INFO: Received reply <480> Oct 19 17:08:40 siika mediaproxy-ng[12832]: Got valid command from udp:127.0.0.1:53325: 20799_12 D kmjhsrcegulqqta(a)siika.tutpro.com;z9hG4bKxcuqspqh nxaoe qskel Oct 19 17:08:40 siika mediaproxy-ng[12832]: [kmjhsrcegulqqta(a)siika.tutpro.com] Tags didn't match for delete message, ignoring Oct 19 17:08:40 siika /usr/sbin/sip-proxy[20799]: INFO: Got contact failure <480> Oct 19 17:08:40 siika mediaproxy-ng[12832]: Got valid command from udp:127.0.0.1:53325: 20799_13 D kmjhsrcegulqqta(a)siika.tutpro.com;z9hG4bKxcuqspqh nxaoe Oct 19 17:08:40 siika mediaproxy-ng[12832]: [kmjhsrcegulqqta(a)siika.tutpro.com - z9hG4bKxcuqspqh] Branch deleted Oct 19 17:08:40 siika mediaproxy-ng[12832]: [kmjhsrcegulqqta(a)siika.tutpro.com] Deleting full call my conclusion from this is that rtpproxy_manage("FROW3") does include to tag in rtpproxy command when called from onreply route, but does not include it when called from failure route. why the difference? it is a bug that to tag is included in onreply route, because it means that it is not possible to delete rtpproxy session in onreply route? -- juha

Richard Fuchs writes: richard, thanks for your reply. that would solve the problem that currently there is no way to delete rtp session in onreply route when lookup has not been performed yet, i.e., when 200 ok has not been received. consider my original test setup where one UAS is behind nat and the other one is not. when the one that is behind nat replies with 480 and the other after that replies with 200 ok, the unused rtp session is left hanging in the air, i.e., in state where new call is created, but no LS command has been received. i have not see in any document description about how long rtp proxy keeps the call state after it has received US command, but no matching LS command. is there a timer that clears those hanging calls once in a while and sip proxy config writer does not need to care about them. could the hanging calls offer a DoS attack possibility? if the change that you propose is made, then consider the setup where two UAS are both behind nat and one replies with 480. if rtp session of that leg is deleted without to tag, would it also delete the other rtp session to which no reply has not arrived yet? -- juha

Richard Fuchs writes: 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, 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

Daniel-Constantin Mierla writes: yes, they are all tested with real mediaproxy-ng rtpproxy server. so you don't care when current implementation makes it is possible to pile up one hour's worth of un-used rtpproxy calls and there is nothing in kamailio config you can do about it? -- juha

Daniel-Constantin Mierla writes: as explained in earlier messages of this thread, the situation unused rtp sessions pile up happens, e.g., when call parallel forks and some forks that needed rtpproxy respond negatively, e.g., with 480, and one responses with 200. thus failure route never gets called that would allow you to destroy the initiated session. -- juha

Daniel-Constantin Mierla writes: sorry that i was not clear enough: the branch replying with 200 ok is not using rtpproxy (e.g. is not behing nat), whereas one or more of the other ones that replied negatively would have used it. -- juha

Daniel-Constantin Mierla writes: that is exactly what i tried to do, but it required the 't' flag that i added to rtpproxy_destroy flags. i committed the 't' flag to rtpproxy_destroy and (as no-op) to force_rtp_proxy. -- juha

Klaus Darilion writes: yes, because operator of sip proxy would save in hardware costs. does that mean that every call is using mediaproxy? if so, what is the advantage of sip proxy to, say, asterisk? - juha