RTP

[tma]

Все зависит от используемого роутера... Многие почему-то ставят себе довольно-таки дешевые роутеры.
Даже старые модели Fritz!Box страдали от этого, томсоны всякие...

[serega_19]

всем спасибо за ответы, отвечаю на свои вопросы:
это нормально, что абонент А начинает отвечать на новый порт, так работает asterisk при NAT=yes

[serega_19]

да и абонент А не должен строго отвечать на порт по которому договорились в SDP, есть правило для T.38
перескакивать через порт с обоих концов при переходе на T.38
это особенность DSP процессоров некоторых вендоров
по хорошему, конечно это должно быть пересогласовано в SDP
но опять же есть масса устройств, которые обсуждают переход на T.38 не задействую сигнализацию и меняя при этом порт

[ys1797]

С каких это пор NAT поддерживает RTP ? Его как хочешь настраивай, а порты у машины внутри NAT и роутера снаружи будут разные. Именно для этого и используются стратегии изменения/резервирования портов во время сессии - собственно все описано в соответствующих RFC. Другое дело что RTP port discovery это только одна из трех проблем SIP/SDP которые приходится решать при NAT во время сессии.

NAT'у по фиг на RTP, он поддерживает UDP, про него и речь.
В отличие от TCP, NAT не может точно узнать, когда обмен по UDP закончился и грохнуть запись в таблице трансляции адресов.

Он их грохает, когда истек expirtion time для этой записи, т.е. нет активности, соответствующей этой записи трансляции.
В случае RTP - там активность довольно высокая, следовательно этот вариант маловероятен.

Если настройка expirtion time для udp записей довольно большое, это ведет к разбуханию таблицы трансляции и в какой-то момент достигнет лимита.
Вот тут-то и может произойти перескок порта, если грохнется нужная старая запись и вместо нее создастся новая.
Мне что-то кажется такой вариант тоже маловероятным, ну если только совсем уж мыльница с NAT'ом дохлая.

это нормально, что абонент А начинает отвечать на новый порт, так работает asterisk при NAT=yes

Если strictrtp="no" (rtp.conf) и nat="yes" так и будет.
Если strictrtp="yes" (rtp.conf) адрес установиться по первому принятому rtp пакету и не будет более меняться.

да и абонент А не должен строго отвечать на порт по которому договорились в SDP, есть правило для T.38

Пр чем тут T.38? передача трафика T.38 так-же описывается в SDP, как и голос, только там тип image.
При NAT'е все происходит аналогично голосу (при NAT="yes"), т.к. паранойную проверку в asterisk не делали для udptl

[tma]

Вот тут-то и может произойти перескок порта, если грохнется нужная старая запись и вместо нее создастся новая.
Мне что-то кажется такой вариант тоже маловероятным, ну если только совсем уж мыльница с NAT'ом дохлая.

В случае использования торрентов многие мыльницы не справляются. Голос просто пропадает и все тут.
После отключения торрентов все начинает работать. Поэтому пользователям, активно использующих торренты ставить
мыльницы в качество роутера я бы не советовал...

[gazizeldar]

Господа знатоки подскажите начинающему нубу
в rtp.conf выставлено по дефолту диапазон 10000-20000
настроено два транка.Проблемы при звонке звук то есть то нету
дебаг на rtp показал что запросы и ответы скачут почти до предела 65000
вот отрывок

PRIME_BBCODE_SPOILER_SHOW PRIME_BBCODE_SPOILER:

Got RTP packet from 192.168.0.19:57940 (type 00, seq 007898, ts 669640, len 000160)
Sent RTP packet to 92.46.61.21:23210 (type 08, seq 040450, ts 669640, len 000160)
Got RTP packet from 192.168.0.19:57940 (type 00, seq 007899, ts 669800, len 000160)
Sent RTP packet to 92.46.61.21:23210 (type 08, seq 040451, ts 669800, len 000160)
Got RTP packet from 192.168.0.19:57940 (type 00, seq 007900, ts 669960, len 000160)
Sent RTP packet to 92.46.61.21:23210 (type 08, seq 040452, ts 669960, len 000160)
Got RTP packet from 192.168.0.19:57940 (type 00, seq 007901, ts 670120, len 000160)
Sent RTP packet to 92.46.61.21:23210 (type 08, seq 040453, ts 670120, len 000160)
Got RTP packet from 192.168.0.19:57940 (type 00, seq 007902, ts 670280, len 000160)
Sent RTP packet to 92.46.61.21:23210 (type 08, seq 040454, ts 670280, len 000160)
Got RTP packet from 192.168.0.19:57940 (type 00, seq 007903, ts 670440, len 000160)
Sent RTP packet to 92.46.61.21:23210 (type 08, seq 040455, ts 670440, len 000160)
Got RTP packet from 192.168.0.19:57940 (type 00, seq 007904, ts 670600, len 000160)
Sent RTP packet to 92.46.61.21:23210 (type 08, seq 040456, ts 670600, len 000160)
Got RTP packet from 192.168.0.19:57940 (type 00, seq 007905, ts 670760, len 000160)
Sent RTP packet to 92.46.61.21:23210 (type 08, seq 040457, ts 670760, len 000160)
Got RTP packet from 192.168.0.19:57940 (type 00, seq 007906, ts 670920, len 000160)
Sent RTP packet to 92.46.61.21:23210 (type 08, seq 040458, ts 670920, len 000160)
Got RTP packet from 192.168.0.19:57940 (type 00, seq 007907, ts 671080, len 000160)
Sent RTP packet to 92.46.61.21:23210 (type 08, seq 040459, ts 671080, len 000160)
Got RTP packet from 192.168.0.19:57940 (type 00, seq 007908, ts 671240, len 000160)
Sent RTP packet to 92.46.61.21:23210 (type 08, seq 040460, ts 671240, len 000160)
Got RTP packet from 192.168.0.19:57940 (type 00, seq 007909, ts 671400, len 000160)
Sent RTP packet to 92.46.61.21:23210 (type 08, seq 040461, ts 671400, len 000160)
Got RTP packet from 192.168.0.19:57940 (type 00, seq 007910, ts 671560, len 000160)
Sent RTP packet to 92.46.61.21:23210 (type 08, seq 040462, ts 671560, len 000160)

<--- SIP read from UDP:192.168.0.19:55160 --->
BYE sip:942002@192.168.0.253:5060 SIP/2.0
Via: SIP/2.0/UDP 192.168.0.19:55160;branch=z9hG4bK-d8754z-0a7cd3973048a205-1---d8754z-;rport
Max-Forwards: 70
Contact: <sip:1000@192.168.0.19:55160;transport=udp>
To: <sip:942002@192.168.0.253>;tag=as3e3066c1
From: "1000"<sip:1000@192.168.0.253>;tag=8d112195
Call-ID: MjJlZTE1NmY1OWE0YTcyN2NlMzBmM2MwM2I4NTUxYzc.
CSeq: 2 BYE
User-Agent: X-Lite 4 release 4.1 stamp 63214
Content-Length: 0


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

<--- Reliably Transmitting (NAT) to 192.168.0.19:55160 --->
SIP/2.0 487 Request Terminated
Via: SIP/2.0/UDP 192.168.0.19:55160;branch=z9hG4bK-d8754z-5d12de89e4530c7a-1---d8754z-;received=192.168.0.19;rport=55160
From: "1000"<sip:1000@192.168.0.253>;tag=8d112195
To: <sip:942002@192.168.0.253>;tag=as3e3066c1
Call-ID: MjJlZTE1NmY1OWE0YTcyN2NlMzBmM2MwM2I4NTUxYzc.
CSeq: 1 INVITE
Server: Asterisk PBX
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH
Supported: replaces, timer
Content-Length: 0


