[Gelöst] Asterisk + Easybell und ipv6 geht nicht

kombjuder

IPPF-Promi
Mitglied seit
2 Nov 2004
Beiträge
3,086
Punkte für Reaktionen
0
Punkte
0
Hallo,

ich habe die die Meldung mit der Einführung von IP V6 bei Sipgate gelesen und meinen Raspi heute entsprechend umgestellt.
Sipgate läuft auch problemlos.
Ich habe mich schlau gemacht welcher meiner Provider noch V6 kann und bin auf Easybell gestossen.
Die entsprechenden Änderungen gemacht und geht nicht. Ein eingehender Anruf produziert:

ERROR[3066][C-00000000]: netsock2.c:271 ast_sockaddr_resolve: getaddrinfo("2001:4090:4008::124", "(null)", ...): Address family for hostname not supported

An welcher Schraube muss ich drehen?

(Asterisk 11.18.0 auf Raspberry an T-Online IP-only)
 

andiling

IPPF-Promi
Mitglied seit
19 Jun 2013
Beiträge
5,975
Punkte für Reaktionen
1
Punkte
0
Hast Du das
Code:
bindaddr=::
gemacht, damit IPv6 überhaupt läuft?
 

kombjuder

IPPF-Promi
Mitglied seit
2 Nov 2004
Beiträge
3,086
Punkte für Reaktionen
0
Punkte
0
Ja, :: ist gemacht, sonst würde Sipgate ja nicht mit ipV6 laufen.
 

kombjuder

IPPF-Promi
Mitglied seit
2 Nov 2004
Beiträge
3,086
Punkte für Reaktionen
0
Punkte
0
Ja wirklich.

Sip show peers sagt:
sipgate-in 2001:ab7::4 Auto (No) No 5060 Unmonitored

und eingehende Anrufe kommen an.
 
Zuletzt bearbeitet:

koyaanisqatsi

IPPF-Urgestein
Mitglied seit
24 Jan 2013
Beiträge
13,705
Punkte für Reaktionen
515
Punkte
113
OK, ich glaubs dir, kannste ruhig wieder löschen. ;)
Und der Router muss das natürlich auch können.
Über Telekom (hab selber 1&1 mit DS) sollte auch natives DS aktiviert sein.
...dann gehen mir langsam die Ideen aus.
 

andiling

IPPF-Promi
Mitglied seit
19 Jun 2013
Beiträge
5,975
Punkte für Reaktionen
1
Punkte
0
Problem dürfte sein, dass eine rDNS Abfrage von 2001:4090:4008::124 keinen Hostnamen zurückgibt.
 

kombjuder

IPPF-Promi
Mitglied seit
2 Nov 2004
Beiträge
3,086
Punkte für Reaktionen
0
Punkte
0
Problem dürfte sein, dass eine rDNS Abfrage von 2001:4090:4008::124 keinen Hostnamen zurückgibt.

Der Kanidat hat 100 Punkte.

Also Reversabfrage aus der Authentifizierung rauswerfen, die Fehlermeldung bleibt, aber die Verbindung kommt zu stande.

Nicht schön, aber es funktioniert.
 

andiling

IPPF-Promi
Mitglied seit
19 Jun 2013
Beiträge
5,975
Punkte für Reaktionen
1
Punkte
0
Du kannst ja easybell drauf hinweisen, vielleicht passen die das an.
 

kombjuder

IPPF-Promi
Mitglied seit
2 Nov 2004
Beiträge
3,086
Punkte für Reaktionen
0
Punkte
0

Artabanos

Neuer User
Mitglied seit
6 Dez 2015
Beiträge
22
Punkte für Reaktionen
0
Punkte
0
Hallo,

da ich seit einiger Zeit vor exakt dem gleichen Problem stehe, würde ich gerne an diesen Thread anknüpfen.

Zunächst stellt sich die Frage, wieso die Fehlermeldung bleibt, obwohl die Reverse-Abfrage entfernt wurde? Das erscheint mir ein Widerspruch zu sein.
Meine zweite Frage wäre, wie hast Du die Abfrage entfernt?

