The output of debug h.323 all is as follows:
FS machine - S:FS_S_INIT E:FS_E_SETUP_NO_FS A:FS_A_NO_FAST_START
## 2011-04-16 21:08:31 : FS machine - state change: FS_S_INIT -->FS_S_DECLINED
## 2011-04-16 21:08:31 : FS machine - media action = MEDIA_NO_ACTION
## 2011-04-16 21:08:31 : H.323 HA: building sync cookie
## 2011-04-16 21:08:31 : H.323 HA: H323_HA_TYPE_Q931_FAST_START
## 2011-04-16 21:08:31 : H.323 HA active sync successful: context id 127 fast_start
## 2011-04-16 21:08:31 : H.323 HA active sync successful: context id 127 q931_tpkt
With the standard H.245 negotiation, the two endpoints need three round-trips, before they agree on the parameters of the audio/video channels:
In certain situations and especially with high-latency network links, this can last for too long and users will notice the delay. To overcome this, the Fast Connect procedure was designed (also known as Fast Start). The endpoint will prepare several variants of the H.245 requestopenLogicalChannel, based on how many codecs it supports. After that, the endpoint encodes each variant of the message to the binary form and the resulting array of binary strings is inserted into a H.225.0/Q.931 message (usually the Setup message).
The called party will pick one of the variants and confirm it in the next H.225.0/Q.931 message, together with its own list of logical channel variants. The rest of the H.245 negotiation will be performed the standard way. Using Fast Connect, the parameters of logical channels (codecs, IP addresses, and ports) are negotiated early in the message exchange; before the called user accepts the call.
2020-11-11: Article archived since it is deemed relevant; article accurate
Note: Replaced words that failed to represent the inclusion and diversity Juniper values; in this case changed master to primary and slave to backup