Database Info

sipdroid + guava running together

can some one please tell me how to get guava and sipdroid running together. When i install one the other installs on top of it ie. installed siproid 1st then installed guava but guava overwrite my files , and vice versa, help pls!!!!!

I'm not sure that you can, they are essentially the same program. Guava is just an edit of Sipdroid... Perhaps if you explain what you are trying to accomplish?

You could modify the guava source code available at gizmo5.com/guava and change the name of the program that is being installed.
Basically, Michael Robertson (gizmo5 guy) hired some guy to make a hacked version of sipdroid that would use google's services in some kind of an unauthorized manner (which ended up becoming GizmoVoice which was decent and free and then sort of disappeared, and now google owns gizmo5)
The coder didn't change the name of the program so it takes the place of sipdroid because they share the same installable "title." Has guava even been updated since August? I think it is running about a ten version's old copy of sipdroid at the core.
So it's really one or the other, unless you or another want to mess around with the guava code (which might prove useful to ChainsDD or the other dialer hackers) of using some kind of "unauthorized" way of calling using Google Voice and a gizmo5 account together. Good luck!

386 said:
You could modify the guava source code available at gizmo5.com/guava and change the name of the program that is being installed.
Basically, Michael Robertson (gizmo5 guy) hired some guy to make a hacked version of sipdroid that would use google's services in some kind of an unauthorized manner (which ended up becoming GizmoVoice which was decent and free and then sort of disappeared, and now google owns gizmo5)
The coder didn't change the name of the program so it takes the place of sipdroid because they share the same installable "title." Has guava even been updated since August? I think it is running about a ten version's old copy of sipdroid at the core.
So it's really one or the other, unless you or another want to mess around with the guava code (which might prove useful to ChainsDD or the other dialer hackers) of using some kind of "unauthorized" way of calling using Google Voice and a gizmo5 account together. Good luck!
Click to expand...
Click to collapse
i'm not a developer and wouldn't know what to do but it sounds like just changing the installable name would be easy for a developer. Could some developer please change this line of code and compile the program for me it doesnt have to be some exotic name guava would do just fine, Thanx in advance to who ever can help

SIP dialing for Gingerbread 2.3 Discussion

In reviewing the new page on the nexus s, the only thing I really am interested in is the internet dialing/SIP. I have tried SIPdroid on the captivate, and it works ok, but very staticy on the other end. I am curious as to whether anyone knows where the SIP client for 2.3 came from. Is it SIPdroid? Did Google buy SIPdroid? I would also be very interested in flashing only the SIP part of Gingerbread 2.3, the rest of the update isnt all that interesting to me. If anyone comes across info or files related to this, post here.
Thanks

Benny1234 said:
In reviewing the new page on the nexus s, the only thing I really am interested in is the internet dialing/SIP. I have tried SIPdroid on the captivate, and it works ok, but very staticy on the other end. I am curious as to whether anyone knows where the SIP client for 2.3 came from. Is it SIPdroid? Did Google buy SIPdroid? I would also be very interested in flashing only the SIP part of Gingerbread 2.3, the rest of the update isnt all that interesting to me. If anyone comes across info or files related to this, post here.
Thanks
Click to expand...
Click to collapse
Google bought Gizmo5 about 1 year ago. This is probably where they got the SIP client.

From what I read on the official document, internet calling works via wifi only.
I hope and i'm sure the devs will modify this to make it work via 3G.

A few things:
1) You are using VoIP over 3g? It's probably not goind to sound great, and any free client you have is not going to implement g729 b/c it requires a license so GSM is your best bet for low bandwidth, and it doesnt sound great.
2) a. No it is not sip droid. b. Sipdroid sucks - it is a terrible client. Basically the PBXes.org people who "wrote" sipdroid took the example "client" from mjsip and jammed an android interface on it. The backend sip implementation is pretty crappy, doesnt support call transfer, does multiple registrations and can flood a registrar.
2) CSipSimple is a much more promising client (IMO). And while has not yet implemented transfers yet, it is based on pjsip, a very well implemented sip stack that does fully support these features. Also, I have found that CSipSimple has less fuzzy audio too.
3) I have been looking at the 2.3 SIP stuff - It's not like you can just take that part from 2.3 and "flash" it to your device.
Besides that, the implementation that is in the 2.3 SDK looks very simplistic so far - and it is unclear to me whether or not the dialer will allow native SIP calling, or if google has just put in sip libraries for people to develop SIP applications. I see no where in any settings that allow you to specify "phone wide" sip credentials.
This would seem to be further backed by the sample "walkie talkie" application that is available with the 2.3 sdk.
4) I doubt google bought gizmo5 for their sip stack/client. There are many highly compliant open source sip stacks freeley available: sofia-sip, pjsip, jain-sip etc. etc. I dont know what is "under the hood" but what google has exposed via the SipProfile so far looks to be sub-par.
5) "Internet calling" support isnt going to be enabled on all devices, although i think the nexus s probably will be one of the few, in fact even in the AVD I get an "internet calling not supported" message when I try to call a sip URI from the dialer.
Your best bet right now - try out CSipSimple. Native SIP support is going to be a bit raw for a while is my guess.

