Проблема с входящими звонками с номеров доступа

[sd]

В данный момент это может быть из-за того, что я сейчас закрыт и перекрыт как только можно и "нахожусь в подсети 10го уровня"? Или же речь не про меня, а про "моего оператора" в данный момент?

Честно говоря, не знаю. Надо попробовать простой вариант, когда нет столько NAT'ов.

Это проблема скорее на вашей или ихней стороне?
На 432101 оставлять автоматический подъем трубки и новости (для тестов) или это ни к чему? В любом случае, спасибо вам, что не оставляете меня на произвол судьбы!!

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

[alexsong]

Сейчас своим дилетантским взглядом пробежался по логам, которые на 6ой странице ветки (4 мои удачных вчерашних и два ваших неудачных сегодняшних).. Увидел там вот это:

Удачное соединение
v=0
o=NCHSoftware-Talk 1302122029 1302122031 IN IP4 85.17.222.134
s=Express Talk Call
c=IN IP4 85.17.222.134
t=0 0
m=audio 30425 RTP/AVP 0 8 96 3 13 101
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:96 G726-32/8000
a=rtpmap:3 GSM/8000
a=rtpmap:13 CN/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=sendrecv

Неудачное соединение
v=0
o=tb640 5 1 IN IP4 192.168.3.10
s=-
c=IN IP4 62.117.120.98
t=0 0
m=audio 30822 RTP/AVP 18 3 0 8 4 2 15 98 98 101
a=rtpmap:2 G726-32/8000
a=rtpmap:98 iLBC/8000
a=rtpmap:98 iLBC/8000
a=rtpmap:101 telephone-event/8000
a=direction:active
a=nortpproxy:yes

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

[sd]

То, что вы написали - это SDP, то есть протокол, в котором указывается, какой(ие) кодеки будут использоваться, порт и IP адрес, куда будут идти голосовые пакеты. Обрыв же происходит из-за того, что та сторона (CENSORED) не получает от нас ACK пакета, который уведомляет ее о том, что мы все получили, и приняли к сведению.

[sd]

Конечно, для чистоты эксперимента, позвонить бы еще в одну sip-сеть, и снять трассировку. Чтобы было 3 разных варианта, так может и придет в голову что-то.

[sd]

Вообщем, причина такого поведения найдена. В случае с CENSORED от них в пакете есть заголовки route, а в sipnet'е заголовки record-route. Record-route указывает на то, что все следующие пакеты должны идти через тот IP-адрес, который указан в record-route, а route - просто дает указания только о текущем пакете (если я правильно понял). Согласно стандарту ACK должен идти на тот IP адрес, который указан в заголовке Contact, или на тот, который указан в record-route (а про route не сказано ничего). В случае с CENSORED, record-route заголовков от них не приходит, а наш sip-прокси почему-то добавляет очередной route вместо правильного record-route, что приводит к тому, что оборудование шлет ответ на IP адрес из заголовка Contact (ваш телефон). В итоге сервера CENSORED'а не получают ACK и прерывают вызов через 11 секунд. тут возможно 2 решения проблемы: каким-то образом заставить наш sip-прокси добавлять именно record-route вместо route, либо попросить CENSORED поправить это у себя. На данный момент уговорить наш sip-прокси это вставлять в пакет record-route не удалось, но мы продолжаем над этим работать.

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

Теперь о PortGo. Опять же, наша железяка не может правильно обработать SDP, который содержится в пакете OK от данного телефона. Наш софт из-за этого тоже ведет себя не так, как ожидается (баг, который мы поправим), то есть не вешает трубку с указанием причины, а просто ничего не делает. Запрос в support производителя уже отправлен. Жду ответа.

[alexsong]

Примерно вас понял! Оперативно вы! Попробую достучаться до CENSORED, как они отреагируют на эту ситуацию.

Если все заработает, да еще и с PortGo, надо будет "переезжать" на ваш сервис целиком и полностью

[sd]

Проблему с PortGo вроде бы удалось вылечить. Проблема была проста: наша железка в некотором роде очень требовательно относится к стандартам. Проблема с PortGo была в том, что он передавал User-agent (название программы, которая шлет данный sip-пакет) в пакете OK (при поднятии трубки), который не соответствует стандартам. В итоге, наша железка тупо игнорировала этот пакет . Сейчас мы этот User-agent вырезаем, и железка довольна

[alexsong]

Ура! Сейчас буду пробовать )) В CENSORED отписался, жду ответа..

[alexsong]

PortGo заработал! Класс! Спасибо! Какая привередливая у вас железяка, однако

CENSORED ответили следующее:

Код: Выделить всё

Тема
Re: Re: Re: Re: Re: Очередная проблема..
Сообщение
Сейчас не готовый что-то ответить.. Дайте немного времени. Сообщим.

Я, соответственно, сразу же отпишусь здесь.

[alexsong]

UPDATE: прибил сообщение.