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@PACKETIZER.COM] Sent: Saturday, December 09, 2000 12:06 AM To: ITU-SG16@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
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@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@PACKETIZER.COM] Sent: Saturday, December 09, 2000 12:06 AM To: ITU-SG16@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
Paul, I think we should define and use something like NULL CallID with all zeros. - Logan "Paul E. Jones" wrote:
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@mailbag.cps.intel.com Sent: Sunday, December 10, 2000 8:23 AM Subject: RE: Corrections to H.225.0v4 and H.323v4 Hi PaulEverything 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 requiredSasha -----Original Message----- From: Paul E. Jones [mailto:paulej@PACKETIZER.COM] Sent: Saturday, December 09, 2000 12:06 AM To: ITU-SG16@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
participants (3)
-
Logan Modahala -
Paul E. Jones -
Sasha Ruditsky