врядли в согласовании дело

вам скорее джиттер надо крутить

ага

ясно спасибо.сейчас потестируем разные варианты.

используйте Е1

я так и не понял, новостной канал сделали?

та не

речь шла про канал телеграма, где они анонсируют новые версии своего клиента

<param name="auto-jitterbuffer-msec" value="120"/> я как понимаю при этом параметре джиттер будет ставится автоматом при задерже 120 мс?? я правильно понял. и ккто как на практике принимает джитер?

на вики рекомендуют ставить <param name="use-jb-lookahead" value="1"/> для webrtc

на практике джиттер я не дергал, увы

только в очень специфичном сетапе, тут мой опыт не поможет

на вики рекомендуют ставить <param name="use-jb-lookahead" value="1"/> для webrtc

спасибо попробую

да не за что :)

<param name="auto-jitterbuffer-msec" value="120"/> я как понимаю при этом параметре джиттер будет ставится автоматом при задерже 120 мс?? я правильно понял. и ккто как на практике принимает джитер?

Джитер в любом случае есть, просто он бывает фиксированный, либо автонастраиваемый в зависимости от латенции канала

на 120 не сработал как надо. пару секунд разговора.потом пропадает и отбой.

добрый вечер

превед

нашел такую штуку в фс. чтобы регистрировались два одинаковыз номер multiple registrations

ага, есть такая

профиле выставил тру

но все равно звонок не приходит на оба номера(

в директории выставил <param name="max-registrations-per-extension" value="2"/>

а как вызов шлёшь?

покажи бридж

<action application="bridge" data="${sofia_contact(${dialed_extension}@${prospect.loc})}"/>

<!--<param name="multiple-registrations" value="contact"/>-->

эту строчку убирать с комента?

<!--<param name="multiple-registrations" value="contact"/>-->

тут вроде знание true надо

тру стоит

давай посмотрим что находится в ${sofia_contact(${dialed_extension}@${prospect.loc})} когда в него бридж идёт

эту строчку убирать с комента?

парсер игнорирует коментированные строки 1. посмотрите, чем отличаются разные регистрации, пробуйте менять dial-string в соответствии с отличными значениями 2. пробуйте другой sip ua

парсер игнорирует коментированные строки 1. посмотрите, чем отличаются разные регистрации, пробуйте менять dial-string в соответствии с отличными значениями 2. пробуйте другой sip ua

проверю спасибо

проверю спасибо

да пока нзчт

<action application="bridge" data="user/345" /

вот так оба номера заработали

давай посмотрим что находится в ${sofia_contact(${dialed_extension}@${prospect.loc})} когда в него бридж идёт

разобрался спасибо

пож)

а чо было то?

он на другойконтекст шел. чуть переделал конфиг и бридж сразу на номер сделал. и оба номера регисрацию прошли

сейчас хочу с таймаутами потестировать.если номер не ответил через 10 сек уходил на другой

leg_delay_start при мультирегистрации?

сейчас хочу с таймаутами потестировать.если номер не ответил через 10 сек уходил на другой

с 1 регой вряд ли выйдет

leg_delay_start при мультирегистрации?

а так можно? ) как опцию бриджа только знаю

ды вот я и спросил собственно)

если честно рассуждаю так что пришел звонок одновремено и указав таймаут уходил на другой номер(незнаю что получится но интересно

чё?

поддерживаю предыдущего оратора

http://www.sipro.com/G729.html

выходит, уже g729 бесплатный

а пруф где-то можно?

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

В рф этот кодек не лицензируем, и есть не жадный кодек от дримволкера

G.729 — Википедия https://ru.m.wikipedia.org/wiki/G.729

Раздел Лицензирование

Всем, привет, прошу совет Ситуация следующая - есть два вышестоящих оператора. При входящих с операторов на мой FS один шлет чисто rfc2833, второй оператор шлет и инбэнд и rfc2833. FS транслирует dtmf на IP-атс моего абона без изменнеий. Абону это не нравится, так как его атс детектит инбэнд и получаются задвоения. Что можно сделать на FS, чтобы он в сторону абонента отдавал либо инбэнд, либо RFC2833 при получении входящих с обоих вышестоящих операторов? Доп. условие - SIP-профайл в сторону операторов - один.

Всем, привет, прошу совет Ситуация следующая - есть два вышестоящих оператора. При входящих с операторов на мой FS один шлет чисто rfc2833, второй оператор шлет и инбэнд и rfc2833. FS транслирует dtmf на IP-атс моего абона без изменнеий. Абону это не нравится, так как его атс детектит инбэнд и получаются задвоения. Что можно сделать на FS, чтобы он в сторону абонента отдавал либо инбэнд, либо RFC2833 при получении входящих с обоих вышестоящих операторов? Доп. условие - SIP-профайл в сторону операторов - один.

и вам, привет изъять inband dtmf из rtp гораздо сложнее, чем не слать согласно rfc, пробуйте добавить <action application="set" data="dtmf_type=none"/> в dialplan при звонке в сторону "абона", которому не нравится

можно попробовать завести для него отдельный профиль с параметром <param name="dtmf-type" value="none"/>

есть более изящный вариант - выполнить: <action application="set" data="drop_dtmf=true"/> но я его не использовал, как оно работает не знаю

кроме того, последнее может вас оставить вообще без dtmf (ни один не пройдёт)

Благодарю за советы. Удалось задетектить с помощью start_dtmf. Он детектит inband и превращает в rfc2833. Но тут получется уже задвоение по rfc2833(( drop_dtmf и dtmf_type=none не помогли

Привет, нужна помощь, как я могу установить значение между кавычек в сип заголовке FROM (From: "" <sip:user@domain>;tag=vvvyc5F5FNUjm) ?

effective_*

+ origination_caller_id_name

+ origination_caller_id_name

о, в чём отличия? мне как раз завтра с ними ковыряться

effective не сработали, а вот origination_caller_id_name помогло, спасибо

А указать это через конфигурацию gateway возможно?

effective_* срабатывает только один раз

в профиле шлюза не факт что сработает как надо например export только в B-leg тупо не рабоатет

Ок, спасибо

А указать это через конфигурацию gateway возможно?

в блок variables

а потом ${sofia_gateway_data ${gw} ovar ${var}}

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

Господа, а кто как с биллингом общается? и с каким работаете если не секрет?

nibblebill, cgrates

ну и самописный

cgrates подключаю к фс через esl

nibblebill понятно

самописный - файловая очередь

cgrates как себя проявляет?

точнее так, что раньше дохнет от нагрузки fs или cgrates?

не тестили?

все зависит от обстоятельств, какую базу используете, какая сеть так-то cgrates конечно позже дохнет

но там если биллинг сдох то и звонки не проходят

эт понятно) само собой) спасибо за инфу

это не всегда само собой :) но cgrates хорош что мне нравится, его и в каму можно засунуть

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

Спасибо)

где достать нормальный мануал под LINKSYS PAP2T там стоооооооолько опций,основной мануал очень короткий и там нет про половину опций

google-> linksys pap2t administration guide / provisioning guide

+ origination_caller_id_name

а как задавать для blind transfer? когда делается transfer -bleg

аттендед работает, а такой нет

что именно задавать? name?

EXPORT (export_vars) [origination_caller_id_name]=[Transfer caller ID name на 102] EXPORT (export_vars) [effective_caller_id_name]=[Transfer caller ID name на 102] из лога