Could a prefix be used to discern dscp vs. tos, such as: tos_audio = dscp:0x18 tos_audio = dscp:24 tos_audio = tos:0x60 tos_audio = tos:96
which would all mean the same thing, although it seems odd to specify dscp when the name is tos_*. On Mon, Feb 10, 2014 at 12:41 PM, George Joseph <[email protected] > wrote: > > On Mon, Feb 10, 2014 at 10:23 AM, Jonathan Rose <[email protected]> wrote: > >> 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. >> >> 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. >> > >> 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. >> >> 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. >> >> 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. >> >> Personally, I favor options 2 and 3. If the community feels differently >> though, I'm open to other approaches. >> >> > 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. > > > >> >> On Mon, Feb 3, 2014 at 11:24 AM, George Joseph < >> [email protected]> wrote: >> >>> >>> As I was playing around with TOS/COS in pjsip last week I noticed some >>> inconsistencies that I'd like to correct... >>> >>> 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. >>> >>> 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. >>> >>> 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... >>> >>> 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. >>> >>> In endpoint, rename tos_audio and tos_video to dscp_audio and dscp_video >>> respectively, then use ast_str2tos to resolve the symbolics. >>> >>> I could also add the new parameters and leave the old ones there for >>> backwards compatibility for a while if that makes sense. >>> >>> What do you think? >>> https://issues.asterisk.org/jira/browse/ASTERISK-23235 >>> >>> >>> >>> > -- > _____________________________________________________________________ > -- Bandwidth and Colocation Provided by http://www.api-digital.com -- > > asterisk-dev mailing list > To UNSUBSCRIBE or update options visit: > http://lists.digium.com/mailman/listinfo/asterisk-dev > -- [image: Digium logo] Scott Griepentrog Digium, Inc · Software Developer 445 Jan Davis Drive NW · Huntsville, AL 35806 · US direct/fax: +1 256 428 6239 · mobile: +1 317 507 4029 Check us out at: http://digium.com · http://asterisk.org
-- _____________________________________________________________________ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
