----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: https://reviewboard.asterisk.org/r/3810/#review12908 -----------------------------------------------------------
Ship it! Ship It! - Joshua Colp On July 27, 2014, 3:39 p.m., Matt Jordan wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > https://reviewboard.asterisk.org/r/3810/ > ----------------------------------------------------------- > > (Updated July 27, 2014, 3:39 p.m.) > > > Review request for Asterisk Developers. > > > Repository: Asterisk > > > Description > ------- > > 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 > ----- > > /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 > ------- > > 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 > >
-- _____________________________________________________________________ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
