Summary:ASTERISK-19366: Periodic RTCP receiver reports in cross-linked asterisk scenario although asterisk is no longer in the RTP path (directmedia)
Reporter:Thomas Arimont (tomaso)Labels:
Date Opened:2012-02-15 07:44:30.000-0600Date Closed:2012-05-08 05:27:19
Versions: Frequency of
Environment:Attachments:( 0) direct_media_no_rtcp_rr.diff
( 1) direct_media_no_rtcp_rr.diff
Description:Asterisk is still sending periodic RTCP receiver reports in a cross-linked asterisk scenario (phone <->Asterisk1 <-> OpenSER <-> Asterisk2 <-> phone) with active directmedia although asterisk is no longer in the RTP path.
This might 'harm nobody else (more precisely: the sip phone)' but does not make any sense since the report does not include any change.
I don't know what the specs/RFCs say about this.
Comments:By: Kinsey Moore (kmoore) 2012-03-05 10:42:36.928-0600

I have seen this type of issue when the RTP for a call goes dormant, but is not released which certainly sounds like the situation here.  A similar issue occurred for inactive audio RTP during T.38 sessions which is now fixed.  I'll be looking into this issue over the next few days.

By: Kinsey Moore (kmoore) 2012-03-05 14:24:33.715-0600

I have attached a patch that corrects the erroneous RTCP RR packets post-reinvite.  This functioned as expected in my simplified reproduction of your scenario and I expect it to disable RTCP RRs during direct media sessions for your scenario as well.

By: Thomas Arimont (tomaso) 2012-03-07 23:13:18.045-0600

thanks a lot! I will check this a.s.a.p.

By: Kinsey Moore (kmoore) 2012-03-20 12:14:57.329-0500

Hello Thomas,
How is testing going?  Have you noticed any side-effects or bugs caused by this patch?

By: Maurice Winkels (maurice) 2012-03-21 04:11:15.258-0500

Hi Kinsey,
sorry, my actual JIRA account is blocked now for more than one week, so I couldn't answer.
Now I'll try it with this private JIRA account.
Your patch obviously needs to be improved.
Referring to a NULL pointer (instance) is not a good thing to do.

if (instance) {
} else if (...)) {
ast_rtp_instance_set_prop(instance, AST_RTP_PROPERTY_RTCP, 1);

If I had taken a closer look to the patch itself before, it wouldn't have been such surprising that I ran directly into a segmentation fault.
Anyway thanks for your help!

Regards Thomas

By: Thomas Arimont (tomaso) 2012-03-22 09:09:46.768-0500

My JIRA account is back. Please see my last comment

By: Kinsey Moore (kmoore) 2012-03-22 09:16:08.704-0500

I apologize for the previous patch.  That version should have never made it on to this issue.  The correct patch is now uploaded and I verified that it does not exhibit the issue the previous patch displayed.

By: Thomas Arimont (tomaso) 2012-03-22 09:44:16.220-0500

no problem at all!
I will test the new version of your patch when my 'overnight' test from issue ASTERISK-19278 has finished, likely tomorrow. O.k.?

By: Kinsey Moore (kmoore) 2012-03-22 09:47:31.602-0500

No problem.  I will be waiting to hear from you when you get a chance to test it.  I will be out of the office for the latter half of Friday, but I will still get email updates on this issue.

By: Thomas Arimont (tomaso) 2012-04-11 08:51:43.939-0500

Hi Kinsey,
sorry again, my results are still outstanding. I will test your patch as soon as I've completed my higher priorized tasks (which are quite a few in the moment).

By: Kinsey Moore (kmoore) 2012-04-24 13:44:05.846-0500

Hi Thomas,
How is the testing going?


By: Thomas Arimont (tomaso) 2012-05-08 05:26:33.487-0500

I guess you won't believe it: I've just tested your patch. And it works fine / like expected!
Good job! And I'm really sorry for the very long delay!
I owe you one big (german) beer! So when you come around next time ... ;-)

I've tested a blindtransfer as well as a attended transfer and I don't see any (useless) RTCP packets more (I've used asterisk


By: Thomas Arimont (tomaso) 2012-05-08 05:27:19.387-0500

... finally ...