Netup 5 + IPTVPORTAL - требуется реализовать связку
Netup 5 + IPTVPORTAL - требуется реализовать связку
Требуется реализовать связку Netup 5 + IPTVPORTAL
А именно, реализовать возможность доступа абонента к определенной группе каналов в зависимости от тарифного плана.
API IPTVPORTAL:
http://ftp.iptvportal.ru/doc/
Просьба писать сюда или на info собака sobinka тчк net
А именно, реализовать возможность доступа абонента к определенной группе каналов в зависимости от тарифного плана.
API IPTVPORTAL:
http://ftp.iptvportal.ru/doc/
Просьба писать сюда или на info собака sobinka тчк net
А это уже как Вам хочется. Можно через URFA сделать, а можно через БД. В любом случае, надо писать прослойку для стыковки биллинга с API IPTV-портала. Специфичных модулей в данной схеме не требуется.LovingFox писал(а):murano, а какие модули UTM5 требуются от самого NetuUp для возможности интеграции с IPTVPORTAL? Нужен ли URFA клиент?murano писал(а):Могу помочь с интеграцией, но не раньше, чем через неделю (работой немного нагружен). Аська: 462851472, скайп dj-murano
А я к тому и спрашивал, что понять хотел, насколько жестко необходим Urfa или еще чего либо.murano писал(а):А это уже как Вам хочется. Можно через URFA сделать, а можно через БД. В любом случае, надо писать прослойку для стыковки биллинга с API IPTV-портала. Специфичных модулей в данной схеме не требуется.LovingFox писал(а):rano, а какие модули UTM5 требуются от самого NetuUp для возможности интеграции с IPTVPORTAL? Нужен ли URFA клиент?
А такой вопрос.
Есть демон rfw, который является тригером событий в UTM5 для внешних систем. Достаточно ли будет событий, которые можно через него передать, чтобы выполнить интеграцию с IPTVPORTAL, или нужно все же разбираться с базой?
Да URFA в принципе не нужна в данном случае. RFW актуален тогда, когда Вы даете клиенту ТВ через unicast. Если используется multicast, тут либо скрипт, который берет данные о тарифных связках из БД и отсылает определенные параметры в middleware, либо (если нет middleware), отсылает параметры на домовые коммутаторы для управления igmp-snooping`ом.LovingFox писал(а):А я к тому и спрашивал, что понять хотел, насколько жестко необходим Urfa или еще чего либо.murano писал(а):А это уже как Вам хочется. Можно через URFA сделать, а можно через БД. В любом случае, надо писать прослойку для стыковки биллинга с API IPTV-портала. Специфичных модулей в данной схеме не требуется.LovingFox писал(а):rano, а какие модули UTM5 требуются от самого NetuUp для возможности интеграции с IPTVPORTAL? Нужен ли URFA клиент?
А такой вопрос.
Есть демон rfw, который является тригером событий в UTM5 для внешних систем. Достаточно ли будет событий, которые можно через него передать, чтобы выполнить интеграцию с IPTVPORTAL, или нужно все же разбираться с базой?
Не совсем понял про разницу юникаст/мультикаст.murano писал(а):Да URFA в принципе не нужна в данном случае. RFW актуален тогда, когда Вы даете клиенту ТВ через unicast. Если используется multicast, тут либо скрипт, который берет данные о тарифных связках из БД и отсылает определенные параметры в middleware, либо (если нет middleware), отсылает параметры на домовые коммутаторы для управления igmp-snooping`ом.LovingFox писал(а): А я к тому и спрашивал, что понять хотел, насколько жестко необходим Urfa или еще чего либо.
А такой вопрос.
Есть демон rfw, который является тригером событий в UTM5 для внешних систем. Достаточно ли будет событий, которые можно через него передать, чтобы выполнить интеграцию с IPTVPORTAL, или нужно все же разбираться с базой?
У абонентов в нашем дизайне сетевой доступ к мультикаст есть ВСЕГДА. Но вот расшифровать мультикаст-контент приставка абонента сможет только в том случае, если она получила актуальные ключи от CAS. Да, абонент сможет послать igmp и получить мультикаст-поток, но без ключей он ему бесполезен. На vlc без ключей от CAS такой поток будет выглядеть как "хрюкающие цветные полоски".
Т.е. функционал "вкл/выкл" для заданного в тарифе у абонента пакета тв-каналов -- это только воздействие на api midleware без воздействия на сетевое оборудование.
В таком варианте, мне кажется, прямого обращения к базе можно избежать и обойтись только тригерами от rfw. Или я не прав?
Вы неправы. RFW всего лишь дает ограниченный функционал - передает в вызываемую программу IP, VLAN и еще некоторые параметры абонента. Он может вызывать любую программу или скрипт, с передачей в нее аргументов в виде некоторых абонентских параметров. Для Middleware Вам надо передавать данные о подключенных услугах, чтобы управлять пакетами подписок на каналы. RFW тут не помощник. Он не способен предоставить информацию об имеющихся тарифных связках, услугах и т.п.
Да, согласен. Посмотрел документацию на RFW -- через него действительно не всю информацию можно получить.murano писал(а):Вы неправы. RFW всего лишь дает ограниченный функционал - передает в вызываемую программу IP, VLAN и еще некоторые параметры абонента. Он может вызывать любую программу или скрипт, с передачей в нее аргументов в виде некоторых абонентских параметров. Для Middleware Вам надо передавать данные о подключенных услугах, чтобы управлять пакетами подписок на каналы. RFW тут не помощник. Он не способен предоставить информацию об имеющихся тарифных связках, услугах и т.п.
Вот тут описание схемы (iptvportal.ru). Агрегатор ТВ-контента будет предоставлять несколько открытых каналов. Но большая часть останется зашифрованной.murano писал(а):На счет шифрования мультикаста - у вас скремблер стоит?
А не лучше ли услуги создавать по принципу <ТВ-Пакет>-<число приставок>, а логины/пароли хранить в тех. параметрах на абонентской связке для подобной услуги?Shiva писал(а):Интегрировать можно добавляя услугу, с логином равным абоненту.
Включение/выключение через rfw, управление подписаками через свою морду или иптвпортал.
Шифрование, я так понял, ares...
-
- Сообщения: 7
- Зарегистрирован: Вт июл 08, 2014 16:53
В биллинге нет смысла хранить логины/пароли к ИПТВ, поскольку их можно извлечь из IPTV-Portal (они там плейнтекстом). Мы просто делаем дополнительную периодическую услугу для каждого ТВ-пакета. Название начинаем с IPTV, а примечание - название пакетв в iptv_portal. И простой скрипт, который по данным из биллинга посылает по событиям запросы в IPTV-Portal.
API там слегка жутенькое - SQL, завернутый в JSON в виде массива массивов массивов, но иптв-портал высылает примеры.
API там слегка жутенькое - SQL, завернутый в JSON в виде массива массивов массивов, но иптв-портал высылает примеры.