Sanjivkumarroshan / csipsimple

Automatically exported from code.google.com/p/csipsimple
0 stars 0 forks source link

cannot call when connected using reverse USB tethering #1681

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago
What steps will reproduce the problem?
1. connect telephone to computer using USB
2. switch to reverse tethering over USB
3. try to call

What is the expected output? What do you see instead?

the call should succeed, sending the packets via my PC

the call is refused with the message "Mobile network not available"

What version of the product are you using? On what operating system?

CSipSimple 0.03-01 r1108
Android 2.2.1

Please provide any additional information below.

I activated all the "For outgoing calls" options in the "Network" setup screen 
in CSipSimple but when I leave the Settings window I get the message "Selected 
network route not allowed with current settings you have setup". What does this 
mean? I'm connected to the the Internet (I can surf, ping www.google.com and 
ntpd works) but CSipSimple will not let me call. When I try to call I get the 
message "Mobile network not available". I know that I don't have mobile network 
coverage (I don't have a SIM card for example) but I am connected to the 
Internet.

Setting up reverse tethering is simple. Just activate tethering 

Setting -> Wireless & networks -> Tethering (Share your's mobile data 
connection via USB"

configure your PC to NAT, configure the USB interface with address 
192.168.42.162

and then run as root on your Android machine

route add default gw 192.168.42.162 dev usb0

Using this setup I can surf without wireless or a SIM card. But I cannot make a 
SIP calls using CSipSimple

I cannot find any combination of options in the "For outgoing calls" list that 
will let me call over my USB connection. Perhaps you can add an option that 
disable all checks and just tries to call.

Original issue reported on code.google.com by slp10...@pook.it on 14 Apr 2012 at 1:56

GoogleCodeExporter commented 9 years ago
In network settings for outgoing calls, have you activated the "Other network" 
option?
Maybe usb tethering is considered as a new connection type.

Also you could try with a nightly build : http://nightlies.csipsimple.com/trunk/

Original comment by r3gis...@gmail.com on 14 Apr 2012 at 2:19

GoogleCodeExporter commented 9 years ago
I tried with every outgoing calls option selected.

I'll try again with "Use WiFi" and "use other networks" selected. If the WiFi 
is on I can call. The packets go via my PC over USB (I'm inspecting them using 
wireshark to debug some connection problems). Packets cannot go via the WiFi 
interface because the telephone is connected to a WiFi access point that 
requires additional authentication via web page.

Once I switch the WiFi off I can no longer can call with CSipSimple. It no 
longer wants to register and when I quit the Setting window I get "Selected 
network route not allowed with current settings you have setup". I can still 
surf and wireshark shows the packets going via the USB connection.

When I switch the WiFi back on CSipSimple registers and I can call again. I 
still see the packets going via the USB connection.

I try a nightly build ASAP.

Original comment by slp10...@pook.it on 14 Apr 2012 at 5:59

GoogleCodeExporter commented 9 years ago
I have now CSipSimple-r1384 installed and I have exactly the same problem.  I 
have all the "For outgoing calls" options selected (including "Use other 
networks") and I can only call when the WiFi is active. As before I can see the 
DNS/SIP and RTP packets going over the USB connection but CSipSimple will only 
register if the WiFi is up.

If I start the brower with reverse USB tethering active and the WiFi off, the 
browser says

No network connection
Browser cannot load this page
because there is no internet
connection.

I then hit ok and the browser loads any page I want without any problems.

Original comment by slp10...@pook.it on 14 Apr 2012 at 6:29

GoogleCodeExporter commented 9 years ago
just for interest, my script, that I put into /data/local/bin/reverse, which 
turns USB tethering into reverse tethering looks like

#!/system/bin/sh
set -e
router=192.168.42.162
ping -w 1 -q -c 1 $router
route add default gw $router dev usb0
dns1=212.27.40.241
d=dns1
if ping -q -c 1 -w 2 $dns1
then
    setprop net.$d $dns1
    d=dns2
fi
dns2=212.27.40.240
if ping -q -c 1 -w 2 $dns2
then
    setprop net.$d $dns2
fi
#nslookup www.acm.org
ntpd -d -n -q -p ntp1.proxad.net -p ntp2.proxad.net

The nameserver addresses and NTP servers that you see are for the Free ISP in 
France.

Original comment by slp10...@pook.it on 14 Apr 2012 at 6:32

GoogleCodeExporter commented 9 years ago
Since you are using Free, I continue in french, tell me if you don't understand 
or prefer english ;).

Si je comprends bien, dans ton cas le système android crois qu'il n'y a pas de 
connection dispo. 
Vu que pour les APIs d'android n'arrivent pas à résoudre le type de 
connection (vu surtout que ce n'est pas une connection qu'android set lui 
même), mais elle est valide au niveau de la couche linux.
Du coup, en effet, tu te retrouve avec des applications qui sont un peu perdues 
(vu qu'en général elles demandent à priori aux API android le status de la 
connection).

Normalement, je dirais qu'il faudrai que tu essaies de trouver un moyen de 
forcer android à supporter ça en envoyant un broadcast bien placé dans ton 
script. Car ça fixerai le pb pour csipsimple mais pour toutes les applis 
android. Ceci dit je n'ai pas trop bien creusé ce genre de cas donc je ne 
pourrais dire quel est le broadcast à envoyer.

Cependant, pour d'autres uses cases j'ai des demandes pour simuler que quoi 
qu'il arrive csipsimple se connecte sans tenir compte du status renvoyé par 
android. Donc je vais avoir une fonctionalité qui pourrait aider dans ton cas. 
Je suis en train de l'ajouter.
Le gros souci, c'est que du coup je n'aurai aucun moyen de garantir la 
connection vu que rien dans android ne m'informera que la connection est valide 
ou pas + qu'elle change. Donc il faudra certainement jouer avec le fait qu'en 
rentrant dans les settings de csipsimple et en ressortant des settings je 
redemmare la stack pour tout re-enregistrer.
(Ou bien que tu envoies un broadcast dans ton script, avec le binaire qui va 
bien (de mémoire "am"), et il me faudra un 
http://developer.android.com/reference/android/net/ConnectivityManager.html#CONN
ECTIVITY_ACTION

Je suis en train de finaliser la feature pour ignorer l'état android et je met 
à jour cette issue.

Original comment by r3gis...@gmail.com on 14 Apr 2012 at 10:19

GoogleCodeExporter commented 9 years ago
This issue was closed by revision r1387.

Original comment by r3gis...@gmail.com on 14 Apr 2012 at 10:35

GoogleCodeExporter commented 9 years ago
I understand French but I'll reply in English just to keep things confusing.

I'm just starting to play with Android to see it can replace my Nokia N900 one 
day so I'm not an expert. It took me a while to find the magic commands to get 
the reverse tethering to work.

I hope that I have given enough information for you to set up reverse tethering 
if you wish to for testing. If not please ask (my PC is running Linux). Having 
all the packets going through my PC means that I can capture them using 
wireshark and try to understand why CSipSimple can connect to sip.ovh.fr and 
why my N900 cannot.

My use case is my Android phone is being used as a SIP phone without a SIM 
card. It is powered and connected to the Internet via USB and my PC. I use a 
Bluetooth headset when calling. I don't have a usable WiFi network around (I'd 
rather not activate my freebox's private network and FreeWifi tends to drop 
out) and in any case I try to avoid doing both bluetooth and WiFi on the same 
device at the same time (as BT and WiFi use the same frequencies).

The option that you are adding to ask CSipSimple to ignore the current network 
status and just try and register and call will certainly help me until I 
understand how to generate the signals to tell Android that it is connected.

I'm not sure exactly what I should do with the command "am". 

I tried

# am broadcast CONNECTIVITY_ACTION
Broadcasting: Intent { act=android.intent.action.VIEW dat=CONNECTIVITY_ACTION }
Broadcast completed: result=0

but I'm not sure how to tell Android that a network TYPE_ETHERNET is now active.

merci, Stuart

Original comment by slp10...@pook.it on 14 Apr 2012 at 10:57

GoogleCodeExporter commented 9 years ago
About the OVH config => 
http://code.google.com/p/csipsimple/source/browse/trunk/CSipSimple/src/com/csips
imple/wizards/impl/Ovh.java

So it's similar to basic config, with sip.ovh.net as registrar, proxy, user 
domain.
If you can get pjsip built on the N900 I can give you exact command line to run 
on the N900. (I never tried to play with pjsip on the N900, but it works pretty 
well on linux so, I guess it should be possible to build it on N900 as well).

Else, why don't you use directly your PC as SIP user agent? There is a lot of 
very good sip client for linux. On my side I often use Blink (based on pjsip 
like csipsimple), but also Twinkle, Empathy and Jitsi.

About the broadcast, I think that the correct command line will be the 
following :
# am broadcast -a "android.net.conn.CONNECTIVITY_CHANGE"

It will be useful for the next build. If I get time tomorrow morning I'll 
anticipate the build of noon, else it will be done automatically as r1387 or 
upper.

Original comment by r3gis...@gmail.com on 14 Apr 2012 at 11:23

GoogleCodeExporter commented 9 years ago
I am having the same problem. I'd really appreciate an option in csipsimple 
that allows all kind of connections so that reversetethering is also accepted.

This is by far the most important issue I found in cSipSimple

Original comment by calendar...@gmail.com on 4 Oct 2012 at 6:46

GoogleCodeExporter commented 9 years ago
Such an option exists :)

Switch to expert global setting mode : first section of this wiki page 
http://code.google.com/p/csipsimple/wiki/ExpertSettingMode?wl=en

Then go in network part. You'll see for outgoing and incoming section a last 
option to allow anyway. 
It will not immediately detect when reconnection is needed (as has no broadcast 
event sent by the android system) but :
 * you can force reconnection manually by going in settings and pressing back key.
 * you can activate the "Check network changes each.." option that is normally first intended for VPN support on 4.x but could also do the trick for this case. (in this case, select a value not too low to not drain battery too fast, but not to high to have things done almost automatically for your needs ;) ).

