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@polycom.co.il To: "'Paul E. Jones'" paulej@PACKETIZER.COM; ITU-SG16@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@PACKETIZER.COM] Sent: Monday, December 24, 2001 3:14 AM To: ITU-SG16@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@IPDIALOG.COM To: ITU-SG16@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@echo.jf.INTEL.COM]On Behalf Of Paul E. Jones Sent: Tuesday, December 18, 2001 3:07 AM To: ITU-SG16@echo.jf.INTEL.COM Subject: Re: Including RTCP report packets in IRR
I completely support your idea.
pj
----- Original Message ----- From: frank.derks@PHILIPS.COM To: ITU-SG16@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