[Home]

Summary:ASTERISK-09329: RTPAUDIOQOS does not always report values
Reporter:John Todd (jtodd)Labels:
Date Opened:2007-04-26 19:00:06Date Closed:2011-06-07 14:07:26
Priority:MinorRegression?No
Status:Closed/CompleteComponents:Core/RTP
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:
Description:In a simple case, RTPAUDIOQOS does not report stats on calls that are terminated by the called side.


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

As an example: A SIP call created to the following context:

[from-jt]
exten => 1,n,Answer
exten => 1,n,Playback(tt-monkeys)
exten => 1,n,NoOp(First Cut: ${RTPAUDIOQOS})
exten => 1,n,Hangup
exten => h,1,NoOp(After Hangup: ${RTPAUDIOQOS})

If the SIP phone hangs up during the playback, the RTPAUDIOQOS settings will be correctly populated.  


Here is an example where the Playback runs out and the call is hung up using Hangup, which incorrectly shows null strings:

   -- Executing [1@from-jt:1] Answer("SIP/2208-09212990", "") in new stack
   -- Executing [1@from-jt:2] Playback("SIP/2208-09212990", "tt-monkeys") in new stack
   -- <SIP/2208-09212990> Playing 'tt-monkeys.ulaw' (language 'en')
   -- Executing [1@from-jt:3] NoOp("SIP/2208-09212990", "First Cut: ") in new stack
   -- Executing [1@from-jt:4] Hangup("SIP/2208-09212990", "") in new stack
 == Spawn extension (from-jt, 1, 4) exited non-zero on 'SIP/2208-09212990'
   -- Executing [h@from-jt:1] NoOp("SIP/2208-09212990", "After Hangup: ") in new stack
public*CLI>


Here is an example where the SIP handset is hung up during the playback of the audio stream, which provides the correct response:

public*CLI>
   -- Executing [1@from-jt:1] Answer("SIP/2208-09212990", "") in new stack
   -- Executing [1@from-jt:2] Playback("SIP/2208-09212990", "tt-monkeys") in new stack
   -- <SIP/2208-09212990> Playing 'tt-monkeys.ulaw' (language 'en')
 == Spawn extension (from-jt, 1, 2) exited non-zero on 'SIP/2208-09212990'
   -- Executing [h@from-jt:1] NoOp("SIP/2208-09212990", "After Hangup: ssrc=1346255525;themssrc=1231180298;lp=0;rxjitter=0.005128;rxcount=184;txjitter=0.000000;txcount=187;rlp=0;rtt=0.000000") in new stack
public*CLI>
Comments:By: Tilghman Lesher (tilghman) 2007-04-26 21:16:18

These values are already available in the CHANNEL() dialplan function:
CHANNEL(rtpqos,audio,all).  Going forward, this should probably be where they should be accessed.
By: Olle Johansson (oej) 2007-04-27 02:58:57

Considering that we have one incoming and one outgoing channel -which one is reported and how do I reach the other side stats?
By: Tilghman Lesher (tilghman) 2007-04-27 08:12:13

It's reported for whichever side the dialplan function is run for.
By: John Todd (jtodd) 2007-04-27 18:11:15

Interestingly, it seems that similar problems were reported on the older variants of this function:

http://bugs.digium.com/view.php?id=9043

On another note:

I'm fine with this function vanishing and turning into the "CHANNEL()" function.  However, I think the CHANNEL() function needs some work, both on a practical side as well as a feature side.  I've opened a new ticket on several issues, and this ticket can probably be closed in favor of the new tickets.  (http://bugs.digium.com/view.php?id=9622 and http://bugs.digium.com/view.php?id=9620)
By: Tilghman Lesher (tilghman) 2007-04-29 18:47:25

Closed upon request of reporter.