Meeting of Q.1 during SG16

patrick.luthi at ties.itu.ch patrick.luthi at ties.itu.ch
Tue Dec 18 12:04:01 EST 2001


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