fastStart element in all Q.931 messages up to and including C onnect

Paul E. Jones paulej at PACKETIZER.COM
Tue Oct 31 23:27:35 EST 2000


RE: fastStart element in all Q.931 messages up to and including ConnectFrancois,

Noted... I'll add that to my list of corrections for H.323v4 unless somebody screams loudly.  This should also be inserted into the Implementers Guide, too, I suppose.

Paul

  ----- Original Message ----- 
  From: Francois Audet 
  To: h323implementors 
  Sent: Tuesday, October 31, 2000 1:32 PM
  Subject: RE: fastStart element in all Q.931 messages up to and including C onnect


  Change the should to a shall then:
    The called endpoint accepts a proposed channel by returning the corresponding OpenLogicalChannel structure in a Q.931 message sent in response to Setup, up to and including Connect. <NEW>A called endpoint may choose to repeat the exact same fastStart element in all subsequent message up to and including Connect. Calling endpoints shall react to the first fastStart element received in a response message to the Setup message and ignore any eventual subsequent fastStart elements.
  If somebody manages to get it wrong after that, they deserve to be taken out of business. 

  I completely disagree with your assertion that we must choose either one or many. Currently some implementations send one, others send many, and we don't see interoperability problems.

    -----Original Message-----
    From: Danail Kirov [mailto:DanailK at vertical.com]
    Sent: Tuesday, October 31, 2000 10:17 AM
    To: Audet, Francois [SC2:4K02:EXCH]; 'Paul E. Jones'; 'Anatoli Levine'; Paul Long
    Cc: h323implementors
    Subject: RE: fastStart element in all Q.931 messages up to and including C onnect


    It seems bullet-prone to me.

    If the called endpoint may choose to repeat the exact same fastStart element in all subsequent message up to and including Connect, then

    The calling endpoint may choose to expect the fastStart in Connect only. At the same time the called endpoint is not required to send fastStart in Connect and may choose not to send fastStart in Connect and as a result the calling endpoint may never get fastStart in Connect and fast connect may fail miserably.

     

    Isn't it clear that those are two mutually exclusive choices?

      1.. The called endpoint is required to include the fastStart element in only one Q.931 message. 
      2.. The called endpoint is required to repeat the exact same fastStart element in all subsequent message up to and including Connect. 
     

    There is no middle ground and no mix and matches are allowed, if we want to have bulletproof fast connect procedure. Any correction in the standard must make it clear and definite that it is either choice 1, or choice 2, but not both at the same time.

     

     

    Danail Kirov

     

     

    -----Original Message-----
    From: Francois Audet [mailto:audet at nortelnetworks.com]
    Sent: Tuesday, October 31, 2000 8:47 AM
    To: 'Paul E. Jones'; 'Anatoli Levine'; Paul Long
    Cc: h323implementors
    Subject: RE: fastStart element in all Q.931 messages up to and including C onnect

     

    I have not problem with your proposed addition.

     

    It seems bullet-proof to me.

    -----Original Message-----
    From: Paul E. Jones [mailto:paulej at packetizer.com]
    Sent: Monday, October 30, 2000 10:34 PM
    To: Audet, Francois [SC2:4K02:EXCH]; 'Anatoli Levine'; Paul Long
    Cc: h323implementors
    Subject: Re: fastStart element in all Q.931 messages up to and including C onnect

    Francois,

     

    You proposed the following textual changes (see enclosed in <NEW></NEW>):

     


----------------------------------------------------------------------------

    The called endpoint accepts a proposed channel by returning the corresponding OpenLogicalChannel structure in a Q.931 message sent in response to Setup, up to and including Connect. <NEW>A called endpoint may choose to repeat the exact same fastStart element in all subsequent message up to and including Connect. Calling endpoints should react to the first fastStart element received in a response message to the Setup message and ignore any eventual subsequent fastStart elements.</NEW>


----------------------------------------------------------------------------

     

    I don't have any problem inserting this text into H.323, but I do fear that people will rely on such repetitions and they may not happen.  Indeed, I would state that an H.323 entity shall not expect more than one response to Fast Connect.  I don't disagree with this text, because I always encourage developers to be very tolerant of "noise" on the wire-- and I consider repetitive data like this to be "noise". :-)

     

    You call these religious arguments... they might be, but we really need closure on this issue.  Unlike the MGCP vs H.248 debates, the world can live with two media gateway control protocols.  However, I don't want to see vendors split on implementation issues relating to H.323: that's not good for anybody at all.  If we don't come to an agreement on it here and now, you know that we'll be correcting it as a customer fumes over interoperability issues later on.  I'd much rather see us agree to something than to bring grief upon our customers.

     

    Can everyone live with the above textual changes?  Do we need more?  Is it well understood that there may be one and only one response containing fastStart?

     

    Paul

     

    ----- Original Message ----- 


    From: Francois Audet 

    To: 'Anatoli Levine' 

    Cc: h323implementors at imtc.org 

    Sent: Monday, October 30, 2000 5:51 PM

    Subject: RE: fastStart element in all Q.931 messages up to and including C onnect

     

    > I disagree with your claim that the stack which sends 
    > multiple Fast Start 
    > responses (as long as they are identical) is not compliant 
    > with the standard - 
    > none of the citations you used claim that ONLY ONE Q.931 
    > message can carry Fast 
    > Start information. I believe that the wording should be 
    > changed to explicitly 
    > allow Fast Start elements to be sent in every Q.931 message 
    > up to Connect as 
    > long as information in those messages stays the same. 

    Correct. That was my proposal too. I didn't keep the exact wording I had. 
    Paul Jones probably still has it. 

    These religious arguments over "one" or "many" are getting nowhere. It 
    seems that sending one and sending many are a fait accomplit. Not much 
    we can do about it except tell the implementor about it. 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.packetizer.com/pipermail/sg16-avd/attachments/20001031/a87afd90/attachment-0001.htm>


More information about the sg16-avd mailing list