Hi, (for those who are more interested in h323 analysis)
maybe some words on how the H323 analysis works in general. There are
some open questions, if you have any better idea for some solutions,
please put it down!
1. When you click on the Statistics->H.323->Show all H.323 Conversations
(maybe this positions and name should be changed) the tap for h225 and
h245 are registered and captured packets are redisected
2. Whenever a h225 packets is seen, it is checked whether it is already
part of a conversation (should the word "call" be used instead of
conversation?) in the list. The check is done using the ip/port pair
combination (should we use some other parameters as well - CALL ID?). If
not, it is added to the list. At this time we also look for the h.245
address which is normally provided in h225 connect message. We need this
address to follow the h245 part of the call in case there is no
faststart. If h245 packet arrives, it is checked to which call does it
belong (based on ip/port) and the counter is increased. If h245 packet
is seen without appropriate h225 part, it is skipped (f.e. in case the
capturing started after the h225 phase).
3. After the redisection of the packets, the taps are removed.
4. The user can now set the filter or select a conversation and press
the Analyse button. This one opens a new window, registers the taps
again and goes through the redisection again filtering out only the
selected conversation. Now the course of h225 and h245 events is
displayed with the delay between the packets and the time from the first
packet. Currently only the most common messages are displayed by name
(look in packet-h225.h and packet-h245.h which one), all the rest are of
type H225_OTHER and H245_OTHER (btw: h323_analysis.c, line 286, should
be H245_OTHER not H225_OTHER, it's a bug).
In the main window, there is an indication for FASTSTART and STATUS of a
call, which caused me problems (or questions):
For the faststart the logic implemented behind is:
With the first h225 packet (should be Setup, but can be missing, Alert,
Call Proc are possible) there is a check if faststart field is included.
If yes, the indication goes on TRUE. Finally, the Connect message is
examined. Depending on existence of faststart field in this message the
status is fixed on true or false. To summarize, if there is faststart
field in connect message, then the FASTSTART was used. Is this ok?
Status of the call:
There are for states I used:
CALL SETUP, IN CALL, COMPLETED and REJECTED:
- After the Setup, Call Proceding and Alerting message the status is
CALL SETUP
- After the Connect message the status is IN CALL
- If the Release Complet is sent after the IN CALL phase the status is
REJECTED.
- If the Release Complet is sent after the CALL SETUP state, the status
is REJECTED
- Otherwise the status is UNKNOWN
I'm aware there are exceptions, f.e if the call in rejected when there
is no faststart in h245 phase. So this part has to be done more
accurate. If you have any suggestions here...
Currently support for the H225 RAS messages is missing.
Feature to launch the RTP analysis from the selected h323 call does not
work yet.
Miha
--
Miha Jemec <m.jemec@xxxxxxxxxxx>
