Exactly. It massively depends on how it’s customized / configured by the provider. Some providers document it more or less or another example here, others not at all (but it’s discussed on free forums as an example for Deutsche Telekom (which is listed as customer of Assia) where even employees of the provider are involved). Deutsche Telekom is rather aggressive. Restarting for a firmware update is ok. But regular restarts could be critical. If you want to do a restart, you should completely turn off the modem (= disconnect power) and wait for at least 15 minutes (that’s what’s guessed for Deutsche Telekom), to be sure, that DLM doesn’t rate it as an DSL line error. I read about users complaining about (massively) reduced bandwidth just because of a short thunderstorm. I don’t know how others react.
Yes - FreePBX doesn’t support it on the GUI - you have to do it via direct configuration in the configfiles (that’s why I mentioned the file names). You can find it under Administrator → Config edit.
BTW: you always need this “feature” if your IP address changes - the reason for the change is pretty irrelevant
Maybe DLM was the reason for the disconnects? Now, your line is considered stable by DLM and it doesn’t need to “optimize” the DSL parameters any more. Did you check for changed DSL parameters after each change of the IP address? After a DSL resync you always will get a new IP address (if your provider doesn’t give you a static one).
@dirk2358 Really interesting and definitely good to know! Even though I don’t think I ever had any problems, the throughput here is always nearly constant. I just found out about the Config Edit module. I will check that out tonight. Until now I always edited the custom files via SSH.
No, I didn’t check for changed DSL parameters, because since I noticed that problem the IP address didn’t change.
@BlazeStudios I couldn’t post the output of the transports when the issue occurs, because it didn’t occur since @Stewart1 requested those logs. I have a cronjob that will inform me the next time the IP address changes, but until then I don’t have them, so I cannot post them.
@BlazeStudios I just figured out why it’s appearing there two times. I set the local network once in ‘Settings’ -> ‘Asterisk SIP Settings’ -> ‘General SIP Settings’ and another time in ‘Settings’ -> ‘Asterisk SIP Settings’ -> ‘SIP Settings [chan_pjsip]’ -> ‘0.0.0.0 (tls)’ -> ‘Local network’. I thought that’s how it’s supposed to be. Which one is wrong?
@dicko It seems like ‘Default’ is ‘tlsv1’ instead of the newer methods. Changed it now.
So, the IP address changed again and the issue occured. This time I didn’t use fwconsole restart but instead I tried a few other commands and checked in-between if that makes it work again:
The last one gave out the error Unable to load config file 'pjsip_wizard.conf', but none of them made a change, so I gave up. Around 30 minutes later I sent a call from a remote extension and then it magically worked. I didn’t change any configuration in those 30 minutes. But even worse, after 4 more hours I tried making another call from the same remote extension and it stopped working again. The IP address didn’t change during that time.
I have not the slightest explanation how this is possible.
@BlazeStudios I always expected the more supported codecs the better, but I changed that now.
Exactly, it doesn’t matter which endpoints I use, there is always no audio at all (in both directions).
@BlazeStudios No audio, that’s right. Ping or host command from FreePBX itself shows that it resolves correctly to the external IP address. The same like on every other device.
I don’t believe that a real call would show more useful info with these logging settings. The 200 OK response has both an incorrect (local) Contact header (just like the similar thread) and c=IN IP4 <SERVER INTERNAL IP> (unlike the similar thread), so it explains why there was no audio.
It appears that either pjsip somehow decided the remote address was local, or something went wrong when it attempted to substitute the external address.
One thing that looks strange is that Direct Media is set for the extension. While an echo test of course could not actually use direct media, it’s conceivable that the test is wrong and turning this off will help.
For further debugging, turn on Enable Debug in Asterisk SIP Settings → [chan_pjsip]. I don’t know enough about pjsip to interpret the output, but hope that if you paste logs for a failing call and a working one, we’ll be able to see where things go astray.
So, I tried turning off Direct Media, but with no effect. Anyway I still left it turned off.
Then I had the idea to enable the option ‘Settings’ -> ‘Asterisk SIP Settings’ -> ‘SIP Settings [chan_pjsip]’ -> ‘Allow Transports Reload’ and applied the configuration. This made the issue (probably just temporarily) disappear. I also disabled it, because it’s not recommended.
Does anyone of you know where I can find the PJSIP Debug Log I just activated? I cannot find it next to the other logs.
Edit: I just checked pjsip show transport 0.0.0.0-tls and it still shows me the subnet two times, even though I removed it from ‘Settings’ -> ‘Asterisk SIP Settings’ -> ‘SIP Settings [chan_pjsip]’ -> ‘0.0.0.0 (tls)’ -> ‘Local network’ and now it’s only in ‘Settings’ -> ‘Asterisk SIP Settings’ -> ‘General SIP Settings’. What am I missing?
