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

Hi all,

I am already seeing ssrc from several vendors each with their own IEs.  
I'd be in favor of proposing something like the following as a starting 
point.  I'm not an RTP expert though so comments and/or improvements are 
welcome.

Name: rtpSSRCId  {or maybe rtpSsrcId}
Type: unsigned32
Semantic: identifier
Description: RTP syncronization source identifier [ RFC 3551]


Name: rtpPayloadEncodingId
Type: unsigned32
Semantic: identifier
Description: RTP payload type identifier as defined in [RFC 3551]


Name: rtpPayloadEncodingName
Type: string
Semantic: default
Description: RTP payload type name [RFC 3551]


Thoughts?

-Andrew


On 04/09/2013 09:04 AM, Schwarz, Albrecht (Albrecht) 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:[email protected]]
> Sent: Dienstag, 9. April 2013 13:33
> To: Schwarz, Albrecht (Albrecht)
> Cc: [email protected]
> 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)" <[email protected]>:
>
>> 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
>> [email protected]
>> _______________________________________________
>> IPFIX mailing list
>> [email protected]
>> https://www.ietf.org/mailman/listinfo/ipfix
>
>
> _______________________________________________
> IPFIX mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/ipfix

_______________________________________________
IPFIX mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ipfix