I've tried that already (with tapping to Expire-setting...). Didnt work.
But it doesnt bother me as long as I can phone to Germany now with
Linphone + Peoplephone.at
thanks again
On Wed, 09 Jan 2019 20:45:13 +0100, Christopher Woods
<christopherwo...@gmail.com> wrote:
Interesting, thanks for the update. I have the same bug on iPhone - if I
remove 0, press Return then press back, the 0 is still >there when I
click on the account again.
To remove the 0 from country code prefix, I deleted the 0, tapped on the
Expire setting and then pressed back. That seems to >save the null value
OK for the prefix setting.
I then tested on Linphone Android, both the CC prefix and substitute +
for 00 settings. Specifying a country code prefix of >"001" in the
settings was turning it into "+001" when I dialed (so 5678 would become
+0015678).
If I specify "+44" (for example) as a prefix, it will include exactly
what I inputted - and also prefix with another + symbol, so a >dialled
number of "6789" becomes "++446789". That's perhaps not what people
might expect to happen, something to >remember for the future. The
'substitute + for 00' option worked as expected.
I think in your setup, it's best to keep them disabled to avoid causing
problems in future. I also find it quicker to dial 00 than >dialing + so
I'm glad that works for you too. I wonder if the AAC-ELD issue is a
Linphone or iOS bug. I'll do some testing >between my devices and see if
I get the same problem trying to dial with AAC-ELD 16 kHz...
Cheers,
Chris
On Wed, 9 Jan 2019 at 19:29, Andi Soko <sok...@soko.cc> wrote:
Thx for the explanation.
I reckon the double + and spaces where just a typo in my emails.
I always dial with the dialpad. Linphone has no access to my contacts.
Yes 49 is germany. 351 is the city.
When I dial:
+49351... its OK.
0049351... its OK.
049351... i get the same error.
0351... i get the same error.
all this is done with "Substitute + in phone numbers" OFF and Country
Code Prefix "0". I cannot delete the CCPrefix (bug in >>app?!). all
this is done with all audio codecs enabled but "AAC-ELD 16kHz". If I
enable it all four dials of above result in the >>same error.
I've already talked to the Peoplefone support. All they said is that I
should use Zoiper as this app is supported by them...
Anyhow... thanks heaps for the help and I'm good with disabling just
the 16kHz of AAC-ELD.
Soko
On Wed, 09 Jan 2019 19:22:42 +0100, Christopher Woods
<christopherwo...@gmail.com> wrote:
This kind of SIP phone service is, at the fundamental level, quite
simple - your phone talks to a central registrar, which >>>does all
the hard work.
You tell the SIP registrar you want to place a call, and the registrar
works out what the route is to reach the other device. >>>Your SIP
registrar also provide a 'bridge' to the remote network (quite common
for SIP-to-PSTN calls to regular telephone >>>networks). The SIP
server also communicates with the phone network on the other side to
set up the call.
In this kind of setup, the SIP registrar is often also a SIP proxy
server, so your audio and the other caller's audio is proxied >>>by
the SIP server. It works exactly the same if someone calls your
PeopleFone number - the other person's phone >>>operator knows that
the route to reach you is via a PSTN-to-SIP bridge between their phone
network and the PeopleFone >>>SIP registrar.
All devices tell each other what formats they support, and they agree
on an audio format to use in each direction. Usually >>>this will be
the same, but you could have one codec for incoming audio and another
for outgoing.
I took another look at your debug logs -- I was wondering if my first
suggestion was accurate (!). I also just noticed that in >>>your first
email, you wrote "Cannot call + +4935...9915", with two plus symbols -
that's invalid.
In your call logs, I can see payload (audio codec) type 0 and type 8
in the SDP m=audio line of the SDP (Session >>>Description file which
is sent by Linphone to the SIP server, which describes what your
handset is capable of). >>>Interestingly, the accompanying rtpmap
definitions are not listed in additional a= lines. It seems Linphone
did not bother to >>>send them, it just declares it can support those
formats, which is probably OK.
For example, for a call attempted using either G.711-Alaw or
G.711-ulaw , I would normally expect to see in the SDP:
m=audio 15010 RTP/AVP 0 8
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
PCMU and PCM8 (payload types 0 and 8) are defined in the RFC3551
standard, so perhaps Linphone just doesn't bother >>>describing them
again. I'm sure a Linphone developer would be able to confirm ;-)
In your call logs, for each call attempt, I can see your device sends
a long list of supported formats (including the >>>telephone-event
ones for DTMF etc):
m=audio 7286 RTP/AVP 96 97 98 0 8 3 9 99 18 100 102 103 104 105 106
101 107 108 109 110 111
I can see the other device is only offering PCMU, PCMA and G.729 as
formats it can support. That's OK.
The first difference between the bad and good calls: for the failed
call, your Linphone offered 16, 22.05, 44.1 and 48 kHz >>>sample rate
AAC. For the working call, Linphone only offered 22.05, 32, 44.1 and
48 kHz sample rate AAC. However, it still >>>offered the other AAC
codecs, along with the older G.711, iLBC, Speex and iSAC codecs.
I think you are actually using G.711 for all these calls, so AAC-ELD
16 kHz enabled or disabled is actually a 'red herring'.
I also noticed in the OK call, you are calling
INVITE sip:+ 4935xxxxx...@sip.peoplefone.at SIP/2.0
Via: SIP/2.0/UDP 192.168.254.71:49268;branch=z9hG4bK.xEZZuwbrr;rport
From: "peoplefone" <sip:90772518...@sip.peoplefone.at>;tag=3-E0YDHEP
To: "+ 4935xxxxxx26" <sip:+ 4935xxxxx...@sip.peoplefone.at>
Are you prefixing "+ " in Linphone before the number? I would not do
that, so clear any value of "Country code prefix" and >>>also disable
"Replace + by 00".
In the previous call which failed, strangely I think you were dialling
correctly - with no space, i.e. +4935... .
From looking at the codec order of preference, I think your handset
may have been using PCMU for the calls, and >>>something else is going
on.
I think what is actually happening is perhaps you should not include
the + in the dialled SIP URI, because the SIP registrar >>>is not
recognising it. In the failed call:
"SIP/2.0 488 Not Acceptable Here [Media Descriptions Syntax error
while parsing the SDP]"
However in the OK call, the SIP URI is
SIP/2.0 180 Ringing
To: "+ 4935xxxxxx26" <sip:+
4935xxxxx...@sip.peoplefone.at>;tag=11d896f4
NB the space! How do you have the number saved in your Contacts?
I believe PeopleFone may be seeing the dialled URI, seeing it has no
leading zero, then using pattern matching to assume >>>it is a German
number, and ignoring the plus symbol as it is not part of the valid
01234@sip format URI. Valid SIP URIs >>>cannot have spaces in them; if
so, this interpretation is clever by PeopleFone, but slightly
confusing :-)
The number you are dialing is 4935xxxxxx26, this is a German number?
Is it normally 035xxxxxx26?
Try enabling whatever codecs you want, but leave PCMU and PCMA
enabled, then redial the number without any leading >>>+ or 00.
PeopleFone's SIP server may be anticipating numbers dialled without
leading zeroes, or perhaps your client is set >>>up to incorrectly
add/remove digits from a dialled SIP URI.
Make sure you have no prefix listed in the account settings, then try
dialing "4935xxxxxx26".
Then try "04935xxxxxx26" (one zero).
Then try "004935xxxxxx26" (two zeroes).
If that works, try dialing "+4935xxxxxx26".
I would be interested to know what happens if you dial "035xxxxxx26"
Make sure to avoid any spaces in the URI. If that all works, something
strange was going on before. If neither 0049 or +49 >>>work in
Linphone, I would suggest contacting PeopleFone support and asking if
there is any known incompatibility with >>>Linphone and their SIP
service. I would also ask them to confirm whether dialling Germany
from Austria requires any >>>special country codes or prefixes, or if
they have special dialling rules set up for Germany.
I'm interested to know how you get on...
On Wed, 9 Jan 2019 at 16:25, Andi Soko <sok...@soko.cc> wrote:
Ohh Ok...makes now more sense to me.
I don't have any clue how SIP works but I reckon to specialists like
you it makes perfect sense :)
Find attached the log of a successful call.
Thanks again
Soko
On Wed, 09 Jan 2019 13:06:53 +0100, Christopher Woods
<christopherwo...@gmail.com> wrote:
It can sometimes be a real headache for no obvious reason :-)
Sounds like they may be using another provider to carry
international calls which doesn't accept AAC, and they may >>>>>be
transcoding for national calls or just leaving it alone.
If however your 'local' calls are only to other users on the same
provider, this isn't totally unexpected, as those calls will
>>>>>usually be establishing directly between devices instead of
having the call audio transcoded via the SIP proxy.
Disabling AAC may have made their system accept one of the lower
quality codecs which they may not officially >>>>>support, but which
works anyway.
Could you send the same kind of log over as before, except showing a
successful call? I'm interested to see what >>>>>codecs it shows -
what codecs are in use? Tap the 'signal bars' icon in top left
corner to display the bit rate and >>>>>codecs in use. You may have
to move your finger to it carefully to avoid triggering the
proximity sensor if it's on the >>>>>same side.
Cheers
Chris
On Wed, 9 Jan 2019, 05:18 Andi Soko <sok...@soko.cc wrote:
Good morning Christopher,
You know... I'm a technical guy... but sometimes cause and effect
eludes me...
After playing around a while with your suggestions it turns out
disabling "AAC-ELD 16kHz" in the audio settings >>>>>>solves the
issue?!?!?
I can understand why a not supported codec can result in a "call
failed".
But how is it possible, that an audio setting is OK for local
(inner-country) calls but wrong for international?!?!
Do you have any clue?
Anyhow... thanks heaps for the awesome help with my issues.
Thanks again!
Soko
On Tue, 08 Jan 2019 19:18:14 +0100, Christopher Woods
<christopherwo...@gmail.com> wrote:
488 not acceptable here can be due to codec problems. In the SDP
in the initial invite, I don't see any G.711 A-law >>>>>>>or U-law
(aka PCMA/PCMU) listed - only Speex, iLBC, AAC and Opus plus the
usual signalling telephone-event >>>>>>>stuff.
Chances are your new telco provider may not wish to transcode to
G.711, so is refusing the set up? Settings -> >>>>>>>Audio ->
PCMU/PCMA at the bottom. I'd expect to see
a=rtpmap:8 PCMA/8000
a=rtpmap:0 PCMU/8000
in the SDP from your client along with all the other codecs, if
calling SIP to PSTN, as fallback codecs. Further >>>>>>>confirmed
by their wiki --
https://enwiki.peoplefone.com/wiki/Supported_Codecs
peoplefone supports the codecs G711a/u, G722, G729. We also
support the T-38 protocol for fax. (Please >>>>>>>>contact us, if
you want to use it.)
Please try to follow the order in the configuration if
possible:
g711a
g711u
g722
g729
Sidenote - although you appear to already have it disabled, if you
have problems establishing calls in future make >>>>>>>sure you
the video feature is disabled ("always use video" on the desktop,
"Enable video" in the mobile client).
Video requires RTP/AVPF profiles to be sent in the SDP, which some
SIP proxies don't like. Your invite appears to >>>>>>>be OK though
(RTP/AVP), except for the lack of G.711 codecs advertised in your
INVITE.
On Tue, 8 Jan 2019 at 09:04, Andi Soko <sok...@soko.cc> wrote:
Hi Sylvain,
Sorry, I've made a wrong assumption. I had an old SIP line from a
different provider in Linphone and didn't know that dailing from
the history also dails the old provider.
So the real issue is apparently:
I cannot dail international numbers with Linphone and
peoplephone.at. Non-international numbers work! With an other App
(Zioper) or another SIP line (localphone.com) everything works.
- Changing the setting "Subsitute + in phone number" doesnt make
a difference
- In the setting "Country code prefix" (if this setting is from
importance) I have tried "+43", "0043" and "0" (country I'm in).
Somehow it doesnt take "" as an entry.
The error is still the same:
Call failed
Cannot call + +4935...9915
Reason was: Not Acceptable Here
[Media Descriptions Syntax error while parsing the SDP]
Find attached the log file.
thanks
Soko
On Tue, 08 Jan 2019 09:43:30 +0100, Sylvain Berfini
<sylvain.berf...@belledonne-communications.com> wrote:
Hi Soko,
Can you attach the logs starting from the INVITE sent to the
server at peoplephone.at to the moment you have the media
description syntax error please ?
Thanks.
Le 08/01/2019 à 09:39, Andi Soko a écrit :
Hey guys,
I have linphone installed and using the a SIP line from
peoplephone.at.
I mainly call customers in Germany and when I call their
official/main number "+4935...9926" everything works.
But when I call an extension-number to get to a specific person
(+4935...9915) I get the following error:
Call failed
Cannot call + +4935...9915
Reason was: Not Acceptable Here
[Media Descriptions Syntax error while parsing the SDP]
When I use another SIP client app (i.e. Zioper) with the same
SIP line all numbers are working. But I like linphone interface
and would like to use it :)
can anyone give me some hints were to look at or which option
to change?
thanks
Soko
_______________________________________________
Linphone-users mailing list
Linphone-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/linphone-users
_______________________________________________
Linphone-users mailing list
Linphone-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/linphone->>>>>>>>users_______________________________________________
Linphone-users mailing list
Linphone-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/linphone-users
_______________________________________________
Linphone-users mailing list
Linphone-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/linphone-users
_______________________________________________
Linphone-users mailing list
Linphone-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/linphone-users
_______________________________________________
Linphone-users mailing list
Linphone-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/linphone-users
_______________________________________________
Linphone-users mailing list
Linphone-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/linphone-users