SIP dialing
Thanks etamme ! Thats some good information! Yeah I would like to use SIP for international calls, wifi and 3G data. I use the phone when we travel and have foreign sims. So making GV /G5 calls would be perfect. I used to use an iphone, but unlocking became a PITA recently. (read as 6.15.00 BB)
Will check out CSSipSimple, I assume it will work with G5. I'm glad someone else realizes Sipdroid is terrible. Every time I use it the other party complains. With all the updates theyve done they have failed to address a major problem.
Thanks again!

have you tried this?
i'm trying it now
http://androidandme.com/2010/12/news/how-to-place-and-receive-internet-calls-with-android-2-3/

Benny1234 said:
I am curious as to whether anyone knows where the SIP client for 2.3 came from.
Click to expand...
Click to collapse
Gingerbread has a built-in SIP stack.

etamme said:
A few things:
1) You are using VoIP over 3g? It's probably not goind to sound great, and any free client you have is not going to implement g729 b/c it requires a license so GSM is your best bet for low bandwidth, and it doesnt sound great.
2) a. No it is not sip droid. b. Sipdroid sucks - it is a terrible client. Basically the PBXes.org people who "wrote" sipdroid took the example "client" from mjsip and jammed an android interface on it. The backend sip implementation is pretty crappy, doesnt support call transfer, does multiple registrations and can flood a registrar.
2) CSipSimple is a much more promising client (IMO). And while has not yet implemented transfers yet, it is based on pjsip, a very well implemented sip stack that does fully support these features. Also, I have found that CSipSimple has less fuzzy audio too.
3) I have been looking at the 2.3 SIP stuff - It's not like you can just take that part from 2.3 and "flash" it to your device.
Besides that, the implementation that is in the 2.3 SDK looks very simplistic so far - and it is unclear to me whether or not the dialer will allow native SIP calling, or if google has just put in sip libraries for people to develop SIP applications. I see no where in any settings that allow you to specify "phone wide" sip credentials.
This would seem to be further backed by the sample "walkie talkie" application that is available with the 2.3 sdk.
4) I doubt google bought gizmo5 for their sip stack/client. There are many highly compliant open source sip stacks freeley available: sofia-sip, pjsip, jain-sip etc. etc. I dont know what is "under the hood" but what google has exposed via the SipProfile so far looks to be sub-par.
5) "Internet calling" support isnt going to be enabled on all devices, although i think the nexus s probably will be one of the few, in fact even in the AVD I get an "internet calling not supported" message when I try to call a sip URI from the dialer.
Your best bet right now - try out CSipSimple. Native SIP support is going to be a bit raw for a while is my guess.
Click to expand...
Click to collapse
Running Gingerbread right now...I can tell you that "Internet Calling" works straight from the dialer. However, my experience with built in SIP over wifi on Pbxes.org is that cSipSimple is more usable. There is a noticeable lag using the built in SIP configuration and only UDP works for PBXes since it doesn't allow a hybrid mode like cSipSimple (TCP for registration, UDP for connection due to PBXes incomplete TCP implementation). The problem I have with cSipSimple is that the mic gain is way too high and it picks up all the background noise.

Benny1234 said:
In reviewing the new page on the nexus s, the only thing I really am interested in is the internet dialing/SIP. I have tried SIPdroid on the captivate, and it works ok, but very staticy on the other end. I am curious as to whether anyone knows where the SIP client for 2.3 came from. Is it SIPdroid? Did Google buy SIPdroid? I would also be very interested in flashing only the SIP part of Gingerbread 2.3, the rest of the update isnt all that interesting to me. If anyone comes across info or files related to this, post here.
Thanks
Click to expand...
Click to collapse
Looks to me that it is based on JAIN-SIP from inspecting the AOSP source. Have look at http://android.git.kernel.org/?p=platform/external/nist-sip.git;a=tree;hb=HEAD
JAIN-SIP was developed by NIST and the AOSP references NIST also. Haven't dug deeper to confirm however.
etamme said:
A few things:
3) I have been looking at the 2.3 SIP stuff - It's not like you can just take that part from 2.3 and "flash" it to your device.
Click to expand...
Click to collapse
What would it take to extract the SIP bits from the AOSP and use it as a reference library for a SIP enabled application? I have never tried but it should be possible no?

