Cisco Cisco Packet Data Gateway (PDG) Fehlerbehebungsanleitung

Seite von 85
Peer-to-Peer Overview   
▀  P2P Overview 
 
▄  Cisco ASR 5000 Series Peer-to-Peer Detection Administration Guide 
OL-22960-01   
 
Winny 
 
Yahoo voice/non-voice 
 
Zattoo 
 
Prepaid and postpaid P2P content-based billing 
 
Statistics reporting—analyzing per-protocol statistics using bulkstats 
 
P2P Voice Call Duration 
The P2P product has the capability to detect network traffic created by P2P VoIP clients such as Skype, Yahoo, MSN, 
Gtalk, Oscar. The VoIP call duration is a direct indication to the revenue impact of the network operator. The P2P 
product is well poised to process the network traffic online to detect and control the VoIP presence, and generate 
records that can be used to calculate the VoIP call durations. 
Random Drop Charging Action 
The random drop charging action is added as an option to degrade P2P voice calls. This is achieved by randomly 
dropping packets of the voice calls over the voice call period. 
Voice data is encoded in multiple packets by the codec. Since there is a possibility of packets being dropped in a 
network, the codec replicates the same information across multiple packets. This provides resilience to random packet 
drops in the network. For a considerable degradable voice quality, a chunk of packets need to be dropped. By this way, 
the codec will be unable to decode the required voice information. The chunk size for achieving degradation of voice 
call varies from one protocol to another. 
The Random Drop decision has to be made once for a chunk of packets. By choosing the random drop time from a 
configured range, the drop is achieved at random seconds within a configured range. The packets will drop within a 
known period of time. For example, if a voice call happens for 2 minutes and if we configure a drop interval of 12–15 
seconds, then a packet will be dropped within the first 15 seconds of the voice call. 
I
MPORTANT
:
  This feature is applicable only for VOIP calls.
 
 
Dynamic Signature Updates 
P2P traffic detection is tricky because most of the P2P protocol details are proprietary, and the protocol characteristics 
change frequently. As these P2P standards are proprietary, there is a tight coupling between the peers too (all the peers 
need to understand the protocols). Since P2P detection depends heavily on the known traffic characteristics the detection 
can suffer if the P2P protocol changes, if some existing traffic characteristics were not known (new use case scenarios), 
if one P2P traffic characteristic matches with another P2P traffic (false positives), and if there are flaws (bugs) in the 
detection logic. Whenever such degradation in P2P detection logic is identified, the P2P detection engine needs to be 
fine tuned or enhanced further to improve the detection accuracy. 
In the earlier releases, the P2P detection logic was part of the chassis software load (ASR 5000 software), to continue to 
detect new traffic patterns based on the changing traffic characteristics, operators needed to upgrade the complete 
software with the updated logic.