首先，要在IIS中配置一个Web站点，用于发布MRTG的监控信息，本文假设该站点的根目录为c:/mrtg,然后，获取MRTG的 Win32版本和Activeperl,分别安装到d:/mrtg/和c:/usr/,为了将MRTG作为系统服务一开机就自动运行，我们还将 Windows 2000 Resource Kit 中的instsrv.exe和srvany.exe复制到d:/mrtg/bin

官方网站:http://people.ee.ethz.ch/~oetiker/webtools/mrtg/

　　Windows 2000 Server中内含了SNMP 网络管理协议，如果你想通过 MRTG 来监控一台Windows 2000服务器的相关信息，就需要启用该Windows 2000 Server 的SNMP 协议.

　　系统默认的Community 是通用的Public,虽然只有只读权限，但是出于安全的考虑，最好修改一下。

　　SNMP使用的是UDP协议 161/162 端口

　　可网管交换机，路由器本来就有SNMP协议，不需添加

　　假设我们要监控的设备的IP是202.108.36.172

　　下面我们进行MRTG的配置：
　　1.进入 d:/mrtg/bin 目录：
　　cd d:/mrtg/bin

　　执行 cfgmaker,生成cfg文件：

　　perl cfgmaker public@202.108.36.172 --global "WorkDir: c:/mrtg"      --output mrtg.cfg

　　这里的public是202.108.36.172的Community,MRTG的监控文件保存在C:/mrtg/,注意WorkDir:与 c:/mrtg中间必需要有空格，输入的配置文件为mrtg.cfg,如果有多台设备要监控，可以在这里分别填入，如：

　　perl cfgmaker public@202.108.36.172 public@202.108.36.173      --global "WorkDir: c:/mrtg" --output mrtg.cfg

　　2.为了让MRTG全天24小时监控，我们在mrtg.cfg中加入以下参数，使MRTG每隔5分钟采集一次数据。

　　RunAsDaemon:yes
　　Interval:5
　　可以使用命令：
　　echo RunAsDaemon:yes >>mrtg.cfg
　　echo Interval:5 >>mrtg.cfg
　　使用中文：
　　echo language:chinese>>mrtg.cfg

　　3.使用IndexMaker生成报表首页:
　　perl indexmaker mrtg.cfg>c:/mrtg/index.htm
　　4.运行MRTG:
　　perl mrtg --logging=mrtg.log mrtg.cfg
　　访问http://yourserver/index.htm 看MRTG是否可以正常工作，生成统计图形。如果正常，终止程序，将其配置为系统服务。

　　将MRTG配置为系统服务：
　　由于MRTG需要由perl来编译执行，不能直接添加为系统服务，所以我们使用Windows 2000 Resource Kit 中的instsrv.exe和srvany.exe这

　　两个程序来帮助我们把MRTG添加为系统服务。

　　1 添加srvany.exe为服务：
　　instsrv MRTG "d:/mrtg/bin/srvany.exe"

　　2 配置srvany:

　　在注册表 HKEY_LOCAL_MACHINE/SYSTEM/CurrentControlset/servicesMRTG 中添加一个 parameters 子键。再在 parameters 子键中添加以下项目：
　　Application的字串值，内容为 C:/usr/bin/perl.exe
　　AppDirectory 的字串值，内容为d:/mrtg/bin/
　　AppParameters的字串值,内容为 mrtg --logging=mrtg.log mrtg.cfg

　　有用的参数

　　Options[_]: growright, bits
　　RunAsDaemon:yes
　　Interval:5
　　language:chinese

一些常见的状态码为：

200 - 服务器成功返回网页
404 - 请求的网页不存在
503 - 服务不可用

详细分解：

1xx（临时响应）
表示临时响应并需要请求者继续执行操作的状态代码。

代码   说明
100   （继续） 请求者应当继续提出请求。 服务器返回此代码表示已收到请求的第一部分，正在等待其余部分。 
101   （切换协议） 请求者已要求服务器切换协议，服务器已确认并准备切换。

2xx （成功）
表示成功处理了请求的状态代码。

代码   说明
200   （成功）  服务器已成功处理了请求。 通常，这表示服务器提供了请求的网页。
201   （已创建）  请求成功并且服务器创建了新的资源。
202   （已接受）  服务器已接受请求，但尚未处理。
203   （非授权信息）  服务器已成功处理了请求，但返回的信息可能来自另一来源。
204   （无内容）  服务器成功处理了请求，但没有返回任何内容。
205   （重置内容） 服务器成功处理了请求，但没有返回任何内容。
206   （部分内容）  服务器成功处理了部分 GET 请求。

3xx （重定向）
表示要完成请求，需要进一步操作。 通常，这些状态代码用来重定向。

代码   说明
300   （多种选择）  针对请求，服务器可执行多种操作。 服务器可根据请求者 (user agent) 选择一项操作，或提供操作列表供请求者选择。
301   （永久移动）  请求的网页已永久移动到新位置。 服务器返回此响应（对 GET 或 HEAD 请求的响应）时，会自动将请求者转到新位置。
302   （临时移动）  服务器目前从不同位置的网页响应请求，但请求者应继续使用原有位置来进行以后的请求。
303   （查看其他位置） 请求者应当对不同的位置使用单独的 GET 请求来检索响应时，服务器返回此代码。
304   （未修改） 自从上次请求后，请求的网页未修改过。 服务器返回此响应时，不会返回网页内容。
305   （使用代理） 请求者只能使用代理访问请求的网页。 如果服务器返回此响应，还表示请求者应使用代理。
307   （临时重定向）  服务器目前从不同位置的网页响应请求，但请求者应继续使用原有位置来进行以后的请求。

