Bellen en glasvezel

BELLEN
, , ,
103

Bedankt voor het delen van jouw configuratie.

Ik gebruik pjsip ipv. sip, dat vraagt iets meer config. Dit is alleen de freedom specifieke config in pjsip.conf:
Transport sectie:

[transport-tls-nat]
type=transport
protocol=tls
method=tlsv1_2
ca_list_path=/etc/ssl/certs
bind=<IP van je server of 0.0.0.0>
local_net=<subnet van je lokale adressen>
external_media_address=<Public IP>
external_signaling_address=<Public IP>

De ca_list_path zorgt ervoor dat je daadwerkelijk het certificaat van de server checkt, het pad kan wat wisselen tussen distro’s.

Registratie:

[freedom]
type=registration
transport=transport-tls-nat
outbound_auth=freedom
server_uri=sip:<Account ID>@sip-tls.freedom.nl
client_uri=sip:<Account ID>@sip-tls.freedom.nl
max_retries=20000    ; There is no "unlimited" option, with retry_interval=60
retry_interval=60    ; this is almost two weeks of retries, should be enough
forbidden_retry_interval=600
expiration=3600
line=yes
endpoint=freedom
auth_rejection_permanent=false
support_outbound=yes

Hier is vooral belangrijk om te zorgen dat hij bij een gefaalde register (bijvoorbeeld doordat je internet verbinding er even uit ligt) blijft proberen. Support_outbound is ook een leuke, die zorgt dat alle connecties vanuit jouw server geïnitieerd worden, ook voor inkomende oproepen. Dat zorgt ervoor dat je in je firewall alleen maar uitgaande verbindingen hoeft toe te staan en inkomend alles dicht kan laten, wel zo veilig.

Authenticatie:

[freedom]
type=auth
username=<Account ID>
password=<Password>

Endpoint:

[freedom]
type=endpoint
disallow=all
allow=alaw
aors=freedom
context=from-freedom
;media_encryption=sdes
acl=freedom
rewrite_contact=true
direct_media=false
transport=transport-tls-nat
from_user=<Account ID>
from_domain=sip-tls.freedom.nl
outbound_auth=freedom

Zoals je ziet staat media_encryption nu even uit om te kunnen testen. Direct_media=false is een belangrijke icm. NAT. De ACL waarnaar verwezen wordt staat in acl.conf.
Deze config zorgt ervoor dat je calls in de context “from-freedom” komen met als extension je Account ID.

Identity om te zorgen dat inkomende calls herkend worden als zijnde van Freedom:

[freedom]
type=identify
match=195.35.114.0/23,185.103.76.0/22
endpoint=freedom

AoR:

[freedom]
type=aor
contact=sip:<Telefoonnummer>@sip-tls.freedom.nl

Bovenstaande config gaat dus allemaal in pjsip.conf

Last but not least de ACL in acl.conf:

[freedom]
deny=0.0.0.0/0.0.0.0
permit=195.35.114.0/255.255.254.0 
permit=185.103.76.0/255.255.252.0

Als je iets ziet wat beter kan hoor ik het ook graag, ik ben zeker geen asterisk guru en dit is ontstaan in mijn weg om het aan de praat te krijgen :slight_smile: .

104

Hoi

Vanaf Asterisk 21 is er geen sip.conf meer en moet het met pjsip.conf.
Ik ben me dus een beetje in pjsip aan het verdiepen. Ik heb zo’n conversie tooltje losgelaten op sip.conf. Wat opvalt is dat ie het verschil tussen lokale en remote registraties niet zo goed snapt. Op zich niet zo gek omdat dit in sip.conf een beetje vaag is.
Noot: Ik heb deze pjsip.conf dus nog niet getest!

Ik heb hier dus geen NAT en wel IPv6. Het tooltje komt met twee aparte TLS transports;

[transport-tls6]
type = transport
protocol = tls 
bind = [::]
cert_file = /etc/asterisk/fullchain.pem
priv_key_file = /etc/asterisk/privkey.pem
verify_server = no
method = sslv23

[transport-tls]
type = transport
protocol = tls
bind = 0.0.0.0
cert_file = /etc/asterisk/fullchain.pem
priv_key_file = /etc/asterisk/privkey.pem
verify_server = no
method = sslv23

