Односторонняя слышимость.
Избитая проблема.
пишу 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
спросил
2012-09-24 14:58:11 +0400
hexes 11 ● 2 ● 2 ● 4
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 )редактировать