|
|
День добрый Dmitry,
Thursday, July 17, 2014, 7:22:46 PM, Вы пишете:
DA> Здравствуйте,
...
>> Посмотрел дамп еще раз не увидел, если не секрет какой номер пакета по порядку?
DA> badsip3, пакеты 15, 16 и далее ещё есть.
Да, но только 15 это синк от пользователя к серверу, а 16 это ак сервера на синк
клиенту, за ними сразу клиент паблиш делает по tcp, причем это сессия первого
плеча.
>> Хотя до сих пор сомневаюсь, что сервер с сторону второго плеча что то посылал.
DA> Пытался. собственно смысл текста ошибки - нужно было соединение (TCP)
DA> для передачи больших пакетов, но нам в нёи отказали (NAT внутрь не
DA> пропустил, ожидаемо).
Не не пытался он в tcp что либо слать, собирался в udp, но споткнулся на wan limit для
upd и сразу ответил 500, так как то что клиент на втором плече tcp умет он и
не подозревал. До пикса и дело не дошло.
>> вот в то, что, сформировав инвайт второму плечу, наткнулся на 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 гвоздями на нем не забит на мертво, а
поддерживать сессию живой через нат это дело давно решенное.
------------------------
С наилучшими пожеланиями
Николай Варинов.
|
|