<------------>
Sending to 192.168.0.19:55160 (NAT)
Scheduling destruction of SIP dialog 'MjJlZTE1NmY1OWE0YTcyN2NlMzBmM2MwM2I4NTUxYzc.' in 32000 ms (Method: BYE)

<--- Transmitting (NAT) to 192.168.0.19:55160 --->
SIP/2.0 200 OK
Via: SIP/2.0/UDP 192.168.0.19:55160;branch=z9hG4bK-d8754z-0a7cd3973048a205-1---d8754z-;received=192.168.0.19;rport=55160
From: "1000"<sip:1000@192.168.0.253>;tag=8d112195
To: <sip:942002@192.168.0.253>;tag=as3e3066c1
Call-ID: MjJlZTE1NmY1OWE0YTcyN2NlMzBmM2MwM2I4NTUxYzc.
CSeq: 2 BYE
Server: Asterisk PBX
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH
Supported: replaces, timer
Content-Length: 0


<------------>

<--- SIP read from UDP:192.168.0.19:55160 --->
ACK sip:942002@192.168.0.253;transport=udp SIP/2.0
Via: SIP/2.0/UDP 192.168.0.19:55160;branch=z9hG4bK-d8754z-5d12de89e4530c7a-1---d8754z-;rport
Max-Forwards: 70
To: <sip:942002@192.168.0.253>;tag=as3e3066c1
From: "1000"<sip:1000@192.168.0.253>;tag=8d112195
Call-ID: MjJlZTE1NmY1OWE0YTcyN2NlMzBmM2MwM2I4NTUxYzc.
CSeq: 1 ACK
Content-Length: 0


<------------->
--- (8 headers 0 lines) ---
Scheduling destruction of SIP dialog '182b5a0d3570dfd840783371703881b3@sip.telecom.kz' in 32000 ms (Method: INVITE)
set_destination: Parsing <sip:42002@sip.telecom.kz:5061> for address/port to send to
set_destination: set destination to 92.46.61.21:5061
Reliably Transmitting (no NAT) to 92.46.61.21:5061:
CANCEL sip:42002@sip.telecom.kz:5061 SIP/2.0
Via: SIP/2.0/UDP 88.204.235.202:5060;branch=z9hG4bK52d82332
Max-Forwards: 70
From: "1000" <sip:680744793@sip.telecom.kz>;tag=as46b06b6c
To: <sip:42002@sip.telecom.kz:5061>
Call-ID: 182b5a0d3570dfd840783371703881b3@sip.telecom.kz
CSeq: 102 CANCEL
User-Agent: Asterisk PBX
Content-Length: 0


---
Scheduling destruction of SIP dialog '182b5a0d3570dfd840783371703881b3@sip.telecom.kz' in 32000 ms (Method: INVITE)
== Spawn extension (DLPN_DialPlan2, 942002, 1) exited non-zero on 'SIP/1000-00000068'

<--- SIP read from UDP:92.46.61.21:5061 --->
SIP/2.0 200 OK
Via: SIP/2.0/UDP 88.204.235.202:5060;branch=z9hG4bK52d82332
From: "1000" <sip:680744793@sip.telecom.kz>;tag=as46b06b6c
To: <sip:42002@sip.telecom.kz:5061>;tag=1196309816-1337945138774
Call-ID: 182b5a0d3570dfd840783371703881b3@sip.telecom.kz
CSeq: 102 CANCEL


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

<--- SIP read from UDP:92.46.61.21:5061 --->
SIP/2.0 487 Request terminated
Via: SIP/2.0/UDP 88.204.235.202:5060;branch=z9hG4bK52d82332
From: "1000" <sip:680744793@sip.telecom.kz>;tag=as46b06b6c
To: <sip:42002@sip.telecom.kz:5061>;tag=1196309816-1337945138774
Call-ID: 182b5a0d3570dfd840783371703881b3@sip.telecom.kz
CSeq: 102 INVITE
Content-Length: 0


