[Problem] Asterisk: Unable to create channel of type 'SIP' (cause 20 - Subscriber absent)

howy-1

Neuer User
Mitglied seit
5 Apr 2010
Beiträge
39
Punkte für Reaktionen
0
Punkte
6
Hallo zusammen,

zuerst mein System: Asterisk 1.8 mit chan_capi, Intern als Haustelefonanlage per SIP, als Clients Fritzbox und Speedports, an denen Analogtelefone hängen. Telefonie ins Festnetz per CAPI.

Nun das Problem: Wenn Anrufe von außen reinkommen, klingeln die Clients, hebt man ab, ist niemand dran und gleichzeitig klingeln die anderen Telefone weiter. Der Anrufer von draußen kriegt einen Normalklingelton, dann das Besetztzeichen. Beim zweiten Versuch Sekunden später ist dann alles ganz normal, der Anruf kommt durch und auch die anderen Clients verstummen, wenn einer abnimmt.
Manchmal braucht es 3 Versuche, andermal klappt es gleich beim ersten Versuch.

Ich hab mal Logeinträge von einem Fehlanruf:

/var/log/asterisk/messages:
Code:
[May 31 11:26:50] WARNING[30279] app_dial.c: Unable to create channel of type 'SIP' (cause 20 - Subscriber absent)

/var/log/asterisk/full:
Code:
[May 31 11:26:28] DEBUG[31271] chan_sip.c: Allocating new SIP dialog for [email protected]:5060 - OPTIONS (No RTP)
[May 31 11:26:28] DEBUG[31271] acl.c: For destination '192.168.1.101', our source address is '192.168.1.5'.
[May 31 11:26:28] DEBUG[31271] chan_sip.c: Setting SIP_TRANSPORT_UDP with address 192.168.1.5:5060
[May 31 11:26:28] DEBUG[31271] chan_sip.c: SIP call-id changed from '[email protected]:5060' to '[email protected]:5060'
[May 31 11:26:28] DEBUG[31271] chan_sip.c: Initializing initreq for method OPTIONS - callid [email protected]:5060
[May 31 11:26:28] DEBUG[31271] chan_sip.c: Trying to put 'OPTIONS sip' onto UDP socket destined for 192.168.1.101:5060
[May 31 11:26:28] DEBUG[31271] chan_sip.c: Stopping retransmission on '[email protected]:5060' of Request 102: Match Found
[May 31 11:26:28] DEBUG[31271] chan_sip.c: Destroying SIP dialog [email protected]:5060
[May 31 11:26:28] DEBUG[31271] chan_sip.c: Allocating new SIP dialog for [email protected]:5060 - OPTIONS (No RTP)
[May 31 11:26:28] DEBUG[31271] acl.c: For destination '192.168.1.101', our source address is '192.168.1.5'.
[May 31 11:26:28] DEBUG[31271] chan_sip.c: Setting SIP_TRANSPORT_UDP with address 192.168.1.5:5060

Und so geht das einige Zeilen weiter...

Zur Erklärung:
192.168.1.5 ist der Asterisk-Server
192.168.1.101 ist eine der Client-Boxen

Meine sip.conf:
Code:
[general]
port=5060
bindaddr=0.0.0.0
allowguest=no
srvlookup=yes
alwaysauthreject=yes
language=de
insecure=invite,port
host=dynamic
defaultexpirey=300
maxexpirey=3600
nat=yes
register=yes
qualify=1000
localnet=192.168.1.0/24
pedantic=no

[2001]
callerid="2001"<2001>
type=friend
register=yes
qualify=1000
secret=****
callgroup=2
pickupgroup=2
host=dynamic

Die anderen Peers sind genauso eingestellt.

Wo könnte ich ansetzen? Ich hab schon einiges in [general] versucht, zuletzt pedantic=no (weil in Asterisk 1.8 wohl per default auf yes), aber nichts brachte eine Verbesserung.
Wenn es gar nicht gehen würde, könnte man ja von einer Fehlkonfiguration ausgehen, aber es ist ca. 50:50, dass der Fehler auftritt, und dann gehts ja irgendwann doch.
Raustelefonieren geht immer ohne Probleme.

