Тема: TDE100 + V-SIPEXT32 + PAP2T
Уважаемые гуру, задаю вопрос пока без логов/трассеров и т.п., может, есть готовый ответ. Если отсутствует - буду собирать необходимую информацию.
Клиент с VoIP-шлюза регистрируется на панасе. Настройки платы/портов в панасонике и на шлюзе по умолчанию. Сеть между станцией и шлюзом - полный VPN с маршрутизацией, т.е. они в разных подсетях, но видят друг друга без всяких NAT-ов во все стороны. Регистрация проходит нормально, звонки ходят в обе стороны, о частностях настройки в других темах.
Так вот, если в момент полной работоспособности разорвется VPN (иногда такое случается), то следующая попытка регистрации на шлюзе выглядит как Can’t connect to login server, на другом шлюзе (SPA8000) просто Failed. При этом шлюз из подсети станции виден нормально, станция из подсети шлюза - тоже. И после этого не помогает даже полное выключение шлюза, и найдено только одно решение - нужно в настройках каждой линии на шлюзе поменять SIP-порт (например, 5060 на 5070). После этого регистрация проходит хорошо, звонки опять ходят, все довольны до следующего падения VPN. При следующем падении можно писать обратно 5060 - все снова будет работать.
Вопрос - есть ли какой-нибудь солюшн по данному поводу, или я один с таким столкнулся?
Уважаемые гуру, задаю вопрос пока без логов/трассеров и т.п., может, есть готовый ответ. Если отсутствует - буду собирать необходимую информацию.
Клиент с VoIP-шлюза регистрируется на панасе. Настройки платы/портов в панасонике и на шлюзе по умолчанию. Сеть между станцией и шлюзом - полный VPN с маршрутизацией, т.е. они в разных подсетях, но видят друг друга без всяких NAT-ов во все стороны. Регистрация проходит нормально, звонки ходят в обе стороны, о частностях настройки в других темах.
Так вот, если в момент полной работоспособности разорвется VPN (иногда такое случается), то следующая попытка регистрации на шлюзе выглядит как Can’t connect to login server, на другом шлюзе (SPA8000) просто Failed. При этом шлюз из подсети станции виден нормально, станция из подсети шлюза - тоже. И после этого не помогает даже полное выключение шлюза, и найдено только одно решение - нужно в настройках каждой линии на шлюзе поменять SIP-порт (например, 5060 на 5070). После этого регистрация проходит хорошо, звонки опять ходят, все довольны до следующего падения VPN. При следующем падении можно писать обратно 5060 - все снова будет работать.
Вопрос - есть ли какой-нибудь солюшн по данному поводу, или я один с таким столкнулся?
Интересная проблема. Не сталкивался ни разу с такой. Думаю на каналообразующее оборудование. Без VPN попробуй, а линк обрывать физически. Ну и ещё - коли шлюз другой заюзать, то будет ли окаянная ситуация развиваться по-иному?
картинку Status линксиса можно увидеть?
картинку Status линксиса можно увидеть?
Как только вылезет - пришлю.
На SPA8000 у меня есть неиспользуемый порт, для эксперимента поднял астериск и подключил этот порт к астеру. Так вот, у меня на всех портах с панасоником следующая регистрация происходит через 300s, а с астером через 3600. Посмотрел - в астериске действительно стоит Register time max 3600, на панасонике в настройке платы V-SIPEXT32 - 320s. Изменил время в настройках платы на 3600, перезагрузил станцию - все равно к панасонику коннектятся через 300s. Но мой VPN поднимается хоть и медленно, но не 5 минут все-таки.
Уважаемые гуру, задаю вопрос пока без логов/трассеров и т.п., может, есть готовый ответ. Если отсутствует - буду собирать необходимую информацию.
Клиент с VoIP-шлюза регистрируется на панасе. Настройки платы/портов в панасонике и на шлюзе по умолчанию. Сеть между станцией и шлюзом - полный VPN с маршрутизацией, т.е. они в разных подсетях, но видят друг друга без всяких NAT-ов во все стороны. Регистрация проходит нормально, звонки ходят в обе стороны, о частностях настройки в других темах.
Так вот, если в момент полной работоспособности разорвется VPN (иногда такое случается), то следующая попытка регистрации на шлюзе выглядит как Can’t connect to login server, на другом шлюзе (SPA8000) просто Failed. При этом шлюз из подсети станции виден нормально, станция из подсети шлюза - тоже. И после этого не помогает даже полное выключение шлюза, и найдено только одно решение - нужно в настройках каждой линии на шлюзе поменять SIP-порт (например, 5060 на 5070). После этого регистрация проходит хорошо, звонки опять ходят, все довольны до следующего падения VPN. При следующем падении можно писать обратно 5060 - все снова будет работать.
Вопрос - есть ли какой-нибудь солюшн по данному поводу, или я один с таким столкнулся?
Интересная проблема. Не сталкивался ни разу с такой. Думаю на каналообразующее оборудование. Без VPN попробуй, а линк обрывать физически. Ну и ещё - коли шлюз другой заюзать, то будет ли окаянная ситуация развиваться по-иному?
Если заюзать D-Link - работает стабильнее, отключается реже, но если отключится - нужно подержать шлюз выключенным более 5 минут, тогда заработает. А с линксисами даже 20 минут отключения не помогает.
Собственно, я сюда пишу потому, что люди говорят о том, что реализация SIP в панасониках не славится прямотой, и советуют искать причину именно в нем.
Да, забыл сказать, прошивка панасоника - 4.20.
Каналы низкого уровня приличные, от Петерстара, оптика или WBA. VPN организован, конечно, на роутерах SOHO с DD-WRT, но кроме VoIP там еще используется удаленный рабочий стол, так вот он стабильно поднимается после обрыва сразу же.
Собственно, я сюда пишу потому, что люди говорят о том, что реализация SIP в панасониках не славится прямотой, и советуют искать причину именно в нем.
Да, забыл сказать, прошивка панасоника - 4.20.
Те люди, которые разбираются в SIP Панасоника, такого не скажут. А те, кто говорит про кривоту - скорее всего смотрят через призму своих ручек. Панас просто жёстко придерживается RFC. И если Астериск может “закрыть глаза” на некоторые ошибки в протоколе, то Панас их не допускает обычно.
Собственно, я сюда пишу потому, что люди говорят о том, что реализация SIP в панасониках не славится прямотой, и советуют искать причину именно в нем.
Да, забыл сказать, прошивка панасоника - 4.20.
Те люди, которые разбираются в SIP Панасоника, такого не скажут. А те, кто говорит про кривоту - скорее всего смотрят через призму своих ручек. Панас просто жёстко придерживается RFC. И если Астериск может “закрыть глаза” на некоторые ошибки в протоколе, то Панас их не допускает обычно.
ОК, я не собираюсь тут холивар начинать, я в панасоник верю, и станции у меня все именно панасоник, но проблема есть, и ее надо решать 😉
Как только вылезет - пришлю.
Вы когда всё живое пришлите для начала
Собственно, я сюда пишу потому, что люди говорят о том, что реализация SIP в панасониках не славится прямотой, и советуют искать причину именно в нем.
Да, забыл сказать, прошивка панасоника - 4.20.
Те люди, которые разбираются в SIP Панасоника, такого не скажут. А те, кто говорит про кривоту - скорее всего смотрят через призму своих ручек. Панас просто жёстко придерживается RFC. И если Астериск может “закрыть глаза” на некоторые ошибки в протоколе, то Панас их не допускает обычно.
ОК, я не собираюсь тут холивар начинать, я в панасоник верю, и станции у меня все именно панасоник, но проблема есть, и ее надо решать 😉
Я подобный вопрос решал только как АУ - через японский суппорт Панасоника. И они в моём случае таки заметили, что ПО, с которым у меня были проблемы, шлёт на панас запрос примерно такого вида ...,>, а по RFC положено ....>, из-за этого Панас футболил запросы на регистрацию этого ПО (SIP-факс), а Астериск, например, косячный запрос “прощал” и разрешал регистрацию. Я твою проблему пока не понял - думать над ней надо, а мозг и так устаёт на работе. И пишу всё это к тому, что надо долго и нудно анализировать логи. Или воспользоваться услугами ТЦ, через которых оказывается официальная техподдержка АТС Панасоник. Понятно, что работникам надо платить зарплату, и эти услуги будут небесплатными. В случае по моей проблеме мы поставляли клиенту АТС и услуги по первоначальной настройке, так что решение для клиента не стоило дополнительных денег.
Собственно, я сюда пишу потому, что люди говорят о том, что реализация SIP в панасониках не славится прямотой, и советуют искать причину именно в нем.
Да, забыл сказать, прошивка панасоника - 4.20.
Те люди, которые разбираются в SIP Панасоника, такого не скажут. А те, кто говорит про кривоту - скорее всего смотрят через призму своих ручек. Панас просто жёстко придерживается RFC. И если Астериск может “закрыть глаза” на некоторые ошибки в протоколе, то Панас их не допускает обычно.
ОК, я не собираюсь тут холивар начинать, я в панасоник верю, и станции у меня все именно панасоник, но проблема есть, и ее надо решать 😉
Я подобный вопрос решал только как АУ - через японский суппорт Панасоника. И они в моём случае таки заметили, что ПО, с которым у меня были проблемы, шлёт на панас запрос примерно такого вида ...,>, а по RFC положено ....>, из-за этого Панас футболил запросы на регистрацию этого ПО (SIP-факс), а Астериск, например, косячный запрос “прощал” и разрешал регистрацию. Я твою проблему пока не понял - думать над ней надо, а мозг и так устаёт на работе. И пишу всё это к тому, что надо долго и нудно анализировать логи. Или воспользоваться услугами ТЦ, через которых оказывается официальная техподдержка АТС Панасоник. Понятно, что работникам надо платить зарплату, и эти услуги будут небесплатными. В случае по моей проблеме мы поставляли клиенту АТС и услуги по первоначальной настройке, так что решение для клиента не стоило дополнительных денег.
К сожалению, контакт с АУ, который инсталлил, утерян и вряд ли будет возобновлен. Пока что в поиске новых адекватных контактов, а вопрос висит уже давно, приходится пока самому разбираться. Причем руководство не в духе и предложило мне доделать все висяки по телефонии самостоятельно в рамках моего бюджета (я админ, понятное дело). Читал уже много тем на этом форуме и знаю, что настоящие панасониководы админов не любят, но уж слишком сильно не бейте, пожалуйста 😉
Очень удачно - как раз поймал один шлюз на вылете. Сохранил страничку, поменял порты, сохранил снова с удачной регистрацией.
pap2t-166-240.zip (Размер: 56KB - Загрузки: 38)К сожалению, контакт с АУ, который инсталлил, утерян и вряд ли будет возобновлен. Пока что в поиске новых адекватных контактов, а вопрос висит уже давно, приходится пока самому разбираться. Причем руководство не в духе и предложило мне доделать все висяки по телефонии самостоятельно в рамках моего бюджета (я админ, понятное дело).
http://old.panasonic.ru/tc_pbx/
По поводу руководства - ну что же, сочувствую. Если нужны отмазки - скажи, что к некоторым функциям АТС ты не имеешь доступа(это, кстати, правда). По твоей проблеме лично мне надо слишком много телодвижений совершать, поэтому помочь не смогу. Возможно, у меня тямы не хватает, но я не вижу источник твоей проблему без нудного копания в логах. Может, кому-то скучно и нет работы, тогда могут забесплатно помочь. Может, кто-то мегаопытный сможет “на лету” ответ найти. Или вон есть тут “специалисты”, которые не очень хорошо разбираются, зато пишут много и советы дают - глядишь, 200 советов дадут, один случайно подойдёт 😊
К сожалению, контакт с АУ, который инсталлил, утерян и вряд ли будет возобновлен. Пока что в поиске новых адекватных контактов, а вопрос висит уже давно, приходится пока самому разбираться. Причем руководство не в духе и предложило мне доделать все висяки по телефонии самостоятельно в рамках моего бюджета (я админ, понятное дело).
http://old.panasonic.ru/tc_pbx/
По поводу руководства - ну что же, сочувствую. Если нужны отмазки - скажи, что к некоторым функциям АТС ты не имеешь доступа(это, кстати, правда). По твоей проблеме лично мне надо слишком много телодвижений совершать, поэтому помочь не смогу. Возможно, у меня тямы не хватает, но я не вижу источник твоей проблему без нудного копания в логах. Может, кому-то скучно и нет работы, тогда могут забесплатно помочь. Может, кто-то мегаопытный сможет “на лету” ответ найти. Или вон есть тут “специалисты”, которые не очень хорошо разбираются, зато пишут много и советы дают - глядишь, 200 советов дадут, один случайно подойдёт 😊
Спасибо и на том. Я, собственно, надеялся только на то, что кто-нибудь уже аналогичную проблему решал и сможет сразу пальцем ткнуть. Иначе самому понятно, что без логов не обойтись.
Насчет ТЦ прикольно очень - в Питере их всего 2, а сколько людей, называющих себя АУ? И как проверить наличие действующего сертификата у него?
Собственно, я сюда пишу потому, что люди говорят о том, что реализация SIP в панасониках не славится прямотой, и советуют искать причину именно в нем.
Да, забыл сказать, прошивка панасоника - 4.20.
Те люди, которые разбираются в SIP Панасоника, такого не скажут. А те, кто говорит про кривоту - скорее всего смотрят через призму своих ручек. Панас просто жёстко придерживается RFC. И если Астериск может “закрыть глаза” на некоторые ошибки в протоколе, то Панас их не допускает обычно.
ОК, я не собираюсь тут холивар начинать, я в панасоник верю, и станции у меня все именно панасоник, но проблема есть, и ее надо решать 😉
Я подобный вопрос решал только как АУ - через японский суппорт Панасоника. И они в моём случае таки заметили, что ПО, с которым у меня были проблемы, шлёт на панас запрос примерно такого вида ...,>, а по RFC положено ....>, из-за этого Панас футболил запросы на регистрацию этого ПО (SIP-факс), а Астериск, например, косячный запрос “прощал” и разрешал регистрацию. Я твою проблему пока не понял - думать над ней надо, а мозг и так устаёт на работе. И пишу всё это к тому, что надо долго и нудно анализировать логи. Или воспользоваться услугами ТЦ, через которых оказывается официальная техподдержка АТС Панасоник. Понятно, что работникам надо платить зарплату, и эти услуги будут небесплатными. В случае по моей проблеме мы поставляли клиенту АТС и услуги по первоначальной настройке, так что решение для клиента не стоило дополнительных денег.
Я один вопрос тоже пробовал решать через АУ, который обратился в японский саппорт Панасоника. И меня отфутболили со свистом, а потом я сам догадался. А проблема была в следующем - на TDA30 IPGW4 использует для голоса порты подряд от 1720, кажется, и далее до 1729… вроде, я точно не помню, но вот когда он попадал на порт 1723… многие роутеры этот порт специальным образом обрабатывают, как стандартный для PPTP, и соответственно не идет там голос нормально. А вот как изменить диапазон портов - АУ мне сказал, что этот шлюз очень скуп в настройках, диапазон зашит и не меняется, и что моя проблема слишком мелкая для Панасоника, чтоб специально для меня менять прошивку IPGW4.
Поймал другой шлюз на зависших линиях, на этот раз SPA8000.
Одним линиям я поменял порт, другим не стал, и снял протокол траффика, и вот какая интересная картинка получилась:
В пакетах от тех линий, которые потом успешно зарегистрировались, есть такой кусок:
Authorization: Digest username=“261”,realm=“Registered Users”,nonce=“69d2a44891231a356bd6ad5ab469”,uri=“sip:172.27.178.240”,algorithm=MD5,response=“b18e4e07ce7d2b282a229bab7cca”
Authentication Scheme: Digest
username=“261”
realm=“Registered Users”
nonce=“69d2a44891231a356bd6ad5ab469”
uri=“sip:172.27.178.240”
algorithm=MD5
response=“b18e4e07ce7d2b282a229bab7cca”
В пакетах от других линий эта часть отсутствует напрочь. Хоть это и панасоническая тема, но вдруг кто-то может подкинуть идею, где копать дальше?
