Information Technology Reference
In-Depth Information
across a new message that is not in the set, then the message is added
automatically to the database in the table for future use. In the second
part of the algorithm, simple message matching is performed. The input
of this algorithm is a single H.245 message, mi (mi is the
i
th message to be
encoded), and the output is the corresponding bit stream B(mi). Looking
from the programming point of view, during the system initialization, a
H.245 message set is compiled into bit streams and then is stored in a table,
T(m). For each H.245 message mi (to be encoded), it is looked for in the
precompiled message database (i.e., table T(m)), if a match is found, then it
is retrieved and returned. After that, the returned bit stream B(mi) is fur-
ther checked if a replacement is needed, if no, B(mi) is returned directly,
if yes, then the changed field(s) is dynamically compiled, replaced, and
returned. However, if the message mi is not found, then it is just compiled
and returned dynamically and is stored in the database for further use
(for the next incoming calls).
One of the key issues of the lookup table approach is to find the efficient
way to manage the table data storage and retrieval system. We propose the
table should be managed in an index-based fashion. Each encoded message
string is saved as an array in that table with an index number. So in the
retrieval process, each entity is returned in terms of its reference number
(integer). This approach is used because, it is a much less time consuming
way to locate and return each table entry as compared to the traditional
algorithms involving special key generation. Thus, an appreciable amount
of time can be saved for data retrieval in the table and eventually leading
to a big gain in the overall system performance. Figure 3.13 describes this
procedure pictorially.
3.4.4 Performance evaluation and Discussion
In this section, we evaluate the performance and efficiency of our method
through experimental results. As we have already mentioned earlier, we
have developed our IP-3G bidirectional call handling gateway. Our system
leverages PC to PSTN/PC and vice versa video, voice, and text chatting-
conferencing provision.
We have successfully tested our 3G-gateway for the compatibility test after
embedding the currently proposed performance enhancement algorithm
into it. We made phone calls to different brands and makes of 3G handsets
and also to the Dilithium 3G Network Analyzer (model no. FXPAG-P42G).
All attempts of 3G video calls were setup and conversations were held suc-
cessfully. It proves that the proposed algorithm is fully compatible with the
existing 3G protocol as well as with all commercially available 3G handsets
or mobile devices too, as depicted in Figure 3.14.
Although the gateway is verified to be fully compatible and interoper-
able with SIP and 3G-324M protocol stack, we still have some difficulties in
subscribing a T1 line from a local operator. Due to this constraint, we can
