netch

Сколько Linksys'ов ни видел - по умолчанию порты были разными, но можно было ставить одинаковый и в итоге работало. В SPA8000 это сломали?

Автомат регистрации должен работать независимо от звонков, так что это просто совпадение по времени. (Хотя мы обучали один UA перерегистрироваться после каждого звонка, но 1) таки после звонка, 2) ему при этом отдавалось сколько денег на счету.) Так что не ищите в этом причину. А вот в поведении агента на 213.133.168.52 я не вижу никакого криминала: он ведь сбросил звонок получив 488, а не отдав 488. Он захотел переключиться на факс, ему отдали отказ, он не знает что дальше делать - нужно ведь факс послать - и посылает BYE, потому что не видит, что дальше делать с этим звонком. Положение RFC о том, что после 488 диалог продолжается - говорит только о логике собственно стека, но не о логике над ним. Действительно, после 488 диалог ещё действует. Но реакция верхнего уровня на событие подобного рода - отказ в переустановлении сессии в нужном виде - может быть ЛЮБОЙ из допустимых, и BYE - совершенно допустимая реакция - не понравилось, разорвали в любой момент. Никакого "лечения" ситуации я тут не вижу, кроме варианта заставить передать тот же факс по G.711, а не T.38.

Зачем нужен бекап-сервер, перестающий быть таковым при выпадании винта? А за углом ещё на 200 дороже, поэтому кто купит здесь - тот лох. Любая система строится из оценки необходимой надёжности. Выпадение винта на таком сервере крайне маловероятно (если явную дрянь не покупать), а одновременно с рабочим сервером - тем более. Зеркало тут может окупиться, а может и нет. Для надёжности лучше держать два винта и заливать чётные/нечётные архивы на них по очереди.

Вообще-то оно такое по умолчанию. И надо явно от этого отказываться. Но по данному треду я понял, что у вас скорее всего материнка чуть кривая и там не работает стандартный ребут через ACPI. Тогда надо попробовать покрутить sysctl'и hw.acpi.disable_on_reboot и hw.acpi.handle_reboot. Почитайте тематические места. Например, ньюсгруппу fido7.ru.unix.bsd. Там несколько раз подымался вопрос качества mpd5, freebsd7 и присутствует один из разработчиков mpd.

Да фишка в том что если мне не отбило мой склероз до конца, то кроме a=sendrecv шлюз никера поддерживать не обязан, поэтому он замутиться может только отсылая свой контакт с нулевым адресом. Читаю RFC3264 - насколько я его понимаю, sendrecv, sendonly и inactive входят в обязательный набор. С устройствами, которые начали разрабатывать ещё во времена SIP1, действительно, может быть дохрена проблем странной совместимости. Документы - это сертификация? Увы, не занимаемся таким, AFAIR. Но если кто-то возьмётся помочь с этим - думаю, вполне можно договориться... по крайней мере я сброшу начальству все предложения такого рода. Не, реинвайт он конечно "какбе" обязателен, но вовсе не факт что он отработает. Девайс обязан по стандарту если он "не может" не менять параметров сессии, и это единственная вещь которую девайсы достаточно исправно выполняют (хотя мне попадались уроды которые с 488 ошибкой дропались, причем что-то из рапространенного). Может не менять, действительно. "An offered stream MAY be rejected in the answer, for any reason." Хотя в нашей практике я мало видел тех, кто действительно так делает (вот из свежих жалоб - ругались про NexTone). Циска ведёт себя своеобразно - если не послал хоть что-то с нового адреса, может не принять его замену. Что такое "референсный стек"? По-моему, такого нет в принципе. А что за финт, я, извините, таки не понял. Можно пример SDP? MEGACO/H.248. Там вроде всего хватает. Плюс, что важно, это жестко централизованый протокол. И всеми важными делами там занимается свитч. А не как в сипе, сначала придумали одноранговую фактически систему, а потом стали изобретать методы как в рамках стандарта от этого избавиться... Там не надо ни от чего избавляться, достаточно просто плюнуть на домены.:)) Честно говоря не углядел там мессагу... Если вкратце, то одна кривая обработка rr по дороге и приплываем так что мало не покажется. Плюс принципиальное отсутствие хантинга из-за чего звонок "размножается" по всем доступным направлениям, а на стыке с ТСОП не факт что "дубликаты" отобьются с правильным cause code, чтобы их в узле где их форкнуло корректно пришибло. Кроме того поддержка rr опять же штука опциональная... То есть в стандарте написано вроде что "должен, но если не умеешь то ничо тебе не будет". Умный хантинг предполагает ещё много чего такого, что не совместимо с идеей прокси. Для этого есть B2BUA. "rr" - это что? Ваши сокращения мне всё-таки в заметной мере непонятны.

