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