diemilz
Goto Top

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:

[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?

Content-ID: 333445

Url: https://administrator.de/contentid/333445

Ausgedruckt am: 24.11.2024 um 23:11 Uhr

LordGurke
LordGurke 28.03.2017 aktualisiert um 19:06:46 Uhr
Goto Top
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:
[general]
...
pedantic=no

Eventuell wird dann der SDP korrekt geparsed und du bekommst eine Audioverbindung.
diemilz
diemilz 29.03.2017 um 08:19:32 Uhr
Goto Top
Hat leider nichts gebracht, die Fehlermeldung ist die gleiche. Ist Asterisk hier so empfindlich, dass es zwingend Groß- und Kleinschreibung unterscheiden muss?
LordGurke
LordGurke 30.03.2017 aktualisiert um 23:30:21 Uhr
Goto Top
Es scheint, dass auch der ausgeschaltete "pedantic"-Modus da nichts ausrichtet.
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.
diemilz
diemilz 31.03.2017 aktualisiert um 15:24:16 Uhr
Goto Top
Ich versuche das noch mit T-Com zu klären, was wir auf Seiten der Telefonanlage für Möglichkeiten haben.

Auf Seiten Asterisk müsste ich also die betroffenen Codezeilen oben anpassen und dann prüfen, ob es läuft? Gibt es keinerlei Konfigurationsparameter, die diese Prüfung "abschwächen", damit es doch funktioniert oder kann man diesen Parameter umschreiben, bevor Asterisk die Daten erhält?

Ich muss auch mal saublöd fragen: Der Media-Offer stammt doch von dem Client/Telefon, von wo aus der Anruf angenommen wird und nicht von der Anlage, richtig?
diemilz
diemilz 05.04.2017 um 13:27:00 Uhr
Goto Top
So, ich konnte Asterisk nun endlich dazu bewegen, mit der NetPhone zu kommunizieren. Der hier genannte Fehler entsteht, wenn ich mit meinem Mobile-Client auf meinem SmartPhone den Anruf annehme. Er bleibt aber auch erstmal auf unbestimmte Zeit bestehen, denn weder T-Com noch Swyx sehen da Handlungsbedarf, da es sich bei den Mobile-Clients von Swyx um "keine richtigen SIP-Clients" handelt und bei Swyx sich keiner für Case-Sensitive interessiert. Änderungen sollen immer bei den 3rd-Party-Clients gemacht werden, das sei auch bekannt. So die Aussage der T-Com.

Zwar funktioniert jetzt dennoch soweit alles, aber ich bin dennoch enttäuscht über Swyx/T-Com, dass die so eine Aussage treffen.