Re: [IPFIX] comments on draft-scholz-ipfix-rtp-msg-00

Hadriel,

Multiple SSRC within the 5-tuple is how the CTS product line encodes
multiple audio/video channels. Other implementations eg. T3 series use
different 5-tuples. 

(5-tuple = ipsrc, ipdst, iprotocol, l4ports)

" we should treat is as a separate flow from an IPFIX reporting
perspective, right?"

this is exactly what is done in the implementation of:

	draft-akhter-opsawg-perfmon-ipfix
	draft-akhter-opsawg-perfmon-method

In fact, the key fields for the default RTP template (IOS configuration
follows):

    match ipv4 protocol
    match ipv4 source address
    match ipv4 destination address
    match transport source-port
    match transport destination-port
    match transport rtp ssrc

and the collect fields are:

    collect routing forwarding-status
    collect ipv4 dscp
    collect ipv4 ttl
    collect transport packets expected counter
    collect transport packets lost counter
    collect transport packets lost rate
    collect transport event packet-loss counter
    collect transport rtp jitter mean
    collect transport rtp jitter minimum
    collect transport rtp jitter maximum
    collect interface input
    collect interface output
    collect counter bytes
    collect counter packets
    collect counter bytes rate
    collect counter packets dropped
    collect timestamp interval
    collect application media bytes counter
    collect application media bytes rate
    collect application media packets counter
    collect application media packets rate
    collect application media event
    collect monitor event

If the 'rtp ssrc' is not set as a key field, the various metrics form
the differing SSRC flows are aggregated to how a IPFIX 'flow' is
defined.

-----Original Message-----
From: ipfix-bounces@ietf.org [mailto:ipfix-bounces@ietf.org] On Behalf
Of Hadriel Kaplan
Sent: Tuesday, March 27, 2012 5:41 PM
To: Hendrik Scholz
Cc: <ipfix@ietf.org>
Subject: Re: [IPFIX] comments on draft-scholz-ipfix-rtp-msg-00

On Mar 27, 2012, at 1:33 PM, Hendrik Scholz wrote:

>> 3) Some of the IEs imply there's a single SSRC for a flow - are you 
>> assuming a flow is by definition the 6-tuple of IP src/dest, port 
>> src/dest, transport type, and SSRC?  In other words, if there are two

>> or more SSRCs in the same 5-tuple, would they be separate IPFIX 
>> flows? (they're only one "RTP" session from an RTP and SDP 
>> perspective)
> 
> Yes, a separate SSRC in between two nodes should be recorded in 
> separate records. After all these streams would most likely belong to 
> separate calls.

As much as I'd love for that to be the case, technically they might or
might not.  For normal voice between two users it's always the case.
But RFC 3550 always supported separate SSRCs in the same RTP session and
thus in the same 5-tuple, and RTCWeb and CLUE Working Groups have both
been talking about using that ability. (so for example video from
multiple cameras goes in the same RTP session, with separate SSRCs)  At
least that's what I believe they're thinking of.  And of course even for
a normal voice call there could be an SSRC collision, changing the SSRC
mid-call.

I'm ok with assuming one, just wondering what we do if we get a second
one.  I think you're saying we should treat is as a separate flow from
an IPFIX reporting perspective, right?

-hadriel

_______________________________________________
IPFIX mailing list
IPFIX@ietf.org
https://www.ietf.org/mailman/listinfo/ipfix