Subject: RE: Network Package

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

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]
Subject: RE: Network Package

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]
Subject: RE: Network Package

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-----
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: "Madhu Babu Brahmanapally" <[email-masked]>
Date: Wed, 30 May 2001 10:46:00 -0400

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,

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

--

--