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

From: "Eric Burger" <[email-masked]>
Date: Wed, 16 Jul 2003 14:55:13 -0400

To be clear, I was endorsing the conclusion of your paper.

You examined diverting copies of RTCP summary reports to a third-party vs. having the third-party subscribe to a 'call statistics' package.  The conclusion was that a subscription was the most sensible.  I was just piling on reasons why your choice was the best, and why third-party reporting of RTCP is not the best solution.

> -----Original Message-----
> From: Alan Johnston [mailto:[email-masked]]
> Sent: Wed, July 16, 2003 2:38 PM
> To: Eric Burger
> Cc: [email-masked]
> Subject: RE: [Sipping] FWD:I-D
> ACTION:draft-johnston-sipping-rtcp-summary-00.txt
> 
> 
> Eric,
> 
> The stated intent is delivery of RTCP XR (extended report) 
> summary reports, 
> not individual RTCP SR or RR reports which would generate 
> much traffic of 
> little interest.
> 
> Thanks,
> Alan.
> 
> 
> At 11:09 AM 7/14/2003 -0400, Eric Burger wrote:
> >Would any reporting system ever be interested in RTCP 
> messages?  I would 
> >expect network operators (who I presume would be the interested 
> >third-parties) to be interested in end-of-call summaries 
> only.  Otherwise, 
> >a service provider of any significant size is signing up for 
> a significant 
> >amount of RTCP reporting (flooding?).
> >
> >Being NOTIFIED of end-of-call statistics is a sensible 
> option.  That way 
> >you can use the existing SIP security, subscription, and 
> message routing 
> >infrastructure.
> >
> > > -----Original Message-----
> > > From: Alan Johnston [mailto:[email-masked]]
> > > Sent: Fri, June 27, 2003 2:38 PM
> > > To: [email-masked]
> > > Subject: [Sipping] FWD:I-D
> > > ACTION:draft-johnston-sipping-rtcp-summary-00.txt
> > >
> > >
> > > FYI - a new draft on the delivery of RTCP summary reports to
> > > third parties.
> > >
> > > Comments most welcome.
> > >
> > > Thanks,
> > > Alan Johnston
> > > MCI
> > >
> > >
> > > ----------
> > > To: IETF-Announce: ;
> > > Subject: I-D ACTION:draft-johnston-sipping-rtcp-summary-00.txt
> > > From: [email-masked]
> > > Date: Tue, 24 Jun 2003 06:56:20 -0400
> > > Reply-to: [email-masked]
> > > Sender: [email-masked]
> > >
> > > A New Internet-Draft is available from the on-line
> > > Internet-Drafts directories.
> > >
> > >
> > >          Title           : RTCP Summary Report Delivery to
> > > SIP Third Parties
> > >          Author(s)       : A. Johnston, H. Sinnreich, A. Clark
> > >          Filename        : 
> draft-johnston-sipping-rtcp-summary-00.txt
> > >          Pages           : 9
> > >          Date            : 2003-6-23
> > >
> 
> 
> 

_______________________________________________
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

---

From: Jonathan Rosenberg <[email-masked]>
Date: Wed, 16 Jul 2003 20:31:14 -0400

It seems to me that this is all about network management. The question
is how a provider monitors and manages the quality of calls in a VoIP
network with lots of endpoints.

In that case, I think there are some important higher level questions
that need to be asked:

1. Is the aim of collection to monitor overall network quality (i.e.,
performance management)?
2. Is the aim of the collection to look for faults (fault management)?

If the problem is (1), real time reporting is not
needed. It seems to me that to have each phone send a summary
report to the provider at the end of each call might be burdensome.
Why not just sweep these statistics up periodically using SNMP, with
the SNMP MIB? Once a day or something would work, if not less
frequently even. This is a standard technique for collecting 
statistics. Indeed, one probably could sample subsets of the phones to 
obtain information - not all of the data is needed.

If the problem is (2), it seems that you don't want notifications for
all calls - only ones where there is a problem. Thus, if one had a
managed object representing a loss threshold, you might set a trap to
get fired when the threshold is crossed. All of the standard problems
of alarm correlation and root cause analysis would then apply, and
standard network management tools exist for that.

Either way, its not clear to me that SIP is the right tool for network
management.

Thanks,
Jonathan R.

Eric Burger wrote:

> You examined diverting copies of RTCP summary reports to a
> third-party vs. having the third-party subscribe to a 'call
> statistics' package.  The conclusion was that a subscription was
> the most sensible.  I was just piling on reasons why your choice
> was the best, and why third-party reporting of RTCP is not the best
> solution.
> 
> 
>> -----Original Message----- From: Alan Johnston
>> [mailto:[email-masked]] Sent: Wed, July 16, 2003 2:38 PM 
>> To: Eric Burger Cc: [email-masked] Subject: RE: [Sipping]
>> FWD:I-D ACTION:draft-johnston-sipping-rtcp-summary-00.txt
>> 
>> 
>> Eric,
>> 
>> summary reports, not individual RTCP SR or RR reports which would
>> generate much traffic of little interest.
>> 
>> Thanks, Alan.
>> 
>> 
>>>> -----Original Message----- From: Alan Johnston
>>>> [mailto:[email-masked]] Sent: Fri, June 27, 2003 2:38
>>>> PM To: [email-masked] Subject: [Sipping] FWD:I-D 
>>>> Thanks, Alan Johnston MCI
>>>> 
>>>> 
>>>> ---------- To: IETF-Announce: ; Subject: I-D
>>>> ACTION:draft-johnston-sipping-rtcp-summary-00.txt From:
>>>> [email-masked] Date: Tue, 24 Jun 2003 06:56:20
>>>> -0400 Reply-to: [email-masked] Sender:
>>>> [email-masked]
>>>> 
>>>> Title           : RTCP Summary Report Delivery to SIP Third
>>>> Parties Author(s)       : A. Johnston, H. Sinnreich, A. Clark
>>>>  Filename        :
>> 
>>>> Pages           : 9 Date            : 2003-6-23
>>>> 
>> 
>> 
>> 
> 
> 
> _______________________________________________ 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
> 

-- 
Jonathan D. Rosenberg, Ph.D.                600 Lanidex Plaza
Chief Technology Officer                    Parsippany, NJ 07054-2711
dynamicsoft
[email-masked]                     FAX:   (973) 952-5050
http://www.jdrosen.net                      PHONE: (973) 952-5000
http://www.dynamicsoft.com