LOG file description

• the FIN/ACK or RST segments are observer
• no packet has been observed (from both sides) for IDLE_TIME microsecond (defined in param.h). By default is set to 10 min.

Tstat produces a "log_udp_complete" file which logs every UDP possible flow pair tracked by tstat. By default, only P2P UDP traffic is logged here. UDP information for other application protocols (Skype, IM protocols, etc.) is logged in the protocol own log_*_complete file. It's possible to log all the UDP traffic by defining LOG_ALL_UDP.
An UDP flow pair is identified when the first UDP segment is observed for a UDP socket pair, and is ended when no packet has been observed (from both sides) for UDP_IDLE_TIME microsec (defined in param.h). By default is set to 5 min.
Each line is composed of two parts: values referring to the "client" host (i.e. the host source of the first segment for the flow), and values referring to the "server" host (i.e. the destination of the first segment of the flow).
Here it follows a brief description of the columns.

log_udp_complete		Parameters logged in the UDP flow level log file
Column no.		Short desc	Long descr
Client	Server
1	9	Client/Server IP address	IP addresses of the client/server
2	10	Client/Server UDP port	UDP port addresses for the client/server
3	11	First time	Client/Server first packet time since first segment ever [ms]
4	12	Completion time	Time between the first and the last packet from the client/server [s]
5	13	Data bytes	Number of bytes transmitted in the payload
6	14	Packets	Total number of packets observed from the client/server
7	15	Internal	Bool set to 1 if the client/server has internal IP
8	16	UDP Type	Protocol type for the client->server/server->client semiflow. See description below.

Similarly, a complete log keeping track of each RTP flow measured indexes is maintained in the log_rtp_complete file.
Being it impossible to detect RTP/RTCP flows, a heuristic methodology as been implemented. A state machine is used, to track RTP flows. At the first UDP packet, it is labeled as unknown. For each new UDP flows, Tstat double checks if the UDP payload may be an RTP/RTCP packet. This is done by double checking that

• the version field is set to 2
• the payload type field has an admissible values (for RTP or for RTCP)
• the UDP ports are larger than 1024 and are even/odd for RTP/RTCP

If so, the flow is marked as possible RTP/RTCP flow (first_RTP/first_RTCP status).

When the second UDP segment of this UDP flow (same IP/ports) is observed, then Tstat double checks it still be interpreted as RTP/RTCP payload.
In the case of RTP flows, it checks that

• the version is equal to 2
• the same ssrc is present
• the seqno is the expected one
• the payload type is the same as before.

Then the flows is marked as RTP and its analysis may start.

For RTCP flows, a simpler heuristic is used:

• the version must be equal to 2
• the payload type must be a correct one
• the UDP ports are larger than 1024 and are even/odd for RTP/RTCP.

If so, the flow is considered a RTCP flow and its analysis may start.

For each RTP flow which is successfully tracked, a line in the log_rtp_complete file will be written when the flows ends. Here it follows a brief description of the columns.

log_rtp_complete	Parameters logged in the RTP flow level log file
Col no.	Short desc	Long descr
1	Client IP addr	IP addresses of the transmitter
2	Client TCP port	UDP port addresses of the transmitter
3	pnum	total number of packets observed
4	ssrc	synchronization source identifier used
5	avg pkt delay	average inter-packet gap [ms] over the all session
6	jitter	average jitter observed over all session (RFC3550)
7	out of sequence	total number of out of sequence packets observed
8	duplicate	total number of duplicate packets observed
9	late	total number of late packets observed
10	lost	total number of lost packets observed
11	internal src	1 if the IP sender address was internal
12	internal dst	1 if the IP sender address was internal

Similarly, a complete log keeping track of each CHAT flow measured indexes is maintained in the log_chat_complete file.

Tstat is able to classify MSN Messenger, Yahoo! Messenger and Chat based on XMPP Protocol such as Jabber or Google Talk.

For each chat flow which is successfully tracked, a line in the log_chat_complete file will be written when the flows ends. Here it follows a brief description of the columns.

log_chat_complete		Parameters logged in the CHAT flow level log file
Column no.		Short Description	Long Description
Client	Server
1	11	Client/Server IP addr	IP address of the client/server
2	12	Client/Server port	TCP port address for the client/server
3	13	Flow Size	Flow Size [Bytes]
4	14	Total packets	No. of Total flow packets
5	15	Total messages	No. of Total messages sent by client
6	16	No. of MSGs A	No. of messages "A" sent by client [for MSN only, always 0 for the others]
7	17	No. of MSGs D	No. of messages "D" sent by client [for MSN only, always 0 for the others]
8	18	No. of MSGs N	No. of messages "N" sent by client [for MSN only, always 0 for the others]
9	19	No. of MSGs U	No. of messages "U" sent by client [for MSN only, always 0 for the others]
10	20	No. of MSGs Y	No. of messages "Y" sent by client [for MSN only, always 0 for the others]
21		Start Time	Flow Start Time (Unix Epoch Time) [s]
22		End Time	Flow End Time [s]
23		Chat Flow Type	Chat Flow Type : see below
24		Chat Version	Version of the protocol used by the Instant Messaging application
25		Internal	Client IP address is internal ? (0=no, 1=yes)
26		TCP Flow No.	TCP Flow ID Number
27		"T"	Label to state a TCP Flow
28		Chat Protocol	Type of Upper Level Protocol [32=MSN, 64=Yahoo, 128=Jabber/GTalk]

Chat Flow Type
Value	Description	IM Protocols
0	Unknown	All
1	Login	All
2	Presence	All
3	Chat	All
4	Presence+Chat	Yahoo only
5	Http Tunneling	MSN only
6	Peer-to-Peer Chat (i.e. direct TCP connection between clients instead of C2S/S2C)	Yahoo only
7	Unclassified Yahoo Messenger flow	Yahoo only

Each message tracked by Tstat is maintained in the log_chat_messages file.

Tstat is able to detect messages received or sent by MSN, Yahoo, Jabber or GTalk clients.

For each chat message successfully tracked, a line in the log_chat_messages file will be written as soon as the message is received/sent. Here it follows a brief description of the columns.

log_chat_messages	Parameters logged in the CHAT flow level log file
Col no.	Short Description	Long Description
1	TCP Flow No.	TCP Flow ID Number
2	Message Type	Type of Message (? if not available)
3	Dir	TCP Flow Direction (1=C2S, -1=S2C)
4	Message Size	Message Payload Size [Bytes] (? if not available)
5	Payload Size	TCP Payload Size [Bytes]
6	Start Time	Flow Start Time (Unix Epoch Time) [s]
7	Arrival Time	Message Arrival Time [s]