Почему не возможно дозвониться до некоторых мобильных номеров?

Question

[Дмитрий Лебедев]

Здравствуйте.

Столкнулись с проблемой. Стоит голосовой VOIP-шлюз Eltex TAU-24.
Сделал базовые настройки, прописал номера, исходящая/входящая связь имеется. Но есть загвоздка, почему-то не получается звонить на некоторые мобильные номера.
Т.е на некоторые мобильные номера звонит, а на некоторые сразу сбрасывает. Как шлюз выбирает, на какие звонить, а на какие нет, не понимаю. Ладно бы одного ОпСоСа, но получается и МТС и Билайн и Мегафон.
Перезагрузка устройства не помогает. Уже все перепробовал, ничего не получается.

Провайдер тоже разводит руками. Подскажите куда копать и в чем может быть проблема?

Answer 1

[Дмитрий Лебедев]

Wireshark вообще сказал, что нет SIP соединений :) зато доблестный Syslog сообщил много интересностей. Ответ от ТП Eltex:
*******************************************
Ясно судя по логу, происходит следующее:
-мы отдаем INVITE с тегом Supported: 100rel, в этом случае взаимодействующий шлюз по своему усмотрению может передавать предварительные ответы либо надежно, либо нет;
-взаимодействующий шлюз(%SIP_SERVER%) выбирает передавать предварительные ответы надежно, т.к в сообщении 183 присутствует тег Require: 100rel
-получив это сообщение, тау соответственно его подтверждает сообщением PRACK
-на которое затем ругается SIP провайдер сообщением 481 Call Leg/Transaction Does Not Exis
-и затем мы(тау) отбиваем вызов.

Варианты решения:
1) (НЕ РЕКОМЕНДУЕТСЯ)В настройках SIP профиля изменить опцию "100rel" в положение off. Тогда мы не будем передавать в INVITE тег Supported: 100rel и данная цепочка не повториться. Но тогда при поступлении входящего вызова с тегом Supported: 100rel или Require: 100rel
тау будет ругаться сообщением 420.

2)(РЕКОМЕНДУЕТСЯ) Узнайте у вашего SIP провайдера: "почему он сначала передает 183 с Require: 100rel, а затем ругается на наше подтверждение PRACK? ведь он сам говорит, что мол я поддерживаю подтверждение, поэтому тау и передает PRACK."
Если SIP сервер не поддерживает подтверждение предварительных ответов (RFC 3262), то он не должен передавать Require: 100rel в 183 сообщении.
*******************************************

Сделал по первому варианту, все заработало. У провайдера так и не получилось, что-либо выяснить.

Answer 2

[Пума Тайланд]

собственно достаточнопросто посмотреть свои логи и логипровайдера . а не разводить руками

Answer 3

[Владимир]

собственный софтсвитч используется или провайдера?

Comments

[Дмитрий Лебедев]

Не совсем понял.
Eltex TAU-24 - мы приобретали сами и настройки я делал сам
Провайдер нам дал только Логин, Пароль и Сервер для SIP регистрации. На аккаунте привязано 6 внешних номеров, для исходящей и входящей связи
И все. Больше ничего.

[Владимир]

откройте руководство eltex.nsk.ru/sites/default/files/tau16_24.ip_SIP_2...
5.1.3.2 Снятие трассировки, зеркалирование сетевого трафика
снимаете дамп и анализируйте в wireshark

Answer 4

[Дмитрий Скогорев]

Телефонию у нормального оператора берете или нашли goip'щика на форуме? какая-то закономерность есть (код/регион/время суток)?

Comments

[Дмитрий Лебедев]

У "нормального" провайдера.
Закономерности нет, разные регионы (Владивосток, Екатеринбург, Томск и т.д), разные номера, разные ОпСоСы. Время не важно, такое ощущение, что номер в невидимомо блеклисте. Проверял по с другого офиса звонить, все нормально по данным номерам. Трубку берут.

Причем звонки на межгород городские нормально, проблем нет (ну это только исходящая, по входящей не сообщали о проблемах).

[Дмитрий Скогорев]

@k3NGuru соответственно да. снять дамп для начала бы, да посмотреть с чем отбивается звонок

[Дмитрий Скогорев]

@k3NGuru ну и еще неплохо бы зацепиться напрямую, например софтфоном и попробовать позвонить