Тема: Подключение sip к TDE-100
Регистрацию провайдер требует, адрес сервера регистрации совпадает с ip sip-сервера. Включил регистрацию, каналы упали в ous и не поднимаются.
Сигнализация ходит через процессор. RTP с голосом через DSP.
В консоли меню Utitlity - Ping. Пингани сервер провайдера. Он хоть видится?
Регистрацию провайдер требует, адрес сервера регистрации совпадает с ip sip-сервера. Включил регистрацию, каналы упали в ous и не поднимаются.
Выключил “отмену регистрации при статусе порта ins” и всё завелось и входящая и исходящая. Всем огромное спасибо за терпение и отзывчивость.
Однако, по словам оператора, по снифу прова весь его трафик идет на ip процессора, так что непонятка с ip DSP осталась, хотя и вызов и голос всё ходит отлично в обе стороны.
Солнце встаёт на востоке?.. Всё, ничего больше не трогай..
И снова всем здравствуйте, радость была недолгой. Через 30 секунд обоюдного разговора исходящий звонок с tde-100 через сип сбрасывается, а входящие идут нормально тем временем. Не подскажете, что копать то?
Опять корявый СИП... Трассировку первым делом надо копать...
Добрый день, выкладываю трассу неудачного исходящего звонка, http://zalil.ru/33968419
С входящими всё нормально.
Добрый день, выкладываю трассу неудачного исходящего звонка, http://zalil.ru/33968419
С входящими всё нормально.
Ерунда какая-то...
Ни SETUPa от АТС, ни CONNECTa от прова и CONNECT ACKNOWLEDGEa от АТС нет в трассе. Только СЕШН ПРОГРЕСС от прова, после чего (как раз через 30 сек) выдается Request Terminated…
Пров, скорее всего, не пониамет, что Вы что-то набрали... Странно, как получается, что исходящий вызов идет без коннекта...
ЗЫ: При снятии трассы сначала запускайте трассировщик, а потом набирайте номер, чтобы был виден весь процесс...
ЗЗЫ: Снимите трассу входящего звонка для сравнения...
Добрый всем вечер, наконец-то добрался до станции и снял новые трассировки.
1) Звонок исходящий (через 28 сек обрыв): http://zalil.ru/33978376
2) Звонок входящий: http://zalil.ru/33978379
3) Попытка входящего звонка и исходящий звонок (через 28 сек обрыв): http://zalil.ru/33978386
Проблема только с исходящими звонками, входящие ходят нормально. А исходящие рвутся всегда (мобильный, городской - не важно) в промежутке 28-31 сек. Провайдер рассказал что его сервер не понимает PRACK, который шлет панасоник, пока грешу на него, но с ходу не нашел, хотя помню где-то точно было про 100rel. Помогите пожалуйста, что еще может быть не так?
V-SIPGW16
Shelf Property.
Дополнительные сведения о запросе INFO содержатся в RFC 2976.
PRACK
Протокол SIP определяет два типа ответов на запрос, инициирующий соединение – предварительные и окончательные. Окончательные ответы передают результат обработки запроса и отсылаются надёжно (с подтверждением). Предварительные ответы обеспечивают информацию о текущей стадии обработки запроса, но отсылаются ненадёжно. Однако, в некоторых случаях, включающих взаимодействие с ТфОП, необходим механизм обеспечения надёжности передачи предварительных ответов. В целях поддержки функции надёжной транспортировки предварительных ответов требуется наличие у элемента SIP соответствующей опции (идентифицирующейся с помощью option tag «100rel»).
Механизм надёжности работает по схеме, сходной с существующими механизмами надёжности для окончательных ответов класса 2хх на запрос INVITE. Надёжные предварительные ответы повторно передаются TU (пользователем транзакций) с интервалом, возрастающим по экспоненциальному закону. Повторные передачи прекращаются, когда приходит сообщение PRACK. Тип запроса PRACK играет ту же роль, что и ACK, но для предварительных ответов. Однако между ними имеется принципиальное отличие – PRACK является обычным SIP-сообщением, как запрос BYE. Т.е. его надёжность обеспечивается последовательно (hop-by-hop) при прохождении через каждый stateful прокси-сервер. Также как BYE (но в отличие от ACK) PRACK требует отправки ответа при его получении.
На устанавливающий диалог запрос UAS может послать ответ класса 1хх (кроме 100) надёжно при условии, что запрос содержит заголовок Supported с option tag «100rel». Это означает, что UAC поддерживает расширение для надёжной передачи предварительных ответов и может принимать и обрабатывать такие ответы. В то же время
UAC при создании запроса может потребовать надёжной доставки предварительных ответов на него. Для этого UAC вставляет в запрос заголовок Require с option tag «100rel». Каждый предварительный ответ имеет порядковый номер, содержащийся в заголовке RSeq ответа (от 1 до (231 – 1)). После формирования предварительного ответа ядро UAS периодически передаёт его серверной транзакции для отсылки. Предварительный ответ устанавливает диалог, если до сих пор он не был установлен.
При получении надёжного ответа UAC создаёт запрос PRACK и передаёт его в диалоге, находящемся на ранней стадии, который связан с предварительным ответом. Сообщение PRACK включает заголовок RAck, который указывает порядковый номер подтверждаемого предварительного ответа. Повторные передачи PRACK не зависят от получения ответов класса 1хх, т.е. UAC не должен повторно передавать запрос PRACK, когда получает повторную передачу уже подтверждённого предварительного ответа.
Повторные передачи надёжного предварительного ответа прекращаются при получении ядром UAS запроса PRACK. Если PRACK соответствует неподтверждённому предварительному ответу, то отсылается ответ класса 2хх.
После того, как надёжный предварительный ответ был подтверждён, UAS может передавать дополнительные надёжные предварительные ответы. Значение заголовка RSeq в каждом последующем предварительном ответе будет на единицу больше.
Дополнительные сведения о запросе PRACK содержатся в RFC 3262. Пример.
Anton VladimirINVITE 180 (Ringing)PRACK 200 (OK) <на PRACK>
Рис. 2.5. Пример использования запроса PRACK
Добрый всем вечер, наконец-то добрался до станции и снял новые трассировки.
1) Звонок исходящий (через 28 сек обрыв): http://zalil.ru/33978376
2) Звонок входящий: http://zalil.ru/33978379
3) Попытка входящего звонка и исходящий звонок (через 28 сек обрыв): http://zalil.ru/33978386Проблема только с исходящими звонками, входящие ходят нормально. А исходящие рвутся всегда (мобильный, городской - не важно) в промежутке 28-31 сек. Провайдер рассказал что его сервер не понимает PRACK, который шлет панасоник, пока грешу на него, но с ходу не нашел, хотя помню где-то точно было про 100rel. Помогите пожалуйста, что еще может быть не так?
С какой целью Вы (а не панасоник) шлете PRACK?
Убрал галочку V-SIPGW16 -> Shelf Property -> 100rel и полегчало, всё стабильно звонит и ничего не рвется. Большое спасибо всем за помощь.
провозился с настройкой из-за невнимательности ip адресам, а так все оказалось элементарно просто, решил написать статью с описанием своих ошибок, может кому пригодится Как я настроивал sip trank на TDE 600
