День добрый Dmitry,
Thursday, July 17, 2014, 7:22:46 PM, Вы пишете:
DA> Здравствуйте,
...
>> Посмотрел дамп еще раз не увидел, если не секрет какой номер пакета по порядку?
DA> badsip3, пакеты 15, 16 и далее ещё есть.
Да, но только 15 это синк от пользователя к серверу, а 16 это ак сервера на синк клиенту, за ними сразу клиент паблиш делает по tcp, причем это сессия первого плеча.
>> Хотя до сих пор сомневаюсь, что сервер с сторону второго плеча что то посылал.
DA> Пытался. собственно смысл текста ошибки - нужно было соединение (TCP) DA> для передачи больших пакетов, но нам в нёи отказали (NAT внутрь не DA> пропустил, ожидаемо).
>> вот в то, что, сформировав инвайт второму плечу, наткнулся на WAN UDP Limit и >> ответил 500 первому верю.
DA> Именно в виду невозможности отправить пакет во второе плечо через TCP
DA> соединение.
Только вот с чего ему его слать, второе плечо пока молчит о том что оно tcp
может, сессии с ним нет, привязки этой сессии ко второму плечу нет, куда и на
какой порт слать синк для установления сессии сервер, не телепат, не знает, так
что 500 от сервера вполне логичен и закономерен.
DA> По крайней мере в badsip3 всё рабботало по UDP, кроме нескольких SYN/ACK DA> пакетов на/с порт 5060.
Смотрим пакет 35 инвайт от клиента по udp, после 401 от сервера он переходит на tcp, пакеты 39,40 и инвайт с авторизацией общим размером 1555 байт идет уже в tcp и именно в той сессии которая в 15,16 пакете устанавливается и 500 приходит в ней же. А второй вызов уже весь между первым плечом и сервером идет в tcp.
Настойка клиента только на tcp тоже решит эту проблему, так как с ната от по tcp скорее всего он выйдет, если sip гвоздями на нем не забит на мертво, а поддерживать сессию живой через нат это дело давно решенное.
Этот архив был сгенерирован hypermail 2.1.8 : Fri 18 Jul 2014 - 00:17:25 MSK