7.8 H.323 Implementation Architecture


7.8 H.323 Implementation Architecture

Implementation of H.323 using a wireless link is shown in Figure 7.8. The wireless VoIP terminal is H.323 capable and uses a wireless air interface protocol such as GPRS or cdma2000 to connect to the base station. The other VoIP terminal connected to the Internet also is H.323 capable. The medium is voice packets. The terminals have two major functional planes:

  1. The signaling plane that receives all messages coming to H.323 protocol supporting RAS (registration, admission, and status), H.225, and H.245.

  2. The media plane that receives messages of H.323 belonging to RTP/RTCP. Recall that the control messages of H.225 and H.245 are carried on TCP, whereas RTP/RTCP messages are carried on UDP.

click to expand
Figure 7.8: High-level view of VoIP implementation.

If the H.225 and H.245 messages are carried on UDP, there should not be significant differences in the analysis of our architecture. Note that TCP has three-way handshake and retransmission, while UDP has none. The characteristic difference between UDP and TCP over RLP (air link) is the three-way handshake, i.e., the beginning of the TCP session. The purpose of RLP is to provide reliable transmission, hence, TCP retransmission has no, if not zero, significant impact. The advantage of using UDP over TCP is (1) the UDP header overhead is lower (20 bytes as opposed to about 40 bytes for TCP), and (2) TCP has three-way handshake before each session. For an H.323 connection, typically, one handshake over air link is used. But there may be more than one if a gateway is being used, in that case, it is over land link communication only. If the air-link bandwidth is higher, so that 20 bytes vs. 40 bytes is not an issue, then the initial delay caused by the TCP three-way handshake is the only difference. The TCP retransmission could come in handy over a complex link (air and land) situation.

The performance of VoIP call setup using wireless links is influenced by three factors:

  1. The number of messages exchanged to set up the call

  2. The size of the messages

  3. The number of TCP sessions that are set up

Reduction of any of these factors results in shorter call setup delay. Table 7.1 shows the size of the signaling and control messages for call setup using regular H.323 procedures. The frames indicate the number of air links. The wireless link FER (probability) can be as high as 0.1. With this high FER, the regular H.323 procedure call setup delay contribution can be as high as 40 seconds for a 9.6-kbps link and 30 seconds for a 19.2-kbps link. This high delay is unacceptable, compared to the current call setup delay (less than 3 seconds) of the PSTN system. To improve performance, we consider direct routing call model for this implementation. Table 7.2 shows the fastConnect messages and their sizes, which are significantly reduced.

Table 7.1: Message Sizes Associated with the Regular Call Setup Procedure

Messages

Payload Size

Number of Frames (9.6 kbps)

Number of Frames (19.2 kbps)

Setup: H.225

254 octet

14

7

Alerting: H.225

97 octet

7

4

Connect: H.225

165 octet

10

5

TC Set: H.225

587 octet ( 2)

29 ( 2)

15 ( 2)

TC Set ACK: H.245 ( 2)

71 octet ( 2)

6 ( 2)

3 ( 2)

OC: H.245 ( 2)

115 octet ( 4)

8 ( 4)

4 ( 4)

OC ACK: H.245 ( 4)

64 octet ( 4)

5 ( 4)

3 ( 4)

RTCP packet

120 octet

8

4

Table 7.2: Message Sizes of the fastConnect Procedure

Messages

Payload Size

Number of Frames (9.6 kbps)

Number of Frames (19.2 kbps)

Setup + fastStart

599 octet

30

15

Alerting

97 octet

7

4

Connect + fastStart

280 octet

15

8

RTCP packet

120 octet

8

4

The calling endpoint initiates the fastConnect procedure by sending an H.225 setup message containing the fastStart element to the called endpoint. When the called endpoint accepts the fastConnect procedure, it sends an H.225 message (call proceeding, alerting, progress or connect) containing a fastStart element selected from among the open logical channel proposals offered by the calling point. The channel accepted is considered opened once the H.245 open logical channel and open logical channel ACK procedures have been completed. Then the called endpoint may begin transmitting media (according to the channel opened) immediately after sending an H.225 message containing the fastStart element. The calling endpoint must therefore be prepared to receive media on any of the receive channels it proposed in the H.225 set message, because it is possible for the media to be received prior to the H.225 message indicating precisely which channels to use. Once an H.225 message containing the fastStart element is received by the calling endpoint, it may discontinue attempting to receive media on the channels for which proposals were not accepted by the called endpoint. The calling endpoint may begin transmitting media according to the channels opened immediately upon receiving an H.225 message containing the fastStart element. Therefore, the called endpoint must be prepared to receive media on the channels it accepted in the H.225 message containing the fastStart element. After establishing a call using the fastConnect procedure, either endpoint may initiate the H.245 procedures at any time during the call, using tunneling or a separate H.245 connection. If a call using the fastConnect procedure continues to completion without initiating the H.245 procedure, it may be terminated by either endpoint sending an H.225 Release Complete message

