Anrufer erhalten kein Klingelton nur Stille und nichts passiert

[chsvat]

Habe folgedes Problem:

Im Prinzip läuft alles (Asterisk an Telekom all IP Anschluss), nur manchmal, wenn Leute uns anrufen wollen (oder ich es selbst mit dem Handy probiere) erhalten sie/ich kein Klingelton und auch im Asterisk log passiert nichts (habe verbose=9 gesetzt). Wenn ich es aber gleich danach nochmal probiere (mit meinem Handy) funktioniert es einwandfrei.
Was kann das sein?

Ich habe einen pfsense Router davor und TCP/UDP Ports 5060-5080 und 10000-20000 auf den Asterisk weitergeleitet.
In sip.conf habe ich "externhost" mit einer no-ip Adresse angegeben und "externrefresh" steht auf 10.


Außerdem bekomme ich manchmal noch wenn ich mich selbst mit dem Handy anrufen will

chan_sip.c:15069 handle_request_invite: Failed to authenticate user <sip:[email protected];user=phone>;tag=04f77dc2

Trotzdem klingelt es hier normal (aber manchmal auch nicht).

Danke im Voraus.

 

[abw1oim]

Der Fehler (Failed to authenticate user) sollte nicht auftreten, aber um Näheres sagen zu können, müsstest Du uns mal an Deiner sip.conf teilhaben lassen.

 

[chsvat]

Habe Asterisk Version 1.4.34 da diese per apt installiert wurde auf Debian 7

; Generelle Konfiguration
;
[general]
allowguest=no
;alwaysauthreject=yes
autocreatepeer=no
pedantic=no
context=default
bindport=5060
bindaddr=192.168.xyz.xyz
externhost=xyz.no-ip.biz
externrefresh=10
localnet=192.168.xyz.0/255.255.255.0
srvlookup=yes
;nat=yes
;nat=auto_force_rport,auto_comedia
disallow=all
allow=ulaw
allow=alaw
allow=gsm
language=de
defaultexpirey=280
maxexpirey=3600
allowoverlap=yes

;
; DTAG-IP -> Registrierung der Rufnummern
;
register => 0xxxxxxxx34:xxxxx:[email protected]/0xxxxxxxx34
register => 0xxxxxxxx35:xxxxx:[email protected]/0xxxxxxxx35
register => 0xxxxxxx9:xxxxx:[email protected]/0xxxxxxx9
;
;
[external-standard](!)
trustrpid=no
canreinvite=no
context=ankommend
type=peer
insecure=port,invite
usereqphone=no
t38pt_udptl=no
nat=yes
;nat=auto_force_rport,auto_comedia
disallow=all
allow = ulaw
allow = alaw
allow = gsm
dtmfmode=rfc2833

[DTAG-IP](external-standard)
[email protected]
[email protected]
username=xxxx
;fromuser="telefonnummer"
secret=xxxx
;remotesecret=xxxx
host=tel.t-online.de
fromdomain=tel.t-online.de
qualify=yes
call-limit=3

; Telekom Loadbalancer

