[IPFIX] IPFIX-based identification of RTP traffic with support of RTP-specific information elements?

[Carter Bullard]

Hey Albrecht,
Argus has good support for RTP flow tracking.  We capture most of the identifiers for the RTP and the returning RTCP. Some are rather esoteric, from the IPFIX perspective.  We've got things like codec specific values, so we can calculate a good packet jitter value, in the presence of silence supression, just to name a few. 

Argus lives at http://qosient.com/argus

Maybe you can find argus useful for your task.

Carter

Carter Bullard, QoSient, LLC
150 E. 57th Street Suite 12D
New York, New York 10022
+1 212 588-9133 Phone
+1 212 588-9134 Fax

On Apr 9, 2013, at 9:04 AM, "Schwarz, Albrecht (Albrecht)" <albrecht.schwarz at alcatel-lucent.com> wrote:

> Michael,
> I'm aware that existing IPFIX elements are sufficient for the identification of "legacy" RTP traffic, which means without any multiplexing scheme.
> 
> However, "RTP multiplexing" models (at various levels), - as e.g. discussed by RTCWEB and CLUE (also AVTCORE, RTPEXT, MMUSIC) -, require the additional consideration of further, RTP specific elements, as outlined by my initial email.
> 
> Thus, my question is still open ...
> 
> Albrecht
> 
> -----Original Message-----
> From: Michael Krüger [mailto:michael.krueger at voipfuture.com] 
> Sent: Dienstag, 9. April 2013 13:33
> To: Schwarz, Albrecht (Albrecht)
> Cc: ipfix at ietf.org
> Subject: Re: [IPFIX] IPFIX-based identification of RTP traffic with support of RTP-specific information elements?
> 
> Hi Albrecht, et al.,
> 
> 
> Am 09.04.2013 um 11:57 schrieb "Schwarz, Albrecht (Albrecht)" <albrecht.schwarz at alcatel-lucent.com>:
> 
>> Hi Benoit, et al.,
>> 
>> just a quick question for clarification, would expect that this topic was already discussed by the IPFIX community in the past:
>> 
>> The IPFIX registry only lists the RTP SN (RFC 3550) element:
>> http://www.iana.org/assignments/ipfix/ipfix.xml 
>> => rtpSequenceNumber 
>> 
>> I'm wondering about support of more RTP-specific elements, which would be e.g. required for more fine-granular identification of RTP/RTCP (sub-flows)?
>> Such as support of
>> a) RTP:
>> - RTP PT (payload type)| RTCP PT (packet type)
>> - RTP SSRC
>> - RTP CSCR(s)
>> 
>> b) RTCP basic reports:
>> - RTCP SDES CNAME
>> - etc
>> 
>> c) RTCP extension reports (RFC 3611, XRBLOCK):
>> - RTCP XR BT
>> - etc
>> 
>> Looks odd that the IANA registry just provides the RTP SN, because the SSRC or/and CNAME might be much more interesting for traffic identification purposes. Hm?
> 
> My understanding is that the flowId can be used to identify a RTP flow. The parameters to define a flowId label may be the IP addresses and ports, but I guess within your own domain you are free to hash in the RTP PT, SSRC and CSRC values. But you are right that it could be beneficial to be able to report those values directly. But for the purpose of identifying a RTP flow the flowId may do the job just fine. 
> 
>> 
>> Regards,
>> Albrecht
>> 
>> PS
>> I've noticed the " draft-scholz-ipfix-rtp-audio-quality" proposal.
>> Prime purpose is (in my understanding) the export of LOCAL measurements, e.g. according RTCP XR BT=7 or other RTP application-level performance metric types according XRBLOCK.
>> However, if such measurements would be REMOTELY generated AND reported along the IP media path using RTCP XR reports (see RFC 6792), then the IPFIX entity could identify and export such measurements ... if there would by IPFIX information elements available ("which is basically feasible ...") ... i.e. another category in above list.
> 
> The purpose of that draft is to report quality metric from mid-point measurements from e.g passive network monitoring tools. Therefore mid-point injection of RTCP-XR packets is not an option for that draft proposal. Furthermore our practical experience shows that RTCP packets are most often blocked in the network and therefore not a perfect fit for quality reporting in our opinion. The intention is rather to have a common set of elements defined that can be used to report RTP quality monitoring results, and then send via other protocols and network connections to data collection / reporting systems or mediation devices.
> 
> Regards,
> Michael
> 
>> 
>> 
>> __________________________________________________
>> Dr. Albrecht Schwarz
>> Alcatel-Lucent
>> Albrecht.Schwarz at alcatel-lucent.com 
>> _______________________________________________
>> IPFIX mailing list
>> IPFIX at ietf.org
>> https://www.ietf.org/mailman/listinfo/ipfix
> 
> 
> 
> _______________________________________________
> IPFIX mailing list
> IPFIX at ietf.org
> https://www.ietf.org/mailman/listinfo/ipfix
>