Пожалуйста, войдите здесь. Часто задаваемые вопросы О нас
Задайте Ваш вопрос

Проблемы с односторонней слышимостью. Хаотичные.

0

Односторонняя слышимость.

Избитая проблема. пишу tcpdump-ом звонок. начинаю слушать. и... слышу оба голоса, в оба направления.

Записываю 2 звонка:

оба из города, на один и тот же шлюз, но разные линии(РАР2Т). Один нормально проходит, другой нет.

Т.е. у обоих я в записи слышу голос, но абоненты не слышат голос из города.

пров - * - РАР2Т

дамп снимал м/у * и РАР2Т

Проблема бывает и внутри с локальными звонками. Тогда все пиры находятся в пределах одной сети, одно адресное пространство, никаких натов.

[pap2t](!)
nat=yes
type=friend
host=dynamic
dtmfmode=info
disallow=all
allow=alaw
call-limit=1
deny=0.0.0.0/0.0.0.0
permit=10.1.1.0/255.255.255.0
canreinvite=no
qualify=300
callcounter=yes
callwaiting=no

[133](pap2t)
defaultuser=133
secret=xxx
context=km
callerid="ATC Line 3" <133>

[134](pap2t)
defaultuser=134
secret=yyy
context=km
callerid="ATC Line 4" <134>

image description image description

С голосом:

|Time     | 10.1.1.111                            |
|         |                   | 10.1.1.236        |                   
|40.966   |         INVITE SDP ( g711A)           |SIP From: sip:111111@10.1.1.111 To:sip:133@10.1.1.236:5060
|         |(5060)   ------------------>  (5060)   |
|40.979   |         100 Trying|                   |SIP Status
|         |(5060)   <------------------  (5060)   |
|40.992   |         180 Ringing                   |SIP Status
|         |(5060)   <------------------  (5060)   |
|44.184   |         200 OK SDP ( telephone-event)          |SIP Status
|         |(5060)   <------------------  (5060)   |
|44.184   |         ACK       |                   |SIP Request
|         |(5060)   ------------------>  (5060)   |
|44.191   |         RTP (g711A)                   |RTP Num packets:5338  Duration:106.738s SSRC:0x36223CC1
|         |(17932)  ------------------>  (16398)  |
|44.209   |         RTP (g711A)                   |RTP Num packets:5336  Duration:106.716s SSRC:0x1844FA61
|         |(17932)  <------------------  (16398)  |
|150.945  |         BYE       |                   |SIP Request
|         |(5060)   <------------------  (5060)   |
|150.945  |         200 OK    |                   |SIP Status
|         |(5060)   ------------------>  (5060)   |

Глухой:

|Time     | 10.1.1.111                            |
|         |                   | 10.1.1.236        |                   
|1640.920 |         INVITE SDP ( g711A)           |SIP From: sip:222222@10.1.1.111 To:sip:134@10.1.1.236:5060
|         |(5060)   ------------------>  (5060)   |
|1640.939 |         100 Trying|                   |SIP Status
|         |(5060)   <------------------  (5060)   |
|1640.953 |         180 Ringing                   |SIP Status
|         |(5060)   <------------------  (5060)   |
|1644.156 |         200 OK SDP ( telephone-event)          |SIP Status
|         |(5060)   <------------------  (5060)   |
|1644.156 |         ACK       |                   |SIP Request
|         |(5060)   ------------------>  (5060)   |
|1644.161 |         RTP (g711A)                   |RTP Num packets:1670  Duration:33.380s SSRC:0x5A357151
|         |(13556)  ------------------>  (16400)  |
|1644.183 |         RTP (g711A)                   |RTP Num packets:1669  Duration:33.369s SSRC:0xADAD41E9
|         |(13556)  <------------------  (16400)  |
|1677.561 |         BYE       |                   |SIP Request
|         |(5060)   <------------------  (5060)   |
|1677.562 |         200 OK    |                   |SIP Status
|         |(5060)   ------------------>  (5060)   |


    <--- SIP read from UDP:10.1.1.236:5060 --->
