AF
Asterisk Forum
обсуждения телефонии, VoIP и IP-PBX
12разделов
5 423тем
34 385сообщений
← К списку тем

no reply to our critical packet

Newbies/FAQ Forum 10 сообщений 12.11.2010 18:47 - 16.11.2010 13:15
#1
Всем спасибо! Проблема решена.
1) для опции externip был указан не правильный !Р
2) для каждого peer`a необходимы такие опции:
Код:
nat=yes
qualify=yes
canreinvite=no
sipreinvite=no
#2 12.11.2010 18:47

no reply to our critical packet

Соединение устанавливается нормально, но, при этом, звука с обеих сторон (у двух соединенных клиентов) не слышно и через 20 секунд после снятия трубки, происходит разрыв соединения с таким сообщением
Код:
[Nov 12 12:29:07] WARNING[12531]: chan_sip.c:2022 retrans_pkt: Maximum retries exceeded on transmission tuecefzqlrjbchx@host3 for seqno 37 (Critical Response) -- See doc/sip-retransmit.txt.
[Nov 12 12:29:07] WARNING[12531]: chan_sip.c:2044 retrans_pkt: Hanging up call tuecefzqlrjbchx@host3 - no reply to our critical packet (see doc/sip-retransmit.txt).


Такое поведение началось, после переноса всей копии астериска (с заменой в sip.conf IP адресов) в другую сеть, в которой другой NAT (порты 5060 и 10000:20000 открыты).
В нашей сети все работает, эта же копия астериска в другой сети не работает. Что было
Код:
sip_client (softphone) -> asterisk -> NAT -> provider -> ...

и что стало
Код:
sip_client (softphone) -> NAT(1) -> NAT(2) -> asterisk -> NAT(2) -> provider -> ...

В певом случаее, sip_client и asterisk находятся в одной локальной сети, во втором, все находятся в разных сетях.
В чем может быть проблема?
#3 13.11.2010 06:49
Основная проблема в человеке, который сделал NAT(1) -> NAT(2) -> asterisk -> NAT(2)
Все остальное - следствия

Если уж так хочется с таким количеством натов жить - брать в зубы tcpdump и смотреть последовательно как меняется пакет и что прилетает/улетаемт перед/после каждого ната.
И, если понимания нет, постить сюда логи сигнализации с подробным описанием и логи как минимум с ключами tcpdump -lnvvs0
#4 13.11.2010 10:03
Извиняюсь, но в описании проблемы, я допустил ошибку. Схема, которая получилась после переноса выглядит вот так
Код:
sip_client (softphone) -> NAT(1) -> NAT(2) -> asterisk -> provider -> ...

Я сравнивал sip debug на работающем сервере (до переноса) и после переноса. Все значения (From:, To:) в пакетах подставляются верно.
#5 13.11.2010 10:17
Еще поле Contact важно. Настроить STUN на софтфоне. Порты открыты или проброшены? Выложите SIP трейс звонка который не проходит
#6 13.11.2010 11:03
А вот поле contact, не соответствует ((((
В первом случае (когда все работает), в поле contact подставляется внешний !Р. А во втором случае, в поле contact подставляется внутренний !Р (( Как я понимаю, должно в обоих вариантах, подставлятся внешний !Р адрес, да?

Порты открыты.
Что такое sip трейс? Это sip debug?
#7 13.11.2010 12:34
Трейс это от слова trace, полный лог звонка по SIP. Вероятнее всего софтфон не знает что он находится за НАТом. Настраиваете STUN, это протокол прохождения НАТа, на софтфоне.
#8 13.11.2010 14:45
Yur4ek писал(а):
Настраиваете STUN, это протокол прохождения НАТа, на софтфоне.

STUN - это абсолютно бесполезный протокол, ничего и никуда оно проходить не умеет.

На астерисковском пире включено nat=yes ?
Надо включить его и периодические регистрации на софтфоне (не реже, чем время таймаута неактивных UDP-сессий в натах, например 2-5 минут).
Ну или делать пробросы портов на обоих натах
#9 13.11.2010 15:08
да, опция nat=yes присутствует.
порты открыты.
Проблема остается.
Как я понял, проблема в том, что: после переноса сервера астериск в другую сеть, клиент (софтфон) оказался для астериска за НАТом, что и является проблемой для передачи звука. Или проблема в НАТе той сети, куда был перенес астериск?
#10 16.11.2010 13:15
Если я правильно понимаю, то надо ориентироватся вот на это http://asterisk.ru/knowledgebase/Asterisk+SIP+NAT+solutions
4й вариант подходит. Только, вот где найти ", инструкция прилагается >> " ????????