ITU Telecommunication Standardization Sector Document Q1-D11 (AVD-2738)
Study Group 16
Q.1/16 Rapporteur Meeting
Biel-Bienne, Switzerland 19-20 May 2005
Source * : |
RADVISION |
Title: |
Automatic Connect Negotiation |
Purpose: |
Proposal |
___________________
This proposal adds new functionality to H.324 allowing faster call setup times.
The main problem today with H.324 is the fact that call setup takes too long. Today, to open a call with an audio and a video channel, 10 or more H.245 messages need to be exchanged.
This requires 3-10 round trips and might even take more – due to more messages, channel conflicts or just noisy communication lines.
This proposal tries to reduce the time required during call setup or at later stages by reducing the number of round trips needed before starting to send media to 1/2 a round trip.
The proposal requires minor changes to H.324 Annex J and an addition of a new chapter or annex.
Annex J
ASN.1 OIDs defined in this Recommendation
Table J.1/H.324 – Summary of OIDs defined in H.324
OID |
Clause |
{ itu-t(0) recommendation(0) h(8) 324 generic-capabilities(1) SessionResetCapability(1) } |
7.7.1 |
{ itu-t(0) recommendation(0) h(8) 324 generic-capabilities(1) acnCapability(2) } |
TBD |
Table J.2/H.324 – SessionResetCapability Capability Identifier
Capability name |
SessionResetCapability |
Capability identifier type |
Standard |
Capability identifier value |
{ itu-t(0) recommendation(0) h(8) 324 generic-capabilities(1) SessionResetCapability(1) } |
maxBitRate |
This parameter is not used. |
Collapsing |
This field shall not be used and shall be ignored by receivers. |
nonCollapsing |
This field shall not be used and shall be ignored by receivers. |
nonCollapsingRaw |
This field shall not be used and shall be ignored by receivers. |
Transport |
This field shall not be used and shall be ignored by receivers. |
Automatic Connect Negotiation
Automatic Connect Negotiation reduces the number of round trips required during call setup or when there is a need to reconfigure channels from around 3-5 round trips to 1/2 a round trip before starting to send media on the channels.
ACN Automatic Connect Negotiation signaling
Terminals supporting the ACN procedure shall signal it in any TCS message they send by adding the acnCapability defined in Annex J.
If both terminals support ACN, they shall assume that the ACN procedure is used in that call.
By analyzing the local and the remote's TCS, along with the specific acnCapability parameters, both terminals shall decide on the most preferable channels to open, send the relevant OLC messages and start sending the media without waiting for any acknowledgement messages. The multiplexing entry table shall also be known in advance and shall contain a single entry for each channel opened.
An ACN enabled terminal shall indicate it in every TCS message sent by it.
Upon determination of the master (which occurs once the terminal has sent out its own MSD and received the remote terminal's MSD or MSD Ack message), an ACN enabled terminal shall decide on the most preferable channels to open if both terminals support ACN and shall send the relevant OLC messages. The terminal may start sending media without waiting for the acknowledgement messages of his TCS, MSD or OLC messages.
The moment a terminal using ACN in an ACN-enabled call knows who the master is and who the slave is of the call it can start sending media. For this to happen, both terminals must be able to receive media on channels that were not fully opened and both terminals should know the multiplexing entry table the other is using to multiplex its data.
Table 1 defines the capability identifier for the acnCapability Capabilitiy. Tables 2 to 3 define the associated capability parameters. All of the capability parameters are collapsing parameters.
Table 1: acnCapability Capability Identifier
Capability name: |
acnCapability |
Capability class: |
Control capability. |
Capability identifier type: |
Standard. |
Capability identifier value: |
{ itu-t(0) recommendation(0) h(8) 324 generic-capabilities(1) acnCapability(2) } |
maxBitRate: |
Shall not be included |
NonCollapsingRaw: |
This field shall not be included |
transport: |
This field shall not be included |
Table 2: acnCapability Parameter - masterBidirectionalVideo
Parameter name: |
masterBidirectionalVideo |
Parameter description: |
This is a collapsing GenericParameter. If the terminal indicating this parameter's value as 1 will be selected as the master of the call, it shall open a bidirectional video channel. In this case, the slave shall not open a video channel using the ACN procedure. If the master of the call indicates this parameter's value as 1, then the slave should open its own unidirectional channel. |
Parameter identifier value: |
1 |
Parameter status: |
Shall be present once for capability exchange |
Parameter type: |
unsignedMax, with the value 0 or 1 |
Supersedes: |
- |
Table 3: acnCapability Parameter - mediaBuffering
Parameter name: |
mediaBuffering |
Parameter description: |
This is a collapsing GenericParameter. A terminal indicating this parameter's value as 1 is able to buffer the incoming media send before the relevant OLC message is received from the remote terminal, allowing faster call setup. |
Parameter identifier value: |
2 |
Parameter status: |
Shall be present once for capability exchange |
Parameter type: |
unsignedMin, with the value 0 or 1 |
Supersedes: |
- |
When channels need to be opened by both terminals, each terminal shall look at the local capabilities, the remote terminal's capability and the master indication.
Each terminal shall decide on the most suitable channels to open. The slave terminal shall not open any bidirectional channel using ACN, and shall not open a bidirectional video channel using ACN if the master has indicated it is going to open a bidirectional video channel (using the masterBidirectionalVideo parameter defined in Table 2). The master terminal shall open a bidirectional video channel using ACN if it indicated it using the masterBidirectionalVideo parameter, and shall open a unidirectional video channel using ACN otherwise. The audio channel shall be opened as unidirectional by both terminals.
The terminal can start sending media in parallel to sending its OLC message without waiting for any acknowledgement from the remote terminal. The receiver terminal shall be able to ignore or buffer incoming data before receiving any OLC message.
If no video or no audio channel exists, and the relevant entry in the multiplexing table is not in use (i.e – is not defined or defined for a closed logical channel) this mechanism can be used to open such a channel: An OLC can be sent out and media can be sent immediately, without waiting for the channel's acknowledgement.
Each terminal shall be able to send and receive media for its primary audio and primary video channels before sending or receiving any MultiplexEntrySend message by using the following default table:
For the primary audio channel, entry 1 shall be used with a repeatCount of untilClosingFlag.
For the primary video channel, entry 2 shall be used with a repeatCount of untilClosingFlag.
The multiplexing entry table is predefined and contains a single entry for the first audio and video channels opened. The multiplexing entry table may be reconfigured by sending a MultiplexEntrySendMessage.
The terminal receiving an OLC using ACN may reject the proposed channel and ignore any media received for this channel and shall not buffer any incoming media for this media type until a new OLC is received for it.
In this case, the terminal receiving an OpenLogicalChannelReject should try to reopen a more suitable channel using the regular OLC procedure or it can try to use ACN again to open this channel, but shall assume the remote terminal is not buffering media for this channel until it receives an acknowledgement that the remote terminal received its new OLC message.
We propose adding this as a new Annex to H.324 to allow faster call setup procedures.
This procedure is better than current techniques and other pending proposals since it requires only 1/2 a round trip to start sending media, while requiring very little negotiation and signaling.
___________________