[asterisk-dev] Proposal for PJSIP TOS/COS and DSCP

Mon Feb 10 12:21:34 CST 2014

If it helps understanding the difference between DSCP and TOS, here is a
table I put together years back that shows all the common values.

QoS Values are very confusing, so I'm making a table of the different types
of values that mean the same thing.

 USED FOR Cisco Type Prec. Level DSCP Binary DSCP Hex DSCP Decimal Diffserv/
TOS HexDiffserv/ TOS Dec. Not Used cs7 7 111XXX 40-4E    Not Used cs6 6
 110XXX 30-3E    AUDIO ef 5 101110 2E 46 B8 184  cs5 5 101000 28 40 A0 160
 af43 4 100110 26 38 98 152
 af42 4 10010024 3690144  af41 4 100010 22 34 88 136 cs44100000 20 32 80 128
  af33 3 011110 1E 30 78 120  af32 3 011100 1D 28 70 112  af31 3 011010 1A
 26 68 104 SIP cs3 3 011000 18 24 60 96
  af23 2 010110 16 22 58 88  af22 2 010100 14 20 50 80  af21 2 010010 12 18
 48 72  cs2 2 010000 10 1640 64  af13 1 001110 0E 14 38 56  af12 1 001100 0D
 12 30 48  af11 1 001010 0A 10 28 40  cs1 1 001000 08 8 20 32 DATA be 0
 000000 00 0 0 0
Precedence Values:
7 Reserved 6 Routing 5 Voice 4 Streaming Video 3 Call Signalling 2
 Transactional 1 Bulk Data 0 Best Effort

On Mon, Feb 10, 2014 at 11:23 AM, Jonathan Rose <jrose at digium.com> 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.
>
>
> On Mon, Feb 3, 2014 at 11:24 AM, George Joseph <
> george.joseph at fairview5.com> 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
>>
>
>
>
> --
> Jonathan R. Rose
> Digium, Inc. | Software Engineer
>
> 445 Jan Davis Drive NW - Huntsville, AL 35806 - US
> direct +1 256 428 6139
>
> 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
>

-- 
[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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-dev/attachments/20140210/8938222d/attachment.html>