<div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Feb 10, 2014 at 10:23 AM, Jonathan Rose <span dir="ltr"><<a href="mailto:jrose@digium.com" target="_blank" onclick="window.open('https://mail.google.com/mail/?view=cm&tf=1&to=jrose@digium.com&cc=&bcc=&su=&body=','_blank','location=yes,menubar=yes,resizable=yes,width=800,height=600');return false;">jrose@digium.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">I've been looking into this issue and researching how TOS became the DiffServ field, but there are some issues with changing configuration options during a release that we feel the community needs to have some input on. We have a few options for going forward here, and some are more disruptive to existing configurations than others.<div>

<br></div><div>1. We can change the names of the fields and correct the behavior so that all values set for pjsip.conf are DSCP values. In this case, 'tos' becomes 'dscp' while 'tos_audio' and 'tos_video' become 'dscp_audio' and 'dscp_video' respectively. Databases and the alembic scripts we supply for building them would need to add the new fields. This change would certainly break existing configurations if we don't alias the TOS fields. If we do alias the TOS fields, then people expecting the current behavior will likely have QOS values that don't reflect their expectations. It's an obscure problem that would probably go unnoticed for a while.</div>
</div></blockquote><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><br></div><div>2. We can have the 'tos' value for transports be set correctly by dropping the ECN portion (bits 7 and 8) and have the remaining 6 bits form the DSCP value so that it is being set as a TOS value would be.  The benefit here is that this would require no significant changes on the configuration end while still being more or less accurate to what the settings are. We would probably want to display a warning message indicating that the field doesn't have support for the ECN bits if a value is supplied that includes them. In this scenario, 'tos_audio' and 'tos_video' for endpoints could be left alone and remain functioning as they do in chan_sip.<br>

</div><div><br></div><div>3. We can leave the existing TOS values functioning in the TOS manner while adding DSCP values that override them if provided. This would require correcting the behavior of the 'tos' setting for transports while we leave 'tos_audio' and 'tos_video' in 12 and then adding options for 'dscp', 'dscp_audio', and 'dscp_video' to trunk. In trunk the TOS options would be considered deprecated (but still functional). This is probably the cleanest way to do it, but it's still a bit more disruptive (when Asterisk 13 gets rolled out anyway) than option 2.<br>

</div><div><br></div><div>Another thing to consider is whether or not we want to add support for reading the TOS/DSCP values as strings. While this wouldn't break any existing pjsip.conf files, we would need to update the alembic scripts for changing the TOS values to be strings in databases and this would require a little effort in upgrades. This is another change that might be better left as trunk only.</div>

<div><br></div><div>Personally, I favor options 2 and 3. If the community feels differently though, I'm open to other approaches.</div></div><div class="gmail_extra"><br></div></blockquote><div> </div><div>I'd say Option 3 plus the ability to use the strings.  They remove the ambiguity of whether a number is a DSCP or TOS value.</div>
<div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Feb 3, 2014 at 11:24 AM, George Joseph <span dir="ltr"><<a href="mailto:george.joseph@fairview5.com" target="_blank" onclick="window.open('https://mail.google.com/mail/?view=cm&tf=1&to=george.joseph@fairview5.com&cc=&bcc=&su=&body=','_blank','location=yes,menubar=yes,resizable=yes,width=800,height=600');return false;">george.joseph@fairview5.com</a>></span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><br><div>As I was playing around with TOS/COS in pjsip last week I noticed some inconsistencies that I'd like to correct...</div>

<div><br></div><div>There's a 'tos' parameter on the transport object but not only does it actually set DSCP instead of TOS, it sets it in pjproject only and therefore for signalling only.</div>
<div><br></div><div>There are tos_audio and tos_video parameters on endpoint which do set tos for the rtp engine but they don't accept hex or symbolic values as chan_sip does.</div><div><br></div><div>So, given that DSCP has been around for a while and that's what the symbolic values represent anyway, Id like to do the following...</div>


<div><br></div><div>In transport, rename tos and cos to dscp_sip and cos_sip respectively and for dscp_sip,  create a new function ast_str2dscp() as a companion to the existing ast_str2tos that resolves the symbolics.  The new function is needed because while the existing ast_str2tos function takes in a string representation of DSCP, it left-shifts it 2 bits to go into the rtp_engine's tos field.  pjproject only accepts dscp.</div>


<div><br></div><div>In endpoint, rename tos_audio and tos_video to dscp_audio and dscp_video respectively, then use ast_str2tos to resolve the symbolics.</div><div><br></div><div>I could also add the new parameters and leave the old ones there for backwards compatibility for a while if that makes sense.</div>


<div><br></div><div>What do you think?</div><div><a href="https://issues.asterisk.org/jira/browse/ASTERISK-23235" target="_blank">https://issues.asterisk.org/jira/browse/ASTERISK-23235</a><br></div><div><br></div><div><br>

</div><div><br></div></div></blockquote></div></div></blockquote></div></div></div>