On Fri, 19 Oct 2007 17:56:53 +0400
"Andrew V.Statsenko" <CGatePro@mx.ru> wrote:
> В Птн, 19/10/2007 в 04:37 -0700, Vladimir A. Butenko пишет:
> > Владимир, разрешите принести извинения такое использование вашего > сервера, он показался наболее "правильным".
Да ему-то что - он железный. И алюминявый.
>> ACK-и не получены.
>
>> во втором - ACK для неизвестной транзакции.
> > А это прокся бросила транзакцию и по Via докинула и вернула диалог до > UAC'a, отсюда и branch=0.
Хотя я с трудом понимаю, что Вы написали, но тут явно где-то кто-то порылся:
а) по получении 4xx от CGatePro Ваш прокси (если это был единственный форк)
должен был:
а1) сразу отдать этот 4xx наверх (Циске)
a2) послать ACK.
Отрицательные ACK всегда идут hop-to-hop, они никогда не релеятся (кроме как
в случае stateless proxy, про которые надо забыть сразу).
На что Циска должна была Вам сразу выдать ACK, который Вы должны были сжевать на месте - такие ACK никогда не должны идти downstream.
Если же он пошёл, то это значит, что в Вашем прокси пропала транзакция.
может, по тайм-ауту. Но раз ACK пришёл, то значит, что Вы только что отдали
наверх 4xx. Из чего следует (возможно):
б) если Вы получили 4xx/5xx/6xx и отдали его наверх, то при получении
"снизу" какого-то кода еще раз - он НЕ ДОЛЖЕН опять релеиться наверх. А у
Вас, видимо, релеится?
Понять, как это должно работать, можно по структуре того же CGatePro - вот пришёл запрос, сделали серверную транзакцию (SIPS в CGatePro), она сформировала запрос, и отдала его на обработку в "Transaction Unit" (SIGNAL в CGatePro). Тот её как-то обработал, например, форкнул, создав 1 или более SIP CLient транзакций (SIPC в CGatePro), и они все начали как-то этот запрос пропихивать дальше.
Если одна из этих SIPC получила код ошибки (300+), то она отдаёт его в Transaction Unit, который что-то с ней будет делать (копить, ожидая окончания других SIPC или сразу отдаст наверх). НИКОГДА БОЛЬШЕ эта клиентская транцакция не должна больше ничего наверх отдавать. То, что ей продолжает сыпаться этот код, а она продолжает слать на него ACK (который почему-то не доходит) - это уже чисто конкретно интимная жизнь этой транзакции, о которой никто знать не должен. С точки зрения Transaction Unit, эта клиентская транзакция свою функцию выполнила. В CGatePro ей вообще идет сигнал disconnect, чтобы она знала, что никому больше не нужна, и может убить себя апстену в любой момент, никому не говоря.
Единственное исключение из всего это - это 2xx ответ на INVITE, который таки да, может быть просто "пропихнут" upstream. Хотя я бы очень снисходительно отнёсся к прокси, который такой "свободный" 2xx-INVITE просто бы уронил на пол. А вот к прокси, который апстримет наверх все собранные его client transaction негативные ответы, вместо того, чтобы собрать их в ОДИН, и только его и послать - снисхождения нет. От него у многих дивайсов крыша поедет.
> -- > С уважением, > Андрей Стаценко, > Наунет СП. > > ################################################################## > Вы получили это сообщение потому, что подписаны на список рассылки > <CGatePro@mx.ru>. > > Чтобы отписаться, отправьте сообщение на адрес <CGatePro-off@mx.ru> > Чтобы переключиться в режим дайджеста - mailto:<CGatePro-digest@mx.ru> > Чтобы переключиться в индексный режим - mailto:<CGatePro-index@mx.ru> > Для административных запросов адрес <CGatePro-request@mx.ru> > Архив списка: http://mx.demos.su/lists/cgp-russian/ > > >
Sincerely,
Vladimir
Получено Fri Oct 19 20:35:46 2007
Этот архив был сгенерирован hypermail 2.1.8 : Sat 20 Oct 2007 - 04:14:50 MSD