Summary:ASTERISK-08784: $RTPAUDIOQOS dosn't report
Reporter:dario (dario)Labels:
Date Opened:2007-02-12 09:35:31.000-0600Date Closed:2007-03-27 11:01:08
Versions:Frequency of
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

exten => _997X,1,Set(__TRANSFER_CONTEXT=test_1)
exten => _997X,2,Goto(test_1,${EXTEN},1)

exten => _997X,1,Dial(SIP/${EXTEN},60,tT)
exten => _X.,1,Dial(SIP/${EXTEN},300,rtT)
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.