Even if you don't support parsing the STUN packets, you should make sure you will discard them anyways (since a STUN packet will fail as a RTP packet if you do a proper header check).<br><br>For video doing keep alives is a little trickier than audio -- in audio you can encode silence and send that as data, knowing the remote party won't hear it. The equivalent in video doesn't really exist. So, STUN packets are great if you can use them, otherwise I've seen some implementations send a bogus RTP packet using an unused payload type to keep the pinhole open.
<br><br>Duane<br><br><div><span class="gmail_quote">On 11/28/06, <b class="gmail_sendername">Olle E Johansson</b> <<a href="mailto:oej@edvina.net">oej@edvina.net</a>> wrote:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<br>28 nov 2006 kl. 15.42 skrev Bruce Bauman:<br><br>> If a videophone is behind a NAT, the firewall will often timeout the<br>> bindings after a small amount of time and Asterisk will be unable to<br>> send video to the phone.
<br>><br>> Has anyone encountered/solved this problem? How do you keep the RTP<br>> stream open during periods of inactivity?<br><br>There's something called RTP keepalives that some devices use.<br>You need to send at least every 29th sec...
<br><br>What it really is, is something for others to discuss. With newer<br>devices<br>you could send STUN requests on the RTP port - you certainly have to<br>be ready to receive them (the new SIP outbound draft).<br><br>
/O<br>_______________________________________________<br>--Bandwidth and Colocation provided by <a href="http://Easynews.com">Easynews.com</a> --<br><br>asterisk-video mailing list<br>To UNSUBSCRIBE or update options visit:
<br> <a href="http://lists.digium.com/mailman/listinfo/asterisk-video">http://lists.digium.com/mailman/listinfo/asterisk-video</a><br></blockquote></div><br>