[DTAG-IP_IN16_026](external-standard)
host=217.0.16.26
trustrpid=no
[DTAG-IP_IN16_035](external-standard)
host=217.0.16.35
trustrpid=no
[DTAG-IP_IN16_090](external-standard)
host=217.0.16.90
trustrpid=no
[DTAG-IP_IN16_102](external-standard)
host=217.0.16.102
trustrpid=no
[DTAG-IP_IN16_106](external-standard)
host=217.0.16.106
trustrpid=no
[DTAG-IP_IN16_154](external-standard)
host=217.0.16.154
trustrpid=no
[DTAG-IP_IN16_163](external-standard)
host=217.0.16.163
trustrpid=no
[DTAG-IP_IN16_166](external-standard)
host=217.0.16.166
trustrpid=no
[DTAG-IP_IN16_170](external-standard)
host=217.0.16.170
trustrpid=no
[DTAG-IP_IN16_230](external-standard)
host=217.0.16.230
trustrpid=no
[DTAG-IP_IN17_026](external-standard)
host=217.0.17.26
trustrpid=no
[DTAG-IP_IN17_035](external-standard)
host=217.0.17.35
trustrpid=no
[DTAG-IP_IN17_090](external-standard)
host=217.0.17.90
trustrpid=no
[DTAG-IP_IN17_102](external-standard)
host=217.0.17.102
trustrpid=no
[DTAG-IP_IN17_106](external-standard)
host=217.0.17.106
trustrpid=no
[DTAG-IP_IN17_154](external-standard)
host=217.0.17.154
trustrpid=no
[DTAG-IP_IN17_163](external-standard)
host=217.0.17.163
trustrpid=no
[DTAG-IP_IN17_166](external-standard)
host=217.0.17.166
trustrpid=no
[DTAG-IP_IN17_170](external-standard)
host=217.0.17.170
trustrpid=no
[DTAG-IP_IN17_230](external-standard)
host=217.0.17.230
trustrpid=no
[DTAG-IP_IN19_026](external-standard)
host=217.0.19.26
trustrpid=no
[DTAG-IP_IN19_035](external-standard)
host=217.0.19.35
trustrpid=no
[DTAG-IP_IN19_090](external-standard)
host=217.0.19.90
trustrpid=no
[DTAG-IP_IN19_102](external-standard)
host=217.0.19.102
trustrpid=no
[DTAG-IP_IN19_106](external-standard)
host=217.0.19.106
trustrpid=no
[DTAG-IP_IN19_154](external-standard)
host=217.0.19.154
trustrpid=no
[DTAG-IP_IN19_163](external-standard)
host=217.0.19.163
trustrpid=no
[DTAG-IP_IN19_166](external-standard)
host=217.0.19.166
trustrpid=no
[DTAG-IP_IN19_170](external-standard)
host=217.0.19.170
trustrpid=no
[DTAG-IP_IN19_230](external-standard)
host=217.0.19.230
trustrpid=no
[DTAG-IP_IN20_026](external-standard)
host=217.0.20.26
trustrpid=no
[DTAG-IP_IN20_035](external-standard)
host=217.0.20.35
trustrpid=no
[DTAG-IP_IN20_090](external-standard)
host=217.0.20.90
trustrpid=no
[DTAG-IP_IN20_102](external-standard)
host=217.0.20.102
trustrpid=no
[DTAG-IP_IN20_106](external-standard)
host=217.0.20.106
trustrpid=no
[DTAG-IP_IN20_154](external-standard)
host=217.0.20.154
trustrpid=no
[DTAG-IP_IN20_163](external-standard)
host=217.0.20.163
trustrpid=no
[DTAG-IP_IN20_166](external-standard)
host=217.0.20.166
trustrpid=no
[DTAG-IP_IN20_170](external-standard)
host=217.0.20.170
trustrpid=no
[DTAG-IP_IN20_230](external-standard)
host=217.0.20.230
trustrpid=no

; #########################################
;
; ENDGERÄTE:
;
blablabla

 

[abw1oim]

Das sieht eigentlich - für 1.4 - gut und ordentlich aus (einschließlich der korrekten Einstellungen für nat, insecure und secret).
Insoweit könntest Du nur versuchen, einen sip debug mitlaufen zu lassen (Achtung: Produziert viele Daten) und nach full zu schreiben (logger.conf anpassen).
Wenn dann Dein Szenario (Anruf kommt nicht durch) eintritt, kannst Du dann mal ins Log schauen, ich tippe, da kommt ein INVITE und das wird irgendwie abgewiesen.
Nach Deiner sonstigen Beschreibung sollte die Firewall nicht als Verursacher des Problems in Betracht kommen - nichts desto trotz kannst Du auch dort versuchen, zu loggen und zu schauen, ob im betrachteten Szenario Pakete ankommen und an die Asterisk weitergegeben werden.

 