На не то чтобы пессимистичен, реалистичен. Кривого оборудования - каждая первая железка... А клиент себе норовит купить всегда покривее, потому-что подешевше. Это да. Но тем не менее ситуация уже значительно лучше, чем была года три назад. И вообще такая ситуация с любой технологией. С email было когда-то не лучше.;) Тем более что для SIP очень много делается для исправления - см. хотя бы RFC по torture tests, а также конференции SipIT, на которых проводятся живые тесты совместимости. Знаю, встречали, но с audiocodes MP-202. Более того, оно рядом написало "a=ptime:20" и "a=ptime:0", и сиди понимай как хочешь. Пришлось в конфиге его заменить, благо там был SER и это решалось тривиально. Да, это часто. Сегодня вот лог от snom320 подсунули - там в таком же месте URL не в <>, синтаксический разборщик это не всосал ибо не должен. А почему Вы считаете, что это неправильно (я про mute)? По-моему, это единственный нормальный вариант. Из контакта вообще-то себя нельзя убирать в принципе. Если устройство не умеет свой MOH, значит, оно должно просто показать холд (любым из методов - a=sendonly, a=inactive, c=0.0.0.0), а дальше дело свича это отработать. В случае PSTN АТС ведь MOH генерирует станция? Так пусть свич это и делает, незачем на телефон сваливать, у него и так проблем достаточно. А зачем быть девелопером своего свича-то? Вот ставим операторам, те могут загрузить по вкусу MOH для юзеров и дальше он будет играть - тот, который назначен для того, что на холд поставили. Они сами в основном ничего не девелопят, только используют:) Это какие два метода? re-INVITE + UPDATE? второй да, необязателен, а первый вполне обязателен (см. RFC3264). Но UPDATE имеет смысл только при PRACK, а сам по себе PRACK это всё-таки достаточно угловой (jIMHO) случай. Вот именно что Вы пессимист. Стар или нет, но этот стакан у Вас уже всегда наполовину пуст. Я тоже уже далеко не вьюноша, но вижу, что 1) процессы таки идут, и на улучшение, 2) есть давление рынка, которое всё-таки приведёт всех ко вполне вменяемому результату. SIP безусловно не идеал (и граблей в нём дофига), но он перспективен, и сейчас это важнее. (В отличие от, например, IPv6, который и слишком крив, и бесперспективен.) Я уже четыре года вожусь с SIP. Раньше было хуже. Раньше, например, кроме Sipura вменяемых юзерских UA не было в принципе. Сейчас и та Sipura в виде Linksys деградировала, и конкуренты подросли, так что есть что выбирать. Нет никакого "пассажира" который это сделал сам по себе. Есть требования времени: 1. Должен быть стандарт IP-телефонии для Internet как единственного общего транспорта. 2. IETF должен его поддерживать и направлять. 3. Это не может быть H.323 из-за его закрытости и недоговорённости (есть масса проблем совместимости из-за недосказанностей и особенно из-за нечеловеческого стиля описания). 4. IAX ещё не было. MGCP слаб и не очень расширяем. Что остаётся? Вот выбор HTTP в качестве стилевой базы - мягко говоря, не лучшее решение. Но это IETF, и он иначе пойти (к сожалению) не мог. Расстреляете весь IETF? Про конференции промолчу, не возился. А про рутинг - я в соседней ветке высказался предметно, Вы так и не сказали, что именно не нравится.