4xx（请求错误）
这些状态代码表示请求可能出错，妨碍了服务器的处理。

代码   说明
400   （错误请求） 服务器不理解请求的语法。
401   （未授权） 请求要求身份验证。 对于需要登录的网页，服务器可能返回此响应。
403   （禁止） 服务器拒绝请求。
404   （未找到） 服务器找不到请求的网页。
405   （方法禁用） 禁用请求中指定的方法。
406   （不接受） 无法使用请求的内容特性响应请求的网页。
407   （需要代理授权） 此状态代码与 401（未授权）类似，但指定请求者应当授权使用代理。
408   （请求超时）  服务器等候请求时发生超时。
409   （冲突）  服务器在完成请求时发生冲突。 服务器必须在响应中包含有关冲突的信息。
410   （已删除）  如果请求的资源已永久删除，服务器就会返回此响应。
411   （需要有效长度） 服务器不接受不含有效内容长度标头字段的请求。
412   （未满足前提条件） 服务器未满足请求者在请求中设置的其中一个前提条件。
413   （请求实体过大） 服务器无法处理请求，因为请求实体过大，超出服务器的处理能力。
414   （请求的 URI 过长） 请求的 URI（通常为网址）过长，服务器无法处理。
415   （不支持的媒体类型） 请求的格式不受请求页面的支持。
416   （请求范围不符合要求） 如果页面无法提供请求的范围，则服务器会返回此状态代码。
417   （未满足期望值） 服务器未满足"期望"请求标头字段的要求。

5xx（服务器错误）
这些状态代码表示服务器在尝试处理请求时发生内部错误。 这些错误可能是服务器本身的错误，而不是请求出错。

代码   说明
500   （服务器内部错误）  服务器遇到错误，无法完成请求。
501   （尚未实施） 服务器不具备完成请求的功能。 例如，服务器无法识别请求方法时可能会返回此代码。
502   （错误网关） 服务器作为网关或代理，从上游服务器收到无效响应。
503   （服务不可用） 服务器目前无法使用（由于超载或停机维护）。 通常，这只是暂时状态。
504   （网关超时）  服务器作为网关或代理，但是没有及时从上游服务器收到请求。
505   （HTTP 版本不受支持） 服务器不支持请求中所用的 HTTP 协议版本。

PuTTY的图形化界面也可以配置出一个代理，但是那个用鼠标点击的不自动

PuTTY完整版自带的PLINK.exe可以完美的做这个事情，命令是：

解释成中文：

就这么简单。

如果是Linux下，直接使用ssh命令就可以了：

代理设置好了之后，在Firefox下这样设置：

其实F-secure  也有此功能，不过有点缺陷就是，  F-secure 的SSH tunnel  的 local tunnel 只能针对一个一个地址，而没办法全部的网址， 需要转发哪个地址，就需要手工添加。

转至：http://hi.baidu.com/%C1%E8%D4%C6%D7%B7%B7%E7/blog/item /2964ccdc863036a9cd1166f6.html

var hexcase = 1;
var b64pad = "";
var chrsz = 8;
var mode = 32;
function preprocess(A){   //这里A是表格的数据
    var B = "";
    B += A.verifycode.value;   //这里是验证码的值
    B = B.toUpperCase();        //这里把验证码转换成大写字母
    A.p.value = md5(md5_3(A.p.value) + B);          

//然后把密码框的数据进行MD5加密 先把密码md5_3处理，然后和验证码一起MD5
    return true
}

//下面看看md5_3的内容

function md5_3(B){
    var A = new Array;                         //申请一个数组
    A = core_md5(str2binl(B), B.length * chrsz);       //我们看看str2binl发生了什么， B的长度乘以8

//str2binl函数压缩了前三位，然后对每个字母进行unicode转换，再移位，再看看core_md5是什么
    A = core_md5(A, 16 * chrsz);
    A = core_md5(A, 16 * chrsz);
    return binl2hex(A)
}

function md5(A){
    return hex_md5(A)
}

function hex_md5(A){
    return binl2hex(core_md5(str2binl(A), A.length * chrsz))
}

function b64_md5(A){
    return binl2b64(core_md5(str2binl(A), A.length * chrsz))
}

function str_md5(A){
    return binl2str(core_md5(str2binl(A), A.length * chrsz))
}

function hex_hmac_md5(A, B){
    return binl2hex(core_hmac_md5(A, B))
}

function b64_hmac_md5(A, B){
    return binl2b64(core_hmac_md5(A, B))
}

function str_hmac_md5(A, B){
    return binl2str(core_hmac_md5(A, B))
}

function md5_vm_test(){
    return hex_md5("abc") == "900150983cd24fb0d6963f7d28e17f72"
}

