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. В которых никто не понимал нихрена включая местное представительство (нет, оно, конечно, могло перевести на русский документацию и даже вспомнить пару типичных граблей;)) Но о чём это говорит, кроме кривости отдельных решений и неорганизованности вендоров?

А может сделать лукап целевого номера в зоне e164.arpa и получить подробный ответ, куда направлять звонок по тому же SIP не заморачиваясь транзитом через "цепочку операторов у которых существуют договорные отношения и настроена маршрутизация в соответствии с ними". это уже действительно работает? тогда договора между операторами не так уж и важны гм судя по различным мнениям придется видимо самому тестировать Это работает, но в каждой стране относятся к этому по-своему. Ни Украина ни Россия, например, вообще не забрали свой индекс. Многие европейские - забрали и позволяют операторам - владельцам блоков администрировать по своему вкусу, то есть в итоге это сводится к тому, что абонент может на вебе оператора задать SIP URL для своего телефона и самому далее решать последствия того, что к нему пойдут звонки. Операторы также могут задавать подобное для целых блоков, указывая входные ворота своих софтсвичей, но из-за необходимости тратиться на входящие звонки этого не делают, потому что приём любого звонка откуда угодно без договора будет давать только убытки без компенсации. Так что операторы сами для себя такое не строят. По-моему, оно на операторский обмен и не предназначалось.

То есть, ни Пастернака, ни RFC3263 Вы не читали, зато "как мать и как женщина" успешно осуждаете то, чего не знаете. И что для SIP штатно предусмотрена и схема поиска сервиса значительно гибче чем "mx записи с приоритетами", и процесс перебора адекватно описан включая контроль "живой вообще или нет", не знаете. Что ж, спасибо, Ваш уровень понятен. Во-первых, не надо вспоминать про то что "во второй ревизии" что-то делали - как известно, любая разработка становится адекватной только с условной версии 3.0, как с RFC3261-3265 и получилось (которая появилась аж в 2002, пора бы и забыть, что было до всемирного потопа). Во-вторых, прокси и регистрации - адекватный способ не заморачиваться каждому с собственным доменом (что было бы уже полнейшей глупостью) и при этом обеспечить гибкость работы и роуминг. Когда надо передавать специфику SS7 - да, можно и так (но не всегда это лучший метод). Тем не менее, если не заморачиваться SS7, а использовать то, что нужно клиентам, а не промежуточным станциям - вся эта байда становится ненужной. И правильно работать именно так. Если Вам вдруг нужно транзитить SS7 - лучше возьмите H.323 или вообще напрямую SS7-over-IP, на это тоже есть стандарт, и не пытайтесь заставить легковой автомобиль везти на своей спине Боинг-747. SIP подчиняется общим тенденциям сетей с коммутацией пакетов. Мне тоже не нравится, что IntServ умер не сумев выйти за пределы академических реализаций. Тем не менее DiffServ, если его грамотно провести через сеть, работает без насилия и безумных затрат. И оказывается, что прискорбно, в разы дешевле, чем IntServ и тем более сети с коммутацией каналов. Я подозреваю, что тут какой-то мировой заговор:)) Так кто заставлял-то именно так натягивать? А лучше 3) когда не будут пытаться его использовать для того, для чего его не надо использовать - а именно, для связи придуманных под другие стандарты узлов. А вместо этого будет эволюционный процесс перевода на SIP всё более близких к конечному пользователю частей.

Никто её не закопал. Она есть и никуда не уходит, но именно её нецентрализуемость и неканализируемость препятствует глобально видимым решениям, а также прямому переносу проводной телефонии на неё. Именно поэтому Вы её не видите. Переходные же формы существуют уже сейчас. В софтсвиче, который я писал, сейчас добавляется возможность форварда на произвольный SIP URL. В некоторых других это уже сделано. Таким образом, абонент получает в качестве основного идентификатора глобальный телефонный номер, но не ограничен им в выборе метода приёма звонка. И, разумеется, в качестве клиентского терминала должна быть не ATA186 или SPA2000, а нечто более разумное. Барыги-то тут при чём? А может сделать лукап целевого номера в зоне e164.arpa и получить подробный ответ, куда направлять звонок по тому же SIP не заморачиваясь транзитом через "цепочку операторов у которых существуют договорные отношения и настроена маршрутизация в соответствии с ними". А можно подробнее? Много лет с ним работал, никакой "такой жопы" не замечал. Может, Вам неудачная реализация попалась? Точно неудачная реализация. Вероятно, кто-то просто настроил какой-нибудь SER 0.8 в режим одновременного звонка по разным направлениям и успокоился. Не надо по ней делать выводы о всей технологии. У нас для случая нескольких операторов к одному и тому же пункту назначения существуют 1) skipping hunt mode, при котором перебор операторов идёт последовательно, а коды ответа делятся на те, которые означают отказ по дороге, и те, которые обозначают отказ от собственно вызываемого абонента, 2) рандомизация порядка перебора таких операторов, 3) управляемые таймауты ожидания ответа от оператора, 4) контроль их доступности и временное исключение из попыток доступа при недоступности. Всё это вместе даёт адекватную работу. Да, естественно, наличие всяких H.323 по дороге - ничего не портит, при правильно подобранной трансляции кодов отказа. Так что - "Вы просто не умеете их готовить"

