When I do: asterisk -x ‘sip show channelstats’ I get output regarding jitter and packet loss thats useful however I do not see any way to associate those lines with actual channels from using asterisk -x ‘core show channels concise’. None of the returned output from channelstats seems to match anything from channels. How can I figure out which channelstats line belongs to which channel?
You would need to use sip show channel against the call-ID to find the owning channel.
Note that a SIP channel may be associated with more than one Asterisk channel during its life time. Also at the end of a call, there may be no Asterisk channel associated with it; Asterisk won’t allow a SIP channel to be removed if it has an owner in place, the owner being its current Asterisk channel. In many case the channel name moves with the SIP channel, but especially when the channel is being shutdown, the name may be modified. The unique ID definitely does change in many cases.
A SIP channel may never have an associated Asterisk channel, although I’m not sure if there will be any channelstats captured in those cases.
Moreover, chan_sip will not be present, not just be disabled, in the next Asterisk release, later this year. As such you should not be spending time on development work that is tied to chan_sip.
Thank you. I will take a look.
At this time I have no plans to upgrade asterisk to any version that does not support chan_sip. Every single time I’ve tried pjsip in the past its been completely unreliable. Thats most likely my fault but it is what it is.
Usage: sip show channelstats Lists all currently active SIP channels RTCP statistics. Note that calls in the much optimized RTP P2P bridge mode will not show any packets here.
Is there any way to force calls into this “much optimized RTP P2P bridge mode” ?
This is the problem I am trying to solve. A problem that has plagued me for more than a decade now.
[Mar 17 18:01:41] WARNING[C-00001e9a] file.c: Translated frame write failed
directmedia=yes (bad examples for chan_sip use a deprecated name, canreinvite), combined with not doing anything that requires Asterisk to see the media, so not recording, no spying, no transcoding, no processing of DTMF for feature codes, except possibly using dtmfmode=info, no use of local channels, etc.