-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviewboard.asterisk.org/r/3304/#review11079
-----------------------------------------------------------

Ship it!


I verified it's working consistently and correctly.  Looking forward to phase 2!

- George Joseph


On March 5, 2014, 1:19 p.m., Jonathan Rose wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviewboard.asterisk.org/r/3304/
> -----------------------------------------------------------
> 
> (Updated March 5, 2014, 1:19 p.m.)
> 
> 
> Review request for Asterisk Developers, George Joseph, Kevin Harwell, and 
> Matt Jordan.
> 
> 
> Bugs: ASTERISK-23235
>     https://issues.asterisk.org/jira/browse/ASTERISK-23235
> 
> 
> Repository: Asterisk
> 
> 
> Description
> -------
> 
> As was discussed on the mailing list, current behavior of the 'tos' setting 
> for PJSIP transports is to interpret this value as a DSCP value. The tos 
> settings (tos_audio/tos_video) for PJSIP endpoints on the other hand are 
> interpreted as TOS values as their name would imply. This patch changes the 
> transport TOS value to comply with the old behavior and allows for all TOS 
> values to be set as strings from the DSCP string pool using the ast_str2tos 
> function.
> 
> Upon examining the alembic scripts (which needed to be updated to allow for 
> string values on the TOS settings), I noticed that both TOS and COS values 
> (all of them) were set to YES/NO enum values. Obviously that's not proper 
> since COS is an integer between 0 and 7 and TOS was previously an integer as 
> well. Since I had to fix TOS anyway, I went ahead and updated the COS values 
> to use integers as well.
> 
> NOTE: This is phase 1 of the effort. Phase 2 will deprecate the TOS values 
> for both object types in favor of more modern DSCP fields. The TOS values 
> will remain usable, but the DSCP values will override them if present.
> 
> 
> Diffs
> -----
> 
>   /branches/12/res/res_pjsip/pjsip_configuration.c 409678 
>   /branches/12/res/res_pjsip/config_transport.c 409678 
>   /branches/12/main/acl.c 409678 
>   /branches/12/include/asterisk/acl.h 409678 
>   
> /branches/12/contrib/ast-db-manage/config/versions/4c573e7135bd_fix_tos_field_types.py
>  PRE-CREATION 
> 
> Diff: https://reviewboard.asterisk.org/r/3304/diff/
> 
> 
> Testing
> -------
> 
> Tested that wireshark would send the same DSCP values in SIP packets when 
> using a tos value for transport that the RTP would have when using 
> tos_audio/video.
> Tested output for various TOS values as strings to see what would happen in 
> the following cases:
>   string input (numerical) - result: successful configuration (if a tos value 
> can't be matched to a DSCP string value though, it will show as 'unknown' 
> when examining the object configuration)
>   string input (alph) from DSCP string pool - result: successful configuration
>   string input (alpha) not from DSCP string pool - result: failed 
> configuration
> 
> Tested upgrading and downgrading with alembic. Made sure the fields ended up 
> matching my expectations in each case.
> 
> 
> Thanks,
> 
> Jonathan Rose
> 
>

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

Reply via email to