[iptv-users] iptv-users Digest, Vol 2, Issue 4 MDU SOLUTION

Thu Jul 2 13:22:31 EDT 2009

Dear colleagues,

If any of you are interested in a solution to deliver IPTV in MDUs or via 
Coax, HFC, Fiber Deep or FTTH RF overGlass based networks please contact me.

We have developed a Hybrid DVB-C/IPTV/DOCSIS STB and eco-system, named 
IP-NET VISION, which allows the deployment of IPTV services over RF based 
networks.

Regards,

Max Morales
HFCNET & IP-NET
Off: 1-954-578-5929 ext. 41
Cell: 1-954-684-7069
Fax/Unified Messaging: 1-954-212-9205
Web: http://www.hfcnet.net
IP-NET.... Intelligent Networks(tm)
----- Original Message ----- 
From: <iptv-users-request at puck.nether.net>
To: <iptv-users at puck.nether.net>
Sent: Thursday, July 02, 2009 12:00 PM
Subject: iptv-users Digest, Vol 2, Issue 4

> Send iptv-users mailing list submissions to
> iptv-users at puck.nether.net
>
> To subscribe or unsubscribe via the World Wide Web, visit
> https://puck.nether.net/mailman/listinfo/iptv-users
> or, via email, send a message with subject or body 'help' to
> iptv-users-request at puck.nether.net
>
> You can reach the person managing the list at
> iptv-users-owner at puck.nether.net
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of iptv-users digest..."
>
>
> Today's Topics:
>
>   1. Re: STB/video stream monitoring (Alex Moen)
>   2. Re: STB/video stream monitoring (Kevin Shymkiw)
>   3. Re: STB/video stream monitoring (Alex Moen)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Thu, 2 Jul 2009 08:36:28 -0500
> From: Alex Moen <alexm at ndtel.com>
> To: Kevin Shymkiw <kshymkiw at gmail.com>
> Cc: iptv-users at puck.nether.net
> Subject: Re: [iptv-users] STB/video stream monitoring
> Message-ID: <F7492320-B74E-469C-B704-A849A5C72642 at ndtel.com>
> Content-Type: text/plain; charset=WINDOWS-1252; format=flowed;
> delsp=yes
>
> Actually, we're kind of moving away from the super head end model.
> Transport agreements are getting harder to get.  As long as whoever is
> maintaining the SHE is responsive to the other member's requests and
> input, things go well.  When the managers of the SHE start changing
> things without consent of the group, or are not available when things
> break, it can get very frustrating.
>
> We are moving to FTTH, but have to deploy video on ADSL2+ to customers
> who do not have fiber, or those in areas that cannot get fiber (ie,
> apartment bldgs).  We are looking at VDSL, but so far we haven't found
> a system that we like or that is mature.
>
> Alex
>
>
>
> On Jul 2, 2009, at 6:59 AM, Kevin Shymkiw wrote:
>
>> That seems to be the model we want to move to is a "super head
>> end".  It seems to make more sense in terms of managing and
>> verifying content quality.
>>
>> I hear alot of you talking about DSLAM issues, etc... are most of
>> you doing IPTV through DSL or VDSL Networks?
>>
>> Kevin
>>
>> Frank Bulk wrote:
>>>
>>> Since we use a state-wide shared head end , if there?s an issue
>>> with an encoder other service providers in the state see it, too.
>>> Additionally the organization that manages the headend has
>>> Ineoquest, too.  Today we pick up the MPEG-2 video over OC-3s, so
>>> we have all the ATM PM counters, too, in regards to transport.
>>>
>>> Frank
>>>
>>> From: Kevin Shymkiw [mailto:kshymkiw at gmail.com]
>>> Sent: Wednesday, July 01, 2009 7:24 AM
>>> To: frnkblk at iname.com
>>> Cc: 'Alex Moen'; iptv-users at puck.nether.net
>>> Subject: Re: [iptv-users] STB/video stream monitoring
>>>
>>> In all honesty, we have had alot of Finger Pointing that ended up
>>> being bad feeds from the source, especially since we pick up alot
>>> of our feeds from other Video/Cable Providers.  But without a
>>> doubt, if you have a video probe at your edge before you go to the
>>> Copper Plant, it makes it very easy to point the finger at them and
>>> have the proof to support it.
>>>
>>> We do also seem to have alot of issues, when we are doing >6-8G of
>>> Multicast over some of the Cisco Cards we have deployed, so at
>>> times, that does come back to bite us.
>>>
>>> Kevin
>>>
>>> Frank Bulk wrote:
>>> When you have this finger-pointing, what does the problem actually
>>> end up
>>> being?  The vast majority of our video quality issues relate to the
>>> copper
>>> plant.  Only a minority have been related our transport gear's
>>> ability to
>>> drop the content off the DSL port.
>>>
>>> Frank
>>>
>>> -----Original Message-----
>>> From: Alex Moen [mailto:alexm at ndtel.com]
>>> Sent: Tuesday, June 30, 2009 11:35 AM
>>> To: frnkblk at iname.com
>>> Cc: iptv-users at puck.nether.net
>>> Subject: Re: [iptv-users] STB/video stream monitoring
>>>
>>> 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.
>>>
>>> http://www.ineoquest.com
>>>
>>> Alex
>>>
>>>
>>> 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
>>> out
>>> there, Psytechnics, that has a module it can integrate into the
>>> middleware
>>> 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
>>> drive.
>>>
>>> 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.
>>>
>>> Frank
>>>
>>>
>>> _______________________________________________
>>> iptv-users mailing list
>>> iptv-users at puck.nether.net
>>> https://puck.nether.net/mailman/listinfo/iptv-users
>>>
>>>
>>>
>>> _______________________________________________
>>> iptv-users mailing list
>>> iptv-users at puck.nether.net
>>> https://puck.nether.net/mailman/listinfo/iptv-users
>>>
>>>
>
>
>
> ------------------------------
>
> Message: 2
> Date: Thu, 02 Jul 2009 09:43:47 -0400
> From: Kevin Shymkiw <kshymkiw at gmail.com>
> To: Alex Moen <alexm at ndtel.com>
> Cc: iptv-users at puck.nether.net
> Subject: Re: [iptv-users] STB/video stream monitoring
> Message-ID: <4A4CB993.8060702 at gmail.com>
> Content-Type: text/plain; charset=windows-1252; format=flowed
>
> For MDU's, why don't you run FTT"x" and put it in a common area, and
> terminate it into a Multi-Layer Switch?  Then run Cat6 from the Common
> Area, into each apartment.  This allows you to still target MDU's, and
> have all the flexibility you would need, just like FTTH.
>
> As well, I guess my mindset is a bit different as far a SHE is
> concerned, since I am in a company where the Network is so big, and we
> own so much fiber, that sometimes my ideas, don't scale well for the
> smaller MSO's/ISP's/CATV Operators =).
>
> Kevin
>
> Alex Moen wrote:
>> Actually, we're kind of moving away from the super head end model.
>> Transport agreements are getting harder to get.  As long as whoever is
>> maintaining the SHE is responsive to the other member's requests and
>> input, things go well.  When the managers of the SHE start changing
>> things without consent of the group, or are not available when things
>> break, it can get very frustrating.
>>
>> We are moving to FTTH, but have to deploy video on ADSL2+ to customers
>> who do not have fiber, or those in areas that cannot get fiber (ie,
>> apartment bldgs).  We are looking at VDSL, but so far we haven't found
>> a system that we like or that is mature.
>>
>> Alex
>>
>>
>>
>> On Jul 2, 2009, at 6:59 AM, Kevin Shymkiw wrote:
>>
>>> That seems to be the model we want to move to is a "super head end".
>>> It seems to make more sense in terms of managing and verifying
>>> content quality.
>>>
>>> I hear alot of you talking about DSLAM issues, etc... are most of you
>>> doing IPTV through DSL or VDSL Networks?
>>>
>>> Kevin
>>>
>>> Frank Bulk wrote:
>>>>
>>>> Since we use a state-wide shared head end , if there?s an issue with
>>>> an encoder other service providers in the state see it, too.
>>>> Additionally the organization that manages the headend has
>>>> Ineoquest, too.  Today we pick up the MPEG-2 video over OC-3s, so we
>>>> have all the ATM PM counters, too, in regards to transport.
>>>>
>>>> Frank
>>>>
>>>> From: Kevin Shymkiw [mailto:kshymkiw at gmail.com]
>>>> Sent: Wednesday, July 01, 2009 7:24 AM
>>>> To: frnkblk at iname.com
>>>> Cc: 'Alex Moen'; iptv-users at puck.nether.net
>>>> Subject: Re: [iptv-users] STB/video stream monitoring
>>>>
>>>> In all honesty, we have had alot of Finger Pointing that ended up
>>>> being bad feeds from the source, especially since we pick up alot of
>>>> our feeds from other Video/Cable Providers.  But without a doubt, if
>>>> you have a video probe at your edge before you go to the Copper
>>>> Plant, it makes it very easy to point the finger at them and have
>>>> the proof to support it.
>>>>
>>>> We do also seem to have alot of issues, when we are doing >6-8G of
>>>> Multicast over some of the Cisco Cards we have deployed, so at
>>>> times, that does come back to bite us.
>>>>
>>>> Kevin
>>>>
>>>> Frank Bulk wrote:
>>>> When you have this finger-pointing, what does the problem actually
>>>> end up
>>>> being?  The vast majority of our video quality issues relate to the
>>>> copper
>>>> plant.  Only a minority have been related our transport gear's
>>>> ability to
>>>> drop the content off the DSL port.
>>>>
>>>> Frank
>>>>
>>>> -----Original Message-----
>>>> From: Alex Moen [mailto:alexm at ndtel.com]
>>>> Sent: Tuesday, June 30, 2009 11:35 AM
>>>> To: frnkblk at iname.com
>>>> Cc: iptv-users at puck.nether.net
>>>> Subject: Re: [iptv-users] STB/video stream monitoring
>>>>
>>>> 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.
>>>>
>>>> http://www.ineoquest.com
>>>>
>>>> Alex
>>>>
>>>>
>>>> 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
>>>> out
>>>> there, Psytechnics, that has a module it can integrate into the
>>>> middleware
>>>> 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
>>>> drive.
>>>>
>>>> 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.
>>>>
>>>> Frank
>>>>
>>>>
>>>> _______________________________________________
>>>> iptv-users mailing list
>>>> iptv-users at puck.nether.net
>>>> https://puck.nether.net/mailman/listinfo/iptv-users
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> iptv-users mailing list
>>>> iptv-users at puck.nether.net
>>>> https://puck.nether.net/mailman/listinfo/iptv-users
>>>>
>>>>
>>
>>
>
>
> ------------------------------
>
> Message: 3
> Date: Thu, 2 Jul 2009 08:49:50 -0500
> From: Alex Moen <alexm at ndtel.com>
> To: Kevin Shymkiw <kshymkiw at gmail.com>
> Cc: iptv-users at puck.nether.net
> Subject: Re: [iptv-users] STB/video stream monitoring
> Message-ID: <A181F974-3F9E-4711-9DC4-92FDEEEDD683 at ndtel.com>
> Content-Type: text/plain; charset=WINDOWS-1252; format=flowed;
> delsp=yes
>
> The problem with the MDU's in this area is that the owners will not
> let any new cable be run.  We have to work with what is there.  Kind
> of a pain.  And the company does not want to put pressure on the
> owners, so we do what we can.
>
> As far as the SHE, it really makes a lot of sense if you can get the
> transport agreements, but is sure is nice to be able to just go fix a
> problem in your own headend rather than waiting for someone else to
> fix it.  Bandwidth for the app is not a problem, it's just the
> frustration of waiting for a problem to be resolved.
>
> Alex
>
>
> On Jul 2, 2009, at 8:43 AM, Kevin Shymkiw wrote:
>
>> For MDU's, why don't you run FTT"x" and put it in a common area, and
>> terminate it into a Multi-Layer Switch?  Then run Cat6 from the
>> Common Area, into each apartment.  This allows you to still target
>> MDU's, and have all the flexibility you would need, just like FTTH.
>>
>> As well, I guess my mindset is a bit different as far a SHE is
>> concerned, since I am in a company where the Network is so big, and
>> we own so much fiber, that sometimes my ideas, don't scale well for
>> the smaller MSO's/ISP's/CATV Operators =).
>>
>> Kevin
>>
>> Alex Moen wrote:
>>> Actually, we're kind of moving away from the super head end model.
>>> Transport agreements are getting harder to get.  As long as whoever
>>> is maintaining the SHE is responsive to the other member's requests
>>> and input, things go well.  When the managers of the SHE start
>>> changing things without consent of the group, or are not available
>>> when things break, it can get very frustrating.
>>>
>>> We are moving to FTTH, but have to deploy video on ADSL2+ to
>>> customers who do not have fiber, or those in areas that cannot get
>>> fiber (ie, apartment bldgs).  We are looking at VDSL, but so far we
>>> haven't found a system that we like or that is mature.
>>>
>>> Alex
>>>
>>>
>>>
>>> On Jul 2, 2009, at 6:59 AM, Kevin Shymkiw wrote:
>>>
>>>> That seems to be the model we want to move to is a "super head
>>>> end".  It seems to make more sense in terms of managing and
>>>> verifying content quality.
>>>>
>>>> I hear alot of you talking about DSLAM issues, etc... are most of
>>>> you doing IPTV through DSL or VDSL Networks?
>>>>
>>>> Kevin
>>>>
>>>> Frank Bulk wrote:
>>>>>
>>>>> Since we use a state-wide shared head end , if there?s an issue
>>>>> with an encoder other service providers in the state see it,
>>>>> too.  Additionally the organization that manages the headend has
>>>>> Ineoquest, too.  Today we pick up the MPEG-2 video over OC-3s, so
>>>>> we have all the ATM PM counters, too, in regards to transport.
>>>>>
>>>>> Frank
>>>>>
>>>>> From: Kevin Shymkiw [mailto:kshymkiw at gmail.com]
>>>>> Sent: Wednesday, July 01, 2009 7:24 AM
>>>>> To: frnkblk at iname.com
>>>>> Cc: 'Alex Moen'; iptv-users at puck.nether.net
>>>>> Subject: Re: [iptv-users] STB/video stream monitoring
>>>>>
>>>>> In all honesty, we have had alot of Finger Pointing that ended up
>>>>> being bad feeds from the source, especially since we pick up alot
>>>>> of our feeds from other Video/Cable Providers.  But without a
>>>>> doubt, if you have a video probe at your edge before you go to
>>>>> the Copper Plant, it makes it very easy to point the finger at
>>>>> them and have the proof to support it.
>>>>>
>>>>> We do also seem to have alot of issues, when we are doing >6-8G
>>>>> of Multicast over some of the Cisco Cards we have deployed, so at
>>>>> times, that does come back to bite us.
>>>>>
>>>>> Kevin
>>>>>
>>>>> Frank Bulk wrote:
>>>>> When you have this finger-pointing, what does the problem
>>>>> actually end up
>>>>> being?  The vast majority of our video quality issues relate to
>>>>> the copper
>>>>> plant.  Only a minority have been related our transport gear's
>>>>> ability to
>>>>> drop the content off the DSL port.
>>>>>
>>>>> Frank
>>>>>
>>>>> -----Original Message-----
>>>>> From: Alex Moen [mailto:alexm at ndtel.com]
>>>>> Sent: Tuesday, June 30, 2009 11:35 AM
>>>>> To: frnkblk at iname.com
>>>>> Cc: iptv-users at puck.nether.net
>>>>> Subject: Re: [iptv-users] STB/video stream monitoring
>>>>>
>>>>> 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.
>>>>>
>>>>> http://www.ineoquest.com
>>>>>
>>>>> Alex
>>>>>
>>>>>
>>>>> 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
>>>>> out
>>>>> there, Psytechnics, that has a module it can integrate into the
>>>>> middleware
>>>>> 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
>>>>> drive.
>>>>>
>>>>> 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.
>>>>>
>>>>> Frank
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> iptv-users mailing list
>>>>> iptv-users at puck.nether.net
>>>>> https://puck.nether.net/mailman/listinfo/iptv-users
>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> iptv-users mailing list
>>>>> iptv-users at puck.nether.net
>>>>> https://puck.nether.net/mailman/listinfo/iptv-users
>>>>>
>>>>>
>>>
>>>
>
>
>
> ------------------------------
>
> _______________________________________________
> iptv-users mailing list
> iptv-users at puck.nether.net
> https://puck.nether.net/mailman/listinfo/iptv-users
>
>
> End of iptv-users Digest, Vol 2, Issue 4
> ****************************************
>

--------------------------------------------------------------------------------

No virus found in this incoming message.
Checked by AVG - www.avg.com
Version: 8.5.375 / Virus Database: 270.13.2/2214 - Release Date: 07/02/09 
05:54:00