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

From: "Schwarz, Albrecht (Albrecht)" <[email-masked]>
Date: Tue, 9 Apr 2013 09:57:28 +0000

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?

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.

__________________________________________________
Dr. Albrecht Schwarz
Alcatel-Lucent
[email-masked]

---

From: Michael Krüger <[email-masked]>
Date: Tue, 9 Apr 2013 13:32:41 +0200

Hi Albrecht, et al.,

> 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. 

> 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 measurement…

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

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

---

From: "Schwarz, Albrecht (Albrecht)" <[email-masked]>
Date: Tue, 9 Apr 2013 13:04:16 +0000

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-masked]] 
Sent: Dienstag, 9. April 2013 13:33
To: Schwarz, Albrecht (Albrecht)
Cc: [email-masked]
Subject: Re: [IPFIX] IPFIX-based identification of RTP traffic with support of RTP-specific information elements?

Hi Albrecht, et al.,

Regards,
Michael

---

From: Andrew Feren <[email-masked]>
Date: Tue, 09 Apr 2013 10:32:41 -0400

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

---

From: "Schwarz, Albrecht (Albrecht)" <[email-masked]>
Date: Wed, 10 Apr 2013 07:04:43 +0000

Andrew,
that's already a step in that direction.
Comments below.
Regards,
Albrecht

From: Andrew Feren [mailto:[email-masked]]
Sent: Dienstag, 9. April 2013 16:33
To: Schwarz, Albrecht (Albrecht)
Cc: Michael Krüger; [email-masked]
Subject: 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.

[ABS] RFC 3551 = RTP AVP Profile; Reference should be "basic" RTP = RFC 3550

[ABS]  ditto, ... = RFC 3550

[ABS]  Ref. correct, there are at least three other RTP profiles; Description might be improved, sth like:
"Description: RTP payload type name according RTP AVP profile (and static codepoint assignments) [RFC 3551]"

Thoughts?

-Andrew

Michael,

Albrecht

-----Original Message-----

Cc: [email-masked]<mailto:[email-masked]>

Hi Albrecht, et al.,

Am 09.04.2013 um 11:57 schrieb "Schwarz, Albrecht (Albrecht)" <[email-masked]><mailto:[email-masked]>:

Hi Benoit, et al.,

 => rtpSequenceNumber

Such as support of

a) RTP:

- RTP SSRC

- RTP CSCR(s)

b) RTCP basic reports:

- RTCP SDES CNAME

- etc

- RTCP XR BT

- etc

Regards,

Albrecht

PS

Regards,

Michael

Dr. Albrecht Schwarz

Alcatel-Lucent

[email-masked]<mailto:[email-masked]>

IPFIX mailing list

[email-masked]<mailto:[email-masked]>

IPFIX mailing list

[email-masked]<mailto:[email-masked]>