Ich persönlich habe zur Lösung des Problems folgendes versucht:

Wie von Easybell empfohlen, habe ich die Registrierung nicht mittels Hostname, sondern IP-Adresse versucht:
Code:
0049xxxxxxxxxxxx:[email protected][2001:4090:4008::124]/0049xxxxxxxxx

Während dieses Vorgehen bei SIPGate anstandslos funktioniert, bekomme ich bei Easybell folgende Meldung:
Code:
 Forbidden - wrong password on authentication for REGISTER for '0049xxxxxxxxxx' to '[2001:4090:4008::124]'

Edit: Das ist allerdings irreführend. Wahrscheinlich sieht Asterisk nur ein 403 und interpretiert diesen Code selbständig als Passwort-Fehler. Wenn ich mir die von Easybell kommenden SIP-Pakete mittels Packetsniffer anschaue, lautet die darin im Klartext enthaltene Fehlermeldung nämlich "403 Domain not served here".

Meine nächste Idee war Asterisk das zu geben was es sehen will. Dazu habe ich im DNS-Server meines Routers einen entsprechenden statischen DNS-Eintrag vorgenommen, und den Registrierungsstring entsprechend geändert in:
Code:
0049xxxxxxxxxx:[email protected]/0049xxxxxxxxxx

Im Prinzip sollte das eigentlich funktionieren, denn "host" liefert das gewünschte Ergebnis:
Code:
host  2001:4090:4008::124
4.2.1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.8.0.0.4.0.9.0.4.1.0.0.2.ip6.arpa domain name pointer ipv6.sip.easybell.de.

Doch Asterisk gibt wieder die bekannte Fehlemeldung:
Code:
[2015-12-06 13:31:47] ERROR[797][C-0000000c]: netsock2.c:303 ast_sockaddr_resolve: getaddrinfo("2001:4090:4008::124", "(null)", ...): Address family for hostname not supported
[2015-12-06 13:31:47] WARNING[797][C-0000000c]: chan_sip.c:10955 process_sdp_c: Unable to lookup RTP Audio host in c= line, 'IN IP4 2001:4090:4008::124'
[2015-12-06 13:31:47] WARNING[797][C-0000000c]: chan_sip.c:10516 process_sdp: Insufficient information in SDP (c=)...

Eigentlich ist das ja obsolet, denn ich könnte im Registrationstring auch mit sip1.easybell.de als Registrar arbeiten, denn:
Code:
host sip1.easybell.de
sip1.easybell.de has address 212.172.97.118
sip1.easybell.de has IPv6 address 2001:4090:4008::124

und

host  2001:4090:4008::124
4.2.1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.8.0.0.4.0.9.0.4.1.0.0.2.ip6.arpa domain name pointer sip1.easybell.de.
Doch auch hier erfolgt die gleiche Fehlermeldung. Es liegt also meines Erachtens nicht an Easybell, und nicht an einem fehlenden reverse-DNS-Eintrag, sondern an einem grundsätzlichen Fehler in Asterisk in der Funktion netsock2. Aber es kann doch nicht sein, daß das niemand bemerkt hat.

Habe ich irgendwas übersehen?

Um eventuellen Fragen vorzubeugen, ja IPv6 via SIPGATE funktioniert einwandfrei. :)

Asterisk 13.2.0 ohne PJSIP
FreePBX 12.0.76.2
 
Zuletzt bearbeitet:

Artabanos

Neuer User
Mitglied seit
6 Dez 2015
Beiträge
22
Punkte für Reaktionen
0
Punkte
0
Ich habe noch ein wenig weiter an dem Problem geforscht. Dabei gelangte ich mittlerweile zu der Überzeugung, daß das Problem aufseiten von Easybell zu suchen ist.

Die Registrierung mittels

Code:
0049xxxxxxxxxx:[email protected]/0049xxxxxxxxxx
funktioniert einwandfrei. Der entsprechende Sip-Trace zeigt keinerlei Auffälligkeiten.

