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
