How often is a traveller, making use of publicly available wifi, going to find himself attaching unawares to one of those networks? Perhaps you and I have a totally different idea of the likely market of potential users for this device. If you are going to talk about getting real, you should think about who is likely to use it and where.
If posters were to make all possible hedges to their suggestions, posts would go on for page after page. Yes, I could have said “so picky” instead of just “picky”. I could have listed NAT as well as firewall. Neither would add anything of substance to the point nor detract from it.
Nokia N800’s VoIP is not the only one that has worked out of the box on my network and anywhere else I have connected it. I have avoided mentioning Taki, because “Blackberry” might be a dirty word around here. Still it worked, until BB cut it off.
As I said in a reply to Gavaudan, I might be able to give a better answer to your question about VoIP over a cellular network when a SIM that I have ordered arrives.
I have installed a Keepgo Worldwide Data SIM, activated data roaming, switched off wifi, and tried again. Audio is still one way only. As before, crystal clear coming from the server to the L5, nothing in the other direction.
Once again, it is possible that Bell Canada is blocking VoIP packages from prepaid roaming users. It is a notoriously restrictive telecom. It would be a bit strange, though, for VoIP packages to be blocked one way but not the other.
Unfortunately, Bell Canada 3G is the only network I can use in Canada with my European modem. I am going to buy the North American modem when I can get shop.puri.sm to take my order (something is making them slow this morning).
On another topic, the “suddenly stops browsing” problem seems to have disappeared since the recent rash of updates, including the new kernel. It is too short a time to be definite on this though.
[CORRECTION 08 Mar 2023: This problem has not disappeared. I could add another browsing failure, “refuses to start browsing” when there is no other device already connected to the AP. For example, I can get positive responses to “ping www.sncf.com” and yet the browser says “Unable to find that site” when I try to open it (and the same result repeatedly when I try again). This is a serious defect of the L5.]
UPDATE: Managed to connect to Rogers network. No difference.
UPDATE 2:
(1) Turned off wifi access point of home network;
(2) Obtained stable 3G/4G data connection with Telus network;
(3) Activated VoIP in Calls and made a call: no outgoing audio;
(4) Turned off VoIP in Calls and closed Calls app;
(5) Activated Hotspot on L5 and connected N800 to pureos access point;
(6) Opened Internet Calls on N800 and made a call - audio both ways.
In other words, using the same network connection between L5 and VoIP server, plus an additional possible-point-of-failure link, but using a different VoIP app and bypassing Calls, the VoIP call is successful.
In addition to these three, with their individual volume sliders, three more volume sliders appear, only when a call is in progress through Calls, just below VolumeLevels>SystemSounds on the Settings>Sound page. There are icons at the left side of the page beside these three sliders. The first icon is something I can not decipher. The other two show a stylised picture of a smartphone, accompanied by the word “Calls”.
It would appear that the two sliders named “Calls” might reasonably be thought to control microphone and speaker volume for the duration of the call, overriding any settings lower down the page. [EDIT 11 March 2023: Yes, I have tested this and that is what those temporary additional sliders do.] Does anybody know whether this is in fact the case? If not, what do they represent?
In any case, with both of those temporarily present sliders set to their maximum, there is still no audio going out to the VoIP server during a VoIP call through the Calls app.
Besides the audio input from the microphone, there is another source of audio transmitted from a phone to its exchange. Key presses on the dial pad generate audio in the form of DTMF tones. These are handled by a network (POTS, cellular or internet) in the same way as any other audio.
With the cellular network disconnected and VoIP calling activated in the L5 Calls app, calls can be dialled successfully from the dialpad. This means that audio is able to go from the L5 Calls app to the server before a call is connected. [EDIT: This is wrong. raenrfm has explained that dialpad presses to dial a call do not generate audio transmission. Once the call is connected, they do operate as audio transactions. The change from functioning to non-functioning dialpad is explained by the change from non-audio to audio operation, rather than a change in the L5’s handling of audio.]
However, once the call is connected, further dialpad presses (such as making a selection from a voicemail menu) have no effect. Either the dialpad ceases to function or, as with microphone input, the L5 Calls app fails to send audio to the server when a VoIP call is in progress.
As noted in my last post, additional volume sliders temporarily populate the Settings>Sound page when a call of either kind (cellular or VoIP) is in progress from the Calls app, indicating that audio is handled differently by the L5 during that time. This different handling works satisfactorily for a cellular call. It does not seem to work for VoIP calls.
EDIT: Clarified that all phone calls under consideration are initiated from the Calls app.
The only codecs currently supported by gnome-calls are PCMA, PCMU, G722 and GSM [see gitlab.gnome.org/GNOME/calls/-/issues/349]. All of these are operational in Calls on L5. It is possible to remove codec(s) using
"gsettings set org.gnome.Calls preferred-audio-codecs "
but it is not possible to add any codecs other than the four on the list.
My VoIP provider does not offer PCMA but does offer the other three. In case PCMA might be causing the trouble, I removed it from ẗhe L5. It made no difference. I have now restored PCMA on the L5.
Thank you again.
P.S. I note that Flowroute (the SIP provider used by FamousJameous) offers the full G711 codec, which includes PCMA. Maybe that makes the difference between his success and other users’ failure.
I don’t remember if you’ve mentioned which VoIP provider you use. (I tried searching and just reading several posts in this topic and didn’t find it, but I easily could have missed it)
If you are willing to share that and it’s relatively easy to set up and relatively low cost, I might be willing to set up an account and try it with my L5.
Maybe for some reason the L5 thinks that the VoIP provider does offer it and settles on that codec but then of course the provider says no way. If that’s the case then there is something wrong with the SIP implementation on the L5 not negotiating properly.
That is an extremely generous offer. My provider is https://voip.ms . Costs are low.
Their Pricing page says that outgoing calls can be made without a DID number, so you are not forced to pay for a DID.
The same Pricing page also says that “internal” calls are free. That should mean all calls to SIP URIs (not necessarily only @sip.voip.ms) but the page is not specific on that point.
They have a large number of servers in USA and Canada, 3 in Europe and 1 in Australia - https://wiki.voip.ms/article/Servers . If you get a DID number, you choose a server for that DID as part of setting it up. If you don’t get a DID, I assume that you can choose any server from the list when configuring your L5 to use the account.
My account number is 6-digit. I assume that new accounts today will still be 6-digit or at most 7. The SIP URI is account_number@sip.voip.ms . As far as I can see, SIP calls to that URI should connect, even if you don’t have a DID (but I don’t know this for sure).
The account number is the username for L5 configuration.
The account setup process has changed since I did it. The website claims that you can be set up and making calls in 5 minutes.
A minimum of US$15 must be deposited before you can use their services. Within 90 days you can ask for a refund of the unused balance, but it is not guaranteed that they will pay it.
So, I set up a VoIP.ms Account (For some reason they wouldn’t let me use an email address on my domain, that was annoying) and added a VoIP account to Calls and disabled my Flowroute account. At first, it showed only the textbox+keyboard when dialing. My Flowroute accounts shows a phone dial pad. I tried dialing anyway and kept getting a DNS Error popup. Eventually I went back into the account settings and found a toggle switch for “Use for Phone Calls” that was set to off. I turned that switch on and now I get the dial pad when dialing with the VoIP.ms. However, I can’t seem to call a non-sip number. With my Flowroute account, I can just dial the number and from what I’ve read that should work with VoIP.ms as well.
I turned off “Use for Phone Calls” and instead typed in “echo@conference.sip2sip.info” using the keyboard and that call worked and I could hear my voice echoed back to me. I also tried the VoIP.ms echo test by dialing 4443 (with the keyboard, not the dial pad) and I can hear the voice prompt but I get no echoes of my own voice.
So, kind of a mixed bag for me. The echo@conference.sip2sip.info seems positive, but that’s about the only good news. Certainly if you have anything you want me to try, let me know.
Thank you very much for this . I have just logged on, intending to tell you about the echo test. Your test is conclusive. The audio from your voice is not getting to the voip.ms server. You do not need to make a call to another phone.
Something else you can try if you are interested, also free. You can call the voice mail by dialling *97 . When it connects, swipe up the call window to get back the dial pad [EDIT: Oh sorry, I just noticed that the dialpad was not working for you, even before the call connected]. I found that there was no response to the dial pad when the call to voice mail was still running, meaning that that DTMF audio (which was reaching the server when you dialled *97 - EDIT: This is wrong: see the EDIT in the next paragraph) is no longer getting to the server. Something happens to cut off all outgoing audio when a call is in process. (You will have to swipe back to the call window to end the call, because the # on the dialpad will not do anything.)
Your test result is pointing more strongly to a problem of mismatched codecs, and it seems that for some reason the L5 switches to a different codec when the call has connected. Maybe raenrfm would know whether this could be a normal occurrence in SIP calling. [EDIT: raenrfm has corrected my understanding of this situation. The dialpad does not send out audio when a call is dialed. Audio is sent when keypresses are made after a call is connected. Therefore there is no change in the audio handling by Calls: the change is from non-audio to audio operation of the keypad.]
It seems that github is not interested in expanding the selection of codecs for gnome-calls. Maybe the G.729a is not FOSS and therefore ideologically unacceptable.
Apparently the server @conference.sip2sip.info can accept the codecs available in gnome-calls, not requiring any others. Thank you also for this further test.
Many thanks again. I would say that your tests are conclusive that the problem does not relate to anything we can configure in the L5 or in our own networks.
[EDIT: Yes, I have just checked on sip2sip SipTesting page. They accept G.722 and G.711 among others. Those are precisely the codecs in gnome-calls. It really looks as though we have found the cause of the problem and also found that there is no solution other than (in my case) changing VoIP provider. I don’t want to do that, so I’ll have to write off the L5 as an internet phone (other than for receiving login codes).]
SOLUTION: If you want to use the L5 as an internet phone, you have to choose a VoIP provider that accepts G.711 (comprising PCMU and PCMA) as a complete set of audio codecs. There should be higher quality audio if the provider also accepts the G.722 wideband codec. [See alternative solutions below in this post.]
Great thanks to all who contributed their effort to finding the cause of this problem, and particularly to FamousJameous and raenrfm. EDIT: Credit also to Sample3364 who found a better solution - see below.
REVISED SOLUTION, 8 Mar 2023: Forum member Sample3364 has posted a way to activate two-way audio if your provider does not offer the full G.711 codec but does offer G.722. He found that he could get two-way audio by deactivating all codecs except G.722 in his account with voip.ms.
One major flaw remains: you can’t use the dialpad during a call on gnome-calls to navigate a voice mail system etc. There is a discussion of this on gitlab at https://gitlab.gnome.org/GNOME/calls/-/issues/553 The proposed workaround is to carry another device capable of generating DTMF tones and hold it to the mic of your GNOME-equipped device as needed. I tried this with two online dtmf tone generators, from https://onlinetonegenerator.com/dtmf.html and https://pbxbook.com/other/dtmftone.html. It did not work.
Another flaw is that the audio from the L5 end is very scratchy.
FURTHER REVISION, 10 Mar 2023: Only the PCMU codec has to be disabled in the server to achieve two-way audio, when your provider offers PCMU and G.722 but not PCMA. (PCMU is also called G.711U and ulaw.) Other codecs such as G.729 can be left active; they could be useful if you use other phones and ATA’s on the same VoIP account. This fits in with FamousJameous’s experience with Flowroute, and also the test I have just run leaving G.729a and gsm codecs active.
It would be interesting to hear from someone whose provider offers PCMA but not PCMU.
Once the call setup is done and the codec is selected for that call I don’t think there is a mechanism for further negotiation during the call, as long as the two endpoints are in contact (UDP usually) the call should continue otherwise the call drops and a new call/negotiation happens. Ironically we were dealing with a one way audio issue recently. Traditional POTS lines now are actually not so much POTS anymore. Your land line most likely these days connects to a cabinet in your neighbourhood that basically converts the copper analog circuit to SIP and then into the voice core for routing. We are still using DMS switches from the 70’s but it’s slowly being replaced with SIP based tech. In fact the brain of our DMS is now entirely SIP based just using the copper line cards from the DMS. Of course once you have GPON fibre to your home that SIP translation now occurs at the ONT (Optical Network Terminal) that is right in your house, we are rarely installing any copper anymore. SIP is literally everywhere.
OK, but the DTMF tones dialing the call are sent out before the call setup is done. It seems that the setup involves* selecting a codec that happens to differ from the one in operation when the dial tones were (successfully) sent out.
*(at least in the specific situation of calls from gnome-calls in the L5)
There is a difference between the “touchtones” to dial a call and the ones you do for example to interact with an auto-attendant while in a call. In SIP land when you dial a call it’s not sending tones anymore, you’re just entering in an address, it’s not an audio thing.
In that case, you have solved the puzzle that the dialpad can dial the call but then stops working once the call is connected (at which time it would be an audio thing).
No change of codec is needed, because there was no codec in operation before. Thank you for clarifying this situation, which had me quite baffled.
Thank you very much for this. I have edited the “Solution” post to include it and give you credit. In my own test, I found that the audio also worked both ways when the gsm and G.729a codecs were left active as well as the G.722. (Not sure if there is much need for gsm codec these days, but you never know.)
I am having this issue while trying to receive cellular (not VoIP) calls. Just as described in the first post here — no outgoing audio at all, though I can hear incoming audio perfectly. Any ideas anyone?
(The L5 has got the latest update, and I can see the mic bar reacting to sounds in the Settings.)
Forum member raenrfm, who has made important contributions to this discussion, knows a lot about the way that audio codecs are handled in telephone systems. You might try contacting him directly.
The gnome-calls application supports a very limited selection of audio codecs, the same selection for cellular calls as for sip/voip. The maintainers of that software are not interested in adding any more, so it makes no difference how up-to-date you have kept your pureos. (I understand that the problem here lies in the fact that there are many non-FOSS codecs widely used in telephony, and Gnome software is strictly FOSS.)
Besides the limited selection of codecs (specifically PCMA, PCMU, G722 and GSM), raenrfm has suggested that there may be an error in the L5’s procedure of codec negotiation (see post 67 of this thread). He might be able to help you find out which audio codecs are supported by your cellular provider and what you might try to cope with a mismatch.