[iptv-users] STB/video stream monitoring
frnkblk at iname.com
Thu Jul 2 00:26:33 EDT 2009
Thanks for sharing that approach, it makes sense.
It's true, we usually discount the home network as having any issues. As an
ISP, we very rarely seem CAT5 be an issue. If the DSLAM's 15-minute PM bins
showed nothing, we would likely focus our energy on the DSLAM and its
From: Thomas Kernen [mailto:tkernen at deckpoint.ch]
Sent: Wednesday, July 01, 2009 3:41 AM
To: frnkblk at iname.com
Cc: 'Kevin Shymkiw'; Alex Moen; iptv-users at puck.nether.net
Subject: Re: [iptv-users] STB/video stream monitoring
The typical approach I see is the following:
- L7 in depth analysis tools at the head-end to make sure the outgoing
streams are clean.
- L3 monitoring within the core and edge
- L3 (via RTCP stats) for the STB
- L7 with sample STBs located around the network attached to the access
As for the copper issue, are you sure they are only copper and not also
home network related? usually those issues go in pair but most people
are (still) focusing on the copper plant because they haven't (yet) seen
the home networking issues.
Frank Bulk wrote:
> It's certain not clear to me layer(s) deserve the most attention: L1 & 2,
> L4, or L7. As Kevin points out, some products are better for some layers
> than others, and depending on the user of the tool, certain ones are more
> attractive than others. My guess is that head end gurus might like an L7
> product, but the largest support group tends to be outside plant techs
> would likely prefer an L1 & 2 product. I guess I would see a product like
> Mixed Signals located more in the head end. The edge transport doesn't
> affect the MPEG content, so I really only would need an L4 product at the
> edge to tell me about response times to IGMP joins/leaves, jitter, loss,
> We can't afford a tool to cover each layer. Since we can use the tool for
> L1 & 2 to resolve our copper dial-tone and DSL issues, then it's a L4
> "versus" L7 question.
> -----Original Message-----
> From: Kevin Shymkiw [mailto:kshymkiw at gmail.com]
> Sent: Tuesday, June 30, 2009 1:15 PM
> To: Alex Moen
> Cc: frnkblk at iname.com; iptv-users at puck.nether.net
> Subject: Re: [iptv-users] STB/video stream monitoring
> I have tried Frame Grabber. Frame Grabber, needs to actually plug into
> a STB, which obviously if your an all IP shop, you would much rather
> just do an IGMP Join into a group, rather then deploy a Decoder, and a
> STB. Mixed Signals also has much better alarming features, and with
> their new release later this year, will be looking for Jitter in the
> MPEG, etc.... If you would like a contact there, you are more than
> welcome to contact me off list, and I can send you our Mixed Signals Rep.
> As far as the Alarming/Alerting, Mixed Signals on the probe itself can
> be set up to look at 5.1 Audio, and alarm for any channel of the 5.1
> Audio going quiet. Also alarms on MPEG Freezes, and many MPEG related
> alarms, other than ETR-290 stuff. Ineoquest is big on MDI Scoring,
> which basically should tell you they are stuck into the Transport Layer
> of IPTV. Mixed Signals and Symmetricom both, don't use any MDI Scoring,
> since the MDI values are all looking at Transport Layer.
> Alex Moen wrote:
>> Good info.. I am going to look into that too. Have you tried the iCMS
>> and FrameGrabbers yet from Ineo? How do they compare?
>> On Jun 30, 2009, at 12:14 PM, Kevin Shymkiw wrote:
>>> I have used Ineoquest, and would have to recomend Mixed Signals over
>>> Ineoquest (http://mixedsignals.com/index.php). Ineoquest is still
>>> looking more into the Transport Layer, rather than the MPEG itself.
>>> Mixed Signals and Symmetricom are heavily into the MPEG encoding,
>>> etc... We have a large scale deployment of Ineoquest and Mixed
>>> Signals, when I say large scale I mean >$2million, and by far the
>>> Mixed Signals product out performs Ineoquest.
>>> Alex Moen wrote:
>>>> Take a look at Ineoquest's iVMS (for transport quality monitoring)
>>>> and iCMS (for video/audio content quality and end-user experience
>>>> monitoring). We use both of these products, and they can be both a
>>>> lifesaver and a "finger-pointing" resolver.
>>>> On Jun 30, 2009, at 11:02 AM, Frank Bulk wrote:
>>>>> Is anyone doing any video stream error monitoring/checking from the
>>>>> point-of-view of the STB? I know that there is at least one vendor
>>>>> there, Psytechnics, that has a module it can integrate into the
>>>>> of the STB, but I haven't see IPTV middleware vendors picking that
>>>>> up. I
>>>>> know that the Amino 110 writes out some rudimentary stats to the
>>>>> We track most of our video problems based on the 15-minute PM bins
>>>>> that our
>>>>> transport gear's ADSL ports record, but nothing L4 and up.
>>>>> Ideally every STB would have something Psytechnic-like built in.
>>>>> iptv-users mailing list
>>>>> iptv-users at puck.nether.net
>>>> iptv-users mailing list
>>>> iptv-users at puck.nether.net
> iptv-users mailing list
> iptv-users at puck.nether.net
More information about the iptv-users