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

Paul E. Jones paulej at PACKETIZER.COM
Wed May 31 01:29:20 EDT 2000


Pete,

If we could follow such logic, I would agree that this procedure would be
worth perusing.  Unfortunately, the inclusion of fastStart and tunneled
H.245 messages in the SETUP message is not defined.  There is no way to
predict how a V2 device will behave when receiving these messages.  I like
the idea, but I'm afraid we will compromise backward compatibility by
including it.

Let's assume a V2 device does *not* recognize the tunneled H.245 in SETUP
(ignores it), but accepts the Fast Connect proposal.  Assume, also, that in
the CONNECT message, the endpoint includes the fastStart element *and* a
tunneled TCS message.  What could the calling endpoint *safely* assume?

Assume that CONNECT was the first message received following the SETUP if
that helps complicate matters further for you. :-)

I just need further convincing.

Paul

----- Original Message -----
From: "Pete Cordell" <pete at TECH-KNOW-WARE.COM>
To: <ITU-SG16 at mailbag.cps.intel.com>
Sent: Tuesday, May 30, 2000 2:40 PM
Subject: Re: On TD26 - Fast TCS and M/S negotiation in H.323v4


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

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