Asterisk непроксирующий RTP

[demon]

Лирика: Не одно десятилетие в сети и с астериском.. без проблем игнорирую грубый тон, наезды, съезды с темы..

Давно на этом форуме.. но ничего не изменилось. С исходниками и отладкой гораздо проще разговаривать.

P.S. Извините что спросил.

[ded]

Извините что ответил.
Считаете, тон был грубым, и откровенно наезжали?
Почему не удалось поговорить с исходниками на эту тему?

P.S. Почитал топик с Вами 3 года назад, видимо, я слишком груб, что не понимаю сути. Что же Вам так кажется грубым? Покажете пример на другом форуме, где от общения на котором у Вас благоприятные ощущения?

[Zavr2008]

ТС, в этом лично я не увидел никаких съездов до Вашего предыдущего поста - видимо в сердцах за прошое)
С мультифоном не всё так просто ИМХО - хорошо еще если работает..

Как решение вопроса может стоит на хостинге виртуалку поднять если в офис канал тупит (а именно это видимо и есть источник надобности directmedia).

[demon]

Как решение вопроса может стоит на хостинге виртуалку поднять если в офис канал тупит (а именно это видимо и есть источник надобности directmedia).

Речь вовсе не об офисе.
Есть выделенный сервер у провайдера, на котором работает вся логика (довольно сложная) обработки соединений, правил входящих и исходящих, конференций и много чего прочего. Но есть и проблема с каналом, которую я так же пытаюсь решить, но...
И вот "хотелось бы" оставить обработку SIP на этом сервере, а RTP потоки соединять на другом... пусть даже виртуалке. Пусть даже ценой потери записи звонков, VOLUME, TRANSFER и может чего-то ещё..

Так же есть проблема когда.. например, два азиатских друга (до которых просто пинг идёт ~600 мс) желают общаться друг с другом... Кидать RTP потоки через сервер - задержки, lost, fraction lost.. а самому SIP пофиг.

Выход без многократного дублирования серверов с их логикой?

[Zavr2008]

Тогда советую камалию начать осваивать, думаю самое то для данной задачи.

[MIKS]

К сожалению, Asterisk слишком много (точнее все) хочет знать про внутренности SIP соединения. У него на первом месте по логике стоит именно комфортность и безпроблемность голосового соединения с т.з. юзеров. Поэтому он анализирует не только то что подсунут юзеры в свои SDP но и еще зачастую и сам RTP поток (например одно плечо INFO второе rfc никогда не запроксирует напрямую). Там такой внутренней логики в chan.sip достаточно (я не знаю как в pjsip но на 90% уверен что так-же т.к. прокладка к asterisk у него скорее всего унаследовала логику chan.sip).
В камаилио(опен сер) ядро построено только на обработке сигнализации. Он честно добавит соответствующие заголовки и отправит дальше. Смотреть кто что там что объявил в SDP RTP не будет.
Логика камалио - передать сигнальную информацию от одной точки к другой.
Логика Asterisk - соединить двух юзеров по голосовому каналу.

[Zavr2008]

К сожалению, Asterisk слишком много (точнее все) хочет знать про внутренности SIP соединения

Asterisk просто не SIP proxy. А именно это явно нужно для подобной задачи. Почти большинство "облачников" используют камалию кста (втихаря конечно)..