[Gelöst] Keine eingehenden Anrufe mit Asterisk

Sidebar Sidebar
Upgrade 3CX to v18 and get it hosted free!
M

Mileena

Neuer User
Mitglied seit
8 Jan 2017
Beiträge
2
Punkte für Reaktionen
0
Punkte
0
Hallo,

bin ziemliche Anfängerin was VoIP und Asterisk angeht, habe aber ein Problem damit. Ich hatte Asterisk installiert, konfiguriert und getestet, lief alles ohne Probleme. Dann habe ich den Asterisk Server heruntergefahren und wieder gestartet, danach gingen eingehende Anrufe nicht mehr, die Meldung die der Anrufer bekommt ist "Diese Nummer ist uns nicht bekannt".

Asterisk 13.13.1 Debian 8 Die drei Rufnummern (xxxxxyyy622 und xxxxxxyyy623 xxxxxyyyy624) sind meine eigenen. Asterisk befindet sich hinter einer Firewall. Telekom VoIP Anschluss.

Wenn jetzt einer anruft, erscheint folgendes in der Asterisk CLI

Code: 
[Jan  7 15:56:36] NOTICE[992][C-00000000] chan_sip.c: Call from '[email protected]' (217.0.23.105:5060) to extension 'XXXXXXYYY623' rejected because extension not found in context 'incoming-22'.

Meine sip.conf

Code: 
[general]
port=5060
externip=xxxxxx.ddns.net
;localnet=xxx.xxx.1.0/255.255.255.224
allowsubscribe=no
allowguest=no

register => xxxxxxxxxx622:xxxxxxxxx:[email protected]@tel.t-online.de/xxxxxxxxxx622~480
register => xxxxxxxxxx623:xxxxxxxxx:[email protected]@tel.t-online.de/xxxxxxxxxx623~480
register => xxxxxxxxxx624:xxxxxxxxx:[email protected]@tel.t-online.de/xxxxxxxxxx624~480

[t-online-22]
[email protected]
fromuser=xxxxxxxxxx622
secret=xxxxxxxxx
context=incoming-22
;extension=xxxxxxxxxx622
type=peer
host=tel.t-online.de
fromdomain=tel.t-online.de
realm=tel.t-online.de
nat=force_rport,comedia
directmedia=no
insecure=port,invite
canreinvite=yes
dtmfmode=inband
qualify=yes
session-timers=refuse
allow=!all,alaw,g722

[t-online-23]
[email protected]
fromuser=xxxxxxxxxx623
secret=xxxxxxxxx
context=incoming-23
;extension=xxxxxxxxxx623
type=peer
host=tel.t-online.de
fromdomain=tel.t-online.de
realm=tel.t-online.de
;nat=yes
nat=force_rport,comedia
directmedia=no
insecure=port,invite
canreinvite=yes
dtmfmode=inband
qualify=yes
session-timers=refuse
allow=!all,alaw,g722

[t-online-24]
[email protected]
fromuser=xxxxxxxxxx624
secret=xxxxxxxxx
context=incoming-24
;extension=xxxxxxxxxx624
type=peer
host=tel.t-online.de
fromdomain=tel.t-online.de
realm=tel.t-online.de
nat=force_rport,comedia
directmedia=no
insecure=port,invite
canreinvite=yes
dtmfmode=inband
qualify=yes
session-timers=refuse
allow=!all,alaw,g722

[xxxxx622]
type=friend
secret=test
host=dynamic
context=trunk-dtag-22

[xxxxx623]
type=friend
secret=test
host=dynamic
context=trunk-dtag-23

[xxxxx624]
type=friend
secret=test
host=dynamic
context=trunk-dtag-24

Meine extensions.conf

Code: 
[incoming-22]
exten => XXXXXYYYY622,1,Verbose(Incoming call via DTAG)
 same => n,Dial(SIP/YYYY624)
 same => n,Hangup

[incoming-23]
exten => XXXXXYYYY623,1,Verbose(Incoming call via DTAG)
 same => n,Dial(SIP/YYYY623)
 same => n,Hangup

[incoming-24]
exten => XXXXXYYYY624,1,Verbose(Incoming call via DTAG)
 same => n,Dial(SIP/YYYY624)
 same => n,Hangup

[trunk-dtag-22]
exten => _X.,1,Verbose(Outgoing call via DTAG)
 same => n,Set(CALLERID(all)=XXXXXYYYY622)
 same => n,Dial(SIP/t-online-22/${EXTEN},180,rg)
 same => n,Hangup

[trunk-dtag-23]
exten => _X.,1,Verbose(outgoing call via DTAG)
 same => n,Set(CALLERID(all)=XXXXXYYYY623)
 same => n,Dial(SIP/t-online-23/${EXTEN},180,rg)
 same => n,Hangup

[trunk-dtag-24]
exten => _X.,1,Verbose(Outgoing call via DTAG)
 same => n,Set(CALLERID(all)=XXXXXYYYY624)
 same => n,Dial(SIP/t-online-24/${EXTEN},180,rg)
 same => n,Hangup

Wie gesagt bis zum neustart ging alles, vielleicht hat ja jemand eine Idee.

Grüße
Mileena
 
Zuletzt bearbeitet:
Call from '[email protected]' (x.x.x.x:5060) to extension 'XXXXXXYYY623' rejected because extension not found in context 'incoming-22'
Zum Vergrößern anklicken....

Irgend etwas verwechselt die Nummern.

Ein [incoming] für alle ankommenden Anrufe anstatt [incoming-22], [incoming-23], ... könnte das Problem umgehen.
 
Danke Tippfehler für den Hinweis, habe es jetzt abgeändert.

Code: 
[incoming]
exten => xxxxxxxxx622,1,Answer
exten => xxxxxxxxx622,n,Dial(SIP/xxxx622)
exten => xxxxxxxxx622,n,Hangup

exten => xxxxxxxxx623,1,Answer
exten => xxxxxxxxx623,n,Dial(SIP/xxxx623)
exten => xxxxxxxxx623,n,Hangup

exten => xxxxxxxxx624,1,Answer
exten => xxxxxxxxx624,n,Dial(SIP/xxxx624)
exten => xxxxxxxxx624,n,Hangup

Jetzt funktionieren alle Telefone wieder, nur ein Problem ist geblieben, ich habe noch ein Analog-Fax, das tut eingehend sowie ausgehend nicht.

Die Ausgabe von sip set debug peer xxxx623 bringt folgendes:

Code: 
INVITE sip:[email protected];uniq=A9FCD78374E4925B3559B343FF55F SIP/2.0
Via: SIP/2.0/UDP xxx.xxx.1.3:5060;branch=z9hG4bK5b42de01
Max-Forwards: 70
From: "Anonymous" <sip:[email protected]>;tag=as62899686
To: <sip:[email protected];uniq=A9FCD78374E4925B3559B343FF55F>;tag=4D7B948EBE63EAC3
Contact: <sip:[email protected]:5060>
Call-ID: [email protected]:5060
CSeq: 103 INVITE
User-Agent: Asterisk PBX 13.13.1
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH, MESSAGE
Supported: replaces, timer
X-asterisk-Info: SIP re-invite (External RTP bridge)
Content-Type: application/sdp
Content-Length: 280

v=0
o=root 1996776513 1996776514 IN IP4 217.0.4.68
s=Asterisk PBX 13.13.1
c=IN IP4 217.0.4.68
t=0 0
m=audio 31956 RTP/AVP 8 0 3 99
a=rtpmap:8 PCMA/8000
a=rtpmap:0 PCMU/8000
a=rtpmap:3 GSM/8000
a=rtpmap:99 telephone-event/8000
a=fmtp:99 0-16
a=maxptime:150
a=sendrecv

---
[Jan  8 13:36:54] VERBOSE[1439][C-00000008] bridge_native_rtp.c: Remotely bridged 'SIP/t-online-22-00000010' and 'SIP/xxxx623-00000011' - media will flow directly between them
[Jan  8 13:36:54] VERBOSE[1439][C-00000008] bridge_native_rtp.c: Remotely bridged 'SIP/t-online-22-00000010' and 'SIP/xxxx623-00000011' - media will flow directly between them
[Jan  8 13:36:54] VERBOSE[1347] chan_sip.c: 
<--- SIP read from UDP:xxx.xxx.1.6:5060 --->
SIP/2.0 200 OK
Via: SIP/2.0/UDP xxx.xxx.1.3:5060;branch=z9hG4bK5b42de01;received=xxx.xxx.1.3
From: "Anonymous" <sip:[email protected]>;tag=as62899686
To: <sip:[email protected];uniq=A9FCD78374E4925B3559B343FF55F>;tag=4D7B948EBE63EAC3
Call-ID: [email protected]:5060
CSeq: 103 INVITE
Contact: <sip:[email protected];uniq=A9FCD78374E4925B3559B343FF55F>
User-Agent: AVM FRITZ!Box Fon 5050 12.04.31 (Feb 5 2007)
Supported: 100rel,replaces,timer
Allow-Events: telephone-event,refer
Allow: INVITE,ACK,OPTIONS,CANCEL,BYE,UPDATE,PRACK,INFO,SUBSCRIBE,NOTIFY,REFER,MESSAGE
Content-Type: application/sdp
Accept: application/sdp, multipart/mixed
Accept-Encoding: identity
Content-Length: 248

v=0
o=user 2207711 2207712 IN IP4 xxx.xxx.1.6
s=Asterisk PBX 13.13.1
c=IN IP4 xxx.xxx.1.6
t=0 0
m=audio 7082 RTP/AVP 8 0 99
a=rtpmap:8 PCMA/8000
a=rtpmap:0 PCMU/8000
a=rtpmap:99 telephone-event/8000
a=fmtp:101 0-11
a=sendrecv
a=rtcp:7083
<------------->
[Jan  8 13:36:54] VERBOSE[1347] chan_sip.c: --- (15 headers 12 lines) ---
[Jan  8 13:36:54] VERBOSE[1347][C-00000008] chan_sip.c: Found RTP audio format 8
[Jan  8 13:36:54] VERBOSE[1347][C-00000008] chan_sip.c: Found RTP audio format 0
[Jan  8 13:36:54] VERBOSE[1347][C-00000008] chan_sip.c: Found RTP audio format 99
[Jan  8 13:36:54] VERBOSE[1347][C-00000008] chan_sip.c: Found audio description format PCMA for ID 8
[Jan  8 13:36:54] VERBOSE[1347][C-00000008] chan_sip.c: Found audio description format PCMU for ID 0
[Jan  8 13:36:54] VERBOSE[1347][C-00000008] chan_sip.c: Found audio description format telephone-event for ID 99
[Jan  8 13:36:54] VERBOSE[1347][C-00000008] chan_sip.c: Capabilities: us - (ulaw|alaw|gsm|h263), peer - audio=(ulaw|alaw)/video=(nothing)/text=(nothing), combined - (ulaw|alaw)
[Jan  8 13:36:54] VERBOSE[1347][C-00000008] chan_sip.c: Non-codec capabilities (dtmf): us - 0x1 (telephone-event|), peer - 0x1 (telephone-event|), combined - 0x1 (telephone-event|)
[Jan  8 13:36:54] VERBOSE[1347][C-00000008] chan_sip.c: Peer audio RTP is at port xxx.xxx.1.6:7082
[Jan  8 13:36:54] VERBOSE[1347][C-00000008] chan_sip.c: set_destination: Parsing <sip:[email protected];uniq=A9FCD78374E4925B3559B343FF55F> for address/port to send to
[Jan  8 13:36:54] VERBOSE[1347][C-00000008] chan_sip.c: set_destination: set destination to xxx.xxx.1.6:5060
[Jan  8 13:36:54] VERBOSE[1347][C-00000008] chan_sip.c: Transmitting (no NAT) to xxx.xxx.1.6:5060:
ACK sip:[email protected];uniq=A9FCD78374E4925B3559B343FF55F SIP/2.0
Via: SIP/2.0/UDP xxx.xxx.1.3:5060;branch=z9hG4bK66c6e788
Max-Forwards: 70
From: "Anonymous" <sip:[email protected]>;tag=as62899686
To: <sip:[email protected];uniq=A9FCD78374E4925B3559B343FF55F>;tag=4D7B948EBE63EAC3
Contact: <sip:[email protected]:5060>
Call-ID: [email protected]:5060
CSeq: 103 ACK
User-Agent: Asterisk PBX 13.13.1
Content-Length: 0


---
[Jan  8 13:37:44] VERBOSE[1347] chan_sip.c: 
<--- SIP read from UDP:xxx.xxx.1.6:5060 --->
BYE sip:[email protected]:5060 SIP/2.0
Via: SIP/2.0/UDP xxx.xxx.1.6:5060;branch=z9hG4bK9F460A81A0115812
From: <sip:[email protected];uniq=A9FCD78374E4925B3559B343FF55F>;tag=4D7B948EBE63EAC3
To: "Anonymous" <sip:[email protected]>;tag=as62899686
Call-ID: [email protected]:5060
CSeq: 103 BYE
X-RTP-Stat: PS=1660;OS=398400;SP=0/0;SO=0;PR=0;OR=0;CR=0;SR=0;PL=0;BL=0;EN=PCMA;DE=;JI=0
Reason: Q.850; cause=16
Max-Forwards: 70
User-Agent: AVM FRITZ!Box Fon 5050 12.04.31 (Feb 5 2007)
Supported: 100rel,replaces,timer
Allow-Events: telephone-event,refer
Content-Length: 0

<------------->
[Jan  8 13:37:44] VERBOSE[1347] chan_sip.c: --- (13 headers 0 lines) ---
[Jan  8 13:37:44] VERBOSE[1347][C-00000008] chan_sip.c: Sending to xxx.xxx.1.6:5060 (no NAT)
[Jan  8 13:37:44] VERBOSE[1347][C-00000008] chan_sip.c: Scheduling destruction of SIP dialog '[email protected]:5060' in 32000 ms (Method: BYE)
[Jan  8 13:37:44] VERBOSE[1347][C-00000008] chan_sip.c: 
<--- Transmitting (no NAT) to xxx.xxx.1.6:5060 --->
SIP/2.0 200 OK
Via: SIP/2.0/UDP xxx.xxx.1.6:5060;branch=z9hG4bK9F460A81A0115812;received=xxx.xxx.1.6
From: <sip:[email protected];uniq=A9FCD78374E4925B3559B343FF55F>;tag=4D7B948EBE63EAC3
To: "Anonymous" <sip:[email protected]>;tag=as62899686
Call-ID: [email protected]:5060
CSeq: 103 BYE
Server: Asterisk PBX 13.13.1
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH, MESSAGE
Supported: replaces, timer
Content-Length: 0


<------------>
[Jan  8 13:37:44] VERBOSE[1441][C-00000008] bridge_channel.c: Channel SIP/xxxx623-00000011 left 'native_rtp' basic-bridge <1545a74e-7481-4472-b05c-9a1606764dd9>
[Jan  8 13:37:44] VERBOSE[1439][C-00000008] bridge_channel.c: Channel SIP/t-online-22-00000010 left 'native_rtp' basic-bridge <1545a74e-7481-4472-b05c-9a1606764dd9>
[Jan  8 13:37:44] VERBOSE[1439][C-00000008] pbx.c: Spawn extension (incoming, xxxxxxxxx623, 2) exited non-zero on 'SIP/t-online-22-00000010'
[Jan  8 13:37:47] VERBOSE[1347] chan_sip.c: -- wrong response code 0
[Jan  8 13:37:53] WARNING[1347] chan_sip.c: Retransmission timeout reached on transmission p65567t1483872150m246668c583195503s2 for seqno 105 (Non-critical Request) -- See https://wiki.asterisk.org/wiki/display/AST/SIP+Retransmissions
Packet timed out after 6400ms with no response
[Jan  8 13:38:16] VERBOSE[1347] chan_sip.c: Really destroying SIP dialog '[email protected]:5060' Method: BYE

Vermute das es etwas mit NAT zu tun hat, habe verschiedene Einstellungen probiert, aber ohne Erfolg.
 
Man kann für einen Host keine unterschiedlichen Contexte definieren, Asterisk nimmt immer das erste Peer in der sip.conf mit passendem host/insecure und dessen context. Deshalb landeten ursprünglich alle Anrufe im [incoming-22]. Mit einem gemeinsamen incoming Context wird das zunächst funktionieren, über kurz oder lang wirst Du aber wahrscheinlich auch ein Opfer der Load Balancer werden.

Vermute das es etwas mit NAT zu tun hat, habe verschiedene Einstellungen probiert, aber ohne Erfolg.
Zum Vergrößern anklicken....

canreinvite gibt es seit 1.8 nicht mehr, das heißt jetzt directmedia und sollte bei externen Peers auf jeden Fall auf no stehen. Sicherheitshalber im [general] directmedia=no setzen und ggf bei den internen Clients dann explizit erlauben.

Den localnet Eintrag solltest Du aktivieren, damit Asterisk intern und extern unterscheiden kann.

Fax over VoIP ist und bleibt aber trotzdem eine wackelige Geschichte. T.38 hilft da halbwegs, aber stell trotzdem am Fax die Übertragungsrate auf max 9600bps runter.

Endlich noch ein Mädel, die sich mit Asterisk beschäftigt, ich dachte schon ich bleibe auf ewig die Einzige hier. Willkommen an Board! :phone02:
 
rentier-s schrieb:
über kurz oder lang wirst Du aber wahrscheinlich auch ein Opfer der Load Balancer werden.
Zum Vergrößern anklicken....

Ist es eigentlich gesichert, dass die Signalisierung auch über einen anderen als den Registrierungsserver reinkommen kann? Ich habe den All IP seit 'nem Monat oder so und logge jetzt seit einer Woche alle Verbindungen die ich auf Firewall Ebene akzeptiere (aus dem Netz 217.0.0.0/13) oder ablehne. Die abgelehnten checke ich zusätzlich mit grepcidr ob sie aus einem Netz kommen das von der Telekom alloziert ist. Das Script sieht so aus
Code: 
#!/bin/sh

ffile=/tmp/ip-filtered
echo "Dropped Tkom addresses:"
zgrep 'VOIP:DROP' /var/log/Remotes/router.log* | sed 's/.*SRC=\([.0-9]*\).*DPT=\([0-9]*\).*/\1/' | sort -u > $ffile
grepcidr -f /root/telekom-cidrs $ffile

echo
echo "Accepted Tkom addresses:"
zgrep 'VOIP:ACCEPT' /var/log/Remotes/router.log* | sed 's/.*SRC=\([.0-9]*\).*DPT=\([0-9]*\).*/\1:\2/' | sort -u
und die Ausgabe zB so
Code: 
Dropped Tkom addresses:

Accepted Tkom addresses:
217.0.23.39:5060
217.0.4.132:30024
217.0.4.196:30040
217.0.4.196:30041
217.0.5.100:30016

Wie man sieht kommen Media von sonstwo aus dem Netz, aber die Signalisierung immer von demselben Server. Daher nochmal die Frage, auch weil ich mir einfach nicht vorstellen kann das deren Setup - mit Verlaub - so dämlich sein könnte.
 
bhertz schrieb:
Ist es eigentlich gesichert, dass die Signalisierung auch über einen anderen als den Registrierungsserver reinkommen kann?
Zum Vergrößern anklicken....

Mit Sicherheit kann ich das nicht sagen, ich selbst habe das nicht aktiv beobachtet, weil ich allowguest an habe. Wir hatten hier schon Threads dazu, wo genau das das Problem war. Der Ablauf war immer, dass urplötzlich keine Anrufe mehr durch kamen, laut Logs erkannte Asterisk den host nicht mehr, nach einem sip reload war wieder alles in Ordnung. Ich könnte mir vorstellen, dass man mittlerweile zB. nur noch bei jeder PPPoE Einwahl einen neuen Server zugewiesen bekommt, das könnte auch erklären warum Du seit einem Monat den gleichen hast. Bei mir liefert tel.t-online.de zur Zeit übrigens 217.0.23.203.

Ich wollte damit keine Diskussion auslösen, sondern Mileena nur einen Hinweis mit auf den Weg geben, falls es mal deswegen nicht mehr funktioniert.
 
rentier-s schrieb:
Ich wollte damit keine Diskussion auslösen, sondern Mileena nur einen Hinweis mit auf den Weg geben, falls es mal deswegen nicht mehr funktioniert.
Zum Vergrößern anklicken....

Ok, aber vielleicht ist das ja genau die Diskussion die geführt werden sollte und immer noch nicht abgeschlossen ist, insbesondere wegen Mangels klarer Ansagen von Seiten der Telekom. Im Gegensatz zu anderen bin ich erst seit kurzem dabei, aber es scheint ja immer noch große Konfusion darüber zu herrschen wie weit man seinen Router/Asterisk "aufmachen" muss.

Beispiel Zuweisung neuer Server, das du angesprochen hast. Das sollte überhaupt kein Problem sein solange die Telekom es sauber implementiert. Mein Asterisk 13 macht vor jedem (Re-)Registrierungsvorgang einen DNS SRV Lookup. Und wenn der Lookup einen neuen Server liefert, nach Priorität und Gewichtung, dann wird eben dort registriert. Und dort ist man dann eben auch erreichbar, wenn die Telekom ihre Arbeit richtig macht.

Ich habe einen Fall selbst erlebt in der kurzen Zeit, wie du ihn beschreibst. Aber der Grund dafür lag hierin: http://www.ip-phone-forum.de/showthread.php?t=276806&p=2165421&viewfull=1#post2165421

Das heisst bei dem Dual Stack Zugang gibt dir die Tkom vier Nameserver, je zwei mit IPv4 und IPv6 Adressen. Und die geben eben unterschiedliche Antworten auf die DNS SRV Lookups. Das heisst bei den IPv4 DNS Servern ist der Top SIP Registrar ein anderer Server als bei den IPv6 DNS Servern. Was immer noch kein Problem sein sollte, dann registriert sich Asterisk eben mal hier und mal da und bekommt auch immer ein "OK" zurück. Das heisst es versteht sich logischerweise als korrekt registriert. Aber die Telekom Server, mit ihrer klar unsauberen Implementierung, steigen aus unerfindlichen Gründen aus.

Daher meine Verwunderung, dass diese Dinge anscheinend noch immer nicht geklärt sind.
[Piiieeeeeep, bitte sachlich bleiben, Novize]
 
Zuletzt bearbeitet von einem Moderator:
Um antworten zu können musst du eingeloggt sein.

Zurzeit aktive Besucher

Gesamt: 590 (Mitglieder: 3, Gäste: 587)

Neueste Beiträge

Statistik des Forums

Themen
244,840
Beiträge
2,219,265
Mitglieder
371,543
Neuestes Mitglied
Brainbanger
Holen Sie sich 3CX - völlig kostenlos!
Verbinden Sie Ihr Team und Ihre Kunden Telefonie Livechat Videokonferenzen

Gehostet oder selbst-verwaltet. Für bis zu 10 Nutzer dauerhaft kostenlos. Keine Kreditkartendetails erforderlich. Ohne Risiko testen.

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.
Ihr E-Mail-Adresse verifizieren

Ihr E-Mail-Adresse verifizieren

Wir haben Ihnen eine E-Mail geschickt. Klicken Sie auf die Schaltfläche im E-Mail-Text, um Ihre E-Mail-Adresse zu verifizieren – (Können Sie diese nicht finden können, dann überprüfen Sie Ihren Spam-Ordner).

IPPF im Überblick

Neueste Beiträge

Direktlinks Telefonanlage

Website-Sponsoren

3CX sponsor
KONTAKTIEREN SIE UNS BEI INTERESSE
| Style by ThemeHouse
XenPorta 2 PRO © Jason Axelrod of 8WAYRUN
Oben Unten
Zurück