AO
На asterisk проброшен порт 5060 или другой? Используете UDP или TCP?
Size: a a a
2020 October 27
PZ
Скиньте printscreen headers 200
PZ
Anton Oskin
На asterisk проброшен порт 5060 или другой? Используете UDP или TCP?
Если вопрос мне, то вроде да, проброшены. Регистрация проходит, вызов тоже, а с 200 проблема, или точнее с АСК)
AO
Pavel Z
Если вопрос мне, то вроде да, проброшены. Регистрация проходит, вызов тоже, а с 200 проблема, или точнее с АСК)
Проброшен тот порт, который слушает asterisk (5060), или какой-то другой порт на 5060?
PZ
Anton Oskin
Проброшен тот порт, который слушает asterisk (5060), или какой-то другой порт на 5060?
который слушает астериск
YG
Pavel Z
Если проброшен не 5060 то проблема именно в этом - так как в ACK порт 5060
Если нет - тос снимите pcap со стороны софтфона - увидите
куда улетает ACK
Если у вас там какой нить SIP-ALG то он вполне может "поправить" адрес контакта
Если нет - тос снимите pcap со стороны софтфона - увидите
куда улетает ACK
Если у вас там какой нить SIP-ALG то он вполне может "поправить" адрес контакта
PZ
Если проброшен не 5060 то проблема именно в этом - так как в ACK порт 5060
Если нет - тос снимите pcap со стороны софтфона - увидите
куда улетает ACK
Если у вас там какой нить SIP-ALG то он вполне может "поправить" адрес контакта
Если нет - тос снимите pcap со стороны софтфона - увидите
куда улетает ACK
Если у вас там какой нить SIP-ALG то он вполне может "поправить" адрес контакта
алг отключили, дамп не снять, нечем..
PZ
хотя, есть ноут, на нём снимем, точно
AO
Pavel Z
алг отключили, дамп не снять, нечем..
SIP ALG на обоих концах может быть. От него проще избавиться путём использования нестандартного порта для SIP. Лучше ещё пускать SIP по TCP через NAT, - не будет проблем с зависанием соединения.
PZ
Anton Oskin
SIP ALG на обоих концах может быть. От него проще избавиться путём использования нестандартного порта для SIP. Лучше ещё пускать SIP по TCP через NAT, - не будет проблем с зависанием соединения.
спасибо за идею, со стороны инициатора мобильная сеть или сеть другого провайдера с двойным натом. При этом вызов из любой из этих точек имеет одну и ту же картину, на астер, который за третьим нат, не прилетает АСК. Пока у меня все подозрения на роутер, который натит астер.
YG
Pavel Z
спасибо за идею, со стороны инициатора мобильная сеть или сеть другого провайдера с двойным натом. При этом вызов из любой из этих точек имеет одну и ту же картину, на астер, который за третьим нат, не прилетает АСК. Пока у меня все подозрения на роутер, который натит астер.
Чисто теоретически роутер еще можно проверить на таймаут закрытия порта
обычно это 30 секунд
но если выставлен маленький timeout - то вы можете поймать эту же проблему
но это оч редкий случай
обычно это 30 секунд
но если выставлен маленький timeout - то вы можете поймать эту же проблему
но это оч редкий случай
AO
Pavel Z
спасибо за идею, со стороны инициатора мобильная сеть или сеть другого провайдера с двойным натом. При этом вызов из любой из этих точек имеет одну и ту же картину, на астер, который за третьим нат, не прилетает АСК. Пока у меня все подозрения на роутер, который натит астер.
В chan_sip ещё долго был баг из-за которого надо было указывать externtcpport=<пробрасываемый порт>, иначе asterisk прописывал неправильный порт в заголовки и во время звонка была похожая проблема (добавьте на всякий случай, если используете chan_sip, и будете пробрасывать нестандартный TCP-порт).
PZ
Чисто теоретически роутер еще можно проверить на таймаут закрытия порта
обычно это 30 секунд
но если выставлен маленький timeout - то вы можете поймать эту же проблему
но это оч редкий случай
обычно это 30 секунд
но если выставлен маленький timeout - то вы можете поймать эту же проблему
но это оч редкий случай
Причина стала очевидна. Внешний порт на роутере для сип не 5060
PZ
Anton Oskin
В chan_sip ещё долго был баг из-за которого надо было указывать externtcpport=<пробрасываемый порт>, иначе asterisk прописывал неправильный порт в заголовки и во время звонка была похожая проблема (добавьте на всякий случай, если используете chan_sip, и будете пробрасывать нестандартный TCP-порт).
И вот тут похоже вы правы, хотя 16 астер, вроде как можно было исправить) на роутере используется внешний нестандартный порт, который пробрасывает на 5060 астера, и используется chan_sip. Ну и транспорт используется UDP
YG
Anton Oskin
В chan_sip ещё долго был баг из-за которого надо было указывать externtcpport=<пробрасываемый порт>, иначе asterisk прописывал неправильный порт в заголовки и во время звонка была похожая проблема (добавьте на всякий случай, если используете chan_sip, и будете пробрасывать нестандартный TCP-порт).
Так он правильый порт прописывает
ну точнее пропсывает он 5060
по до дизе - говорилось что 5060 и прокидывался)
ну точнее пропсывает он 5060
по до дизе - говорилось что 5060 и прокидывался)
YG
Pavel Z
Причина стала очевидна. Внешний порт на роутере для сип не 5060
А говорили что 5060 )
AO
Pavel Z
Причина стала очевидна. Внешний порт на роутере для сип не 5060
Если это UDP, тогда можно указать externaddr=<IP>:<пробрасываемый порт>, но не советую SIP по UDP через NAT.
PZ
А говорили что 5060 )
да, согласен, некоторые вещи выясняются гораздо позже запланированного..
PZ
Anton Oskin
Если это UDP, тогда можно указать externaddr=<IP>:<пробрасываемый порт>, но не советую SIP по UDP через NAT.
понял, попробуем
YG
Anton Oskin
Если это UDP, тогда можно указать externaddr=<IP>:<пробрасываемый порт>, но не советую SIP по UDP через NAT.
SIP over TCP может точно так же поломаться об NAT
так как для внутри сессии вполне может установиться новое TCP соединение исходя из того что прописано в пакете
Так что профита от SIP over TCP кроме как возможности прокидывать больше данных в одном пакете в целом - нет
так как для внутри сессии вполне может установиться новое TCP соединение исходя из того что прописано в пакете
Так что профита от SIP over TCP кроме как возможности прокидывать больше данных в одном пакете в целом - нет