[asterisk-commits] oej: branch oej/pinefrog-deluxe-rtcp-test r241854 - /team/oej/pinefrog-deluxe...

Thu Jan 21 04:10:59 CST 2010

Author: oej
Date: Thu Jan 21 04:10:57 2010
New Revision: 241854

URL: http://svnview.digium.com/svn/asterisk?view=rev&rev=241854
Log:
Adding some documentation for testers

Added:
    team/oej/pinefrog-deluxe-rtcp-test/README.pinefrog-rtcp   (with props)

Added: team/oej/pinefrog-deluxe-rtcp-test/README.pinefrog-rtcp
URL: http://svnview.digium.com/svn/asterisk/team/oej/pinefrog-deluxe-rtcp-test/README.pinefrog-rtcp?view=auto&rev=241854
==============================================================================

--- team/oej/pinefrog-deluxe-rtcp-test/README.pinefrog-rtcp (added)
+++ team/oej/pinefrog-deluxe-rtcp-test/README.pinefrog-rtcp Thu Jan 21 04:10:57 2010
@@ -1,0 +1,95 @@
+Olle E. Johansson
+oej at edvina.net
+
+
+
+
+
+
+Pinefrog - RTCP cleanup and additions
+-------------------------------------
+
+RTCP, as defined in RFC 3550, is a protocol that co-exists with RTP, the protocol used
+for realtime multimedia in VoIP. RTCP gives the endpoints a tool to exchange data about
+the media streams exchanged. As a result, both ends can get informaiton about the
+latency for data sent in both directions, packet loss and jitter for each media stream.
+
+A VoIP call is at least two media streams and they can have different properties in
+regards of quality. A router or switch in the middle could have a lot of outbound traffic,
+causing delays and possible packet loss. This might not affect inbound traffic.
+
+In Asterisk, the RTCP handler is part of the RTP module. The RTP module produces RTCP
+report that can be added to channel variables, cdr logs or sent through AMI.
+
+In 1.4, the data used is mostly based on the latest report, it's not aggregated. This
+is fixed in trunk.
+
+In both implementations (and the 1.6 releases in between) the RTCP support is not
+very complete.
+
+- It doesn't handle RTCP SDES packets
+- It doesn't send RTCP END packets at end of session
+- It doesn't handle receiving END packets
+- It doesn't handle re-invites in a good way.
+- It seems to mix sender and receiver reports, thus mixing data from two streams 
+    - when does this happen, if at all?
+
+RTCP and NAT
+------------
+I suspect that RTCP doesn't traverse NAT very well in our implementation. For RTP,
+we start with sending media to probe NAT. I've added emtpy RTCP RR+SDES CNAME packets
+to start probing a NAT (if Asterisk is behind a NAT). I am afraid that very few devices
+do that early on.
+The idea is (like RTP)
+ - Send a few RTCP packets in the start of the session.
+ - The receiver can then apply symmetric RTCP and start sending to the NAT outside port
+   that we're sending from and we'll get their packets.
+
+Todo
+----
+- When CNAME changes, we have a different stream and need to restart the stats.
+  Should we add ability to produce multiple RTCP reports for one "call" and aggregate them?
+  The different parts might have different properties.
+- Document realtime storage format. Add missing fields.
+
+Done
+----
+- Added support of outbound and inbound SDES. The SDES includes a stream identifier, CNAME. 
+- Added support of outbound SDES end and goodbye
+- Added manager events at end-of call
+- Added realtime storage of RTCP reports
+- Added time manager events (configured in sip.conf)
+- Added more information to RTCP debug
+- Added more data aggregation to ast_rtcp structure (from svn trunk really)
+- Added RTCP for p2p RTP bridges. Needs to be tested and validated.
+
+Open Issues
+-----------
+The final manager report lacks (in the case of the second channel) the bridged channel. We could save that data.  This will affect realtime as well, so we need to copy the channel name to a stored variable while it exists.
+
+Do we have a counter of consecutive lost packets? How do we measure lost packets on inbound
+stream? Gaps in seq numbers or just the sender reports from the other end compared with received 
+no of packets?
+
+
+Ideas and thoughts for the future
+---------------------------------
+- Asterisk propagates jitter and packet loss over a bridge (especially the p2p RTP bridge).
+  If the call is transfered on the OTHER side of the bridge, we have a new call with new
+  properties. Maybe events like this should generate a new SDES and reset RTCP?
+  Part A of the call can have very different properties than part B. If I have a call with
+  someone internally, that then transfers me to a call with someone on the Internet, the
+  call quality (jitter etc) will change dramatically. This will require some sort of CONTROL
+  packet over the bridge, informing about changes on the other side of the bridge (masq).
+- Can we have some sort of ring buffer for the latest RTCP reports for a device (peer) 
+  and use that to determine the status of the connection to the peer?
+- Can we use the RTCP APP packet for relaying events in joined bridges, like meetme?
+- What should we use as CNAME? Currently SIP call ID.
+- Separate on the IPs of different media servers. IE we can have one SIP peer with
+  multiple media IPs with different properties
+
+Scenarios to test
+------------------
+- normal bridged call
+- RTP p2p bridged call
+- Nat traversal - Asterisk outside of NAT and inside (as client to external service)

Propchange: team/oej/pinefrog-deluxe-rtcp-test/README.pinefrog-rtcp
------------------------------------------------------------------------------
    svn:eol-style = native

Propchange: team/oej/pinefrog-deluxe-rtcp-test/README.pinefrog-rtcp
------------------------------------------------------------------------------
    svn:keywords = Author Date Id Revision

Propchange: team/oej/pinefrog-deluxe-rtcp-test/README.pinefrog-rtcp
------------------------------------------------------------------------------
    svn:mime-type = text/plain


