Односторонняя слышимость.
Избитая проблема.
пишу 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>
С голосом:
|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
sip дамп с сессии не дает представления о прохождении RTP UDP через NAT.
zzuz (Sep 24 '12)editОК, посмотрю непосредственно на RTP debug. Куда ещё покопать?
hexes (Sep 25 '12)editНичего нового, копать в сторону NAT.
zzuz (Sep 25 '12)editНу какого NAT? Если его нет? Говорю же, проблемы бывают в пределах одного свитча! PAP2TLine1 - свитч - * свитч - PAP2TLine2
hexes (Sep 25 '12)editа что тогда nat=yes стоит? для красоты?
zzuz (Sep 25 '12)editОно стоит для звонков из города, когда траф уходит за пределы сети (или нет?). Почему локальные звонки то себя так ведут?
hexes (Sep 25 '12)editВообщем ситуация совсем не понятная: 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 (Sep 25 '12)editМожет всё таки начать с мануала и разобраться с параметром nat ? для начала.
zzuz (Sep 25 '12)editВообщем появидась альтернативная идея: Т.к. * в локалку выходит ч/з тэгированный VLAN. И MTU VLANа=1500 и интерфейса =1500 то... часть пакетов не пролезает ч/з интерфейс. Понизил MTU VLANа до 1490. Помониторю.
Идею с NATом я не сильно рассматриваю, просто потому, что она плавающая. Как мне кажется при проблемах с NATом пакеты или ходят, или нет. Стабильно... А тут ч/з звонок.
Возможно я не прав?
hexes (Sep 25 '12)editНекоторые чрезмерно умные роутеры могут прикрыть порт во время сессии или закрыть его сразу же после сигнализации. Вариантов много. В дампах это всегда видно.
zzuz (Sep 25 '12)editЭто опять же подразумевает наличие этого самого "чрезмерно умного роутера"... У меня всё чрезмерно просто.
hexes (Sep 25 '12)editДа я прочитал про nat=yes, про симметричный RTP сервер. (Я так понимаю весь RTP траф. идёт ч/з *?) Но это мне не помогает понять где проблема...
hexes (Sep 25 '12)editИдею с MTU кажется стоит тоже отмести. (логично рассуждая) дамп я снял с VLAN интерфейса м/у * и РАР2Т, и в нём голос я слышал. Соответственно пакеты пролезли ч/з MTU интерфейса...
Если дамп с 2мя звонками (1 нормальный, 2ой без голоса) вам чтото скажет, буду очень благодарен если посмотрите!
hexes (Sep 25 '12)editкакой нафиг МТУ? голосовые пакеты длиной <100. если вы их перепаковываете - вы себе сам злобный буратино. елси у вас есть вланы,то очевеидно что у вас УЖЕ не все просто и есть умный роутер.
meral (Sep 25 '12)editНе перепаковываю =)
Умный роутер-маршрутизатор - НЕТ его! Свитч принимающий тэгированный VLAN с * врятли можно назвать умным. Он кроме этого ничего не умеет (3com 2226Plus).
Господа, я правда не могу назвать себя гуту VoIP. Поэтому обратился к вам за помощью. И Крайне признателен за то время которое вы на меня тратите...
hexes (Sep 26 '12)edit