Men zegt dat bij het niet beschikbaar zijn van IPv6 automatisch word teruggevallen op IPv4. In dit verband is het interessant om te kijken wat er gebeurd als je geen transport opgeeft. Met sip.conf is dual stack in ieder geval geen probleem.
Ik vroeg me af of sslv23 niet te strak is. Jij hebt daar sslv12. Misschien is sslv123 wat.
support_outbound ken ik niet. Verwijst naar RFC 5626. Maar eens doorlezen.

Endpoint;
Ik heb hier direct_media=no omdat Asterisk dan als RTP proxy werkt. Met conversies die hierdoor mogelijk zijn. Bv IPv4 ↔ Ipv6.
Het tooltje komt met;
from_domain=freedom.nl

Identify, Ruime match;
match = sipproxy.voipgrid.nl
match = 185.103.76.0/22
match = 195.35.114.0/23
match = 2a06:2a80::/29

Ik vind ‘match’ een stuk beter geregeld dan in sip.conf.
Er is hier geen ACL. Ik heb wel restricties voor de LAN middels contact_permit en contact_deny.

Aor;
Het tooltje gebruikt hier de Account_Id ipv mijn telefoon nummer.

ACL;
Het tooltje maakt een ACL met contact permit en deny voor de LAN.

Dank voor pjsip info.
Pjsip is helemaal nieuw voor mij.

Vr.Gr,
Rob

105

Precies, dat was voor mij de voornaamste reden om met pjsip te beginnen. Helaas aan de voorbeelden op de wiki allemaal uit van sip.conf.

Volgens mij is dat niet nodig. Als je de IPv6 bind doet ([::]) dan zou je ook IPv4 moeten pakken.

Let op: tls1_2 niet ssl :slight_smile: . pjsip default naar tls1 en daarmee kwam tls niet op, met tls1_3 ook niet, met tls1_2 wel. Mijn conclusie is dat sip-tls.freedom.nl nog geen tls1.3 doet.

Voor zover ik weet is een transport verplicht, de keren dat ik een fout in m’n transport had zitten (waardoor dat deel van de configuratie genegeerd wordt) kwam m’n endpoint niet op.

Die is niet nodig. Volgens Algemene firewall instellingen - Help is IPv6 alleen in gebruik voor de webhooks.

Eerlijk gezegd is AoR bij mij nog een vaag concept dus ik weet ook niet of mijn invulling juist is.

In priincipe doet het hier nu wat ik wil. Alleen CLIP (nummerweergave) doet het nog niet. :thinking:, ik heb ook nog niet kunnen vaststellen of dat aan asterisk of m’n ATA ligt.

106

Hoi

De documentatie word momenteel herschreven. Het gevolg hiervan is dat de links in de voorbeelden niet meer werken. Ik heb mbv web archive een beperkte conversie gemaakt;
http://www.sput.nl/software/asterisk/webarchive-links.html

Een bind aan ‘::’ werkt perfect in sip.conf. Volgens sommigen kom je in pjsip.conf dan voor IPv4 op IPv6 mapped IPv4 adressen uit (bv ::ffff.1.2.3.4). Dit kan een bug zijn in oudere versies pjsip.

Ik heb sslv23 geinterpreteert als versie 2 of 3. Blijkbaar is dat 2.3. Weer iets dat ik nergens heb kunnen vinden.

Met SRV lookups enabled (default) kom je op IPv6 uit. Zie ook;
http://www.sput.nl/internet/freedom/voip.html
Dit is dus iets dat met match een stuk makkelijker is.
In een transport een IP versie vastleggen is dus niet handig. SRV records kunnen immers veranderen.

Nummer weergave werkt hier perfect. Sinds een tijdje werkt naam bij nummer ook weer. Maar dat alles dus zonder ATA. Het is hier allemaal SIP.
Noot: Er zijn twee methoden voor nummerweergave bij POTS. FSK en DTMF. Voor zover mij bekend gebruiken alleen Nederland en India DTMF. Als je ATA nummerweergave genereert moet dat dus DTMF zijn.

Iets anders. Ik heb een AGI die oa web lookups doet. Ik gebruik hiervoor nu text mode browser w3m, maar ik wil eigenlijk iets gaan gebruiken dat JavaScript ondersteund. Bv iets met headless Chromium ofzo.
Suggesties zijn welkom.

Vr.Gr,
Rob

107

Bedankt voor de links naar webarchive. Die kom je inderdaad nog vaak tegen. Sowieso kom ik voor goede documentatie nu vaak op andere plekken dan de site van asterisk uit. Wel jammer dat ze de oude documentatie weg hebben gehaald voordat er nieuwe is.

