19 Oct
2012
19 Oct
'12
6:16 p.m.
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(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
_______________________________________________
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users(a)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(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users