The challenge for wireless VoIP is the higher FER of the wireless links. The control messages require a very high level of integrity and a very low BER quality although it is tolerant to delay. On the other hand, the RTP voice messages are very sensitive to delay, but can tolerate higher FER. It was observed in the current wireless network that the FER of 10-1 to 10-3 is suitable for reasonably good voice quality. In the wireless air interface, the RLP layer brings the attributes that are needed for the control messages, whereas for voice packets, RLP will degrade voice quality due to its delay variations and subsequent jitter. Therefore, we propose separating these two packet streams and handling them through two different mechanisms of the air interface. The control messages will be routed through the MAC/RLP layer of the air interface. But RTP voice packets will bypass the RLP stage and will be transmitted without any ARQ protection. In addition, we propose taking advantage of the tunneling concept of H.323 to encapsulate H.245 messages within H.225 messages. This capability is supported in H.323 recommendations, thus, N-PDUs created by H.323 processing will be classified into two classes by using a classifier. H.323 media streams for interactive traffic (particularly, VoIP) are treated differently than the H.323 control packet streams (e.g., H.225, H.245, RTCP messages). Because the VoIP packets can sustain higher FER than the control traffic, it is recommended that transparent RLP (i.e., no RLP retransmission) be used for VoIP packets, while nontransparent (regular) RLP be used for H.323 control packets. Due to the interactive nature of voice, VoIP packets should get higher priority over any in-band H.323 control packets within the session. Two types of subflows requiring differentiation have been identified for VoIP service using H.323:

  1. H.323 control packets including H.225 and RTCP: These packets need higher reliability for better performance. They have less-stringent delay requirements compared to media packets. The QoS to be satisfied for these packets is

    • Call setup delay is the time required to set up the call after completion of sending the information for the call, i.e., after pressing the send button of the wireless terminal. The H.225 signaling will control this delay.

    • Connection delay is the time required to make the media connection after receipt of the answer signal. RTCP packet synchronization will control this delay.

  2. H.323 media packets carried by RTP: These packets have lower reliability requirements than the control packets, but have stringent delay requirements. Handle these packets at highest priority within a delay restriction of 250 to 300 milliseconds. The two components of this QoS are the end-to-end delay of the voice packets and the blocking probability of the voice packets when multiple sources are sharing the same wireless resources.

7.8.1 Delay Analysis of H.323 Control Signaling over Wireless

We will assume the simple call setup message flows of H.323, as depicted in Figure 7.4. The total call setup delay will be the cumulative delay due to:

  1. Setup time for two TCP sessions that include exchange of SYN, SYN-ACK, and ACK messages

  2. Successfully transmitting all H.225 and H.245 messages

  3. Successfully receiving an RTCP CNAME message

First, we present the analysis of RTCP packets based on mathematical models as suggested in Bao [30] and Sen et al. [31] for CDMA networks. Next, we analyze H.323 call setup flows and their interactions with TCP. Some information in an RTCP packet is more important than other information, e.g., CNAME and BYE. They are critical and need to be reliably transmitted to guarantee user-perceived QoS and network performance. We assume a maximum of three trials in our analysis for RLP, and restrict the maximum retransmission time for a packet to be much less than the RTCP transmission interval T. (Note: We present here the results of the paper [see Das et al. [32], [33]] without discussing the details of the analysis. Interested readers can refer to the original papers for the details.)

7.8.2 Analysis of RTCP:CNAME Packet Delay

Let

p

=

The probability of a frame being in error in the air link

k

=

The number of RLP frames in an RTCP packet transmitted over air and T 5 seconds is the RTCP transmission interval

D

=

The end-to-end frame propagation delay over the radio channel, with typical values on the order of 100 milliseconds

τ

=

The interframe time of RLP with typical values on the order of 20 milliseconds

Assume a user just joined the RTP session. The average delay of receiving the CNAME packet indicates the waiting period for the user to play the associated RTP streams properly. Thus

The packet loss rate without RLP: q = 1 - (1- p)k

The packet loss rate with RLP: q = 1 - (1 - p(p(2 - p))6)k

Thus, the average delay (T1) associated with receiving the first RTCP CNAME packet after joining the session without RLP is given by

If RLP is used, the average delay T2 for a newly joined member to receive the first RTCP packet containing the CNAME item after joining the session with RLP can be approximated by

where the delay D is changed to D" for RLP retransmission and is given by