Вот потому REFER должен отрабатывать свитч оператора. Что и делаем. Ну после того как я писал реализацию трансферов обоих основных видов в свиче - может, и могу иронизировать?;)) С MOH как раз проблем практически нет - его можно (при разумном ограничении по поддерживаемым кодекам) сделать на весь трансфер, или до того, как вызываемый начал отдавать ringback, или ещё как-то похоже. Из наблюдаемых - основные проблемы вызывает call leg recombination в случае зрячего трансфера, когда стороны изначально договорились на совсем разные кодеки. Вот тут приходится извращаться - заставлять их передоговариваться, и если некоторые не умеют (или вообще дропают звонок нафиг по re-INVITE) - суши вёсла. Но это как бы обоснованный риск. Вы слишком пессимистичны и, судя по всему, работали с самым паршивым оборудованием, какое только досталось:) По моему впечатлению, чем больше производитель кичится своим брэндом - тем паршивее у него реализация. Сколько ещё это будет продолжаться - не знаю, но не один год.

ну а почему не просто в конфиге это описать? if (условие) { sl_send_reply("500", "net, tebya ne vidno"); break; };

Раз это аташка (телефон подключается) - попробуйте перебрать вертикальные коды (звёздочка и две цифры) по какому-то из известных стандартов (обычный Centrex, ATA186, что-то иное). И всё-таки - речь про call forwarding или call transfer?

А может быть расскажете конкретно, чем Вам не по вкусу методы трансферов SIP? (последняя надежда;))

Я вот тоже могу вспомнить, как у нас дважды UMC (местные сотовики, ныне часть МТС) не могла прийти в себя, несмотря на то, что никакого землетрясения не было - потому что у них (jIMHO, они-то не сознаются) мощности были подобраны впритык и ажиотажа не выдерживали в принципе. А с другой стороны - как на строительстве станции метро "Демеевская" упал кран и улицу растянуло сантиметров на 20, порвало часть телефонии и водопровод, но сотовая связь работала. И о чём это говорит, кроме как о наличии примера противоположного результата? Вы сами чуть подумайте:) - как землетрясение может влиять на сотовую связь? Что, от этого эфир сдвинулся?;)) Нет, видимо, где-то кабель порвали. Почему порвали - потому что запаса не было, был натянут сильно, или же в каналы пропихнут куда он еле залазил и притёрся. И при чём тут GSM и VoIP?;))

Вы простите о чем ? Об voip или все таки о sip ? Почувствуйте разницу ;) Чувствую. У Голдена - как правило, H.323. А вот у Оптимы телефоны взяли по SIP (это нам удобнее - им самим пофиг, они и ашкой оддадут). Ну и в чём разница, если и то и то работает, но SIP с более человеческим лицом в плане поиска проблем? Это простите где на Украине ? А ну понятно.... В России этого в разы больше. У нас уже и блокираторы с трудом найдёшь, и кабеля высушены. А Вы расскажите, пожалуйста, как обстоит с проводной связью где-нибудь в вятской глубинке.:)) В 19-м барышни сидели на коммутаторах:) Нет, я про связь exUSSR образца 1990 года, которая местами сохранилась до сих пор, и чем меньше НП, тем такое вероятнее. Во "всеобщий праздник" - например, 31 декабря в 23:55 - проводная уже не работает, перегружена. Про катаклизмы лучше для обоих видов не вспоминать - при них никакие расчёты уровня загрузки спокойного времени, даже с трёхкратным запасом, не работают, и картина будет телефонным эквивалентом выезда из города в пятницу в 18:00.