SIP/2.0 200 OK
To: <sip:134@10.1.1.236:5060>;tag=731d88e2d9417038i1
From: "asterisk" <sip:asterisk@10.1.1.111>;tag=as68ff9164
Call-ID: 7a40997337376e701762e9313f17f781@10.1.1.111:5060
CSeq: 102 OPTIONS
Via: SIP/2.0/UDP 10.1.1.111:5060;branch=z9hG4bK59d979ba
Server: Linksys/PAP2T-5.1.6(LS)
Content-Length: 0
Allow: ACK, BYE, CANCEL, INFO, INVITE, NOTIFY, OPTIONS, REFER
Supported: x-sipura, replaces

<------------->
--- (10 headers 0 lines) ---
Really destroying SIP dialog '7a40997337376e701762e9313f17f781@10.1.1.111:5060' Method: OPTIONS
Audio is at 18356
Adding codec 0x8 (alaw) to SDP
Reliably Transmitting (NAT) to 10.1.1.236:5060:
INVITE sip:134@10.1.1.236:5060 SIP/2.0
Via: SIP/2.0/UDP 10.1.1.111:5060;branch=z9hG4bK7f9e7b17;rport
Max-Forwards: 70
From: "8111111111" <sip:111111111@10.1.1.111>;tag=as2844ffd6
To: <sip:134@10.1.1.236:5060>
Contact: <sip:111111111@10.1.1.111:5060>
Call-ID: 14fb0b6d087aa3cc23b7983c51b5766c@10.1.1.111:5060
CSeq: 102 INVITE
User-Agent: Asterisk PBX 1.8.15.1
Date: Thu, 27 Sep 2012 03:14:12 GMT
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH
Supported: replaces, timer
Content-Type: application/sdp
Content-Length: 200

v=0
o=root 76669505 76669505 IN IP4 10.1.1.111
s=Asterisk PBX 1.8.15.1
c=IN IP4 10.1.1.111
t=0 0
m=audio 18356 RTP/AVP 8
a=rtpmap:8 PCMA/8000
a=silenceSupp:off - - - -
a=ptime:20
a=sendrecv

---

<--- SIP read from UDP:10.1.1.236:5060 --->
SIP/2.0 100 Trying
To: <sip:134@10.1.1.236:5060>
From: "111111111" <sip:111111111@10.1.1.111>;tag=as2844ffd6
Call-ID: 14fb0b6d087aa3cc23b7983c51b5766c@10.1.1.111:5060
CSeq: 102 INVITE
Via: SIP/2.0/UDP 10.1.1.111:5060;branch=z9hG4bK7f9e7b17
Server: Linksys/PAP2T-5.1.6(LS)
Content-Length: 0

<------------->
--- (8 headers 0 lines) ---

<--- SIP read from UDP:10.1.1.236:5060 --->
SIP/2.0 180 Ringing
To: <sip:134@10.1.1.236:5060>;tag=fbe03bfa725de560i1
From: "111111111" <sip:111111111@10.1.1.111>;tag=as2844ffd6
Call-ID: 14fb0b6d087aa3cc23b7983c51b5766c@10.1.1.111:5060
CSeq: 102 INVITE
Via: SIP/2.0/UDP 10.1.1.111:5060;branch=z9hG4bK7f9e7b17
Server: Linksys/PAP2T-5.1.6(LS)
Content-Length: 0

<------------->
--- (8 headers 0 lines) ---
list_route: no route
Scheduling destruction of SIP dialog '14fb0b6d087aa3cc23b7983c51b5766c@10.1.1.111:5060' in 6400 ms (Method: INVITE)
Reliably Transmitting (NAT) to 10.1.1.236:5060:
CANCEL sip:134@10.1.1.236:5060 SIP/2.0
Via: SIP/2.0/UDP 10.1.1.111:5060;branch=z9hG4bK7f9e7b17;rport
Max-Forwards: 70
From: "111111111" <sip:111111111@10.1.1.111>;tag=as2844ffd6
To: <sip:134@10.1.1.236:5060>
Call-ID: 14fb0b6d087aa3cc23b7983c51b5766c@10.1.1.111:5060
CSeq: 102 CANCEL
User-Agent: Asterisk PBX 1.8.15.1
Content-Length: 0


