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 > <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