Volgens mij bestaat SSL 2.3 helemaal niet, dus jouw eerste interpretatie lijkt me beter. Sowieso, als je ergens nog echt SSL gebruikt is het goed om daar eens kritisch naar te kijken en naar minimaal TLS1.2 over te gaan.

SRV records heb ik zelf eigenlijk nog nooit gebruikt. Misschien moet ik daar ook eens naar kijken.

Het lag inderdaad aan de ATA. Er zijn ook nog een hoop (sub)varianten van DTMF en FSK, als ik alle mogelijke combinaties in m’n ATA uitvermenigvuldig kom ik op meer dan 100 mogelijkheden uit :slight_smile: . Op m’n DECT werkt het inmiddels, op m’n all-in-one (HP 6790) niet, maar dat is minder belangrijk.

Dat zal lastig zijn denk ik. In het verleden heb ik wel eens firefox laten draaien op een Xephir/Xvfb, daarop kan hij dan gewoon z’n GUI kwijt maar je ziet er uiteindelijk niets van. Het bedienen is dan wel een dingetje :slight_smile: .
Een ander idee is misschien om de javascript in nodejs te draaien? Alleen heb je dan iets nodig wat de API’s die browsers beschikbaar stellen emuleert.

108

Hoi

stdin - stdout met pipe() - fork() - exec() vind ik het makkelijkst.

Een vriend stelde dit voor;
Webdriver versie 1:

Webdriver versie 2:

Ik heb er even vluchtig naar gekeken. Werkt zo te zien met HTTP achtig protocol via socket. Ook goed.

Daarnaast schijn je headless [1] met een scriptje te kunnen starten. Zo’n scriptje kan je natuurlijk als temp file on the fly genereren.

[1] Voorbeeld;

chromium --headless --disable-gpu --dump-dom https://javatester.org/javascript.html | html2text

Zegt hier dat JavaScript disabled is, maar daar is wel uit te komen.

Vr.Gr,
Rob

109

WebDriver ziet er inderdaad interessant uit, ik kende het nog helemaal niet. Het klinkt inderdaad zinvol om op die manier een browser te “bedienen”. WebDriver2 ziet er ook veelbelovend uit, maar het document is net een paar maanden oud, ik verwacht dat het nog wel even duurt voordat browsers het ondersteunen.

Inmiddels heb ik overigens ook een ticket bij Freedom ingeschoten voor de inkomende gesprekken die niet gecrypt zijn.

110

Hoi

In Debian package chromium-driver dat chromedriver bevat. Er is in Debian geen Firefox equivalent, wil in Ubuntu als ik het wel heb. Er staat echter een Firefox equivalent op Github;

Ik heb gister wat zitten experimenteren met telnet en dan wat voorbereide JSON’s cut and pasten;
Als je HTML ophaalt zit dat ook weer in een JSON.

Er zijn laagjes die je boven op webdriver kan leggen waaronder Selenium. Maar die hebben dan weer geen C bindings. Maar wie into Python is kan z’n hart ophalen.

Ik weet overigens niet of er buiten Nederland ook telefoon reverse lookup websites zijn. Misschien eerst maar eens naar kijken.

Eens kijken wat Freedom zegt over de binnenkomende RTP.

Vr.Gr,
Rob

111

Ik ben nog wat verder aan het sleutelen aan m’n asterisk setup. Wat ik voor elkaar wil krijgen is dat ik vanuit het dialplan kan bepalen of bij een uitgaand gesprek m’n nummer weergegeven wordt bij de ontvanger.
Default staat dat aan, dus als ik standaard Dial(PJSIP/${EXTEN}@freedom) doe dan zie ik op m’n mobiel dat het nummer weergegeven wordt.
Nu probeer ik dat te onderdrukken met Dial(PJSIP/${EXTEN}@freedom,u(prohib)) maar dat heeft geen enkel resultaat. In plaats van prohib heb ik ook unavailable en prohib_not_screened geprobeerd, maar het heeft allemaal als resultaat dat het nummer weergegeven wordt. Deze experimenen zijn gebaseerd op deze documentatie: Dial - Asterisk Documentation

Zijn er nog andere manieren om dit voor elkaar te krijgen?

Edit: Inmiddels heb ik ook Set(CALLERID(pres)=prohib) gevonden, en ook dat heeft geen resultaat.

