Subject: Re: Zero not allowed

From: Christian Groves <[email-masked]>
Date: Thu, 1 Feb 2001 13:32:33 +1100

G'Day Troy,

I didn't say that every element is is valid for all three. I said Annex
C is appropriate for all 3. As you point out, something that's used for
LocalControl probably isn't valid for Local/Remote.

Annex C.11 SDP equivalents could be used in Local Control if you want.
As defined in ABNF H.248 Annex B, SDP cannot be used in Local Control
:).

Annex C is there to be used how you want its a bucket the same way SDP
is. To make any sense of it I maintain that you need extra documentation
ie. profiles, capability sets Q.1950 to figure out the appropriate
information elements to drive things for certain
procedures/functionality. Otherwise H.248, annex a, b, c, packages etc
is a mess and interoperability for real applications is a mess.

Cheers, Christian

Troy Cauble wrote:
>
> Christian,
>
> Are you saying that every Annex C property is appropriate for
> all three of the Local, Remote, and LocalControl descriptors?
>
> I suspect they're not and that each Annex C property should
> identify which descriptors they're appropriate for.  (Package
> properties do this.)
>
> What about Annex C.11, the SDP equivalents?  Are they appropriate
> for local control or not?  You say "yes" and "no" below :)
>
> -troy
>
> Christian Groves wrote:
> >
> > Just to clarify Tom, both SDP and Annex C ARE within local and remote.
> > Annex C is also for Local Control. SDP is not.
> >
> > Christian
> >
> > Tom Taylor wrote:
> > >
> > > Just as a historical sidelight: originally we were going to allow both SDP and Annex C encodings within Local and Remote, but
> > > the use of Annex C got restricted to binary encoding at the Redbank meeting.  Can x00 not appear within an MTPAddress, in
> > > which case the exclusion is unwarranted?
> > >
> > > I'm also concerned about the assumption of null-terminated strings.  That assumption is C/C++ specific and should not be
> > > refelcted in a general protocol.  Not that we should deliberately make it hard for C programmers, but we shouldn't do anything
> > > unnatural just to accommodate them.
> > >
> > > On Tue, 16 Jan 2001 11:26:03 -0500, Troy Cauble <[email-masked]> wrote:
> > >
> > > >Yes.  Please don't add the zero.
> > > >
> > > >SDP is limited to "the ISO 10646 character set in
> > > >UTF-8 encoding".
> > > >
> > > >Based on that the range of characters for "octetString"
> > > >should probably be narrowed, not widened.
> > > >
> > > >I think the problem is that the name "octetString" is
> > > >misleading and implies that a full range of octet values
> > > >needs to be supported.
> > > >
> > > >I'm especially worried about adding '0' because that
> > > >terminates a character string and may cause implementation
> > > >issues.
> > > >
> > > >-troy
> > > >
> > > >
> > > >"Rosen, Brian" wrote:
> > > >>
> > > >> Well, maybe something along the lines of
> > > >> "The octet zero is not among the permitted characters in octet string,
> > > >> which is used in the ABNF for local and remote descriptors.  As the current
> > > >> definition of these descriptors is limited to SDP, and a zero octet would
> > > >> not
> > > >> be a legal character in SDP, this is not a concern."
> > > >>
> > > >> > -----Original Message-----
> > > >> > From: Christian Groves [mailto:[email-masked]]
> > > >> > Sent: Monday, January 15, 2001 12:45 AM
> > > >> > To: [email-masked]
> > > >> > Subject: Re: Zero not allowed
> > > >> >
> > > >> >
> > > >> > G'Day Brian and Paul,
> > > >> >
> > > >> > It doesn't sound like people care very much for this change?
> > > >> > Do you want
> > > >> > something added to the implementors' guide.
> > > >> >
> > > >> > Cheers, Christian
> > > >> >
> > > >> > Paul Long wrote:
> > > >> > >
> > > >> > > Brian,
> > > >> > >
> > > >> > > The low end of the range of acceptable characters for octetString
> > > >> > > suspiciously starts with %01 rather than %00.
> > > >> > >
> > > >> > >    octetString          = *(nonEscapeChar)
> > > >> > >    nonEscapeChar        = ( "\}" / %x01-7C / %x7E-FF )
> > > >> > >
> > > >> > > Since octetString is only referenced in mtpAddress,
> > > >> > localDescriptor, and
> > > >> > > remoteDescriptor, maybe it doesn't matter if an octet of
> > > >> > zero is excluded. I
> > > >> > > was just wondering why it was left out. Sounds like there
> > > >> > was no reason.
> > > >> > >
> > > >> > > Paul
> > > >> > >
> > > >> > > -----Original Message-----
> > > >> > > From: Media Gateway Control (megaco)
> > > >> > > [mailto:[email-masked]]On Behalf Of
> > > >> > Rosen, Brian
> > > >> > > Sent: Friday, January 12, 2001 2:08 PM
> > > >> > > To: [email-masked]
> > > >> > > Subject: Re: Zero not allowed
> > > >> > >
> > > >> > > I don't think we thought about it.
> > > >> > > For SDP, it doesn't matter.  Beyond that, who knows.
> > > >> > > I suppose it would be better if it allowed zero.
> > > >> > >
> > > >> > > Brian
> > > >> > >
> > > >> > > > -----Original Message-----
> > > >> > > > From: Paul Long [mailto:[email-masked]]
> > > >> > > > Sent: Sunday, December 31, 2000 12:30 PM
> > > >> > > > To: [email-masked]
> > > >> > > > Subject: Zero not allowed
> > > >> > > >
> > > >> > > >
> > > >> > > > I noticed that an octet of zero is not allowed in the ABNF
> > > >> > > > octetString. Was
> > > >> > > > this intentional?
> > > >> > > >
> > > >> > > > Paul Long
> > > >> > > > ipDialog, Inc.
> > > >> >

