[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=206677#comment-206677 ] 

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

I've been thinking about this some more.

One of the problems with using the actual {{ast_channel}} object in the RTP stack is that the {{ast_channel}} objects can get destroyed out from underneath you. You can either attempt to fixup the RTP instances whenever the {{ast_channel}} object goes away, or you can ref count the {{ast_channel}} object in the RTP stack. The first option is prone to missing a fixup spot and getting a seg fault; the latter is prone to having ref count leaks (and, since it creates a circular dependency, is a bad idea (tm))

However, we really don't need the {{ast_channel}} object, as we're really just interested in getting some aspect of the channel's state when an AMI event needs to be fired. In general, we just want the name - but we're not looking to actually change the channel state. We really want a read/only version of the channel.

There is an option in trunk that provides that. The Stasis-Core cache maintains the state of all channels. If we store the channel's uniqueid - which never changes, even during a masquerade - we can use that to snag the channel state for our events. And we don't have to worry about all of the masquerades and fixups and ref leaks.

I think I'm going to go with that approach here, as it feels a lot safer and makes use of the channel state cache (which is awfully handy for things like this)
                
> 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