Aktuell grad nochmal probiert, jetzt ging es, aber in der Konsole standen trotzdem diese Zeilen mit:

Code:
    -- SIP/2001-00000000 connected line has changed. Saving it until answer for CAPI/ISDN1#02/*****-0
    -- SIP/2002-00000001 connected line has changed. Saving it until answer for CAPI/ISDN1#02/*****-0
    -- SIP/2003-00000002 connected line has changed. Saving it until answer for CAPI/ISDN1#02/*****-0
    -- SIP/2004-00000003 connected line has changed. Saving it until answer for CAPI/ISDN1#02/*****-0

****** ist die MSN, auf der der Anruf reinkam.

Beste Grüße

Dirk
 
Zuletzt bearbeitet von einem Moderator:
hab zwar schon lange nix mehr mit Asterisk gemacht, aber müsste in der sip.conf unter bindaddr nicht die IP deines Servers stehn? (also statt 0.0.0.0 eher 192.168.1.5) (sorry falls ich mich irre, aber hab das letzte mal vor 10 Jahren Asterisk in meinem Praktikum zum IT benutzt wobei das hier rauskam: http://www.ms-netpage.de/files/MiniQuickinstall_Asterisk_OpenSourcePBX_D_.pdf , denk aber mal das sich seither [vers 0.9] ne Menge verändert hat)
 
Zuletzt bearbeitet:
müsste in der sip.conf unter bindaddr nicht die IP deines Servers stehn? (also statt 0.0.0.0 eher 192.168.1.5)

Das mit der bindaddr habe ich so verstanden, dass das die Adresse ist, auf die der jeweilige Prozess "angebunden" ist (gibts ja nicht nur beim Asterisk). Und da bedeutet 0.0.0.0 , dass er an alle gebunden ist...
 
Fuer mich sieht das so aus, als waere die Nebenestelle zum Zeitpunkt des Anrufes nicht registriert. Das wuerde auch erklaeren, warum die anderen Apparate weiterhin klingeln.

Mach aus dem qualify=1000 mal ein qualify=yes.

Das mit der bindaddr=0.0.0.0 hast du richtig verstanden, das kann so stehenbleiben.

Was ich vermisse sind Eintraege fuer die Codecs in der sip.conf, also etwas wie disallow=all, allow=alaw etc. ...

Viel Glueck!

Sorry, ich sehe gerade noch etwas ...

Wenn der Asterisk auf Anrufe von draussen reagieren soll, dann lass den mal lieber auf Port 5062 lauschen, denn auf Port 5060 lauscht ja schon die Fritzbox.
 
Fuer mich sieht das so aus, als waere die Nebenestelle zum Zeitpunkt des Anrufes nicht registriert. Das wuerde auch erklaeren, warum die anderen Apparate weiterhin klingeln.

Die anderen Apparate klingeln ja weiter, bis man sie abhebt oder ein gewisser Timeout errreicht ist. Es kommt dann auch keine Verbindung zustande, weil der Anrufer ja schon längst zu diesem Zeitpunkt aus der Leitung geflogen ist. Der Anruf kommt ja über CAPI rein, doch es wird nicht gleich der passende SIP-Channel aufgemacht. Beim zweiten Anrufversuch gehts dann meistens.

Es sind zwar nicht ständig alle Peers registriert, aber die hauptsächlichsten schon.

Mach aus dem qualify=1000 mal ein qualify=yes.

Ok, dann versuche ich das mal so. qualify=1000 ist aber lt. http://www.voip-info.org/wiki/view/Asterisk+sip+qualify auch erlaubt, wenn man den Intervall ändern möchte. Die Einstellung von qualify hat zumindest eine Änderung gebracht, dass bei "sip show peers" nun die peers als "managed" drin stehen, mit Angabe ihrer Antwortzeit, gegen vorher "unmanaged". Eine Änderung am Problem selber brachte es nicht.

Alternativ setze ich jetzt mal qualify=yes und schaue, ob es was bringt.

Was ich vermisse sind Eintraege fuer die Codecs in der sip.conf, also etwas wie disallow=all, allow=alaw etc. ...

Auch ohne diese Eingabe funktioniert es ja intern, also nur über SIP hervorragend.

Mir ist aber grad noch ein Logeintrag aufgefallen:

[Jun 1 12:47:58] DEBUG[31288] chan_sip.c: SIP call-id changed from '18fd06ea0a0
[email protected]:5060' to '3e70218528dd96a847d52bcf4a259b3a@192
.168.1.5:5060'

Wieso wird da eine call-id verändert? Die Peers sind doch fest zugewiesen, und es sind ja auch nur max. 10 Peers. Oder kann man diese call-id noch irgendwo fest eintragen?

Wenn der Asterisk auf Anrufe von draussen reagieren soll, dann lass den mal lieber auf Port 5062 lauschen, denn auf Port 5060 lauscht ja schon die Fritzbox.

Von außen (falls Du Festnetz meinst), kriegt der Asterisk alles über chan_capi rein. SIP-Telefonie läuft nur in meinem LAN.
Aber falls ich da was falsch verstanden habe, muss ich dann den Port auch noch woanders ändern?
 
Moin Dirk,

Asterisk 1.8 mit chan_capi, Intern als Haustelefonanlage per SIP, als Clients Fritzbox und Speedports, an denen Analogtelefone hängen. Telefonie ins Festnetz per CAPI.
kannst du mal etwas genauer beschreiben, wer da an was haengt, also wo die Anrufe ankommen und wer oder was die dann wohin weiterleitet?

Ansonsten mal 'sip debug' benutzen. Die Meldung 'cause 20 - Subscriber absent' kenne ich nur aus Situationen, wo das angerufene Telefon nicht online ist. Ich hatte kuerzlich ein aehnliches Problem mit einem Panasonic KX-UT113. Da war im Telefon selbst etwas falsch konfiguriert woraufhin das Telefon sich immer wieder abgemeldet und neu registriert hat. Kam dann genau zu dem Zeitpunkt ein Anruf rein, wurde der mit 'Subscriber absent' abgewiesen.

In deiner sip.conf kommen mir ein paar Eintraege merkwuerdig vor, aber das kann daran liegen, dass du eine aeltere Version vom Asterisk benutzt, die ich kaum kenne.
 
kannst du mal etwas genauer beschreiben, wer da an was haengt, also wo die Anrufe ankommen und wer oder was die dann wohin weiterleitet?

Ok, dann nochmal genauer: Anrufe von außen kommen über ISDN rein (chan_capi) und SIP ist nur für interne Telefonie. Als SIP-zu-analog-Konverter fungieren eine Fritzbox und 2 Speedports mit je 3 analogen Telefonen (Peer 2001 - 2009).

Der Fehler tritt sporadisch auf, ca. 50:50. Ein über ISDN ankommender Anruf wird kurz signalisiert und dann abgewiesen. Beim zweiten Versuch klappts dann meistens. Ich vermute irgendwas im Zusammenhang mit der Öffnung der SIP-Channels geht da erstmal schief oder dauert zu lange. Oder es hat wirklich mit diesem "chan_sip.c: SIP call-id changed from ...." zu tun. Das einzige, was mir in dem Zusammenhang einfällt, ist im Dialplan das Einfügen der Null für die Telefonanlage in die Nummernanzeige, mittels:
exten => ******,1,Set(CALLERID(num)=0${CALLERID(num)})

****** ist die ISDN-MSN, worauf der Anruf reinkommt.
 
Die Meldung "cause 20" sagt ziemlich eindeutig, dass Asterisk der Client nicht unter der bekannten Adresse/Port erreichen kann.

In der sip.conf muss das register=yes raus, das ist nur für Peers wenn man sich die register=> Anweisung sparen will.
host=dynamic macht im [general] auch keinen Sinn.
Wo wir grad dabei sind, die Angabe von ms bei qualify ist nicht das Interval in dem die Abfrage stattfindet, sondern der Timeout, den der Client Zeit hat auf das OPTIONS von Asterisk zu antworten. Bei langsamen/wackeligen Netzwerken mag das Sinn machen das größer yes (=1000) zu setzen, damit ein Client nicht fälschlich als offline markiert wird.
Wenn sich alles im gleichen Netzwerk befindet, muss nat=yes nicht sein.
Außerdem meinst Du mit port=5060 wahrscheinlich bindport=5060.

All das sollte aber eigentlich nicht das Problem sein. Vielleicht bringt ein sip debug (sip set debug peer 2001) Licht ins Dunkle. Lange genug laufen lassen, damit man die Registrierung sieht. Danach mal direkt versuchen anzurufen und dann bis kurz vor der nächsten Registrierung warten und nochmal versuchen.
 
Ok, das klingt auf jeden Fall schonmal nach jemand, der die Materie tiefer kennt. :)

