дело не в плате за трафик, если бы я хотел пропускать медиапоток через сервер, выбрал бы разжеванный asterisk, который только проглотить остается.

Конечно после подтверждения. Но это в данном случае не имеет значения.

Alekz:

А теперь расскажите мне дураку, почему при падении SIP Proxy ртп соединение развалится в зависимости от транспорта для сигналки? Это раз.

В случае с SIP не уверен. В случае с H323 терминатор и оригинатор обязаны обмениваться информацией и в случае падения сервера сессия развалится автоматически.

RTP over TCP никто посылать не собирается. ;)

т.е. мы легких путей не ищем?;) лучше велосипед изобрести...

Транзитчики уже давно решили эту проблему начав проксировать медиа о чем вам и было сказано ранее

Имеют место. Но когда начинаются такие проблемы как-то не до сессии уже -- разговора не выйдет.

switch:

с этого места поподробнее!

Была сложность с диагностированием проблемы. В случае с TCP ее легче было бы диагностировать и предотвратить.
Описывать очень долго -- там целая цепочка из шлюзов, SBC и софтсвитчей.
Рассказывать подробности я не имею права.
Скажу только одно -- проблема была в OpenSER'е, на котором была включен высокий уровень детализации логов, что вызвало частичный отказ в ответах на SIP-запросы.
До моего вмешательства проблему не могли решить около 8 часов подряд, перезагружали все подвернувшееся под руку оборудование.

Да, так и решаем. Но тем самым увеличиваем интернет-трафик, повышаем нагрузку на оборудование и, соответственно, себестоимость минуты.

я могу со своей колокольни судить
у клиента было так: одна лыжа в центре, с потоком, другая - в филиале, соединена с центром по h323. между ними канал, по скорости ничего так, но радиоэзернет любил кратковременно падать. В этом филиале был склад и сидел отдел закупки, связь рвалась постоянно.
поставили астер, соединили по SIP. звонки не рвутся, токо иногда голос пропадал, что пофиксили буфером.

tma, причем тут h323 и TCP?! В сипе, как я уже говорил, тоже можно принудить рефрешить сессию - от транспорта это не зависит, это особенность сигнализации. (Про ртп я и не сомневался - я о тебе лучшего мнения =) )

Аналогично с диагностированием проблем - чем TCP, как протокол помог бы? Конкретную проблему можно опустить, только преимущество TCP над UDP применительно к диагностированию проблем обработки сигнализации.

Про сообщение, по которому биллингуется вызов, я заговорил потому, что без ОК на BYE вызов будет биллинговаться дальше, даже если сигнализацию заблокировали на UA. Соответственно "бесплатных" разговоров не будет.

Все проверять нужно. Весь операторский рынок работает по H.323 и все ими пользуются. Это о чем-то да говорит...

Если сервер за firewall'ом, то не очень-то получится.

Alekz:

чем TCP, как протокол помог бы?

Проблема была бы сразу видна на поверхности. С UDP так не получится, т.к. он не требует подтверждения доставки.

Если интересует сама тема TCP vs UDP для SIP, то могли бы искать сами.
Вот интересная ссылка для изучения: http://tools.ietf.org/html/draft-rosenberg-sip-sctp-00
В частности там говорится, что SIP over UDP не эффективен для управления нагрузкой.
SIP over TCP обеспечивает сквозную защиту путей передачи посредством протокола безопасности транспортного уровня (Transport Layer Security, TLS) и поддержку более крупных пакетов с данными (из какой-то статьи о Microsoft).

Alekz:

Про сообщение, по которому биллингуется вызов, я заговорил потому, что без ОК на BYE вызов будет биллинговаться дальше, даже если сигнализацию заблокировали на UA. Соответственно "бесплатных" разговоров не будет.

Биллинг рано или поздно перестанет биллинговать, т.к. у него есть встроенные ограничения.
Биллинг обычно работает по Radius-протоколу, который не знает ни о каких BYE и OK.
Если упал sip proxy, то биллинг не поможет -- sip proxy уже не будет помнить о сессиях.
Вариантов можно массу найти.
Решение в данном случае одно -- проксирование RTP.

SIP vs H323 я здесь разводить не буду, если угодно -- в ICQ.