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

Mon Feb 10 12:37:59 CST 2014

On Mon, Feb 10, 2014 at 11:21 AM, Scott Griepentrog <sgriepentrog at digium.com
> wrote:

> 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.
>

To highlight the problem...   a pjsip transport uses column 6 to set the
signalling because pjproject only accepts DSCP decimal values but a pjsip
endpoint uses column 8 to set the media because rtp_engine only accepts TOS
decimal values.

chan_sip accepts columns 2, 7, or 8 and does any appropriate
conversion/lookup, but it doesn't accept 5 or 6.

>
>  USED FOR Cisco Type Prec. Level  DSCP Binary DSCP Hex DSCP Decimal Diffserv/
> TOS Hex Diffserv/ 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 16 40 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
>>>
>>>
>>>
>>>
>>>
>>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-dev/attachments/20140210/8ea1a862/attachment-0001.html>