Die meisten Sachen in der sip.conf kommen vom rumprobieren das Problem in den Griff zu kriegen.
host=dynamic, nat=yes, register=yes und qualify=yes hab ich jetzt alles wieder rausgenommen.

Seltsam ist eben, dass ich das ganze System hardwaremäßig schon einige Jahre ohne Probleme in Betrieb hatte, einzige Veränderung war der Umzug des Asterisk vom Router (Asterisk 1.6 mit Fli4l als BS) auf den Server (Asterisk 1.8 mit Eisfair), wobei ich die Configdateien komplett übernommen habe. Bis auf dieses Problem funzt ja auch alles. Die meisten Anrufer fliegen beim ersten Versuch mit Besetztzeichen wieder raus, die Wahlwiederholung Sekunden später kommt dann durch.

Vielleicht bringt ein sip debug (sip set debug peer 2001) Licht ins Dunkle. Lange genug laufen lassen, damit man die Registrierung sieht.

Wie müsste das mit der Registrierung aussehen? Die Boxen, an denen die Telefone hängen, sind durchgehend eingeschaltet und online im LAN, oder läuft eine Registrierung im Asterisk irgendwann ab und muss neu registriert werden (so ähnlich wie die IPs beim DHCP-Server)?

Ich habe grad im SIP debug die folgende Zeile:

