[asterisk-bugs] [JIRA] (ASTERISK-20754) rtp_engine's RTCP{Sent, Received} events should contain the Channel name

[Matt Jordan (JIRA)]

    [ https://issues.asterisk.org/jira/browse/ASTERISK-20754?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=206656#comment-206656 ] 

Matt Jordan commented on ASTERISK-20754:
----------------------------------------

Any improvements to RTCP events would have to be done in trunk. There's a lot of significant work being done in the interfaces area that will actually make it easier to use RTCP information throughout Asterisk, not just for AMI. Since this patch was related to that, I figured I'd take a look at it to see what could be pulled up in relation to that work.

Pinefrog obviously also comes to mind as something that benefits from this, as it uses the RTCP related information for CQR as well.

While it is important to have the channel information related to the RTP instance, that actually already occurs when two RTP capable channels are natively bridged. That isn't quite as extensive as what you do here in this patch, but I'm thinking of trying to marry those two concepts.

One problem this patch does appear to have are masquerades. When a masquerade occurs, the channel pointer becomes invalid as the RTP instance will be put onto another channel object. The original channel object can be disposed of, since the RTP instance doesn't ref bump the channel object (as an aside, it shouldn't ref bump the channel object as it doesn't own the channel object). This means there are potential crashes here during transfer operations, call pickup, and other scenarios that currently use masquerades.

While masquerades are much less frequent in Asterisk 12, they can still occur in rare cases, so having a perma-pointer back to the channel may be tricky. There are masquerade fixup callbacks that could be used to update the channel pointer in the RTP instance; we may have to use them.
                
> rtp_engine's RTCP{Sent,Received} events should contain the Channel name
> -----------------------------------------------------------------------
>
>                 Key: ASTERISK-20754
>                 URL: https://issues.asterisk.org/jira/browse/ASTERISK-20754
>             Project: Asterisk
>          Issue Type: Improvement
>      Security Level: None
>          Components: Resources/res_rtp_asterisk
>    Affects Versions: 1.8.18.0
>            Reporter: Jaco Kroon
>            Assignee: Matt Jordan
>            Severity: Trivial
>         Attachments: asterisk-rtcp-channel.patch
>
>
> It's all good and well being able to detect bad links, but in some cases we really want to be able to associate which calls were affected afterwards.  In combination with tracking which calls are using which channels (monitoring the AMI) and having the RTCP data associated with a specific channel this can be achieved externally to asterisk, hopefully allowing us to figure out which calls exactly were bad.
> This is particularly important for us since we communicate with SBCs, but just knowing that we had packet loss coming from the SBC is not good enough to figure out where the loss originated, and we need to be able to provide A and B numbers to our peering partners to be able to track the path that the calls took on their networks.  With this information I can pro-actively monitor RTP traffic and automatically file appropriate reports, and instead of becoming reative when my clients reports problems I can find them and fix them before they moan at me (and just notify them that some bad link got sorted out).

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.asterisk.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira