Subject: RE: Network Package

From: "Rosen, Brian" <[email-masked]>
Date: Tue, 29 May 2001 17:38:12 -0400

> > If you implement any part of a package, you implement all of it.
> > If a package extends any part of a package, it extends all of it.
> 
> What do you mean by this statement?
> 
> Package A might have Signals and Events.
> Are you saying Package B can't extend A's Signals
> but not A's Events?  It can't extend the values
> for Signal A1, without extending the values for
> Event A7 ??
Well, not the way you wrote it, but probably what you meant.
If Package A defines Signal A1 and Event A7, and Package
B extends Package A, then Signal B/A1 and event B/A7 are
defined, and must be implemented.  You don't have to "extend"
event A7, but you do have to implement it.

Brian

---

From: "Blatherwick, Peter" <[email-masked]>
Date: Tue, 29 May 2001 21:19:40 -0400

See below, [PB] comments..  -- Peter

-----Original Message-----
From: Madhu Babu Brahmanapally [mailto:[email-masked]]
Sent: May 29, 2001 19:12
To: 'Rosen, Brian'; 'Chuong Nguyen'; [email-masked]
Subject: RE: Network Package

HI Brian/all,
 
In your example A/T1 and B/T1 actually mean to the MG for reporting of the same event(I.e T1). But I think generating two notifies for this purpose is unnecessary and doesn't carry any extra information. I think the reporting should be either A/T1 or B/T1 as both mean the same. If they mean the same why to provide redundant information to MGC??? 

[PB] No, if the MGC asks for both events A/T1 and B/T1, it should receive both when they occur (assuming both are exposed by the MG of course).  That's what the MGC asked for, and its in charge.   I agree this is redundant (actually likely the same physical event underlies both in general).  More complex to implement special case handling than to just do what was asked by the MGC.  

Lets say a event descriptor has Events=123{A/a1, A/a1} (grammar allows this and there is no statement restricting multiple occurrence of the same event) does this leads to reporting of two Notifies from the MG?????? IMHO reporting of single event is enough.  

[PB] This on is less clear, but I still believe MG should report both.  I see no harm, and likely more simplicity in MG design, to return both.  Again, if the MGC did not want both, it should not ask for both.   

Related query: Is it valid to have multiple occurrence of the same signal/ event or properties in any of the descriptors ????

[PB] As above, I see no reason why not.  Same logic applies.  (I have not double checked the syntax to verify this is actually allowed though...)

-Regards
Madhubabu

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On Behalf Of Rosen, Brian
Sent: Tuesday, May 29, 2001 5:47 PM
To: 'Chuong Nguyen'; [email-masked]
Subject: RE: Network Package

Well rtp/dur and nt/dur are "the same thing" in the sense that the mean the same
thing, but if you implement (expose) both packages, then they are "separate"
statistics.  Using Events is perhaps easier to understand.  Suppose Package A
implements event E1, and package B extends Package A, and a given implementation
exposes both A and B, such that an audit of termination T1 returns Packages{..A,B..}
 
You can say Add=T1{Events=123{B/E1}}
or you can say
Add=T1{Events=123{A/T1}}
or even
Add=T1{Events=123{A/T1,B/T1}}
 
In the latter, detection of the event would result in a notify of both.
 
Returning to statistics, the value would be the same, but they are separate
statistics.
 
Brian

-----Original Message-----
From: Chuong Nguyen [mailto:[email-masked]]
Sent: Tuesday, May 29, 2001 5:29 PM
To: [email-masked]
Subject: Re: Network Package

"Rosen, Brian" wrote: 

If you implement any part of a package, you implement all of it.If a package extends any part of a package, it extends all of it.

What is not required is that if you implement a package that extendsanother package that you have to "expose" the underlying package.This means that if you implement rtp you don't have to expose nt.If you list nt as one of the packages in an audit, then you have toimplement nt/dur.

<cnn>  I don't quite follow here. 
               You seem to imply that nt/dur and rtp/dur are 2 different things. 
               I thought both nt/dur and rtp/dur are the same thing w/the same value. 
              If MG exposed nt, what should it return for duration - nt/dur or rtp/dur? 

Do you know the intend of tdmc/os and tdmc/or? 
I thought the same as Madhubabu about how they are calculated. 

Brian 

-----Original Message----- 
From: Madhu Babu Brahmanapally [ mailto:[email-masked] <mailto:[email-masked]> ] 
Sent: Tuesday, May 29, 2001 5:15 PM 
To: 'Chuong Nguyen' 
Cc: [email-masked] 
Subject: RE: Network Package
Hi chuong/all,IMO if PackageB extends PackageA and if one of the statistic/property of Package A is not valid for termination realizing packageB then there is no reason why PackageB extends PackageA. Then PackageB shouldn't extend PackageA (just only to reuse few properties/statistics) but should define the same properties (Might be with different IDs) in packageB. I think the extension of packages is logical if the newly defined package can inherit "all" the properties already defined in the base package and also define new properties. In your example, I was in the impression that "OS" and "OR" can be calculated as "The number of octet sent or received is equal to the duration of the Termination, in seconds, multiplied by the sampling frequency,  8000 Hz.". (Of course this seems to be redundant info if the MGC is aware of the sampling frequency). Isn't this the intention?????-RegardsMadhubabu 

-----Original Message----- 
From: [email-masked] [ mailto:[email-masked] <mailto:[email-masked]> ]On Behalf Of Chuong Nguyen 
Sent: Tuesday, May 29, 2001 4:38 PM 
To: [email-masked] 
Subject: Network Package
Hi All 

Is it reasonable to assume that Network Package StatisticsID will never be used directly? 
That is nt/dur, nt/os and nt/or will normally be rtp/dur, rtp/os and rtp/or respectiviely 
since rtp package extends nt package. 

I know that it is agreed that if a termination realizes rtp package, it also realizes nt package 
and either nt/.. or rtp/.. are valid packageName. 

But if we allow, nt/... instead of rtp/.., are we saying that if MGC receives nt/.., it has to 
know whether it is for rtp or tmcd termination by the terminationID? 

Furthermore, since tdmc package extends nt package, do "octet sent" (OS) and "octet 
received" (OR) really apply to tdm termination? 

Also what does it mean for a TDM termination to realize the "NT" package properties 
of "Maximum Jitter Buffer"? 

So a more general question, if a termination realizes a packageB that extends 
packageA and there are items in the packageA that does not make sense to 
the termination what should MG/MGC do. 

Take the above as an example and assuming that it does not make sense for TDM 
termination to have "OS" and "OR", what should MG return for TDM termination 
statistics if the termination realizes "TDMC" package? 
Just "duration". 

--- 
Said it is valid to have "OS" and "OR" for TDM. 
IF MGC does a Subtract=* on a specific context w/1 TDM and 1 RTP termination, 
is it valid for MG to return nt/dur, nt/os and nt/or for the TDM termination and RTP 
termination instead of tdmc/dur, ... vs rtp/dur ? 

Thanks 
Chuong 

-- 

  Alcatel USA, Inc             Internet: [email-masked]

  1000 Coit Road Plano, Texas 75075           Phone:    (972) 519-4613

  **** The opinions expressed are not those of Alcatel USA, Inc ****

-- 

  Alcatel USA, Inc             Internet: [email-masked]

  1000 Coit Road Plano, Texas 75075           Phone:    (972) 519-4613

  **** The opinions expressed are not those of Alcatel USA, Inc ****

---

From: "Blatherwick, Peter" <[email-masked]>
Date: Tue, 29 May 2001 22:06:28 -0400

You may be right (a flaw in the package hierarchy), but in practice its too late, the NT package is done.  Maybe version 2...
-- Peter

-----Original Message-----
From: Madhu Babu Brahmanapally [mailto:[email-masked]]
Sent: May 29, 2001 21:48
To: 'Blatherwick, Peter'; 'Chuong Nguyen'; [email-masked]
Subject: RE: Network Package

Hi Peter/All,
I think the better place for the "Maximum Jitter Buffer" is the RTP package
instead of the NT package. 0 can be the value for TDM terminations but...if
its the same value... no extra information is conveyed to MGC. Only RTP
package realizing terminations should use them.

Regards
Madhubabu

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]]On Behalf Of Blatherwick,
Peter
Sent: Tuesday, May 29, 2001 9:35 PM
To: 'Chuong Nguyen'; [email-masked]
Subject: RE: Network Package

See below (and related responses to Madhubabu).   -- Peter

-----Original Message-----
From: Chuong Nguyen [mailto:[email-masked]]
Sent: May 29, 2001 18:15
To: [email-masked]
Subject: Re: Network Package

Ok.  I follow you now but ....

IS this clearly stated somewhere?
This could be a nightmare for MGC to receive the same statistics value via 2
different
parameter.  Talk about the overhead of parsing these text strings.

[PB]  I believe this logic was given in the Implementors' Guide.  If it
remains unclear, please let us all know what needs to be clarified.

[PB] Yes, there would be double the overhead, but that's not really
different overhead from MGC asking for 2 sets of statistics from different
sources.

 Can someone answer the question what does it mean for tdmc package to
extend nt package property of "Maximum Jitter Buffer"?

[PB] My opinion, not as author of the tdmc Package,  is the property should
simply always be 0.  There is no jitter buffer.  I agree this is not a very
interesting value, so if the MGC is not interested it should not ask, and if
its software is designed to handle the general case of any package extending
from nt, it better be able to handle 0 as the answer.

Thanks
Chuong

"Rosen, Brian" wrote:

Well rtp/dur and nt/dur are "the same thing" in the sense that the mean the
samething, but if you implement (expose) both packages, then they are
"separate"statistics.  Using Events is perhaps easier to understand.
Suppose Package Aimplements event E1, and package B extends Package A, and a
given implementationexposes both A and B, such that an audit of termination
T1 returns Packages{..A,B..}You can say Add=T1{Events=123{B/E1}}or you can
sayAdd=T1{Events=123{A/T1}}or evenAdd=T1{Events=123{A/T1,B/T1}}In the
latter, detection of the event would result in a notify of both.Returning to
statistics, the value would be the same, but they are
separatestatistics.Brian

-----Original Message-----
From: Chuong Nguyen [ mailto:[email-masked]
<mailto:[email-masked]> ]
Sent: Tuesday, May 29, 2001 5:29 PM
To: [email-masked]
Subject: Re: Network Package
"Rosen, Brian" wrote:

If you implement any part of a package, you implement all of it.If a package
extends any part of a package, it extends all of it.

What is not required is that if you implement a package that extendsanother
package that you have to "expose" the underlying package.This means that if
you implement rtp you don't have to expose nt.If you list nt as one of the
packages in an audit, then you have toimplement nt/dur.

<cnn>  I don't quite follow here.
               You seem to imply that nt/dur and rtp/dur are 2 different
things.
               I thought both nt/dur and rtp/dur are the same thing w/the
same value.
              If MG exposed nt, what should it return for duration - nt/dur
or rtp/dur?

Brian

-----Original Message-----
From: Madhu Babu Brahmanapally [ mailto:[email-masked]
<mailto:[email-masked]> ]
Sent: Tuesday, May 29, 2001 5:15 PM
To: 'Chuong Nguyen'
Cc: [email-masked]
Subject: RE: Network Package
Hi chuong/all,IMO if PackageB extends PackageA and if one of the
statistic/property of Package A is not valid for termination realizing
packageB then there is no reason why PackageB extends PackageA. Then
PackageB shouldn't extend PackageA (just only to reuse few
properties/statistics) but should define the same properties (Might be with
different IDs) in packageB. I think the extension of packages is logical if
the newly defined package can inherit "all" the properties already defined
in the base package and also define new properties. In your example, I was
in the impression that "OS" and "OR" can be calculated as "The number of
octet sent or received is equal to the duration of the Termination, in
seconds, multiplied by the sampling frequency,  8000 Hz.". (Of course this
seems to be redundant info if the MGC is aware of the sampling frequency).
Isn't this the intention?????-RegardsMadhubabu

-----Original Message-----
From: [email-masked]
 mailto:[email-masked]
<mailto:[email-masked]> ]On Behalf Of Chuong Nguyen
Sent: Tuesday, May 29, 2001 4:38 PM
To: [email-masked]
Subject: Network Package
Hi All

Is it reasonable to assume that Network Package StatisticsID will never be
used directly?
That is nt/dur, nt/os and nt/or will normally be rtp/dur, rtp/os and rtp/or
respectiviely
since rtp package extends nt package.

I know that it is agreed that if a termination realizes rtp package, it also
realizes nt package
and either nt/.. or rtp/.. are valid packageName.

But if we allow, nt/... instead of rtp/.., are we saying that if MGC
receives nt/.., it has to
know whether it is for rtp or tmcd termination by the terminationID?

Furthermore, since tdmc package extends nt package, do "octet sent" (OS) and
"octet
received" (OR) really apply to tdm termination?

Also what does it mean for a TDM termination to realize the "NT" package
properties
of "Maximum Jitter Buffer"?

So a more general question, if a termination realizes a packageB that
extends
packageA and there are items in the packageA that does not make sense to
the termination what should MG/MGC do.

Take the above as an example and assuming that it does not make sense for
TDM
termination to have "OS" and "OR", what should MG return for TDM termination
statistics if the termination realizes "TDMC" package?
Just "duration".

---
Said it is valid to have "OS" and "OR" for TDM.
IF MGC does a Subtract=* on a specific context w/1 TDM and 1 RTP
termination,
is it valid for MG to return nt/dur, nt/os and nt/or for the TDM termination
and RTP
termination instead of tdmc/dur, ... vs rtp/dur ?

Thanks
Chuong

--

--

--

---

From: "Michael Brown" <[email-masked]>
Date: Wed, 30 May 2001 14:52:00 -0400

Comments inline.

-----Original Message-----
From: Chuong Nguyen [mailto:[email-masked]]
Sent: Wednesday, May 30, 2001 10:58 AM
To: [email-masked]
Subject: Re: Network Package

See comment below: 

<cnn>  Are you referring to the following in IGv6  Section 12.1? 

When packages are extended, the properties, events, signals and statistics
defined in the base package can be referred to using either the extended
package name.  For example, if Package A defines event e1, and Package B
extends Package A, then B/e1 is an event for a termination implementing
Package B. By definition, the MG MUST also implement the base Package, but
it optional to publish the base package as an allowed interface.  If it does
publish A, then A would be reported on the Package Descriptor in AuditValue
as well as B, and event A/e1 would be available on a termination.  If the MG
does not publish A, then only B/e1 would be available.  If published through
AuditValue, A/e1 and B/e1 are the same event. 
For the purpose of improved interoperability and backward compatibility, the
an MG MAY publish all Packages supported by its Terminations, including base
Packages from which extended Packages are derived.  An exception to this is
in cases where the base packages are expressly designed to be extended by
others, not directly controlled, and may not have any function on their own
or be nonsensical on their own, in which case the MG SHOULD NOT publish the
base Packages. 

<cnn>  I don't see anything remotely stating what we are discussing about
statistics and 
               event reporting.   Specifically that one can get duplicate
statistics. 

[MB] I would disagree as I think the IG statements are definitely related
although perhaps not complete. There are two different issues here. First is
the case where the MGC is specifically asking for certain statistics. This
is covered by the spec along the lines of the earlier statements that the
MGC is in control and if it asks for something stupid, well, the MG should
do it. 

The second issue is a bit more problematic (the Subtract request resulting
in reporting of statistics); however, the behavior of the MG in reporting
statistics is based on which packages are "published" by the MG. If the MG
implementation publishes both a base package and a package that extends that
base package, then the default behavior would be to report both statistics.
I don't mean to say that it is a useful thing to do... just that it is what
will happen. The point is that IMO publishing both the packages is a poor
implementation choice on the part of the MG. So, this gets to your
question... do we need to document that this is a poor implementation
choice? I'm not really convinced that it is necessary.

<cnn>  I am using the case of Subtract Request which does not specify any
parameter. 
              Thus MG will reply w/all statistics in which case MGC will
receive duplicate 
              statistics.
[MB] Issue #2 above.  

<cnn>  So in general if a package that extends another package and there is
some parameters 
               that might not apply, we do not flag it as an error but
assume some default value 
               and treat it as a nop? 

              So does NT package qualify as a "base package" based on the
definition of what 
              a "base package" is as quoted above - 

An exception to this is in cases where the base packages are expressly
designed to be extended by others, not directly controlled, and may not have
any function on their own or be nonsensical on their own, in which case the
MG SHOULD NOT publish the base Packages. 

Should something be added to each package to define whether it is a "base
package" 
which meant that it can't be used on its own? 

NT package is one example to me since each termination that realizes this
package must 
belong to some network type which should have its own network-type package
(RTP, 
TDM, ATM, etc).

[MB]  The fact is that the Jitter Buffer property WAS supposed to be moved
from the Network to the RTP package. Initially, there was only a network
package and it had all of the properties that now reside in RTP package.
After discussion about support of other network types, it was agreed that
the approach that you describe in the previous paragraph was the right one
and the RTP package was created. I don't remember why the Jitter Buffer
parameter didn't get moved, but this was pointed out at that time and the
intent was that it would be moved to the RTP package before publication of
the version 1 spec. Unfortunately, the change didn't get made and was
overlooked at the time of determination/Last Call. So, there we have it...
The Network package was supposed to be a generic base package, but it isn't
exactly. As far as what should be done, unfortunately, based on the existing
rules for versioning (which I think we should revisit), we aren't able to
simply remove the property from the Network package in a new version. So, I
think that the right thing is to include some text in the Network Package to
deprecate the use of the Jitter Buffer property there (I don't believe that
this would qualify as a new verion of the package) and upversion the RTP
package and add the property. (Just by the way, this upversioning of the
package would, I think, not necessarily have to wait for Version 2 of the
H.248 spec since versioning of a package is not necessarily tied to a
particular version of the base protocol.)

[MB] I think that your suggestion that in general we should handle this type
of error as a NOP really isn't a good rule of thumb as a "fix". It is OK as
a workaround, but the package should ultimately be fixed (or done right to
begin with :-) ).

 [MB] One other thing was about whether we should add something stating that
a package is a base package. I'm not adamantly opposed to the idea, but I
really don't think it's necessary.

---

From: "Blatherwick, Peter" <[email-masked]>
Date: Wed, 30 May 2001 16:52:38 -0400

Hmmm....  I still don't agree its unclear, and am hesitant to add description for special cases that actually aren't special at all, just odd MGC behavior.  My opinion.  (Just remove the BREAK and everything's ok.)
-- Peter

-----Original Message-----
From: Madhu Babu Brahmanapally [mailto:[email-masked]]
Sent: May 30, 2001 10:46
To: 'Blatherwick, Peter'; [email-masked]
Subject: RE: Network Package

HI Peter/All,

Might be an implementation issue but let me put the same query with some
sample code.

The Section 7.1.9 Events Descriptor 4th paragraph,
"When an event is processed against the contents of an active Events
   descriptor and found to be present in that descriptor ("recognized"),
   the default action of the MG is to send a Notify command to the MG."

After interpretation, the statement above was implemented as follows

ProcessDetectedEvent( Event detected is passed)
{
  if ( Events Descriptor is active)
  {
      for ( each event in the events descriptor )
      {
           if ( match Found)
           {
                 GenerateNotifyTowardsMGC ( event, timestamp, RequestId,
etc...)
                 PostEventDetectionProcessing(Event Detected)
                 break;
           }
      }
  }
  else
     ProcessEventAccordingToEventsBufferDescriptor( Event detected is
passed)
}

Its true that the IG mentions about package extension, but no where (I mean
either in IG/protocol) its mentioned that if one event recognition matches
two events in the Events Descriptor...(at First I wondered how this was
possible...) there will be two Notify commands generated towards MGC.

IMHO Unless explicitly mentioned about the multiple Notifies for single
hardware event, the general interpretation of event matching will be some
thing as shown above...which is actually not the intent.

Regards
Madhubabu

-----Original Message-----
From: Blatherwick, Peter [mailto:[email-masked]]
Sent: Tuesday, May 29, 2001 10:05 PM
To: 'Madhu Babu Brahmanapally'; [email-masked]
Subject: RE: Network Package

Now I'm not so sure what you're getting at below -- what is different from
previous examples.  I see the rules as completely general.  MG simply checks
for events to report (redundant or not, doesn't care or even necessarily
know), in the order requested, and for each one follows the
buffering/reporting algorithm per current handling settings.  Perhaps a more
explicit example?

Re the IG, I don't think it explicitly mentions "synonyms" (nice term by the
way ;-), but does give clear guidance on what is considered equivalent, how
the MG exposes its interfaces, and how the MGC specifies what it wants.
Event reporting text in the core protocol document and/or IG I personally
believe already are clear on how events are reported.  Since we are not
talking about special cases, simply same handling for all events requested
by MGC, I don't see that specific text is required.  My opinion.

-- Peter

-----Original Message-----
From: Madhu Babu Brahmanapally [mailto:[email-masked]]
Sent: May 29, 2001 21:44
To: 'Blatherwick, Peter'; 'Rosen, Brian'; 'Chuong Nguyen';
[email-masked]

HI Peter/All,

I agree that the MG does whatever is said by the MGC. But, if say Events
Descriptor is X,Y,Z and say X and Z means the same (Similar to the A/T1 and
B/T1). Now the MG while reporting the event in the Notify also has to check
events beyond match???? Is this fine???

1) Then this has to be true while buffering events in Events Buffer
according to Event Buffer descriptor and
2) While processing of new events descriptor when Event Buffer control is
lockstep.

But I see no such statement in the Protocol Text. If the intention of
matching of event is to match all the "synonyms" of the event. Then this
text needs to be specified in the IG at least to avoid any
misunderstandings.

Regards
Madhubabu

-----Original Message-----
From: Blatherwick, Peter [mailto:[email-masked]]
Sent: Tuesday, May 29, 2001 9:22 PM
To: 'Madhu Babu Brahmanapally'; 'Rosen, Brian'; 'Chuong Nguyen';
[email-masked]

As in previous e-mail, just sent, I don't believe the below error should
apply to the case of MGC requesting both A/T1 and B/T1.   MG is simply
responding to the request.   May be a better case for using this if the
request is for A/T1 and A/T1, but I still don't think so.  MG simply does as
its told.
-- Peter

-----Original Message-----
From: Madhu Babu Brahmanapally [mailto:[email-masked]]
Sent: May 29, 2001 19:19
To: 'Rosen, Brian'; 'Chuong Nguyen'; [email-masked]
Subject: RE: Network Package

Brian/All,

Sorry for wrong information in my earlier mail.... Error code "456 -
Parameter or Property appears twice in this Descriptor" is present for
avoiding multiple instances of properties/parameters. If A/T1 and B/T1 mean
the same doesn't this fall into the above error category.

Regards
Madhubabu

-----Original Message-----
[mailto:[email-masked]]On Behalf Of Rosen, Brian

Well rtp/dur and nt/dur are "the same thing" in the sense that the mean the
same
thing, but if you implement (expose) both packages, then they are "separate"
statistics.  Using Events is perhaps easier to understand.  Suppose Package
A
implements event E1, and package B extends Package A, and a given
implementation
exposes both A and B, such that an audit of termination T1 returns
Packages{..A,B..}

Brian

-----Original Message-----
From: Chuong Nguyen [mailto:[email-masked]]
Sent: Tuesday, May 29, 2001 5:29 PM
To: [email-masked]
Subject: Re: Network Package

"Rosen, Brian" wrote:

Brian

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

---

Thanks
Chuong

--

--

---

From: "Blatherwick, Peter" <[email-masked]>
Date: Wed, 30 May 2001 17:14:28 -0400

Basically, I agree with Mike's statements.  See a bit more below.  This is getting long, so I'll shut up (for now)...
-- Peter

-----Original Message-----
From: Michael Brown [mailto:[email-masked]]
Sent: May 30, 2001 14:52
To: [email-masked]
Subject: RE: Network Package

Comments inline.

-----Original Message-----
From: Chuong Nguyen [mailto:[email-masked]]
Sent: Wednesday, May 30, 2001 10:58 AM
To: [email-masked]
Subject: Re: Network Package

See comment below: 

IS this clearly stated somewhere? 
This could be a nightmare for MGC to receive the same statistics value via 2 different 
parameter.  Talk about the overhead of parsing these text strings.

[PB]  I believe this logic was given in the Implementors' Guide.  If it remains unclear, please let us all know what needs to be clarified. 

When packages are extended, the properties, events, signals and statistics defined in the base package can be referred to using either the extended package name.  For example, if Package A defines event e1, and Package B extends Package A, then B/e1 is an event for a termination implementing Package B. By definition, the MG MUST also implement the base Package, but it optional to publish the base package as an allowed interface.  If it does publish A, then A would be reported on the Package Descriptor in AuditValue as well as B, and event A/e1 would be available on a termination.  If the MG does not publish A, then only B/e1 would be available.  If published through AuditValue, A/e1 and B/e1 are the same event. 
For the purpose of improved interoperability and backward compatibility, the an MG MAY publish all Packages supported by its Terminations, including base Packages from which extended Packages are derived.  An exception to this is in cases where the base packages are expressly designed to be extended by others, not directly controlled, and may not have any function on their own or be nonsensical on their own, in which case the MG SHOULD NOT publish the base Packages. 

<cnn>  I don't see anything remotely stating what we are discussing about statistics and 
               event reporting.   Specifically that one can get duplicate statistics. 

[MB] I would disagree as I think the IG statements are definitely related although perhaps not complete. There are two different issues here. First is the case where the MGC is specifically asking for certain statistics. This is covered by the spec along the lines of the earlier statements that the MGC is in control and if it asks for something stupid, well, the MG should do it. 

The second issue is a bit more problematic (the Subtract request resulting in reporting of statistics); however, the behavior of the MG in reporting statistics is based on which packages are "published" by the MG. If the MG implementation publishes both a base package and a package that extends that base package, then the default behavior would be to report both statistics. I don't mean to say that it is a useful thing to do... just that it is what will happen. The point is that IMO publishing both the packages is a poor implementation choice on the part of the MG. So, this gets to your question... do we need to document that this is a poor implementation choice? I'm not really convinced that it is necessary. 

[PB] Agree both cases are actually something that should not happen anyway, at least for any reasonable circumstance I can see.  MG should not publish redundant Packages (only "leaf nodes" in general), but is free to do so if it wants.  One case where MG implementation might do this is to allow MGCs to use more advanced (extended) packages recently defined, while still allowing for less advanced ones (base packages) to be used by MGCs that don't know the extended ones.  In that case MGC would need to explicitly ask for which one it wants (as it normally would).  Other case could be where MGC sets Events=ALL, in which case the MGC should be ready to handle the flood, but I would not see this being done in a system where the flood would could actually be a problem (i.e inside small networks only, or where Package sets are know in advance not to be redundant or otherwise cause excess loads).  

[PB] Yes, there would be double the overhead, but that's not really different overhead from MGC asking for 2 sets of statistics from different sources. 

<cnn>  I am using the case of Subtract Request which does not specify any parameter. 
              Thus MG will reply w/all statistics in which case MGC will receive duplicate 
              statistics.
[MB] Issue #2 above.  

[PB] My opinion, not as author of the tdmc Package,  is the property should simply always be 0.  There is no jitter buffer.  I agree this is not a very interesting value, so if the MGC is not interested it should not ask, and if its software is designed to handle the general case of any package extending from nt, it better be able to handle 0 as the answer. 

<cnn>  So in general if a package that extends another package and there is some parameters 
               that might not apply, we do not flag it as an error but assume some default value 
               and treat it as a nop? 

              So does NT package qualify as a "base package" based on the definition of what 
              a "base package" is as quoted above - 

An exception to this is in cases where the base packages are expressly designed to be extended by others, not directly controlled, and may not have any function on their own or be nonsensical on their own, in which case the MG SHOULD NOT publish the base Packages. 

Should something be added to each package to define whether it is a "base package" 
which meant that it can't be used on its own? 

NT package is one example to me since each termination that realizes this package must 
belong to some network type which should have its own network-type package (RTP, 
TDM, ATM, etc).

[MB]  The fact is that the Jitter Buffer property WAS supposed to be moved from the Network to the RTP package. Initially, there was only a network package and it had all of the properties that now reside in RTP package. After discussion about support of other network types, it was agreed that the approach that you describe in the previous paragraph was the right one and the RTP package was created. I don't remember why the Jitter Buffer parameter didn't get moved, but this was pointed out at that time and the intent was that it would be moved to the RTP package before publication of the version 1 spec. Unfortunately, the change didn't get made and was overlooked at the time of determination/Last Call. So, there we have it... The Network package was supposed to be a generic base package, but it isn't exactly. As far as what should be done, unfortunately, based on the existing rules for versioning (which I think we should revisit), we aren't able to simply remove the property f!
!
rom the Network package in a new version. So, I think that the right thing is to include some text in the Network Package to deprecate the use of the Jitter Buffer property there (I don't believe that this would qualify as a new verion of the package) and upversion the RTP package and add the property. (Just by the way, this upversioning of the package would, I think, not necessarily have to wait for Version 2 of the H.248 spec since versioning of a package is not necessarily tied to a particular version of the base protocol.)

[MB] I think that your suggestion that in general we should handle this type of error as a NOP really isn't a good rule of thumb as a "fix". It is OK as a workaround, but the package should ultimately be fixed (or done right to begin with :-) ).

 [PB] Disagree with "NOP".  Meaning of NOP to me is the requesting end (MGC) will see nothing come back, and could get confused as a result.  I prefer to return a value of some kind, even if its non-interesting (like 0 jitter buffer size for example).  Again, if you know its a meaningless value, then don't ask for it in the first place.  

 [MB] One other thing was about whether we should add something stating that a package is a base package. I'm not adamantly opposed to the idea, but I really don't think it's necessary.  

[PB] Personally I think its a REAL GOOD IDEA (note alternate IETF key words ;-) for packages intentionally designed to be base packages *only* to say so.   There are several example of this in the existing Annexes, used where the Package is not meant to be exposed, has no function on its own, or is non-sensible on its own.  (This is sorta like virtual classes in OO world.)

---

From: [email-masked]
Date: Thu, 31 May 2001 17:24:31 +0530

Hi

Apart from the IG not mentioning about the "double notify", we have another
issue....
In case both the events in the ED have an embedded event descriptor(EED), which
EED should be activated.
Is it decided based upon the sequence of events in the ED ??
...if it is so we donot guarantee "double notify"...in case of EEDs...is it
right.

Would it not be appropriate to restrict the definition of A/E1 and B/E1 (in case
B extends a package A with event E1), to mean the same event...

How about restricting MG as well as MGC to expose only "leaf" packages (extended
packages) but to be lenient enough to accept both base as well as extended
package definitions....this would take care of any interoperability and
compatibilty issues too.
Hence, MGC would send only A/E1 in ED but can accept A/E1 and B/E1 in observed
ED.
and MG shall send only A/E1 in observed ED (or A in Audit response) and accept
B/E1 in ED etc.
Any comments..

-Kapil Nayar
Hughes Software Systems

HI Peter/All,

Regards
Madhubabu

-----Original Message-----
From: Blatherwick, Peter [mailto:[email-masked]]
Sent: Tuesday, May 29, 2001 10:05 PM
To: 'Madhu Babu Brahmanapally'; [email-masked]
Subject: RE: Network Package

-- Peter

-----Original Message-----
From: Madhu Babu Brahmanapally [mailto:[email-masked]]
Sent: May 29, 2001 21:44
To: 'Blatherwick, Peter'; 'Rosen, Brian'; 'Chuong Nguyen';
[email-masked]

HI Peter/All,

Regards
Madhubabu

-----Original Message-----
From: Blatherwick, Peter [mailto:[email-masked]]
Sent: Tuesday, May 29, 2001 9:22 PM
To: 'Madhu Babu Brahmanapally'; 'Rosen, Brian'; 'Chuong Nguyen';
[email-masked]

-----Original Message-----
From: Madhu Babu Brahmanapally [mailto:[email-masked]]
Sent: May 29, 2001 19:19
To: 'Rosen, Brian'; 'Chuong Nguyen'; [email-masked]
Subject: RE: Network Package

Brian/All,

Regards
Madhubabu

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

Brian

-----Original Message-----
From: Chuong Nguyen [mailto:[email-masked]]
Sent: Tuesday, May 29, 2001 5:29 PM
To: [email-masked]
Subject: Re: Network Package

"Rosen, Brian" wrote:

Brian

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

---

Thanks
Chuong

--

--

---

From: [email-masked]
Date: Thu, 31 May 2001 17:39:20 +0530

Hi Peter

A bit late in my response....
But, I agree with your suggestion of maxJitterBuf value to be 0 for TDMC
package.
If we look at the protocol document
"12.1.1   Package
*  Extends (Optional): A package may extend an existing package. The
      version of the original package must be specified. When a package
      extends another package it shall only add additional Properties,
      Events, Signals, Statistics and new possible values for an
      existing parameter described in the original package."

Can we define "new possible value" for maxJitterBuffer in TDMC package as 0.
We definitely, need to change the protocol document...but we can save on
addition/ deletion of properties...as discussed earlier.

Thanks,

-Kapil Nayar
Hughes Software Systems

"Blatherwick, Peter" <[email-masked]> on 05/31/2001 02:44:28 AM

To:   "'Michael Brown'" <[email-masked]>, [email-masked]
cc:    (bcc: Kapil Nayar/HSS)

Basically, I agree with Mike's statements.  See a bit more below.  This is
getting long, so I'll shut up (for now)...
-- Peter

-----Original Message-----
From: Michael Brown [mailto:[email-masked]]
Sent: May 30, 2001 14:52
To: [email-masked]
Subject: RE: Network Package

Comments inline.

-----Original Message-----
From: Chuong Nguyen [mailto:[email-masked]]
Sent: Wednesday, May 30, 2001 10:58 AM
To: [email-masked]
Subject: Re: Network Package

See comment below:

[PB]  I believe this logic was given in the Implementors' Guide.  If it remains
unclear, please let us all know what needs to be clarified.

When packages are extended, the properties, events, signals and statistics
defined in the base package can be referred to using either the extended package
name.  For example, if Package A defines event e1, and Package B extends Package
A, then B/e1 is an event for a termination implementing Package B. By
definition, the MG MUST also implement the base Package, but it optional to
publish the base package as an allowed interface.  If it does publish A, then A
would be reported on the Package Descriptor in AuditValue as well as B, and
event A/e1 would be available on a termination.  If the MG does not publish A,
then only B/e1 would be available.  If published through AuditValue, A/e1 and
B/e1 are the same event.
For the purpose of improved interoperability and backward compatibility, the an
MG MAY publish all Packages supported by its Terminations, including base
Packages from which extended Packages are derived.  An exception to this is in
cases where the base packages are expressly designed to be extended by others,
not directly controlled, and may not have any function on their own or be
nonsensical on their own, in which case the MG SHOULD NOT publish the base
Packages.

[MB] I would disagree as I think the IG statements are definitely related
although perhaps not complete. There are two different issues here. First is the
case where the MGC is specifically asking for certain statistics. This is
covered by the spec along the lines of the earlier statements that the MGC is in
control and if it asks for something stupid, well, the MG should do it.

The second issue is a bit more problematic (the Subtract request resulting in
reporting of statistics); however, the behavior of the MG in reporting
statistics is based on which packages are "published" by the MG. If the MG
implementation publishes both a base package and a package that extends that
base package, then the default behavior would be to report both statistics. I
don't mean to say that it is a useful thing to do... just that it is what will
happen. The point is that IMO publishing both the packages is a poor
implementation choice on the part of the MG. So, this gets to your question...
do we need to document that this is a poor implementation choice? I'm not really
convinced that it is necessary.

[PB] Agree both cases are actually something that should not happen anyway, at
least for any reasonable circumstance I can see.  MG should not publish
redundant Packages (only "leaf nodes" in general), but is free to do so if it
wants.  One case where MG implementation might do this is to allow MGCs to use
more advanced (extended) packages recently defined, while still allowing for
less advanced ones (base packages) to be used by MGCs that don't know the
extended ones.  In that case MGC would need to explicitly ask for which one it
wants (as it normally would).  Other case could be where MGC sets Events=ALL, in
which case the MGC should be ready to handle the flood, but I would not see this
being done in a system where the flood would could actually be a problem (i.e
inside small networks only, or where Package sets are know in advance not to be
redundant or otherwise cause excess loads).

[PB] Yes, there would be double the overhead, but that's not really different
overhead from MGC asking for 2 sets of statistics from different sources.

<cnn>  I am using the case of Subtract Request which does not specify any
parameter.
              Thus MG will reply w/all statistics in which case MGC will receive
duplicate
              statistics.
[MB] Issue #2 above.

[PB] My opinion, not as author of the tdmc Package,  is the property should
simply always be 0.  There is no jitter buffer.  I agree this is not a very
interesting value, so if the MGC is not interested it should not ask, and if its
software is designed to handle the general case of any package extending from
nt, it better be able to handle 0 as the answer.

<cnn>  So in general if a package that extends another package and there is some
parameters
               that might not apply, we do not flag it as an error but assume
some default value
               and treat it as a nop?

An exception to this is in cases where the base packages are expressly designed
to be extended by others, not directly controlled, and may not have any function
on their own or be nonsensical on their own, in which case the MG SHOULD NOT
publish the base Packages.

[MB]  The fact is that the Jitter Buffer property WAS supposed to be moved from
the Network to the RTP package. Initially, there was only a network package and
it had all of the properties that now reside in RTP package. After discussion
about support of other network types, it was agreed that the approach that you
describe in the previous paragraph was the right one and the RTP package was
created. I don't remember why the Jitter Buffer parameter didn't get moved, but
this was pointed out at that time and the intent was that it would be moved to
the RTP package before publication of the version 1 spec. Unfortunately, the
change didn't get made and was overlooked at the time of determination/Last
Call. So, there we have it... The Network package was supposed to be a generic
base package, but it isn't exactly. As far as what should be done,
unfortunately, based on the existing rules for versioning (which I think we
should revisit), we aren't able to simply remove the property!
 f!
!
rom the Network package in a new version. So, I think that the right thing is to
include some text in the Network Package to deprecate the use of the Jitter
Buffer property there (I don't believe that this would qualify as a new verion
of the package) and upversion the RTP package and add the property. (Just by the
way, this upversioning of the package would, I think, not necessarily have to
wait for Version 2 of the H.248 spec since versioning of a package is not
necessarily tied to a particular version of the base protocol.)

[MB] I think that your suggestion that in general we should handle this type of
error as a NOP really isn't a good rule of thumb as a "fix". It is OK as a
workaround, but the package should ultimately be fixed (or done right to begin
with :-) ).

 [PB] Disagree with "NOP".  Meaning of NOP to me is the requesting end (MGC)
will see nothing come back, and could get confused as a result.  I prefer to
return a value of some kind, even if its non-interesting (like 0 jitter buffer
size for example).  Again, if you know its a meaningless value, then don't ask
for it in the first place.

 [MB] One other thing was about whether we should add something stating that a
package is a base package. I'm not adamantly opposed to the idea, but I really
don't think it's necessary.

[PB] Personally I think its a REAL GOOD IDEA (note alternate IETF key words ;-)
for packages intentionally designed to be base packages *only* to say so.
There are several example of this in the existing Annexes, used where the
Package is not meant to be exposed, has no function on its own, or is
non-sensible on its own.  (This is sorta like virtual classes in OO world.)

---

From: "Blatherwick, Peter" <[email-masked]>
Date: Thu, 31 May 2001 16:11:15 -0400

Re below, NO, TDMC does not need to specify anything new, its a r/w integer value now.  We cannot override the values type.  TDMC would merely return 0 when read, fail with "invalid parameter" if MGC (foolishly) tried to set it to anything other than 0.  Latter action is perfectly valid for any package extended from NT, since clearly you can't set JIT to an arbitrarily large value on *any* MG.  

As previously stated, I disagree, the protocol does not need to be changed for this issue.  

-- Peter

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: May 31, 2001 08:09
To: Blatherwick, Peter
Cc: 'Michael Brown'; [email-masked]
Subject: RE: Network Package

Hi Peter

Thanks,

-Kapil Nayar
Hughes Software Systems

-----Original Message-----
From: Michael Brown [mailto:[email-masked]]
Sent: May 30, 2001 14:52
To: [email-masked]
Subject: RE: Network Package

Comments inline.

-----Original Message-----
From: Chuong Nguyen [mailto:[email-masked]]
Sent: Wednesday, May 30, 2001 10:58 AM
To: [email-masked]
Subject: Re: Network Package

See comment below: