[Problem] Asterisk stürzt ab...

[ca.funke]

Hallo allerseits,

ich habe einen Asterisk-Server aus Kostengründen zu einem neuen Provider umgezogen. Bei der Gelegenheit bin ich von 1.4.3 auf 1.8.10 umgestiegen.

Der Server ist nur für den privaten Gebrauch. Ausgehend soll es ab dem Heimtelefon Anrufe ermöglichen. Das funktioniert durchgängig.

Ferner soll eine deutsche und eine schweizerische Nummer parallel bei mir zu Hause und auf dem Handy klingeln. Das funktioniert nur noch teilweise.

Auf dem alten Server lief das ganze sehr stabil und zuverlässig. Auf dem neuen Server funktionieren ankommende Anrufe für 20-60 Minuten ab Neustart zuverlässig, dann klappt´s nicht mehr.

Sobald es nicht mehr geht, und es kommt ein Anruf rein, erscheint auf der Konsole:

NOTICE[12446]: chan_sip.c:22622 handle_request_invite: Call from '' (12.34.567.890:5060) to extension 'ext1' rejected because extension not found in context 'default'.

Ob sip.conf und extensions.conf zur Lösung helfen, weiss ich nicht - füge sie trotzdem an. Was auch immer sonst benötigt werden könnte stelle ich gerne zur Verfügung.

Wäre für jede Hilfe dankbar!

sip.conf

[general]
context=default
bindport=5060
bindaddr=my.ip.add.ress
srvlookup=yes

;#########################################################################################
;######################## register => username:[email protected]/??? ###################
;#########################################################################################

register => abc:[email protected]/49123456789 ;Sipgate DE
register => ghi:[email protected]/41123456789 ;netvoip CH



;#########################################################################################
;######################## INCOMING SIP-configurations ####################################
;#########################################################################################

; ##### DE SIPGATE IN (0049123456789)
[DE_in]
type=peer
fromdomain=sipgate.de
host=sipgate.de
canreinvite=no
disallow=all
allow=alaw
context=ankommend-de


; ##### CH NETVOIP IN (0041-123456789)
[CH_in]
type=peer
fromdomain=sip.netvoip.ch
host=sip.netvoip.ch
canreinvite=no
disallow=all
allow=alaw
context=ankommend-ch



;#########################################################################################
;######################## OUTGOING SIP-configurations ####################################
;#########################################################################################


; ##### Finera forward (no number, destination determined in webinterface www.intervoip.com)
[finera_forward]
type=peer
host=sip.voipbuster.com
insecure=very
nat=no
canreinvite=no
disallow=all
allow=alaw

; ##### SIPGATE DE  OUT (0049-123456789)
[de_out_sipgate]
type=peer
username=abc
fromuser=abc
secret=def
host=sipgate.de
fromdomain=sipgate.de
insecure=port
canreinvite=no
nat=no
disallow=all
allow=alaw


;##### NETVOIP CH OUT (0041-123456789)
[ch_out_netvoip]
type=peer
username=ghi
fromuser=ghi
secret=jkl
host=sip.netvoip.ch
fromdomain=sip.netvoip.ch
insecure=very
canreinvite=no
nat=no
disallow=all
allow=alaw


;#########################################################################################
; Sip-Endgeräte (hier kommen die Anmeldekontexte für die SIP Endgeraete 30-39)
;#########################################################################################
;
[30]
callerid=Phone 1 <30>
host=dynamic
user=30
secret=passwort
type=friend
mailbox=30
nat=yes
canreinvite=no

[31]
callerid=Phone 2 <31>
host=dynamic
user=31
secret=passwort
type=friend
mailbox=31
nat=yes
canreinvite=no

extensions.conf

;#########################################################################################
;######################## GENERAL ########################################################
;#########################################################################################

[general]
static=yes
writeprotect=no

;#########################################################################################
;######################## OUTGOING dialplan ##############################################
;#########################################################################################


; ########## SCHWEIZ outgoing ##########
exten => _00418.,1,Dial(SIP/ch_out_netvoip/${EXTEN}) ; CH-sondernummern über netvoip
exten => _00417.,1,Dial(SIP/voipgain/${EXTEN}) ; CH-mobile über voipgain
exten => _0041.,1,Dial/SIP/voipgain/${EXTEN}) ; CH-Festnetz über voipgain

; ########## GERMANY outgoing ##########
exten => _0049800.,1,Dial(SIP/de_out_sipgate/${EXTEN}) ; D-0800 über sipgate
exten => _00491.,1,Dial(SIP/voipgain/${EXTEN}) ; D-mobile über voipgain
exten => _0049.,1,Dial(SIP/voipgain/${EXTEN}) ; D-Festnetz über voipgain


; ########## ALL OTHER outgoing ##########
exten => _00.,1,Dial(SIP/voipgain/${EXTEN}) ; alles über voipgain



;#########################################################################################
;######################## INCOMING dialplan ##############################################
;#########################################################################################


[ankommend-de]
exten => _X.,1,GotoIf($["${CALLERID(num):0:2}"="00"]?prefixok:fixprefix)
exten => _X.,n(prefixok),Dial(SIP/finera_forward/finera.username&SIP/30)
exten => _X.,n,Hangup()
exten => _X.,n(fixprefix),Set(CALLERID(num)=0049${CALLERID(num):1})
exten => _X.,n,Dial(SIP/finera_forward/finera.username&SIP/30)
exten => _X.,n,Hangup()


[ankommend-ch]
exten => _X.,1,GotoIf($["${CALLERID(num):0:2}"="00"]?prefixok:fixprefix)
exten => _X.,n(prefixok),Dial(SIP/finera_forward/finera.username&SIP/30)
exten => _X.,n,Hangup()
exten => _X.,n(fixprefix),Set(CALLERID(num)=0049${CALLERID(num):1})
exten => _X.,n,Dial(SIP/finera_forward/finera.username&SIP/30)
exten => _X.,n,Hangup()


;#########################################################################################
;######################## GENERAL ########################################################
;#########################################################################################

[default]
include => lokal
include => sipgate_out

 

[abw1oim]

Das ist relativ einfach:
Mit dem Versionshub hat sich die Reihenfolge der Interpretation der Kontexte in der sip.conf geändert. Ergebnis: Deine eingehenden Calls landen in default und werden rejected, da es dort kein passendes pattern gibt.

Lösung:

Die sip.conf-Kontexte

; ##### SIPGATE DE  OUT (0049-123456789)
[de_out_sipgate]
type=peer
username=abc
fromuser=abc
secret=def
host=sipgate.de
fromdomain=sipgate.de
insecure=port
canreinvite=no
nat=no
disallow=all
allow=alaw


;##### NETVOIP CH OUT (0041-123456789)
[ch_out_netvoip]
type=peer
username=ghi
fromuser=ghi
secret=jkl
host=sip.netvoip.ch
fromdomain=sip.netvoip.ch
insecure=very
canreinvite=no
nat=no
disallow=all
allow=alaw

entsorgen, respektive relevante Teile davon in

[DE_in]
type=peer
fromdomain=sipgate.de
host=sipgate.de
canreinvite=no
disallow=all
allow=alaw
context=ankommend-de


; ##### CH NETVOIP IN (0041-123456789)
[CH_in]
type=peer
fromdomain=sip.netvoip.ch
host=sip.netvoip.ch
canreinvite=no
disallow=all
allow=alaw
context=ankommend-ch

integrieren, etwa so:

[DE_sipgate]
type=peer
[B]defaultuser[/B]=abc
fromuser=abc
secret=def
fromdomain=sipgate.de
host=sipgate.de
[B]directmedia[/B]=no
nat=no
insecure=port
disallow=all
allow=alaw
context=ankommend-de


; ##### CH NETVOIP IN (0041-123456789)
[CH_netvoip]
type=peer
[B]defaultuser[/B]=ghi
fromuser=ghi
secret=jkl
fromdomain=sip.netvoip.ch
host=sip.netvoip.ch
[B]directmedia[/B]=no
nat=no
insecure=port,invite
disallow=all
allow=alaw
context=ankommend-ch

(Hinweis: Fette Markierungen sind zusätzlich durch den Versionshub bedingte Syntaxänderungen in der Konfig)

und die extenions.conf in den Dial-Statements anpassen:

...
exten => _00418.,1,Dial(SIP/CH_netvoip/${EXTEN}) ; CH-sondernummern über netvoip
...
exten => _0049800.,1,Dial(SIP/DE_sipgate/${EXTEN}) ; D-0800 über sipgate
...

Dann sollte das alles wieder wie gewünscht/gewohnt funktionieren.

 

[ca.funke]

Das ist relativ einfach:
Mit dem Versionshub hat sich die Reihenfolge der Interpretation der Kontexte in der sip.conf geändert. Ergebnis: Deine eingehenden Calls landen in default und werden rejected, da es dort kein passendes pattern gibt.

Hallo Olaf (abw1oim),

vielen Dank für Deine Mühe/Antwort! Werde es entsprechend Deiner Anweisungen anpassen.

Was ich nicht verstehe: Dein Hinweis hört sich so an, als wenn das Problem immer bestehen müsste. Nach Neustart des Asterisk funktioniert es jedoch erstmal, und dann "plötzlich" nicht mehr.

Zusätzliche Frage: Ich hatte meinen Asterisk nach Betateilchens Anleitung zusammengebaut, ohne viel zu verstehen. Beta sagte, dass die Konfigurationen eingehend/ausgehend besser getrennt werden sollten. Also ist das nach Versionshub nicht mehr der Fall?

Dank und Gruss in die Heimat, bin ursprünglich Bonner
Christian

 

[abw1oim]

Die Frage, warum es manchmal nicht funktioniert, erschließt sich mir leider auch nicht, dieses Verhalten steht sogar im Widerspruch zur Dokumentation . Es müssste nämlich IMHO der erste passende Kontext genommen werden, und das ist ja hier der jeweilige _in-Kontext im Original.

Die ursprüngliche Anleitung von Betateilchen ist auch (IMHO bis Asterisk 1.6.0) so verwendbar und man kann trefflich darüber streiten, ob man ein- und ausgehenden Verkehr in der Konfiguration nun trennt oder nicht ...
Die Trennung ist auch ab 1.6.1 noch möglich, scheint aber mindestens bei Dir nicht sauber zu funktionieren. Allein schon wegen des geringeren Konfigurationsaufwandes habe ich mir allerdings auch angewöhnt, immer nur eine peer-Definition für in- und Outbound pro Provider-Host zu haben.

 

[ca.funke]

...Es müssste nämlich IMHO der erste passende Kontext genommen werden...

Hoffe die Frage ist nicht zu Basic: Wie wird denn bestimmt, welcher Kontext passt/genommen wird?

 

[abw1oim]

Auf Basis des Mappings IP-Adresse <-> host=-Angabe

 

[ca.funke]

Darf ich mir das so vorstellen:

Der Register aus der sip.conf sagt dem sip-Provider "wenn ein Anruf kommt, bitte an mich (IP-Addresse)". Der sip-provider merkt sich dann die IP der Anfrage, und wenn ein Anruf kommt, wird er an die "gemerkte" IP, also den Asterisk, mit einem gewissen Header, weitergeleitet.

Im Header steht irgendwo "von:sipgate.de"

Dies wird dann mit den Einträgen in der sip.conf verglichen. Der erste Eintrag in dem "fromdomain=sipgate.de" vorkommt wird dann genommen, und an den entsprechenden Context weitergeleitet...

Stimmt das zumindest von der Logik, oder totaler Holzweg?

 

[abw1oim]

Nicht ganz:

