linphone-users
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Linphone-users] Linphone and Asterisk 11 - directrtpsetup / directmedia


From: Filip Malenka
Subject: [Linphone-users] Linphone and Asterisk 11 - directrtpsetup / directmedia
Date: Wed, 01 Apr 2015 14:16:36 +0200
User-agent: Mozilla/5.0 (X11; Linux i686; rv:31.0) Gecko/20100101 Thunderbird/31.5.0

Hi all,

thank you Linphone developers for your tremendous work and for your
clients for multiple platforms.

Currently I am strunggling with the directrtpsetup and directmedia on my
custom asterisk server behind NAT. I would like to have a working media
release mechanism to be able to interconnect two speaking peers directly
(P2P). I know that there is a limitation of this setup to clients, that
are NOT behind NAT, but since it is working partially with the Linphones
and their STUN/ICE capability, I am looking deeper into the problem.

I tried both ways directrtpsetup and directmedia with both failing at
some point. I would prefer to have directrtpsetup.

Linphone clients are all set up using STUN/ICE and STUN server set to
stun.linphone.org

When I call from a mobile client (Android - Linphone 2.3.2-348) via 3g
network to a client behind NAT, I get ringing, the call can be answered
on the other side, but then there is silence and call drops after few
seconds with a message that the other side is not responding.
Once I make a call the other way around, from NATed client to Android
client, there is success, I get all, sound, video, ZRTP verification code.
The most interresting thing is, that after I end this call (NAT ->
Mobile) I can establish another call in both directions (Mobile -> NAT
and NAT -> Mobile) and it works, sound, video, ZRTP. At least for a
while until e.g. I restart the NATed PC. Afterwards (Mobile -> NAT)
doesn't work anymore...
It's like something has been cached before, then it holds for a while,
allows communication in both ways and then it gets lost. Router?
Settings? I am using DD-WRT firmware on a D-Link DIR-300..

I have investigated the network traffic via Wireshark and the only thing
I can see is, that unsuccessfull calls (Mobile -> NAT) lead only to one
way UDP traffic like 192.168.1.105:7078 -> 85.xx.xx.xx:7076. The remote
IP isn't talking back to the 7078 port or it is, but not to the correct
NATed IP address.

I noticed, that when making outbound call from NAT, a STUN BINDING
REQUEST is sent to stun.linphone.org and my public address is correctly
set for the RTP communication.
When receiving an inbound call from Mobile, on NATed PC there is no STUN
request issued. Why? How is the remote Android client supposed to know,
to which public port to send Audio/Video?
Shouldn't the inbound call do a STUN request either?
What I can see as well, that there are couple of other "BINDING
REQUESTS" afterwards to and from client IP's. What are those? Should the
clients respond to these requests in a similar way like the
stun.linphone.org?

This behavior is the same when calling from one NAT to another NAT only
worse, because the clients behind both NATs won't find each other never.
Why doesn't the STUN/ICE handle these situations like expected?

With kind regards.
Filip.


Current sip.conf:
[general]
context=internal
videosupport=yes
textsupport=yes
accept_outofcall_message=yes
outofcall_message_context=astsms
allowguest=no
allowoverlap=no
bindport=5060
bindaddr=0.0.0.0
srvlookup=no
disallow=all
allow=gsm
allow=mpeg4
alwaysauthreject=yes
nat=force_rport,comedia
directrtpsetup=yes
keepalive=yes
externhost=xxxxx.xx
localnet=192.168.1.0/255.255.255.0
tlsenable=yes
tlsbindaddr=0.0.0.0
tlscertfile=/etc/asterisk/keys/asterisk.pem
tlscafile=/etc/asterisk/keys/ca.crt
transport=tls
tlscipher=ALL
tlsdontverifyserver=yes
tlsclientmethod=tlsv1

[7001]
type=friend
host=dynamic
md5secret=db69093ccea73123044d83410eec31f5
context=internal
transport=tls

[7002]
type=friend
host=dynamic
md5secret=156cd9603a912a279359498d99fbed3b
context=internal
transport=tls

[7003]
type=friend
host=dynamic
md5secret=a955e68e454a9003641afe5359f062fc
context=internal
callerid=PikoLino <7003>
transport=tls

[7004]
type=friend
host=dynamic
md5secret=3382a73ee4c17a2825bfe941f83a7f88
context=internal
callerid=Katka <7004>
transport=tls



reply via email to

[Prev in Thread] Current Thread [Next in Thread]