Really destroying SIP dialog '[email protected]:5060' Method: OPTIONS


Vorher hab ich für die Peers die ganzen Zeilen, welche wahrscheinlich die Registrierung darstellen.

Code:
<--- SIP read from UDP:192.168.1.101:5060 --->

<------------->
Reliably Transmitting (no NAT) to 192.168.1.101:5060:
OPTIONS sip:[email protected];uniq=885B5973514ABEA847907275A538C SIP/2.0
Via: SIP/2.0/UDP 192.168.1.5:5060;branch=z9hG4bK6399f9ee
Max-Forwards: 70
From: "asterisk" <sip:[email protected]>;tag=as6f62ea5d
To: <sip:[email protected];uniq=885B5973514ABEA847907275A538C>
Contact: <sip:[email protected]:5060>
Call-ID: [email protected]:5060
CSeq: 102 OPTIONS
User-Agent: Asterisk PBX 1.8.32.2
Date: Mon, 08 Jun 2015 17:49:19 GMT
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH, MESSAGE
Supported: replaces, timer
Content-Length: 0


---

<--- SIP read from UDP:192.168.1.101:5060 --->
SIP/2.0 200 OK
Via: SIP/2.0/UDP 192.168.1.5:5060;branch=z9hG4bK6399f9ee;received=192.168.1.5
From: "asterisk" <sip:[email protected]>;tag=as6f62ea5d
To: <sip:[email protected];uniq=885B5973514ABEA847907275A538C>;tag=1D228EA945B29137
Call-ID: [email protected]:5060
CSeq: 102 OPTIONS
Contact: <sip:[email protected];uniq=885B5973514ABEA847907275A538C>
User-Agent: AVM FRITZ!Box Fon 5050 (UI) 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
Accept: application/sdp, multipart/mixed
Accept-Encoding: identity
Content-Length: 0


<------------->
--- (14 headers 0 lines) ---
Really destroying SIP dialog '[email protected]:5060' Method: OPTIONS

<--- SIP read from UDP:192.168.1.101:5060 --->

<------------->
eisfair*CLI>
 
Abend

Ich erklär mal kurz das SIP Debuggen. ;)

Also ein erfolgreiches Registrieren sieht im lokalen Netz so aus...

