Summary:	ASTERISK-08784: $RTPAUDIOQOS dosn't report
Reporter:	dario (dario)	Labels:
Date Opened:	2007-02-12 09:35:31.000-0600	Date Closed:	2007-03-27 11:01:08
Priority:	Minor	Regression?	No
Status:	Closed/Complete	Components:	Core/General
Versions:		Frequency of Occurrence
Related Issues:
Environment:		Attachments:	( 0) rtpaudioqos_issue.txt
Description:	There is a problem witch $RTPAUDIOQOS is one scenario: My hardware configuration PSTN <--> Gateway PRI <--> Asterisk <--> Gateway FXS <--> Phone When a connection is coming from PSTN and I disconnect it by hang up from Phone, there is no information about QOS in my CDR. Other scenario ie: disconnect from pstn side, or connection from voip and disconnect either from voip or from pstn works good. My configuration pstn gateway is in context remote fxs gateway is in context test_1 extensions.conf [remote] exten => _997X,1,Set(__TRANSFER_CONTEXT=test_1) exten => _997X,2,Goto(test_1,${EXTEN},1) exten => h,1,NoOp(RTPAUDIOQOS = ${RTPAUDIOQOS}) [test_1] exten => _997X,1,Dial(SIP/${EXTEN},60,tT) exten => _X.,1,Dial(SIP/10.10.119.225/${EXTEN},300,rtT) exten => h,1,NoOp(RTPAUDIOQOS = ${RTPAUDIOQOS})
Comments:	By: Tilghman Lesher (tilghman) 2007-02-12 16:07:37.000-0600 You're right.  In fact, I have no idea why this variable ever worked. By: Olle Johansson (oej) 2007-02-14 09:17:33.000-0600 Can you enable sip history and dumphistory and catch that in a log file? Thanks. By: Olle Johansson (oej) 2007-02-14 10:04:36.000-0600 I think we should move it to a CDR variable, really. By: Olle Johansson (oej) 2007-02-14 10:10:22.000-0600 It gets added to the history, but that is after "h" is executed. So the channel variable is added too late. By: Olle Johansson (oej) 2007-02-14 14:56:25.000-0600 I'm actually getting that channel variable on some calls. hmm. By: Tilghman Lesher (tilghman) 2007-02-14 15:00:00.000-0600 I think I discovered that if it _generates_ the BYE, the value will never be retrievable, but if you _receive_ the BYE, then it's possible. By: Matt Riddell (zx81) 2007-03-01 19:46:54.000-0600 Any progress on this? Can someone point me where to look for this?  I've tried moving the code earlier in chan_sip.c and it didn't help.  I had a look at rtp.c (it would be really easy to just update a chan var on every stat being received), but I can't see how to get back from a ast_rtp to a chan. By: Russell Bryant (russell) 2007-03-27 11:01:07 This has been resolved by the patch from issue 9370.  There is a new dialplan function, RTPQOS, that should be used instead.