---
Scheduling destruction of SIP dialog '14fb0b6d087aa3cc23b7983c51b5766c@10.1.1.111:5060' in 6400 ms (Method: INVITE)

<--- SIP read from UDP:10.1.1.236:5060 --->
SIP/2.0 487 Request Terminated
To: <sip:134@10.1.1.236:5060>;tag=fbe03bfa725de560i1
From: "111111111" <sip:111111111@10.1.1.111>;tag=as2844ffd6
Call-ID: 14fb0b6d087aa3cc23b7983c51b5766c@10.1.1.111:5060
CSeq: 102 INVITE
Via: SIP/2.0/UDP 10.1.1.111:5060;branch=z9hG4bK7f9e7b17
Server: Linksys/PAP2T-5.1.6(LS)
Content-Length: 0

<------------->
--- (8 headers 0 lines) ---
Transmitting (NAT) to 10.1.1.236:5060:
ACK sip:134@10.1.1.236:5060 SIP/2.0
Via: SIP/2.0/UDP 10.1.1.111:5060;branch=z9hG4bK7f9e7b17;rport
Max-Forwards: 70
From: "111111111" <sip:111111111@10.1.1.111>;tag=as2844ffd6
To: <sip:134@10.1.1.236:5060>;tag=fbe03bfa725de560i1
Contact: <sip:353161@10.1.1.111:5060>
Call-ID: 14fb0b6d087aa3cc23b7983c51b5766c@10.1.1.111:5060
CSeq: 102 ACK
User-Agent: Asterisk PBX 1.8.15.1
Content-Length: 0


---
Scheduling destruction of SIP dialog '14fb0b6d087aa3cc23b7983c51b5766c@10.1.1.111:5060' in 6400 ms (Method: INVITE)

<--- SIP read from UDP:10.1.1.236:5060 --->
SIP/2.0 200 OK
To: <sip:134@10.1.1.236:5060>;tag=fbe03bfa725de560i1
From: "111111111" <sip:111111111@10.1.1.111>;tag=as2844ffd6
Call-ID: 14fb0b6d087aa3cc23b7983c51b5766c@10.1.1.111:5060
CSeq: 102 CANCEL
Via: SIP/2.0/UDP 10.1.1.111:5060;branch=z9hG4bK7f9e7b17
Server: Linksys/PAP2T-5.1.6(LS)
Content-Length: 0
удалить закрыть спам изменить тег редактировать

спросил 2012-09-24 14:58:11 +0400

hexes Gravatar hexes
11 2 2 4

обновил 2012-09-27 07:30:38 +0400

Comments

sip дамп с сессии не дает представления о прохождении RTP UDP через NAT.

zzuz ( 2012-09-24 15:40:27 +0400 )редактировать

ОК, посмотрю непосредственно на RTP debug. Куда ещё покопать?

hexes ( 2012-09-25 08:33:14 +0400 )редактировать

Ничего нового, копать в сторону NAT.

zzuz ( 2012-09-25 10:45:28 +0400 )редактировать

Ну какого NAT? Если его нет? Говорю же, проблемы бывают в пределах одного свитча! PAP2TLine1 - свитч - * свитч - PAP2TLine2

hexes ( 2012-09-25 11:23:31 +0400 )редактировать

а что тогда nat=yes стоит? для красоты?

zzuz ( 2012-09-25 11:37:32 +0400 )редактировать

Оно стоит для звонков из города, когда траф уходит за пределы сети (или нет?). Почему локальные звонки то себя так ведут?

hexes ( 2012-09-25 12:00:48 +0400 )редактировать

