Tilghman wrote: > On Monday 06 November 2006 12:36, Dan Austin wrote: >> 'Fixing' app_conference is a worthy endevour, but convincing >> chan_iax to honor framing limits on both the send and receive >> legs of a channel would be a big win. Even better would be >> the addition of an IE to convey the desired framing/payload would >> allow Asterisk and endpoints to 'negotiate' symmetric packetization. >> Chan_skinny has that feature, and it greatly reduces the amount >> of effort to make sure all devices are using identical values >> for framing.
> But it still is an issue. If a malicious attacker finds that you crash > when a 50ms frame is submitted to your system, then you might be > crashing all day. Sending someone a packet larger than they are > expecting should never cause their system to crash. If it does, that's > a bug on the receiving system. I agree completely with your point of view, I am just saying that more could be done. In the scenario that Moises described, it sounds like he might managed the server that the SPA is registered to. If he had the ability to force the framing between the two servers to 20ms, it would have helped. It would not help if an endpoint that uses a payload other than 20ms was register to the same server that hosts app_conference, so making app_conference more resilient is a valid goal. IAX is a great concept, but it is lacking when it comes to media control, specifically framing, which limits the sysadmins ability to control his (or her) environment. I have a few ideas on how to improve the situation, but implimentation would require more intimate knowledge of IAX2 than I posess.... Dan _______________________________________________ --Bandwidth and Colocation provided by Easynews.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
