Asterisk 1.4.15-dfsg-1 crasht

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

PinguTS

Neuer User
Mitglied seit
16 Jul 2006
Beiträge
7
Punkte für Reaktionen
0
Punkte
0
So, jetzt bin ich mal in die "gestern ging's noch und ich habe nichts gemacht"-Falle gestolpert.

Ich habe hier Asterisk auf einem Debian GNU/Linux Testing laufen und gestern gings noch. OK, ich habe etwas gemacht; ich habe ein Update durch geführt. Ja, hätt' ich mal's gelassen.

Es läuft Asterisk mit Fritz Card!Classic und einem angemeldeten SpeedPort W900V, wo eine ISDN-Anlage hängt:
ISDN-PBX : Fritz Card!Classic : Asterisk : W900V : ISDN intern

Es laufen:
Asterisk 1.4.15-dfsg-1
chan-capi 1.0.2-1


Wie gesagt, alles lief bisher super. Nur jetzt, crasht Asterisk jedesmal, nachdem ein Anruf getätigt wurde. Dabei ist es egal, ob der Anruf aus dem öffentlichen ISDN kommt oder über den W900V.

Beispiel: Anruf von intern nach extern; Anruf wird extern nicht entgegen genommen, intern legt vorher auf
Code: 
    -- Executing [017959xxxxx@internal:1] Dial("SIP/fritz-isdn-081fba80", "CAPI/ISDN1/017959xxxxx|60|r") in new stack
    -- Called ISDN1/017959xxxxx
    -- CAPI/ISDN1#02/017959xxxxx-0 is making progress passing it to SIP/fritz-isdn-081fba80
    -- CAPI/ISDN1#02/017959xxxxx-0 is ringing
ts-data*CLI> 
Disconnected from Asterisk server
ts@ts-data:~$
Beispiel: Anruf von extern nach intern; Anruf wird von intern nicht entgegen genommen, extern legt vorher auf
Code: 
  == ISDN1#02: Incoming call '017959xxxxx' -> '366xxxx'
    -- Executing [366xxxx@capi-in:1] Ringing("CAPI/ISDN1#02/366xxxx-0", "") in new stack
    -- Executing [366xxxx@capi-in:2] Dial("CAPI/ISDN1#02/366xxxx-0", "SIP/pingu&SIP/fritz-isdn|20|r") in new stack
[Dec 18 18:36:53] WARNING[7240]: channel.c:3257 ast_request_with_uniqueid: No translator path exists for channel type SIP (native 65535) to 0
[Dec 18 18:36:53] WARNING[7240]: app_dial.c:1150 dial_exec_full: Unable to create channel of type 'SIP' (cause 58 - Bearer capability not available)
[Dec 18 18:36:53] WARNING[7240]: channel.c:3257 ast_request_with_uniqueid: No translator path exists for channel type SIP (native 65535) to 0
[Dec 18 18:36:53] WARNING[7240]: app_dial.c:1150 dial_exec_full: Unable to create channel of type 'SIP' (cause 58 - Bearer capability not available)
  == Everyone is busy/congested at this time (2:0/0/2)
    -- Executing [366xxxx@capi-in:3] Goto("CAPI/ISDN1#02/366xxxx-0", "3669197-CHANUNAVAIL|1") in new stack
    -- Goto (capi-in,366xxxx-CHANUNAVAIL,1)
    -- Executing [366xxxx-CHANUNAVAIL@capi-in:1] Wait("CAPI/ISDN1#02/366xxxx-0", "20") in new stack
    -- Executing [366xxxx-CHANUNAVAIL@capi-in:2] capiCommand("CAPI/ISDN1#02/366xxxx-0", "deflect|0179596xxxx") in new stack
ts-data*CLI> 
Disconnected from Asterisk server
ts@ts-data:~$
Die internen Telefone klingeln bei diesem Anruf NICHT.

Wie man sieht, scheint er neuerdings Probleme mit dem SIP-Channel zu haben. Leider habe ich noch nicht herausfinden können was obige WARNINGs bedeuten.

