I'm pretty sure I neglected to forward this patch to the list. This
patch modifies rtpproxy so one stream's timeout (the video stream, for
example) does not fire a notify event unless the timed-out stream is the
last stream with that call-id.
This fixes the problem where an offered, but unaccepted video stream
would timeout the entire call after 1 minute.
-------- Original Message --------
Subject: Video SDP and Timeout Notification
Date: Thu, 01 Sep 2011 11:03:40 -0600
From: Jeremy Childs <[email protected]>
To: [email protected]
Maxim:
I have discovered an interesting problem with timeout notification and
SDP offers that include a second media stream (video, in my case).
If the second stream in the offer is not accepted by the callee, then
the second rtpproxy session times out after 60 seconds, and timeout
notification is sent to the controlling application, cancelling the call.
I can see a couple of ways of fixing this, and am looking for advice
regarding which strategy is better:
1. The easy fix is to NOT send notifications if the session is not
complete.
if (sc->complete) { do_timeout_notification(); }
2. Harder (but maybe more correct) is to only send a notification if
this is the last session left with the given call-id.
if (is_last_session(sp->call_id)) { do_timeout_notification(); }
Do you have any thoughts on which strategy is better?
J
_______________________________________________
Devel mailing list
[email protected]
http://lists.rtpproxy.org/mailman/listinfo/devel