Вообщем ситуация совсем не понятная: Got RTP packet from 10.1.1.233:16426 (type 08, seq 003969, ts 421383292, len 000160) Got RTP packet from 10.1.1.233:16426 (type 08, seq 003970, ts 421383452, len 000160) Sent RTP packet to 10.1.1.233:16426 (type 08, seq 054568, ts 507597632, len 000160) Got RTP packet from 10.1.1.233:16426 (type 08, seq 003971, ts 421383612, len 000160) Sent RTP packet to 10.1.1.233:16426 (type 08, seq 054569, ts 507597792, len 000160) Got RTP packet from 10.1.1.233:16426 (type 08, seq 003972, ts 421383772, len 000160) Sent RTP packet to 10.1.1.233:16426 (type 08, seq 054570, ts 507597952, len 000160) Sent RTP packet to 10.1.1.233:16426 (type 08, seq 054571, ts 507598112, len 000160) Got RTP packet from 10.1.1.233:16426 (type 08, seq 003973, ts 421383932, len 000160) Sent RTP packet to 10.1.1.233:16426 (type 08, seq 054572, ts 507598272, len 000160)

Всё ходит, а голоса нет, перезваниваю с того же пира на тот же, всё есть...

hexes ( 2012-09-25 12:12:18 +0400 )редактировать

Может всё таки начать с мануала и разобраться с параметром nat ? для начала.

zzuz ( 2012-09-25 12:16:59 +0400 )редактировать

Вообщем появидась альтернативная идея: Т.к. * в локалку выходит ч/з тэгированный VLAN. И MTU VLANа=1500 и интерфейса =1500 то... часть пакетов не пролезает ч/з интерфейс. Понизил MTU VLANа до 1490. Помониторю.

Идею с NATом я не сильно рассматриваю, просто потому, что она плавающая. Как мне кажется при проблемах с NATом пакеты или ходят, или нет. Стабильно... А тут ч/з звонок.

Возможно я не прав?

hexes ( 2012-09-25 13:29:47 +0400 )редактировать

Некоторые чрезмерно умные роутеры могут прикрыть порт во время сессии или закрыть его сразу же после сигнализации. Вариантов много. В дампах это всегда видно.

zzuz ( 2012-09-25 13:36:41 +0400 )редактировать

Это опять же подразумевает наличие этого самого "чрезмерно умного роутера"... У меня всё чрезмерно просто.

hexes ( 2012-09-25 13:55:56 +0400 )редактировать

Да я прочитал про nat=yes, про симметричный RTP сервер. (Я так понимаю весь RTP траф. идёт ч/з *?) Но это мне не помогает понять где проблема...

hexes ( 2012-09-25 13:58:01 +0400 )редактировать

Идею с MTU кажется стоит тоже отмести. (логично рассуждая) дамп я снял с VLAN интерфейса м/у * и РАР2Т, и в нём голос я слышал. Соответственно пакеты пролезли ч/з MTU интерфейса...

Если дамп с 2мя звонками (1 нормальный, 2ой без голоса) вам чтото скажет, буду очень благодарен если посмотрите!

hexes ( 2012-09-25 14:02:30 +0400 )редактировать

какой нафиг МТУ? голосовые пакеты длиной <100. если вы их перепаковываете - вы себе сам злобный буратино. елси у вас есть вланы,то очевеидно что у вас УЖЕ не все просто и есть умный роутер.

meral ( 2012-09-25 14:58:31 +0400 )редактировать

Не перепаковываю =)

Умный роутер-маршрутизатор - НЕТ его! Свитч принимающий тэгированный VLAN с * врятли можно назвать умным. Он кроме этого ничего не умеет (3com 2226Plus).

Господа, я правда не могу назвать себя гуту VoIP. Поэтому обратился к вам за помощью. И Крайне признателен за то время которое вы на меня тратите...

hexes ( 2012-09-26 07:06:23 +0400 )редактировать

5 Ответов