Wrong mic (top)
OCedHrt said:
The problem I have with cSipSimple is that the mic gain is way too high and it picks up all the background noise.
Click to expand...
Click to collapse
You can set the mic gain:
While in a call, click the menu button (bottom left)
Select Media
Move the Mic slider left to lower the volume (quickly before the screen goes back to default).
However, this does not really solve the problem because cSipSimple uses the mic on top of the phone which does not pick up your voice very well, and pics up the sound from the receiver (speaker) causing the person on the other end to hear an echo of everything they say.
I have not been able to find a way to change this behavior.

anyone having an issue with phone calls being rejected with sip dialing? I've tried sipdroid, csipsimple and native sip. using google voice forwarding a number i recieved from ipkall, and using iptel.org instead of pbxes

Bluetooth DUN on CM 7.1.0

Hi all,
I spent a couple of days Googling around, trying to get Bluetooth DUN working on Cyanogenmod 7.1.0 on my Viewsonic GTablet.
After some hacking around with the source, I got it working. I can connect my GTablet to the internet through my Blackberry Torch on Rogers (in Ontario, Canada).
I've already posted my notes to the CM forums, but apparently since I'm a noob here I can't post the link to it, so here's my notes (direct copied from the CM forums):
Dial-up networking requires the chat binary, which is included in the standard Linux ppp package. For some reason, this binary was omitted from the Android ppp package, so I downloaded the Android 2.3.7 source, copied the chat source in to the Android ppp package and built it from scratch. The instructions for this were found at afewe DOT wordpress DOT com/android-arm-development/use-point-to-point-protocol-ppp-in-android/
Once the chat binary is installed in the proper location on the Android device (/system/bin/chat) it's just a matter of writing a pppd config and chatscript for your given provider. These configs can be found in the berry4all package at berry4all DOT com.
I copied the 'rogers' file from that package and put it in /etc/ppp/peers/rogers, then the rogers-chat file and put it in /etc/ppp/chatscripts/rogers-chat.
I modified the /etc/ppp/peers/rogers so that the last line, which calls the chat binary, reflected the proper locations of the binary and the chat script.
Finally, I removed the 'novj' option from the pppd config. Once the config was all up and ready to go, I went to the terminal and did:
$ su
# rfcomm bind /dev/rfcomm0 <BT MAC> <channel>
# pppd call rogers
And voila! A stable, bluetooth dial-up network connection through my phone.
I just wanted to throw out my notes first to make people aware that its possible and easy. If there's enough interest, I'll write a more detailed and specific step-by-step howto on getting it set up.

Hi,
I see that CM 7.1 includes "bluetooth tether" support now but it's not clear to me what this actually is. Does CM 7.1 include the DUN bluetooth profile? It sounds like you're using reverse tethering, i.e. you are using a Blackberry's data connection so you're using the DUN profile on the Blackberry and are using the CM device as a client?
I have a stock Desire S and am looking for DUN support so I can use the internet access in my car through the Desire's 3G connection. The car supports only DUN and PDANet doesn't work for some reason.
Thanks,
Tim

Looks like you're out of luck.... same story for my Benz with Comand Online Navcom system.
If you drive an MB like me, you'll have to wait for an update later this year (from MB that is)... or buy a BlackBerry.
Sent from my GT-P7500 using Tapatalk

Is it confirmed that mercedes benz are providing this update?
Sent from my GT-I9100 using Tapatalk

