Corrections to H.225.0v4 and H.323v4

Pete Cordell pete at TECH-KNOW-WARE.COM
Mon Dec 11 05:04:54 EST 2000


Paul,

The GEF stuff looks good to me.

Pete.

=============================================
Pete Cordell
Tech-Know-Ware
pete at tech-know-ware.com
+44 1473 635863
=============================================

  ----- Original Message ----- 
  From: Paul E. Jones 
  To: ITU-SG16 at mailbag.cps.intel.com 
  Sent: 11 December 2000 06:11
  Subject: Re: Corrections to H.225.0v4 and H.323v4


  Sasha and others,
   
  I have modified the document per these discussions.  The text now states that the guid field shall be set to all zeros.  I removed the comment added in the ASN.1 relating to the use of empty.
   
  I have also modified the URQ text.  The text that was there was somewhat redundant with text two paragraphs above in H.323 version 4.  The paragraphs above describe the actions of the endpoint and the two paragraphs shown in the document describe the actions of the Gatekeeper.  Please review the modified text here and in context with the H.323 version 4 document.
   
  Thanks,
  Paul
   
    ----- Original Message ----- 
    From: Sasha Ruditsky 
    To: Paul E. Jones 
    Cc: ITU-SG16 at mailbag.cps.intel.com 
    Sent: Monday, December 11, 2000 12:41 AM
    Subject: RE: Corrections to H.225.0v4 and H.323v4


    Hi Paul 
     
    I think that NULL callIdentifier is better solution.
     
    I believe that there are and probably there will be additional cases that require sending of Q.931 message related to the whole multiplex.
    One possible example is STATUS messages in Annex R.
     
    So, probably in the specific case of the FACILITY message the security is not significantly compromised, but I think we definitely cannot say the same generally about all the cases when the Q.931 message relates to the multiplex. 
     
    So I believe that definition of specific callIdentifier for such cases is required.
     
     
    Sasha
      -----Original Message-----
      From: Paul E. Jones [mailto:paulej at packetizer.com]
      Sent: Sunday, December 10, 2000 7:57 PM
      To: Sasha Ruditsky
      Cc: ITU-SG16 at mailbag.cps.intel.com
      Subject: Re: Corrections to H.225.0v4 and H.323v4


      Sasha,
       
      The problem with that is that the Facility message contains a call Identifier.  The only place this is currently used is in setting the multipleCalls flag.  I don't think that's an issue, even with security compromised.  We have to have something that makes the text in H.323v4 work-- right now there's no way to send a Facility message to change the multipleCalls flag.
       
      As an alternative, we could specify that the CallIdentifier will contain 16 zeros when sending non-call-related messages, as opposed to using the empty choice.
       
      What's the group's preference?
       
      Paul
       
        ----- Original Message ----- 
        From: Sasha Ruditsky 
        To: Paul E. Jones 
        Cc: ITU-SG16 at mailbag.cps.intel.com 
        Sent: Sunday, December 10, 2000 8:23 AM
        Subject: RE: Corrections to H.225.0v4 and H.323v4


        Hi Paul
         
        Everything looks OK with me except the very 1st change.
        Specifically the empty h323-message-body element for non call related Q.931 messages.
        The empty h323-message-body does not allow to add tokens to the FACILITY message so it cannot be authenticated and its integrity cannot be checked.
        My proposal is to change wording here to allow non empty h323-message-body in the case security is required
         
         
        Sasha 
         
         
         
         
         -----Original Message-----
        From: Paul E. Jones [mailto:paulej at PACKETIZER.COM]
        Sent: Saturday, December 09, 2000 12:06 AM
        To: ITU-SG16 at mailbag.cps.intel.com
        Subject: Corrections to H.225.0v4 and H.323v4
        Importance: High


          H.323 Experts,
           
          I have attached a document that contains the complete list of corrections for H.225.0v4 and H.323v4, with differences against the decided text, that we have discussed on the mailing list this past week.
           
          I would like all interested parties to review these changes.
           
          I am open to changing the wording, but I would like to get consensus on making these changes.  I have asked the TSB to see if we can make these corrections prior to the publication of the documents.  If so, I want to have the support of everyone to make these corrections.  I don't believe that any of these issues should be contentious, but without these corrections, I'm afraid that many more questions and interoperability problems will arise.
           
          If it turns out that we cannot update the approved text before publication, I plan to submit this document (or a modified version with comments I receive from you) to the next meeting in March.  Personally, I'd rather correct the Recommendation before publication, rather than adding this to the Implementers Guide.
           
          Thanks,
          Paul
           
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.packetizer.com/pipermail/sg16-avd/attachments/20001211/b256624f/attachment-0004.html>


More information about the sg16-avd mailing list