[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: [AVT] New draft-clark-avt-rtcpxr-video-00.txt
>
-----------------------------------------------------------------------------------------------------------------------------------------------
Service Quality Matters. Test the performance and quality of your VoIP or IP video service at:
http://www.TestYourVoIP.com
http://www.TestYourIPVideo.com-----Original Message-----
> From: Alan Clark [mailto:alan.d.clark at telchemy.com]
> Sent: Wednesday, February 01, 2006 11:00 AM
> To: Hedayat, Kaynam
> Cc: IETF AVT working group
> Subject: Re: [AVT] New draft-clark-avt-rtcpxr-video-00.txt
>
> Kaynam
>
> Within the test and management equipment industry this is a
> well established, long standing and probably perpetual
> problem area. The signaling may travel by a different path
> to the media, may well be sent over an encrypted connection
> and may be "owned" by a third party (in the case of voice or
> video traffic being sent over interconnected networks).
>
> It is not a question of "simplicity" but rather making sure
> that emerging VoIP and Video services are actually capable of
> being managed given the range of likely deployment scenarios.
> If probes and analyzers have to do extensive decoding of
> RTP/ MPEG transport payloads - which may sometimes be
> encrypted - in order to do any level of performance
> monitoring and troubleshooting this would be extremely
> expensive for service providers and enterprise network
> managers and in some cases completely impractical.
I argue that this problem is already solved through out of band
correlation. I again argue that adding complexity and breaking the
architectural integrity of a protocol is not justified by simplicity of
implementations.
>
> I'm sure that if your software engineers started writing code
> that was completely impossible to either test or debug, then
> you would not be too keen on using it, even if it appeared to
> work. In the same sense, network managers need to be
> confident that they can test and debug services that they deploy.
Again, there are tools available today that allow the providers
troubleshoot and debug their networks through out of band correlation.
>
> I would prefer to put "sufficient" information into the RTCP
> XR Video payload to allow network test equipment to function
> and consider the safe and sensible assumption is that
> signaling information may not be available.
If signaling information is not available it is for a reason the most
common one hiding the signaling detail.
>
> Regards
>
> Alan
>
>
> Hedayat, Kaynam wrote:
>
> >I agree with Colin on this point. Transfer of partial correlation
> >information will introduce a need to include the full
> details of SDP on
> >the media path. The correct solution is offline correlation.
> We should
> >not introduce complexities endpoint implementations through
> standards
> >for the sake of simplicity in monitoring solutions.
> >
> >Regards,
> >Kaynam
> >
> >
> >
> >-------------------------------------------------------------
> ----------
> >-------------------------------------------------------------
> ----------
> >- Service Quality Matters. Test the performance and quality of your
> >VoIP or IP video service at:
> >http://www.TestYourVoIP.com
> >http://www.TestYourIPVideo.com-----Original Message-----
> >From: avt-bounces at ietf.org [mailto:avt-bounces at ietf.org] On
> Behalf Of
> >Colin Perkins
> >Sent: Thursday, January 19, 2006 7:27 PM
> >To: Alan Clark
> >Cc: IETF AVT working group
> >Subject: Re: [AVT] New draft-clark-avt-rtcpxr-video-00.txt
> >
> >Alan,
> >
> >On 19 Jan 2006, at 23:37, Alan Clark wrote:
> >
> >
> >>I'll take a look at this - the intent with the "correlation
> ID" was to
> >>
> >>
> >
> >
> >
> >>do what you suggest. There is some duplicate information
> in some of
> >>the extended descriptions of payloads, which would also be
> present in
> >>SDP definitions within signaling protocols such as SIP,
> however since
> >>we can't rely on the signaling messages taking the same path as the
> >>RTP stream, mid-stream monitoring systems may not be able
> to identify
> >>
> >>
> >
> >
> >
> >>the codec type (e.g. if a dynamic payload type is used).
> >>
> >>
> >
> >Indeed, I expect that mid-stream monitoring won't be able to
> determine
> >the codec in an on-line basis. You'll need to correlate with the
> >signalling later, if the signalling & media follow different
> paths. At
> >some point you'll always need to do that, unless you convey full
> >details of the SDP and SIP (or whatever control protocol used)
> >signalling in-band. And I hope no-one is proposing to convey
> all those
> >details in-band!
> >
> >Colin
> >
> >_______________________________________________
> >Audio/Video Transport Working Group
> >avt at ietf.org
> >https://www1.ietf.org/mailman/listinfo/avt
> >
> >_______________________________________________
> >Audio/Video Transport Working Group
> >avt at ietf.org
> >https://www1.ietf.org/mailman/listinfo/avt
> >
> >
> >
>
>
_______________________________________________
Audio/Video Transport Working Group
avt at ietf.org
https://www1.ietf.org/mailman/listinfo/avt