On Wed, Dec 09, 2015 at 01:24:07PM +0200, Andrej N. Gritsenko wrote:
Вообще-то это работало по причине плохой настройки АОН на АТС - согласно спецификации, этот запрос (тональные частоты 4+6) должен отправляться в интервале 0.1...0.2 секунды от момента установления соединения, а на 0.5 секунды разговорный тракт клиента должен быть отключен. Это всё согласно спецификации, т.е. это вот самое "пропищать определенным тоном" не имело права попасть на аппаратуру АОН на АТС и, соответственно, работать никак не должно было. Но работало иногда, благодаря багам (были они случайные или специально организованные как "отдельная услуга за деньги" - уже не существенно). Система АОН использовала специфический DTMF, совсем не то, что использовалось в зарубежных АТС, потому ни о какой совместимости с caller-id речи даже не шло, особенно учитывая, что в разных странах были разные реализации caller-id - местами DTMF, а больше разные вариации на тему FSK. Так что забудьте про АОН, если читаете про caller-id. Равно как и наоборот. Это я вам как связист со стажем говорю. окей, показался большой дядька. давно не виделись ;-) теперь ещё раз. стенд для воспроизведения факапа спокойно воспроизводится в здании, в которое вообще ничего, кроме питания и оптики, не заходит. забудьте про местные АТС.
есть забугорная железка, в которой много чего на caller-id повязано. есть обоснованное бредположение, что в каком-то виде этот caller-id в ней работает. она воткнута в cisco spa112 (по сути, неудачный выкидыш linksys'ных voip fxs шлюзов). spa112 с астериски номер видит верно, но сквозь rj11 до требуемой железяки эта информация уже не просачивается. вопрос в том, по какой методике рыться дальше mbr, -- Igor "CacoDem0n" Grabin