Summary: | ASTERISK-23235: pjsip transport/tos interpreted differently than endpoint/tos_audio | ||
Reporter: | George Joseph (gjoseph) | Labels: | |
Date Opened: | 2014-01-31 12:12:06.000-0600 | Date Closed: | 2014-03-14 11:47:18 |
Priority: | Minor | Regression? | |
Status: | Closed/Complete | Components: | Resources/res_pjsip |
Versions: | 12.0.0 | Frequency of Occurrence | Constant |
Related Issues: | |||
Environment: | Fedora 20 x86_64 | Attachments: | |
Description: | It appears that setting tos in a transport actually sets the DSCP field in the IP header for SIP packets whereas setting tos_audio in an endpoint sets the old tos field in the IP header for RTP packets.
Example... {code} [sometransport] type=transport tos=12 {code} results in {code} Differentiated Services Field: 0x30 (DSCP 0x0c: Assured Forwarding 12; ECN: 0x00: Not-ECT (Not ECN-Capable Transport)) {code} Note that the DSCP is set to 0x0c (12 dec) BUT {code} [someendpoint] type=endpoint tos_audio=12 {code} results in {code} Differentiated Services Field: 0x0c (DSCP 0x03: Unknown DSCP; ECN: 0x00: Not-ECT (Not ECN-Capable Transport)) {code} Note that in this case, the entire field is set to 0x0c (12 dec) and the DSCP is set to an unknown DSCP. Ideally the name of the parameter should match the actual field set. If it's 'tos' then it should set the old-style tos field in the IP header. If it's 'dscp' it should set the new-style DSCP field in the IP header. I vote for changing them both to dscp and having them set the new-style DSCP header field. | ||
Comments: | By: Jonathan Rose (jrose) 2014-03-14 11:48:09.555-0500 Well, it's not dscp (this change was dropped due to how it would impact configuration) now, but at least its consistent. |