Corrections to H.225.0v4 and H.323v4

[Logan Modahala]

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 at 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 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/a88554d5/attachment-0001.htm>