[SR-Users] rtpproxy delete fails

[Juha Heinanen]

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 at 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 at siika.tutpro.com;z9hG4bKxcuqspqh nxaoe qskel
> > Oct 19 17:08:40 siika mediaproxy-ng[12832]: [kmjhsrcegulqqta at 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 at siika.tutpro.com;z9hG4bKxcuqspqh nxaoe
> > Oct 19 17:08:40 siika mediaproxy-ng[12832]: [kmjhsrcegulqqta at siika.tutpro.com - z9hG4bKxcuqspqh] Branch deleted
> > Oct 19 17:08:40 siika mediaproxy-ng[12832]: [kmjhsrcegulqqta at 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 at 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 at lists.sip-router.org
> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users