|Subject:||Re: [Linphone-users] Call failed to certain numbers|
|Date:||Wed, 09 Jan 2019 21:02:05 +0100|
|User-agent:||Opera Mail/1.0 (Win32)|
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,ChrisOn Wed, 9 Jan 2019 at 19:29, Andi Soko <address@hidden> 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.SokoOn Wed, 09 Jan 2019 19:22:42 +0100, Christopher Woods <address@hidden> 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 8a=rtpmap:0 PCMU/8000a=rtpmap:8 PCMA/8000PCMU 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 111I 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 callingINVITE sip:+ address@hidden SIP/2.0Via: SIP/2.0/UDP 192.168.254.71:49268;branch=z9hG4bK.xEZZuwbrr;rportFrom: "peoplefone" <sip:address@hidden>;tag=3-E0YDHEPTo: "+ 4935xxxxxx26" <sip:+ address@hidden>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 isSIP/2.0 180 RingingTo: "+ 4935xxxxxx26" <sip:+ address@hidden>;tag=11d896f4NB 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 address@hidden 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 <address@hidden> 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 againSokoOn Wed, 09 Jan 2019 13:06:53 +0100, Christopher Woods <address@hidden> 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.CheersChrisOn Wed, 9 Jan 2019, 05:18 Andi Soko <address@hidden 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!SokoOn Tue, 08 Jan 2019 19:18:14 +0100, Christopher Woods <address@hidden> 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:0 PCMU/8000in 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_Codecspeoplefone 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:
- g729Sidenote - 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 <address@hidden> 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
- 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:
Cannot call + +4935...9915
Reason was: Not Acceptable Here
[Media Descriptions Syntax error while parsing the SDP]
Find attached the log file.
On Tue, 08 Jan 2019 09:43:30 +0100, Sylvain Berfini
> 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 ?
> 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?
>> Linphone-users mailing list
> Linphone-users mailing list
Linphone-users mailing list
Linphone-users mailing list
Linphone-users mailing list
Linphone-users mailing list
|[Prev in Thread]||Current Thread||[Next in Thread]|