In meiner /etc/asterisk/sip.conf steht eigentlich nichts besonderes drin
Code: 
[general]
context=default                 ; Default context for incoming calls
realm=sip.example.info            ; Realm for digest authentication
bindport=5060                   ; UDP Port to bind to (SIP standard port is 5060)
bindaddr=0.0.0.0                ; IP address to bind to (0.0.0.0 binds to all)
srvlookup=yes                   ; Enable DNS SRV lookups on outbound calls
externhost=sip.example.info       ; Alternatively you can specify an 
externrefresh=10                ; How often to refresh externhost if 
localnet=192.168.0.0/255.255.0.0; All RFC 1918 addresses are local networks
localnet=172.16.0.0/12          ; Another RFC1918 with CIDR notation

#include "sip.d/*.conf"

Im Verzeichnis liegen dann die einzelnen Dateien für die erlaubten SIP-Clients, also für meine W900V /etc/asterisk/sip.d/fritz.conf:
Code: 
[fritz-isdn]
type=friend
username=fritz-isdn
secret=mysecret
qualify=no
nat=yes
host=dynamic
canreinvite=yes
context=internal
defaultip=192.168.2.1
language=de

Wenn mir noch diese Woche jemand einen Tipp geben könnte wonach ich suchen muss bzw. wie ich es beheben kann wäre es super. Denn wie viele werde ich über Weihnachten nach Hause fahren und dann sollte es spätestens funktionieren.

Danke
 
Also ich habe noch einmal einen Anruf von intern nach extern probiert, um das Problem einzukreisen. Leider hat mich das noch nicht weitergebracht. Vielleicht erkennt jemand von Euch etwas:
Code: 
Connected to Asterisk 1.4.15~dfsg-1 currently running on ts-data [192.168.1.3] (pid = 9718)
ts-data*CLI> core set verbose 100
Verbosity was 0 and is now 100
ts-data*CLI> sip set debug peer fritz-isdn
SIP Debugging Enabled for IP: 192.168.2.1:5060
ts-data*CLI> sip show peer fritz-isdn
ts-data*CLI> 

  * Name       : fritz-isdn
  Secret       : <Set>
  MD5Secret    : <Not set>
  Context      : internal
  Subscr.Cont. : <Not set>
  Language     : de
  AMA flags    : Unknown
  Transfer mode: open
  CallingPres  : Presentation Allowed, Not Screened
  Callgroup    : 
  Pickupgroup  : 
  Mailbox      : 
  VM Extension : asterisk
  LastMsgsSent : 32767/65535
  Call limit   : 0
  Dynamic      : Yes
  Callerid     : "" <>
  MaxCallBR    : 384 kbps
  Expire       : 1659
  Insecure     : no
  Nat          : Always
  ACL          : No
  T38 pt UDPTL : No
  CanReinvite  : Yes
  PromiscRedir : No
  User=Phone   : No
  Video Support: No
  Trust RPID   : No
  Send RPID    : No
  Subscriptions: Yes
  Overlap dial : Yes
  DTMFmode     : rfc2833
  LastMsg      : 0
  ToHost       : 
  Addr->IP     : 192.168.2.1 Port 5060
  Defaddr->IP  : 192.168.2.1 Port 5060
  Def. Username: fritz-isdn
  SIP Options  : (none)
  Codecs       : 0x8000e (gsm|ulaw|alaw|h263)
  Codec Order  : (none)
  Auto-Framing:  No 
  Status       : Unmonitored
  Useragent    : 
  Reg. Contact : sip:[email protected];uniq=D56824B20E79A9A62534FB5D069DB
ts-data*CLI> 
ts-data*CLI> 
<--- SIP read from 192.168.2.1:5060 --->
INVITE sip:[email protected] SIP/2.0
Via: SIP/2.0/UDP 192.168.2.1:5060;branch=z9hG4bKF7578D20C72DEE8A
From: <sip:[email protected]>;tag=00F6328CDD59BF2D
To: <sip:[email protected]>
Call-ID: [email protected]
CSeq: 9 INVITE
Contact: <sip:[email protected];uniq=D56824B20E79A9A62534FB5D069DB>
Max-Forwards: 70
Expires: 120
User-Agent: AVM FRITZ!Box Fon Speedport W 900V 34.04.21 (Jul 12 2006)
Supported: 100rel,replaces,timer
llow-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:   404

