Corrections to H.225.0v4 and H.323v4

[Paul E. Jones]

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/20001210/3790a291/attachment-0001.htm>