[Home]

Summary:ASTERISK-09341: CHANNEL QOS functions do not report stats after hangup
Reporter:John Todd (jtodd)Labels:
Date Opened:2007-04-27 18:02:07Date Closed:2007-06-29 13:08:21
Priority:MinorRegression?No
Status:Closed/CompleteComponents:Core/RTP
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:( 0) rtpqos-bt.txt
Description:
Depending on what side of a call hangs up first, the CHANNEL(rtpqos...) features do not return with any data.  This is related to http://bugs.digium.com/view.php?id=9610  however it seems to have the opposite behaviors.

Upon examination, it seems that as soon as the channel is freed (goes to "h" for whatever reason) then the CHANNEL function cannot report the summary data.  This makes it impossible to collect data on channels that hang up, because we're already at "h" by the time we try to collect data out of the CHANNEL function.

Proposed solution: upon channel hangup, store the last RTP QOS data in the CHANNEL function and leave it there until the dialplan exits.  It does not appear to be harmful to do this, and makes post-hangup collection of the data possible.  The "state" item of the function can be used to ensure that the call is terminated if that is required, but it is left to the discretion of the dialplan author.


****** ADDITIONAL INFORMATION ******

Using this dialplan:

[from-jt]
exten => 1,1,Answer
exten => 1,n(monkeys),Playback(tt-monkeys)
exten => 1,n,NoOp(Channel data pre-hangup: ${CHANNEL(rtpqos,audio,all)})
exten => 1,n,Hangup

exten => h,1,NoOp(Channel data post-hangup: ${CHANNEL(${CHANNEL})})
exten => h,n,Hangup



Here is a "correct" report, where I allow Asterisk to generate the BYE on the session.  The value for RTP QOS appear to be filled in correctly before "Hangup" is called, and then after Hangup is called:


public*CLI>
   -- Executing [1@from-jt:1] Answer("SIP/2208-09445578", "") in new stack
   -- Executing [1@from-jt:2] Playback("SIP/2208-09445578", "tt-monkeys") in new stack
   -- <SIP/2208-09445578> Playing 'tt-monkeys.ulaw' (language 'en')
   -- Executing [1@from-jt:3] NoOp("SIP/2208-09445578", "Channel data pre-hangup: ssrc=743342575;themssrc=852380759;lp=4;rxjitter=0.007992;rxcount=802;txjitter=0.000000;txcount=809;rlp=0;rtt=0.000000") in new stack
   -- Executing [1@from-jt:4] Hangup("SIP/2208-09445578", "") in new stack
 == Spawn extension (from-jt, 1, 4) exited non-zero on 'SIP/2208-09445578'
   -- Executing [h@from-jt:1] NoOp("SIP/2208-09445578", "Channel data post-hangup: ") in new stack
   -- Executing [h@from-jt:2] Hangup("SIP/2208-09445578", "") in new stack
 == Spawn extension (from-jt, h, 2) exited non-zero on 'SIP/2208-09445578'
public*CLI>


And now when I hang up the SIP client before the monkeys recording finishes playing, I get this unexpected data, which is null values in the CHANNEL QOS function results, in post-hangup:


public*CLI>
   -- Executing [1@from-jt:1] Answer("SIP/2208-09446bb8", "") in new stack
   -- Executing [1@from-jt:2] Playback("SIP/2208-09446bb8", "tt-monkeys") in new stack
   -- <SIP/2208-09446bb8> Playing 'tt-monkeys.ulaw' (language 'en')
 == Spawn extension (from-jt, 1, 2) exited non-zero on 'SIP/2208-09446bb8'
   -- Executing [h@from-jt:1] NoOp("SIP/2208-09446bb8", "Channel data post-hangup: ") in new stack
   -- Executing [h@from-jt:2] Hangup("SIP/2208-09446bb8", "") in new stack
 == Spawn extension (from-jt, h, 2) exited non-zero on 'SIP/2208-09446bb8'
public*CLI>

Comments:By: John Todd (jtodd) 2007-04-27 18:06:11

I have no idea what happened to that first bt file, but this one seems to be better.
By: Olle Johansson (oej) 2007-04-30 02:01:58

...would it hurt if we saved it in the CDR automatically?
By: John Todd (jtodd) 2007-04-30 11:26:29

I have no objections to that, myself.  However, I believe it should still be available in the CHANNEL settings so that the dialplan can do things with the values.

Additionally, you may get some opposition from CDR purists.  :-)
By: Olle Johansson (oej) 2007-05-02 05:50:51

Well, since we have custom CDR variables we might as well use them and the purists can configure the pure CDR's they want...
By: Joshua C. Colp (jcolp) 2007-06-29 13:08:21

I can confirm that under the latest 1.4 and trunk this issue is no longer present.