[asterisk-dev] [Code Review] 3810: res_hep_rtcp: Add module that sends RTCP information to a Homer Server

[Matt Jordan]

-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviewboard.asterisk.org/r/3810/
-----------------------------------------------------------

(Updated July 27, 2014, 10:39 a.m.)


Review request for Asterisk Developers.


Changes
-------

Updated review with bugs found by tests. See updated description.


Repository: Asterisk


Description (updated)
-------

This patch adds a new module to Asterisk, res_hep_rtcp. The module subscribes to Stasis and receives RTCP information back from the message bus, which it encodes into HEPv3 packets and sends to the res_hep module for transmission.

Using this, someone with a Homer server can get live call quality monitoring for all channels in their Asterisk 12+ systems.

NOTE:

There were a few bugs uncovered by the tests written for the Asterisk Test Suite. As it turned out, these bugs were actually all in modules other than res_hep_rtcp, but I've included them with this diff as they are relatively small.
1) chan_pjsip failed to set its channel unique ids on its RTP instance on outbound calls. It now does this in the appropriate location, in the serialized call callback.
2) The rtp_engine was overflowing some values when packed into JSON. Specifically, some longs and unsigned ints can't be be packed into integer values, for obvious reasons. Since libjansson only supports integers, floats, strings, booleans, and objects, we print these values into strings.
3) res_rtp_asterisk had a few problems:
   (a) it would emit a source IP address of 0.0.0.0 if bound to that IP address. We now use ast_find_ourip to get a better IP address, and properly marshal the result into an ast_strdupa'd string.
   (b) Reports can be generated with no report bodies. In particular, this occurs when a sender is transmitting information to a receiver (who will send no RTP back to the sender). As such, the sender has no report body for what it received. We now properly handle this case, and the sender will emit SR reports with no body. Likewise, if we receive an RTCP packet with no report body, we will still generate the appropriate events.


Diffs (updated)
-----

  /branches/12/res/res_rtp_asterisk.c 419680 
  /branches/12/res/res_hep_rtcp.c PRE-CREATION 
  /branches/12/main/rtp_engine.c 419680 
  /branches/12/channels/chan_pjsip.c 419680 
  /branches/12/CHANGES 419680 

Diff: https://reviewboard.asterisk.org/r/3810/diff/


Testing (updated)
-------

Some manual testing has be done, and automated tests have been written that exercise two scenarios:

 * One where both sides transmit RTP information to each other (rtcp-sender)
 * One where one side transmits RTP information, and the other is a passive receiver (rtcp-receiver)

See https://reviewboard.asterisk.org/r/3863

As a side note, Alexander actually demo'd this at Kamailio World - you can see it on the 'dangerous demos' here - http://www.youtube.com/watch?v=ykBdOTCCSHs


Thanks,

Matt Jordan

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-dev/attachments/20140727/5ec418c3/attachment.html>