AM
мне как обычно вчера надо все сделать, чтоб завтра работало
Size: a a a
2019 November 18
е
щас покажу, минутку
е
мне как обычно вчера надо все сделать, чтоб завтра работало
кажись у меня только кладётся. а проверку выключили. хаха.
<action application="limit" data="hiredis default ${caller_id_number}_world 1 limit_exceeded XML features"/>е
тут просто
АХ
кажись у меня только кладётся. а проверку выключили. хаха.
<action application="limit" data="hiredis default ${caller_id_number}_world 1 limit_exceeded XML features"/>он же и кладёт и проверяет
е
я чуть позже буду
АХ
если проверка не прошла - делает трансфер в limit_exceeded
PZ
Привет всем, может знает кто
почему инвайт на железку:
почему инвайт на железку:
Local SDP:
v=0
o=RINGME 1574063525 1574063526 IN IP4 213.170.66.150
s=RINGME
c=IN IP4 213.170.66.150
t=0 0
m=audio 24960 RTP/AVP 102 0 8 103 101
a=rtpmap:102 opus/48000/2
a=fmtp:102 useinbandfec=0; cbr=1; maxaveragebitrate=30000; maxplaybackrate=48000; ptime=20; minptime=10; maxptime=40
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:103 telephone-event/48000
a=fmtp:103 0-16
a=rtpmap:101 telephone-event/8000
А что вам смущает?серая сетка от железки?
е
он же и кладёт и проверяет
да? я давно это делал
Е
Pavel Z
А что вам смущает?серая сетка от железки?
dtmf не работает
почему он выбрал send payload to 103 recv payload to 101
тогда как только 103 48000гц
почему он выбрал send payload to 103 recv payload to 101
тогда как только 103 48000гц
Е
Причем, это в принципе не очень хороший подход у fs, т.к. разные железки в ответ дают разное- один выбрирает 101 8000Гц (и это почему-то fs слушает, наверное по-умолчанию), другой выбирает 103 c 48000
кто-то вообще выдвигал мысль, что dtmf2833 не нужна дискретизация
а самое смешное- что названивают какие-то спам-звонки, а у них все ок..
интересно, зачем вообще несколько telephone-event, если a=rtpmap:101 telephone-event/8000
прекрасно справляется?
кто-то вообще выдвигал мысль, что dtmf2833 не нужна дискретизация
а самое смешное- что названивают какие-то спам-звонки, а у них все ок..
v=0
o=Avaya 0 0 IN IP4 172.83.45.42
s=Avaya
c=IN IP4 172.83.45.42
t=0 0
m=audio 8000 RTP/AVP 18 3 110 8 0 97 101
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:18 G729/8000
a=fmtp:18 annexb=no
a=rtpmap:97 iLBC/8000
a=rtpmap:3 GSM/8000
a=rtpmap:98 AMR/8000
a=rtpmap:9 G722/8000
a=rtpmap:100 SPEEX/8000
a=rtpmap:99 AMR-WB/16000
a=rtpmap:102 SPEEX/16000
a=rtpmap:121 G7221/16000
a=fmtp:121 bitrate=24000
a=rtpmap:105 opus/48000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=sendrecv
интересно, зачем вообще несколько telephone-event, если a=rtpmap:101 telephone-event/8000
прекрасно справляется?
A
чтобы не менять частоту дискретизации на ходу
Е
ну тогда в принципе, все понятно,
проблема архитектурного решения (в скрине) - при частоте 8000Гц указывается все равно 48000/2 при этом dtmf в sdp завязывается на 48000
проблема архитектурного решения (в скрине) - при частоте 8000Гц указывается все равно 48000/2 при этом dtmf в sdp завязывается на 48000
Е
у fs все хорошо, у тех, кто отвечает на такое sdp- плохо(
Е
варианта указать opus/8000/2 вроде как нету? не нашел =(
A
логичнее всего согласовывать сразу оба пейлоада если присутствует wb кодек
Е
это все имхо, конечно же)
Е
логичнее всего согласовывать сразу оба пейлоада если присутствует wb кодек
сразу оба- что значит? не понял(
A
103 и 101