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

[Paul E. Jones]

RE: On TD26 - Fast TCS and M/S negotiation in H.323v4Francois,

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 
  > 
  > ----- Original Message ----- 
  > From: "Pete Cordell" <pete at TECH-KNOW-WARE.COM> 
  > To: <ITU-SG16 at mailbag.cps.intel.com> 
  > Sent: Saturday, May 20, 2000 1:57 PM 
  > Subject: On TD26 - Fast TCS and M/S negotiation in H.323v4 
  > 
  > 
  > > I note that TD-26 has been accepted to show how TCS can be 
  > conveyed in 
  > > parallel with fast start. 
  > > 
  > > However, the example shows the use of call proceeding for 
  > receiving TCS 
  > back 
  > > from the remote endpoint.  This is not typically an 
  > end-to-end message, 
  > and 
  > > therefore how the procedure works with the gatekeeper 
  > routed model needs 
  > to 
  > > be addressed. 
  > > 
  > > Possible solutions are: 
  > > 
  > > 1. Refer to the new text that says it is the responsibility of the 
  > > gatekeeper to forward any tunnelled message for which none 
  > is available 
  > > using FACILITY.  (There might be some objection from some to using a 
  > > facility message this early in the call setup process though.) 
  > > 
  > > 2. Restrict the tunnelling (and probably the fast start 
  > info) to Alerting, 
  > > Connect and Facility, which generally are end-to-end.  I 
  > believe this is 
  > > compatible with the latest procedures for deciding when 
  > fast start has 
  > been 
  > > ignored. 
  > > 
  > > Which ever option is chosen, it would also be nice to have 
  > a picture for 
  > it 
  > > also! 
  > > 
  > > Pete 
  > > 
  > > ============================================= 
  > > Pete Cordell 
  > > pete at tech-know-ware.com 
  > > ============================================= 
  > > 
  > > 
  > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 
  > > For help on this mail list, send "HELP ITU-SG16" in a message to 
  > > listserv at mailbag.intel.com 
  > > 
  > 
  > 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.packetizer.com/pipermail/sg16-avd/attachments/20000530/c81ca4f0/attachment-0004.html>