<------------->
--- (7 headers 0 lines) ---
set_destination: Parsing <sip:42002@sip.telecom.kz:5061> for address/port to send to
set_destination: set destination to 92.46.61.21:5061
Transmitting (no NAT) to 92.46.61.21:5061:
ACK sip:42002@92.46.61.21:5061;transport=udp SIP/2.0
Via: SIP/2.0/UDP 88.204.235.202:5060;branch=z9hG4bK52d82332
Max-Forwards: 70
From: "1000" <sip:680744793@sip.telecom.kz>;tag=as46b06b6c
To: <sip:42002@sip.telecom.kz:5061>;tag=1196309816-1337945138774
Contact: <sip:680744793@88.204.235.202:5060>

Астериск находиться за НАТ шлюз на freebsd/ с него проброшены порты 5060 и 5061 и диапазон 10000-20000 UDP
Почему Астериск не передает rtp в выставленном диапазоне?
ниже даю sip.conf и rtp.conf пробовал выставлять уже в rtp 5000-31000 dвсе вно подскакивает
Астериск 1,8,2
sip.conf

Код: Выделить всё

[general]
context = default
allowoverlap = no
;allowtransfer=no   
udpbindaddr = 0.0.0.0  
 tcpenable = no  ; Enable server for incoming TCP connections (default is no)
tcpbindaddr = 0.0.0.0  ; IP address for TCP server to bind to (0.0.0.0 binds to all interfaces)
srvlookup = yes
subscribecontext = default
allowexternaldomains = yes
allowguest = no
allowsubscribe = yes
allowtransfer = yes
alwaysauthreject = no
autodomain = no
callevents = no
checkmwi = 10
compactheaders = no
defaultexpiry = 120
dumphistory = no
externrefresh = 10
g726nonstandard = no
jbenable = no
jbforce = no
jblog = no
maxcallbitrate = 384
maxexpiry = 3600
minexpiry = 60
mohinterpret = default
notifyringing = yes
pedantic = no
progressinband = never
promiscredir = no
realm = asterisk
recordhistory = no
registerattempts = 0
registertimeout = 20
relaxdtmf = no
sendrpid = no
sipdebug = yes
t1min = 100
t38pt_udptl = no
tos_audio = none
tos_sip = none
tos_video = none
trustrpid = no
useragent = Asterisk PBX
usereqphone = no
videosupport = no
nat = no
 externip = 88.204.235.202
localnet = 192.168.0.0/255.255.0.0
disallow = all
allow = ulaw,alaw,g729
canreinvite=no
register = 680744793:XXXXXXXXX:680744793@sip.telecom.kz:5061
register => 0040937492:XXXXXXXXX@sipnet.ru
[kt_sip]
type = friend
username = 680744793
secret = XXXXXXXX
host = sip.telecom.kz
port = 5061
fromuser = 680744793
fromdomain = sip.telecom.kz
dtmfmode = info
insecure = very
context = from_kt_sip
port = 5061
disallow = all
allow = alaw
allow = ulaw
;allow=g729
canreinvite = no
;reinvite = no
registersip = yes
trunkstyle = customvoip
insecure = invite
[sipnet]
type=friend
username=0040937492
secret=XXXXXXXXX
host=sipnet.ru
fromuser=0040937492
fromdomain=sipnet.ru
dtmfmode=info
insecure=very
context=from_sipnet
disallow=all
allow=alaw
allow=ulaw
allow=g729
canreinvite=nonat
reinvite=no
registersip=yes
trunkstyle=customvoip
insecure=invite

Многочиленное и продолжительное гугление ничего не дали
первоначально рассматривал вариант думал что ОС Убунту из-за этого , но потом поставил ан Centos аналогичные проблемы.
Еще По идее входящие и исходящие пакеты Астериск должне пропускать через себя ? ну вот под типа такого
пир 1000------Астериск----------Сипнет
а rtp дебаге смотрю пакет идет сразу от локально IP с клиентом на транк Сипнета
Подскажите а то уже совсем запутался.