Сняв трейс варшарком выяснилось что проблема заключается в джиттере, при декодировании в варшарке джитера до 80мс - проблема с голосом исчезает.
Подскажите насколько верны настройки джиттера SIP в астериске:
sip_custom.conf :
jbenable=yes
jbforce=yes
jbresyncthreshold = 1000
jbimpl = adaptive
jbmaxsize = 700
jbtargetextra = 100
jblog = no
И вообще работает
ли он может где то ещё включить его нужно И работает ли он на DAHDI chan_dahdi.conf :
[channels]
context=from-pstn
signalling=fxs_ks
rxwink=300 ; Atlas seems to use long (250ms) winks
usecallerid=yes
hidecallerid=no
callwaiting=yes
usecallingpres=yes
callwaitingcallerid=yes
threewaycalling=yes
transfer=yes
canpark=yes
cancallforward=yes
callreturn=yes
echocancel=yes
echocancelwhenbridged=no
faxdetect=incoming
echotraining=yes
rxgain=0.0
txgain=0.0
callgroup=1
pickupgroup=1
jbenable = yes
jbmaxsize = 1000
jbresyncthreshold = 1000
jbimpl = fixed
Спасибо.
| Цитата: |
| при разговоре с sip->sip внутри астера |
Это как? Asterisk сам с собой "разговаривает" ?
Пока непонятно как передается media-трафик:
1) устройство1 --- Asterisk --- устройство2
2) устро1ство1 --- устройство2
Также немаловажно где (на каком/перед каким устройством) и с какими параметрами записывали трафик.
Уважаемый amateur - может джиттер у меня просто не работает - так как при декодированнии варшарком - голос становится иделаьным
а в реальности во время разговора пакеты могут доходить с разным интервалом задержки, что и создает звук плохого качества.
покажите настройки SIP и обоих пиров. (пароли и адреса можно убрать или скрыть)
Не факт, что вам в этом случае нужно использовать Asterisk для пересылки media-трафика. Во-первых, Asterisk сам вносит n-ное кол-во джиттера. Во-вторых, зачем грузить процессор ненужной работой. Если же все-таки нужно пересылать media-трафик через Asterisk (например, устройства не имеют прямой связи друг с другом, или требуется обработка media-трафика), не нужно использовать буфер компенсации джиттера в Asterisk. Оба IP-телефона наверняка тоже имеют свои буферы, а Asterisk только мешает им работать, создавая ненужную задержку перед отправкой media-трафика получателю.
deny=0.0.0.0/0.0.0.0
disallow=all
secret=zzzz
dtmfmode=rfc2833
canreinvite=no
context=perv-only
host=dynamic
trustrpid=yes
sendrpid=no
type=friend
nat=yes
port=5060
qualify=yes
qualifyfreq=60
transport=udp
encryption=no
callgroup=5
pickupgroup=5
allow=ulaw,alaw,gsm,h263,h263p
dial=SIP/1107
mailbox=1107@default
permit=0.0.0.0/0.0.0.0
callerid=zzzz
callcounter=yes
faxdetect=no
cc_monitor_policy=generic
и
[1300]
deny=0.0.0.0/0.0.0.0
disallow=all
secret=zzzzz
dtmfmode=rfc2833
canreinvite=no
context=perv-only
host=dynamic
trustrpid=yes
sendrpid=no
type=friend
nat=yes
port=5060
qualify=yes
qualifyfreq=30
transport=udp
encryption=no
callgroup=
pickupgroup=
allow=alaw,ulaw,g729
dial=SIP/1300
mailbox=1300@device
permit=0.0.0.0/0.0.0.0
callerid=zzz
callcounter=yes
faxdetect=no
cc_monitor_policy=generic
canreinvite=no
и
nat=yes
попробуйте сделать
directmedia=no
nat=no
вместо canreinvite опция называется directmedia
эти опции нужно поставить и в general, если не предполагается использовать NAT
Там нет возможности directmedia выставить
ЗЫ. в chan_sip.c в опции конфигурирования:
| Код: |
| } else if (!strcasecmp(v->name, "directmedia") || !strcasecmp(v->name, "canreinvite")) { |
так что использование canreinvite или directmedia сейчас не важно (я смотрел в 10.5.1)
Последний раз редактировалось: adt2k (Чт Июн 28, 2012 10:30)
jbenable=no
-Да
-Нет-RFC3581
-никогда-RFC3581
-route NAT no rport
?
Просто -Нет-RFC3581 выставить ?
jbenable=no
можно только в файлах конфигурациооных, в админке нет такой возможности
буфер должен быть включен и настроен на сервере и на клиенте.
Added after 58 seconds:
| Цитата: |
| тогда будет не эффективно использование буфера только на клиентской стороне. буфер должен быть включен и настроен на сервере и на клиенте. |
У нас два "клиента", у каждого свой буфер. Asterisk тут "третий лишний".
выставил - должен сразу результат появится ?? может чего перегрузить
Трейс снова снимать ?
при canreinvite=yes есть 1 связка клиент - клиент, и то не всегда.
Added after 1 minutes:
| Appela @ Чт Июн 28, 2012 15:34 писал(а): |
| "Нет-RFC3581" выставил - должен сразу результат появится ?? может чего перегрузить Трейс снова снимать ? |
это не ко мне вопрос. я через различные GUI не настраиваю и особенностей настроек не знаю.
Проблема прослеживается не постоянно, она то есть то нет.
Added after 1 minutes:
ребят такое впечатление что ДЖиттер не отрабатывает как надо.. либо настроен корявенько..
Added after 1 minutes:
причём позвонив ещё клиентам людям внутри астера (та же схема) у них тоже самое прослеживается проблема с голосом. Пропадает и восстанавливается.. Приоритет по Qos`у сделан
даже при 80 сип разговорах не больше 10% подымается загрузка проца + памяти Mem: 3631756k total, 1851672k used, 1780084k free, 93192k buffers
Added after 2 minutes:
Cpu(s): 2.1%us, 1.0%sy, 0.0%ni, 95.9%id, 0.1%wa, 0.6%hi, 0.3%si, 0.0%st
средняя загрузка
Added after 2 minutes:
Мне кажется необходимы рыть в сторону джиттера...
Кстати а на что влияет интернал тайминг ?
Added after 4 minutes:
Network QoS Settings:
---------------------------
IP ToS SIP: CS3
IP ToS RTP audio: EF
IP ToS RTP video: AF41
IP ToS RTP text: CS0
802.1p CoS SIP: 4
802.1p CoS RTP audio: 5
802.1p CoS RTP video: 6
802.1p CoS RTP text: 5
Jitterbuffer enabled: Yes
Jitterbuffer forced: Yes
Jitterbuffer max size: 200
Jitterbuffer resync: 1000
Jitterbuffer impl: adaptive
Jitterbuffer tgt extra: 40
Jitterbuffer log: Yes
| Код: |
| jbenable = yes ; Enables the use of a jitterbuffer on the receiving side of a ; SIP channel. Defaults to "no". An enabled jitterbuffer will ; be used only if the sending side can create and the receiving ; side can not accept jitter. The SIP channel can accept jitter, ; thus a jitterbuffer on the receive SIP side will be used only ; if it is forced and enabled. jbforce = no ; Forces the use of a jitterbuffer on the receive side of a SIP ; channel. Defaults to "no". jbmaxsize = 200 ; Max length of the jitterbuffer in milliseconds. jbresyncthreshold = 1000 ; Jump in the frame timestamps over which the jitterbuffer is ; resynchronized. Useful to improve the quality of the voice, with ; big jumps in/broken timestamps, usually sent from exotic devices ; and programs. Defaults to 1000. jbimpl = fixed ; Jitterbuffer implementation, used on the receiving side of a SIP ; channel. Two implementations are currently available - "fixed" ; (with size always equals to jbmaxsize) and "adaptive" (with ; variable size, actually the new jb of IAX2). Defaults to fixed. |
примерно так
при звонке появляется такое:
-- adaptive jitterbuffer created on channel SIP/1119-00007393
-- adaptive jitterbuffer created on channel SIP/1107-00007392
значит адаптивный джиттер включился и работает, но сразу сыпется такое:
Warning[69220]:chan_iax2.c:1149 jb_warning_output: Resyncing the jb. last_delay 0, this delay -998869, threshold 1000, new offset 998869
WARNING[6922]: chan_iax2.c:1149 jb_warning_output: Resyncing the jb. last_delay 0, this delay -61392, threshold 1000, new offset 61392
так вот вернёмся к джиттеру - после внесения изменений в файл:
sip_custom.conf :
jbenable=yes
jbforce=yes
jbresyncthreshold = 1000
jbimpl = adaptive
jbmaxsize = 700
jbtargetextra = 100
jblog = no
Кроме как sip reload - может сам процесс астериска перегрузить ? - этого не делал...может тогда это применится ?? или я немного не в теме....
Added after 41 minutes:
Есть может у других мысли по всему этому поводу ?
| Код: |
| jbenable=no |
| Код: |
| jbenable=yes jbforce=no |
Дальше делайте что хотите. Хоть ОС переустанавливайте.
а тогда jbenable=yes jbforce=no - как будет работать ? и вообще что оно даст ?
| Код: |
| jbenable=yes jbforce=no |
рекомендуемые насторойки
SIP:
jbimpl = adaptive
jbmaxsize = 2000
Тестировать буду сегодня.. Завтра дам ответ как работает.
Анесту и всем принимавшим участие большое спасибо.
Как приятно когда люди не посылают в различные документации на сотни страниц, а дельным советом могут помочь.
_________________
нанотехнолигии в области Asterisk
-A OUTPUT -p tcp -m tcp --dport 5060 -j DSCP --set-dscp 26
-A OUTPUT -p udp -m udp --sport 8000:60000 -j DSCP --set-dscp 46
-A OUTPUT -p udp -m udp --dport 5060 -j DSCP --set-dscp 26
-A OUTPUT -p tcp -m tcp --dport 1720 -j DSCP --set-dscp 26
-A OUTPUT -p udp -m udp --dport 1720 -j DSCP --set-dscp 26
-A OUTPUT -p tcp -m tcp --sport 5060 -j DSCP --set-dscp 26
-A OUTPUT -p udp -m udp --sport 5060 -j DSCP --set-dscp 26
Вот такой небольшой кусок из iptables .. Может он не верно настроен ?? Хотя тут всё предельно просто и ясно.
Кстати обещал отписаться по проблеме с голосом - траблы устранились..
Added after 1 hours 46 minutes:
Кстати, может кто знает ?
А как можно в режиме реального времени в астериске, при активном разговоре посмотреть а какой джиттер используется*??*
Если опять брать варшарк снимать трейс - вродибы всё хорошо всё снимается, но когда необходимо поглядеть разговор(сам голос в варшарке) необходимо сначала выбрать джиттер в который хотим декодировать - стандартно предлагает 50мс, при декодировании в 50 мс отчётливо слышны косяки в голосе - при декодировании в 100мс уже всё - всё чётко... Дак вот может есть возможность тогда и в варшарке послушать без декодирования, т.е. прослушать разговор в точности такой какой был записан
| Appela @ Пн Июл 02, 2012 07:37 писал(а): |
| QOS настроен на сервере.. ... |
если только на сервере этого мало.
должны и устройства настроены быть
_________________
нанотехнолигии в области Asterisk