Original comment by r3gis...@gmail.com on 4 Oct 2012 at 9:37

GoogleCodeExporter commented 9 years ago
tried that, but csipsimple cannot get internet connection. i cannot even 
register with my sip provider (iptel.org), i get "Error while registering - 
Service Unavailable" or request timed out.
Tried enabling all kind of network connections and also only enabling "use 
anyway"
the reverse tethering software i am using is 
"http://forum.xda-developers.com/showthread.php?t=1371345"

Original comment by calendar...@gmail.com on 8 Oct 2012 at 12:00

GoogleCodeExporter commented 9 years ago
If you get this kind of error it's usually because there is an actual problem 
on network layer to reach the sip server.

Regarding the information on the xda post :

" The system detect automatically ports like http (80), https (443) , Market 
(5228),UDP ports like DNS, ..."

It seems to selectively choose some ports. Maybe those of SIP are not allowed 
to go through.
Did you succeed with any other SIP app?

Some remark on the xda thread post : (citation)" So unless the application is 
not well written, it must work." ...
The simple fact that (citation) "From Android Os point of vue, there is no 
internet connection." means that any well written application that checks 
network connection will fail think there is no connectivity... so I'm a little 
bit puzzled about what the author of this tool considers as a well written 
application.
Besides if only some port are mapped it will not work for any protocol using 
different port than the one already mapped. It's less efficient than something 
that adds a network route.

Apparently from screenshot there is some tabs on the windows app that could be 
useful to debug what's going on. So maybe you can try to observe what you see 
in Connections/debug tabs when the app is trying to register and see if there 
is some activity.

Original comment by r3gis...@gmail.com on 8 Oct 2012 at 12:12