morfair

И всё-таки я подтянул Kamailio к своей этой задаче. Прямо перед отправкой в под-роутер DISPATCH (dispatcher на FreeSWITCH) сделал вот такой приём: if ( is_method("INVITE") ) { # https://kamailio.org/docs/modules/3.3.x/modules_k/cfgutils.html#idp1794224 $var(delay) = ($RANDOM / 1048576 * 1000); # 2 ** 20 = 2048 #xlog("L_DBG","INVITE SLEEP: $var(delay)\n"); sl_send_reply("100", "Trying, sleep $var(delay)"); t_set_auto_inv_100(0); # turn off automatic 100 replies usleep("$var(delay)"); # waits "time" micro-seconds. } И ситуация стала намного лучше!! Т.е. я придерживаю INVITE перед проксированием на рандомное время в 0 до 2000 мс и CPS у меня как-то размазываются. Но у меня серьезный вопрос!! Функция usleep() в Kamailio блокирующая или нет? Т.е. у меня весь children тупо висит в бесконечном цикле указанное кол-во micro-seconds, или способен выполнять работу по другим соединениям??

А есть пример такого прокси?

У него есть https://vk.com/a1ex_eri

Уже пробовал сделать DROP'ами, т.к. рассуждал, что UDP, всё равно еще пакет пришлет... В итоге стали жаловаться клиенты, что долго тишина в трубке, потом сброс.

Други, подскажите как сделать. Есть входящие пакеты определенного типа, конкретно SIP INVITE. Их я могу выцепить iptables'ом. Нюанс в том, что они прилетают кучей, к примеру сразу штук 20, а потом тишина. Получается 20 pps. А мне надо получить 5 pps, не прибегаю к дропу пакетов, а лишь придержав их через lanetcy, т.е. обработать за 4 секунды. Как такое реализовать в Linux?

Здравствуйте! Коммутатор DES-3200-18 (fw: 1.88.B006). На него в теге на порт 17 приходит VLAN 1234 с мультикастом для IPTV. С него же с порта 5 включен коммутатор ZyXel (там тоже настроен MVR). Проблема в том, что если STB (IPTV-плеер) включен напрямую в DES-3200-18, то всё работает (IGMP Join, Report на продление, Leave), а вот если STP включен в ZyXel, то DES-3200-18 не пропускает с него Report на продление, а лишь Join и Leave. Таким образом видео показывается лишь пять минут и перестает. В чем проблема, почему DES-3200 не пропускает IGMP Report'ы (кроме Join и Leave) с нижестоящего ZyXel? С ZyXel'я они на порт 5 D-Link'а приходят (проверил зеркалом), а на уходе, на порту 17 - нет. enable igmp_snooping create igmp_snooping multicast_vlan iptv_milticast 1234 config igmp_snooping multicast_vlan iptv_milticast state enable config igmp_snooping multicast_vlan iptv_milticast add member_port 4,10-12,15 config igmp_snooping multicast_vlan iptv_milticast add tag_member_port 5 config igmp_snooping multicast_vlan iptv_milticast add source_port 17 config igmp_snooping multicast_vlan_group iptv_milticast add 224.0.0.0-239.255.255.config igmp_snooping vlan_name default state disable fast_leave disable report_suppression disable config igmp_snooping data_driven_learning vlan_name default aged_out disable config igmp_snooping vlan_name iptv_milticast fast_leave enable report_suppression disable config igmp_snooping data_driven_learning vlan_name iptv_milticast aged_out disable Кросслинк: http://forum.dlink.ru/posting.php?mode=edit&f=2&p=961443

Примерно так: D-Link: rad_recv: Access-Request packet from host 10.90.68.90 port 1033, id=23, length=96 User-Name = "1C7508058FDC" User-Password = "1C7508058FDC" NAS-IP-Address = 10.90.68.90 NAS-Identifier = "D-Link" NAS-Port-Type = Virtual Service-Type = Framed-User Framed-Protocol = PPP NAS-Port = 1 Framed-IP-Address = 239.37.239.5 ZyXel: rad_recv: Access-Request packet from host 10.90.68.81 port 1026, id=10, length=141 User-Name = "1c7508058fdc" User-Password = "1c7508058fdc" Service-Type = Framed-User NAS-Port-Type = Virtual Called-Station-Id = "B0-B2-DC-B2-7B-B6" NAS-IP-Address = 10.90.68.81 NAS-Port = 2 Calling-Station-Id = "1C-75-08-05-8F-DC" Framed-IP-Address = 192.168.7.97 NAS-Port-Id = "VLAN65/239.37.239.9" Как шифруете и расшифровываете, если не секрет? Поддержка со со стороны Middleware нужна? Мало наглядной инфы гуглится по этому поводу.

спасибо! а мы буквально только что раскопали igmp radius auth, будем через радиус пробовать. Работает, железобетонно. Ага, у нас только и длинки, и зухели, разные реквесты они шлют, к сожалению( Надо разруливать

спасибо! а мы буквально только что раскопали igmp radius auth, будем через радиус пробовать.

А после подключения тестовой пачки юзеров загрустил от нагрузки на аплинки... Курю мультикаст и ограничение доступа к оному. Вопросов как всегда больше чем ответов. Настроил MVR на центральном свитче. А как тащить дальше? Так же MVR везде настраивать? А как быть со свитчами типа DES-2108, которые так не умеют? Не придумали как защитить доступ к мультикасту?

Скажите, а откуда брать ПЕРВЫЙ HD, Россия HD? Это же вроде государственные каналы, их потока нет в свободном доступе?

Ребят, только вникаю в эту тему, объясните, пож. Есть поток, который идет мультикастом в MPTS. Хотим заюзать Stalker Middleware. Есть два основополагающих вопроса. Конечные устройства будут брать поток с севрера со Stalker'ом, или надо как-то маршрутизировать тот самый мультикаст до клиентов? И если второе - а как тогда отключать клиента?

в пятницу прошлую карбон обновился пока обновлялся 2 минуты - 180 пропусков, а так 5-10. А должен бы быть ноль!!)

/etc/freeradius/sites-enabled, в apache-стиле сделан в дебиане, где лежит конфиг с логикой (порядком) работы.

С FreeRADIUS'ом всё просто. Быстренько пробегаетесь по radiusd.conf, потом в clients.conf прописываете nas'ы, localhost уставляете, затем более осознанно настраиваете sql.conf, и в site-enables (в debian style etc) убираете почти всё, кроме pap, chap, sql. Готово.