v=0
o=user 10345522 10345522 IN IP4 192.168.2.1
s=call
c=IN IP4 192.168.2.1
t=1198054753 1198058353
m=audio 7078 RTP/AVP 8 0 2 102 100 99 97 105 101
a=sendrecv
a=rtpmap:2 G726-32/8000
a=rtpmap:102 G726-32/8000
a=rtpmap:100 G726-40/8000
a=rtpmap:99 G726-24/8000
a=rtpmap:97 iLBC/8000
a=fmtp:97 mode=30
a=rtpmap:105 speex/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-11
a=rtcp:7079

<------------->
--- (17 headers 17 lines) ---
Sending to 192.168.2.1 : 5060 (no NAT)
Using INVITE request as basis request - [email protected]

<--- Reliably Transmitting (NAT) to 192.168.2.1:5060 --->
SIP/2.0 407 Proxy Authentication Required
Via: SIP/2.0/UDP 192.168.2.1:5060;branch=z9hG4bKF7578D20C72DEE8A;received=192.168.2.1
From: <sip:[email protected]>;tag=00F6328CDD59BF2D
To: <sip:[email protected]>;tag=as634bb913
Call-ID: [email protected]
CSeq: 9 INVITE
User-Agent: Asterisk PBX
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY
Supported: replaces
Proxy-Authenticate: Digest algorithm=MD5, realm="sip.example.info", nonce="6bf595c2"
Content-Length: 0


<------------>
Scheduling destruction of SIP dialog '[email protected]' in 32000 ms (Method: INVITE)
Found user 'fritz-isdn'

<--- SIP read from 192.168.2.1:5060 --->
ACK sip:[email protected] SIP/2.0
Via: SIP/2.0/UDP 192.168.2.1:5060;branch=z9hG4bKF7578D20C72DEE8A
From: <sip:[email protected]>;tag=00F6328CDD59BF2D
To: <sip:[email protected]>;tag=as634bb913
Call-ID: [email protected]
CSeq: 9 ACK
User-Agent: AVM FRITZ!Box Fon Speedport W 900V 34.04.21 (Jul 12 2006)
Content-Length: 0


<------------->
--- (8 headers 0 lines) ---
ts-data*CLI> 
<--- SIP read from 192.168.2.1:5060 --->
INVITE sip:[email protected] SIP/2.0
Via: SIP/2.0/UDP 192.168.2.1:5060;branch=z9hG4bK5EADB2C0A3D80E1D
From: <sip:[email protected]>;tag=00F6328CDD59BF2D
To: <sip:[email protected]>
Call-ID: [email protected]
CSeq: 10 INVITE
Contact: <sip:[email protected];uniq=D56824B20E79A9A62534FB5D069DB>
Proxy-Authorization: Digest username="fritz-isdn", realm="sip.example.info", nonce="6bf595c2", uri="sip:[email protected]", response="66c799916892cd129c8eaa0811e6a7ec", algorithm=MD5
Max-Forwards: 70
Expires: 120
User-Agent: AVM FRITZ!Box Fon Speedport W 900V 34.04.21 (Jul 12 2006)
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:   404

v=0
o=user 10345522 10345522 IN IP4 192.168.2.1
s=call
c=IN IP4 192.168.2.1
t=1198054753 1198058353
m=audio 7078 RTP/AVP 8 0 2 102 100 99 97 105 101
a=sendrecv
a=rtpmap:2 G726-32/8000
a=rtpmap:102 G726-32/8000
a=rtpmap:100 G726-40/8000
a=rtpmap:99 G726-24/8000
a=rtpmap:97 iLBC/8000
a=fmtp:97 mode=30
a=rtpmap:105 speex/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-11
a=rtcp:7079

