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

From: Paul E. Jones

To: ITU-SG16@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@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@packetizer.com]
Sent: Sunday, December 10, 2000 7:57 PM
To: Sasha Ruditsky
Cc: ITU-SG16@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@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