RTCP Reporting by Translators

This memo is informative and as such contains no normative requirements. However it does import text fragments from other documents which contain normative requirements. The following guidance is provided for interpretation of key words in these fragments: The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in . Any requirements are those of the quoted document and not of the current informative memo.

defines three types of RTP systems which may source and sink RTP streams. These types are RTP end systems, RTP mixers, and RTP translators. For purposes of reporting connection quality to other RTP systems, RTP mixers and RTP end systems are very similar. Mixers resynchronize audio packets and do not relay RTCP reports received from one cloud towards other cloud(s). Translators do not resynchronize packets and SHOULD forward certain RTCP reports between clouds. Translators have a wide range of possible reporting behaviours. This memo is intended to assist readers in thinking about the use of RTCP by RTP translators, by collecting relevant requirements and architectural considerations. An RTP translator is defined in as "An intermediate system that forwards RTP packets with their synchronization source identifier intact". gives the following examples of translators: devices that convert encodings without mixing; replicators from multicast to unicast; and application-level filters in firewalls. For each session, an RTP translator has at least two RTP connections via different logical interfaces to network clouds, with logical separation based on a transport layer identifier (e.g. by UDP port) or at a lower layer (e.g. IP address, Ethernet VLAN identifier, ATM VCI, or physical interface). RTP traffic streams flowing via these two connections may be unicast or multicast, and may be unidirectional or bidirectional. Section 7 of defines the RTCP processing in the translator which is required to maintain correct semantics for the RTCP communication between the RTP end systems involved in the connection. This memo does not try to augment or in any way to modify normative text of , but it gathers together the various items of text from which are relevant to RTCP processing and reporting by translators. It attempts to clarify the consequences of the recommendations, including those which arise from applying the recommendations to RTCP-based reporting beyond the "basic" RTCP standardised by . The memo attempts to systematise the wide range of possibilities for measurement and reporting topologies or architectures which arise when RTP translators are capable of making measurements and sending the resulting metrics to other RTP systems. It suggests that it is helpful to consider the choices of "what measurements should be sent where" as an application of policy. Different policies lead to different tradeoffs between the cost of RTCP processing against the level of detailed knowledge which RTCP makes available about the performance of a monitored connection. collects relevant definitions and descriptions of recommended behaviour from . states some known requirements which may be satisfied, or partly satisfied, as a result of RTP translators' reporting of packet transport metrics. These have been used to drive the architectural suggestions. provides an architectural analysis of reporting by translators. It considers the sources of the information which might be available to an RTP system, and the destinations towards which that information might be sent. It suggests that decisions by each RTP system, to transfer information from specific sources or types of sources towards specific destinations or types of destinations, may be controlled by policy. The end-to-end measurement architecture results from the collective effect of these policy-based decisions made at each RTP system. In connections involving multiple systems, it is important to know which system made the measurements which resulted in a set of metrics, and to know which system originated the packet stream which is the subject of the measurement. considers the naming issues for SSRC and CNAME which arise. Some recent groups of metrics have multiple optional sections. Some of these may have significant costs, but may be useful in special circumstances, either for specific types of connections or at specific times (e.g. for diagnosis). This raises the question of whether, and how, these capabilities might be activated when needed. outlines possible schemes for control of reporting by translators. As this discussion touches on capabilities of the signalling and management planes, which are outside the scope of the memo, these methods are discussed only in general terms. provides some examples of the application of policy to create useful monitoring architectures, e.g. to provide useful localisation of transport faults whilst bounding the link bandwidth and RTP system processing capacity occupied by RTCP. recommends that RTCP packets should be combined to minimise header overheads. Using an example architecture from , considers how this might apply to the concatenation of reports from multiple translators, and shows a possible benefit in determining the order of named systems along a connection path. Discussion in this memo is not restricted to any one set of metrics within the broad scope of RTCP, such as "basic" RTCP as defined in , RTCP XR as defined in , RTCP HR as defined in , or other schemes. It appears that any RTCP scheme which meets the naming requirements of may, in principle, be used for reporting by an RTP translator. Individual metrics may not be measurable or meaningful when reported by certain types of RTP translator, e.g. metrics related to the behaviour of a de-jitter buffer may not be relevant to an RTP translator which does not contain a de-jitter buffer, but this level of detail is outside the scope of the current memo.

