So, does anyone know why FS doesnt initiate rtp stream towards the client. So if its not a bug, i guess its the guy in between the keyboard and chair ;) What m’I missing? Sent from my iPhone
On 28 Feb 2018, at 11:11, Tihomir Culjaga <tculjaga@gmail.com> wrote:
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@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@lists.freeswitch.org> On Behalf Of Tihomir Culjaga Sent: mercoledì 28 febbraio 2018 09:57
To: FreeSWITCH Users Help <freeswitch-users@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@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@lists.freeswitch.org> On Behalf Of Tihomir Culjaga Sent: mercoledì 28 febbraio 2018 09:01 To: FreeSWITCH Users Help <freeswitch-users@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@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@85.114.41.180:15061
TLS-BIND-URL sips:mod_sofia@85.114.41.180:15061;maddr=192.168.100.60;transport=tls
WS-BIND-URL sip:mod_sofia@192.168.100.60:5066;transport=ws
WSS-BIND-URL sips:mod_sofia@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@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@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@8000
2018-02-27 11:13:02.733376 [DEBUG] switch_core_media.c:3021 Set Codec sofia/tls-public/sip:agent2/nexios@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@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@8000
2018-02-27 11:13:02.733376 [DEBUG] switch_core_media.c:4631 sofia/tls-public/sip:agent2/nexios@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@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@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@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@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@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@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/nexios@213.147.96.240:10551]
2018-02-27 11:13:02.753388 [INFO] switch_channel.c:3127 sofia/tls-public/sip:agent2/nexios@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@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@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@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@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@213.147.96.240:10551 Standard EXECUTE
EXECUTE sofia/tls-public/sip:agent2/nexios@213.147.96.240:10551 echo()
Regards,
Tihomir.
_________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@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@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@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@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org