Слишком бурный тред получился, попробую сформулировать конструктивный ответ покомпактнее. Технически это выглядит так. Для sip2.name выясняется, куда именно посылать первичный запрос. Этот процесс описан в RFC3263 и состоит из пачки запросов DNS: NAPTR - чтобы определить приоритеты транспортов; SRV - чтобы для каждого транспорта определить имена серверов; A - чтобы по именам определить адреса серверов. Затем посылается запрос INVITE с указанием вызываемого (URL <sip:abon2@sip2.name>). В ответ на INVITE может прийти согласие, отказ или переадресация на другой URL (при которой процесс может повторяться с самого начала). При согласии, одновременно согласовывается голосовой транспорт (кодеки, порты, детализация параметров). Процесс можно упростить, не прописывая NAPTR и/или SRV, если не нужна предельная гибкость настройки. В результате, действительно получается возможность каждого позвонить каждому, зная его SIP URL, который в свою очередь привязан к DNS и потому позволяет значительно более гибко управлять своими контактами не залагаясь на телефонное номерное пространство. Далее на эту схему могут налагаться ограничения (например, вызываемый использует фильтр, требует авторизации, подписи вызывающего, etc.) - это уже уровень наворотов. Многие сейчас штатно реализуют возможность позвонить им по SIP URL точно так же, как по публично анонсированному номеру телефона. Часто используется упрощённая схема, в которой домен игнорируется, соответственно поиск вызываемого через DNS не производится, у конечного абонента прописан один прокси, через который и идёт всё внешнее общение. Это "телефонная" реализация, в том смысле, что обычно username соответствует номеру телефона (в глобальном, национальном или локальном представлении). Насколько я понял, ram_scan защищает именно её, сильно и IMO несправедливо критикуя многодоменную схему. Я участвовал в разработке софтсвича под "телефонную" схему, она действительно проще, но распределение номеров через стандартные телефонистские структуры может создавать проблемы (и ограничение цифровыми последовательностями - тем более). "Телефонная" схема характерна именно направленной канализацией звонков - проще контролировать разговоры абонента, к тому же некоторые технические проблемы вроде NAT значительно проще решить при наличии прокси. Многодоменная схема, наоборот, ближе к духу Internet - каждый имеет право в своём домене настроить что хочешь и получать куда хочешь. Не всегда минуя - тот же вопрос NAT решается часто только через сервера. Но сервер может вместо этого и дать переадресацию. Как уже сказал, в многодоменной схеме "бабло за разговор" не обязательно берётся. Впрочем, и в телефонной ничто не мешает договориться о другом канале связи и перейти на него:)

Через патчпанели разводится одножильный ("монтажный") кабель, а для патчкорда - многожильный. Если у Вас одножильный - то он штатно разводится через патчпанели независимо от категории. Есть специальные разъёмы для такого случая, но это всё-таки изврат и должно применяться только при отсутствии другого решения.

