[AVT] comments on draft-ietf-avt-rtcp-xr-mib-01.txt rtcpXrSessionIDTable

[Mark Baugher <mbaugher at cisco.com>]

Alan, Amy
  I have some comments and questions regarding the rtcpXrSessionIDTable 
of the RTCP XR MIB.

1. The MIB uses the abstraction "call," which is not defined.  It is 
outside of RTP as well as RTCP XR.  This is a signaling abstraction.  
Somehow, signaling information is used to create and initialize objects 
in the MIB but it is not described where the information is obtained 
and the issues related to different signaling protocols.  We need 
consistency in object definition to get interoperable implementations.  
Are you sure that implementers of the different systems that use this 
MIB will have the same notion of what a call is?  This should at least 
be addressed, probably in section 2, since there are sometimes RTP 
means for obtaining information but mostly this will come from diverse 
signaling protocols that may have different and even ambiguous 
definitions for some signaling objects.

2. Section 2 calls this a table of session information.  The table 
description says that each row is created for each endpoint.  So, it is 
not a session table though "session" is in the name.  The DESCRIPTION 
says its a table of call records and should give a reference to where a 
"call record" is defined.  It looks like it could be organized by SSRC, 
which is an optional value for the table's SessionIdentifier object.  
When organized by SSRC, then most of this table is redundant when there 
is more than on SSRC from the source of a "call."  But how does an 
implementer know that there should be a table row per SSRC or not?  Is 
there some definition of "call record" that would ensure that two 
implementations would do this in the same way?

3. The table is indexed by rtcpXrSessionIDIndex.  How is this value 
obtained for an efficient search?  That is, a management application 
might want to search rows in the rtcpXSessionIDTable by the source 
address and port, destination address and port, the session address 
combined with the SSRC, or something that meaningfully identifies the 
call.  SessionIDIndex is an arbitrary number and not descriptive 
information.  Why wouldn't a management application be forced to scan 
the entire table to find the rows corresponding to session or SSRC 
values?  How do you avoid doing this?

4. rtcpXrSessionIDSessionIdentifier can be either a "billing record 
correlation identifier" or an SSRC.  Where is "billing record" defined? 
 Are billing record identifiers unique?  Is this identifier likely to 
be in 1:1 correspondence with the SSRC or not?   If it is not, what 
keeps one implementation from choosing to create one row per SSRC and 
another one to do it differently?

5. rtcpXrSessionIDCallStartTime is not defined.  Is this object 
initialized from call signaling or when the first packet was observed?

6. It is not defined how rtcpXrSessionIDCallStopTime is to be 
determined?  Is this from the signaling?

7. Is it fair to say that UDP is the only transport protocol that will 
ever be used for a "call?"

8. rtcpXrSessionIDSrceIdenType and rtcpXrSessionIDDestIdenType does not 
state where the information is obtained, what to do if the information 
is not available from signaling, and how the corresponding Identifiers 
are obtained.

Mark

_______________________________________________
Audio/Video Transport Working Group
avt at ietf.org
https://www1.ietf.org/mailman/listinfo/avt