I very much doubt it (I'm also trying to get it working with Comand Online).
http://telematicsnews.info/2011/08/...connectivity-options-to-comand-online_ag2223/
Not great news.

tj80 said:
I very much doubt it (I'm also trying to get it working with Comand Online).
Click to expand...
Click to collapse
From the press release:
"An option for customers having phones without DUN support is the Mercedes-Benz “Bluetooth (SAP) telephone module - V4″, available early 2012. The new version (V4) offers UMTS capability, allowing fast data connection using customer SIM card or accessing SIM information from SAP (SIM Access Profile) enabled mobile phone."
and:
"... Furthermore Mercedes-Benz is in close talks with leading Android phone vendors to enable the DUN feature in their phones by default."
(I have Android 2.3 and Windows Phone 7.5 devices)

Yes, so we can pay £400 for a SAP module or buy a new phone if anyone actually launches an Android handset with DUN - remembering that Google appear to have zero interest so it will be manufacturer specific. Oh yes, I nearly forgot - Android doesn't have SAP profile support either!
I'd say the chances of Mercedes updating existing systems to work with phones which don't support DUN is virtually zero. Hardly ideal on a system which cost £2000...
Cheers,
Tim

I agree. It was a huge mistake of MB to go with this dead BT DUN protocol!

I thought Android phones do support SAP, isn't that why the car can dial a contact?

agupta80 said:
I thought Android phones do support SAP, isn't that why the car can dial a contact?
Click to expand...
Click to collapse
'fraid not, that uses PBAP (phone book access protocol).

is there a way to know which API is calling an application?

Hi to all,
sorry for my poor english but this is not my first language.
I'm a Ph.D student and i'm trying to understant if something we are working on is feasible.
We are looking for a method to know in real time, directly on the phone, which API an application is calling.
For example, i wonna know in realtime if an application call an API to turn on the bluetooth or call the API to send an information (of any kind) through the bluetooth connection.
Any help would be really appreciated.
If you need further information just ask, maybe my explanation was a little bit too shallow.

Lierus said:
Hi to all,
sorry for my poor english but this is not my first language.
I'm a Ph.D student and i'm trying to understant if something we are working on is feasible.
We are looking for a method to know in real time, directly on the phone, which API an application is calling.
For example, i wonna know in realtime if an application call an API to turn on the bluetooth or call the API to send an information (of any kind) through the bluetooth connection.
Any help would be really appreciated.
If you need further information just ask, maybe my explanation was a little bit too shallow.
Click to expand...
Click to collapse
Hi Lierus,
no problem about the english, it is not my mother tongue too (I'm a PhD too)...
Did you take a look at "Intent"? http://developer.android.com/guide/components/intents-filters.html
It is the common way to both start a new activity in the same application and start an Activity/Service in another application that expose an API invokable by an Intent.
I do not know if this can help you or not? however if you give more info maybe I can give you a more precise answer.
Simone

Hi Simone, thanks for your answer.
I bet you're Italian .. I am too
Maybe i was too generic in my original question.
My final purpose is to know when a generic application (a third party application) uses some devices or, more generally, calls an API to use such devices. These calls that i want to monitor are the ones related to the manifest's permissions.
This action should be registered by the application i'm writing..
Example:
Application "Pippo" has the permission to use the Bluetooth (grant by the user during installation).
My application "Monitor" should know and register when Pippo really invokes the Bluetooth Api!
Thanks again
Marco

Lierus said:
Hi Simone, thanks for your answer.
I bet you're Italian .. I am too
Maybe i was too generic in my original question.
My final purpose is to know when a generic application (a third party application) uses some devices or, more generally, calls an API to use such devices. These calls that i want to monitor are the ones related to the manifest's permissions.
This action should be registered by the application i'm writing..
Example:
Application "Pippo" has the permission to use the Bluetooth (grant by the user during installation).
My application "Monitor" should know and register when Pippo really invokes the Bluetooth Api!
Thanks again
Marco
Click to expand...
Click to collapse
ok, I understood.
I think that if you want to build an app like a "monitor" you have to monitor the "Intent" that the apps use in the Android ecosystem to call both external API (third party application) or internal (e.g., start a new Activity). For example, we have a device with an app (named Pippo) that sends data over the bluetooth connection.
Basically, Pippo calls isEnabled() to check whether Bluetooth is currently enable:
Code:
Intent enableBtIntent = new Intent(BluetoothAdapter.ACTION_REQUEST_ENABLE);
startActivityForResult(enableBtIntent, REQUEST_ENABLE_BT);
the Monitor app should register an intent-filter on the "ACTION_REQUEST_ENABLE" action, so when the Pippo sends the intent, the Monitor receives the Intent and then forwards the Intent to the right app (like a man-in-the-middle).
what do you think?
p.s. take a look at this app https://play.google.com/store/apps/details?id=uk.co.ashtonbrsc.android.intentintercept
Best,
Simone

Yes this is a good starting point..
I will investigate this opportunity
i hope that i can discriminate and understand who invokes the intent (not just when it is invoked).
Thanks again.
Marco

Is it works?
Sent from my LegoIce™Galaxy_S4 using XDA Premium 4 mobile app

dhirajahuja432 said:
Is it works?
Sent from my LegoIce™Galaxy_S4 using XDA Premium 4 mobile app
Click to expand...
Click to collapse
yes
try it yourself,
https://play.google.com/store/apps/details?id=uk.co.ashtonbrsc.android.intentintercept
the implementation of this app, is based on the idea explained above.
Simone

Hiding Android API Calls

I wanted to know that whether an app uses a specific Android API (e.g. that API can be getApkContentSigners()). So, is it possible that we can hide the Android API call without Reflections?
Because, if it is through reflections, then even the method which we will be invoking, we have to specify it as a string literal and store it in a variable. So, if we are decompiling the apk (through jadx-gui), we can still see the Android API call. Is there any other methodology, that can be used to hide the Android API calls?
Are commercial tools like dex-guard has the capability to hide the Android API calls, so that when we try to disassemble/decompile it, and we are doing a pattern-based search to find the API call, we won't be able to see it?
Thanks a lot for helping me