27 Apr
2020
27 Apr
'20
10:27 a.m.
### 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
```
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/kamailio/kamailio/issues/2303
27 Apr
27 Apr
3:19 p.m.
Maybe @rfuchs can check this one.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/kamailio/kamailio/issues/2303#issuecomment-620181233
3:22 p.m.
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.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/kamailio/kamailio/issues/2303#issuecomment-620183167
28 Apr
28 Apr
2:47 a.m.
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?
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/kamailio/kamailio/issues/2303#issuecomment-620414684
8:17 a.m.
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).
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/kamailio/kamailio/issues/2303#issuecomment-620568662
29 Apr
29 Apr
2:19 a.m.
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.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/kamailio/kamailio/issues/2303#issuecomment-621012058
8:14 a.m.
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
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/kamailio/kamailio/issues/2303#issuecomment-621163858
8:14 a.m.
Closed #2303.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/kamailio/kamailio/issues/2303#event-3284320577
1589
days inactive
1591
days old
7 comments
3 participants
participants (3)
-
Daniel-Constantin Mierla -
mihovilkolaric
-
Richard Fuchs