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

Pete Cordell pete at TECH-KNOW-WARE.COM
Tue May 30 14:40:17 EDT 2000


RE: On TD26 - Fast TCS and M/S negotiation in H.323v4Hi Paul, Francois, and
others,

I think it is important that we make it work, but as you say, it has to be
reliable and any burden of insuring backwards compatibility has to be placed
on the newer EP.  In this case it is primarily an issue for the calling EP.

As I see it, (and I'm sure you'll correct me if I'm not seeing it right!)
when there is H.245 in the SETUP message, then the called endpoint can
either ignore the H.245, or accept it.  (It could clear the call, but I'll
ignore that one for the time being.)  There is also the case where it
decides that the H.245 takes precedence over fast start.

Knowing whether fast start has been accepted is fairly straight forward.

I think the called endpoint has a very good idea of what decision was taken
with regard to the H.245 based on the reply from the called endpoint.

- If the reply message in which the fast start information is contained
contains H.245, then it can assume that the called EP accepted the H.245.
The H.245 state about which channels are open will be updated according to
the fast start parameters.

- If the reply message in which the fast start information is contained
contains no H.245, then it has probably ignored the H.245.

--- If H.245 tunneling is enabled, but the calling endpoint believes that
the called endpoint ignored its H.245 in the SETUP message, then it can
re-transmit its capability set when it becomes OK to do so under the normal
fast start/H.245 rules.  (It should probably modify the sequence number
before doing this.)

--- In the case where the called EP actually did accept the H.245 but did
not reply as expected, the called EP will receive a second capability set.
However, endpoints should be able to handle this as this is a standard H.245
procedure.

So as long as V4 endpoints use this kind of logic then I think it is safe
for them to combine both H.245 and fast start.

Perhaps we should document the above more formally for V4, and maybe say
that if a V4 EP wants to accept both fast start and H.245 Cap tunnelling at
the same time then it SHALL put the fast start and H.245 in the same
message.

Does this sound in any way reasonable?

Pete.

=============================================
Pete Cordell
pete at tech-know-ware.com
=============================================

----- Original Message -----
From: Paul E. Jones
To: Francois Audet ; Mailing list for parties associated with ITU-T Study
Group 16 ; pete
Cc: Alexander (Sasha) Ruditsky ; Dale Skran
Sent: 30 May 2000 08:20
Subject: Re: On TD26 - Fast TCS and M/S negotiation in H.323v4


Francois,

But the possibility exists that a V2 device may accept both, reject one or
the other, or reject both since a SETUP containing fastStart and tunneled
H.245 is "illegal".  Heck, a "strict" endpoint may even drop the call, but I
suspect that nobody would go that far.

If fastStart was accepted and the remote end returns the tunneling flag set
to TRUE, how do you know if it did or did not process the H.245 message in
the SETUP?  I'm not convinced that this procedure is going to make everybody
happy.  (Same could be said if fastStart is not accepted, I suppose.)

My concern is that this issue is potentially damaging to some
implementations.  If all of the vendors have no problem with this change,
then I can live with it.  Cisco has no objection, but I would like to
solicit the input of others-- changes like this, even as good as they are,
could cause serious problems.

It appears that we've already made a similar "mistake" by allowing H.245
procedures to be done in parallel to fastConnect by removing the clause that
says that if we start H.245, fast connect is terminated.  That text was
removed, because there was a race condition that could occur, which could
result in interoperability problems.  The right solution probably should
have been to document the race condition and tell people "don't do that".
However, we made the change and now some manufacturers have serious backward
compatibility problems.  I don't want to make the same mistake again.

Comments?

Paul

----- Original Message -----
From: Francois Audet
To: 'Paul E. Jones' ; Mailing list for parties associated with ITU-T Study
Group 16 ; pete
Cc: Alexander (Sasha) Ruditsky ; Dale Skran
Sent: Monday, May 29, 2000 11:00 PM
Subject: RE: On TD26 - Fast TCS and M/S negotiation in H.323v4


Yes, a few comments:
1 It seems that all current implementations that we could think of
  would simply ignore the tunnelling information if the fastStart
  element is present. This means, that there would be no
  interoperability problems. Fast start would be sucessfull, but not
  tunnelling, which would mean that tunnelling would have to happen
  after the SETUP message, as per H.323v2 and v3.
2 There is a small possibility that an implementation would acutally
  give priority to the tunnelling information instead of the fastStart
  element (v2 and v3 don't say what would happen if they are present, they
  just say not to do it). In that particular case, the fastStart would fail
  but the tunnelling would be successful. So the worst case scenario is that
  fastStart fails, but "fast tunnelling" is successful. This doesn't seem to
  me to be a real interoperability problem. In any case, it seems that case
  1 is much more likely.


> -----Original Message-----
> From: Paul E. Jones [mailto:paulej at packetizer.com]
> Sent: Monday, May 29, 2000 7:46 PM
> To: Mailing list for parties associated with ITU-T Study
> Group 16; pete
> Cc: Audet, Francois [SC9:4K02:EXCH]; Alexander (Sasha) Ruditsky; Dale
> Skran
> Subject: Re: On TD26 - Fast TCS and M/S negotiation in H.323v4
>
>
> Pete, Sasha, Francois, Dale, et al,
>
> I have concerns about this document that differ from Pete's.
> However, since
> discussion on this document has started, I thought I might as
> well express
> my concerns now while the material is fresh on people's minds.
>
> The issue has to do with the very first sentence of the
> proposal, which says
> to strike "shall not" and replace it with "may".  So, V2
> devices shall not
> send a fastStart element and an H.245 message in SETUP, but
> V4 may.  This
> seems to be a serious backward compatibility issue.  If a V2
> device were to
> receive a SETUP containing fastStart and an encapsulated
> H.245 message, what
> would it do?  I believe the behavior is not defined.
>
> Would somebody like to comment?
>
> Paul
>
... cut ...

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
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