Including RTCP report packets in IRR

Paul E. Jones paulej at PACKETIZER.COM
Fri Dec 28 16:50:22 EST 2001


Roni,

The GK might be used as a place for centralized monitoring of voice quality
and/or the GK might use the information to re-route traffic.  For example,
if an ingress call from a GW will likely result in poor VoIP quality, the GW
might re-route the call over an alternate connection... perhaps re-directing
it back to the PSTN :-)

Paul

----- Original Message -----
From: "Even ,Roni" <roni.even at polycom.co.il>
To: "'Paul E. Jones'" <paulej at packetizer.com>; <ITU-SG16 at echo.jf.INTEL.COM>
Sent: Thursday, December 27, 2001 9:43 AM
Subject: RE: Including RTCP report packets in IRR


> Paul,
> The need for the report is not clear to me. Usually RTCP is used for
> codec/encoder communication and not call control. What is needed by the GK
> that is in the RTCP today. If the application is monitoring then maybe
SNMP
> has it already.
> Roni
>
> -----Original Message-----
> From: Paul E. Jones [mailto:paulej at packetizer.com]
> Sent: Thursday, December 27, 2001 6:41 AM
> To: Even ,Roni; ITU-SG16 at echo.jf.INTEL.COM
> Subject: Re: Including RTCP report packets in IRR
>
>
> Roni,
>
> Yes, you're right.  However, it seems reasonable that H.323 systems might
> report this information to the GK for decision making purposes.  We could
> use SNMP, but we'd need agreement from both sides that that is the way to
> go.  I would guess that the reporting to the GK is intended for some
> decision processes... would you really prefer to have poll via SNMP
instead?
> I'd suspect you're not going to use traps.
>
> Paul
>
> ----- Original Message -----
> From: "Even ,Roni" <roni.even at polycom.co.il>
> To: "'Paul E. Jones'" <paulej at PACKETIZER.COM>;
<ITU-SG16 at echo.jf.INTEL.COM>
> Sent: Tuesday, December 25, 2001 9:33 AM
> 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