0

у вас пробелмы либо

1) с интернетом

2) с роутером

3) с пониманием сути вопроса.

причем да, хаотичные. особенно 3.

ссылка удалить спам редактировать

ответил 2012-09-24 16:44:25 +0400

meral Gravatar meral flag of Ukraine
23347 24 20 177
http://pro-sip.net/

Comments

По пунктам: 1) причём тут инет? Если вы про прова, то от него траф долетает, я его в дампе слышу. Так же аналогичные проблемы в локалке. 2) роутер тоже причём? Проблемы возникают даже в локалке, без какой либо маршрутизации. 3) Поможете разобраться? В чём по вашему проблемы? (профи себя нигде не называл...)

hexes ( 2012-09-25 08:27:37 +0400 )редактировать

при том что у вас воип. то что он долетает не значит что звук хороший.например может долетать с задержкой в 500мс и посылаться абонентом нафиг как устаревший. 2) ну значит свич или сервер.3) проблемы в понимании как работает воип и как работает qos судя по всему.попытки мониторить воип неверными методами. если у вас через звонок - снимите дам из астериска sip set debug on, rtp set debug on и смотрите что с портами и адресами. но для этого опять таки надо понимать воип и сип.

meral ( 2012-09-25 14:56:39 +0400 )редактировать

Конечно глубокого понимания нет. Но основы я знаю. 2) что с ними может быть не так? 3) возможно. Пытаюсь разобраться. И буду благодарен за помощь!

hexes ( 2012-09-26 07:16:14 +0400 )редактировать

ну телепаты же в отпуске. если вы не можете разобраться,нанимайте специалиста(и желательно ен меня, ибо решение этой задачи неинтересно). ну откуда я заню что не так? дебажте. смотрите соответсвие портов в сип и ртп. смотрите таймстампы пакетов.

meral ( 2012-09-26 14:49:26 +0400 )редактировать

Пытаюсь... Думал мне здесь с этим и помогут. Ткнут в каком направлении копать...

hexes ( 2012-09-27 07:27:03 +0400 )редактировать
0

Давайте рассуждать логически... Если из дампа между * и Linksys слышно голос в обе стороны, то проблема где-то в Linksys (или телефоне к нему подключенному). Согласны?

ссылка удалить спам редактировать

ответил 2012-09-28 14:37:59 +0400

asteriskguru Gravatar asteriskguru
1160 4 5 21
http://www.asteriskguru.r...

Comments

не факт.

meral ( 2012-09-28 14:45:53 +0400 )редактировать

Аргументы?

asteriskguru ( 2012-09-28 22:35:10 +0400 )редактировать

Аргументы - такое бывает на разных РАР2Т. Грешу или на сеть, или на настройки * или РАР2Т. Так же думаю аргумент - хаотичность. 5 раз проходит всё ОК, один без голоса.

hexes ( 2012-10-01 07:18:30 +0400 )редактировать

настроил больше 5 сотен таких короочек. у всех все ок. ну кроме гдето десятка которым порты выжгли(так у них вообще звука нет)

meral ( 2012-10-01 19:07:28 +0400 )редактировать

2asteriskguru в моей практике были случаи с подобными симптомами изза еверной настройки роутеров и фаерволов. больше 5 случаев. отношения к оборудованию не имели.

meral ( 2012-10-01 19:08:44 +0400 )редактировать
0

разбирайтесь с VLAN'aми

ссылка удалить спам редактировать

ответил 2012-09-27 22:32:47 +0400

Out Gravatar Out
882 5 3 20

Comments

Объясните, что вы имеете ввиду? Что с ними разбираться?

hexes ( 2012-09-28 13:31:58 +0400 )редактировать
0

Советую запустить wireshark. Записать RTP сессию. Там есть RTP Analyzer - можно посмотреть есть ли проблемы с потоком, например jitter. Также там можно проиграть поток и убедиться а реально приходят ли голосовые данные. Далее: на самом астере с помощью tcpdump увидеть, а приходят ли они. И если нет NAT: тогда nat=never в настройках!

