[svn-commits] oej: branch oej/pinetestedition-1.8 r383032 - /team/oej/pinetestedition-1.8/p...

Wed Mar 13 11:02:19 CDT 2013

Author: oej
Date: Wed Mar 13 11:02:15 2013
New Revision: 383032

URL: http://svnview.digium.com/svn/asterisk?view=rev&rev=383032
Log:
Adding pinefrog documentation

Added:
    team/oej/pinetestedition-1.8/patches/README.pinefrog-rtcp   (with props)

Added: team/oej/pinetestedition-1.8/patches/README.pinefrog-rtcp
URL: http://svnview.digium.com/svn/asterisk/team/oej/pinetestedition-1.8/patches/README.pinefrog-rtcp?view=auto&rev=383032
==============================================================================

--- team/oej/pinetestedition-1.8/patches/README.pinefrog-rtcp (added)
+++ team/oej/pinetestedition-1.8/patches/README.pinefrog-rtcp Wed Mar 13 11:02:15 2013
@@ -1,0 +1,184 @@
+Olle E. Johansson
+oej at edvina.net
+
+2013-03-05
+
+
+
+
+
+
+Pinefrog - RTCP cleanup and additions
+-------------------------------------
+
+This branch is aimed at porting the code in pinefrog-1.4, which is now a few years old,
+to Asterisk 1.8 and hopefully (with some help) to Asterisk trunk to be integrated.
+The 1.4 code has been running in production for years in universities, call centers
+and service providers.
+
+The 1.8 port of Pinefrog is supported by Nordicom, Norway (http://www.nordicom.no). 
+The 1.4 work was sponsored by several companies, including ClearIT AB, Sweden.
+
+Status of 1.8 port
+------------------
+2013-03-05	Started
+2013-03-12	Updated README to document current status
+
+Todo for 1.8
+------------
+Done. - Add support of outbound and inbound SDES. The SDES includes a stream identifier, CNAME. 
+Done. - Add support of outbound SDES end and goodbye
+Done. - Add manager events at end-of call
+Done. - Add realtime storage of RTCP reports
+Done. - Add time manager events (configured in sip.conf)
+Done. - Add more information to RTCP debug
+Done. - Add more data aggregation to ast_rtcp structure (from svn trunk really)
+- Add RTCP for p2p RTP bridges. Needs to be tested and validated.
+
+Background
+==========
+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.
+
+Logging
+-------
+This module logs Call Quality Records either to Realtime databases (see structure
+below) or to a new log channel named CQR. Here's an example log entry, broken
+to multiple lines for clarity:
+
+[Mar 12 14:10:13] CQR[27938] sip/rtcp.c: CQR Channel: SIP/demo2-0000000b Uid example.com-1363086575.11
+     Bch SIP/demo3-0000000a Buid example.com-1363086575.10 Pvt 12474f1963f3312d0cfc930472a164d7 at 62.80.214.22:5060 
+     Media audio Lssrc 653259305 Rssrc 1997455415 Rip 87.96.134.129 Rtt 0:0:0 Ljitter 0.000000 Rjitter 0.026454 
+     Rtcpstatus Active Dur 6 Pout 169 Plossout 0 Pin 157 Plossin 0
+
+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.
+
+Done in 1.4
+-----------
+- 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)
+- Call hold
+- Call with music-on-hold
+- Call transfer
+
+Send feedback from your reports to oej at edvina.net
+
+Database structure
+-------------------
+Example database schema for MySQL:
+
+CREATE TABLE `astcqr` (
+  `channel` varchar(50) NOT NULL,
+  `uniqueid` varchar(35) NOT NULL,
+  `bridgedchannel` varchar(50) NOT NULL,
+  `bridgeduniqueid` varchar(35) NOT NULL,
+  `pvtcallid` varchar(80) NOT NULL,
+  `rtpmedia` varchar(50) NOT NULL,
+  `localssrc` varchar(50) NOT NULL,
+  `remotessrc` varchar(50) NOT NULL,
+  `rtt` varchar(10) NOT NULL,
+  `localjitter` varchar(10) NOT NULL,
+  `remotejitter` varchar(10) NOT NULL,
+  `sendformat` varchar(10) NOT NULL,
+  `receiveformat` varchar(10) NOT NULL,
+  `rtcpstatus` varchar(10) NOT NULL,
+  `duration` varchar(10) NOT NULL,
+  `packetsent` varchar(30) NOT NULL,
+  `packetreceived` varchar(30) NOT NULL,
+  `packetlossin` varchar(30) NOT NULL,
+  `packetlossout` varchar(30) NOT NULL,
+  `rttmax` varchar(12) NOT NULL,
+  `rttmin` varchar(12) NOT NULL,
+  `writetranslator` varchar(15) NOT NULL,
+  `readtranslator` varchar(15) NOT NULL,
+  `writecost` varchar(10) NOT NULL,
+  `readcost` varchar(10) NOT NULL,
+  `remoteip` varchar(25) NOT NULL,
+  KEY `ChannelUnique` (`channel`,`uniqueid`)
+) ENGINE=MyISAM DEFAULT CHARSET=latin1 COMMENT='FOr pinefrog stats'
+
+Realtime configuration
+========================
+In extconfig.conf add
+
+rtpcqr => mysql,asterisk,astqos
+
+When you run "sip show settings" you should see this:
+
+  QoS realtime reports:   Enabled

Propchange: team/oej/pinetestedition-1.8/patches/README.pinefrog-rtcp
------------------------------------------------------------------------------
    svn:eol-style = native

Propchange: team/oej/pinetestedition-1.8/patches/README.pinefrog-rtcp
------------------------------------------------------------------------------
    svn:keywords = Author Date Id Revision

Propchange: team/oej/pinetestedition-1.8/patches/README.pinefrog-rtcp
------------------------------------------------------------------------------
    svn:mime-type = text/plain


