5 Apr
2017
5 Apr
'17
9:53 p.m.
On Wednesday, April 5, 2017 8:55:36 AM CDT Richard Fuchs wrote:
On 04/04/2017 09:33 PM, Anthony Joseph Messina wrote:
Thanks, Richard. I am amidst a call right now which shows it's kernelized.
The output from cat /proc/rtpengine/0/list shows nothing changing throughout
the call (after repeating the command).
rtpengine[29508]: INFO: [0_4088656235(a)10.77.79.165 port 30520]: Confirmed peer
address as 10.77.79.3:10646
rtpengine[29508]: INFO: [0_4088656235(a)10.77.79.165 port 30534]: Confirmed peer
address as 10.77.79.165:12668
rtpengine[29508]: INFO: [0_4088656235(a)10.77.79.165 port 30534]: Kernelizing
media stream: 10.77.79.165:12668
rtpengine[29508]: DEBUG: [0_4088656235(a)10.77.79.165 port 30534]: enabling
kernel intercept with stream idx 2
rtpengine[29508]: INFO: [0_4088656235(a)10.77.79.165 port 30520]: Kernelizing
media stream: 10.77.79.3:10646
rtpengine[29508]: DEBUG: [0_4088656235(a)10.77.79.165 port 30520]: enabling
kernel intercept with stream idx 0
rtpengine[29508]: INFO: [0_4088656235(a)10.77.79.165 port 30521]: Confirmed peer
address as 10.77.79.3:10647
rtpengine[29508]: INFO: [0_4088656235(a)10.77.79.165 port 30535]: Confirmed peer
address as 10.77.79.165:12669
~]# cat /proc/rtpengine/0/list
local inet4 10.77.79.3:30520
src inet4 10.77.79.3:30534
dst inet4 10.77.79.165:12668
stats: 0 bytes, 0 packets,
0 errors
RTP payload type 0: 0 bytes, 0
packets
RTP payload type 9: 0 bytes, 0
packets
RTP payload type 101: 0 bytes, 0
packets
RTP payload type 106: 0 bytes, 0
packets
SRTP encryption (outgoing) parameters:
cipher: AES-CM-128
HMAC: HMAC-SHA1
auth tag length: 10
local inet4 10.77.79.3:30534
src inet4 10.77.79.3:30520
dst inet4 10.77.79.3:10646
stats: 0 bytes, 0 packets,
0 errors
RTP payload type 0: 0 bytes, 0
packets
RTP payload type 9: 0 bytes, 0
packets
RTP payload type 101: 0 bytes, 0
packets
RTP payload type 106: 0 bytes, 0
packets
SRTP decryption (incoming) parameters:
cipher: AES-CM-128
HMAC: HMAC-SHA1
auth tag length: 10
--
Anthony - https://messinet.com/ - https://messinet.com/~amessina/gallery
F9B6 560E 68EA 037D 8C3D D1C9 FF31 3BDB D9D8 99B6
After more digging, I see (from the Asterisk
perspective) that after a
certain amount of time, the "RTCP report" size gets smaller and this is
the point at which the audio from Asterisk back to the softphone is
dropped. Again, this audio drop occurred around 19 minutes into the
call.
I'm not sure this means anything, but perhaps it can point someone more
knowledgeable in the right direction.
A good place to start is to inspect /proc/rtpengine/0/list and check the
packet and byte counters for the respective local ports. This way you
can check if incoming packets are actually arriving at rtpengine.