Hallo!
Hatte zuerst mal ein Problem via Arcor VOIP herauszuwählen. Das geht nun, näheres findet sich in http://www.ip-phone-forum.de/showthread.php?t=133204
Weil dort dann die Frage nach den Abbrüchen aufkam mache ich mal ein neues Thema dazu. Ich habe versucht den Grund dafür im SIP Trace zu finden und folgendes herausgefunden.
Nachdem die Verbindung einige Zeit sauber steht kommt von Arcor ein lustiges SIP herein:
<-- SIP read from 212.144.24.38:5060:
OPTIONS sip:ARCOR-NUMMER@MEINE-IP SIP/2.0
Via: SIP/2.0/UDP 212.144.24.38:5060;branch=z9hG4bKbbcu7i00bokhlnglk 241sh00000k1.1
To: <sip:MEINE-NUMMER@(vorwahl).sip.arcor.de>;tag=as272e10fc
From: <sip:GERUFENE-NUMMER@(vorwahl).sip.arcor.de>;tag=SD9nnjd99-b1c5672d
Call-ID: 6297c6987f30617755dbc6122141c3e0@(vo...sip.arc or.de
CSeq: 104 OPTIONS
Max-Forwards: 69
Content-Length: 0
Asterisk macht einen Search auf ARCOR-NUMMER@MEINE-IP und findet nix, weshalb es dann folgendes rausschickt:
--- (8 headers 0 lines) ---
Looking for ARCOR-NUMMER in default (domain MEINE-IP)
Transmitting (no NAT) to 212.144.24.38:5060:
SIP/2.0 404 NOT FOUND
Daraufhin kommt von Arcor flugs BYE vorbei und die Verbindung ist weg. Ich habe also einen neuen Kontext angelegt und eingebunden und dort meine Nummer als Extension eingetragen:
[options]
exten => ARCOR-NUMMER,1,NoOp()
Jetzt bekommt Arcor schön sein 200 OK geschickt, die Verbindung hält ungefähr 10 Sekunden länger als vorher. Denn nun folgendes:
<-- SIP read from 212.144.24.38:5060:
MESSAGE sip:ARCOR-NUMMER@MEINE-IP SIP/2.0
Via: SIP/2.0/UDP 212.144.24.38:5060;branch=z9hG4bKbbcu7i00bokhlnglk 241sn0000gk1.1
To: <sip:MEINE-NUMMER@(vorwahl).sip.arcor.de>;tag=as272e10fc
From: <sip:GERUFENE-NUMMER@(vorwahl).sip.arcor.de>;tag=SD9nnjd99-b1c5672d
Call-ID: 6297c6987f30617755dbc6122141c3e0@(vo...sip.arc or.de
CSeq: 105 MESSAGE
Max-Forwards: 69
P-AoC: Info, type=AOC-D
Content-Type: ASN1/aoc
Content-Length: 20
¡~"0
¡0
-----
Der Dreck da drunter scheint mir der Content zur MESSAGE zu sein. Asterisk schickt dann ein nettes
SIP/2.0 415 Unsupported Media Type
und von Arcor kommt wieder ein BYE. Der gerufene Anschluss ist ein ISDN Anschluss, sollte also von sich aus keine SIP Requests schicken.
Hat jemand eine Idee, was ich via extensions.conf auf den OPTIONS Request antworten kann oder wie MESSAGE so zu behandeln ist, dass der Arcor Server damit zufrieden wäre? Reicht ja vielleicht, wenn ich die Message einfach an /dev/null weitergebe. Es sei denn, dass Teil erwartet auch noch eine vernünftige Antwort. Auf jeden Fall braucht es erstmal ein 200 OK, um das heraus finden zu können.
Sieht mir irgendwie nach einem Check für "unterstützte" Endgeräte und Software aus. Oder ist das ein normales Verhalten eines SIP Proxies? Vielleicht ein netter Weg, um das Banner Modul in der Arcor Software mit neuem Inhalt zu beliefern ;-)
Jemand eine Idee?
Hatte zuerst mal ein Problem via Arcor VOIP herauszuwählen. Das geht nun, näheres findet sich in http://www.ip-phone-forum.de/showthread.php?t=133204
Weil dort dann die Frage nach den Abbrüchen aufkam mache ich mal ein neues Thema dazu. Ich habe versucht den Grund dafür im SIP Trace zu finden und folgendes herausgefunden.
Nachdem die Verbindung einige Zeit sauber steht kommt von Arcor ein lustiges SIP herein:
<-- SIP read from 212.144.24.38:5060:
OPTIONS sip:ARCOR-NUMMER@MEINE-IP SIP/2.0
Via: SIP/2.0/UDP 212.144.24.38:5060;branch=z9hG4bKbbcu7i00bokhlnglk 241sh00000k1.1
To: <sip:MEINE-NUMMER@(vorwahl).sip.arcor.de>;tag=as272e10fc
From: <sip:GERUFENE-NUMMER@(vorwahl).sip.arcor.de>;tag=SD9nnjd99-b1c5672d
Call-ID: 6297c6987f30617755dbc6122141c3e0@(vo...sip.arc or.de
CSeq: 104 OPTIONS
Max-Forwards: 69
Content-Length: 0
Asterisk macht einen Search auf ARCOR-NUMMER@MEINE-IP und findet nix, weshalb es dann folgendes rausschickt:
--- (8 headers 0 lines) ---
Looking for ARCOR-NUMMER in default (domain MEINE-IP)
Transmitting (no NAT) to 212.144.24.38:5060:
SIP/2.0 404 NOT FOUND
Daraufhin kommt von Arcor flugs BYE vorbei und die Verbindung ist weg. Ich habe also einen neuen Kontext angelegt und eingebunden und dort meine Nummer als Extension eingetragen:
[options]
exten => ARCOR-NUMMER,1,NoOp()
Jetzt bekommt Arcor schön sein 200 OK geschickt, die Verbindung hält ungefähr 10 Sekunden länger als vorher. Denn nun folgendes:
<-- SIP read from 212.144.24.38:5060:
MESSAGE sip:ARCOR-NUMMER@MEINE-IP SIP/2.0
Via: SIP/2.0/UDP 212.144.24.38:5060;branch=z9hG4bKbbcu7i00bokhlnglk 241sn0000gk1.1
To: <sip:MEINE-NUMMER@(vorwahl).sip.arcor.de>;tag=as272e10fc
From: <sip:GERUFENE-NUMMER@(vorwahl).sip.arcor.de>;tag=SD9nnjd99-b1c5672d
Call-ID: 6297c6987f30617755dbc6122141c3e0@(vo...sip.arc or.de
CSeq: 105 MESSAGE
Max-Forwards: 69
P-AoC: Info, type=AOC-D
Content-Type: ASN1/aoc
Content-Length: 20
¡~"0
¡0
-----
Der Dreck da drunter scheint mir der Content zur MESSAGE zu sein. Asterisk schickt dann ein nettes
SIP/2.0 415 Unsupported Media Type
und von Arcor kommt wieder ein BYE. Der gerufene Anschluss ist ein ISDN Anschluss, sollte also von sich aus keine SIP Requests schicken.
Hat jemand eine Idee, was ich via extensions.conf auf den OPTIONS Request antworten kann oder wie MESSAGE so zu behandeln ist, dass der Arcor Server damit zufrieden wäre? Reicht ja vielleicht, wenn ich die Message einfach an /dev/null weitergebe. Es sei denn, dass Teil erwartet auch noch eine vernünftige Antwort. Auf jeden Fall braucht es erstmal ein 200 OK, um das heraus finden zu können.
Sieht mir irgendwie nach einem Check für "unterstützte" Endgeräte und Software aus. Oder ist das ein normales Verhalten eines SIP Proxies? Vielleicht ein netter Weg, um das Banner Modul in der Arcor Software mit neuem Inhalt zu beliefern ;-)
Jemand eine Idee?