---

From: Troy Cauble <[email-masked]>
Date: Thu, 1 Feb 2001 10:11:42 -0500

> is a mess and interoperability for real applications is a mess.

That's fine.  I assume you guys on the standards committees
will have these profiles, etc. any day now :)

-troy

---

From: Hsien-Chuen Yu <[email-masked]>
Date: Thu, 1 Feb 2001 16:16:16 -0600

Christian,

I was reading the Draft Version 2 of Annex N - congestion
handling package. The procedure says this is to reduce
the processing load on the MG. However, I think there
are generally two types of load on an MG. The first type
is probably what you called the processing load, which is
the "calls per second" load. The second type is the
load determined by other MG resources (other than the
real-time), which can be translated into "number of
simultaneous connections". For various reasons, a MG can
go into an overload condition of either or both type. I
think it would be beneficial to separate these two types
of overload in the package, so that the MGC can take
appropriate actions based on the nature of overload.

Regards,

Jim Yu

---

From: Christian Groves <[email-masked]>
Date: Fri, 2 Feb 2001 16:19:09 +1100

G'Day Jim,

What actions were you thinking that the MGC could take based on the
different types of loads?

Cheers, Christian

---

From: Hsien-Chuen Yu <[email-masked]>
Date: Mon, 5 Feb 2001 12:03:27 -0600

Christian,

In general, the MGC would have some knowledge about the maximum
capacity a MG has, and would refrain from using that MG (reject
or redirect new calls) when the MG is at its capacity. This action
would be taken regardless whether the MG is real-time overloaded or
not. The type of congestion due to internal resource failure
(reduced MG capacity) is meant to convey such information to the
MGC.

Regards,

Jim

---

From: Christian Groves <[email-masked]>
Date: Wed, 7 Feb 2001 10:33:36 +1100

Hello Jim,

I believe that the current Annex N allows for this behaviour. The MG
tells the MGC when it is overloaded. The MGC can reject call, refrain
from using the MG etc... this behaviour depends on the application. Its
not specified in Annex N.

MG Capacity is one area that I'd like to stay out of. 0-100% is I think
the best way of describing it. Capacity is dynamic and can be specified
in many ways. We had alot of trouble coming up with any metric in SG16
for H323 GWs and GKs.

I think we should only have different congestion events if the behaviour
of the MGC will be very different depending on the event.

Cheers, Christian

---

From: Hsien-Chuen Yu <[email-masked]>
Date: Wed, 7 Feb 2001 09:00:18 -0600

Christian,

Consider the scenario where the MG capacity (~ maximum number
of connections it can support) is reduced by 20% due to some
hardware failure. Using the existing Annex N definition, I would
assume the MG will send MGCon with Reduction=20 at the time
the hardware failure is detected, and send MGCon with Reduction=0
when the failure is fixed. My question is during this period of
time, without knowing the nature of the congestion, the MGC will
likely to drop 20% of new calls all the time, even if the call load
is light and the number of connections in the MG is small. Is this
what we would expect?

Regards,

Jim