where Cij represents that the first frame received correctly at destination is the i-th retransmission frame at the j-th retransmission trial, n denotes the maximum number of RLP retransmissions, and Pf denotes the effective packet loss seen at the RTCP layer (q) and is given by

7.8.3 H.323 Call Setup Message Delay Analysis

Because H.225 and H.245 messages are carried over TCP, an analysis of TCP transport delay over wireless will lead to an insight to the H.323 call setup delay performance. We have assumed a radio channel bandwidth of 9.6 kbps. The two endpoints are assumed to be in close proximity, hence any wireline network delay is assumed to be negligible. The following assumptions are made about the end-to-end TCP sessions carrying the H.323 messages:

  1. TCP operates in an interactive mode.

  2. The delayed acknowledgment mode of TCP operation is turned off.

  3. TCP always times out whenever a packet is lost (i.e., it never does fast retransmit).

  4. Round-trip delay is 200 milliseconds, because the one-way delay for message (D) is assumed to be 100 milliseconds (approx.).

  5. The initial TCP round-trip timer (RTO) value is exactly equal to the round-trip delay. Subsequent variation of RTO is as specified for TCP. [34]

  6. If initial capability exchange or master-slave determination procedures fail, no retry should be issued, as opposed to the standard that suggests at least two additional retransmissions before the endpoint abandons the connection attempt.

Following Karn's algorithm for TCP timer backoff, the RTO is multiplied by a constant factor after each retransmission due to time out. Hence, RTOi+1 = c RTOi, where RTOi is the i-th TCP retransmission timer. This causes RTO to grow exponentially after each retransmission. We let c = 2, as it is most commonly implemented. Initially, RTO = 100 milliseconds, as assumed previously. Hence, RTOi = 2i 100 milliseconds, ..., RTOi = 2i 100 milliseconds. Furthermore, TCP will not allow infinite number of retransmissions. Hence, if TCP retransmission succeeds, after Nm attempts (without loss of generality, we assume Nm = 10) for example, the average delay to transmit a TCP packet is

T'+RTO1+RTO2+...+RTOm=T'+(2Nm+1-2) 100

where T' is the end-to-end propagation delay of the TCP packet. We shall establish the average delay for successful transmission of a TCP packet both with and without a radio link reliable transmission scheme (RLP).

For the purpose of our analysis, we stipulate in the following that the packet loss rate is q < 0.5. Recall that D(100 milliseconds) and τ(20 milliseconds) are the end-to-end frame propagation delay over the radio channel and the interframe time, respectively.

7.8.4 Average TCP Packet Transmission Delay

7.8.4.1 Average TCP Packet Transmission Delay without RLP

The TCP packet loss rate is q = 1 - (1 - p)k, where p is the probability of a frame being in error in the air link and k is the number of air-link frames contained in a TCP segment. The probability of successfully transmitting a TCP segment is

(1-q)+(1-q)q+...+(1-q)qNm-1=1-qNm

The average delay for successfully transmitting a TCP segment with no more than Nm retransmission trials is

where Nm denotes the maximum number of TCP retransmissions.

The TCP packets are going to carry the H.323 control messages in the payload. Hence, the total call setup delay is the cumulative addition of the delays for transmitting all the H.323 call setup messages and the RTCP:CNAME packet.

The total delay without RLP is

where TNi is the average delay given above for i-th TCP segment (carrying one of the H.323 control messages in the payload) and TC is the average delay to receive the first RTCP:CNAME packet after joining the session.

7.8.4.2 Average TCP Packet Transmission Delay with RLP

Thus, the average delay to transmit a TCP segment successfully is given by

where D' denotes the effective transport delay for TCP and is represented by

When the air-link FER is very high, too many RLP retransmissions may cause enough delay that TCP's retransmission timer always times out, thus, the average call setup delay with RLP is

where Ti = min{TRi, TNi}.

7.8.5 Average H.323 Call Setup Delay

We now compute the average call setup delay for a regular H.323 procedure and a fastConnect procedure. The models presented in the previous section imply that an average regular H.323 call setup delay increases exponentially as FER increases. Three major factors contribute to the delay — the number of message exchanges, size of message exchanges, and the number of TCP sessions set up. Reduction of any of these factors results in shorter call setup delay for any H.323 call. H.323 provides ways for addressing this or similar issues, including encapsulation of H.245 messages within H.225 messages (tunneling), and the fastConnect procedure. In order to conserve resources, either or both these mechanisms synchronize call signaling and control, and reduce call setup time. These mechanisms can be invoked by the H.323 calling endpoint. In this discussion, we will investigate the call setup delay incurred by the fastConnect procedure only.

