[Freeswitch-users] NAT / UDP hole punching issue

Tihomir Culjaga tculjaga at gmail.com
Wed Feb 28 10:11:17 UTC 2018


Nope, this is a real life scenario and just the fact that it works when i
port forward the RTP range on the FS side proves everything network related
is working just fine.

My question here goes to FS team ....why FS is not sending any RTP packets
to a remote client even when the client advertises the public IP:PORT in
SDP..
Both client and FS uses STUN ( in network capture i see them communicate
with their stun servers respectively ). The client sends RTP toward FS
while FS does not.

how do i debug rtp forwarding on FS itself ... is there any debug i can
turn on ?





On 28 February 2018 at 10:34, Francesco Facco de Lagarda <
francesco at delagarda.com> wrote:

> Sorry to hear Tihomir.
>
>
>
> Is there ANYWAY you can test everything locally on same network (i.e.
> without stun, nat, etc..) maybe the issue isn’t with stun!
>
>
>
>
>
> *From:* FreeSWITCH-users <freeswitch-users-bounces at lists.freeswitch.org> *On
> Behalf Of *Tihomir Culjaga
> *Sent:* mercoledì 28 febbraio 2018 09:57
>
> *To:* FreeSWITCH Users Help <freeswitch-users at lists.freeswitch.org>
> *Subject:* Re: [Freeswitch-users] NAT / UDP hole punching issue
>
>
>
> RTP ports are defined. When i do a port forward for my RTP range i get my
> RTP audio working i guess due to rtp-auto-adjust feature on FS... but it
> should work without port forwarding.
>
>
>
> here simply FS is not starting to send RTP traffic to the client even if
> it notified its public IP:PORT in SDP on 200 OK.
>
>
>
> i see FS contacting a STUN server, getting the public IP:PORT and than ...
> doesn't send any RTP traffic towards the client... this is what its bugging
> me.
>
>
>
> T.
>
>
>
> On 28 February 2018 at 09:18, Francesco Facco de Lagarda <
> francesco at delagarda.com> wrote:
>
> Check your RTP ports .. in the fs config and the port forwarding on
> firewalls.
>
> Also, (two cent’s worth), I had a lot of problems with rtp (video and
> audio) using VErto.. in the end I read that if you don’t specify a stun
> server, by default it uses google’s.. I don’t know if its applicable in
> this case, but you never know!
>
>
>
> Good luck!
>
> F
>
>
>
> *From:* FreeSWITCH-users <freeswitch-users-bounces at lists.freeswitch.org> *On
> Behalf Of *Tihomir Culjaga
> *Sent:* mercoledì 28 febbraio 2018 09:01
> *To:* FreeSWITCH Users Help <freeswitch-users at lists.freeswitch.org>
> *Subject:* Re: [Freeswitch-users] NAT / UDP hole punching issue
>
>
>
> does anyone have a clue ? :=)
>
>
>
> On 27 February 2018 at 11:50, Tihomir Culjaga <tculjaga at gmail.com> wrote:
>
> hi,
>
>
>
>
>
> I have "no audio" issue with TLS and i hope someone could help as Im
> getting crazy ... literally :(
>
>
>
> my setup is like this:
>
>
>
> Phone <> NAT <> INTERNET <> NAT <FreeSWITCH>
>
>
>
> FreeSWITCH version: 1.6.12~64bit ( 64bit)
>
>
>
> I have a separate profile configured for TLS:
>
>
>
>     <param name="rtp-ip" value="192.168.100.60"/>
>
>     <param name="sip-ip" value="192.168.100.60"/>
>
>     <param name="apply-nat-acl" value="rfc1918"/>
>
>
>
>     <param name="ext-sip-ip" value="stun:stun.freeswitch.org"/>
>
>     <param name="ext-rtp-ip" value="stun:stun.freeswitch.org"/>
>
>
>
>     <!--<param name="aggressive-nat-detection" value="true"/>-->
>
>
>
>    <param name="tls-only" value="true"/>
>
>    <param name="tls-sip-port" value="15061"/>
>
>
>
>
>
>
> ============================================================
> =====================================
>
> Name                    tls-public
>
> Domain Name             N/A
>
> Auto-NAT                false
>
> DBName                  sofia_reg_tls-public
>
> Pres Hosts              192.168.100.60,192.168.100.60
>
> Dialplan                XML
>
> Context                 public
>
> Challenge Realm         auto_from
>
> RTP-IP                  192.168.100.60
>
> Ext-RTP-IP              stun:stun.freeswitch.org
>
> SIP-IP                  192.168.100.60
>
> Ext-SIP-IP              85.114.41.180
>
> TLS-URL                 sip:mod_sofia at 85.114.41.180:15061
>
> TLS-BIND-URL            sips:mod_sofia at 85.114.41.180:
> 15061;maddr=192.168.100.60;transport=tls
>
> WS-BIND-URL             sip:mod_sofia at 192.168.100.60:5066;transport=ws
>
> WSS-BIND-URL            sips:mod_sofia at 192.168.100.60:7443;transport=wss
>
> HOLD-MUSIC              local_stream://moh
>
> OUTBOUND-PROXY          N/A
>
> CODECS IN               PCMA
>
> CODECS OUT              PCMA
>
> TEL-EVENT               101
>
> DTMF-MODE               rfc2833
>
> CNG                     13
>
> SESSION-TO              0
>
> MAX-DIALOG              0
>
> NOMEDIA                 false
>
> LATE-NEG                true
>
> PROXY-MEDIA             false
>
> ZRTP-PASSTHRU           false
>
> AGGRESSIVENAT           false
>
> CALLS-IN                0
>
> FAILED-CALLS-IN         0
>
> CALLS-OUT               2
>
> FAILED-CALLS-OUT        2
>
> REGISTRATIONS           0
>
>
>
>
>
>
> i manage to register the phone with no problems but when i call the phone
> i get no audio;
>
>
>
> bgapi expand originate ${sofia_contact(tls-profile/agent2/
> nexios at 192.168.100.60)} &echo()
>
>
>
>
>
>
>
> FS sends the invite as:
>
>
>
>
>
> SDP in INVITE message from FS
>
>
>
>    v=0
>
>    o=FreeSWITCH 1519708899 1519708900 IN IP4 *85.114.41.180*
>
>    s=FreeSWITCH
>
>    c=IN IP4 *85.114.41.180*
>
>    t=0 0
>
>    m=audio *17480* RTP/AVP 8 101
>
>    a=rtpmap:8 PCMA/8000
>
>    a=rtpmap:101 telephone-event/8000
>
>    a=fmtp:101 0-16
>
>    a=ptime:20
>
>
>
>
>
> SIP Client responds with:
>
>
>
>    SDP in 200 OK from the client
>
>
>
>
>
>    v=0
>
>    o=- 3728718779 3728718780 IN IP4 *213.147.96.240*
>
>    s=pjmedia
>
>    b=AS:84
>
>    t=0 0
>
>    a=X-nat:0
>
>    m=audio *4002 *RTP/AVP 8 101
>
>    c=IN IP4 213.147.96.240
>
>    b=TIAS:64000
>
>    a=rtcp:4003 IN IP4 *213.147.96.240*
>
>    a=sendrecv
>
>    a=rtpmap:8 PCMA/8000
>
>    a=rtpmap:101 telephone-event/8000
>
>    a=fmtp:101 0-16
>
>
>
>
>
>
>
> So the UDP stream is: client( *4002 * ) <> ( *17480* )FS
>
>
>
> when i sniff the traffic (on both sides client/FS) using wireshark, i see
> RTP packets ( src:4002, dst:17480 ) leaving the client towards FS, but I
> don't see RTP packets ( src:17480, dst:4002 ) from FS side leaving
> towards the client.
>
>
>
>
>
> so my question, of course, is why FS is not sending RTP packets to the
> IP:PORT notified in 200 OK SDP from the client ? Did i miss some needed
> configuration ?
>
>
>
>
>
> in FS logs i see  *192.168.100.60 port 17480 -> 213.147.96.240 port 4002*
> but nothing is actually being sent out from FS
>
>
>
> 2018-02-27 11:13:02.733376 [DEBUG] sofia.c:6965 Channel
> sofia/tls-public/sip:agent2/nexios at 213.147.96.240:10551 entering state
> [ready][200]
>
> 2018-02-27 11:13:02.733376 [DEBUG] switch_core_media.c:4311 Audio Codec
> Compare [PCMA:8:8000:20:64000:1]/[PCMA:8:8000:20:64000:1]
>
> 2018-02-27 11:13:02.733376 [DEBUG] switch_core_media.c:4366 Audio Codec
> Compare [PCMA:8:8000:20:64000:1] ++++ is saved as a match
>
> 2018-02-27 11:13:02.733376 [DEBUG] switch_core_media.c:4227 Set
> telephone-event payload to 101 at 8000
>
> 2018-02-27 11:13:02.733376 [DEBUG] switch_core_media.c:3021 Set Codec
> sofia/tls-public/sip:agent2/nexios at 213.147.96.240:10551 PCMA/8000 20 ms
> 160 samples 64000 bits 1 channels
>
> 2018-02-27 11:13:02.733376 [DEBUG] switch_core_codec.c:111
> sofia/tls-public/sip:agent2/nexios at 213.147.96.240:10551 Original read
> codec set to PCMA:8
>
> 2018-02-27 11:13:02.733376 [DEBUG] switch_core_media.c:4572 Set
> telephone-event payload to 101 at 8000
>
> 2018-02-27 11:13:02.733376 [DEBUG] switch_core_media.c:4631
> sofia/tls-public/sip:agent2/nexios at 213.147.96.240:10551 Set 2833 dtmf
> send payload to 101 recv payload to 101
>
> 2018-02-27 11:13:02.733376 [DEBUG] switch_core_media.c:6588 AUDIO RTP
> [sofia/tls-public/sip:agent2/nexios at 213.147.96.240:10551] *192.168.100.60
> port 17480 -> 213.147.96.240 port 4002 *codec: 8 ms: 20
>
> 2018-02-27 11:13:02.733376 [DEBUG] switch_rtp.c:3875 Starting timer [soft]
> 160 bytes per 20ms
>
> 2018-02-27 11:13:02.733376 [DEBUG] switch_core_media.c:6806 Activating
> RTCP PORT 4003
>
> 2018-02-27 11:13:02.733376 [DEBUG] switch_rtp.c:4261 RTCP send rate is:
> 5000 and packet rate is: 20000 Remote Port: 4003
>
> 2018-02-27 11:13:02.733376 [DEBUG] switch_rtp.c:2534 Setting RTCP remote
> addr to 213.147.96.240:4003 2
>
> 2018-02-27 11:13:02.733376 [DEBUG] switch_core_media.c:6887
> sofia/tls-public/sip:agent2/nexios at 213.147.96.240:10551 Set 2833 dtmf
> send payload to 101
>
> 2018-02-27 11:13:02.733376 [DEBUG] switch_core_media.c:6894
> sofia/tls-public/sip:agent2/nexios at 213.147.96.240:10551 Set 2833 dtmf
> receive payload to 101
>
> 2018-02-27 11:13:02.733376 [DEBUG] switch_core_media.c:6917
> sofia/tls-public/sip:agent2/nexios at 213.147.96.240:10551 Set rtp dtmf
> delay to 40
>
> 2018-02-27 11:13:02.733376 [NOTICE] sofia.c:8023 Channel
> [sofia/tls-public/sip:agent2/nexios at 213.147.96.240:10551] has been
> answered
>
> 2018-02-27 11:13:02.733376 [DEBUG] switch_channel.c:3770
> (sofia/tls-public/sip:agent2/nexios at 213.147.96.240:10551) Callstate
> Change RINGING -> ACTIVE
>
> 2018-02-27 11:13:02.753388 [DEBUG] switch_ivr_originate.c:3686 Originate
> Resulted in Success: [sofia/tls-public/sip:agent2/n
> exios at 213.147.96.240:10551]
>
> 2018-02-27 11:13:02.753388 [INFO] switch_channel.c:3127
> sofia/tls-public/sip:agent2/nexios at 213.147.96.240:10551 Flipping CID from
> "" <0000000000> to "Outbound Call" <nexios>
>
> 2018-02-27 11:13:02.753388 [DEBUG] mod_commands.c:4788
> (sofia/tls-public/sip:agent2/nexios at 213.147.96.240:10551) State Change
> CS_CONSUME_MEDIA -> CS_EXECUTE
>
> 2018-02-27 11:13:02.753388 [DEBUG] switch_core_state_machine.c:584
> (sofia/tls-public/sip:agent2/nexios at 213.147.96.240:10551) Running State
> Change CS_EXECUTE
>
> 2018-02-27 11:13:02.753388 [DEBUG] switch_core_state_machine.c:650
> (sofia/tls-public/sip:agent2/nexios at 213.147.96.240:10551) State EXECUTE
>
> 2018-02-27 11:13:02.753388 [DEBUG] mod_sofia.c:198
> sofia/tls-public/sip:agent2/nexios at 213.147.96.240:10551 SOFIA EXECUTE
>
> 2018-02-27 11:13:02.753388 [DEBUG] switch_core_state_machine.c:328
> sofia/tls-public/sip:agent2/nexios at 213.147.96.240:10551 Standard EXECUTE
>
> EXECUTE sofia/tls-public/sip:agent2/nexios at 213.147.96.240:10551 echo()
>
>
>
>
>
>
>
> Regards,
>
> Tihomir.
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> _________________________________________________________________________
> Professional FreeSWITCH Consulting Services:
> consulting at freeswitch.org
> http://www.freeswitchsolutions.com
>
> Official FreeSWITCH Sites
> http://www.freeswitch.org
> http://confluence.freeswitch.org
> http://www.cluecon.com
>
> FreeSWITCH-users mailing list
> FreeSWITCH-users at lists.freeswitch.org
> http://lists.freeswitch.org/mailman/listinfo/freeswitch-users
> UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users
> http://www.freeswitch.org
>
>
>
> _________________________________________________________________________
> Professional FreeSWITCH Consulting Services:
> consulting at freeswitch.org
> http://www.freeswitchsolutions.com
>
> Official FreeSWITCH Sites
> http://www.freeswitch.org
> http://confluence.freeswitch.org
> http://www.cluecon.com
>
> FreeSWITCH-users mailing list
> FreeSWITCH-users at lists.freeswitch.org
> http://lists.freeswitch.org/mailman/listinfo/freeswitch-users
> UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users
> http://www.freeswitch.org
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freeswitch.org/pipermail/freeswitch-users/attachments/20180228/26bcdd6a/attachment-0001.html>


More information about the FreeSWITCH-users mailing list