SIP Trace vom IP-Telefon
Code:
Sent to udp:192.168.178.9:5060 at Jun  8 20:26:23 (636 bytes):
REGISTER sip:openelec SIP/2.0
Via: SIP/2.0/UDP 192.168.178.6:5060;branch=z9hG4bK-p1mhlp07dchd;rport
From: <sip:1005@openelec>;tag=cntjcoqfx0
To: <sip:1005@openelec>
Call-ID: 313433333532333231343236393430-d8vqzg82x43r
CSeq: 2007 REGISTER
Max-Forwards: 70
User-Agent: snom320/8.7.5.13
Contact: <sip:[email protected]:5060;line=fjv3n8lc>;reg-id=1;q=1.0;audio;mobility="fixed";duplex="full";description="snom320";actor="principal";events="dialog";methods="INVITE,ACK,CANCEL,BYE,REFER,OPTIONS,NOTIFY,SUBSCRIBE,PRACK,MESSAGE,INFO"
Allow-Events: dialog
X-Real-IP: {x-snom-adr}
Supported: path
Expires: 3600
Content-Length: 0


Received from udp:192.168.178.9:5060 at Jun  8 20:26:23 (513 bytes):
SIP/2.0 401 Unauthorized
Via: SIP/2.0/UDP 192.168.178.6:5060;branch=z9hG4bK-p1mhlp07dchd;received=192.168.178.6;rport=5060
From: <sip:1005@openelec>;tag=cntjcoqfx0
To: <sip:1005@openelec>;tag=as0a8aabee
Call-ID: 313433333532333231343236393430-d8vqzg82x43r
CSeq: 2007 REGISTER
Server: Asterisk PiBX
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH
Supported: replaces, timer
WWW-Authenticate: Digest algorithm=MD5, realm="asterisk", nonce="26647ccc"
Content-Length: 0


Sent to udp:192.168.178.9:5060 at Jun  8 20:26:23 (786 bytes):
REGISTER sip:openelec SIP/2.0
Via: SIP/2.0/UDP 192.168.178.6:5060;branch=z9hG4bK-omh3w021ncvi;rport
From: <sip:1005@openelec>;tag=cntjcoqfx0
To: <sip:1005@openelec>
Call-ID: 313433333532333231343236393430-d8vqzg82x43r
CSeq: 2008 REGISTER
Max-Forwards: 70
User-Agent: snom320/8.7.5.13
Contact: <sip:[email protected]:5060;line=fjv3n8lc>;reg-id=1;q=1.0;audio;mobility="fixed";duplex="full";description="snom320";actor="principal";events="dialog";methods="INVITE,ACK,CANCEL,BYE,REFER,OPTIONS,NOTIFY,SUBSCRIBE,PRACK,MESSAGE,INFO"
Allow-Events: dialog
X-Real-IP: {x-snom-adr}
Supported: path
Authorization: Digest username="1005",realm="asterisk",nonce="26647ccc",uri="sip:openelec",response="448f479080bd55e3be9f93d8c8f71ed9",algorithm=MD5
Expires: 3600
Content-Length: 0


Received from udp:192.168.178.9:5060 at Jun  8 20:26:23 (575 bytes):
OPTIONS sip:[email protected]:5060;line=fjv3n8lc SIP/2.0
Via: SIP/2.0/UDP 192.168.178.9:5060;branch=z9hG4bK033a5c86;rport
Max-Forwards: 70
From: "asterisk" <sip:[email protected]>;tag=as041ca2b6
To: <sip:[email protected]:5060;line=fjv3n8lc>
Contact: <sip:[email protected]:5060>
Call-ID: [email protected]:5060
CSeq: 102 OPTIONS
User-Agent: Asterisk PiBX
Date: Mon, 08 Jun 2015 18:26:23 GMT
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH
Supported: replaces, timer
Content-Length: 0


Sent to udp:192.168.178.9:5060 at Jun  8 20:26:23 (645 bytes):
SIP/2.0 200 OK
Via: SIP/2.0/UDP 192.168.178.9:5060;branch=z9hG4bK033a5c86;rport=5060
From: "asterisk" <sip:[email protected]>;tag=as041ca2b6
To: <sip:[email protected]:5060;line=fjv3n8lc>;tag=ji69lj41u5
Call-ID: [email protected]:5060
CSeq: 102 OPTIONS
User-Agent: snom320/8.7.5.13
Contact: <sip:[email protected]:5060;line=1ty17qr5>;reg-id=1
Accept-Language: en
Accept: application/sdp
Allow: INVITE, ACK, CANCEL, BYE, REFER, OPTIONS, NOTIFY, SUBSCRIBE, PRACK, MESSAGE, INFO, UPDATE
Allow-Events: talk, hold, refer, call-info
Supported: timer, replaces, from-change
Content-Length: 0


