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

[Jaco Kroon (JIRA)]

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

Jaco Kroon commented on ASTERISK-20754:
---------------------------------------

Matt, yes!  Related, the code from Olle to get the channel name listed is actually a much cleaner mechanism than what mine is (much less intrusive and doesn't rely on channel drivers doing the "right" thing).  So I think you really rather snarf the appropriate bits from that patch.  If my head comes for gulping some air in the next few days I'll see if I can do that for you.  However, I really am after a bigger patch that improves the RTCP AMI events in general.  Got a proposal but it may be too much of a change according to some for going into 11, and there is already refactoring for trunk ... so that leaves us in a bit of a pinch.  I did make it configurable that you get the current behaviour by default and my alternate behaviour on explicit configuration.
                
> 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