IP address of caller should be written somewhere

[GoogleCodeExporter]

What steps will reproduce the problem?
1. Start CSipWitch with "local" account.
2. Call to this "local" account from some IP
3. Accept or reject the call
4. Go to log and open info of that call

What is the expected output? 
IP address of the caller is written somewhere.

What do you see instead?
caller_chosen_username@_my_ip_address

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

Please provide any additional information below.
Of course clicking to that log entry should dial back to caller's IP address 
(in similar way).

Original issue reported on code.google.com by vi0...@gmail.com on 24 Jul 2012 at 12:28

[GoogleCodeExporter]

Here, what do you mean by local? As far as I understood you also have a local 
sip server on your device.
If your "local" account is a basic with ip set to 127.0.0.1, it could be normal 
that you get the caller@your_ip_address since it's probably what the sip server 
at 127.0.0.1 gives as information to CSipSimple.

If by "local" you mean the local account created with local wizard. And that 
you reach directly the application (without using a sip server proxy in the 
middle), it's very weird. And I will need some logs (see HowToCollectLogs wiki 
page), in order to find a clue on why CSipSimple get the incorrect address.
I just did some tests with that (to be sure), but on my side it correctly 
display the correct remote ip. (depending on which client I use on remote side 
it shows remote_user@remote_ip or just "sip:remote_ip" (which is also valid as 
sip contact).

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

• Changed state: Need-Details

[GoogleCodeExporter]

I mean operation without a SIP server.

1. Start CSipSimple on a device which have IP address 192.168.99.9 on Wi-FI. No 
accounts in the list (except of that virtual "Local" account)
2. Start Twinkle on 192.168.99.2
3. In Twinkle, add account "qqq@192.168.99.9" (any username)
4. In Twinkle, call to "www" (any username)
5. In CSipSimple we have a call from "qqq@192.168.99.9"

The actual caller IP (192.168.99.2) is not visible.

I expect that if there is local internetless Wi-Fi networks with two devices 
with CSipSimple (both having "Local" account added), then after one device 
calls the other (by entering explicit IP address), the other can call back to 
the first's device (also by explicit IP).

Original comment by vi0...@gmail.com on 24 Jul 2012 at 1:31

[GoogleCodeExporter]

Imagine the use case:

1. You and your friend are far away from any networks, GMS or Wi-Fi or whatever.
2. You and your friend have two Android devices and want to use then as poor 
man's walkie-talkie.
3. You set up the first device as "Portable hotspot" (android version >= 2.3).
4. You friend connects to that hot spot.
5. Both you and your friend keeping CSipSimple active, with "Local" account 
(you also set "Start anyways" expert setting)
6. Your friend can call to you by entering "qqq@192.168.43.1".
7. But you can't easily call back to your friend because of you don't know what 
IP address your DHCP server has configured for him and CSipSimple does not show 
IP or remember the caller's IP.

Original comment by vi0...@gmail.com on 24 Jul 2012 at 1:43

[GoogleCodeExporter]

In comment #2, why in twinkle you add an account with the IP of the remote 
part????
Just add as account the IP of the twinkle PC.

In your case in point 3 of comment 2, the correct setting is 
"add caccount qqq@192.168.99.2" !! 

If you announce as account the .9.... it's just logic that csipsimple get as 
contact the account with .9. 
Try to change your twinkle account, you'll see it works just fine (I use it 
very often for my tests) and BTW it's a valid configuration while referencing a 
remote IP address in twinkle configuration when you want a local account in 
twinkle is wrong.

I'm even very surprised that you get the call established for more than 30sec 
because CSipSimple should not be able to find the route to twinkle to send the 
final invite and should timeout.

So as for your comment #2, it's absolutely logic that you get qqq@192.168.99.9 
... because you actually configured Twinkle to send that !!!! 
Also in twinkle if you configure properly as a local account for twinkle (I 
mean with the IP of the PC), you have to dial www@192.168.99.9 to reach 
csipsimple (because obviously in this case, you need to specify the IP of the 
other sip client you want to reach) and not just www.
Doing this clean configuration, you'll also be able to call a second client 
running on ip 192.168.99.10 by calling in twinkle zzzz@192.168.99.10

About the point 2, is that something you actually tested? If you setup 2 local 
accounts on two CSipSimple, normally it will display you the remote IP. In fact 
even without username because it's strict. It will display you as call log and 
as incoming call sip:REMOTE_IP

I think that you get confused with the Twinkle configuration. If you use two 
csipsimple (that does a proper local configuration and is not based on wrong 
input of the local IP address), it will just work properly.

Original comment by r3gis...@gmail.com on 24 Jul 2012 at 2:00

• Changed state: WrongConfig

[GoogleCodeExporter]

"If you setup 2 local accounts on two CSipSimple, normally it will display you 
the remote IP." -> OK, I'll test this with two CSipSimples later.

