Asterisk als SIP-Client an Swyx-Anlage betreiben für Monitoring
Hallo zusammen,
ich hatte unter diesem Thread versucht, ein Monitoring-System (Check_MK Enterprise 1.2.8p19 auf Debian 8.7 Server) über Asterisk an eine Swyx/T-Com NetPhone-TK-Anlage zu binden. Dies ist mir auch soweit gelungen, ich habe jedoch noch folgendes Problem:
Check_MK erzeugt die Meldung, die mithilfe des Programms "picotts" in eine Wave-Datei umgewandelt wird. Anschließend konvertiert das Programm "sox" die Wave-Datei in eine für Asterisk lesbare Datei um. Anschließend wird ein Call-File erzeugt und Asterisk baut die Verbindung auf. Mein Telefon klingelt, doch wenn ich abnehme, legt das System gleich wieder auf. In der Asterisk-Konsole tauchen mit aktiviertem SIP-Debugging folgende Fehler auf:
Der Monitoring-Server hat die Durchwahl 777 (IP-Adresse 192.168.100.240), die angerufene Nummer ist die 720, die Telefonanlage hat die IP-Adresse 192.168.100.10. Ich kann soviel erkennen, dass es anscheinend Probleme mit dem A-Law-Codec im Zusammenhang mit den abzuspielenden Wave-Dateien gibt. Ich habe schon die T-Com angerufen, doch bisher noch keine Infos erhalten.
Die Datei "sip.conf" sieht in der Peer-Definition so aus:
Alle anderen Werte innerhalb der Datei sind auf Auslieferzustand. Es gibt in der "extensions.conf" nocht einen entsprechenden Wählplan.
Hat jemand einen Tipp für mich?
ich hatte unter diesem Thread versucht, ein Monitoring-System (Check_MK Enterprise 1.2.8p19 auf Debian 8.7 Server) über Asterisk an eine Swyx/T-Com NetPhone-TK-Anlage zu binden. Dies ist mir auch soweit gelungen, ich habe jedoch noch folgendes Problem:
Check_MK erzeugt die Meldung, die mithilfe des Programms "picotts" in eine Wave-Datei umgewandelt wird. Anschließend konvertiert das Programm "sox" die Wave-Datei in eine für Asterisk lesbare Datei um. Anschließend wird ein Call-File erzeugt und Asterisk baut die Verbindung auf. Mein Telefon klingelt, doch wenn ich abnehme, legt das System gleich wieder auf. In der Asterisk-Konsole tauchen mit aktiviertem SIP-Debugging folgende Fehler auf:
[Mar 28 15:02:15] WARNING[29162]: pbx_spool.c:309 safe_append: Unable to set utime on /var/spool/asterisk/outgoing/30081.call: Operation not permitted
-- Attempting call on SIP/720@MON01 for s@Voicealerts:1 (Retry 1)
== Using SIP RTP CoS mark 5
Audio is at 10624
Adding codec 100004 (alaw) to SDP
Adding non-codec 0x1 (telephone-event) to SDP
Reliably Transmitting (no NAT) to 192.168.100.10:5060:
INVITE sip:720@192.168.100.10:5060 SIP/2.0
Via: SIP/2.0/UDP 192.168.100.240:5060;branch=z9hG4bK1eac33b2
Max-Forwards: 70
From: <sip:777@192.168.100.10>;tag=as68d17f68
To: <sip:720@192.168.100.10:5060>
Contact: <sip:777@192.168.100.240:5060>
Call-ID: 7b76576d1f2b345b2d98f81b78db30d2@192.168.100.10
CSeq: 102 INVITE
User-Agent: Asterisk PBX 11.13.1~dfsg-2+deb8u2
Date: Tue, 28 Mar 2017 13:02:15 GMT
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH, MESSAGE
Supported: replaces, timer
Content-Type: application/sdp
Content-Length: 254
v=0
o=root 190450244 190450244 IN IP4 192.168.100.240
s=Asterisk PBX 11.13.1~dfsg-2+deb8u2
c=IN IP4 192.168.100.240
t=0 0
m=audio 10624 RTP/AVP 8 101
a=rtpmap:8 PCMA/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=ptime:20
a=sendrecv
---
<--- SIP read from UDP:192.168.100.10:5060 --->
SIP/2.0 100 Trying
Via: SIP/2.0/UDP 192.168.100.240:5060;branch=z9hG4bK1eac33b2
To: <sip:720@192.168.100.10:5060>
From: <sip:777@192.168.100.10>;tag=as68d17f68
Call-ID: 7b76576d1f2b345b2d98f81b78db30d2@192.168.100.10
CSeq: 102 INVITE
Allow: REGISTER, INVITE, ACK, CANCEL, BYE, NOTIFY, REFER, OPTIONS, INFO, SUBSCRIBE, UPDATE
User-Agent: T-Com IpPbxSrv/10.30.0.283
Content-Length: 0
<------------->
--- (9 headers 0 lines) ---
<--- SIP read from UDP:192.168.100.10:5060 --->
SIP/2.0 180 Ringing
Via: SIP/2.0/UDP 192.168.100.240:5060;branch=z9hG4bK1eac33b2
Contact: <sip:192.168.100.10:5060;transport=udp>
To: "Mustermann, Max"<sip:720@192.168.100.10:5060>;tag=3b02646c
From: <sip:777@192.168.100.10>;tag=as68d17f68
Call-ID: 7b76576d1f2b345b2d98f81b78db30d2@192.168.100.10
CSeq: 102 INVITE
Allow: REGISTER, INVITE, ACK, CANCEL, BYE, NOTIFY, REFER, OPTIONS, INFO, SUBSCRIBE, UPDATE
User-Agent: T-Com IpPbxSrv/10.30.0.283
X-IPPBXAlertType: 0
X-IPPBXRedirected: false
X-IPPBXCalledNumber: 720
X-IPPBXCalledName: Glotzbach, Stephan
X-IPPBXServerCallId: 217195
X-IPPBXServerCallContext: afxwlxhzih38
Content-Length: 0
<------------->
--- (16 headers 0 lines) ---
list_route: hop: <sip:192.168.100.10:5060;transport=udp>
<--- SIP read from UDP:192.168.100.10:5060 --->
SIP/2.0 200 OK
Via: SIP/2.0/UDP 192.168.100.240:5060;branch=z9hG4bK1eac33b2
Contact: <sip:192.168.100.10:5060;transport=udp>
To: "Mustermann, Max"<sip:720@192.168.100.10:5060>;tag=3b02646c
From: <sip:777@192.168.100.10>;tag=as68d17f68
Call-ID: 7b76576d1f2b345b2d98f81b78db30d2@192.168.100.10
CSeq: 102 INVITE
Allow: REGISTER, INVITE, ACK, CANCEL, BYE, NOTIFY, REFER, OPTIONS, INFO, SUBSCRIBE, UPDATE
Content-Type: application/sdp
User-Agent: T-Com IpPbxSrv/10.30.0.283
X-IPPBXServerCallId: 217195
X-IPPBXServerCallContext: afxwlxhzih38
X-IPPBXRedirected: false
X-IPPBXCalledNumber: 720
X-IPPBXCalledName: Glotzbach, Stephan
Content-Length: 281
v=0
o=- 3699694938 3699694939 IN IP4 192.168.100.10
s=pjmedia
c=IN IP4 192.168.100.10
b=AS:84
t=0 0
a=X-nat:0
m=audio 15028 rtp/avp 8 101
b=TIAS:64000
a=rtcp:50013 IN IP4 172.16.20.204
a=sendrecv
a=rtpmap:8 PCMA/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
<------------->
--- (16 headers 14 lines) ---
[Mar 28 15:02:19] WARNING[29138][C-00000000]: chan_sip.c:10067 process_sdp: Unknown RTP profile in audio offer: audio 15028 rtp/avp 8 101
[Mar 28 15:02:19] WARNING[29138][C-00000000]: chan_sip.c:10429 process_sdp: Failing due to no acceptable offer found
list_route: hop: <sip:192.168.100.10:5060;transport=udp>
set_destination: Parsing <sip:192.168.100.10:5060;transport=udp> for address/port to send to
set_destination: set destination to 192.168.100.10:5060
Transmitting (no NAT) to 192.168.100.10:5060:
ACK sip:192.168.100.10:5060;transport=udp SIP/2.0
Via: SIP/2.0/UDP 192.168.100.240:5060;branch=z9hG4bK288bfd07
Max-Forwards: 70
From: <sip:777@192.168.100.10>;tag=as68d17f68
To: <sip:720@192.168.100.10:5060>;tag=3b02646c
Contact: <sip:777@192.168.100.240:5060>
Call-ID: 7b76576d1f2b345b2d98f81b78db30d2@192.168.100.10
CSeq: 102 ACK
User-Agent: Asterisk PBX 11.13.1~dfsg-2+deb8u2
Content-Length: 0
---
set_destination: Parsing <sip:192.168.100.10:5060;transport=udp> for address/port to send to
set_destination: set destination to 192.168.100.10:5060
Reliably Transmitting (no NAT) to 192.168.100.10:5060:
BYE sip:192.168.100.10:5060;transport=udp SIP/2.0
Via: SIP/2.0/UDP 192.168.100.240:5060;branch=z9hG4bK3c91143f
Max-Forwards: 70
From: <sip:777@192.168.100.10>;tag=as68d17f68
To: <sip:720@192.168.100.10:5060>;tag=3b02646c
Call-ID: 7b76576d1f2b345b2d98f81b78db30d2@192.168.100.10
CSeq: 103 BYE
User-Agent: Asterisk PBX 11.13.1~dfsg-2+deb8u2
X-Asterisk-HangupCause: Bearer capability not available
X-Asterisk-HangupCauseCode: 58
Content-Length: 0
---
Scheduling destruction of SIP dialog '7b76576d1f2b345b2d98f81b78db30d2@192.168.100.10' in 6400 ms (Method: INVITE)
Scheduling destruction of SIP dialog '7b76576d1f2b345b2d98f81b78db30d2@192.168.100.10' in 6400 ms (Method: INVITE)
[Mar 28 15:02:19] NOTICE[30087]: pbx_spool.c:389 attempt_thread: Call failed to go through, reason (1) Hangup
[Mar 28 15:02:19] WARNING[30087]: pbx_spool.c:309 safe_append: Unable to set utime on /var/spool/asterisk/outgoing/30081.call: Operation not permitted
<--- SIP read from UDP:192.168.100.10:5060 --->
SIP/2.0 200 OK
Via: SIP/2.0/UDP 192.168.100.240:5060;branch=z9hG4bK3c91143f
Contact: <sip:192.168.100.10:5060;transport=udp>
To: <sip:720@192.168.100.10:5060>;tag=3b02646c
From: <sip:777@192.168.100.10>;tag=as68d17f68
Call-ID: 7b76576d1f2b345b2d98f81b78db30d2@192.168.100.10
CSeq: 103 BYE
Allow: REGISTER, INVITE, ACK, CANCEL, BYE, NOTIFY, REFER, OPTIONS, INFO, SUBSCRIBE, UPDATE
User-Agent: T-Com IpPbxSrv/10.30.0.283
Content-Length: 0
<------------->
--- (10 headers 0 lines) ---
Really destroying SIP dialog '7b76576d1f2b345b2d98f81b78db30d2@192.168.100.10' Method: INVITE
Der Monitoring-Server hat die Durchwahl 777 (IP-Adresse 192.168.100.240), die angerufene Nummer ist die 720, die Telefonanlage hat die IP-Adresse 192.168.100.10. Ich kann soviel erkennen, dass es anscheinend Probleme mit dem A-Law-Codec im Zusammenhang mit den abzuspielenden Wave-Dateien gibt. Ich habe schon die T-Com angerufen, doch bisher noch keine Infos erhalten.
Die Datei "sip.conf" sieht in der Peer-Definition so aus:
[MON01]
type = peer
username = 777
fromuser = 777
fromdomain = 192.168.100.10
canreinvite = no
callbackextension = 777
registertimeout = 120
remotesecret = 777
directmedia = yes
qualify = yes
dtmfmode = rfc2833
insecure = port,invite
host = 192.168.100.10
port = 5060
disallow = all
allow = alaw
Alle anderen Werte innerhalb der Datei sind auf Auslieferzustand. Es gibt in der "extensions.conf" nocht einen entsprechenden Wählplan.
Hat jemand einen Tipp für mich?
Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 333445
Url: https://administrator.de/forum/asterisk-als-sip-client-an-swyx-anlage-betreiben-fuer-monitoring-333445.html
Ausgedruckt am: 26.12.2024 um 19:12 Uhr
5 Kommentare
Neuester Kommentar
Ich vermute, die Asterisk stört sich daran, dass von der Swyx-Anlage im Media-Element im SDP-Teil das Casing nicht eingehalten wird.
Eigentlich sind die Werte "Case-Significant" und demzufolge ist "rtp/avp" etwas anderes als "RTP/AVP".
Deshalb bekommt die Asterisk keine gültige Media-Destination zusammen (denn es gibt dadurch keinen gültigen Media-Teil) und hat keine nutzbaren Codecs.
Versuche mal bitte, in der Asterisk im [general]-Teil der sip.conf folgende Zeile hinzuzufügen:
Eventuell wird dann der SDP korrekt geparsed und du bekommst eine Audioverbindung.
Eigentlich sind die Werte "Case-Significant" und demzufolge ist "rtp/avp" etwas anderes als "RTP/AVP".
Deshalb bekommt die Asterisk keine gültige Media-Destination zusammen (denn es gibt dadurch keinen gültigen Media-Teil) und hat keine nutzbaren Codecs.
Versuche mal bitte, in der Asterisk im [general]-Teil der sip.conf folgende Zeile hinzuzufügen:
[general]
...
pedantic=no
Eventuell wird dann der SDP korrekt geparsed und du bekommst eine Audioverbindung.
Es scheint, dass auch der ausgeschaltete "pedantic"-Modus da nichts ausrichtet.
Laut dem Sourcecode wird tatsächlich Case-Sensitive/Binärsicher geprüft:
Und da haben die Asterisk-Leute nicht ganz unrecht - denn im Standard (RFC 4317) steht auf Seite 7 geschrieben, dass der Value üblicherweise Case-Sensitive ist. Und in allen Beispielen im RFC finden sich ausschließlich "RTP/AVP" in Großbuchstaben.
Setze dich da am Besten mal mit dem Hersteller eurer Telefonanlage in Verbindung und frage mal nach, ob die das nicht mal anpassen mögen.
Natürlich ist es nicht schön, dass sich die Asterisk da jetzt so dermaßen anstellt, aber andererseits ist das auch einfach ein Fehler.
Nachtrag:
Natürlich könnte man jetzt auch eine Asterisk nehmen und an dieser Stelle die Verwendungen von "strcmp" durch "strcasecmp" ersetzen, welches Case-Insensitive prüft. Aber das kann andere Implikationen haben...
Nachtrag 2:
Ich habe gerade auf meiner heimischen Asterisk einen solchen SDP reingeworfen und die exakt gleiche Fehlermeldung wie du bekommen. Passe ich das "rtp/avp" auf Großbuchstaben an geht es. Es liegt also definitiv und nachgetestet genau daran.
Laut dem Sourcecode wird tatsächlich Case-Sensitive/Binärsicher geprüft:
} else if (strcmp(protocol, "RTP/AVP") && strcmp(protocol, "RTP/AVPF")) {
ast_log(LOG_WARNING, "Unknown RTP profile in audio offer: %s\n", m);
continue;
}
Und da haben die Asterisk-Leute nicht ganz unrecht - denn im Standard (RFC 4317) steht auf Seite 7 geschrieben, dass der Value üblicherweise Case-Sensitive ist. Und in allen Beispielen im RFC finden sich ausschließlich "RTP/AVP" in Großbuchstaben.
Setze dich da am Besten mal mit dem Hersteller eurer Telefonanlage in Verbindung und frage mal nach, ob die das nicht mal anpassen mögen.
Natürlich ist es nicht schön, dass sich die Asterisk da jetzt so dermaßen anstellt, aber andererseits ist das auch einfach ein Fehler.
Nachtrag:
Natürlich könnte man jetzt auch eine Asterisk nehmen und an dieser Stelle die Verwendungen von "strcmp" durch "strcasecmp" ersetzen, welches Case-Insensitive prüft. Aber das kann andere Implikationen haben...
Nachtrag 2:
Ich habe gerade auf meiner heimischen Asterisk einen solchen SDP reingeworfen und die exakt gleiche Fehlermeldung wie du bekommen. Passe ich das "rtp/avp" auf Großbuchstaben an geht es. Es liegt also definitiv und nachgetestet genau daran.