Ну почему же другой. Во-первых, можно по-разному отвечать. Например, первая/вторая линия знает, что "маска сети - параметр из четырёх чисел через точку, который вводится в параметрах сетевого адаптера вместе с адресом в сети" (точные формулировки уточняются по ближайшей Windows), а какой его смысл как именно битовой маски - ему ещё знать не следует (а кормить юзера - тем более). Ну а во-вторых, если юзер хочет подробностей - можно и в справочник посмотреть и процитировать (даже без понимания) смысловой текст. Смысл в этом как раз есть - потому что помогает решать ситуации типа "сосед сказал, что у меня маска сети кривая, что это такое и зачем? почему он так говорит?" - 99%, думаю, объяснения с указанием на конкретное диалоговое окно удовлетворят полностью (раз после этого завелось). Вообще, составление планов-схем решения вопросов для поддержки - действительно серьёзная задача и порой высокое искусство (там, где надо нарисовать такие формулировки, чтобы те, кто сам не знает деталей и подводных камней, и дальше не догадывались про них). А с другой стороны надо, чтобы тот, кто действительно понимает или имеет нестандартные проблемы, был не послан далеко нахрен, а обслужен (пусть даже третьей-четвёртой линией) и чтобы опыт такого обслуживания был в итоге применён. Есть две типичные ошибки реализации такой поддержки: 1) первая-вторая линия умирают на месте в окопах, но не сдаются, результаты же их обороны никуда дальше не идут и про проблему можно узнать чисто случайно 2) первая-вторая линия действуют жёстко по плану, не предусматривающему ничего за пределами 95% штатных ситуаций Вторая приводит к диалогу вида - У меня нет кнопки Пуск, у меня FreeBSD+XOrg+Windowmaker - Хорошо, когда включите компьютер - перезвоните (при этом саппортер ещё и доволен собой - как же, выставил клиента лохом не говоря ему это напрямую) Первая приводит к ситуации вида (реальность одного нашего местного Оператора, 2001-й год): связь с Москвой на 10Мб/с (по тем временам зверски круто) 5-ю параллельными E1 через кошку, раскидывающую пакетики примерно поровну. Начинает глючить первая E1. Потери порядка 2-3%. Саппорт начинает принимать звонки о проблеме. Но - "ни пяди родной земли оккупантам!" и инженеры ничего не знают. Проходит пара дней. Начинает подыхать вторая E1. Потери порядка 5%. Картина с саппортом не меняется. Ещё пара дней. Первая отсыхает почти полностью. Потери доходят процентов до 15. Саппорт дохнет на месте, но не сдаётся. Инженеры в блаженном неведении. Дохнет дальше. Уже процентов 20. Наконец Очень Важный Клиент рявкает лично генеральному. Тот спускает молнию вниз. Проблемы вылечиваются за пару часов, после чего в местную курилку пишется вопрос: "Ребята, а если канал пошёл сначала FR, потом ATM, потом снова FR, могут ли быть keepalives канального уровня?" Пол-Киева умирает со смеху, ибо в курсах, что Оператор целую неделю фактически не работал. Что-то я растёкся по древу... это уже не про тестирование, но смысл такой - надо владеть ситуацией.;)

Ну киевская Воля-кабель так делает. Когда можно так определить (по первым цифрам). По полному номеру вроде ещё нет. Почему наг.ру ? Почему не "планеты Земля" ? Потому что ты на Бабуине прописан:)

По ITIL и тому подобным нормативам, есть четыре линии поддержки, поднимаемые вопросы относятся скорее ко 2-й (уже техническая, но с общими знаниями) и 3-й (те что уже отвечают не по бумажке). От себя - системного тестирования не проводим (знаю, что зря, но людей мало и в принципе всех знаем в деталях), а вот каверзные вопросы позадавать - это сколько угодно:)) Ну а если бы составлял опрос - то сделал бы вопросы всех уровней. Начиная от "что такое маска сети" до серьёзных запросов типа "опишите последовательность действий диагностики проблемы".

А вот теперь объясните, пожалуйста - может, я чего-то не догоняю. Вот есть городской телефон например 2292222 и есть внутренний 229. Как именно астериск их будет различать в конкретном случае? Ну ладно, не астериск, а UA с диалпланом. По паузе или по '#' в конце? Я с ходу вижу недостатки у любого из этих вариантов достаточные, чтобы не пытаться ставить такое простым пользователям.

Уточните, пожалуйста - речь про втыкаемые в тот же таз digium'овские и аналогичные платы? Ну так на них свет клином не сошёлся - можно отдельные коробки использовать, выбор широкий. Заодно добавится устойчивости от местных перегрузок (digium'овские порты, мягко говоря, сделаны не совсем грамотно). На нормальный бесперебойник, если честно, надо ставить всё:) И "классика" будет без него работать только в младших моделях - тех, у которых в выключенном состоянии внешние линии сцеплены ключами с внутренними. На моей второй работе сплошной voip (как и то что она делает;)), внешний - от телефонного оператора, проблем нет. Не скажу, что это универсальная ситуация, но "очень тяжело", наверно - таки перебор.