H323 version labeling - FW: h323 Annex E support

[Lyons, Terry]

Frank,
I do not object to have some reports that are needed by the GK. I would
object to copy all RTCP info to the IRR. The RTCP is a direct connection
between encoder and decoder. This is used and will be used for supporting
media specific indications that will help the communication like for error
resilience. Another problem is that decomposed systems like gateways will
have the RTCP in the MG part while the GK communication will be done by the
MGC who does not have all the RTCP information. that is why I suggested that
instead of stating that the need is for the RTCP info to list the
information that will be useful for the GK

Regards
Roni

-----Original Message-----
From: frank.derks at PHILIPS.COM [mailto:frank.derks at PHILIPS.COM]
Sent: Tuesday, January 08, 2002 4:48 PM
To: ITU-SG16 at echo.jf.INTEL.COM
Subject: Re: Including RTCP report packets in IRR


Roni,

the idea is that the GK may have its reasons for wanting this sort of
information. Depending on why the GK wants this information, it may be
classified as being for call control, diagnosis, accounting, etc. An example
of usage for call control would be the re-routing of the call when it is
experiencing insufficient quality.

I agree that there may be other ways of obtaining this sort of information
(E.g. through the RTP MIB: RFC2959) and that we may have take other "call
control" protocols (like SIP, MGCP and H.248/Megaco) into consideration, to
avoid coming up with a H.323
specific solution. Furthermore, the solution(s) may be dependent on the
purpose of the information, although I would not opt for a variety of
solutions that do more or less the same.

The reason, why I initially, proposed the "H.323 solution", is because it is
relatively easy to add this to H.323 and because it may serve a multitude of
purposes.

The fact that this topic is being discussed within the IETF is good, but we
must be aware that this is something in which any of us can freely
participate. In a sense we all "are" the IETF if we decide to participate.
If there are any ideas withing this
community, then we should not hesitate to coomunicate this on the AVT
mailing list.

Regards,

Frank




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
> >
>