Проблема при переадресации

[alg]

В какой-то степени это действительно наша проблема, т.к. наши софт и оборудование любят, когда входящие пакеты сформированы по стандарту. Если есть отклонения - возможны варианты. Что-то мы можем обойти, вырезав или скорректировав нестандартные заголовки (прецеденты были), но если в пакете прописан не тот IP-адрес - это финиш. Такое бывает, к примеру, если удаленная сторона имеет не вполне корректную реализацию SIP-стека или имеется неточность в настройках. Но надежды разобраться (в т.ч., общаясь с их инженерами) не теряем.

Корбину и Сипнет я привел для примера. Реально провайдеров, с которыми у нас нет проблем, значительно больше, и ни с одним из них мы не договаривались - все работают как один с точки зрения формируемых SIP-пакетов.

[Alexan]

Сейчас провел следующий эксперимент.
От Манго завернул вызов в Сипнет, от них завернул к вам... Не пошло. Обратился в Сипнет за комментариями. Ответили следующее:
-----------------
мы, очевидно, отправляем вызов согласно настроенной вами переадресации,
но в ответ от comtube получаем:
SIP/2.0 403 Sorry, no transit calls to PSTN allowed
-----------------
Что скажете?

[alg]

Звонок был на городской номер? Если да, то все верно - вызов пришел на нашу платформу с Сипнета, но набираемый номер - городской. Мы такие вызовы отсекаем, не позволяя через нас звонить на город из других сетей.

[Alexan]

У меня в настройках по приоритету: 1 прием на сип-клиент и 2 (при не ответе) переадресация на городской.
На сип-клиент вызов так же не прошёл.
А в чём тайный смысл таких запретов? Вам же выгодно чтобы звонили в городскую сеть, вы же на этом зарабатываете.

[alg]

Смысл запрета звонить из другой сети через нас на город напрямую? Мы не можем идентифицировать клиента при таких вызовах, вот и весь смысл. Вот если вызов придет из другой сети на наш 6-значный SIP-номер, а на SIP-номере установлена переадресация на город - все должно сработать (ибо нам известен владелец 6-значного номера и есть на кого "повесить" переадресацию на город).
Т.е., если из сипнета позвонить, например, на 792612345678@sip.comtube.ru, то вызов не пройдет. А вот вызов на 123456@sip.comtube.ru (на котором настроена переадресация и достаточно средств на счете) допустим.

У нас была небольшая неточность в настройках - вероятно, она могла повлиять на то, что вызов не состоялся. Будет время - попробуйте, пожалуйста, еще раз.

[Alexan]

У нас была небольшая неточность в настройках - вероятно, она могла повлиять на то, что вызов не состоялся. Будет время - попробуйте, пожалуйста, еще раз.

Попробовал еще раз. Докладываю. Ни на сип-клиент ни на переадресованный телефон вызов не пришел.
в Сипнете вызов зафиксировали как отвеченный с вашей стороны, причем там где 32 сек связь разорвалась сама, в остальных 2-х случаях я сделал отбой на вызывающей стороне (не на принимающей, до туда не дошло).
23/04/10 17:51 a**@sipnet.ru 78123**@mangosip.ru SIP ID 00000000 0:10 0.00000 0.00000
23/04/10 17:51 a**@sipnet.ru 78123**@mangosip.ru SIP ID 00000000 0:10 0.00000 0.00000
23/04/10 17:47 a**@sipnet.ru 78123**@mangosip.ru SIP ID 00000000 0:32 0.00000 0.00000

[alg]

Там, где 32 секунды - это потому, что вызов реально никуда не пошел. Наш биллинг все вызовы привязывает к конкретному клиенту, а судя по логам, звонок был с манги через нас на сипнет - тут непонятно, кто звонит (чистый транзит). Поэтому коммутатор попытался проиграть фразу "Данная услуга не предусмотрена Вашим тарифным планам" и прервать вызов, но:
- из-за проблемы с кодеками и/или проксированием голоса фраза не прозвучала
- из-за проблем с ACK'ом вызов не прервался.

[Alexan]

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

Звонок был с Манги на Сипнет, а от них (по переадресации на 123456@ваш_сип_сервер) на вас. И транзита тут ни какого нету. Вернее транзит (как я его себе понимаю) есть, но законный, т.с. мы за все платим.

Эту связку "Манго (или хоть кто) -> Сипнет -> Вы -> Я" я решил сделать, т.к. вы сказали, что от Сипнета входящие принимаете нормально, оказалось, что нет.

[sd]

Входящие вызовы с sipnet.ru мы принимаем нормально. В вашем случае, это вызов переадресованный, то есть у него есть три составляющих:
номер телефона в INVITE - куда реально идет вызов (в вашем случае, это sip:123456@comtube.ru)
номер телефона в "To:" - первоначально набранный номер (в вашем случае, это sip:aххххх@sipnet.ru)
номер телефона в "From:" - от кого идент вызов (в вашем случае, это sip:aххххх@mangosip.ru)

Мы, к сожалению, не видим номер, который находится в строке с INVITE (особенность нашей железки, которую производители обещались исправить). Отсюда вытекает, что наша платформа видит только номера "To:" и "From:", в которых, в данном случае, не указан номер нашей платформы. Этот вызов отбивается с предварительным проговариванием сообщения о невозможности принять вызов.

Когда вызов идет напрямую с sipnet.ru на comtube.ru, номера в INVITE и "To:" одинаковы, в них указан наш номер. В этом случае вызов проходит успешно.

В вашем случае, необходимо с mangosip.ru делать переадресацию сразу на нас, но только тогда, когда мы совместно с их инженерами решим проблему с пакетом ACK. Двойная переадресация с участием sipnet.ru сейчас тоже работать не будет, но это проблема, решение которой зависит от производителей нашего оборудования.

[Alexan]

В вашем случае, необходимо с mangosip.ru делать переадресацию сразу на нас, но только тогда, когда мы совместно с их инженерами решим проблему с пакетом ACK. Двойная переадресация с участием sipnet.ru сейчас тоже работать не будет, но это проблема, решение которой зависит от производителей нашего оборудования.

Спасибо за понятное объяснение. От меня что нибудь требуется для решения проблемы с Манго? Или с инженерами Манго вы сами всё решите? Если мне остаётся только ждать, то эксперименты я заканчиваю и жду вашего сообщения о решении проблемы с Манго.
Кстати, мы планируем еще городской телефончик прикупить, но уже от www.teleum.ru Они тоже дают переадресацию на сип. У вас был опыт взаимодействия с их сервисом?