Received from udp:192.168.178.9:5060 at Jun  8 20:26:23 (546 bytes):
SIP/2.0 200 OK
Via: SIP/2.0/UDP 192.168.178.6:5060;branch=z9hG4bK-omh3w021ncvi;received=192.168.178.6;rport=5060
From: <sip:1005@openelec>;tag=cntjcoqfx0
To: <sip:1005@openelec>;tag=as0a8aabee
Call-ID: 313433333532333231343236393430-d8vqzg82x43r
CSeq: 2008 REGISTER
Server: Asterisk PiBX
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH
Supported: replaces, timer
Expires: 3600
Contact: <sip:[email protected]:5060;line=fjv3n8lc>;expires=3600
Date: Mon, 08 Jun 2015 18:26:23 GMT
Content-Length: 0
...wobei ich mir angewöhnt habe...

1. 1. Blick auf: User-Agent:
2. ...dann auf: CSec:
3. ...am End: 2. Zeile mit SIP (ob OK oder nicht)

Ach, ja, das Erste: SIP/2.0 401 Unauthorized
Ist etwas verwirrend, es wird eigentlich ein nonce= ausgetauscht.
Das dient der Authentifizierung, wenn genau hingeschaut wird.

Also.
Demnach ist das was du gepostet hast, was?

Ach was solls, das hier beantworte ich auch noch schnell....
:confused:
läuft eine Registrierung im Asterisk irgendwann ab und muss neu registriert werden (so ähnlich wie die IPs beim DHCP-Server)?
Das kann/wird über das expiry= ausgehandelt.
Der Klient darf also mit dem Server darüber verhandeln.
Der Server bestimmt natürlich letztendlich: Expires: 3600
...moment ich tipp mal (3600 geteilt durch 60 = .... ) : 60 Minuten (2x nachgerechnet)
Also: Der Klient muss sich nach 1 Stunde wieder registrieren.
 
Zuletzt bearbeitet:
Demnach ist das was du gepostet hast, was?

Das ist ein Ausschnitt dessen, was ein paar Sekunden nach Eingabe von sip set debug peer 2001 ausgegeben wird (2001 ist ein Peer bei mir).

Könnte das Problem vielleicht damit zusammenhängen, dass die Peers 2001, 2002, u. 20003 an ein und derselben IP hängen? Es ging zwar über Jahre mit Asterisk 1.6 so gut, aber wer weiß...

Ich weiß nicht, warum immer diese Meldung kommt:

Really destroying SIP dialog '[email protected]:5060' Method: OPTIONS

Und warum kommen ständig dies Registrierungsmeldungen aller paar Sekunden?
 
Das ist nur ein OPTIONS Request gewesen, keine Registrierung.
...ähnlich einem Ping.
Nach einem REGISTER sieht das so aus...
Code:
Really destroying SIP dialog '313433323734393137393133373636-cx2shzx41idf' Method: REGISTER

Eine Fritz!Box Nummer darf sich bei mir übrigens...
sip.conf
Code:
[basic-options](!) ; a template
dtmfmode=rfc2833
type=friend

[ast-user](!,basic-options)
secret=seccret
host=dynamic
qualifyfreq=600
qualify=1000

[my-codecs](!) ; a template for my preferred codecs
disallow=all
allow=g722
allow=alaw