<------------->
--- (18 headers 17 lines) ---
Sending to 192.168.2.1 : 5060 (NAT)
Using INVITE request as basis request - [email protected]
Found user 'fritz-isdn'
Found RTP audio format 8
Found RTP audio format 0
Found RTP audio format 2
Found RTP audio format 102
Found RTP audio format 100
Found RTP audio format 99
Found RTP audio format 97
Found RTP audio format 105
Found RTP audio format 101
Peer audio RTP is at port 192.168.2.1:7078
Found audio description format G726-32 for ID 2
Found audio description format G726-32 for ID 102
Found unknown media description format G726-40 for ID 100
Found unknown media description format G726-24 for ID 99
Found audio description format iLBC for ID 97
Found audio description format speex for ID 105
Found audio description format telephone-event for ID 101
Capabilities: us - 0x8000e (gsm|ulaw|alaw|h263), peer - audio=0xe0c (ulaw|alaw|g726|speex|ilbc)/video=0x0 (nothing), combined - 0xc (ulaw|alaw)
Non-codec capabilities (dtmf): us - 0x1 (telephone-event), peer - 0x1 (telephone-event), combined - 0x1 (telephone-event)
Peer audio RTP is at port 192.168.2.1:7078
Looking for 017959xxxxx in internal (domain 192.168.1.3)
list_route: hop: <sip:[email protected];uniq=D56824B20E79A9A62534FB5D069DB>

<--- Transmitting (NAT) to 192.168.2.1:5060 --->
SIP/2.0 100 Trying
Via: SIP/2.0/UDP 192.168.2.1:5060;branch=z9hG4bK5EADB2C0A3D80E1D;received=192.168.2.1
From: <sip:[email protected]>;tag=00F6328CDD59BF2D
To: <sip:[email protected]>
Call-ID: [email protected]
CSeq: 10 INVITE
User-Agent: Asterisk PBX
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY
Supported: replaces
Contact: <sip:[email protected]>
Content-Length: 0


<------------>
    -- Executing [017959xxxxx@internal:1] Dial("SIP/fritz-isdn-081fd078", "CAPI/ISDN1/017959xxxxx|60|r") in new stack
    -- Called ISDN1/017959xxxxx
ts-data*CLI> 
<--- Transmitting (NAT) to 192.168.2.1:5060 --->
SIP/2.0 180 Ringing
Via: SIP/2.0/UDP 192.168.2.1:5060;branch=z9hG4bK5EADB2C0A3D80E1D;received=192.168.2.1
From: <sip:[email protected]>;tag=00F6328CDD59BF2D
To: <sip:[email protected]>;tag=as70a3ca4e
Call-ID: [email protected]
CSeq: 10 INVITE
User-Agent: Asterisk PBX
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY
Supported: replaces
Contact: <sip:[email protected]>
Content-Length: 0


<------------>
    -- CAPI/ISDN1#02/017959xxxxx-0 is making progress passing it to SIP/fritz-isdn-081fd078
    -- CAPI/ISDN1#02/017959xxxxx-0 is ringing
ts-data*CLI> 
<--- SIP read from 192.168.2.1:5060 --->
CANCEL sip:[email protected] SIP/2.0
Via: SIP/2.0/UDP 192.168.2.1:5060;branch=z9hG4bK5EADB2C0A3D80E1D
From: <sip:[email protected]>;tag=00F6328CDD59BF2D
To: <sip:[email protected]>
Call-ID: [email protected]
CSeq: 10 CANCEL
Proxy-Authorization: Digest username="fritz-isdn", realm="sip.example.info", nonce="6bf595c2", uri="sip:[email protected]", response="84c662e1669fc4a296b9639c3a23f8ae", algorithm=MD5
Reason: Q.850; cause=16; text="(null)"
Max-Forwards: 70
User-Agent: AVM FRITZ!Box Fon Speedport W 900V 34.04.21 (Jul 12 2006)
Supported: 100rel,replaces,timer
Allow-Events: telephone-event,refer
Content-Length: 0


<------------->
--- (13 headers 0 lines) ---
Sending to 192.168.2.1 : 5060 (NAT)