Edit 2: Inmiddels heb ik gevonden dat ik *31* voor het gebelde nummer moet zetten om mijn nummer te onderdrukken, Dial(PJSIP/*31*${EXTEN}@freedom) is dan dus het juiste Dial commando.

112

Hoi

Zelf heb ik wegens overlast anoniem bellen hier geblokkeerd. Compleet met zelf ingesproken tekst en uitleg;
Je kan anoniem bellen uitschakelen met *31#.

Vr.Gr,
Rob

113

Dat is vervelend inderdaad, zelf heb ik daar nog geen last van.
Wat ik nu gemaakt heb is dat op basis van het gekozen nummer het weergeven van m’n nummer geblokkeerd wordt. Bel ik naar bekenden dan wordt het nummer gewoon meegegeven, bel ik naar een onbekende dan wordt het onderdrukt.

114

SIP RING komt echt van de oproepende partij, wat er vermoedelijk gebeurt bij support outbound is dat er een “SIP ping” of SIP empty packet naar de andere kant gaat om dat NAT levend te houden.

Even de RFC opgezocht. Outbound support doet 2 dingen… het laat de client 1) een verbinding initieren en leven houden en 2) bij tls ook de certificaat controle. Daarbij kan de server vervolgens de calls over de “link” sturen met de laatst bekende credentials. etc.
Het is dus een gloryfied NAT keep alive.

115

Het klopt dat het inderdaad voornamelijk een oplossing is die is bedacht vanwege NAT issues. Als het bij-effect is dat ik alleen maar uitgaande verbindingen hoef toe te staan vind ik dat ook mooie veiligheidswinst :slight_smile: . Hoe minder bereik m’n server vanaf internet heeft hoe beter.

Wat jij omschrijft zie ik inderdaad ook gebeuren: De TLS sessie waarmee de register heeft plaatsgevonden wordt in stand gehouden en gebruikt om een invite van de SIP provider naar mij te sturen. Voor een uitgaande invite wordt een aparte TLS sessie gebruikt.
Voor de media wordt in de SIP sessie afgesproken welke adressen en poorten er gebruikt worden, en dan wordt er vanuit mijn server een UDP pakket uitgestuurd wat eruit ziet als een UDP antwoord op die adres/poort combinatie waardoor er een (statefull) gaatje in de firewall ontstaat en de sessie vanuit de SIP provider naar binnen mag.

116

De uitdaging begint pas als je twee sites met elkaar wil laten praten die allebei achter NAT liggen… of nog leuker CGNAT…
(Ik bedoel dan de RTP (voice/video) deel van de verbinding. want je moet ook bij de ander binnen komen).

117

NAT aan beide kanten is sowieso een situatie die directe communicatie tussen twee clients stukmaakt, dat geldt niet alleen voor SIP maar ook andere protocollen met soortgelijke mogelijkheden. Als het een NAT is die je zelf in de hand hebt (bijvoorbeeld op je router thuis) dan valt er nog wat te regelen met port forwards. Voor NAT’s waar je dat niet hebt zou support_outbound een optie kunnen zijn, met CGNAT ben je over het algemeen game over.
Een oplossing daarvoor is een 3e partij waar beiden naartoe verbinden en die de communicatie tussen die twee kan regelen. Die 3e partij kan een echt externe partij zijn of een eigen server/VPS.

118

Inmiddels heb ik wat contact gehad met de helpdesk, en er lijkt een oplossing te zijn:
Als je sip.encryptedsip.com gebruikt ipv. sip-tls.freedom.nl dan werkt de encryptie zowel inkomend als uitgaand. Gevalideerd met logs en wireshark, en asterisk staat nu zo dat is niets accepteert wat unencrypted is.
Dat nu wetende heb ik deze documentatie gevonden:
https://www.voipgrid.nl/partnerinformatie/encrypted-bellen/
En ik zie dat het nu ook zo op Encrypted bellen - Help staat, ik ga nu bijna twijfelen of dat onlangs is aangepast of dat ik er echt al die keren overheen heb gelezen :slight_smile: .

Het forum waarschuwt me netjes dat dit in februari 2023 al eens in dit topic vermeld was, maar aangezien we dat beiden over het hoofd hebben gezien lijkt het me geen probleem om dat nog eens te posten :slight_smile: .

Er zijn wel een paar dingen anders aan de SIP TLS sessie naar sip.encryptedsip.com:

  • sip.encryptedsip.com ondersteund TLS1.3 (sip-tls.freedom.nl doet TLS1.2)
  • sip.encryptedsip.com maakt gebruik van een wildcard certificaat, dat mag niet volgens RFC 5922. In de pjsip configuratie moet je allow_wildcard_certs=yes zetten, anders vind asterisk hem niet ok.
119

Hoi

Ik ben eindelijk aan de pjsip.
Het blijkt dus dat de pjsip IPv6 sockets IPv6-only zijn. Je kan dus een ‘bind=[::]’ met een ‘bind=0.0.0.0’ combineren. Derhalve zijn er zes transports te maken waar je er met chan_sip / sip.conf drie had;

Transport:  transport-tcp             tcp      0      0  0.0.0.0:5060
Transport:  transport-tcp6            tcp      0      0  [::]:5060
Transport:  transport-tls             tls      0      0  0.0.0.0:5061
Transport:  transport-tls6            tls      0      0  [::]:5061
Transport:  transport-udp             udp      0      0  0.0.0.0:5060
Transport:  transport-udp6            udp      0      0  [::]:5060

Dat de pjsip IPv6 sockets IPv6-only zijn is niet makkelijk te vinden. Het staat in de changelog. In de Asterisk source vind je het niet direct terug omdat pjproject een aparte tar is. Als je die uitpakt zie je dus wel dat met setsockopt() de socket IPv6-only geforceerd word.

Nu geld voor veel VoIPGRID SIP dozen dat ze naast een IPv4 adres 195.35.x.y een IPv6 adres 2a06:2a80:0:x::y hebben. En allemaal luisteren ze naar poort 5061. TLS via IPv6 kan dus gewoon.

sipproxy.voipgrid.nl was middels SRV records dual stack, maar dat is recent IPv4-only geworden.
Wel is er een sip6.voipgrid.nl. Deze heeft twee IPv6 adressen en middels SRV records komen er daar nog twee bij. Een viervoudige redundantie dus. En pjsip doet aan fail over.

Ik heb de pjsip.conf net zolang getweakt todat de SIP pakketten de zelfde zijn als met sip.conf. Alles werkt: UDP, TCP, TLS, IPv4 en IPv6.

Blijven er twee punten over;

Als ik in de config ‘sips:’ ipv ‘sip:’ gebruik, blijft de ‘From:’ in een
uitgaande INVITE hardnekkig ‘sip:’ en word derhalve geweigerd. Ik weet eigenlijk niet of ik sips nodig heb.

Bij gecrypte audio is binnenkomend nog steeds niet gecrypt. Zonder ‘media_encryption_optimistic=yes’ worden binnenkomende INVITE’s dan geweigerd.

Vr.Gr,
Rob

120

Ik moest hier ook weer even in duiken, het is een tijd geleden dat ik hier mee bezig ben geweest.

Voor dual stack kan ik niet terug vinden dat je iets bijzonders hoeft te doen. Door op de IPv6 wildcard te luisteren regelt het OS dat ook IPv4 meegenomen wordt. Dat is wel afhankelijk van de setting in /proc/sys/net/ipv6/bindv6only welke op 0 moet staan.

Volgens mij is sips op zich niet nodig. Als ik op mijn link naar freedom kijk zie ik ook dat alles als sip: uri’s voorbij komt, terwijl het toch zeker over sip-tls gaat. In dit geval dwing je dat al af met je asterisk configuratie.

Heb je sip.encryptedsip.com al eens geprobeerd (zie mijn vorige post)? Dat heeft bij mij alle problemen rondom encrypted audio verholpen.

121

Hoi

/proc/sys/net/ipv6/bindv6only regelt de default. Meestal is deze 0 (bij mij ook). Maar je kan hier met setsockopt() van afwijken;

int opt6only;
opt6only = 0;   
setsockopt(sfd, IPPROTO_IPV6, IPV6_V6ONLY, &opt6only, sizeof(int));

sfd is de socket file descriptor.
opt6only = 0 maakt de socket dual stack.
opt6only = 1 maakt de socket IPv6-only.

pjsip is om mij onbekende redenen ontworpen voor aparte IPv4 en IPv6 sockets. Toen dat problemen gaf op veel Linux systemen (die dus standaard dual stack zijn), heeft men IPv6 sockets IPv6 only geforceerd.

Je kan dit eenvoudig zelf testen;

[transport-tcp6]
type=transport
protocol=tcp
bind=[::]

Als dan een telnet 127.0.0.1 5060 niet werkt is de socket IPv6-only.

sip.encryptedsip.com heb ik zeker geprobeerd. Werkt alleen met uitgaande encrypted audio.

Vr.Gr,
Rob

122

Dat klopt, maar dat wil je toch juist? Of wil je inkomend alles gecrypt hebben en uitgaand per call een keuze maken?