<div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Mar 5, 2015 at 5:27 AM, Yousf Ateya <span dir="ltr"><<a href="mailto:y.ateya@starkbits.com" target="_blank">y.ateya@starkbits.com</a>></span> wrote:<br><br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Asterisk provides a way to set <a href="https://wiki.asterisk.org/wiki/display/AST/IP+Quality+of+Service" target="_blank">tos and cos fields</a> in IP headers. But as stated in documentation:<br><blockquote>Since IAX connections combine signalling, audio, and video into one UDP 
stream, it is not possible to set the TOS separately for the different 
types of traffic<br clear="all"></blockquote><div>So the packet priority is assigned to signaling, voice and video; which minimizes the benefit of having packet priority.<br><br></div><div>If there are separate settings for signaling and voice, users can increase priority of signaling; to ensure that control packets get better chance than voice packets.<br></div></div></blockquote><div><br></div><div>The issue isn't that the settings for signalling and voice are combined, it is that signalling and voice information are multiplexed over a single socket. These quality settings are set on the socket that services both signalling and media; changing them on the fly between frames on a single socket would probably have "interesting" effects. Keep in mind that the settings determine the priority of packets being sent from the socket. Given how often signalling and media can change on a single socket for a number of chan_iax2 channels, you would defeat the purpose of setting TOS/COS if you changed them frequently.<br><br></div><div>The only way you could overcome that would be to break apart the signalling and media onto different sockets. That has several drawbacks:<br></div><div>(1) One of IAX2's strengths is its ability to pass media and signalling over a single port, which helps with NAT/firewalls<br></div><div>(2) It would make chan_iax2 no longer compliant with its own RFC<br></div><div>(3) It would certainly be a non-trivial amount of work. Since chan_iax2 can really only be tested against itself, it makes verifying that such a change does not inject a large amount of risk into the driver rather difficult.<br> </div></div><br>-- <br><div class="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div>Matthew Jordan<br></div><div>Digium, Inc. | Director of Technology<br></div><div>445 Jan Davis Drive NW - Huntsville, AL 35806 - USA</div><div>Check us out at: <a href="http://digium.com" target="_blank">http://digium.com</a> & <a href="http://asterisk.org" target="_blank">http://asterisk.org</a></div></div></div></div></div>
</div></div>