siniypin at gmail.com Guest
|
Posted: Mon Jul 13, 2009 4:30 pm Post subject: [Freeswitch-users] port restricted NAT, SRTP problem |
|
|
Hi guys!
I'm a novice in VoIP world, and may be missing some important concepts, but recently I've faced a problem with client softphone residing behind a port-restricted NAT and a public FS server and can't find an explanation on why it is happening and how to escape it.
Okey, the problem is as follows. I have a client residing behind port restricted NAT. It can register at our public server and can issue a looped call and hear itself perfectly well. But when I call to speek to this natted guy from computer exposed to web without any routers he able to hear me for merely a second and then I become muted and he hear nothing. On the other side I can hear this guy quite good, though with slight jittery sound.
If I set bypass_media param in our server's external profile to true - everything works as it supposed to - we hear one another. But still there is a problem with call originating from that guy - it is being interrupted after some time (after about 30 sec).
Both clients are capable to do STUN and ICE and have these options enabled. Calls are secured with TLS and SRTP enabled on our server. FreeSWITCH is installed on Windows Server 2008 box with open UDP traffic and TCP, UDP ports 5080,5081 opened in order to expose an external profile. As far as I understand, with bypass_media param disabled FreeSWITCH is acting as media proxy and it is unable to do ICE and that should be a reason why that guy can't hear me. In overmentioned peer2peer scenario switching to no media mode is acceptable, but still there is a question whether this call with media flow bypassing FreeSWITCH is secured? I guess not. Cause I don't have any certificates installed on clients.
Also, we've plans to use our FreeSWITCH as a media conference server. And of course this guy failes to connect to the testing one.
Below are some of configurations:
vars.xml
...
<X-PRE-PROCESS cmd="set" data="external_rtp_ip=74.208.167.44"/>
...
external.xml
...
<param name="inbound-bypass-media" value="true"/>
...
public dialplan
<extension name="secure_media" continue="true">
<condition field="${sip_has_crypto}" expression="^(AES_CM_128_HMAC_SHA1_32|AES_CM_128_HMAC_SHA1_80)$" break="never">
<action application="set" data="sip_secure_media=true"/>
<action application="export" data="sip_secure_media=true"/>
<action application="playback" data="misc/8000/call_secured.wav"/>
</condition>
</extension>
<extension name="guard_auth" continue="true">
<condition field="${sip_authorized}" expression="^true$" break="never">
<anti-action application="respond" data="407"/>
</condition>
</extension>
<extension name="simple_conference">
<condition field="destination_number" expression="^(.*)\.conference\..{2}$">
<action application="conference" data="$1"/>
</condition>
</extension>
<extension name="one2one">
<condition field="destination_number" expression="(.*)">
<action application="bridge" data="sofia/external/$1%${domain_name}"/>
</condition>
</extension>
My SDP:
Remote SDP:
v=0
o=- 3456517465 3456517465 IN IP4 91.79.44.168
s=pjmedia
c=IN IP4 91.79.44.168
t=0 0
a=X-nat:2
m=audio 1142 RTP/SAVP 103 102 104 117 3 0 8 9 101
a=rtpmap:103 speex/16000
...
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
a=rtcp:1143 IN IP4 91.79.44.168
a=crypto:1 AES_CM_128_HMAC_SHA1_80 inline:ee+Xv9etM5t5w3DH5B1hR+i9lrt7BHQhzJIwFv7d
a=crypto:2 AES_CM_128_HMAC_SHA1_32 inline:ELeudfX0mgsL+0u7qzGOqdEfg891fMn281BJszkS
a=ice-ufrag:70db7dd4
a=ice-pwd:708804fe
a=candidate:H 1 UDP 39 91.79.44.168 1142 typ host
...
And this is the other guy SDP:
Remote SDP:
v=0
o=- 3456517469 3456517470 IN IP4 85.140.191.254
s=pjmedia
c=IN IP4 85.140.191.254
t=0 0
a=X-nat:8
m=audio 23374 RTP/SAVP 103 101
a=rtpmap:103 speex/16000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
a=rtcp:23375 IN IP4 85.140.191.254
a=crypto:1 AES_CM_128_HMAC_SHA1_80 inline:2m4YBCRid0h+5AIaIGmXaqelQsSuK3HP1jtAMoiG
a=ice-ufrag:182f5a61
a=ice-pwd:1d690863
a=candidate:S 1 UDP 31 85.140.191.254 23374 typ srflx raddr 192.168.2.2 rport 2796
...
PS sorry for a long post |
|