On TD26 - Fast TCS and M/S negotiation in H.323v4

Paul E. Jones paulej at PACKETIZER.COM
Wed Jun 7 04:55:22 EDT 2000


I completely agree that we could probably solve a number (or all of these)
issues with the empty fastStart.  However, we have an issue: the
Implementers Guide for v3 now has a "fast connect refused" field (I forget
the exact field name).

Somebody proposed this as a mechanism, but it was rejected-- why I cannot
recall now.  I am recalling less and less and this morning wears on...


----- Original Message -----
From: "Paul Long" <Plong at SMITHMICRO.COM>
To: <ITU-SG16 at mailbag.cps.intel.com>
Sent: Wednesday, June 07, 2000 3:51 AM
Subject: Re: On TD26 - Fast TCS and M/S negotiation in H.323v4

> Paul,
> An EP that thinks that Alerting-without-fastStart indicates FC has been
> rejected is clearly making a false assumption.
> You know, if EPs would just start using an empty fastStart component in
> responses up to Connect to indicate rejection of FC, we'd solve this
> once and for all. No more waiting until Connect to determine if FC is
> supported. No more worrying about terminating FC by using H.245. It is
> already inherent in H.323 that an empty fastStart essentially indicates
> rejection of FC, so we just need to add words to v4 and the v3IG
> an EP to encode an empty fastStart if it doesn't support FC (or knows that
> it will eventually reject FC) instead of waiting until Connect to not
> fastStart.
> Paul Long
> Smith Micro Software, Inc.
> "Primum non nocere"
> -----Original Message-----
> From: Paul E. Jones [mailto:paulej at PACKETIZER.COM]
> Sent: Wednesday, June 07, 2000 1:44 AM
> Subject: Re: On TD26 - Fast TCS and M/S negotiation in H.323v4
> Bob,
> That text in section 8.2.1 has been removed via the Implementers Guide.
> There were a few issues with the text as it was, with a "race condition"
> being the most notable.
> If an aggressive endpoint sends a SETUP w/ fastStart and the other end
> returns Alerting without fastStart, the calling endpoint may assume that
> FC
> was rejected, so it sends a Facility with H.245 messages.  Then (perhaps
> at
> the same time), the called endpoint returns CONNECT with fastStart...
> now,
> what state are things in?  The caller thought that it terminated FC and
> the
> called party thinks that FC was accepted.
> One could say "the caller should then recognize that FC was indeed
> accepted", but it defeats the purpose of "terminating FC".  The reason
> for
> that text was so that the calling EP could do its best to try to get the
> H.245 tunnel up and channels open before CONNECT-- we could get into a
> terrible mess.
> Now, there could be work-arounds to this issue, but I believe that the
> procedural explanation to work-around the race condition may be far
> worse.
> However, I am not opposed to a work-around.  Apparently, the removal of
> that
> text has caused some confusion, so it may be worth reinstating that text
> and
> defining some general guidelines.
> However, we need to think through this carefully.  Contributions are
> definitely solicited :-)  We could leave the text as it is in the IG
> (which
> I believe fixes the issues) or we could reinstate the text and provide
> some
> guiding text (which may reduce incompatibilities with V2 equipment).
> Paul
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> For help on this mail list, send "HELP ITU-SG16" in a message to
> listserv at mailbag.intel.com

For help on this mail list, send "HELP ITU-SG16" in a message to
listserv at mailbag.intel.com

More information about the sg16-avd mailing list