<div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Dec 2, 2013 at 10:54 AM, Thomas Rechberger <span dir="ltr"><<a href="mailto:t.rechberger@gmail.com" target="_blank">t.rechberger@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">I am not sure if its just me, but i am able to get only local channel variables containing RTCP QOS values.<br>

The Version is 1.8.14.<br>
I want to store values of bridged channel in CDR.<br>
<br>
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.<br>
<br>
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.<br>
<br>
Channel variables like CHANNEL(rtpqos,audio,rxjitter) show only information about the local channel. So not really usefull.<br>
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.<br></blockquote><div><br></div><div>The values that can be extracted are documented:<br>
<br><a href="https://wiki.asterisk.org/wiki/display/AST/Function_CHANNEL">https://wiki.asterisk.org/wiki/display/AST/Function_CHANNEL</a><br><br></div><div>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.</div>
<div><br> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
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 %.<br>
</blockquote><div><br></div><div>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.<br>
</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
The following interesting variables are completely empty (show 0), here is how i write it to CDR in h:<br>
exten => s,n,Set(CDR(txj)=${<u></u>RTPAUDIOQOSJITTER})<br>
exten => s,n,Set(CDR(rxj)=${<u></u>RTPAUDIOQOSJITTERBRIDGED})<br>
exten => s,n,Set(CDR(txpl)=${<u></u>RTPAUDIOQOSLOSS})<br>
exten => s,n,Set(CDR(rxpl)=${<u></u>RTPAUDIOQOSLOSSBRIDGED})<br>
exten => s,n,Set(CDR(txrtt)=${<u></u>RTPAUDIOQOSRTT})<br>
exten => s,n,Set(CDR(rxrtt)=${<u></u>RTPAUDIOQOSRTTBRIDGED})<br>
<br>
I also checked variables during call with featurecode, but also empty.<br>
<br>
Did i oversee something? Is it the same in Version 11 ?<br>
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.<span class=""></span></blockquote>
<div><br></div><div>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.<br><br>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.<br>
<br>Your best option would be to parse out the values in the various channel variables and store the ones you want.<br><br></div><div>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.<br>
<br></div><div>This usually works pretty well, except for CDRs, which are generally a mess no matter what. :-)<br></div><div><br>Matt<br></div></div><br>-- <br><div dir="ltr"><div>Matthew Jordan<br></div><div>Digium, Inc. | Engineering Manager</div>
<div>445 Jan Davis Drive NW - Huntsville, AL 35806 - USA</div><div>Check us out at: <a href="http://digium.com" target="_blank">http://digium.com</a> & <a href="http://asterisk.org" target="_blank">http://asterisk.org</a></div>
</div>
</div></div>