Subject: RE: [Sipping] FWD:I-DACTION:draft-johnston-sipping-rtcp-summary-00.txt

From: "Jean-Francois Mule" <[email-masked]>
Date: Wed, 13 Aug 2003 18:33:01 -0600

Hi Alan & all,

Here are some comments on the requirement section of ID
draft-johnston-sipping-rtcp-summary-00.txt (see #jfm marks):

>   REQ-1: An authorized third party should be able to receive
>   selected RTCP reports on a near real time basis.
#jfm
Based on section 3, it seems that this requirement is for an authorized
3rd party to be also able to *request and/or* receive selected RTCP
reports?

>   REQ-2: The client should not have to store large amounts of
>   information.
#jfm
This comment applies to the entire ID. 
Is client = SIP UA? Or RTP host acting as receiver? Or the management
agent storing managed objects for some kind of rtp mib objects?  See
comment on REQ-5 on "participant". A terminology section could help.

>   REQ-3: The client must be able to authenticate the third party.
#jfm
For e.g., the client here could be an snmpv3 agent or a sip entity or
(why not) a netconf xml http client? I guess my point is that refining
the requirement will help define the solution that meets your needs.

>   REQ-4: The RTCP report information must be able to be transferred
>   securely.
#jfm
Could you define precisely what you mean by "securely"?
authentication, confidentiality?

>   REQ-5: Only one participant in the session need support the
>   mechanism - the participant will send both sent and received
>   summary reports.
#jfm
I find this requirement confusing, mostly because I'm not sure I
understand what participant it. Does participant mean RTP/RTCP host or
SIP UA client here? 
I also wonder how relevant this requirement is. What if
2 SIP UAs using the same signaling proxy participate in a conferencing
session and their respective RTP/RTCP hosts mix media streams coming 
from distinct RTP/RTCP hosts? How does this requirement work in 
conferencing? 

>   REQ-6: The reports will include or be associated with dialog
>   identifiers for correlation purposes.
#jfm
In this case, I think you mean the RTCPx reports delivered via the SIP
dialog. Depending on how this draft evolves, these may be different
from the RTCP reports. It may help to qualify "reports" then.

To that extent and reading thru the email threads on this draft, there
should be a requirement for a 3rd party to request specific RTCP reports
(and we should not exclude SR, RR or BYE because some applications may
actually be interested in those).

Jean-Francois 

_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [email-masked] for questions on current sip
Use [email-masked] for new developments of core SIP