Der Match erfolgt IP-basiert, d.h. das eingehende SIP-Paket (sipgate schickt es tatsächlich an die IP, wie von Dir vermutet), wird bezüglich seiner IP-Adresse betrachtet. Der Eintrag host=xxx in der sip.conf wird Asterisk-intern auf eine IP-Adresse umgesetzt (DNS-Auflösung).
Das Paket wird jetzt in den Kontext "abgeworfen" für den gilt: Sende-IP-Adresse = erwartete IP-Adresse (aus host=xxx-Zeile).
So jedenfalls der Standard.
Das ist auch der Grund, warum es bei Anbietern mit (nach außen nicht gekapselten) Load-Balancern, wie 1und1, dus.net, gmx, Telekom immer wieder lustig wird, peers für alle IPs zu konfigurieren, von denen Calls kommen können, damit diese eben nicht in Default landen ...

 

[ca.funke]

Wie ist die Interpretationsreihenfolge? Wenn es von Anfang zum Ende geht, sollte es in der ursprünglichen sip.conf doch im ersten Kontext landen (context=ankommend-de), und somit nicht im default...?

Wenn Sipgate die IP 217.10.72.53 hat, könnte man in der sip.conf statt fromdomain=sipgate.de auch fromdomain=217.10.72.53 schreiben?
(Reine Verständnisfrage. Das es nicht so gut wär´, z.B. falls sich die IP ändert, ist schon klar)

Wenn man es dann mit Load-Balancern zu tun hat wo die IPs variabel sind, muss man pro möglicher IP einen Kontext anlegen, oder kann man das irgendwie per Range abdecken? (Kann mir ja aktuell zum Glück aktuell egal sein...)

 

[rentier-s]

Das Paket wird jetzt in den Kontext "abgeworfen" für den gilt: Sende-IP-Adresse = erwartete IP-Adresse

... und die Authentifizierung passt, was hier vielleicht ein Problem sein mag, weil insecure statt in den ankommenden in den abgehenden Peers gesetzt ist.

Außerdem sieht das so aus, als würde der TSP den Contact irgendwann nicht mehr richtig mitgeben ('ext1 rejected...').

20-60 Minuten hört sich verdächtig nach einem expiry an, aber mir erschließt sich nicht, was da ablaufen kann das dieses Verhalten verursacht :noidea:

Btw, beschäftige Dich bitte mit dem Thread zum Thema Hacker und Asterisk, das include => sipgate_out im [default] ist nicht gut.

 

[ca.funke]

...das include => sipgate_out im [default] ist nicht gut...

Hallo rentier-s,

danke für die Hinweise. Das include => sipgate_out brauche ich eigentlich gar nicht, weil über default nichts abgewickelt wird. Hab´s jetzt einfach gelöscht, und alles klappt immer noch.

Die Hackerhinweise bearbeite ich später mal. Habe da schon EUR 50 Lehrgeld gezahlt und ein paar Tricks eingebaut. Aber eine grundsätzlich korrekte Sicherung wäre vermutlich besser.

Außerdem sieht das so aus, als würde der TSP den Contact irgendwann nicht mehr richtig mitgeben ('ext1 rejected...')...

Ich habe das verändert, damit meine Rufnummer da nicht steht. die eigentliche Fehlermeldung lautet:

NOTICE[12446]: chan_sip.c:22622 handle_request_invite: Call from '' (12.34.567.890:5060) to extension '022812345678' rejected because extension not found in context 'default'.

Das zu ändern war vermutlich nicht so raffiniert.

Dank und Gruss,
Christian

 

[abw1oim]

@rentier-s:
Die Authentifizierungslogik stimmt natürlich, das könnte - neben der expiry-Vermutung hier noch ein Problem sein.

@ca.funke:
In der sip.conf gehen bei der peer-Definition leider weder IP-Ranges, noch verschiedene IP-Adressen zu einem Peer, jeder Peer muss genau eine IP haben.

Ansonsten: fromdomain=sipgate.de ist etwas anderes als host=sipgate.de! fromdomain ist für den Outbound-Verkehr und hier insbesondere für den From-Header des abgehenden SIP-Paketes relevant und da kann man nicht durch IP ersetzen! Ich bezog mich hier ausschließlich auf host=sipgate-de, da kann man so man will tatsächlich statt des Domainnamens eine IP (aber eben nur eine) angeben, das potentielle Problem dabei hast Du bereits selbst erwähnt.