А Вы пробовали его вживую? Мы пробовали их powerline серию, впечатление не лучшее: 1. В одной PDP'шке два устройства между собой - 55 Mb/s. В соседних где одна включена в другую - уже 30Mb/s. В разных стойках, но с одного UPS - 7Mb/s. Это всё в одну сторону, два потока навстречу - почти удваивается. Вывод - скорость зависит не столько от расстояния, сколько от количества развилок проводов. Каждая развилка - сигнал делится пополам - скорость заметно падает. Состроить на реальные 100Mb/s в одну сторону мы их не смогли даже на стенде - я уж и не представляю себе, как этого добиться. 2. Не развязаны физически линии собственно питания и линии данных (в отличие от моторолы, у которой всего 14Mb/s и организация звезды), в результате получаются странные эффекты: надо настроить каждое устройство на свой IP и дать свой пароль, чтобы исключить взаимовлияние. Мы этого при настройке сначала не сделали и получили офигенный результат: настраиваемое устройство пропустило пакеты на него же в электросеть, в результате половина настройки досталась ближайшему устройству, а половина - соседнему... потом чтобы разобраться в этой каше - пришлось сажать каждое устройство по отдельности в свою ветку питания, там ему выставлять недефолтные параметры и только тогда выпускать в нормальную сеть. Понятно, что это требует очень качественного фильтра питания или даже on-line UPS - штука в общем дорогая. Вот модель защиты у него неплохая - сильно напоминает WiFi - название сети и пароль. Если они сделали в работе по кабелю ту же логику, что на электричестве - оно сильно хорошо не будет.

+10. Мир всеобщей халтуры. Все стремяться снять с себя ответственность любой ценой. Если честно, то из всех видов голосовой связи, обычная проводная тел. связь - самая надёжная из доступных обычному пользователю. Пока. Дальше будет хуже. Простите, я буду немного неконструктивен.:)) Вы про какую "обычную проводную телефонную связь" говорите? Если реальную - то описывайте её уже полностью, а именно: - 90% сёл и деревень с одним телефоном на всю деревню в сельсовете (и хорошо, если сельсовет есть) - с блокираторами, АВУ и прочей хренью в городе - с колодцами, которые уже 20 лет залиты, мокрыми кабелями, по которым слышны все разговоры соседей, а радио играет громче, чем собеседник - "Саратов!!! Алло, Саратов!!!" - "А что, по телефону нельзя позвонить?" хватит ужасов. Если бы она была реально всем доступна - я бы ещё как-то согласился. Но сейчас (я не пишу для тех, у кого за МКАД жизни нет) сотовики достигли уже того, что в любом селе на огороде копается бабулька, а в кармане у неё - телефон, с которого она может позвонить внуку (который ей этот телефон и купил) - помните анекдот "Де блютуз, ***?" из которого Евросеть себе слоган сделала? А проводники за линию хотят денег больше, чем вся улица стоит. И пока оно так - я за такую "халтуру".

Может, в Вашей деревне оно и так. В нашей (маленькая такая на 5 миллионов фактического населения, Киевом называется) картина следующая: многие операторы давно уже продают телефоны не по проводу, а по IP (особенно - по своим же IP каналам). Такие, как Голден, часто продают смесь из 1-2 проводных телефонов на офис, а далее - добирать по IP, и дают офисные станции заточенные под такую смесь. Всё это сочетается ещё и с гибкой политикой выхода на дальние направления (у Голдена сейчас есть два разных варианта с разными префиксами; а к тому же через обычную междугородку уже можно ходить через разных операторов, вводя для них свои префиксы). По отзывам, результат вполне приличный - бОльшую часть времени с IP транспортом проблем нет, а если есть - всегда остаётся резерв в виде проводных телефонов (которые к тому же работают даже при пропадании местного электричества). Я таких страшилок тоже могу вагон рассказать, особенно когда я в местном интеграторе участвовал в кормлении потребителей решениями на основе всяких Cisco Call Manager. В которых никто не понимал нихрена включая местное представительство (нет, оно, конечно, могло перевести на русский документацию и даже вспомнить пару типичных граблей;)) Но о чём это говорит, кроме кривости отдельных решений и неорганизованности вендоров?