[Home]

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-0600Date Closed:2014-03-14 11:47:18
Priority:MinorRegression?
Status:Closed/CompleteComponents:Resources/res_pjsip
Versions:12.0.0 Frequency of
Occurrence
Constant
Related
Issues:
Environment:Fedora 20 x86_64Attachments:
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.