AC
ну правильно, так и должно быть
Size: a a a
2020 December 02
BB
но pre_answer устанавливает двусторонний медиаобмен.
BB
а мне нужен односторонний. раньше этого можно было добиться как раз установкой ringback
AC
что нифига не логично
AC
пусть и полезно
А
Трафик экономите?
BB
это была единственная канальная переменная, изменение значения которой сразу влияло на сотсояние канала, а не на его поведение в будущем.
BB
что нифига не логично
тут согласен. нифига не логично и вообще выглядит дико. но лучше так, чем вообще никак.
BB
я бы с удовольствием заполучил какой-нибудь параметр к pre_answer, который указывал бы, обеспечивать односторонний (заодно с направлением) или двусторонний медиаобмен.
AC
ну, можно засунуть в конференцию и замьютить конечно
AC
но это адок
А
я бы с удовольствием заполучил какой-нибудь параметр к pre_answer, который указывал бы, обеспечивать односторонний (заодно с направлением) или двусторонний медиаобмен.
Зачем?
BB
надо :)
А
Если раньше работало думаю проблема в сопутсвующих параметрах. Например попробуй выключить аджаст ртп. Так как в твоём кейсе оно бессмысленно и я бы проверил в исходниках проверяется оно или нет
AC
надо :)
Вы для военных что-то делаете? Рации?
AC
там просто вроде есть модуль для этого
AC
я и не припомню ничего кроме радиостанций, что требовало бы sendonly в 183
BB
Вы для военных что-то делаете? Рации?
Нет, тут совершенно другая ситуация. Есть потенциальная возможность установления сессии между абонентами без фактического прихода ответа. Очень не хочется внезапно выяснить, что биллинг не увидел 200 ОК и поэтому разговор не посчитал.
BB
Или наоборот, что биллинг увидел двусторонний обмен RTP и посчитал это в разговор, когда не должен был.
А
Какие жадные