[[COLOR=#ff0000][B]1002[/B][/COLOR]](ast-user,my-codecs)
context=sas
username=FritzBox_7360SL
callerid="FritzBox_7360SL"<1002>
...daran registrieren.
asterisk > sip show peers
Code:
Name/username              Host                                    Dyn Forcerport ACL Port     Status
1002/FritzBox_7360SL       192.168.178.1                            D   N             5060     OK (9 ms)
 
Zuletzt bearbeitet:
Ok, bei mir hängen an der Fritzbox ja 3 Analogtelefone, die als 2001, 2002 und 2003 registriert sind. Interne Telefonie (also nur über SIP) geht ja auch zu jeder Zeit problemlos. Es geht nur um die über CAPI reinkommenden Anrufe. Mir scheint, als würde der Aufbau der Verbindung CAPI zu SIP irgendwo klemmen, weshalb CAPI wieder auflegt.
 
Nun, um ehrlich zu sein, mit CAPI hab ich nichts zu tun.
Im Gegenteil, bin froh wenn die alten Telefone weg sind.
...damit wir Alle noch mehr in HD telefonieren können. :D
..oder verschlüsselt?
...oder alles auf Einmal.
 
Interessanter wäre das SIP Debug allerdings, wenn auch was passieren würde ;-) Mach das Debug an und versuch Dich anzurufen. Da wird jede Menge Text produziert, nicht erschrecken. Entscheidend wäre natürlich, dass der Anruf nicht funktioniert. Entweder kann man das dann mit dem Debug eines funktionierenden Anrufs vergleichen, oder man kann vielleicht direkt eine Ursache erkennen.

BTW, benutze für Logs und Configs bitte [noparse]
Code:
...
[/noparse] Blöcke, dann sind die besser zu lesen als als Quote.

Im "Aufbau der Verbindung CAPI zu SIP" gibt es tatsächlich eine kleine Hürde. CAPI ist wesentlich ungeduldiger als SIP im Hinblick auf die Reaktion der Gegenseite. In langsamen Netzwerken kann es passieren, dass es zu lange dauert, bis vom Endgerät ein Ringing kommt. In diesem Fall würde der Anruf ISDN seitig abgebrochen. Ein Ringing() vor dem Dial() korrigiert das. Kann ich mir in diesem Fall aber auch nicht recht vorstellen.
 
CAPI ist wesentlich ungeduldiger als SIP im Hinblick auf die Reaktion der Gegenseite. In langsamen Netzwerken kann es passieren, dass es zu lange dauert, bis vom Endgerät ein Ringing kommt.

Ok, genau so kommt mir das aber manchmal vor. Als würden die SIP-Geräte bei einem ankommenden Anruf erstmal aus ihrer Lethargie geweckt werden müssen, und bis das soweit ist, hat CAPI schon wieder aufgelegt. Manchmal sind sie halt irgendwie noch wacher und gehen gleich ran...

Ich hab den Ringing-Befehl in extensions.conf eingefügt und werde die Sache mal beobachten.
 
So, nun hab ich auch noch testweise die Fritz-ISDN-Karte gewechselt, doch weder das, noch der eingefügte Ringing-Befehl in der extensions.conf hat was gebracht. Das ist doch zum Mäuse melken...
 
Auch wenn ich immer noch nicht versprechen kann, ob man was drin findet, frag ich Dich jetzt zum dritten Mal nach dem SIP Debug (insb. das INVITE und was danach passiert) eines nicht funktionierenden Anrufversuchs.
 
Auch wenn ich immer noch nicht versprechen kann, ob man was drin findet, frag ich Dich jetzt zum dritten Mal nach dem SIP Debug (insb. das INVITE und was danach passiert) eines nicht funktionierenden Anrufversuchs.

Wenn ich wüsste, wie ich das aus den Logs rausfiltern kann, würde ich das auch gerne posten. Aber in den Logs ist ja alles drin, so dass da zuviel "Beifang" mitkommt. Oder könnte ich auch direkt nur das SIP Debug in eine Datei schreiben lassen?
Bei Eingabe von sip debug in der Asterisk-Konsole laufen da soviele Zeilen auf, dass ich gar nicht weit genug zurückscrollen kann.
 
Du kannst die CLI Ausgabe mit asterisk -r | tee /tmp/asterisk.log in eine Datei schreiben lassen. Dann core set verbose 1 und sip set debug peer 2001, damit sollten nur Warnungen und das SIP Debug für die Fritzbox ausgegeben werden.
 

Statistik des Forums

Themen
246,341
Beiträge
2,250,496
Mitglieder
373,998
Neuestes Mitglied
MacDeath
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.