Closed GoogleCodeExporter closed 9 years ago
Maybe as soon as a socket is connected over vpn there is a mechanism in the vpn
connectivity that ensures that the socket is alive.
It could explain why a packet is always sent when csipsimple is there
regardless of csipsimple settings if added by vpn layer. Probably any other app
that uses an UDP socket will produce the same result.
Two things could be interesting however :
1- update to latest version of the app that you can download and upgrade from :
http://nightlies.csipsimple.com/trunk/
2- wireshark/tcpdump the network traffic and see what is the packet sent (if
it's one from vpn layer or one from csipsimple (\r\n)
I have big doubts it comes from csipsimple for a very good reason... CSipSimple
is not aware of the kind of connectivity. There is no special code to handle
vpn case. The app then use simply unix network interface and it doesn't care on
how this interface is mapped.
The only code related to VPN is to detect when it comes alive or is stopped (to
update sip registration with relevant ip). But when connected the code is
exactly the same. So if you don't observe the same thing with vpn on or off...
I really think the packet comes from VPN layer.
There is only one thing that is to check (but it's more easy to see with latest
versions), it's that you correctly distinguish the keep alive for wifi and for
3g network. If the base connection is 3g one setting is taken into account, if
it's wifi another setting is taken into account. (there is also setting for
UDP/TCP/TLS transport).
Original comment by r3gis...@gmail.com
on 1 Aug 2012 at 9:07
I followed your advice and wiresharked the interface. It is indeed SIP traffic
that is sent over the tunnel, but it seems to originate from the server and not
csipsimple. So I will dig into my asterisk box and see why it does this. If
someone stumbles over this and has advice, please don't hesitate!
Thanks for your prompt reply!
Original comment by rikard.t...@gmail.com
on 2 Aug 2012 at 8:19
Oh, ok I didn't thought about that. Weird that it doesn't occurs when you are
not connected over vpn. Maybe it's not the same interface used for the asterisk
and so it behaves differently depending on the interface.
I'm not expert enough with asterisk to tell ;).
The behavior of the server can indeed have an influence on battery life. If you
have the hand on the server you may try to see if it's possible to use TCP
instead of UDP and to not send keep alives/SIP OPTION (some server are very
verbose and send regular sip options). This is very useful when trunking two
servers but for a mobile client it's bad ;).
Using TCP instead of UDP could allow to use higher keep alive interval and so
win precious battery.
Original comment by r3gis...@gmail.com
on 2 Aug 2012 at 8:29
I found out how to turn off the keep alives in asterisk. In sip.conf, set
qualify=no for the extension connected over wireless. Now my battery
consumption is back to normal. I still can't explain why this only happened
over vpn, it should not make any difference.
Original comment by rikard.t...@gmail.com
on 5 Aug 2012 at 8:37
I can add to the above that I experimented with the keep alive directive in
OpenVPN. When I turned the keep alive off, the android openvpn client responded
by reconnecting the tunnel altogether every 2 minutes, driving a lot of traffic
over the air interface. I am not sure if this is a bug or an intended behavior
(this is not the right forum to sort that out). Setting keep-alive 600 3000 in
server.conf mitigated this problem altogether. Now I only have minimal traffic
over radio once every 10 minutes bringing up my battery life time to very
confortable levels.
So, once again, thanks for a very nice sip client. Hope the above can help
users in need and keep people inside the csipsimple community.
Original comment by rikard.t...@gmail.com
on 7 Aug 2012 at 7:55
Original issue reported on code.google.com by
rikard.t...@gmail.com
on 1 Aug 2012 at 8:26