человеки воткнулись с ними: "Столкнулись с такой проблемой - в SDP входящего инвайта оператор присылает a=sendonly, на что FS корректно отвечает в 200 Ok a=recvonly, в результате медиа со сторон оператора игнорируется. Софтовый клиент в этом случае отвечает sendrcv и проблем с аудио нет. Оператор пытается решить вопрос."

собственно, проблема такая у Олега есть какие нить мысли?

хвост цитаты "Есть ли возможность со стороны FS игнорировать этот атрибут и всегда отвечать sendrcv?"

отловить можно в диалплане в switch_r_sdp, но пройдет ли модификация...

вот только поведение вроде как раз ожидаемое, есть канал односторонний, send, клиенткая сторона при этом будет игнорироваться, и это норма.

это да

call flow даже несколько сложнее: 1.начальный invite со стороны билайна с этим атрибутом в SDP, затем re-invite, уже без SDP. FS отвечает на этот re-invite используя SDP начального инвайта

call flow даже несколько сложнее: 1.начальный invite со стороны билайна с этим атрибутом в SDP, затем re-invite, уже без SDP. FS отвечает на этот re-invite используя SDP начального инвайта

да, и это норма

если нет новых данных - использовать старые

билайн говорит что типа во втором инвайте мы передаем управление SDP вам- вот и формируйте нужный SDP

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

хуйню они говорят..

надо поднимать rfc

самое простое поправить это в сорцах

нет

проблемы с обновлением, сопровождением.. а модификация сип на каме - норм

плюс фильтры

пробуем с ними транк организовать- может там call flow будет другой..

не получится - будем в сторону камаилио смотреть

Rewriting SDP switch_r_sdp: <action application="set"> <![CDATA[switch_r_sdp=(sdp here) ]]> </action>

Disable G.729b on outbound <extension name="disable-annexB" continue="true"> <condition field="${switch_r_sdp}" expression="/(.*)(m=audio \d+ RTP\/AVP)(.*)( 18 )(.*)/s"> <action application="export" data="sip_append_audio_sdp=a=fmtp:18 annexb=no"/> </condition> </extension>

да, находил такое, только вот где сам sdp взять?

вот только ХЗ повлияет ли это на ногу А

сильно врядли

а late negotiaton не помогает?

вот только ХЗ повлияет ли это на ногу А

в теории есть шанс, если вмешаться в согласование

это не пробовали

в общем попробуем продавить корректный call flow при подключении транком (хотя тут скорее всего они будут настаивать на mpls..), расскажу что получится..

Это странное поведение, но вроде есть метод offer sdp, когда инициатор сначала запрашивает медиа возможности терминатора

Обычно стремные циски таким страдают и прочий проприетат

Это странное поведение, но вроде есть метод offer sdp, когда инициатор сначала запрашивает медиа возможности терминатора

если по рфц, то даже если такого нет в фс - можно прикинуть сложность реализации, может и впилить сразу в апстрим.

чтобы не своими патчами было, а частью оф версии

сильно сомневаюсь что это по rfc sofia давно пилится не может быть чтоб такое проморгали если б оно оговаривалось

вот и надо смотреть стандарты

а софия весьма неидеальна, лично я пару сегфолтов им сдавал за первые пол года изучения

спрошу-ка я у билайна на основании чего предложен такой callflow, со ссылкой на rfc.

во пусть докажут что они правы)

сильно сомневаюсь, но кто его знает

<param name="inbound-codec-negotiation" value="scrooge"/> не помогает?

проверил - не помог этот параметр

А кто-нибудь знает как смотреть видео из конференцию, когда сам туда видео не вещаешь?

*ии

a=recvonly

это где?

в SDP от вас

И со звуком тоже?)

два медиа потомока в той части что для видео

коллеги, во фрисвич попадает вызов, условно на 79161234567, в диалплане матчится на правило 7(\d{10}) и дальше бриджуется в sofia/profilename/8$1@a.b.c.d при это фрисвич оригинатору посылает что вызывается нумер 89161234567. Как это можно запретить?

отключить rpid

<action application="export" data="sip_cid_type=none"/>

это в оригинаторе?

это перед бриджом

спасибо, помогло!

давайте договоримся все вопросы по FS задавать здесь

в @ru_voip более общие вопросы

да тут чёт даже не прочитал никто мессадж

никто не понял твоего послания

каюсь, пукан горел

если кому надо лиценз сервер для g729 излеченный от жадности - обращайтесь

В рф 729 не надо лицензировать

У дримвалкера была не жадная версия

не надо, но лицензсервер об этом не знает. приходится его учить с пощью ida

Или подключить открытый модуль

мы не ищем легких путей лол

зачем он нужен? Только недавно от него на астере избавился)

если кому надо лиценз сервер для g729 излеченный от жадности - обращайтесь

xxd ./orig_bin ./origbin.hex xxd ./izm_bin ./izmbin.hex diff -u ./origbin.hex ./izmbin.hex > ./origbin.patch origbin.patch сюда этого достаточно кому нужно тот применит patch ./origbin.hex < ./origbin.patch xxd -r ./origbin.hex ./path_bin

зачем он нужен? Только недавно от него на астере избавился)

Канала меньше ест? Но в целом да, сейчас не особо актуально

есть ещё места на нашей планетке где 512 kbit/s инета технологический предел

Есть же силки и прочие опусы

есть ли железо с их поддержкой не волновает?

и поддержка у оператора связи тоже похрен?

Я не знаю в рф операторов с 729 официально.

зачем его официально предоставлять если его тупо поддерживает все железо в инфраструктуре? просто дают перечень кодеков среди которых есть g.729а

И имхо больше половины таких звонков потребуют транскодинга

Всё железо это что?

Какая поддержка будет например на свиче?

провайдерские транковые шлюзы и софтсвичи клиентские ip-фоны и ATA

на софтсвиче нужна поддержка для IVR, MOH и факсов

Знатоки, подскажите такую вещь

вот есть у меня mod_conference и он всё аудио миксует путём транскодинга opus в L16 и потом обратно что бы отдать юзерам

Если юзеры начнут подключаться с L16, то должно это снизить нагрузку на процы за счет того что транскодинга не будет?

транскодинг будет всегда

сейчас на старой системе он выключен

и хотят на новой выключить

тьфу )

просто из L16 <> L16 меньше ресурсов чем OPUS <> L16

Тогда стоит проверить)

Заметно меньше ресурсов или так?

Сейчас у нас процы как раз из-за транскодинга напрягаются

заметно меньше, но от транскодинга совсем не избавиться это особенность конференций

И еще вопрос:

Когда я клиентом выставляю в sdp a=recvonly, то fs логично выдает a=sendonly

кто-то уже тут был с этой проблемой..

или не тут, а у нас на работе.. )

При этом он не может определить что клиент за NAT находится и шлет все пакеты на серый ip. Это ладно. На клиенте указал STUN и все нормально

fs отправляет видео и аудио пакеты на внешний iP, а у клиента чернота и тишина

алг выключен?

sip alg