<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">https://issues.asterisk.org/jira/browse/ASTERISK-23235</a><br></div><div><br></div><div><br></div><div><br>
</div></div>