muhpages VII 
Well, welcome to the 21st century and to the deep fall pit named all-ip-connect.
Everything just worked
I was proud owner of a device, which is very common in Germany called FritzBOX, which simply worked. It was kind of boring. This is how I decided to screw myself deeply. I decided to do it by myself - 100%. This was a time consuming idea to have.
In fact I had the change to update my Internet connection to unbelivable 250 MBIT down and 40 MBIT up. My FritzBOX wasn't able to handle this enourmous connectivity.
So I decided to have even more problems and trouble with my own environment.
It was a no brainer to give up easiness and reliability and exchange it with something open source and home brewn. Another brand then the stable Fritzbox must be experienced. That's why this robust, working and never failing device was exchanged by a Vigor 160 modem.
Suprisingly this worked out of the box. You cannot image the experience of this speed. Again after 10 years, you can find corners in the Internet slower then yourself.
How ever wants to use phones anymore
The first night of implementing the new solution had some fall pits. I tried to put the FritzBox after the new internet connection as a normal client in the network. This with only one responsibility. Handle the god damn phones.
It failed.
Somehow it didn't manage to get the SIP connection up an running. But who needs a working phone anyway?
Wasn't the web interface working yesterday
The next days I tried to figure out what was wrong with the setup. I tried to modify my settings to the Vigor web interface and it simply wasn't there anymore.
I did usual testing and first configured ssh access to bypass the web interface. But how to connect, if ssh fails on first try?
Add this to your ssh client configuration
Host 192.168.x.y
User $YOUR_ADMIN_NAME
Ciphers 3des-cbc
KexAlgorithms +diffie-hellman-group1-sha1
You have to limit you connections almost to clear text encryption extended by rot13 or similar. With that you can connect.
But than a lucky punsh safed my day. I hitted CTRL+W which closed my Chrome and I used Firefox to reconnect to the Vigor webinterface. It worked. It seems like the Vigor webinterface does not limit Chrome in the way it opens connections. This overstuffs the webserver, which leads to the point where the web interface if falling apart and does not work anymore. Firefox does not kill it completly so it stays functional.
I have a strong guess how Vigor tests their web interface.
If you notice the content of web pages disappears, always try to use another browser.
Can you hear me
After reading some entries in forums and reactivated what I personally have experienced with Asterisk, I had a first configuration.
My PBX was able to register with Telekom sip servers, but outgoing servers didn't work. I got refused (403 Forbidden).
Then incoming calles started to work, but with a flaw. I can hear the caller but my complains about the complexity of the setup stayed unheared. The simply didn't reach the other side. I cannot tell why and how my modem predicted to drop or rearange this traffic, but it got lost on it's way. The obvious solution was to pin down the outgoing ip address of the pbx to the one, which is used for NAT.
This did the trick.
The additional 10 seconds
The newly introduced vdsl modem has a flaw in routing mode. It it's up some queries. So the NAPTR record wasn't resolved. This added additional 10 seconds to each outgoing SIP call.
This I didn't know, back than.
But as i digged through the Internet, i found a hint in a forum of my provider claiming that DNS made issues for the installation.
To keep "Christian" honored, even if the telephone company (again) restructure their forum, here is the quote:
So, kurz zur Rückmeldung. Wir haben das Problem gefunden. Es handelt sich um ein DNS Problem in kombination der Telekom DNS Server und unserem DNSMASQ (auf OpenWRT). Um es kurz zu machen, die Telekom DNS Server lösen den SIP Server anders auf als die öffentlichen SIP Server. Auch verschiedene Telekom DNS Server lösen die Adressen (tel.t-online.de) verschieden auf. Scheint was mit dem Loadbalancing zu tun zu haben, ich kann schlecht nachvollziehen ob es sich um einen Bug oder ein Feature handelt. Schlussendlich habe ich auf den Asterisk Servern einen bind-server installiert. Alternativ kann man auch einen externen DNS anstelle dem Router-DNS eintragen.
Läuft erstmal. Bei Interesse schick ich gern weitere Infos.
Danke für die Mühe.
MFG Christian
He discovered the problem that if you do not use the upstream dns server, you can have issues connection to the SIP servers on provider side.
This made me curious and I also looked into the exchanged DNS data and found the query for an NAPTR record, which failed.
Bypassing my router isn't that problematic and so it was implemented fast and now the calles are made without adding additional 10 seconds of timeoutness to each and every call.
Ask your local dns server (or servers, if you have more than one) about this NAPTR record. It shouldn't fail but may differ at your location.
# host -v -t naptr tel.t-online.de.
Trying "tel.t-online.de"
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 46684
;; flags: qr rd ra; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 3
;; QUESTION SECTION:
;tel.t-online.de. IN NAPTR
;; ANSWER SECTION:
tel.t-online.de. 5707 IN NAPTR 20 0 "s" "SIP+D2U" "" _sip._udp.tel.t-online.de.
tel.t-online.de. 5707 IN NAPTR 30 0 "s" "SIP+D2T" "" _sip._tcp.tel.t-online.de.
tel.t-online.de. 5707 IN NAPTR 10 0 "s" "SIPS+D2T" "" _sips._tcp.tel.t-online.de.
;; ADDITIONAL SECTION:
_sip._udp.tel.t-online.de. 3060 IN SRV 10 0 5060 b-epp-110.edns.t-ipnet.de.
_sip._udp.tel.t-online.de. 3060 IN SRV 20 0 5060 d-epp-110.edns.t-ipnet.de.
_sip._udp.tel.t-online.de. 3060 IN SRV 30 0 5060 h2-epp-110.edns.t-ipnet.de.
Houston, we have a call
It depends on where and how you dig for information. Some forums claim that anonymous calling is possible, while others was you need to know the first name of your maternal cousin and combine it with the atomic weight of your sisters new spouse.
At the end it is unclear why some configuations work and others not, but with accepting almost anything and with that only enabling half of the feature set is a way of (wild guessing starts) backwards compatinility which drives you mad.
I had to implement auth using the T-Online account number and the dialup password. A weird combination partially found in the providers Forum and partially guessed. It may be different for you, because it may uses other username/password combinations like your email credentials with T-Online. This I didn't test or touched as I do not use email with my provider.
My working implemenation of Asterisk pjsip for T-Online sip in 2019.
[transport-udp]
type=transport
protocol=udp
bind=${IP_ADDRESS_OF_ASTERISK}:5060
local_net=${YOUR_NETWORK_WITH_MASK}
external_media_address=${DYNDNS_OR_OUTGOING_IP}
external_signaling_address=${DYNDNS_OR_OUTGOING_IP}
[telekom_aor]
type=aor
contact=sip:tel.t-online.de
[telekom_registration_makro](!)
type=registration
transport=transport-udp
server_uri=sip:tel.t-online.de:5060
retry_interval=60
forbidden_retry_interval=600
expiration=480
auth_rejection_permanent = false
line=yes
[telekom_auth_makro](!)
type = auth
auth_type = userpass
password = ${DIAL_IN_PASSWORD}:${TONLINE_USER_NO}-0001@t-online.de
realm = tel.t-online.de
[telekom_endpoint_makro](!)
type=endpoint
transport=transport-udp
context=telekom_in
disallow=all
allow=g722
allow=alaw
direct_media=no
from_domain=tel.t-online.de
force_rport=false
aors=telekom_aor
[telekom_${YOUR_NUMBER_NATIONAL_FORMAT}](telekom_registration_makro)
outbound_auth=telekom__auth
client_uri=sip:${YOUR_NUMBER_INTERNATIONAL_FORMAT}@tel.t-online.de
contact_user=${YOUR_NUMBER_NATIONAL_FORMAT}
endpoint=telekom_${YOUR_NUMBER_NATIONAL_FORMAT}_endpoint
[telekom_${YOUR_NUMBER_NATIONAL_FORMAT}_auth](telekom_auth_makro)
username=${YOUR_NUMBER_NATIONAL_FORMAT}
[telekom_${YOUR_NUMBER_NATIONAL_FORMAT}_endpoint](telekom_endpoint_makro)
outbound_auth=telekom_${YOUR_NUMBER_NATIONAL_FORMAT}_auth
from_user=${YOUR_NUMBER_INTERNATIONAL_FORMAT}
; callerid=${YOUR_NUMBER_INTERNATIONAL_FORMAT} - this is wrong and causes all
; calls to originate from the
; incoming number which was
; dialed and not from the
; callerid called in.
outbound_proxy = sip:${YOUR_NUMBER_INTERNATIONAL_FORMAT}@tel.t-online.de:5060\;lr
[acl]
type=acl
deny=0.0.0.0/0.0.0.0
permit=127.0.0.0/8
permit=217.0.0.0/13
permit=${YOUR_NETWORK_WITH_MASK}
| Variable | Description |
|---|---|
| IP_ADDRESS_OF_ASTERISK | Important if you have move than one ip address assigned to your pbx (#Can you hear me) |
| YOUR_NETWORK_WITH_MASK | 192.168.x.0/24 or similar (can be specified multiple times) |
| DYNDNS_OR_OUTGOING_IP | if you have dyndns, use this name. If not you have to alter the ip after it changed on your dialup machine. |
| DIAL_IN_PASSWORD | The password you router knows. |
| TONLINE_USER_NO | The 2nd part of the username your router knows. $CONNECTIONID-$TONLINE_USER_NO-$USERNO |
| CONNECTIONID | You should know that one. |
| USERNO | Usually 0001 |
| YOUR_NUMBER_NATIONAL_FORMAT | $LOCAL_PREFIX$NUMBER |
| YOUR_NUMBER_INTERNATIONAL_FORMAT | +$INTERNATIONAL_PREFIX$LOCAL_PREFIX_WITHOUT_LEADING_ZERO$NUMBER |
| LOCAL_PREFIX | 040 for Hamburg as an example |
| LOCAL_PREFIX_WITHOUT_LEATING_ZERO | 40 for Hamburg as an example |
| INTERNATIONAL_PREFIX | 49 for Germany as an example |
| NUMBER | Sequence of digits somebody else has to type into his sip phone to call you if he is in the very same region(LOCAL_PREFIX) |
Visitors
After 2h of having an Asterisk running on port 5060, I had visitors from Iceland with weird call out whiches. That's why this ACL is a good idea. It's also a good idea to limit the external access to this system to whom may contact there. Limiting it to the Telekom network is net perfekt, but better then nothing.
Please always remember that there is harm in what they named the Internet.