But in any case it looks like I can remotely cause CSipSimple to show 
"<sip:Arbitrary_text>" is calling and successfully start a call (normal, 
working, stays for > 30 seconds), probably impersonating someone (the only clue 
is that it shows my local's account name; nothing if the local account is not 
created). 

I have just experimented that it is working. So know your IP address => can 
call you with arbitrary caller's name. Is that insecurity inherent in SIP or 
CSipSimple can do something about that.

Probably such "direct IP" calls should be visibly different than normal calls 
mediated by SIP server.

Original comment by vi0...@gmail.com on 24 Jul 2012 at 3:46

[GoogleCodeExporter]

It's SIP... and the difference between From and Contact header fields.

Consider this situation :

You + a SIP registrar.
You configure that app to use the server *only* as registrar (not as proxy).

This is valid a valid SIP topology. 
When you'll call using this "account", you'll transmit to the remote side your 
"From" registered as the SIP address you are registered on the SIP registrar 
(so that the remote part will be able to contact you back whatever your current 
IP address). 
In this case you don't need to use the registrar as proxy to send the SIP 
packet. So no way the other side knows your registrar IP address else than with 
the From.
So here, you send as From requestor your "public registered sip address". 

However, there is actually a way for the application to retrieve the actual 
"remote" IP address, but it should not use it for user display. 
Simple reason for that : it could be the raw IP of the last b2bua between you 
and the REAL remote part. So it makes no sense display that. 

In fact in your Twinkle configuration of comment 2 here's what you are telling 
to twinkle to do :
"Twinkle please create an account that is announced as sip:qqq@192.168.99.9"
And it does. And actually.... if you have a look to twinkle logs... you'll see 
that it tries to register on 192.168.99.9 !!! And I guess that csipsimple 
doesn't accept this registration ;).
Then, when you call, what it does? Very simple... you didn't configured proxy.. 
so it takes the domain of the account '192.168.99.9' and adds the text you put 
in front ww... So you are calling "sip:ww@192.168.99.9"
And this is allowed by twinkle...because just like csipsimple the transport is 
there, shared by all accounts (even not registered ones) and is valid for calls.

Here, it does a direct call using no proxy, just like csipsimple does when you 
don't configure a proxy in expert setting mode, or just like it does when you 
use local account (but with local account I make sure that I annonce the 
correct IP address... unlike twinkle that just takes what you configured that 
is not necessarily valid !)

Then, about ~security~... Not sure it's really security you talking about but 
more something on how to be sure who's calling is actually the one announced... 
well first you have to remind that on landline calls, it's exactly the same 
problem and that the caller id is something that can be changed or hidden.

Besides, something you probably don't know... but on very low transport layer 
it's not a big deal to take the IP of somebody else.... so if at transport 
level it's not reliable... how could it be at application level ?!?

When you think about security you should go very deep to understand where is 
the root problem. 
If you see something at a very high level that rely on lower level by design 
not secure it's pointless to talk or try to fix the security issue on the 
higher level keeping security based on the same unsafe low level discriminent.

If you are looking for real security there is other ways much better and that 
are normlized like SIP over TLS, ZRTP etc.
SIP over TLS requires a topology and servers (it's for control plan)
ZRTP is used for media and can ensure that there is no man in the middle attack.

Original comment by r3gis...@gmail.com on 24 Jul 2012 at 4:24

[GoogleCodeExporter]

Thanks for the explanation (I'm new to the SIP protocol and was just 
[http://android.stackexchange.com/questions/22239/how-can-i-make-a-point-to-poin
t-voip-call-over-wifi looking] for ways to connect two Androids serverlessly).

Original comment by vi0...@gmail.com on 24 Jul 2012 at 6:09

[GoogleCodeExporter]

Ok :)

Yes SIP protocol is one very complicate. It allows a lot of topologies and 
possible configurations but it makes it very complicate to configure. The good 
side is that most things are possible with that. 
It's just about configuration then ;).

CSipSimple is based on a cross platform sip stack that respect very well sip 
protocol : it's pjsip. All done in CSipSimple is just to adapt it to android 
but that's just about integration. But everything related to SIP transactions 
are made by pjsip. Csipsimple just decides when to start and stop and fill the 
configuration from user input to pjsip stack.
I leave in CSipSimple an access to the sip stack with the expert settings in 
order to allow to address all configurations possible. 
Side benefit of using a cross platform sip stack is that it's robust and works 
well regarding SIP specifications. For example problems that could be 
encountered by sipdroid that is just for android and so try to guess IP 
addresses can't be encountered with pjsip because it has a more consistent and 
documented behavior.

For the anecdote, I started CSipSimple because of this problem in sipdroid and 
because my patches was not considered as interesting by sipdroid guys that 
target more usage with their service (pbxes.org). That's why I started to work 
re-using pjsip stack that is robust and well documented ;)

Original comment by r3gis...@gmail.com on 24 Jul 2012 at 8:06