New draft of H.MMS.1

Roy, Radhika R, ALCTA rrroy at att.com
Fri Dec 28 11:04:15 EST 2001


Alan,

I completely agree with you that we should be consider the type of
information that we report.  Are you also sharing this information with Mike
Buckley (Rapporteur for the group studying QoS)?  Regardless of whether this
information gets reported to the GK or not (that's one issue), we should
ensure that the systems act on the right information, report that
information through the MIBs defined in H.341v2, etc.

Paul

-----Original Message-----
From: Alan Clark [mailto:alan at telchemy.com]
Sent: Wednesday, December 26, 2001 9:36 AM
To: 'ITU-SG16 at echo.jf.INTEL.COM'
Subject: RE: Including RTCP report packets in IRR

> Paul/ Roni/ Frank
>
> We have been introducing this general topic via ETSI TIPHON and more
> recently presented at the IETF-52 AVT session.  We believe that RTCP stats
> are not sufficient for VoIP purposes and also share the concern expressed
by
> others on this thread that it is vital to have several approaches to
getting
> data from the endpoints.
>
> The approach we advocate is:-
>
> (i) Calculate call quality metrics in the endpoint
> It is necessary to consider the "burstiness" of packet loss in order to
> assess impact on VoIP call quality - PLC is effective at hiding isolated
> lost packets but not bursts.  VQmon (ETSI TS101 329-5 Annex E) is a
> lightweight E model based algorithm for estimating call quality that
> incorporates a burst packet loss model.
>
> (ii) Recognize that there are several "audiences" for the data
> In some networks both the network operations/ management and billing
groups
> would like to have access to call quality data however their requirements
> are different.
>
> - operations/management .. real time event reporting, SNMP access, test
and
> diagnosis
>                         .. may need access to data during a call
>                         .. needs support for fault isolation
>
> - billing               .. end of call metrics
>                         .. feed back through end of call messages
>
> (iii) Provide several ways to get data out
> We would like to see multiple ways of extracting data both from the
> end-points and mid-flow.  These should include extended RTCP reports with
> call quality metrics, end of call (DRQ or equivalent) and SNMP access.
>
> Alan Clark
> Telchemy
>
> -----Original Message-----
> From: Mailing list for parties associated with ITU-T Study Group 16
> [mailto:ITU-SG16 at echo.jf.INTEL.COM]On Behalf Of Even ,Roni
> Sent: Tuesday, December 25, 2001 9:33 AM
> To: ITU-SG16 at echo.jf.INTEL.COM
> Subject: Re: Including RTCP report packets in IRR
>
>
> Paul,
> Having a solution for H.323 may not solve the problem. RTP & RTCP are used
> also in other protocols like SIP. At the last IETF meeting (IETF-52) the
> topic was discussed in the AVT WG. Maybe we can see what will happen
there.
> I would like to point out that SNMP can be used to get part of the
> information.
> Roni Even
>
> -----Original Message-----
> From: Paul E. Jones [mailto:paulej at PACKETIZER.COM]
> Sent: Monday, December 24, 2001 3:14 AM
> To: ITU-SG16 at echo.jf.INTEL.COM
> Subject: Re: Including RTCP report packets in IRR
>
>
> Paul,
>
> I suppose this is probably in need of clarification, but the assumption
was
> that if the call contained an audio session, the audio element would be
> included.  Likewise for video, etc.  Unfortunately, there are a few fields
> in H.225.0 that are labeled as "OPTIONAL" in the ASN.1, so implementers
> assume that semantically they're optional, but that's not the case.  We
> don't want to change the syntax (since we don't want to mandate the
> inclusion of a field when the call doesn't have a session of that type),
so
> I suppose it would be nice to see a proposal for clarification of this
> issue.
>
> One other thought about the RTCP stats is that we report them in the DRQ
> rather than the IRR.  One problem with IRRs is that if they are sent too
> frequently, an extremely busy system can get bogged down processing those
> messages.  I imagine that you'd want to set the IRR timer somewhere
outside
> the length of an average call.  Doing so, though, would mean you never get
> stats for the average call.  So perhaps DRQ alone (or in addition to) the
> IRR is the right approach.
>
> Paul
>
> ----- Original Message -----
> From: "Paul Long" <plong at IPDIALOG.COM>
> To: <ITU-SG16 at echo.jf.INTEL.COM>
> Sent: Tuesday, December 18, 2001 10:42 AM
> Subject: Re: Including RTCP report packets in IRR
>
>
> > Paul,
> >
> > Please note though that an EP is not required to include any media info
in
> > perCallInfo, i.e., audio, video, and data. I imagine that this was an
> > oversight, but we ought to explicitly require v5+ EPs to report all
> > currently active media sessions, including RTP.
> >
> > Paul Long
> > ipDialog, Inc.
> >
> > -----Original Message-----
> > From: Mailing list for parties associated with ITU-T Study Group 16
> > [mailto:ITU-SG16 at echo.jf.INTEL.COM]On Behalf Of Paul E. Jones
> > Sent: Tuesday, December 18, 2001 3:07 AM
> > To: ITU-SG16 at echo.jf.INTEL.COM
> > Subject: Re: Including RTCP report packets in IRR
> >
> >
> > I completely support your idea.
> >
> > pj
> >
> > ----- Original Message -----
> > From: <frank.derks at PHILIPS.COM>
> > To: <ITU-SG16 at echo.jf.INTEL.COM>
> > Sent: Monday, December 17, 2001 2:42 AM
> > Subject: Including RTCP report packets in IRR
> >
> >
> > > Dear all,
> > >
> > > RTP's specification mandates that the RTP ports, for a given
> > > source/destination, are "co-located" with the RTCP ports. This
> > > means the the report information about the RTP streams flow
> > > between the communicating endpoints. Although this mode of
> > > operation is intentional, it does make it difficult for 3rd
> > > parties to monitor the statistics as perceived by the endpoints.
> > > This can be particularly useful for network management where
> > > one would like to be able to monitor whether the network
> > > provides adequate quality.
> > >
> > > On way to access the RTCP information would be to route all the
> > > RTCP traffic through some entity, but this also means that the
> > > RTP will have to follow the same path through the network. And
> > > this is not desirable.
> > >
> > > For H.323 there would be the option to include the report packets
> > > in the "audio" element in the perCallInfo element in the IRR
> > > message. This would allow for a Gatekeeper to get a hold of these
> > > "vital" statistics.
> > >
> > > Any views?
> > >
> > > Regards,
> > >
> > > Frank
> >
>



More information about the sg16-avd mailing list