[chsvat]

Hmm dann muss ich wohl weiter rumprobieren.
Was auch noch ein Problem ist... manchmal wenn ich raus telefonieren will kommt

chan_sip.c:13062 handle_response_invite: Received response: "Forbidden" from '"0xxxxxxx9" <sip:[email protected]>;tag=as5b3db0a5'

also ich komme nicht nach extern. Wenn ich dann ein "sip reload" mache gehts wieder, ohne das ich was umgestellt hätte.

Vorhin nachdem jemand versucht hat anzurufen (wo auf der Konsole auch wieder

Failed to authenticate user <sip:[email protected];user=phone>;tag=88a895ce

kam) bekam ich auch (zum ersten mal) ein

chan_sip.c:2014 retrans_pkt: Maximum retries exceeded on transmission [email protected] for seqno 554021 (Critical Response) -- See doc/sip-retransmit.txt

angezeigt

 

[abw1oim]

War das

62.155.1.66

zu diesem Zeitpunkt Deine IP ?

Das "Forbidden" ist bei abgehenden Rufen zur Telekom typischerweise eher ein Problem einer nicht korrekt gesetzten Calleridentifizierung (CALLERID)num) und CALLERID(name) müssen auf der Rufnummer incl. Vorwahl stehen) als denn ein IP-Problem.

Alles andere deutet immer darauf hin, dass ein IP-Wechsel nicht rechtzeitig bemerkt und mit einer Re-Registrierung verbunden wird. Schau doch mal, was Du als Registrierungsintervall bei der DTAG hast (ich nehme da 240 Sekunden, niedriger bekomme ich es nicht, bedeutet aber auch, dass ich bei IP-Wechsel maximal 4 Minuten + externrefresh (bei mir 60 Sekunden) nicht über die Telekom-Nummern erreichbar bin (es sei denn ich mache einen sip reload)).

Ich kann Dir jetzt nicht genau sagen, ob die Einstellung des Registrierungsintervalls mit 1.4 schon per Registrierung ging, aber das wäre wenn dann denn dann die Syntax:

register => 0xxxxxxxx34:xxxxx:[email protected]/0xxxxxxxx34~240

Ansonsten kannst Du da ggf. mit den General-Options (ich meine es wäre defaultexpiry) experimentieren, entscheidend ist, das Registrierungsintervall möglichst niedrig zu bekommen. Ach und noch etwas: Ich bin mir nicht sicher, ob die Telekom mit eienm Serverlookup richtig umgeht. Wenn Du sonst keinen Bedarf dafür hast, sag mal lieber

srvlookup=no

Der Authentifizierungsfehler macht mir noch Sorgen, da kann aber tatsächlich ein sip debug weiterhelfen, damit man mal sieht, welches SIP-Paket zu dem Fehler führt.

Zum Testen empfiehlt es sich hier ggf auch,

allowguest=yes

zu setzen, dann allerdings im default-Kontext unbedingt dafür sorgen, dass außer einem NoOp mit den Anrufdaten auf keinen Fall Rufe nach außen initiiert werden können!

 

[chsvat]

In meinem default context habe ich das:
Wäre damit allowguest ok?

[default]   ; Default Context

;exten => _X.,1,Hangup

; Wer hier landet ist entweder schlecht konfiguriert oder hat keine "Rechte"

exten => _X.,1,Answer ()
exten => _X.,2,Verbose(D E F A U L T ==> ${CALLERID(num)} kam um ${STRFTIME(${EPOCH},,%Y%m%d-%H%M%S)} in DEFAULT an als er versuchte die Nummer ${EXTEN} anzurufen.)
exten => _X.,3,Playback(/var/lib/asterisk/sounds/pbx-invalid.gsm)
exten => _X.,4,Hangup

Die Caller ID lasse ich so setzen:

exten => _0X.,1,Set(CALLERID(num)=0xxxxxxx9)
exten => _0X.,2,Set(CALLERID(name)=)
exten => _0X.,3,Dial(SIP/${EXTEN:1}@DTAG-IP,120)
exten => _0X.,4,Hangup()

 

