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

[Jonathan Rose]

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