Subject: [Sipping] Comments on sipping-rtcp-summary-02

From: "Eric Burger" <[email-masked]>
Date: Sun, 29 Feb 2004 14:49:53 -0500

Package name open issue:
What other information outside of RTCP would this event carry?  If we cannot think of it, then we should stick with RTCP.

Package parameters:
What is the "end of each media session"?  Is that when RTP goes away?  When a BYE is received?  When a re-INVITE changing SDP is successfully negotiated?

Message body open issue:
Definitely should be a MIME type.

On the message format, is there any value to the message being human readable.  Presumably large carriers will be getting thousands of these reports per second.  Is there any value in having the UAS taking the binary RTCP report, formatting it as keyword-values, and sending the expanded information over the network.  Wouldn't it be easier to just copy the RTCP report buffer into the NOTIFY?  Remember, if we go the keyword-value route, UAC will decode the keyword-values back into the identical format we started out with?

I would offer that the message format should be the RTCP report format, to reduce the burden on the UAS, the network, and the UAC.  Just ask Cullen - sending 8-bit binary objects in a message is OK :/)

On the security considerations, it may be worth mentioning that evil service providers will be monitoring not just calls that traverse their network, but EVERY call the device makes.  I may use carrier A for one kind of call and, say, FWD for others.  It would be very tempting to carrier A to notice all of the "lost revenue" from my FWD calls, and to take action against me.  Thus there should be some mechanism in place to limit reporting to third parties to the kinds of calls that the owner of the device allows.  In this example, that would be calls placed through carrier A.  Note that is the honorable intention of the draft in the first place.

_______________________________________________
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