ссылка удалить спам редактировать

ответил 2012-09-27 21:27:53 +0400

Zavr2008 Gravatar Zavr2008 flag of Russian Federation
2886 11 9 40
http://mh.otx.ru/

Comments

Еще для диагногстики можно не пробрасывать звонок на пир дальше, а зарядить скажем на MusicOnHold. Убедиться что одно плечо хотя бы работает. Ну и еще совет поставить ключики tT в Dial - пусть через астер идет траф.

Zavr2008 ( 2012-09-27 21:29:38 +0400 )редактировать

у Линксиса заметил не стоит юзать всегда outbound proxy для исходящих! и сам outbound proxy - ПУСТОЙ!!!! На телефонах линксиса это часто приводило к проблемам. Еще прошиву попробовать обновить стоит.

Zavr2008 ( 2012-09-27 22:39:30 +0400 )редактировать

Jitter в пределах 1мс, есть небольшой промежуток 2.4-2.6. Проиграть поток в Wireshark? проигрывал, слышу оба голоса.

Спасибо за советы!

Есть ещё косяк, не уверен что он относится к делу. Когда на * звонят с сотового, то вместо гудков или MOH, слышно чтото невразумительное. Пинал прова, поменяли кодек с 729 на 711 всё стало ОК, но они "не могут работать на 711". На 729 такая фигня. Говорит разбираться со своей стороны.

hexes ( 2012-09-28 13:30:03 +0400 )редактировать

стоп - у тебя в город по SIP подключение? тогда причем тут линксис?

Zavr2008 ( 2012-09-30 16:04:52 +0400 )редактировать

Да в город SIP. схема: пров - eth1 - * - vlan1 - linksys pap2t Внутри локалки: linksys pap2t - vlan1 - * - vlan1 - linksys pap2t тоже бывают аналогичные проблемы с голосом.

hexes ( 2012-10-01 07:16:42 +0400 )редактировать

в сетке есть пакетлоссы? iperf гоняли?

Zavr2008 ( 2012-10-02 22:07:50 +0400 )редактировать
0

Nat=no пробовал?

ссылка удалить спам редактировать

ответил 2012-09-28 22:39:25 +0400

bolshoy_plohish Gravatar bolshoy_plohish
1388 25 20 38

Comments

А как голос в город ходить будет?

hexes ( 2012-10-01 07:19:08 +0400 )редактировать

Я вижу, что они у тебя в одной сети.

Кто у тебя за NAT-ом оказался.

Структуру сети опиши подробно.

bolshoy_plohish ( 2012-10-01 10:11:24 +0400 )редактировать

В город SIP. схема: пров - eth1 - * - vlan1 - linksys pap2t

Внутри локалки: linksys pap2t - vlan1 - * - vlan1 - linksys pap2t тоже бывают аналогичные проблемы с голосом.

hexes ( 2012-10-01 10:15:40 +0400 )редактировать

В транке который смотрит наружу из-за NAT nat=yes нужно ставить.

bolshoy_plohish ( 2012-10-01 10:44:26 +0400 )редактировать

Кто у тебя сидит за NAT-ом?

bolshoy_plohish ( 2012-10-01 10:49:40 +0400 )редактировать

Ваш ответ

Please start posting your answer anonymously - your answer will be saved within the current session and published after you log in or create a new account. Please try to give a substantial answer, for discussions, please use comments and please do remember to vote (after you log in)!
[скрыть предварительный просмотр]

Закладки и информация

Добавить закладку

подписаться на rss ленту новостей

Статистика

Задан: 2012-09-24 14:58:11 +0400

Просмотрен: 4,628 раз

Обновлен: Jul 22 '14

Проект компании "АТС Дизайн"
Asterisk® и Digium® являются зарегистрированными торговыми марками компании Digium, Inc., США.
IP АТС Asterisk распространяется под лицензией GNU GPL.