[abw1oim]

Der default passt, da kann nichts passieren.
Die CALLERID wird auch richtig gesetzt und wenn Du tatsächlich mit "Amtsnull" wählst, ist auch das Dialkommandi mit ${EXTEN:1} völlig ok.
Wie gesagt, ich würde mal Gäste zulassen und einen debug mitlaufen lassen.
Das Problem muss ja erklärbar und letztlich auch lösbar sein ...

 

[chsvat]

Ok...habe jetzt noch nichts verändert und nur mal das debug angeschaltet mit "sip set debug" (hoffe das ist richtig, denke aber schon).
Vorhin funktionierte das Anrufen vom Handy aus zu uns auf den Anschluss wunderbar, doch jetzt eben gerade hatte ich nochmal debug angeschaltet und getestet und siehe da: Wieder nur Stille bei mir als Anrufer ... und das Beste ... beim debug taucht nichts auf :?
ALLERDINGS funktionieren die anderen 2 der 3 Rufnummern die wir haben wunderbar. Ich blicks nicht.

edit: gerade das debug noch weiter angeguckt und weiter mit dem Handy probiert auf der einen Nummer anzurufen... nachdem

chan_sip.c:13351 handle_response_register: Outbound Registration: Expiry for tel.t-online.de is 260 sec (Scheduling reregistration in 245 s)

kam, funktionierte die Nummer wieder.
Einen Tip woran das dann liegen könnte?

 

[abw1oim]

Ich tippe auf den srvlookup. Setz' den mal auf no.

Wenn Du im debug nichts hast, kommen auch keine Pakete und das wiederum bedeutet, dass Dich der Server der Telekom, bei dem Du registriert bist, nicht wiederfindet. Wenn er aber die anderen beiden Nummern findet, deutet das darauf hin, dass in der internen Konfiguration des Asterisk etwas strubbelig wird. Und dafür könnte das srvlookup zuständig sein.
Außerdem solltest Du auch noch sicherstellen, dass der dnsmgr aus ist (dnsmgr.conf)

 

[chsvat]

srvlookup auf no gesetzt, neu gestartet und nun ist das Problem bei 'ner anderen Nummer :dance:

Kanns vlt. doch an der Firewall liegen?
Ich habe die Weiterleitungen als Rules angelegt, so wie in diesem Video http://www.youtube.com/watch?v=X4lJZ5ntFO4

allowguest habe ich momentan noch auf no

 

[chsvat]

Hatte jetzt vor 2 Tagen nochmal Router und Modem neu gestartet und alles neu verbinden lassen - Die option "srvlookup" ist nun auf "no" gesetzt, "allowguest" habe ich noch auf "no".
Nun scheint alles zu funktionieren, denn die letzten zwei Tage musste ich nichts mehr neu starten
Hoffe das wars.
Danke für deine Hilfe !!!

 

[xrated]

srvlookup betrifft nur ausgehende Gespräche.
Bei Debian7 müsste die Asterisk Version nicht 1.4 sondern 1.8 sein. 1.4 ist uralt und sollte nicht mehr verwendet werden.

Ich würde vermuten, dass es Probleme mit der Registrierung gibt/gab. Das lässt sich auch überwachen oder man gibt sip show registry ein wenn es Probleme gibt.

Und nimm diese 2 Zeilen raus
defaultexpirey=280
maxexpirey=3600

defaultexpiry= Number : Default duration (in seconds) of incoming/outgoing registration. Default 120 seconds.
maxexpiry = Number : Max duration (in seconds) of incoming registration we allow. Default 3600 seconds.

Wir wollen dem Provider nicht vorschreiben wann die Registrierung abläuft, dadurch kann es eben Probleme geben.

Das kann ebenso alles weg:
autocreatepeer=no
pedantic=no
bindaddr=192.168.xyz.xyz