Bei einem eingehenden Anruf erscheint jedoch im Log die bekannte Fehlermeldung:
Code:
[2015-12-06 13:31:47] ERROR[797][C-0000000c]: netsock2.c:303 ast_sockaddr_resolve: getaddrinfo("2001:4090:4008::124", "(null)", ...): Address family for hostname not supported 
[2015-12-06 13:31:47] WARNING[797][C-0000000c]: chan_sip.c:10955 process_sdp_c: Unable to lookup RTP Audio host in c= line, 'IN IP4 2001:4090:4008::124' 
[2015-12-06 13:31:47] WARNING[797][C-0000000c]: chan_sip.c:10516 process_sdp: Insufficient information in SDP (c=)...

Der von Easybell bei einem eingehenden Anruf initiierte Handshake beginnt mit einer Invite-Message: (Telefonnummern und IP-Adressen anonymisiert.)
Code:
<--- SIP read from UDP:[2001:4090:4008::124]:5060 --->
INVITE sip:[email protected][2001:db8::]:5060 SIP/2.0
Max-Forwards: 25
Record-Route: <sip:[2001:4090:4008:0:0:0:0:124];r2=on;lr=on;ftag=582AAF89-566EC5B2000D7585-FF9F9700;ngcplb=yes;socket=sip:[2001:4090:4008:0:00:0:124]:5060>
Record-Route: <sip:127.0.0.1;r2=on;lr=on;ftag=582AAF89-566EC5B2000D7585-FF9F9700;ngcplb=yes;socket=sip:[2001:4090:4008:0:0:0:0:124]:5060>
Via: SIP/2.0/UDP [2001:4090:4008:0:0:0:0:124];branch=z9hG4bK5b08.f2535e9fe516ec0a84a04fb96f838e32.0
Via: SIP/2.0/UDP 127.0.0.1:5080;branch=z9hG4bK0FFaGa.g;rport=5080
From: <sip:[email protected]>;tag=582AAF89-566EC5B2000D7585-FF9F9700
To: <sip:[email protected]>
CSeq: 10 INVITE
Call-ID: [email protected]e_b2b-1
Supported: timer
Allow: INVITE,ACK,PRACK,SUBSCRIBE,BYE,CANCEL,NOTIFY,INFO,REFER,UPDATE
P-Asserted-Identity: <sip:[email protected]>
Content-Type: application/sdp
Content-Length: 245
Contact: <sip:[email protected][2001:4090:4008:0:0:0:0:124]:5060;ngcpct=c2lwOjEyNy4wLjAuMTo1MDgw>

v=0
[COLOR=#ff0000] [B]o=- 1225240426 8000 IN IP4 2001:4090:4008::124[/B][/COLOR]
s=-
[COLOR=#ff0000] [B]c=IN IP4 2001:4090:4008::124[/B][/COLOR]
t=0 0
m=audio 30854 RTP/AVP 8 101
a=rtpmap:8 PCMA/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16,32-36,54
a=sendrecv
a=ptime:20
a=rtcp:30855
<------------->

Bereits diese erste Message enthält doch bereits die rot hervorgehobenen unsinnigen Parameter in Form einer als IPv4 gekennzeichneten IPv6-Adresse, die so natürlich nicht aufgelöst werden kann.
Doch wenn das so ist, dann kann das doch bei anderen Nutzern auch nicht funktionieren. Nutzt denn keiner IPv6 bei Easybell?

[hier geht's weiter]
 
Zuletzt bearbeitet von einem Moderator:

Artabanos

Neuer User
Mitglied seit
6 Dez 2015
Beiträge
22
Punkte für Reaktionen
0
Punkte
0
Hier auch noch mal abschließend von meiner Seite, das Problem lag an Easybell und wurde am gestrigen Tage behoben.
 

Erhalten Sie 3CX für 1 Jahr kostenlos!

Gehostet, in Ihrer privaten Cloud oder on-Premise! Ganz ohne Haken. Geben Sie Ihren Namen und Ihre E-Mail an und los geht´s:

3CX
Für diese E-Mail-Adresse besteht bereits ein 3CX-Konto. Sie werden zum Kundenportal weitergeleitet, wo Sie sich anmelden oder Ihr Passwort zurücksetzen können, falls Sie dieses vergessen haben.
oder via