Using linphone

AppLee

Can it consist only of a wish?

"Merge request" means asking the maintainer to use code modification you made an provided.
An "issue" in gitlab can be either a bug report or a feature request.

Chek the link provided by @CiberSheep:
https://gitlab.com/ubports-linphone/linphone-simple/issues

Read the opened issue to see if yours are already in there.
If not you can create a new one for both features you noted.
A bug report for the automatic domain and a feature request for the dialer.

I think the reason why the dialer is not present has been answered earlier.

CiberSheep

I see I don't express myself very well here. I try to be more clear:

@ogogon said in Using linphone:

@CiberSheep said in Using linphone:

That's the official Linphone App from Linphone.

I apologize if I ask an indecent question, but what is wrong with this assembly?

Nothing wrong. They can do whatever they want with their app.

Why not include it in UBPorts? Why do you need to do another assembly if there is already done and having a fairly wide functionality?

I don't believe I do «another assembly» I believe I have thought about how this app should look in our OS.

And I repeat: I don't see the need of using nearly the whole screen for a dialer that I would nearly use when I can use a more versatile keyboard that is already implemented in the OS.

An answer like "if you are so smart, then take it and turn it on" is not accepted. I want to understand your logic.

I see I don't express very well here. I'm sorry if you read «impatient young kiddo go and make it yourself if you're so smart» I'm trying to say that «if you have a better solution, you are welcome to share» and I expect you to «collaborate in the project, not think this is a product to consume». And I would like, instead of sending a screenshot of an app from another system, you to sit and considerate:

Why a dialer?
What's the benefits to have another assembly specific to the phone number that will be useless for SIP uris?
What's the downside of having the OS keyboard

Then, let's come with a good solution. One that is ours and fit Ubuntu Touch.

I do not want to upset you, but it is not added.

Then, it's a bug

Is the program log somewhere written on the phone, or can I only attach the console output of my Asterisk?

The easiest is to install Logviwer that reads in /var/log/ check that the log doesn't show any SIP number

Sorry, shortcut for Merge Request

Can it consist only of a wish?

Of course, expect an honest answer (not in an hour)

flohack

@ogogon Ubuntu Touch uses a rather unique App framework so none of the existing mobile Apps is suppsoed tun there. Its not a matter of taste if we make a new binary, its rather a must.

So we took the core libraries of Linphone but put them into new clothes, and connected all the parts as UT demands it to do. We cannot reuse easily any of those designs, so its rather a rewrite than a port of the official App

ogogon

@CiberSheep said in Using linphone:

see I don't express very well here.

You have nothing to apologize for. Rather, I need to do this.
English is not my native language, I am not its native speaker.
Therefore, in many situations I understand the lexical meaning, but I do not understand the intonation. Because mechanisms for transmissions of intonation are taken from a little familiar to me the cultural layer.
Please do not worry - in such situations I always ask again.

Why a dialer?

What's the benefits to have another assembly specific to the phone number that will be useless for SIP uris?

What's the downside of having the OS keyboard

Objectively, you are completely right.
But this is very habitually: if you run the softphone, the dialer immediately runs in.

The easiest is to install Logviwer that reads in /var/log/ check that the log doesn't show any SIP number

I installed this program, switched it to the /var/log directory, however I didn’t find a file like linphone.log there.
Do I need to enable logging somehow? Or do I need to look in some other file?

Ogogon.

flohack

@ogogon Sorry to correct @CiberSheep but application logs are not in /var/log but in the user´s app area, and logviewer App can read from there. Do not use to capture logs with terminal or cmdline, open the log viewer app and look there.

ogogon

@Flohack said in Using linphone:

@ogogon Ubuntu Touch uses a rather unique App framework so none of the existing mobile Apps is suppsoed tun there. Its not a matter of taste if we make a new binary, its rather a must.

So we took the core libraries of Linphone but put them into new clothes, and connected all the parts as UT demands it to do. We cannot reuse easily any of those designs, so its rather a rewrite than a port of the official App

Aha! Now I finally understood what was happening! What everyone means, but never speak directly.
The ingenious developers of UT have created an nothing incompatible platform and you cannot just compile an already developed package on it. The package needs to be rewritten for it.
We have another android, only open source!

(I'll go drink three hundred drops of essential valerian!)

ogogon

@Flohack said in Using linphone:

@ogogon Sorry to correct @CiberSheep but application logs are not in /var/log but in the user´s app area, and logviewer App can read from there.

I'm sorry, I already reconfigured it to /var/log. What is the path to user applications area?

Do not use to capture logs with terminal or cmdline, open the log viewer app and look there.

And if I go over ssh and say 'tail -f filename', can something go wrong?
(Of course, I do not want to doubt the reasonability of your advice, but I have done this all my life and it worked.)

Ogogon.

jezek

@ogogon said in Using linphone:

I'm sorry, I already reconfigured it to /var/log. What is the path to user applications area?

Pardon the intrusion. Fresh installation of logviever operates in /home/phablet/.cache/upstart. Have a nice day.

ogogon

@jezek said in Using linphone:

Pardon the intrusion. Fresh installation of logviever operates in /home/phablet/.cache/upstart. Have a nice day.

Thank you!

ogogon

@Flohack said in Using linphone:

@ogogon Sorry to correct @CiberSheep but application logs are not in /var/log but in the user´s app area, and logviewer App can read from there.

In the area of user applications, I found two files - linpfone-tmp.log and linphone.cibersheep.log. Apparently, both are empty - if you click on them, an empty window opens.
I made calls before - both successful and unsuccessful.

Am I doing something wrong again?

Ogogon.

CiberSheep

@ogogon said in Using linphone:

@Flohack said in Using linphone:

@ogogon Sorry to correct @CiberSheep but application logs are not in /var/log but in the user´s app area, and logviewer App can read from there.

I'm sorry, I already reconfigured it to /var/log. What is the path to user applications area?

Do not use to capture logs with terminal or cmdline, open the log viewer app and look there.

And if I go over ssh and say 'tail -f filename', can something go wrong?

Ooops... sorry about that.

You need to have the app open to see the log

flohack

@ogogon you are not supposed to use /var/log as a shared directory. Apps are confined in what they can do quite heavily (as on every mobile device OS so far), and have their own directory for logs and temporary stuff. This is done for security. How else could we ever allow 3rd parties (means non-Ubuntu Touch developers) to contribute any App through a store?

If you trust all the world its fine, we don't. So, Apps cannot do what they want and should not do what they want. Also, the whole root file system is read-only. Also do not use apt to update stuff. We got image-based OTA upgrades. It is faster, saves write cycles on the flash storage, and its transactional, meaning no partially upgraded systems . This is not a desktop, saying this just once more.

The advantage is a superior stability, you cannot brick your device easily, Apps cannot spy on each other and the system, most rootkits/hacks wont work on UT etc. You have claims that Apps can request and the user can allow or disallow them, like mic, camera etc access. This is not possible in a traditional desktop OS. So, a big win.

If you tamper with that security model, you are on your own. We cannot support you when you start changing the way how the OS works. If you start rearranging how logging works you need to give Apps elevated permissions, and that's not how we think a mobile OS should work these days.

So before you complain about why we made everything wrong you should better ask why decisions were made in that way. We di dnot make our life more complicated because it´s fun but because we wanted to improve the architecture.