### Description Altough setting TOS to -1, the TOS-header of the outgoing RTP stream is always set to the default TOS (184, resp 0xb0).
### Troubleshooting
#### Reproduction
Use following flags in rtpengine_manage: `rtpengine_manage("ICE=remove record-call=on call-id=$avp(correlationId) TOS=-1");` and set up a dialog, where the RTP-stream from the UA towards the rtpengine has TOS-field (e.g.: 0x80).
Based on the documentation
A value of -1 may be used to leave the currently used TOS unchanged.
the expected behavior was, that also the stream from rtpengine to the other UA has the same TOS field. However, the stream from rtpengine has the default value 0xb0
#### Debugging Data
Relevant call in kamailio.cfg: ``` rtpengine_manage("ICE=remove record-call=on call-id=$avp(correlationId) TOS=-1"); ```
#### Log Messages
<!-- Check the syslog file and if there are relevant log messages printed by Kamailio, add them next, or attach to issue, or provide a link to download them (e.g., to a pastebin site). -->
``` 2020-04-27T14:50:08.001+02:00 vm1 rtpengine[129780] debug: DEBUG: timer run time = 0.000060 sec 2020-04-27T14:50:08.001+02:00 vm1 rtpengine[130247] debug: DEBUG: timer run time = 0.000060 sec 2020-04-27T14:50:08.968+02:00 vm1 rtpengine[129780] info: INFO: [75CzR7D4L7Cjjpdhq1dbyS]: Received command 'offer' from 192.168.211.21:47072 2020-04-27T14:50:08.968+02:00 vm1 rtpengine[129780] debug: DEBUG: [75CzR7D4L7Cjjpdhq1dbyS]: Dump for 'offer' from 192.168.211.21:47072: { "supports": [ "load limit" ], "sdp": "v=0 o=UA1 0 1 IN IP4 127.0.0.1 s=testcall t=0 0 m=audio 6001 RTP/AVP 8 c=IN IP4 127.0.0.1 a=rtpmap:8 PCMA/8000 a=sendrecv a=ptime:20 a=maxptime:20 a=interval:20 ", "ICE": "remove", "record-call": "on", "TOS": -1, "call-id": "75CzR7D4L7Cjjpdhq1dbyS", "received-from": [ "IP4", "127.0.0.1" ], "from-tag": "1", "command": "offer" } 2020-04-27T14:50:08.968+02:00 vm1 rtpengine[129780] notice: NOTICE: [75CzR7D4L7Cjjpdhq1dbyS]: Creating new call 2020-04-27T14:50:08.969+02:00 vm1 rtpengine[129780] notice: NOTICE: [75CzR7D4L7Cjjpdhq1dbyS]: Turning on call recording. 2020-04-27T14:50:08.969+02:00 vm1 rtpengine[129780] debug: DEBUG: [75CzR7D4L7Cjjpdhq1dbyS]: kernel call idx is 0 2020-04-27T14:50:08.973+02:00 vm1 rtpengine[129780] debug: DEBUG: [75CzR7D4L7Cjjpdhq1dbyS]: Default sink codec is PCMA/8000 2020-04-27T14:50:08.973+02:00 vm1 rtpengine[129780] debug: DEBUG: [75CzR7D4L7Cjjpdhq1dbyS]: 0 DTMF sink entries 2020-04-27T14:50:08.973+02:00 vm1 rtpengine[129780] debug: DEBUG: [75CzR7D4L7Cjjpdhq1dbyS]: Creating codec handler for PCMA/8000 2020-04-27T14:50:08.973+02:00 vm1 rtpengine[129780] debug: DEBUG: [75CzR7D4L7Cjjpdhq1dbyS]: Sink supports codec PCMA/8000 2020-04-27T14:50:08.973+02:00 vm1 rtpengine[129780] debug: DEBUG: [75CzR7D4L7Cjjpdhq1dbyS]: Using passthrough handler for PCMA/8000 2020-04-27T14:50:08.973+02:00 vm1 rtpengine[129780] debug: DEBUG: [75CzR7D4L7Cjjpdhq1dbyS]: creating send_timer 2020-04-27T14:50:08.973+02:00 vm1 rtpengine[129780] debug: DEBUG: [75CzR7D4L7Cjjpdhq1dbyS]: creating send_timer 2020-04-27T14:50:08.973+02:00 vm1 rtpengine[129780] debug: DEBUG: [75CzR7D4L7Cjjpdhq1dbyS]: creating send_timer 2020-04-27T14:50:08.973+02:00 vm1 rtpengine[129780] debug: DEBUG: [75CzR7D4L7Cjjpdhq1dbyS]: creating send_timer 2020-04-27T14:50:08.973+02:00 vm1 rtpengine[129780] debug: DEBUG: [75CzR7D4L7Cjjpdhq1dbyS]: kernel stream idx is 0 2020-04-27T14:50:08.973+02:00 vm1 rtpengine[129780] debug: DEBUG: [75CzR7D4L7Cjjpdhq1dbyS]: kernel stream idx is 1 2020-04-27T14:50:08.973+02:00 vm1 rtpengine[129780] debug: DEBUG: [75CzR7D4L7Cjjpdhq1dbyS]: set FILLED flag for stream 127.0.0.1:6001 2020-04-27T14:50:08.973+02:00 vm1 rtpengine[129780] debug: DEBUG: [75CzR7D4L7Cjjpdhq1dbyS]: set FILLED flag for stream 127.0.0.1:6002 2020-04-27T14:50:08.974+02:00 vm1 rtpengine[129780] debug: DEBUG: [75CzR7D4L7Cjjpdhq1dbyS]: kernel stream idx is 2 2020-04-27T14:50:08.974+02:00 vm1 rtpengine[129780] debug: DEBUG: [75CzR7D4L7Cjjpdhq1dbyS]: kernel stream idx is 3 2020-04-27T14:50:08.974+02:00 vm1 rtpengine[129780] info: INFO: [75CzR7D4L7Cjjpdhq1dbyS]: Replying to 'offer' from 192.168.211.21:47072 (elapsed time 0.002197 sec) 2020-04-27T14:50:08.974+02:00 vm1 rtpengine[129780] debug: DEBUG: [75CzR7D4L7Cjjpdhq1dbyS]: Response dump for 'offer' to 192.168.211.21:47072: { "sdp": "v=0 o=UA1 0 1 IN IP4 127.0.0.1 s=testcall t=0 0 m=audio 6004 RTP/AVP 8 c=IN IP4 192.168.211.21 a=maxptime:20 a=interval:20 a=rtpmap:8 PCMA/8000 a=sendrecv a=rtcp:6005 a=ptime:20 ", "result": "ok" } 2020-04-27T14:50:08.982+02:00 vm1 rtpengine[129780] info: INFO: [75CzR7D4L7Cjjpdhq1dbyS]: Received command 'answer' from 192.168.211.21:60917 2020-04-27T14:50:08.982+02:00 vm1 rtpengine[129780] debug: DEBUG: [75CzR7D4L7Cjjpdhq1dbyS]: Dump for 'answer' from 192.168.211.21:60917: { "supports": [ "load limit" ], "sdp": "v=0 o=UA2 0 1 IN IP4 127.0.0.1 s=testcall t=0 0 m=audio 6000 RTP/AVP 8 c=IN IP4 127.0.0.1 a=rtpmap:8 PCMA/8000 a=sendrecv a=ptime:20 a=maxptime:20 a=interval:20 ", "ICE": "remove", "record-call": "on", "TOS": -1, "call-id": "75CzR7D4L7Cjjpdhq1dbyS", "received-from": [ "IP4", "127.0.0.1" ], "from-tag": "1", "to-tag": "SIPp1", "command": "answer" } 2020-04-27T14:50:08.982+02:00 vm1 rtpengine[129780] debug: DEBUG: [75CzR7D4L7Cjjpdhq1dbyS]: Default sink codec is PCMA/8000 2020-04-27T14:50:08.983+02:00 vm1 rtpengine[129780] debug: DEBUG: [75CzR7D4L7Cjjpdhq1dbyS]: 0 DTMF sink entries 2020-04-27T14:50:08.983+02:00 vm1 rtpengine[129780] debug: DEBUG: [75CzR7D4L7Cjjpdhq1dbyS]: Creating codec handler for PCMA/8000 2020-04-27T14:50:08.983+02:00 vm1 rtpengine[129780] debug: DEBUG: [75CzR7D4L7Cjjpdhq1dbyS]: Sink supports codec PCMA/8000 2020-04-27T14:50:08.984+02:00 vm1 rtpengine[129780] debug: DEBUG: [75CzR7D4L7Cjjpdhq1dbyS]: Using passthrough handler for PCMA/8000 2020-04-27T14:50:08.984+02:00 vm1 rtpengine[129780] debug: DEBUG: [75CzR7D4L7Cjjpdhq1dbyS]: set FILLED flag for stream 127.0.0.1:6000 2020-04-27T14:50:08.985+02:00 vm1 rtpengine[129780] debug: DEBUG: [75CzR7D4L7Cjjpdhq1dbyS]: set FILLED flag for stream 127.0.0.1:6001 2020-04-27T14:50:08.985+02:00 vm1 rtpengine[129780] info: INFO: [75CzR7D4L7Cjjpdhq1dbyS]: Replying to 'answer' from 192.168.211.21:60917 (elapsed time 0.000265 sec) 2020-04-27T14:50:08.985+02:00 vm1 rtpengine[129780] debug: DEBUG: [75CzR7D4L7Cjjpdhq1dbyS]: Response dump for 'answer' to 192.168.211.21:60917: { "sdp": "v=0 o=UA2 0 1 IN IP4 127.0.0.1 s=testcall t=0 0 m=audio 6032 RTP/AVP 8 c=IN IP4 192.168.211.21 a=maxptime:20 a=interval:20 a=rtpmap:8 PCMA/8000 a=sendrecv a=rtcp:6033 a=ptime:20 ", "result": "ok" } 2020-04-27T14:50:09.001+02:00 vm1 rtpengine[130247] debug: DEBUG: timer run time = 0.000057 sec 2020-04-27T14:50:09.001+02:00 vm1 rtpengine[129780] debug: DEBUG: timer run time = 0.000059 sec 2020-04-27T14:50:11.001+02:00 vm1 rtpengine[130247] debug: DEBUG: timer run time = 0.000041 sec 2020-04-27T14:50:11.001+02:00 vm1 rtpengine[129780] debug: DEBUG: timer run time = 0.000043 sec 2020-04-27T14:50:11.494+02:00 vm1 rtpengine[129780] info: INFO: Received command 'ping' from 192.168.211.21:51806 2020-04-27T14:50:11.494+02:00 vm1 rtpengine[129780] debug: DEBUG: Dump for 'ping' from 192.168.211.21:51806: { "command": "ping" } 2020-04-27T14:50:11.495+02:00 vm1 rtpengine[129780] info: INFO: Replying to 'ping' from 192.168.211.21:51806 (elapsed time 0.000001 sec) 2020-04-27T14:50:11.495+02:00 vm1 rtpengine[129780] debug: DEBUG: Response dump for 'ping' to 192.168.211.21:51806: { "result": "pong" } 2020-04-27T14:50:13.001+02:00 vm1 rtpengine[130247] debug: DEBUG: timer run time = 0.000050 sec 2020-04-27T14:50:13.001+02:00 vm1 rtpengine[129780] debug: DEBUG: timer run time = 0.000058 sec 2020-04-27T14:50:14.001+02:00 vm1 rtpengine[130247] debug: DEBUG: timer run time = 0.000045 sec 2020-04-27T14:50:14.001+02:00 vm1 rtpengine[129780] debug: DEBUG: timer run time = 0.000056 sec 2020-04-27T14:50:14.001+02:00 vm1 rtpengine[129780] info: INFO: [75CzR7D4L7Cjjpdhq1dbyS port 6032]: Confirmed peer address as 127.0.0.1:6001 2020-04-27T14:50:14.001+02:00 vm1 rtpengine[129780] debug: DEBUG: [75CzR7D4L7Cjjpdhq1dbyS port 6032]: Forward to sink endpoint: 127.0.0.1:6000 (RTP seq 19303 TS 160) 2020-04-27T14:50:14.021+02:00 vm1 rtpengine[129780] debug: DEBUG: [75CzR7D4L7Cjjpdhq1dbyS port 6032]: Forward to sink endpoint: 127.0.0.1:6000 (RTP seq 19304 TS 320) 2020-04-27T14:50:14.040+02:00 vm1 rtpengine[129780] debug: DEBUG: [75CzR7D4L7Cjjpdhq1dbyS port 6032]: Forward to sink endpoint: 127.0.0.1:6000 (RTP seq 19305 TS 480) 2020-04-27T14:50:14.061+02:00 vm1 rtpengine[129780] debug: DEBUG: [75CzR7D4L7Cjjpdhq1dbyS port 6032]: Forward to sink endpoint: 127.0.0.1:6000 (RTP seq 19306 TS 640) 2020-04-27T14:50:14.080+02:00 vm1 rtpengine[129780] debug: DEBUG: [75CzR7D4L7Cjjpdhq1dbyS port 6032]: Forward to sink endpoint: 127.0.0.1:6000 (RTP seq 19307 TS 800) 2020-04-27T14:50:14.102+02:00 vm1 rtpengine[129780] debug: DEBUG: [75CzR7D4L7Cjjpdhq1dbyS port 6032]: Forward to sink endpoint: 127.0.0.1:6000 (RTP seq 19308 TS 960) 2020-04-27T14:50:14.106+02:00 vm1 rtpengine[129780] info: INFO: [75CzR7D4L7Cjjpdhq1dbyS port 6004]: Confirmed peer address as 127.0.0.1:6000 2020-04-27T14:50:14.106+02:00 vm1 rtpengine[129780] info: INFO: [75CzR7D4L7Cjjpdhq1dbyS port 6004]: Kernelizing media stream: 127.0.0.1:6000 2020-04-27T14:50:14.106+02:00 vm1 rtpengine[129780] debug: DEBUG: [75CzR7D4L7Cjjpdhq1dbyS port 6004]: enabling kernel intercept with stream idx 0 2020-04-27T14:50:14.106+02:00 vm1 rtpengine[129780] debug: DEBUG: [75CzR7D4L7Cjjpdhq1dbyS port 6004]: Forward to sink endpoint: 127.0.0.1:6001 (RTP seq 19303 TS 160) 2020-04-27T14:50:14.121+02:00 vm1 rtpengine[129780] info: INFO: [75CzR7D4L7Cjjpdhq1dbyS port 6032]: Kernelizing media stream: 127.0.0.1:6001 2020-04-27T14:50:14.121+02:00 vm1 rtpengine[129780] debug: DEBUG: [75CzR7D4L7Cjjpdhq1dbyS port 6032]: enabling kernel intercept with stream idx 2 2020-04-27T14:50:14.121+02:00 vm1 rtpengine[129780] debug: DEBUG: [75CzR7D4L7Cjjpdhq1dbyS port 6032]: Forward to sink endpoint: 127.0.0.1:6000 (RTP seq 19309 TS 1120)
```
#### SIP Traffic
<!-- If the issue is exposed by processing specific SIP messages, grab them with ngrep or save in a pcap file, then add them next, or attach to issue, or provide a link to download them (e.g., to a pastebin site). -->
``` No SIP-related issue (RTP only) ```
### Possible Solutions
### Additional Information
* **Kamailio Version** - output of `kamailio -v`
``` rtpengine: 8.2.1 kamailio: 5.3.3 ```
* **Operating System**:
<!-- Details about the operating system, the type: Linux (e.g.,: Debian 8.4, Ubuntu 16.04, CentOS 7.1, ...), MacOS, xBSD, Solaris, ...; Kernel details (output of `uname -a`) --> RHEL 7.6 ``` Linux vm1 3.10.0-957.el7.x86_64 #1 SMP Thu Oct 4 20:48:51 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux ```
Maybe @rfuchs can check this one.
Rtpengine always sets the TOS for outgoing packets. The value of -1 means to leave the underlying default (i.e. the global value) unchanged. It doesn't mean to use the same TOS value as was set for received packets.
Thanks for that clarification - this is what I observed ;-)
From this description in the module's documentation:
TOS=... - change the IP TOS value for all outgoing RTP packets within the entire call in both directions. Only honoured in an “offer”, ignored for an “answer”. Valid values are 0 through 255, given in decimal. If this option is not specified, the TOS value will revert to the default TOS (normally 184). A value of -1 may be used to leave the currently used TOS unchanged.
Resp. also from the source-comment in daemon/calls.c:
``` /* Handle TOS= parameter. Negative value = no change, not present or too large = * revert to default, otherwise set specified value. We only do it in an offer, but * then for both directions. */ ``` I interpreted "no change" as "as received".
What is then actually the difference between negative value ("no change") and > 255 "revert to default"? Both result in the same default?
If you set TOS=123 in the first offer, then setting TOS=-1 in a subsequent offer would leave 123 in place, while omitting TOS= would revert the TOS back to the global default (e.g. taken from the config file).
Thank you very much for the clarification. Maybe it would be good to add it to the documentation.
The original description of the issue is for sure invalid, and can be closed/rejected.
If you want or need the kind of TOS passthrough you're talking about, feel free to open a feature request over at https://github.com/sipwise/rtpengine
Closed #2303.
-
Daniel-Constantin Mierla -
mihovilkolaric
-
Richard Fuchs