[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:all-tabpanel ]

Jaco Kroon updated ASTERISK-20754:
----------------------------------

    Attachment: asterisk-rtcp-channel.patch

This one fixes it for at least SIP.  Multicast RTP is simple enough that I can almost give you a letter it should just work.

Unfortunately I was braindead enough to base this against the 1.8.18.0 version of asterisk ... just completed a checkout of trunk, will rebase against that, but I do need it for 1.8.18.0 for the moment at least.

Code audit is in order.  For each channel type I basically split the updating of ->owner into a function that iterates the various ->rtp, ->vrtp and ->trtp (as appropriate) members and updating their owners too.

It should be noted that up until now there were no users of the ast_rtp_instance_get_chan() function that I could find (at least not in 1.8.18.0), thus these changes should not affect existing functionality (except if I somehow managed to introduce a new bug).
                
> 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
>            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
For more information on JIRA, see: http://www.atlassian.com/software/jira