function core_md5(K, F){
    K[F >> 5] |= 128 << ((F) % 32);
    K[(((F + 64) >>> 9) << 4) + 14] = F;
    var J = 1732584193;
    var I = -271733879;
    var H = -1732584194;
    var G = 271733878;
    for (var C = 0; C < K.length; C += 16) {
        var E = J;
        var D = I;
        var B = H;
        var A = G;
        J = md5_ff(J, I, H, G, K[C + 0], 7, -680876936);
        G = md5_ff(G, J, I, H, K[C + 1], 12, -389564586);
        H = md5_ff(H, G, J, I, K[C + 2], 17, 606105819);
        I = md5_ff(I, H, G, J, K[C + 3], 22, -1044525330);
        J = md5_ff(J, I, H, G, K[C + 4], 7, -176418897);
        G = md5_ff(G, J, I, H, K[C + 5], 12, 1200080426);
        H = md5_ff(H, G, J, I, K[C + 6], 17, -1473231341);
        I = md5_ff(I, H, G, J, K[C + 7], 22, -45705983);
        J = md5_ff(J, I, H, G, K[C + 8], 7, 1770035416);
        G = md5_ff(G, J, I, H, K[C + 9], 12, -1958414417);
        H = md5_ff(H, G, J, I, K[C + 10], 17, -42063);
        I = md5_ff(I, H, G, J, K[C + 11], 22, -1990404162);
        J = md5_ff(J, I, H, G, K[C + 12], 7, 1804603682);
        G = md5_ff(G, J, I, H, K[C + 13], 12, -40341101);
        H = md5_ff(H, G, J, I, K[C + 14], 17, -1502002290);
        I = md5_ff(I, H, G, J, K[C + 15], 22, 1236535329);
        J = md5_gg(J, I, H, G, K[C + 1], 5, -165796510);
        G = md5_gg(G, J, I, H, K[C + 6], 9, -1069501632);
        H = md5_gg(H, G, J, I, K[C + 11], 14, 643717713);
        I = md5_gg(I, H, G, J, K[C + 0], 20, -373897302);
        J = md5_gg(J, I, H, G, K[C + 5], 5, -701558691);
        G = md5_gg(G, J, I, H, K[C + 10], 9, 38016083);
        H = md5_gg(H, G, J, I, K[C + 15], 14, -660478335);
        I = md5_gg(I, H, G, J, K[C + 4], 20, -405537848);
        J = md5_gg(J, I, H, G, K[C + 9], 5, 568446438);
        G = md5_gg(G, J, I, H, K[C + 14], 9, -1019803690);
        H = md5_gg(H, G, J, I, K[C + 3], 14, -187363961);
        I = md5_gg(I, H, G, J, K[C + 8], 20, 1163531501);
        J = md5_gg(J, I, H, G, K[C + 13], 5, -1444681467);
        G = md5_gg(G, J, I, H, K[C + 2], 9, -51403784);
        H = md5_gg(H, G, J, I, K[C + 7], 14, 1735328473);
        I = md5_gg(I, H, G, J, K[C + 12], 20, -1926607734);
        J = md5_hh(J, I, H, G, K[C + 5], 4, -378558);
        G = md5_hh(G, J, I, H, K[C + 8], 11, -2022574463);
        H = md5_hh(H, G, J, I, K[C + 11], 16, 1839030562);
        I = md5_hh(I, H, G, J, K[C + 14], 23, -35309556);
        J = md5_hh(J, I, H, G, K[C + 1], 4, -1530992060);
        G = md5_hh(G, J, I, H, K[C + 4], 11, 1272893353);
        H = md5_hh(H, G, J, I, K[C + 7], 16, -155497632);
        I = md5_hh(I, H, G, J, K[C + 10], 23, -1094730640);
        J = md5_hh(J, I, H, G, K[C + 13], 4, 681279174);
        G = md5_hh(G, J, I, H, K[C + 0], 11, -358537222);
        H = md5_hh(H, G, J, I, K[C + 3], 16, -722521979);
        I = md5_hh(I, H, G, J, K[C + 6], 23, 76029189);
        J = md5_hh(J, I, H, G, K[C + 9], 4, -640364487);
        G = md5_hh(G, J, I, H, K[C + 12], 11, -421815835);

Contents

• Introduction
• Usage
• Examples
  • Record, mix and replay a VoIP call
  • Analyze an RTP session
  • Particular scenarios
  
  
• How it works
• Dependencies and compilation
• Links

Introduction

• reconstruct any RTP stream with an unknown or unsupported signaling protocol
• reconstruct any RTP stream in wireless networks, while doing channel hopping (VoIP activity detector)
• reconstruct and decode any RTP stream in batch mode (with sox, asterisk, ...)
• reconstruct any already existing RTP stream
• reorder the packets of any RTP stream for later analysis (with tshark, wireshark, ...)
• build a tiny wireless VoIP tapping system in a single chip Linux unit
• build a complete VoIP tapping system (rtpbreak would be just the RTP dissector module!)

Usage

INPUT

-r <str>

Read packets from file (pcap format) <str>

-i <str>

Read packets from network interface <str>

-L <int>

Force the datalink header length to <int> bytes. This is useful if the interface type is not correctly recognized by libpcap

OUTPUT

-d <str>

Set the output directory to <str>

-w

Disable the raw dump of RTP sessions

-W

Disable the pcap dump of RTP sessions

-g

Fill the gaps of lost packets in raw dumps with the last sniffed packet, preventing desynchronization problems when decoding/mixing multiple RTP streams (with sox, ...)

-n

Dump packets passing the single packet pattern but not the multiple packets pattern (the noise packets) to pcap file

-f

Disable stdout logging

-F

Enable syslog logging

-v

Be verbose

SELECT

-m

Sniff packets in promiscuous mode

-p <str>

Consider only packets matching the libpcap filter <str>

-e

Expect an even destination UDP port. The RTP packets must have an even destination UDP port. This should be always true, anyway some VoIP networks (like Yahoo) don't respect this rule

-u

Expect unprivileged source/destination UDP ports (> 1024). This should always be true

-y <int>

The RTP packets must have exactly this payload type. For example, if we want only RTP streams with data encoded in G.711 ulaw, we should add the option -y 0, value obtained from the -k option

-l <int>

The RTP payload length must be exactly <int> bytes

-t <float>

Consider terminated any session without new packets for <float> seconds

-T <float>

Consider a timeout of <float> seconds in the pattern over multiple packets

-P <int>

Consider <int> packets in the pattern over multiple packets

EXECUTION

-Z <str>

Run as user <str>

-D

Run in background (option -f implicit)

MISC

-k

Dump a list of known RTP payload types. Note that, because of the useless functionality called "Dynamic RTP Payload", those values shouldn't be considered too much. The rtp_payload_type and codec association is in fact concorded through the Signaling messages (SIP, H.323, SCCP, ...), assigning new values also for those codecs already having a standard and predefined value

-h

Display a summary of the valid options and exit

The files in the output directory have the following naming scheme: The set of files with pattern rtp.x.* refer to the rtpbreak execution number x, the subset of files with pattern rtp.x.y.* refer to the RTP session number y (of the rtpbreak execution number x). At each execution and at each RTP session detection, x and y are respectively incremented. The set of output files of the rtpbreak execution number x is organized as follows:

rtp.x.txt

The rtpbreak execution log, always generated

rtp.x.noise.pcap

The noise packets, generated with option -n enabled

rtp.x.y.*

For each detected RTP stream y:

rtp.x.y.raw

The transported raw data of the RTP session y. Generated by default, can be disabled with option -w enabled

rtp.x.y.pcap

The reordered packets of the RTP session y. Generated by default, can be disabled with option -W enabled

rtp.x.y.txt

The y RTP session log, always generated

Examples

Record, mix and replay a VoIP call

xenion@gollum:~/dev/rtpbreak-1.3$ sudo src/rtpbreak -i wifi0 -g -m -d logz
 + rtpbreak v1.3 running here!
 + pid: 3580, date/time: 19/02/2008#09:49:21
 + Configuration
   + INPUT
     Packet source: iface 'wifi0'
     Force datalink header length: disabled
   + OUTPUT
     Output directory: 'logz'
     RTP raw dumps: enabled
     RTP pcap dumps: enabled
     Fill gaps: enabled
     Dump noise: disabled
     Logfile: 'logz/rtp.0.txt'
     Logging to stdout: enabled
     Logging to syslog: disabled
     Be verbose: disabled
   + SELECT
     Sniff packets in promisc mode: enabled
     Add pcap filter: disabled
     Expecting even destination UDP port: disabled
     Expecting unprivileged source/destination UDP ports: disabled
     Expecting RTP payload type: any
     Expecting RTP payload length: any
     Packet timeout: 10.00 seconds
     Pattern timeout: 0.25 seconds
     Pattern packets: 5
   + EXECUTION
     Running as user/group: root/root
     Running daemonized: disabled
 * You can dump stats sending me a SIGUSR2 signal
 * Reading packets...
 ! [rtp0] detected: pt=0(g711U) 192.168.0.30:2072 => 192.168.0.20:2074
 ! [rtp1] detected: pt=0(g711U) 192.168.0.20:2074 => 192.168.0.30:2072
 * [rtp1] probable reverse RTP stream: [rtp0]
 + Status
   Alive RTP Sessions: 2
   Closed RTP Sessions: 0
   Detected RTP Sessions: 2
   Flushed RTP packets: 3358
   Lost RTP packets: 122 (3.51%)
   Noise (false positive) packets: 0
 + [rtp1] stats: packets inbuffer=262 flushed=1673 lost=61(3.52%), call_length=1m2s
 + [rtp0] stats: packets inbuffer=270 flushed=1685 lost=61(3.49%), call_length=1m2s
 * [rtp1] closed: packets inbuffer=0 flushed=2800 lost=115(3.95%), call_length=1m28s
 * [rtp0] closed: packets inbuffer=0 flushed=2819 lost=106(3.62%), call_length=1m28s
--
Caught SIGINT signal (2), cleaning up...
--
 + Status
   Alive RTP Sessions: 0
   Closed RTP Sessions: 2
   Detected RTP Sessions: 2
   Flushed RTP packets: 5619
   Lost RTP packets: 221 (3.78%)
   Noise (false positive) packets: 0
 + No active RTP streams

xenion@gollum:~/dev/rtpbreak-1.3$

We've sent a SIGUSR2 signal to the rtpbreak process at call_length=1m2s, forcing a stats print. The final output directory content is the following:

xenion@gollum:~/dev/rtpbreak-1.3$ ls -1 logz
rtp.0.0.pcap
rtp.0.0.raw
rtp.0.0.txt
rtp.0.1.pcap
rtp.0.1.raw
rtp.0.1.txt
rtp.0.txt
xenion@gollum:~/dev/rtpbreak-1.3$

Those are the two RTP sessions logs:

xenion@gollum:~/dev/rtpbreak-1.3$ cat logz/rtp.0.0.txt 
RTP stream id: rtp.0.0
Packet source: iface  'wifi0'
First seen packet: 19/02/2008#09:49:29 (pcap time)
Stream peers: 192.168.0.30:2072 => 192.168.0.20:2074
RTP ssrc: 1695569992
RTP payload type: 0 (ITU-T G.711 PCMU)
Last seen packet: 19/02/2008#09:50:57 (pcap time)
Call length: 1m28s
Flushed packets: 2819
Lost packets: 106 (3.62%)
RTP payload length: 240 bytes (fixed)
xenion@gollum:~/dev/rtpbreak-1.3$ cat logz/rtp.0.1.txt 
RTP stream id: rtp.0.1
Packet source: iface  'wifi0'
First seen packet: 19/02/2008#09:49:29 (pcap time)
Stream peers: 192.168.0.20:2074 => 192.168.0.30:2072
RTP ssrc: 112268413
RTP payload type: 0 (ITU-T G.711 PCMU)
Probable reverse RTP stream id: rtp.0.0
Last seen packet: 19/02/2008#09:50:57 (pcap time)
Call length: 1m28s
Flushed packets: 2800
Lost packets: 115 (3.95%)
RTP payload length: 240 bytes (fixed)
xenion@gollum:~/dev/rtpbreak-1.3$

Now, we've to decode, mix and replay this recorded call:

xenion@gollum:~/dev/rtpbreak-1.3$ sox -r8000 -c1 -t ul logz/rtp.0.0.raw -t wav logz/0.wav
xenion@gollum:~/dev/rtpbreak-1.3$ sox -r8000 -c1 -t ul logz/rtp.0.1.raw -t wav logz/1.wav
xenion@gollum:~/dev/rtpbreak-1.3$ sox -m logz/0.wav logz/1.wav logz/call.wav
xenion@gollum:~/dev/rtpbreak-1.3$ mplayer logz/call.wav

Analyze an RTP session

xenion@gollum:~/dev/rtpbreak-1.3$ rtpbreak -P2 -t100 -T100 -d logz -r h323.pcap  
 + rtpbreak v1.3 running here!
 + pid: 4613, date/time: 19/02/2008#10:18:54
 + Configuration
   + INPUT
     Packet source: rxfile 'h323.pcap'
     Force datalink header length: disabled
   + OUTPUT
     Output directory: 'logz'
     RTP raw dumps: enabled
     RTP pcap dumps: enabled
     Fill gaps: disabled
     Dump noise: disabled
     Logfile: 'logz/rtp.1.txt'
     Logging to stdout: enabled
     Logging to syslog: disabled
     Be verbose: disabled
   + SELECT
     Sniff packets in promisc mode: disabled
     Add pcap filter: disabled
     Expecting even destination UDP port: disabled
     Expecting unprivileged source/destination UDP ports: disabled
     Expecting RTP payload type: any
     Expecting RTP payload length: any
     Packet timeout: 100.00 seconds
     Pattern timeout: 100.00 seconds
     Pattern packets: 2
   + EXECUTION
     Running as user/group: xenion/xenion
     Running daemonized: disabled
 * You can dump stats sending me a SIGUSR2 signal
 * Reading packets...
 ! [rtp0] detected: pt=102(?) 172.16.1.109:5004 => 172.16.1.105:5012
 ! [rtp1] detected: pt=0(g711U) 172.16.1.105:5012 => 172.16.1.109:5004
 * [rtp1] probable reverse RTP stream: [rtp0]
 ! [rtp2] detected: pt=31(h261) 172.16.1.109:5006 => 172.16.1.105:5014
 * eof reached.
--
Caught SIGTERM signal (15), cleaning up...
--
 * [rtp2] closed: packets inbuffer=0 flushed=2286 lost=0(0.00%), call_length=4m10s
 * [rtp1] closed: packets inbuffer=0 flushed=4465 lost=0(0.00%), call_length=4m8s
 * [rtp0] closed: packets inbuffer=0 flushed=6254 lost=0(0.00%), call_length=4m10s
 + Status
   Alive RTP Sessions: 0
   Closed RTP Sessions: 3
   Detected RTP Sessions: 3
   Flushed RTP packets: 13005
   Lost RTP packets: 0 (0.00%)
   Noise (false positive) packets: 70
 + No active RTP streams

xenion@gollum:~/dev/rtpbreak-1.3$

xenion@gollum:~/dev/rtpbreak-1.3$ ls -1 logz
0.wav
1.wav
call.wav
rtp.0.0.pcap
rtp.0.0.raw
rtp.0.0.txt
rtp.0.1.pcap
rtp.0.1.raw
rtp.0.1.txt
rtp.0.txt
rtp.1.0.pcap
rtp.1.0.raw
rtp.1.0.txt
rtp.1.1.pcap
rtp.1.1.raw
rtp.1.1.txt
rtp.1.2.pcap
rtp.1.2.raw
rtp.1.2.txt
rtp.1.txt
xenion@gollum:~/dev/rtpbreak-1.3$

xenion@gollum:~/dev/rtpbreak-1.3$ cat logz/rtp.1.0.txt
RTP stream id: rtp.1.0
Packet source: rxfile 'h323.pcap'
First seen packet: 14/11/2006#17:57:29 (pcap time)
Stream peers: 172.16.1.109:5004 => 172.16.1.105:5012
RTP ssrc: 268399165
RTP payload type: 102 (Unknown)
Last seen packet: 14/11/2006#18:01:39 (pcap time)
Call length: 4m10s
Flushed packets: 6254
Lost packets: 0 (0.00%)
RTP payload length: 65 bytes (fixed)
xenion@gollum:~/dev/rtpbreak-1.3$ cat logz/rtp.1.1.txt
RTP stream id: rtp.1.1
Packet source: rxfile 'h323.pcap'
First seen packet: 14/11/2006#17:57:29 (pcap time)
Stream peers: 172.16.1.105:5012 => 172.16.1.109:5004
RTP ssrc: 1910395951
RTP payload type: 0 (ITU-T G.711 PCMU)
Probable reverse RTP stream id: rtp.1.0
Last seen packet: 14/11/2006#18:01:37 (pcap time)
Call length: 4m8s
Flushed packets: 4465
Lost packets: 0 (0.00%)
RTP payload length: 240 bytes (fixed)
xenion@gollum:~/dev/rtpbreak-1.3$ cat logz/rtp.1.2.txt
RTP stream id: rtp.1.2
Packet source: rxfile 'h323.pcap'
First seen packet: 14/11/2006#17:57:29 (pcap time)
Stream peers: 172.16.1.109:5006 => 172.16.1.105:5014
RTP ssrc: 267301810
RTP payload type: 31 (ITU-T H.261)
Last seen packet: 14/11/2006#18:01:39 (pcap time)
Call length: 4m10s
Flushed packets: 2286
Lost packets: 0 (0.00%)
RTP payload length: 945 bytes (variable, this is the last seen)
xenion@gollum:~/dev/rtpbreak-1.3$

Now, we completely dissect the first packet of the third RTP session with tshark:

xenion@gollum:~/dev/rtpbreak-1.3$ cat logz/rtp.1.2.txt | grep "Stream peers"
Stream peers: 172.16.1.109:5006 => 172.16.1.105:5014
xenion@gollum:~/dev/rtpbreak-1.3$ tshark -r logz/rtp.1.2.pcap -d udp.port==5006,rtp -c 1 -V
Frame 1 (1073 bytes on wire, 1073 bytes captured)
    Arrival Time: Nov 14, 2006 17:57:29.972300000
    [Time delta from previous captured frame: 0.000000000 seconds]
    [Time delta from previous displayed frame: 0.000000000 seconds]
    [Time since reference or first frame: 0.000000000 seconds]
    Frame Number: 1
    Frame Length: 1073 bytes
    Capture Length: 1073 bytes
    [Frame is marked: False]
    [Protocols in frame: eth:ip:udp:rtp:h261]
Ethernet II, Src: Dell_15:09:a6 (00:12:3f:15:09:a6), Dst: Dell_ca:ec:cd (00:14:22:ca:ec:cd)
    Destination: Dell_ca:ec:cd (00:14:22:ca:ec:cd)
        Address: Dell_ca:ec:cd (00:14:22:ca:ec:cd)
        .... ...0 .... .... .... .... = IG bit: Individual address (unicast)
        .... ..0. .... .... .... .... = LG bit: Globally unique address (factory default)
    Source: Dell_15:09:a6 (00:12:3f:15:09:a6)
        Address: Dell_15:09:a6 (00:12:3f:15:09:a6)
        .... ...0 .... .... .... .... = IG bit: Individual address (unicast)
        .... ..0. .... .... .... .... = LG bit: Globally unique address (factory default)
    Type: IP (0x0800)
Internet Protocol, Src: 172.16.1.109 (172.16.1.109), Dst: 172.16.1.105 (172.16.1.105)
    Version: 4
    Header length: 20 bytes
    Differentiated Services Field: 0x10 (DSCP 0x04: Unknown DSCP; ECN: 0x00)
        0001 00.. = Differentiated Services Codepoint: Unknown (0x04)
        .... ..0. = ECN-Capable Transport (ECT): 0
        .... ...0 = ECN-CE: 0
    Total Length: 1059
    Identification: 0x0000 (0)
    Flags: 0x04 (Don't Fragment)
        0... = Reserved bit: Not set
        .1.. = Don't fragment: Set
        ..0. = More fragments: Not set
    Fragment offset: 0
    Time to live: 64
    Protocol: UDP (0x11)
    Header checksum: 0xdbc3 [correct]
        [Good: True]
        [Bad : False]
    Source: 172.16.1.109 (172.16.1.109)
    Destination: 172.16.1.105 (172.16.1.105)
User Datagram Protocol, Src Port: wsm-server (5006), Dst Port: 5014 (5014)
    Source port: wsm-server (5006)
    Destination port: 5014 (5014)
    Length: 1039
    Checksum: 0x5f17 [incorrect, should be 0x270c (maybe caused by "UDP checksum offload"?)]
        [Good Checksum: False]
        [Bad Checksum: True]
Real-Time Transport Protocol
    10.. .... = Version: RFC 1889 Version (2)
    ..0. .... = Padding: False
    ...0 .... = Extension: False
    .... 0000 = Contributing source identifiers count: 0
    0... .... = Marker: False
    Payload type: ITU-T H.261 (31)
    Sequence number: 42926
    Timestamp: 3003
    Synchronization Source identifier: 0x0feeb3b2 (267301810)
ITU-T Recommendation H.261
    Start bit position: 0
    End bit position: 2
    Intra frame encoded data flag: False
    Motion vector flag: True
    GOB Number: 0
    Macroblock address predictor: 0
    Quantizer: 0
    Horizontal motion vector data: 0
    Vertical motion vector data: 0
    H.261 stream: 00010006000113220300C0300DFF7FD1019B8103881035C0...

xenion@gollum:~/dev/rtpbreak-1.3$

Particular scenarios

Scope: We want to (successfully) handle some particular scenarios. This is a list of problem description, (probable) cause and (hopefully) solution.

1. Problem

   An improbable high number of RTP sessions and noise packets is detected.

   Cause

   There is some type of silence suppression.

   Solution

   Dilate the timeouts:

   rtpbreak -i eth0 -n -t100 -T100
   

2. Problem

   An expected RTP session is not recognized and some noise packets are detected.

   Cause

   The conversation has been immediately terminated.

   Solution

   Reduce the number of required packets for the multiple packets pattern:

   rtpbreak -i eth0 -n -P2
   

3. Problem

   The expected RTP sessions are not recognized.

   Cause

   The protocol is not RTP, the network interface is not in promisc mode, the conversation is very disturbed, the conversation was immediately terminated.

   Solution

   Dilate the timeouts and reduce the number of required packets for the multiple packets pattern:

   rtpbreak -i eth0 -m -n -P2 -t100 -T100
   

   This is the most aggressive (and computationally expensive) configuration of the detection heuristics and will always detect any RTP session.

How it works

The RTP sessions are composed by an ordered sequence of RTP packets. Those packets transport the Real Time data using the UDP transport protocol. The RTP packets must respect some well defined rules in order to be considered valid, this characteristic allows us to define a pattern on the single packet that is used to discriminate the captured network traffic from packets that can be RTP and those that securely are not. The fixed RTP header has this format:

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|V=2|P|X|  CC   |M|     PT      |       sequence number         |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                           timestamp                           |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|           synchronization source (SSRC) identifier            |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
|            contributing source (CSRC) identifiers             |
|                             ....                              |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

The following checks are performed (on each sniffed packet):

1. Destination UDP port: The destination UDP port must be even, as specified in [rfc1889]. Beyond this, it must be greater than 1024. This because in the UDP and TCP transport protocols the ports <= 1024 are considered privileged and they can't be used by user applications, like VoIP clients.
2. Minimal packet size: The UDP payload size must be greater than 12 bytes, this is the size of the fixed header always present in any RTP packet.
3. RTP version: The RTP protocol version always used is 2, so the value of the V field in the fixed RTP header must be equal to 2.
4. Padding bit: RTP allows to append some bytes as packet trailer, that must be ignored. The number of those bytes is specified exactly in the last packet byte. The P field in the fixed RTP header indicates if this functionality is active. If active, the RTP payload size is adjusted, checking it to be greater than 0.
5. CSRC list: RTP allows the RTP Mixer to insert a list of contributing sources. This list, if present, follows immediately the fixed RTP header and it's composed by addresses (of 32 bits), their number is indicated by the CC field in the fixed RTP header. If present, the RTP payload size is adjusted, checking it to be greater than 0.
6. Extension bit: RTP allows to extend the fixed RTP header. If present, this extension follows the fixed RTP header and the optional CSRC list. His format follows:

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |      defined by profile       |           length              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                        header extension                       |
   |                             ....                              |
   

   The length field indicates the extension size, header of the extension excluded. His presence is indicated by the X field value. If active, the RTP payload size is adjusted, checking it to be greater than 0.

The UDP packets passing those checks are considered like "maybe RTP" packets. Note that the IP and UDP packet checksums aren't checked because quite often they're erroneously computed by VoIP clients. The UDP packets passing those checks are compared with the already detected RTP sessions (this is called pattern over multiple packets). The comparison is done considering the following informations:

1. SSRC: The value of the SSRC field in the fixed RTP header indicates the unique identifier of the Sender of the session. His value is constant in all RTP packets of the same session.
2. IP addresses and UDP ports: The IP addresses and the UDP ports of the Sender and Receiver are constant in all RTP packets of the same session.
3. Sequence number: The seq field in the fixed RTP header indicates the packet sequence number, a value that isn't necessarily initialized to 1 but that it's strictly increasing in RTP packets of the same session. It's considered a window of acceptable values for each session, that changes dynamically. This allows to consider the eventuality that some RTP packets may have been lost.
4. Timestamp: The ts field in the fixed RTP header indicates the sampling timestamp of the first byte of the RTP payload, a value strictly increasing in RTP packets of the same session. Also in this case it's considered a window of acceptable values for each session, that changes dynamically. This allows to consider the eventuality that some RTP packets may have been lost.

If it's identified a possible session, the UDP packet is inserted in his buffer. If this doesn't happen, a new one is created. When to a session are assigned a minimal set of UDP packets, it's considered valid and any UDP packet in his buffer is considered definitely RTP. This must happen before a timeout, after that the session is considered a false positive (noise packets) and destroyed.

Dependencies and compilation

• libnet1
• libnet1-dev
• libpcap0.7
• libpcap0.7-dev

To compile, type "make" in the top directory.

In order to decode the RTP streams with sox, you need sox with the support for the required formats. In debian, you need the following packages:

• sox
• libsox-fmt-all

Links

• Antifork: http://www.antifork.org
• xenion headquarter: http://xenion.antifork.org
• rtpbreak home: http://xenion.antifork.org/rtpbreak

SS7信令协议栈，MTP1，MTP2，MTP3，SCCP，TCAP，ISUP，TUP

3.1 SS7信令协议栈

　　协议是通过网络传送数据的规则集合。 协议栈也就是协议的分层结构，协议分层的目的是为了使各层相对独立，或使各层具有不同的职能。SS7协议一开始就是按分层结构的思想设计的，但SS7协议在开始发展时，主要是考虑在数字电话网和采用电路交换方式的数据通信网中传送各种与电路有关的信息，所以CCITT在80年代提出的SS7技术规范黄皮书中对SS7协议的分层方法没有和OSI七层模型取得一致，对SS7协议只提出了4个功能层的要求。这4个功能层如下：

• 物理层：就是底层，具体是DS0或V.35。
• 数据链路层：在两节点间提供可靠的通信。
• 网络层：提供消息发送的路由选择.。
• 用户部份／应用部份：就是数据库事务处理，呼叫建立和释放。

　　但随着综合业务数字网（ISDN）和智能网的发展，不仅需要传送与电路有关的消息，而且需要传送与电路无关的端到端的消息，原来的四层结构已不能满足要求。在1984年和1988年的红皮书和蓝皮书建议中，CCITT作了大量的努力，使SS7协议的分层结构尽量向OSI的七层模型靠近。

下图图示了SS7信令协议栈：

MTP1(消息传递部分第一层)：即物理层。
MTP1(消息传递部分第二层)：即数据链路层。
MTP1(消息传递部分第三层)：即网络层。
SCCP（信令连接控制部分）
TCAP（事务处理应用部分）
ISUP（ISDN用户部分）
TUP（电话用户部分）

• MTP1
  　　MTP1是SS7协议栈中的最底层，对应于OSI模型中的物理层，这一层定义了数字链路在物理上，电气上及功能上的特性。物理接口的定义包括：E－1，T－1，DS－1，V.35,DS－0，DS －0A（56K）。

• MTP2
  　　MTP2确保消息在链路上实现精确的端到端传送。MTP2提供流控制，消息序号，差错检查等功能。当传送出错时，出错的消息会被重发。MTP2对应OSI模型中的数据链路层。

• MTP3
  　　MTP3在SS7信令网中提供两个信令点间消息的路由选择功能，消息在依次通过MTP1，MTP2，MTP3层之后，可能会被发送回MTP2再传向别的信令点，也可能会传递给某个应用层，如：SCCP或ISUP层。MTP3还提供一些网管功能的支持，包括：流量控制，路由选择和链路管理。MTP3对应OSI模型中的网络层。

• SCCP（信令连接控制部分）
  　　SCCP位于MTP之上，为MTP提供附加功能，以便通过SS7信令网在信令点之间传递电路相关和非电路相关的消息，提供两类无连接业务和两类面向连接的业务。 无连接业务是指在两个应用实体间，不需要建立逻辑连接就可以传递信令数据。面向连接的业务在数据传递之前应用实体之间必须先建立连接，可以是一般性的连接，也可以是逻辑连接。 SCCP以全局码（GT）的形式扩展SS7协议的寻址能力和路由能力，这些扩展基于被叫号码的寻址信息。

• TCAP（事务处理应用部分）
  　　TCAP允许应用调用远端信令点的一个或多个操作，并返回操作的结果。比如：数据库访问或远端调用处理命令等。使用SCCP无连接业务（基本的或有序的），TCAP 在两个用户应用之间提供事务处理对话。

• ISUP（ISDN用户部分）
  　　ISUP在交换局提供基于电路的连接，它直接和MTP3层通信。 ISUP提供基础电信业务，包括连接建立，监示和释放。

• TUP（电话用户部分）
  　　在ITU－TS标准里，TUP和ISUP功能相似，提供相似的业务（如：呼叫建立和拆除）。TUP提供的业务比ISUP少，不支持ISUP中某些业务类别，比如：非话音业务和补充业务，还有，TUP不传递与电路无关的消息包。

• TUP与ISUP比较
  • 应用范围：TUP主要用于南美洲，墨西哥，亚洲和东欧国家。而ISUP用于其他地方的国家。
  • ISUP比TUP提供更丰富的业务，特别是非话音数字业务。
  • TUP和ISUP都提供快速的呼叫建立和拆除；都在呼叫请求消息里包含主叫号码。

　　总的来说，TUP和ISUP的基本功能相同，ISUP能提供更多的业务，它们分别在不同的国家得到了应用。