WLAN selection by SSID - Githubissues

NG-Studio-Development / csipsimple

Automatically exported from code.google.com/p/csipsimple

0 stars 0 forks source link

Enhancement request: Being able to select which Network type to use is great for being Client to some Internet sip server. When attaching csip as Client to a local telephone System in the Office or at home it would be great to add an SSID filter to activate the account only when logged into th especified WLAN network. This avoids spamming sip invites into other networks. Also by bad luck such a network may contain a sip Server at the same private address as mine and thus possibly Trigger security alerts.

So thius has been merged into a duplicate that has been merged into a duplicate that has been merged into a wont fix. I.e. no intend to give any solution a chance either directly in csipsimple either bey plugin of llma/tasker. Sad to hear that. Will have to lookout for an alternative :(

If you read my comments on links given, you'll understand that the solution is to address this need with a plugin. It's a Wont Fix *IN THIS ISSUE LIST*!!! I would like to add that I develop CSipSimple on my free time (nights, weekends and holidays). I released it just in case it could benefit anybody else. There is no company behind CSipSimple and that's why you can't expect a pro support for it and instead it's expected users take time to learn by themselves. And that's also why there is absolutely no problem if you find an alternative that match better your needs. I can only advise you to look first at opensource/free as in speech alternatives such as Linphone, SipDroid and ImsDroid. However, couple of points as you don't want to read more the links given above : The app it's released under free/libre license anyone can contribute to it and the app has an API that allows third party apps to control sip accounts state. BTW, that's what was already done by some skilled users (a plugin for csipsimple for tasker exists). (https://github.com/luklanis/csipsimple-plugin/) I've a project that I also develop on my free time (and I've few..) to propose an opensource/free alternative to tasker/locale. This project will obviously include a plugin for csipsimple that will address most of needs listed in links above. But it will be a *different* project. It's not yet release because it takes time to finalize to avoid to get a lot of feedback from users. It also takes time because supporting csispimple and replying to everybody like I'm currently doing with you takes time and while this is done no code is produced ! So : - do not be sad - take control over software instead of being controlled by software. To do so, search and try to understand things by yourself. Learning leads to Knowledge, Knowledge to freedom !

> So : > - do not be sad > - take control over software instead of being controlled by software. To do so, > search and try to understand things by yourself. Learning leads to Knowledge, > Knowledge to freedom ! Only because you develop for free and you don't get my Point is no reason to get personel. For sure my knowledge should not be your concern since you don't even know me. And if you would know me your concern would surly be eben less ;-) Another poinr: I did read all the comments and not only the ones pointed to. I am not against a plugin solution in general. The Problem with plugins like this one is with th eredundancy they may introduce. Imagine I use tasker and your solution would use llma this requires me the redundant use of both apps which adds complexity and thus Problem potential as well as bettery load. The proposed plugin solution using tasker is a 3rd grade plugin solution where each grade Expresses the software complexity which in turn increases the probklem potential. The "3rd" comes from 3 APIs required to get the "required" function, and represent the minimal complexity of the solution (best case), wheras the worst case would go upt to 7th grade. In this precise case 6th grade may be more realistic which is still huge. In some situations even this complexity is no Problem when it is surpasses or neared by the direct implementation complexity (grade 0). If for instance you would Need to implement tasker like complexity into csipsimple to achieve the goal. So far for the academic in me getting the theoretical analysis point. Now to the app control me or me it thing: Having had a look into all the app Options I guessed that you were at least using the NetworkInfo structure to check th econnection states to be able to determine which Connection type is active and deciding wheter to Register or not. So my thought was that implementing the code for checking the WifiInfo structure in Addition to get the SSID would be very straight Forward (without having looked into the code) with near 0 complexity and much more future proven than any plugin solution. While I know a bit of Android, I did never develop for it. But I did consider having a look into th ecsipsimple code, but the "Won't fix" Status of the request refrained me from doing so as there seems to be no interest in getting zthis into the app itself. So if the "won't fix" is not th efinal word I may have a look and eventually contribute the code as time permits.

""" Only because you develop for free and you don't get my Point is no reason to get personel. For sure my knowledge should not be your concern since you don't even know me. And if you would know me your concern would surly be eben less ;-) """ Sorry if I was rude. I'm just really tired providing support instead of development. I repeat things hundred times and people does not take time to read and search by themselves. That was my point. Try to search and read by yourself first. """ Imagine I use tasker and your solution would use llma """ That's not true. A plugin can be compatible with llama, tasker and locale. A single plugin. """ Problem potential as well as bettery load. """ That's not true, these apps are designed to use as less battery as possible only being notified when conditions changes. Besides they factorize the treatment of these events which makes actually less battery consumption than if all apps register all android events. """ The "3rd" comes from 3 APIs required to get the "required" function """ This already exists in csipsimple and there is a stable API to control sip accounts/features. """ If for instance you would Need to implement tasker like complexity into csipsimple to achieve the goal. """ It's far to be simple to be done cleanly and to address all possible ideas. Your idea is only one that is requested. (It's indeed the one the most requested, but it's not the only one). Reimplementing something already implemented cleanly (a pluggable way) somewhere else is always loss of time and bad idea. """ Addition to get the SSID would be very straight Forward (without having looked into the code) with near 0 complexity and much more future proven than any plugin solution. """ You are absolutely right. Technically speaking would be very very simple to add only SSID. However, you do not take into account very important point : - User experience. Many users has no technical background and are afraid by too many settings. Introducing even more things for 5% users is maybe not a good idea. Keeping things simple is better. Simple and focused. Do one thing and do it well. That's what I try to do with csipsimple. That's why there is a stable 3rd party API usable for other app that would like to focus on secondary features (other than pure SIP). From your comment you are an engineer. The pure engineer approach is good, but when applied to user experience it become a nightmare for users. On this point, Apple approach changed things on the good way. 'There's an app for that' and each of their app is simple. They've done things to far for me as their approach results in restricting capabilities of software they distribute. I believe in the fact there is a way between the Apple way and the engineer way. This way implies each app focus on its topic, that they have a first level of configuration that is easy to use by user, and a second level of configuration for geek/expert. These apps should also be focused on one topic and provide a 3rd party api stable and documented to allow other apps focused on other topics to work with these apps. To give you an idea, I even resent having contacts list inside csipsimple. Apparently this is part of very expected scope of a SIP app; but that is not obvious. The approach having one app for each thing and app working together is really the one of Android. The entire android system software design is made to permit that, and internally use that. There is a phone app, a contact app, a internal telephony app. Each app provide a SDK extending the core SDK. Apps doing same thing implement the same sdk (see the openintent project). It produces apps independant, focused and leave users free to choose the best app for one topic. """ While I know a bit of Android, I did never develop for it. But I did consider having a look into th ecsipsimple code, but the "Won't fix" Status of the request refrained me from doing so as there seems to be no interest in getting zthis into the app itself. """ It's definitely a won't fix *inside* csipsimple. But definitely not a won't fix somewhere else. It is just a request that is not relevant of CSipSimple project as I strongly believe in the fact such feature should take place in a different apps focused on context aware settings. This will allow much more things : being aware of your GPS location, of your google calendar, of what the weather looks like outside... whatever you can imagine is possible in this case. And it will not become and endless run implementing all ideas of all users inside a *SIP* application. Instead, a context aware application is *made* to address this topic. So why re-inventing the wheel inside csipsimple? Why introducing more settings in the app that most users will not understand? Why not trying to do something that could be reused by other SIP app : linphone, sipdroid, imsdroid... if we succeed in doing some common interface between all open apps, only one plugin will be able to address all sip apps, leaving users free to choose their sip app and their context aware app.

""" That's not true. A plugin can be compatible with llama, tasker and locale. A single plugin. """ That was an example only """ That's not true, these apps are designed to use as less battery as possible only being notified when conditions changes. Besides they factorize the treatment of these events which makes actually less battery consumption than if all apps register all android events. """" Designed for battery saving or not, does not matter. The more apps the more battery load. """ This already exists in csipsimple and there is a stable API to control sip accounts/features. """ Ok, you doid not get the point. This is about application complexity and about API usage complexity in particular. This is not my lecture room so I won't go any deeperr into this. The complexity I stated is fact and has nothing to do with the existance of an API but the complexity generated by its use independent of th eAPI complexity itself. """ Addition to get the SSID would be very straight Forward (without having looked into the code) with near 0 complexity and much more future proven than any plugin solution. """ """ You are absolutely right. Technically speaking would be very very simple to add only SSID. However, you do not take into account very important point : - User experience. """ I do take many more things into consideration as what I write ;-) ! The "complex option" argument has a long beard and is just sign of bad design as I would tell my students ;-) The easisets way (not the only, and not always the best) is to pack the options inexperienced users would not use into an "expert" mode. Argument gone. In most cases this allows to hide away already existing options as well, cleaning up the overall interface for inexperienced users making it even more straight forward for them. """ The approach having one app for each thing and app working together is really the one of Android. The entire android system software design is made to permit that, and internally use that. There is a phone app, a contact app, a internal telephony app. Each app provide a SDK extending the core SDK. Apps doing same thing implement the same sdk (see the openintent project). It produces apps independant, focused and leave users free to choose the best app for one topic. """ Using a feature just because it is available and commonly used is not always a decision of good design. """ It's definitely a won't fix *inside* csipsimple. """ Np, I'll lookout for an alternative. """ It is just a request that is not relevant of CSipSimple project as I strongly believe in the fact such feature should take place in a different apps focused on context aware settings. This will allow much more things : being aware of your GPS location, of your google calendar, of what the weather looks like outside... whatever you can imagine is possible in this case. And it will not become and endless run implementing all ideas of all users inside a *SIP* application. Instead, a context aware application is *made* to address this topic. So why re-inventing the wheel inside csipsimple? Why introducing more settings in the app that most users will not understand? Why not trying to do something that could be reused by other SIP app : linphone, sipdroid, imsdroid... if we succeed in doing some common interface between all open apps, only one plugin will be able to address all sip apps, leaving users free to choose their sip app and their context aware app. """ This is a different kettle of fish being about context compexity and information relation. I agree with you that more complex rules like GPS and calendars are out of scope of csipsimple. But ethe WLAN optin is already buildin making it a relate information and SSID being part of it does not add much additional complexity. So for me SSID filtering still belongs into csipsimple. Am option with an condition is not really reinventing the wheel, neither. If we follow the separate what is separatable logic csipsimple would be separated into a keypad app, a sip app, an rtp ap, codec aps, audio output app, audio input app,... each of theam being separatable again,... Also if an external application is to be used (for GPS for instance), csipsimple should be the plugin by itself not requiring any plugin in between. This reduces application adn usage complexity a lot being less erro prone. Unfortunately I will have to move on. But regardless of that, thanks for this great app. Will keep it until I find my alternative.

@gaston : thanks a lot for the time you spent exposing your vision. Always 
enriching to have different points of view.

There is very interesting points you raise. However I think the big point is 
that you try to apply very academic/theorical approach to a system that works 
at much higher abstraction level than what you consider.
For example, the definition itself of an application on android is probably 
something that at your working level you would call more "module" or 
"component". 
And using this definition, your 
"""
If we follow the separate what is separatable logic csipsimple would be 
separated into a keypad app, a sip app, an rtp ap, codec aps, audio output app, 
audio input app,... each of theam being separatable again,...
"""
Is something absolute true and it's the case there is a module for each thing 
you describe. Everything related to sip currently uses pjsip stack that is 
totally modular. CSipSimple has a UI part that can be separated from the rest. 
It's the UI module (and in android a module is an application). CSipSimple has 
a service module that is what I call the API and that can be controlled by UI 
modules bundled with the app but also by any other apps with correct rights. 
The service module hold the glue with the pjsip implementation. And pjsip 
itself is separated into a lot of modules that have each a clean API. That's 
what made successful and easy the intergration of pjsip in Asterisk server to 
provide ICE feature first and what made asterisk developer choose pjsip for the 
next version of their server. That's also how all big software piece with a 
correct design works internally. For example, if you have a look to chrome 
browser code, you'll find a lot of component in it. Each separable from each 
other. That's what make possible to have in csipsimple the webrtc echo 
canceller and webrtc codecs. That's what make android os allowed to use webrtc 
echo canceller too.

These projects are complex compounded projects, and separating things into 
cleanly separated modules is very sane approach. It's the same for csipsimple. 
It's already internally separated into UI and service and it allows any other 
module to use this service. In android a module can be an app.
On very small apps doing just pure algorithm or implementing a single RFC, your 
points are very valid I think and it's good approach to keep things as simple 
as possible. However you can not apply that to all systems. The only rules that 
are good sense rule and applies to all informatics stuff I did is the : 

http://www.python.org/dev/peps/pep-0020/

That's the only thing that I always take into account (and that's why I love 
python ;) ). Other points should always be thought again when in front of a new 
system.

BTW you'll notice one point in the previous:
*Complex is better than complicated.*

So for me it's better to have a complex api usage in the middle than a 
complicated inline (by inline I mean integrated to the core app) code inside 
what manages pure connectivity. This because the complicated code inline will 
grow with users needs and requests as this topic definition is not yet final. 
It's not a RFC topic here, it's a topic to give a not fully defined feature to 
user. The feature to decide when *account* should be enabled. (It's different 
from when sip can use a connectivity/interface which is a different topic for 
me).
This feature should be addressed a (maybe several) focused way. And the current 
way I propose (and that is already partially implemented with the locale 
plugin), is to use a third party app dedicated to condition detection and set 
of settings accordingly. CSipSimple already have this working. It works and has 
no bug. If I introduce the code you propose, it's a risk to introduce bug for 
everybody. If done outside, it's less error prone for everybody as csipsimple 
will just continue working. And this feature development life-cycle can be 
managed outside. I don't care if the complexity rate of that based on an 
academic measure is higher. It's less complicated and easier to manage : 
 - for dev: as anyone can implement this feature the way they prefer and enhance this feature with whatever subfeature they want.
 - for users : as they only take this plugin if they need it and pick the plugin that gives them what they expect without needing upgrade of their core sip app.

Also :
In the face of ambiguity, refuse the temptation to guess.
When you guess :
"""
The more apps the more battery load.
"""
You guess it works this way on android. On some system your assumption is 
totally true. On Android you are mistaken. If you really start to learn and 
understand the internal of android you'll understand what consume battery and 
how what they call "apps" are loaded. Mobile OS system manages the cpu and 
multitasking a very different way than destkop apps. Apps are launched 
dynamically based on manifest of the apps (telling when it should be notified 
etc).
So if you have 10 apps registering for GPS and tracking GPS location, you'll 
consume way more battery than if you have only 1 app that track gps cleverly 
and inform the 10 others apps only when necessary. It will consume less cpu 
cycle and will consume less RAM. So 11 apps is better than 10 apps for your 
battery. (GPS is just an example it goes exactly the same if you want to check 
something periodically etc).

Also on android, apps even if marked 'running' does not necessarily consume cpu 
cycle. An app can be frozen in ram and consume 0 battery. Also apps != 
processes. Apps are just about bundling several component. And these components 
in android sdk are activities (ui), broadcast receivers (something that 
register some kind of hub) and services (something that is really a process 
running in background).
When you install csipsimple codecs plugin there is absolutely 0 battery 
overhead from these apps. Better, the process of these plugins apps does 
nothing even if the plugin is used.
So, again, the feature is important, understand and maybe I'll personnally do 
that. But it's not something that goes inside CSipSimple issue list. Maybe we 
can open an issue list somewhere else for plugins. But there will be no code 
commit inside csipsimple repository about that, and thus no issue list about 
that in csipsimple.
There will be a different project for the plugin somewhere else, maybe done by 
me, maybe done by other.

Academic approach is very important and very interesting to have as background. 
However, I think that you and your students should also have a look to real big 
projects and how these works, especially opensource projects. The best way to 
learn a system is to read good opensource code and understand it. I'm not 
saying csipsimple is internally a good code to read. I'm talking about OSes 
source code, about browser source code etc. The way I currently know android is 
that I've read their source code (also contributed to it), I've also 
intensively read the source code of the dalvik jvm. 
Even reading books you'll always miss important parts of systems. Books are 
good to have a first overview and have a background, but when you start to 
enter the internals, nothing will be as good as reading real source code of 
those knowing system internals. And each system/language is different and have 
different approach and you usually have to adapt these approach instead of 
trying to apply academic rules on these systems. That's why I'm very quick to 
ask anyone searching by themselves and learning by themselves, and why I 
quickly get very frustrated when you replied without trying to understand the 
problematic.

Original comment by r3gis...@gmail.com on 20 Nov 2013 at 11:26

In the face of ambiguity, refuse the temptation to guess. When you guess : """ The more apps the more battery load. """ Sorry, but this gets much to personal again. Your Point-of view is always the same, you know it all and yout Counter part has not the required knowledge. Also, there is no "akademic Point of view", just how stuff works and has been analyzed to work. So you can assume that I never guess, so th ebattery Topic above was not guessed but exactely works likje that in th escope of what I was stating. Movinbg the scope, be it only a bit, just for a Counter Argument to work is just distorting th ediscussion to non-sense. Also when asking others not to guess you should absolutely avoid to do so in first place. Whatever told you I was never part of a large Project (and I really assume that you don't believe that csipsimple is such a big project) or that I don't know how opensource works it must be guessing as you are completely wrong. Worthless to go on. This said, csipsimple has gone from my phone now. /colsed

NG-Studio-Development / csipsimple

WLAN selection by SSID #2555