[Home]

Summary:ASTERISK-16749: RTPAUDIOQOSJITTERBRIDGED and other variables contains nothing if call is terminated from DAHDI
Reporter:sles (sles)Labels:
Date Opened:2010-09-28 23:22:46Date Closed:2013-01-15 11:17:00.000-0600
Priority:MinorRegression?No
Status:Closed/CompleteComponents:Channels/General
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:
Description:Hello!

I have following in extensions.conf:
exten => h,n,NoOp(-- QoS stats RTPAUDIOQOSJITTERBRIDGED: ${RTPAUDIOQOSJITTERBRIDGED})                                                                        
exten => h,n,NoOp(-- QoS stats RTPAUDIOQOSLOSSBRIDGED: ${RTPAUDIOQOSLOSSBRIDGED})                                                                            
exten => h,n,NoOp(-- QoS stats RTPAUDIOQOSRTTBRIDGED: ${RTPAUDIOQOSRTTBRIDGED})    


Than I do Dial from DAHDI (E1 PRI link) to SIP:

   -- Executing [6052@default:4] Dial("DAHDI/28-1", "SIP/6052") in new stack


Really, 6052 is ekiga, i.e. softphone.

Than if I do hangup in ekiga I get:

   -- Executing [h@default:2] NoOp("DAHDI/14-1", "-- QoS stats RTPAUDIOQOSJITTERBRIDGED: rxjitter=0.003858;") in new stack
   -- Executing [h@default:3] NoOp("DAHDI/14-1", "-- QoS stats RTPAUDIOQOSLOSSBRIDGED: lost=16;expected=126;") in new stack
   -- Executing [h@default:4] NoOp("DAHDI/14-1", "-- QoS stats RTPAUDIOQOSRTTBRIDGED: Not available") in new st

but if do I hangup on my phone, connected to PBX, which is connected to asterisk over DAHDI I get:

   -- Executing [h@default:2] NoOp("DAHDI/6-1", "-- QoS stats RTPAUDIOQOSJITTERBRIDGED: ") in new stack
   -- Executing [h@default:3] NoOp("DAHDI/6-1", "-- QoS stats RTPAUDIOQOSLOSSBRIDGED: ") in new stack
   -- Executing [h@default:4] NoOp("DAHDI/6-1", "-- QoS stats RTPAUDIOQOSRTTBRIDGED: ") in new stack

Variables are empty.


Looks like a bug.

Thank you!

Comments:By: Leif Madsen (lmadsen) 2010-09-29 11:39:26

I don't think this is a bug. I'm pretty sure this is working based on the way it is implemented.

When the SIP channel hangs up, the hangup routine is executed by that channel, which contains the RTCP data. When the DAHDI channel hangs up, the hangup routine is executed by that channel, which obviously would have no RTCP data.
By: sles (sles) 2010-09-29 22:41:15

Well, if this is not bug, then this feature is just useless- it is impossible to monitor RTCP if data depends on which user decided to end call.
IMHO, this should be corrected anyway.
Thank you!
By: sles (sles) 2010-09-30 03:53:20

btw "When the DAHDI channel hangs up, the hangup routine is executed by that channel, which obviously would have no RTCP data. "

As you can see channel in h extension is _always_ dahdi, so I can't agree this is by design :-)
I'm pretty shure this _is_ bug!


By: Leif Madsen (lmadsen) 2010-10-04 12:39:21

A developer will have to look at this then and determine if this is a bug or not.
By: Matt Jordan (mjordan) 2013-01-15 11:16:50.071-0600

No, this is not a bug. You are inspecting the RTCP statistics on the wrong channel.

You can achieve what you're looking to do using Asterisk 11's hangup handlers and pre-dial. You can attach a hangup handler to the SIP channel in a pre-dial routine so that when it hangs up, you can get the RTCP statistics from the correct channel.