RFC3550 explains that RTP translators may be used to connect two or more transport-level clouds, and provides a number of detailed recommendations on the generation and processing of RTCP by RTP translators. The following excerpts from include the key guidance on processing of RTCP by RTP translators. Naming-related requirements from are given special attention in below. Section 3 of provides the following definitions: End system: An application that generates the content to be sent in RTP packets and/or consumes the content of received RTP packets. An end system can act as one or more synchronization sources in a particular RTP session, but typically only one. Mixer: An intermediate system that receives RTP packets from one or more sources, possibly changes the data format, combines the packets in some manner and then forwards a new RTP packet. Since the timing among multiple input sources will not generally be synchronized, the mixer will make timing adjustments among the streams and generate its own timing for the combined stream. Thus, all data packets originating from a mixer will be identified as having the mixer as their synchronization source. Translator: An intermediate system that forwards RTP packets with their synchronization source identifier intact. Examples of translators include devices that convert encodings without mixing, replicators from multicast to unicast, and application-level filters in firewalls. Section 6.1 of states: It is RECOMMENDED that translators and mixers combine individual RTCP packets from the multiple sources they are forwarding into one compound packet whenever feasible in order to amortize the packet overhead (see Section 7 [of ]). An example RTCP compound packet as might be produced by a mixer is shown in Fig. 1 [of ]. If the overall length of a compound packet would exceed the MTU of the network path, it SHOULD be segmented into multiple shorter compound packets to be transmitted in separate packets of the underlying protocol. This does not impair the RTCP bandwidth estimation because each compound packet represents at least one distinct participant. Note that each of the compound packets MUST begin with an SR or RR packet. Section 7.1 of summarises the purpose of translators and mixers as follows: An RTP translator/mixer connects two or more transport-level "clouds". Typically, each cloud is defined by a common network and transport protocol (e.g., IP/UDP) plus a multicast address and transport level destination port or a pair of unicast addresses and ports. (Network-level protocol translators, such as IP version 4 to IP version 6, may be present within a cloud invisibly to RTP.) One system may serve as a translator or mixer for a number of RTP sessions, but each is considered a logically separate entity. The same Section provides examples of translators, and a further definition: There may be many varieties of translators and mixers designed for different purposes and applications. Some examples are to add or remove encryption, change the encoding of the data or the underlying protocols, or replicate between a multicast address and one or more unicast addresses. The distinction between translators and mixers is that a translator passes through the data streams from different sources separately, whereas a mixer combines them to form one new stream. Translator: Forwards RTP packets with their SSRC identifier intact; this makes it possible for receivers to identify individual sources even though packets from all the sources pass through the same translator and carry the translator's network source address. Some kinds of translators will pass through the data untouched, but others MAY change the encoding of the data and thus the RTP data payload type and timestamp. If multiple data packets are re-encoded into one, or vice versa, a translator MUST assign new sequence numbers to the outgoing packets. Losses in the incoming packet stream may induce corresponding gaps in the outgoing sequence numbers. Receivers cannot detect the presence of a translator unless they know by some other means what payload type or transport address was used by the original source. Section 7.2 of , titled "RTCP Processing in Translators", provides the following detailed guidance: In addition to forwarding data packets, perhaps modified, translators and mixers MUST also process RTCP packets. In many cases, they will take apart the compound RTCP packets received from end systems to aggregate SDES information and to modify the SR or RR packets. Retransmission of this information may be triggered by the packet arrival or by the RTCP interval timer of the translator or mixer itself. A translator that does not modify the data packets, for example one that just replicates between a multicast address and a unicast address, MAY simply forward RTCP packets unmodified as well. A translator that transforms the payload in some way MUST make corresponding transformations in the SR and RR information so that it still reflects the characteristics of the data and the reception quality. These translators MUST NOT simply forward RTCP packets. In general, a translator SHOULD NOT aggregate SR and RR packets from different sources into one packet since that would reduce the accuracy of the propagation delay measurements based on the LSR and DLSR fields. Section 7.2 of describes the treatment of each RTCP packet type by translators as follows: SR sender information: A translator does not generate its own sender information, but forwards the SR packets received from one cloud to the others. The SSRC is left intact but the sender information MUST be modified if required by the translation. If a translator changes the data encoding, it MUST change the "sender's byte count" field. If it also combines several data packets into one output packet, it MUST change the "sender's packet count" field. If it changes the timestamp frequency, it MUST change the "RTP timestamp" field in the SR packet. SR/RR reception report blocks: A translator forwards reception reports received from one cloud to the others. Note that these flow in the direction opposite to the data. The SSRC is left intact. If a translator combines several data packets into one output packet, and therefore changes the sequence numbers, it MUST make the inverse manipulation for the packet loss fields and the "extended last sequence number" field. This may be complex. In the extreme case, there may be no meaningful way to translate the reception reports, so the translator MAY pass on no reception report at all or a synthetic report based on its own reception. The general rule is to do what makes sense for a particular translation. SDES: Translators typically forward without change the SDES information they receive from one cloud to the others, but MAY, for example, decide to filter non-CNAME SDES information if bandwidth is limited. The CNAMEs MUST be forwarded to allow SSRC identifier collision detection to work. A translator that generates its own RR packets MUST send SDES CNAME information about itself to the same clouds that it sends those RR packets. BYE: Translators forward BYE packets unchanged. A translator that is about to cease forwarding packets SHOULD send a BYE packet to each connected cloud containing all the SSRC identifiers that were previously being forwarded to that cloud, including the translator's own SSRC identifier if it sent reports of its own. APP: Translators forward APP packets unchanged.

