[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Sipping] Possible new requirement for draft-ietf-sipping-rtcp-summary work



Dear Editor, Authors & sipping

We have a potential application for the reporting mechanism in
draft-ietf-sipping-rtcp-summary-02, which has led to the following
question.

draft-ietf-sipping-rtcp-summary-02 provides a capability to send one or
more instances of a VQReportEvent towards a Collector. Different
instances of VQReportEvent are identified by the LocalAddr and
RemoteAddr, containing IP address, port and SSRC. Examples in the draft
show only two instances of a VQReportEvent in each instance of an
application/vq-rtcpxr content, from the local and remote RTP end
systems. In general, connections will include RTP translators (SBCs
etc). RTP translators may also generate RTCP XR reports, which RTP end
systems may wish to report as VQReportEvents. Also RTP translators may
themselves wish to report their local measurements, and/or reports
received from RTP end systems, and possibly also reports received from
other translators, as VQReportEvents. 

There could be two issues: the first may be trivial, a single RTP system
may wish to report more than two instances of VQReportEvent (e.g. two
from RTP end systems and one or more from RTP translators). Is it
permissible to do this?

The second possible issue is that the identification and discrimination
of instances VQReportEvent by a combination of LocalAddr and RemoteAddr
might be weak, for a connection involving RTP translators. RTCP XR
doesn't report IP addresses of the measuring point or the originating
point, so (for example) RTCP reports from all remote RTP end systems
behind an SBC could be reported by the local RTP end system as relating
to sessions to a single remote media IP address at the SBC. LocalAddr
and RemoteAddr contain SSRC but SSRCs are only unique in the scope of
the connection and are almost impossible to interpret at systems which
don't have access to RTCP SDES packets containing the SSRC/CNAME
binding. Is it possible to use CNAME in place of, or as well as, SSRC?
If each VQReportEvent is tagged with the CNAME of the RTP system which
made the measurement and with the CNAME of the RTP system which
originated the measured stream, interpretation should be easier. Even if
an RFC1918 IP address is used as CNAME inside a private network, RFC3550
requires translators at the edge of private networks to substitute
something globally unique, and in many cases the CNAME should be a
meaningful FQDN.

Thanks for views on this.
Geoff



_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use sip-implementors at cs.columbia.edu for questions on current sip
Use sip at ietf.org for new developments of core SIP