[asterisk-users] Not able to get remote channel variables containing RTCP values

Matthew Jordan mjordan at digium.com
Mon Dec 2 11:40:35 CST 2013

On Mon, Dec 2, 2013 at 10:54 AM, Thomas Rechberger
<t.rechberger at gmail.com>wrote:

> I am not sure if its just me, but i am able to get only local channel
> variables containing RTCP QOS values.
> The Version is 1.8.14.
> I want to store values of bridged channel in CDR.
> Phone is Cisco 7941 SIP and with sip show channelstats i see all the
> relevant information (jitter,packet loss) i want to get. It even calculates
> packet loss in %. But i am not able to store it to CDR.
> Asterisk 1.4 seems to have had a function ast_rtp_get_quality but i cant
> find any information about that in sources from 1.8, only a short reference
> in 1.4.
> Channel variables like CHANNEL(rtpqos,audio,rxjitter) show only
> information about the local channel. So not really usefull.
> In some old version they seemed to have it changed from remote_jitter to
> rxjitter, local_jitter to txjitter and so on. Was not even documented.

The values that can be extracted are documented:


I'll admit the description of each parameter isn't terribly verbose, but
there is documentation for what they are. The local/remote refers to the
values reported by Asterisk (local) and the endpoint it is communicating
with (remote). This is only for a single channel; bridged channels are not
accessed by this function.

> The 2 variables RTPAUDIOQOSBRIDGED and RTPAUDIOQOS show exactly the things
> i want, but all information is stored in one field so its not really usable
> because it looks ugly in CDR report and doesnt show packet loss in %.

If you wanted, you could parse the values in those channel variables. They
are semi-colon delineated lists with fixed fields, so if there are
particular values you want you can extract them. This does mean doing a bit
of string parsing in the dialplan, but it is a viable option.

> The following interesting variables are completely empty (show 0), here is
> how i write it to CDR in h:
> exten => s,n,Set(CDR(txj)=${RTPAUDIOQOSJITTER})
> exten => s,n,Set(CDR(rxj)=${RTPAUDIOQOSJITTERBRIDGED})
> exten => s,n,Set(CDR(txpl)=${RTPAUDIOQOSLOSS})
> exten => s,n,Set(CDR(rxpl)=${RTPAUDIOQOSLOSSBRIDGED})
> exten => s,n,Set(CDR(txrtt)=${RTPAUDIOQOSRTT})
> exten => s,n,Set(CDR(rxrtt)=${RTPAUDIOQOSRTTBRIDGED})
> I also checked variables during call with featurecode, but also empty.
> Did i oversee something? Is it the same in Version 11 ?
> I dont want to mess with Voipmonitor because i only need 2 variables of
> remote channel. If sip show channelstats is showing everything correctly,
> it should be not that hard to get that information.

Since you want to write this into the inbound channel's CDR, there isn't
much of another option other than to parse out the channel variables, even
in Asterisk 11.

Technically, in 11, you can use a Pre-Dial handler to attach a Hangup
Handler to the outbound channel. The hangup handler is a subroutine that
will be executed on the outbound channel when it is hung up. In the hangup
handler, you can use the CHANNEL function to extract the values directly
from the outbound channel - however, you can't use that to modify the CDR
on the inbound channel, so that's of limited use to how you want to use it.

Your best option would be to parse out the values in the various channel
variables and store the ones you want.

As an aside: as time has gone on, the idea of always reaching across a
bridge to get another channel's values has become less favoured. Such a
concept doesn't do well with ad-hoc multi-party bridges or conferences, and
thus isn't always sustainable in all scenarios. For the most part, the
emphasis in latter versions is to give people access to the specific
channel that they want to manipulate/retrieve information from, as opposed
to relying on the two-party nature of bridges.

This usually works pretty well, except for CDRs, which are generally a mess
no matter what. :-)


Matthew Jordan
Digium, Inc. | Engineering Manager
445 Jan Davis Drive NW - Huntsville, AL 35806 - USA
Check us out at: http://digium.com & http://asterisk.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-users/attachments/20131202/169e7910/attachment.html>

More information about the asterisk-users mailing list