[Editor's note: it is intended that requirements are added to this section during the development of the draft. Community input is requested either directly as requirements or as scenarios which might lead to additional requirements. Any additional requirements will be taken into account in enhancing proposals and descriptions of options in other sections of the draft.] Apart from the RTP/RTCP protocol-based requirements listed in above, which must be satisfied when translators process or report RTCP, there are also motivating requirements which drive the introduction of these capabilities. Operators' and users' objectives in implementing and using performance monitoring may include some or all of the following: to determine packet transport performance for their own and peer networks, to detect faulty packet transport, to prove faults or poor performance to a single operator's area of responsibility or to a point-to-point link (demarcation), to key monitoring results against individual customer RTP sessions, for correlation with subsequent user-reported faults, and to use monitoring results either alone, or (preferably) in conjunction with data describing characteristics and performance of media terminals and any other networks involved in the connection, to form estimates of media quality experienced by end users

RTCP reception reports may be produced by any of the types of RTP systems which are defined in as capable of receiving RTP packets, that is, by an RTP end system, by an RTP mixer, or by an RTP translator. Here, RTCP reports include "basic" RTCP RR packets , or other types of RTCP reception reports including those defined in , , or further reports which may be defined in future. [Editor's note - need to add references to relevant work on quality monitoring schemes for video and possibly other media] For purposes of sending reports about distribution quality, a mixer is somewhat similar to an end system, since mixers resynchronize audio packets before transmission and do not forward either reception reports from contributing sources towards the destination of the mixed output RTP stream. However an RTP translator has RTP interfaces in more than one transport-level "cloud", but does not resynchronize audio packets in transit between "clouds". Of course, like translators, mixers also have interfaces in multiple clouds which participate in the same RTP session and share the session's SSRC/CSRC space, but the mixer's outgoing RTP packets are labelled with the mixer's SSRC. Hence it is expected that the information provided by RTP translators to other RTP systems will be primarily about transport quality. If RTP mixers provide information to other RTP systems, the main focus may be on higher-level metrics of application quality. An example from the voice domain might be an RTP mixer acting as a conference bridge, which could provide information about echo-path delay and attenuation for connection to each of the participants. [Editor's note: Reporting by mixers is outside the current scope of this memo, but need to ensure that any statements which *are* made are not controversial or contradictory] An RTP translator may: forward RTCP reports generated by RTP systems in one cloud towards RTP systems in another cloud, possibly with modification generate its own RTCP reports and send them to one or more of the clouds to which it is connected. An RTP translator has several potential sources of information about transport and application quality in a session. These include RTCP (including XR) reports received from RTP end systems and mixers RTCP (including XR) reports received from other translators Measurements made locally on incoming RTP streams at the translators' interfaces (Here and in the following, RTCP XR is used to include both the RTCP XR report blocks defined in and other XR report blocks defined elsewhere, such as in , which use the infrastructure defined in .) In general, it is a matter of policy whether each of these types of information should be reported or forwarded by the translator towards neighbouring RTP systems involved in the same session. The objective of this policy may be to ensure that sufficient information is available to support network and service management at RTP systems, whilst avoiding excessive RTCP processing. Where a translator forms a boundary between service providers' domains, a provider may wish to apply policy to restrict the release of network performance information towards the provider's peer. This suggests that policy controlling reporting and forwarding of RTCP information (including XR) might be configurable differently for each network interface, and may be chosen differently for each session if the translator is capable of this level of control. This allows certain types of RTCP reports for the session to be sent outwards via one subset of the translator's interfaces involved in the session, whilst restricting reporting and forwarding outwards via another subset. The following behaviours are potentially useful at a translator: RTCP reports received from an upstream RTP end system or mixer might be forwarded towards the downstream RTP end systems or mixers involved in the session. This behaviour is recommended by to maintain the integrity of the RTCP connection between the RTP end systems involved in the connection. We call this behaviour "a" to aid discussion below of the examples of end-to-end capabilities. RTCP XR reports received from an upstream RTP end system or mixer might be forwarded towards the downstream RTP end systems or mixers involved in the session. We call this behaviour "b". The results of measurements made on an RTP stream received at one of the translator's network interfaces might be sent out as RTCP XR reports towards neighbouring RTP systems, either upstream in the direction towards the RTP system which originated the RTP stream (behaviour "c1"), or downstream in the direction towards the RTP system(s) which will receive the translated RTP stream (behaviour "c2"), or both upstream and downstream (described as behaviour "c1+c2"). RTCP XR reports received from an upstream RTP translator might be forwarded towards the downstream RTP end systems or mixers involved in the session. We call this behaviour "d". Guidance in Section 7.2 of (see above) on RTCP processing in RTP translators requires translators to modify RTCP to reflect the translator's processing of RTP media packets. If such modification is necessary it would apply to packets forwarded under all the behaviours "a", "b", "c2" and "d". It would not apply to behaviour "c1" where a report is returned to the cloud which originated the stream which is the subject of the report. The details of any necessary modification are determined by the details of the RTP translation and are outside the scope of this memo. Material in illustrates how policies may be applied to control these measuring, reporting and forwarding behaviours, and hence achieve potentially useful end-to-end reporting modes.

collects the requirements from related to naming. In the context of RTP and RTCP, naming relates to the choice of values for SSRC and CNAME at an RTP system, and how SSRC and CNAME are used in RTCP reports to other RTP systems. discusses how compliance with these naming requirements allows the identification of the RTP system which made a set of measurements, and the RTP system which originated the measured stream. discusses, in very general terms, how names might be used when reporting results 'upwards' to the signalling or management planes.

Allocation of SSRC by RTP systems is described in detail in Section 8 of . Similarly the allocation of CNAME is described in detail in section 6.5.1 of . This material is not repeated here. Section 7.2 of makes the following statement about SSRC allocation for translators: A translator does not require an SSRC identifier of its own, but MAY choose to allocate one for the purpose of sending reports about what it has received. These would be sent to all the connected clouds, each corresponding to the translation of the data stream as sent to that cloud, since reception reports are normally multicast to all participants. Section 6.5.1 of places a requirement on certain types of translators to have the capability to translate a CNAME. This is likely to apply mainly to connections involving RTP systems which use their IPv4 address as a CNAME. Restating a naming-related requirement from Section 7.2 of already given above: A translator that generates its own RR packets MUST send SDES CNAME information about itself to the same clouds that it sends those RR packets. Application writers should be aware that private network address assignments such as the Net-10 assignment proposed in RFC 1918 may create network addresses that are not globally unique. This would lead to non-unique CNAMEs if hosts with private addresses and no direct IP connectivity to the public Internet have their RTP packets forwarded to the public Internet through an RTP-level translator. (See also RFC 1627.) To handle this case, applications MAY provide a means to configure a unique CNAME, but the burden is on the translator to translate CNAMEs from private addresses to public addresses if necessary to keep private addresses from being exposed. In this memo we assume that RTP systems comply with these normative requirements of .

An RTP system which sends out a report about packets it has sent (such as the RTCP SR packet defined in ) includes its own SSRC as part of the SR. It also provides an RTCP SDES packet containing (at least) its own SSRC and CNAME, to bind SSRC to CNAME. For "basic" RTCP, this is required by the normative text in sections 6.1 and 6.4.1 of . For RTCP XR, it is required by normative text in section 2 of . For RTCP HR (work in progress), which uses the infrastructure for extended reports created by , it is likewise required by normative text in section 2 of . An RTP system which sends out a report about packets it has received (such as the RTCP RR packet defined in ) includes the SSRC of the RTP system which originated the received stream. For "basic" RTCP this is required by the text in section 6.4.2 of . For RTCP XR this is required by normative text in section 4 of and for RTCP HR (work in progress) it is required by normative text in section 3.1 of . recommends that RTP mixers send out multiple SDES packets to bind contributing source (CSRC) identifiers to these sources' CNAMEs. However it is not necesary for a receiving RTP end system (named B) to send out SDES packets to bind a stream-source's SSRC in a receiver report (RR) to the corresponding CNAME of the RTP system (named A) which originated the measured stream. It is assumed that any RTP system which receives the RTCP RR sent by B (containing A's SSRC but not A's CNAME) will also receive an RTCP packet from the stream sender A, which will contain an SR and an SDES packet. This SDES binds A's SSRC to A's CNAME. Section 7.2 of (as repeated above) requires that an RTP translator which sends RRs (and by extension other kinds of reception report such as RTCP XR or RTCP HR reports) must send SDES information about itself along with these reception reports. Although the allocation of an SSRC by an RTP translator is only permissive in , it appears that the obligation to send SDES information also mandates the allocation of an SSRC if the RTP translator wishes to send any kind of reception report (RTCP RR or any kind of RTCP XR report). RTP translators may make measurements related to RTP packet streams from multiple sources. However translators (by definition) forward RTP packets with their SSRC unchanged, and also forward the sender's necessary RTCP SDES information. Hence there is no requirement for RTP translators to create RTCP SDES packets describing the RTP systems which are the sources of the streams measured at the RTP translator. The translator may assume that RTP systems which receive the translator's reception reports for a stream from any given RTP sender will also receive forwarded SDES information describing that sender. Typically these SDES items will be forwarded by the same translator, as part of its required behaviour.

RTP systems are typically controlled by functions in the signalling and/or management planes, and it is often useful to send measurement results either to, or via, these higher-layer entities. Delivery mechanisms include (but are not restricted to): Statistics Descriptors in H.248/MEGACO packages Entries in SNMP MIBs The proposed mechanism using SIP PUBLISH or NOTIFY messages Ad-hoc mechanisms using Call Detail Records (CDRs) As discussed above for reporting within the RTP layer, it is usually necessary to label measurement results with the identity of the RTP system which made the measurement (the Measuring Point), and with the identity of the RTP system which originated the measured stream (the Originating Point). In addition when reports are sent out of the RTP layer 'upwards' to systems in the signalling or management planes, it may be useful to label the measurement results with the identity of the RTP system which made the report upwards (the Reporting Point). The SSRC identifier may convey no meaning to signalling or management systems which do not receive RTCP SDES packets. It is likely to be more useful to label measurement results with the CNAMEs of the RTP systems involved rather than with their SSRCs. An exception arises in cases where some binding information may be missing, and higher layer systems may still be able to deduce useful information about the connection if SSRC information is provided. For example, it might be possible to deduce that several reports provided measurements of the same RTP stream. It is relatively cheap to provide SSRC information in addition to CNAME.

Some recent schemes for monitoring have multiple optional groups of metrics. Some of these have significant costs in processing or bandwidth, but may be useful in special circumstances, either for specific types of connections or at specific times (e.g. for diagnosis). This raises the question of whether, and how, these capabilities might be activated when needed. This section outlines possible schemes for control of reporting by translators. As this discussion touches on capabilities of the signalling and management planes, which are outside the scope of the memo, these methods are discussed only in general terms. The first and simplest scheme is that any optional capabilites are enabled (or not) by configuration data in every participating RTP system. This solution may be satisfactory for RTP systems in a small and/or homogeneous network. However it is unlikely that large populations of independently controlled terminals and RTP translators will be configured in compatible ways. The problem is similar to that of ensuring that a compatible codec is chosen to enable end-to-end communication. Any modification of the level of reporting, e.g. for diagnostics, would need to be a coordinated change of configuration data across multiple systems. If the RTCP monitoring and reporting capability is to be controlled dynamically on a per-connection basis, it is assumed that the SDP Offer/Answer model will be used to signal that an RTP end system wishes to receive metrics of a specific kind. This is in line with some existing practice , and parallels the use of SDP to select a compatible codec. We assume that "basic" RTCP SR and RR will always be sent, as they are not optional in . Hence SDP will typically be used to control additional reporting, probably RTCP XR based. Assuming SDP Offer/Answer is used, there is still the question of the granularity of control. Some of the options are as follows: SDP selects only the top-level protocol (e.g., selects RTCP XR or RTCP HR ). The selection of optional capabilities within the chosen top-level protocol would still require configuration at each RTP system, hence would still be a likely source of incompatibility. SDP controls each reporting option individually, both to determine the top-level protocol and to determine options within the protocol. This is the design choice made in where options within the protocol are defined as XR report block types, and these block types (and, in some cases, options within them) have SDP parameters registered with IANA. This has the advantage that, if a device implements a specific monitoring standard, it can provide any subset of that standard on request. However, the amount of SDP data may become significant. SDP indicates the choice of a profile. The profile is registered. It specifies all the monitoring capabilities and probably also a set of preferred forwarding policies which achieve the desired end-to-end monitoring architecture. This has the advantage that a very small amount of SDP data in signalling (typically a single integer of SDP "payload") can select from a wide range of potentially complex behaviour in an RTP system. The disadvantage is that the RTP systems must implement the chosen profiles, so there will be a time lag between definition of a profile and its becoming available in equipment. To mitigate against this, a number of profiles could be defined at the same time as any new proposal for monitoring. These might include profiles for both "normal" and "diagnostic" purposes. The latter might include more detailed metrics and/or changed policies for forwarding measurements. Of course, local policy may override a request for a specific monitoring behaviour if there are strong reasons to do so, such as a perceived threat to security or performance. SDP may be originated at RTP end systems and carried in signalling such as SIP . In some cases SIP and its SDP attachment may be routed via a system (such as an application-layer gateway) which also contains the RTP translator function. In this case it may need only simple local communication to provide the RTP system with information from the signalling plane. Alternatively the RTP translator may be physically separated from nodes in the signalling path. In the latter case, the SDP Offer/Answer exchange may be extended to the RTP translator over a gateway control protocol such as H.248/MEGACO .

This section defines three potentially useful modes for reporting by translators and shows how each one may be implemented by consistent choices of policy at each RTP system which participates in the connection. These are "uniform" in the sense that the same policy is applied at each system of a given type. A further example illustrates the application of the same principles to a less uniform scenario in which an RTP end system is made responsible for reporting results which were measured by an RTP translator. "End system peering" is a mode in which a translator forwards RTCP reports originating from an RTP end system towards other RTP end systems (possibly with some modification consistent with the translation which it performs ). RTCP reports received from an end system are forwarded towards the same destination(s) as the destination(s) of the RTP packets received at the same interface as that at which the RTCP reports were received. This is the minimum which a translator must do to maintain the integrity of RTCP communication between the end systems. In end system peering mode, the translator does not originate any RTCP reports based on any measurements which it may make locally. A minimum "End system peering" behaviour is realised by application, at each RTP translator, of policy "a" from above. This passes only "basic" RTCP between RTCP end systems. If policy "b" is also included, RTP end systems' XR reports are also passed between RTP end systems. "Local reporting" is a mode in which the translator forwards the end systems' reports as in "end system peering" mode, to maintain RTCP communication between end systems. In addition, the translator makes measurements on the RTP stream arriving at each receive transport interface, creating associated RTCP reports. These RTCP reports are sent by the translator both towards the source and destination(s) of the monitored RTP stream. However, the translator does not forward RTCP reports generated by other translators. "Local reporting" mode allows translators to assist in localising transport faults, whilst keeping RTCP traffic and processing bounded in systems which use large numbers of translators. "Local reporting" behaviour is realised by application, at each RTP translator, of policies "a", "b" and "c1+c2" from above. "Global reporting" is a mode in which the translator forwards the end systems' reports as in "end system peering" mode, to maintain RTCP communication between end systems. In addition the translator makes measurements on the RTP stream arriving at each receive transport interface, creating associated RTCP reports. These RTCP reports are sent by the translator both towards the source and destination(s) of the RTP stream. Finally, the translator also forwards RTCP reports generated by other translators, but only towards the same destination(s) as the destination(s) of the RTP stream received at the same interface as that at which the RTCP reports were received. In particular, no RTCP report received at a translator from a system S is ever sent back towards S. "Global reporting" provides complete transport metrics to every RTP system involved in a session. In particular, end systems receive reports of measurements made on RTP streams at all receive interfaces of every translator. However, the volume of RTCP traffic and RTCP processing may become excessively large in networks, or collections of networks, which use large numbers of translators. "Global reporting" behaviour is realised by application, at each RTP translator, of all the policies "a", "b", "c1+c2" and "d" from above. The following application example illustrates that the policy-based approach is also capable of meeting specific, less uniform requirements. This arises in a provider P1's voice network which has a connection to the network of a second provider P2. P1's network contains an RTP end system, and an application layer gateway which provides a connection to a P2's network. P2's network might be a transit or terminating network. P1's application layer gateway (ALG1) is connected to P2's application layer gateway (ALG2), via a point-to-point link or a routed network. ALG1 and ALG2 provide a symmetric security barrier at the P1-to-P2 network-to-network interface. We assume that both ALGs are RTP translators with measurement capabilities and RTCP-based reporting capabilities. We assume also that both operators are willing to operate their sections of the connection in "local reporting" mode. This includes sending results of their respective ALG's measurements across the network-to-network interface, to assist their peer operator in detecting and localising transport faults. Ideally P1 would like to transfer the results of ALG1's measurements, and the reports which ALG1 receives as local reports from ALG2, directly into P1's management plane. However in this case ALG1 has no capability to report its measurement results "upwards" to signalling or management planes, although P1's RTP end system does have this capability. P1 defines policy "a", "b" and "c1+c2" for reports outgoing via ALG1's interface facing ALG2, in order to achieve the agreed "local reporting" behaviour at the network-to- network interface. In addition, however, P1 defines policies "a", "b", "c1+c2" and "d" for reports outgoing via ALG1's interface to the inside of P1's network. The effect is that ALG1 relays (towards P1's RTP end system) all the reports which the RTP translator ALG2 measured and sent to ALG1. ALG1's behaviour is asymmetric, in that it would not forward out of its outside interface (towards ALG2) any reports from other RTP translators inside P1's network. However for the connection described, this asymmetry is not expressed, because ALG1 receives into its inside interface only reports from P1's RTP end system. According to policy "b" in force at ALG1's outside interface, such reports are forwarded to ALG2.

As stated above in , Section 6.1 of recommends that translators and mixers combine individual RTCP packets from the multiple sources they are forwarding into one compound packet whenever feasible in order to amortize the packet overhead. However, section 7.2 of warns that translators should not aggregate SR and RR packets from different sources because this would degrade the accuracy of round-trip delay measurements based on the LSR and DLSR fields. This guidance is aimed at multicast connections implementing "basic" RTCP, but it may be extended to warn against the aggregation of any other system's RTCP packets with packets originated by RTP end systems and containing SR/RR information. This section suggests a method of aggregation which might reduce packet overhead in cases where translators forward reports from other translators. We suggest that RTP end systems might send all their RTCP information in a single compound RTCP packet which includes both the "basic" RTCP SR/RR information defined in , including the LSR and DLSR fields, and any RTCP XR information which the RTP end system wishes to send. RTP translators which forward RTCP reports from other translators are assumed to comply with the intention of Section 7.2 of , and hence will not attempt to combine their own RTCP reports with reports received from RTP end systems. This behaviour will help to avoid degradation of round-trip delay measurements. However RTP translators might concatenate their own RTCP reports with RTCP reports from peer translators which they choose to forward. If RTP translators append their own report to the end of a compound packet which they choose to forward, the order of concatenated RTCP blocks will be the same as the order in which network segments are traversed. This might be helpful in determining the ordering of RTP translators along the connection and hence in fault localisation for complex, multi-translator connections. This behaviour is described below with respect to the following example of a bidirectional unicast connection between RTP end systems A and Z using three translators J, K, and L:

---- ----- ----- ----- ---- | T|-->|1R 2T|-->|1R 2T|-->|1R 2T|-->|R | | A | | J | | K | | L | | Z | | R|<--|1T 2R|<--|1T 2R|<--|1T 2R|<--|T | ---- ----- ----- ----- ---- [Editors notes: Need to consider desirable behaviour for RTP translators which do not support specific blocks which may arrive from other RTP systems. If translation is transport-level only, probably best to forward unchanged apart from appropriate transport-header modifications, but if translation is application-level (e.g. codec, packetisation time) then semantics might be wrong so better to discard?] In the first example, , translators implement policies "a", "b", "c1+c2" and "d" of . The result is that the connection operates in the mode called "Global Reporting" of above, in which all measurements by translators are forwarded by other translators, ultimately reaching end systems. Without concatenation, this set of policies results in a large number of separate RTCP packets. In , concatenation is applied to reduce the number of separate RTCP packets, here to 3. The packet labelled "RTCP(A.R)" is the report from the end system, identified because its SSRC is the same as the SSRC of the RTP flow in the same direction. This is forwarded without concatenation. The packet labelled RTCP(J.1R, K.1R, L.1R) contains translator reports of measurements made on the RTP flow from A to Z, identified because they report the measured flow having SSRC equal to the SSRC of A. The packet labelled RTCP (J.2R,K.2R,L.2R) contains translator reports of measurements made on the RTP flow from Z to A, identified because they report the measured flow having SSRC equal to the SSRC of Z.

A.R/A.T------>J.1R/J.2T---->K.1R/K.2T---->L.1R/L.2T------>Z.R/Z.T | RTP | | | | |<------------|-------------|-------------|------------->| | | | | | | RTCP(A.R) | RTCP(A.R) | RTCP(A.R) | RTCP(A.R) | |- - - - - - >|- - - - - - >|- - - - - - >|- - - - - - > | | | RTCP(J.1R) | RTCP(J.1R) | RTCP(J.1R) | | |- - - - - - >|- - - - - - >|- - - - - - > | | | RTCP(J.2R) | RTCP(J.2R) | RTCP(J.2R) | | |- - - - - - >|- - - - - - >|- - - - - - > | | | | RTCP(K.1R) | RTCP(K.1R) | | | |- - - - - - >|- - - - - - > | | | | RTCP(K.2R) | RTCP(K.2R) | | | |- - - - - - >|- - - - - - > | | | | | RTCP(L.2R) | | | | |- - - - - - > | | | | | RTCP(L.2R) | | | | |- - - - - - > | | | | | | A.T/A.R<------J.1T/J.2R<----K.1T/K.2R<----L.1T/L.2R<------Z.T/Z.R | RTP | | | | |<------------|-------------|-------------|------------->| | | | | | | RTCP(Z.R) | RTCP(Z.R) | RTCP(Z.R) | RTCP(Z.R) | |< - - - - - -|< - - - - - -|< - - - - - -|< - - - - - - | | RTCP(L.1R) | RTCP(L.1R) | RTCP(L.1R) | | |< - - - - - -|< - - - - - -|< - - - - - -| | | RTCP(L.2R) | RTCP(L.2R) | RTCP(L.2R) | | |< - - - - - -|< - - - - - -|< - - - - - -| | | RTCP(K.1R) | RTCP(K.1R) | | | |< - - - - - -|< - - - - - -| | | | RTCP(K.2R) | RTCP(K.2R) | | | |< - - - - - -|< - - - - - -| | | | RTCP(J.1R) | | | | |< - - - - - -| | | | | RTCP(J.2R) | | | | |< - - - - - -| | | | | | | | |

A.R/A.T------>J.1R/J.2T---->K.1R/K.2T---->L.1R/L.2T------>Z.R/Z.T | RTP | | | | |<------------|-------------|-------------|------------->| | | | | | | RTCP(A.R) | RTCP(A.R) | RTCP(A.R) | RTCP(A.R) | |- - - - - - >|- - - - - - >|- - - - - - >|- - - - - - > | | | | | RTCP(J.1R, | | | | RTCP(J.1R, | K.1R, | | | RTCP(J.1R) | K.1R) | L.1R) | | |- - - - - - >|- - - - - - >|- - - - - - > | | | | | RTCP(J.2R, | | | | RTCP(J.2R, | K.2R, | | | RTCP(J.2R) | K.2R) | L.2R) | | |- - - - - - >|- - - - - - >|- - - - - - > | A.T/A.R<------J.1T/J.2R<----K.1T/K.2R<----L.1T/L.2R<------Z.T/Z.R | RTP | | | | |<------------|-------------|-------------|------------->| | | | | | | RTCP(Z.R) | RTCP(Z.R) | RTCP(Z.R) | RTCP(Z.R) | |< - - - - - -|< - - - - - -|< - - - - - -|< - - - - - - | | RTCP(L.1R, | | | | | K.1R, | RTCP(L.1R, | | | | J.1R) | K.1R) | RTCP(L.1R) | | |< - - - - - -|< - - - - - -|< - - - - - -| | | RTCP(L.2R, | | | | | K.2R, | RTCP(L.2R, | | | | J.2R) | K.2R) | RTCP(L.2R) | | |< - - - - - -|< - - - - - -|< - - - - - -| | | | | | | In the second example, translators implement policies "a", "b", and "c1+c2" of . The result is that the connection operates in the mode called "Local Reporting" described in above, in which measurements by each translator are sent to the nearest-neighbour RTP system in each direction but are not forwarded further. Even without concatenation, this set of policies results in a maximum of three RTCP packets in each direction on each link (per RTCP measurement cycle). There is no opportunity for concatenation in this mode.

None.

There are known security considerations for the operation of RTP translators and mixers which have been documented in (work in progress). However, this document itself contains no normative text and hence should not give rise to any new security considerations, to be confirmed.