Hi,

While I can't really answer your question, the logic in mediaproxy-ng is that if the to-tag is given in the "D"elete message, it has to match the to-tag that was previously given in the "L"ookup message alongside with the from-tag. If no to-tag is given in the delete message, then only the from-tag is used for matching.

If no lookup was ever performed, then mediaproxy obviously has no way of knowing the to-tag and so can't match on it. In that case, only the from-tag should be given in the delete message.

I suppose it could make sense to change mediaproxy's behaviour to ignore the to-tag given in the delete message if it hadn't received a lookup for that particular branch yet. Although right off the bat I'm not 100% certain if that would be correct behaviour or if there might be some undesired side effects to that...

The ";1" is the sequence number of the media stream within the call. If more than one stream is present, you'll see ";1", ";2" and so on.

cheers

On 10/19/12 10:18, Juha Heinanen wrote:

i made more tests on deleting rtpprxy session when 480 is received. in this test there is only one uas registered for AoR test@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@siika.tutpro.com;z9hG4bKxcuqspqh nxaoe qskel Oct 19 17:08:40 siika mediaproxy-ng[12832]: [kmjhsrcegulqqta@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@siika.tutpro.com;z9hG4bKxcuqspqh nxaoe Oct 19 17:08:40 siika mediaproxy-ng[12832]: [kmjhsrcegulqqta@siika.tutpro.com - z9hG4bKxcuqspqh] Branch deleted Oct 19 17:08:40 siika mediaproxy-ng[12832]: [kmjhsrcegulqqta@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

---

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

On 10/19/12 11:16, Juha Heinanen wrote:

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?

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.

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?

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.

cheers

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

On 10/19/12 8:30 PM, Juha Heinanen wrote:

Daniel-Constantin Mierla writes:

...

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?

yes, they are all tested with real mediaproxy-ng rtpproxy server.

...

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

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?

why is that? in failure_route I call rtpproxy_mange() which calls unforce_rtp_proxy() which destroys the initiated session.

Cheers, Daniel

On 10/19/12 9:11 PM, Juha Heinanen wrote:

Daniel-Constantin Mierla writes:

...

why is that? in failure_route I call rtpproxy_mange() which calls unforce_rtp_proxy() which destroys the initiated session.

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.

But in this case the call is completed, because negative response codes are absorbed by tm, 200ok being sent back, so no need to destroy any rtp session. iirc, for all branches of a parallel fork there is one rtp session in rtpproxy (cannot tell about other media relays).

Cheers, Daniel

On 10/19/12 9:40 PM, Juha Heinanen wrote:

Daniel-Constantin Mierla writes:

...

But in this case the call is completed, because negative response codes are absorbed by tm, 200ok being sent back, so no need to destroy any rtp session. iirc, for all branches of a parallel fork there is one rtp session in rtpproxy (cannot tell about other media relays).

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.

You can set a transaction flag when you force rtpproxy for a branch, then in onreply route, if you get a 200ok from a branch not involving rtp relay and that flag is set, then destroy the rtp relaying session.

Cheers, Daniel

On 19.10.2012 21:40, Juha Heinanen wrote:

Daniel-Constantin Mierla writes:

...

But in this case the call is completed, because negative response codes are absorbed by tm, 200ok being sent back, so no need to destroy any rtp session. iirc, for all branches of a parallel fork there is one rtp session in rtpproxy (cannot tell about other media relays).

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.

Is it really worth differing between nated and non-nated clients?

Probably this depends on the setup - e.g. setups for cable-ISPs do not require proxying if cable modems use public IP addresses, but other VoIP services were users mostly of sofpthones I would guess that most of the time the users are behind NAT (or some FW).

In my setup I always treat every user as natted user - this makes the config much more simpler. But I haven't had projects with huge user bases where capacity on the rtpproxy and IP traffic was an issue.

regards Klaus

On 25.10.2012 16:27, Juha Heinanen wrote:

Klaus Darilion writes:

...

Is it really worth differing between nated and non-nated clients?

yes, because operator of sip proxy would save in hardware costs.

...

In my setup I always treat every user as natted user - this makes the config much more simpler. But I haven't had projects with huge user bases where capacity on the rtpproxy and IP traffic was an issue.

does that mean that every call is using mediaproxy? if so, what is the advantage of sip proxy to, say, asterisk?

There are pro's and cons. For example in a Asterisk-based hosted PBX setup I always terminate RTP streams on the Asterisk server (also for legal reasons) and Kamailio is used only as border element/load balancer. Thus, there is no need for an RTP proxy. Same applies if the service is mostly a POTS replacement service (most calls are SIP-PSTN calls, only a few SIP-SIP calls) then I do not care about optimization and relay also RTP stream of SIP-SIP calls via the Asterisk server -> thus no need for rtpproxy.

In scenarios with lots of SIP-SIP calls between the users and without PBX features I use only Kamailio with rtpproxy but treat every user as NATed user (pragmatic approach). And back to your question - in setups where CPU is not a limiting factor (ie Asterisk could be used too) I use Kamailio only as border element for filtering and header manipulation (to deal with broken clients).

But as already said, different scenarios probably requires different handling.

regards Klaus