<--- Reliably Transmitting (NAT) to 192.168.2.1:5060 --->
SIP/2.0 487 Request Terminated
Via: SIP/2.0/UDP 192.168.2.1:5060;branch=z9hG4bK5EADB2C0A3D80E1D;received=192.168.2.1
From: <sip:[email protected]>;tag=00F6328CDD59BF2D
To: <sip:[email protected]>;tag=as70a3ca4e
Call-ID: [email protected]
CSeq: 10 INVITE
User-Agent: Asterisk PBX
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY
Supported: replaces
Content-Length: 0


<------------>

<--- Transmitting (NAT) to 192.168.2.1:5060 --->
SIP/2.0 200 OK
Via: SIP/2.0/UDP 192.168.2.1:5060;branch=z9hG4bK5EADB2C0A3D80E1D;received=192.168.2.1
From: <sip:[email protected]>;tag=00F6328CDD59BF2D
To: <sip:[email protected]>;tag=as70a3ca4e
Call-ID: [email protected]
CSeq: 10 CANCEL
User-Agent: Asterisk PBX
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY
Supported: replaces
Contact: <sip:[email protected]>
Content-Length: 0


<------------>
ts-data*CLI> 
Disconnected from Asterisk server
ts-data:/home/ts# asterisk
 
Warum das:
...
canreinvite=yes

Damit müssten dann auch die ports des SpeedPort W900V offen sein, da asterisk die Kontrolle abgibt!

besser: canreinivit=no
 
Ich weiß nicht. Ich hatte das aus den Beispielen übernommen und bisher hat es auch so funktioniert. Ja die Routen sind so gesetzt, dass der Asterisk und der W900V uneingeschränkt miteinander kommunizieren können. Denn nach ein paar Problemen habe ich die Routen so gesetzt, dass alle Teilnehmer in meinem 192.168.1.x-Netz explizit und uneingeschränkt (auch ohne NAT) mit 192.168.2.1 reden dürfen.

Ich habe jetzt das canreinvite auf no gesetzt. Aber leider hat das an meinem Problem nichts geändert.

PS: Aber irgendwie scheinen die Debian-Maintainer gerade etwas neben der Spur bzw. im Stress zu sein. Es geht wohl auf Weihnachten zu. Denn nachdem ich gestern ein Pakete ge-update-t habe, war plötzlich ip_forwarding deaktiviert und konnte mit meinem VPN nicht mehr in die Firma.

Aber ich werde mir auf dem 24C3 mal den Vortrag zu OpenSER antun. Mal sehen was an dem anders/besser/schlechter ist.
 
Zuletzt bearbeitet:
So, ich muss den Beitrag noch einmal pushen.

Ich habe inzwischen verschiede Updates von Debian mitgemacht, d.h. ich bin auf:
- asterisk 1.4.17~dfsg-2etch2
- chan_cap i 1.0.2-1

Aber leider hat sich an meinem Problem nichts geändert.

Ich habe inzwischen herausgefunden, dass der CAPI-Stack nicht richtig initialisiert wird. Er wird immer scheinbar nur ohne Codec, eben dem Codec "unknown" initialisiert. Hiermit scheitert Asterisk selbst an der Konvertierung, weil es den Code "unknown" schlicht nicht kennt - welch ein Wunder.

Asterisk selber schmiert dann mit einem Core-Dump ab, wenn es den Kanal schließen möchte 'ast_channel_close()', denn es scheint keinen Kanal zu geben.

Kurzum entweder öffnet chan_capi den Kanal nicht richtig oder Asterisk selbst verliert ihn intern irgendwo - wo auch immer.

Da ich eigentlich ein Standard Debian nutze, habe ich auch nichst selbst kompiliertes.

Falls jemand einen Tip hat, wäre ich sehr verbunden.
 
Zuletzt bearbeitet:
Um antworten zu können musst du eingeloggt sein.

Zurzeit aktive Besucher

Gesamt: 583 (Mitglieder: 22, Gäste: 561)

Neueste Beiträge

Statistik des Forums

Themen
246,526
Beiträge
2,253,553
Mitglieder
374,359
Neuestes Mitglied
hitko-am
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