H.323 endpoints may establish media channels in a call using either the regular procedures defined in Recommendation H.245 or the so-called fastConnect procedure. The fastConnect procedure allows the endpoints to establish a basic point-to-point call with as few as one round-trip message exchange, enabling immediate media stream delivery upon call connection.

Figures 7.9 and 7.10 compare the average call setup delays associated with a regular connect procedure and a fastConnect procedure for a 9.6- and a 19.2-kbps channel, respectively. Each procedure is further evaluated with and without support from RLP over the error-prone wireless channel. It can be observed that fastConnect with RLP support provides the minimum call setup delay. Furthermore, the call setup delay for the fastConnect procedure is consistently below 5 seconds for 9.6 kbps and 4 seconds for 19.2 kbps channels, if FER is less than 9%. This is close to the PSTN call setup time of 3 seconds.

click to expand
Figure 7.9: Call setup delay (9.6 kbps).

click to expand
Figure 7.10: Call setup delay (19.2 kbps).

7.8.6 Experimental Verification

Experiments for call setup delay at various FER rates between 1 and 10 percent over the wireless link emulator (WLE) were conducted using Microsoft NetMeeting. An end-to-end NetMeeting VoIP session from Endpoint A (Caller) to Endpoint B (Callee) over the WLE was created. NetMeeting 3.01 uses H.323v2 call signaling (Q.931/H.225/H.245 over TCP) to set up VoIP sessions and the default Microsoft codec G.723.1, 8-kHz mono, 6400 bps for audio compression. In these experiments, the call is considered successful only when the voice path is cut through (i.e., Endpoint B can hear the caller's voice). In addition, the maximum amount of time the called party waited for voice cut-through is 2 minutes, after which the call was marked as unsuccessful.

Two sets of experiments were conducted, one with the channel bandwidth fixed at 9.6 kbps and the others at 19.2 kbps. Thirty delay samples were collected at each FER with RLP and without RLP. Then, the sample mean was computed (see Figures 7.11 and 7.12). The success rate at each FER is shown in Table 7.3.

Table 7.3: Success Rate with NetMeeting

Call Setup Success Rate (percent)

FER (percent)

9.6 kbps (w/RLP)

19.2 kbps (w/RLP)

9.6 kbps (w/o RLP)

19.2 kbps (w/o RLP)

1

100

100

100

100

2

100

100

93

100

3

100

100

83

93

4

100

100

47

93

5

100

100

30

87

8

100

100

0

40

10

100

100

0

23

click to expand
Figure 7.11: Comparison with NetMeeting results (9.6 kbps).

click to expand
Figure 7.12: Comparison with NetMeeting results (19.2 kbps).

With RLP turned on, the result of the call setup success for both 9.6 and 19.2 kbps is perfect, at 100 percent success. With RLP turned off, at 1 percent air-link FER for 9.6 kbps and 1 to 2 percent air-link FER for 19.2 kbps, the call setup success rate is 100 percent. However, as the air-link FER rate increases, the average call setup delay increases (Figures 7.11 and 7.12) and the success rate declined (Table 7.3).

A fast call set-up time is considered a significant step toward providing QoS. Previous sections of this chapter illustrate that it is advantageous to transmit H.323 call setup messages and RTCP packets over air link with RLP, especially for VoIP clients that require exchange of several signaling and control messages before connection. For instance, the call setup procedure for H.323 involves exchange of H.225 and H.245 messages. Hence, the total delay to replay media is the sum of delays experienced by each of the messages. Therefore, the usage of RLP with either the regular or fastConnect call setup procedure enhances services without significantly sacrificing the limited bandwidth.

[30]Bao, G., Performance evaluation of TCP/RLP protocol stack over CDMA wireless link, Wireless Networks, 3 (2), 229–237, 1996.

[31]Sen, S.K. et al., A call admission control scheme for TCP/IP based CDMA voice/data network, ACM/IEEE International Conference on Mobile Computing and Networking, Oct. 1998, Dallas, pp. 276–283.

[32]Das, S.K. et al., Performance Optimization of VoIP Calls over Wireless Links Using H.323 Protocol, IEEE Infocom, June 2002.

[33]Das, S.K. et al., Performance optimization of VoIP calls over wireless links using H.323 Protocol, IEEE Trans. Computers, Special issue on Wireless Internet, Lin, Y.B. and Tseng, Y.-C., Guest Eds., submitted, 2002.

[34]Postel, J., Transmission Control Protocol, RFC 793, IETF, Sept. 1981.




Wireless Internet Handbook. Technologies, Standards and Applications
Wireless Internet Handbook: Technologies, Standards, and Applications (Internet and Communications)
ISBN: 0849315026
EAN: 2147483647
Year: 2003
Pages: 239

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net