Corrections to H.225.0v4 and H.323v4

Sasha Ruditsky sasha at tlv.radvision.com
Mon Dec 11 00:41:15 EST 2000


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  <mailto:sasha at tlv.radvision.com> Ruditsky 
To: Paul E. Jones <mailto:paulej at PACKETIZER.COM>  
Cc: ITU-SG16 at mailbag.cps.intel.com <mailto: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/e40dbed1/attachment-0001.htm>


More information about the sg16-avd mailing list