[Erledigt] MiVoice Office 400, SIP, autom. Wiedereinwahl

[dg2drf]

@Rangierdraht : Bin zwar nicht der Fragesteller, aber er schrieb was von 6.3 HF1

 

[Rangierdraht]

Das wäre ja die neueste, da sollte das eigentlich nicht mehr passieren.

 

[insidERR]

Nochmal Danke für die ganzen Vorschläge. Hier paar Screenshots. Vielleicht fällt einem noch was auf.
(Hoffe, ich kriege wegen dem übergroßen Post hier keinen Ärger)

@Rangierdraht -> Systemrelease: 6.3 HF1 ; Systemsoftware: 9125d1 vom 10.03.2021 ; WebAdmin: 12.25


-----

-----------------

------------------------------


Bilder gemäß Boardregeln als Vorschaubilder eingebunden by stoney

 

[dg2drf]

Ist der Domänen Name immer Rot oder ist das nur so auf dem Foto?

Bei mir ist er grün....

 

[insidERR]

Ist der Domänen Name immer Rot oder ist das nur so auf dem Foto?

Bei mir ist er grün....

ja, "der Domainname kann nicht aufgelöst werden".
Habe jetzt in der Firewall gesehen, das die Mitel den eingestellten DNS-Server nicht erreichen kann, weil geblockt. Lasse jetzt den Verkehr in beide Richtungen durchgehen. Hat leider nix gebracht.

 

[Rangierdraht]

Prack Support kannst noch löschen, hatte schon einige male Probleme damit.
Aber das hat nichts mit der Registrierung zu tun.
Am besten wäre mal ein Trace in der Phase wo die Registrierung nicht klappt.
Weißt du wie das geht?

 

[insidERR]

Hatte gestern die Anlage von zuhause neu gestartet. Sie ist aber nicht aufgewacht. Keine Reaktion.
Die Adresse lies sich anpingen. Port 80 und 443 waren offen. Die Seite lies sich aber nicht öffnen. Als ob sie nicht da wäre.
Alle Endgeräte waren offline.
Heute Mittag dann hingefahren. Auf dem Display stand was von BOOT. Klang als ob er beim Booten abgeschmiert wäre. Also aus und wieder angemacht. Startete problemlos und läuft seit dem. Nur das mit der Wiedereinwahl klappt weiterhin nicht.
Kann eine alte Konfiguration auf ISDN(deaktiviert) noch irgendwie stören?


@Rangierdraht Das mit dem Trace ist mir nicht bekannt.

Bild gemäß Boardregeln als Vorschaubild eingebunden by stoney

 

[Rangierdraht]

Hallo insidERR,
du mußt mit Putty eine Telnet Verbindung auf Port 1818 aufmachen, dort loggst du dich dann mit deinen Zugangsdaten ein.
Dann 1, Rolling Trace,
3, Individual Rolling Trace
4, drücken damit da dann "on" steht
13, start Trace. Dann laufen die SIP Pakete in Echtzeit durch.
Du mußt dann auf die "Register" Meldungen schauen und evtl. die Ausgabe hier posten.
Am besten du stellst im Putty die Ausgabe in eine Datei ein.
Mit Enter kannst du den Trace beenden.

 

[insidERR]

Hallo @Rangierdraht
Danke für die Erklärung wie man aufzeichnet. Hat super gefunzt.
Hier paar Ausschnitte wo REGISTER vorkommt:

Diese Daten kommen praktischminütlich, obwohl "Bevorzugtes Registrierungs-Intervall" auf 240 eingestellt ist.

SIP 18:26:48.208: TRANSCEIVER : IaSipTransceiverC::handleData() pbxIpAddr is 192.168.3.1:5060:TCP
SIP 18:26:48.209: TRANSCEIVER : LAN > UA: "403 Forbidden (R403_REQUEST_NOT_ALLOWED)" status [5798 OPTIONS] received from [217.0.26.133:5060:TCP]
SIP 18:26:48.209: TRANSCEIVER : SIP/2.0 403 Forbidden (R403_REQUEST_NOT_ALLOWED)
SIP 18:26:48.209: TRANSCEIVER : Via: SIP/2.0/TCP 192.168.3.1;rport=59934;received=195.14*.***.*;branch=z9hG4bK_AI2021May142648194172
SIP 18:26:48.209: TRANSCEIVER : To: <sip:sip-trunk.telekom.de>;tag=11f32086
SIP 18:26:48.209: TRANSCEIVER : From: <sip:sip-trunk.telekom.de>;tag=AIE9F21**********4C23C1
SIP 18:26:48.209: TRANSCEIVER : Call-ID: AIB*********EC6A
SIP 18:26:48.209: TRANSCEIVER : CSeq: 5798 OPTIONS
SIP 18:26:48.209: TRANSCEIVER : Content-Length: 0
SIP 18:26:48.209: TRANSCEIVER :
SIP 18:26:48.210: TRANSCEIVER : Incoming SIP message was not sent through the ALG
SIP 18:26:48.210: UA_SIP_MSG : LAN > UA: "403 Forbidden (R403_REQUEST_NOT_ALLOWED)" status [5798 OPTIONS] received from [217.0.26.133:5060:TCP]
SIP 18:26:48.210: UA_SIP_MSG : SIP/2.0 403 Forbidden (R403_REQUEST_NOT_ALLOWED)
SIP 18:26:48.210: UA_SIP_MSG : Via: SIP/2.0/TCP 192.168.3.1;rport=59934;received=195.14*.***.*;branch=z9hG4bK_AI2021May142648194172
SIP 18:26:48.210: UA_SIP_MSG : To: <sip:sip-trunk.telekom.de>;tag=11f32086
SIP 18:26:48.210: UA_SIP_MSG : From: <sip:sip-trunk.telekom.de>;tag=AIE9F21*********4C23C1
SIP 18:26:48.210: UA_SIP_MSG : Call-ID: AIB**********C6A
SIP 18:26:48.210: UA_SIP_MSG : CSeq: 5798 OPTIONS
SIP 18:26:48.210: UA_SIP_MSG : Content-Length: 0
SIP 18:26:48.210: UA_SIP_MSG :
SIP 18:26:48.211: USER_AGENT : Session not found for incoming STATUS where CSeq="5798 OPTIONS"
SIP 18:26:52.203: USER_AGENT : "non-INVITE Client" transaction failed for "5795 REGISTER"
SIP 18:26:52.203: USER_AGENT : transactionFailed(): TCPonly case is handled in transport layer

Das hier kam ungefähr 2 Minuten nachdem ich das Intervall auf 60 gesetzt habe. Danach war die Anlage wieder registriert.

SIP 18:27:26.242: TRANSPORT : IaSipTransportC::handleData:217.0.26.101:5060:TCP
SIP 18:27:26.242: TRANSCEIVER : IaSipTransceiverC::handleData() pbxIpAddr is 192.168.3.1:5060:TCP
SIP 18:27:26.243: TRANSCEIVER : Incoming SIP message was not sent through the ALG
SIP 18:27:26.244: USER_AGENT : ====== WARNING 38224 [p0=0x00000001, p1=0x0000003c, p2=0x000000f0] ======
SIP 18:27:26.244: UA-ER_IFACE : ?? => UA: updateExtProvider() and reregister its accounts, pId=1, rAddr=[0.0.0.0:5060:TCP], rName='reg.sip-trunk.telekom.de', realm='sip-trunk.telekom.de
pPName='', pPAddr=[0.0.0.0:5060:TCP], sPName='', sPAddr=[0.0.0.0:5060:TCP]
exp=240, EKA='T', FFrC=1, div=2, prfx='T', MOGCT=20, ALG='F', redirect='F'
prefCodec='Unspecified', codecMode='Off', callTransferMode='ReInvite', IdentityHeaderType='PAI', IdentityHeaderContent='SystemClip'
Transport Protocol='TCP', IncomingOrigUrlLocation='FromField', authId='', authPwd='' UsePrimaryProxyAsOutboundProxy='false' IgnoreDisplayName= 'Both'
SIP 18:27:26.245: USER_AGENT : IaSipUserAgentC::handleUpdateExtProvider()
SIP 18:27:26.245: USER_AGENT : IaSipExtRegistrarC::handleUpdateExtRegistrarProvider()
SIP 18:27:26.245: USER_AGENT : IaSipDnsCacheC::FQDN_ListC::kickResolver() myHostName: [reg.sip-trunk.telekom.de]
SIP 18:27:26.250: USER_AGENT : IaSipDnsCacheC::SRV_ListC::kickResolver() mySrvString: [_sip._tcp.reg.sip-trunk.telekom.de]
SIP 18:27:26.252: USER_AGENT : IaSipDnsCacheC::FQDN_ListC::kickResolver() myHostName: [n-ipr-a02.edns.t-ipnet.de]
SIP 18:27:26.255: USER_AGENT : IaSipDnsCacheC::FQDN_ListC::kickResolver() myHostName: [n-ipr-a01.edns.t-ipnet.de]
SIP 18:27:26.257: USER_AGENT : IaSipDnsCacheC::FQDN_ListC::kickResolver() myHostName: [d-ipr-a02.edns.t-ipnet.de]
SIP 18:27:26.260: USER_AGENT : IaSipUserAgentC::sendSipMessage(): Sending a message to clientId [] / sipEpId [None]

Sagt dir das hier etwas?
SIP 20:38:34.290: USER_AGENT : [] CseqMethod(SIP_OPTIONS) StatusCode(200 OK)
SIP 20:38:34.290: USER_AGENT : Session not found for incoming STATUS where CSeq="6320 OPTIONS"
SIP 20:38:34.291: TRANSPORT : [0x9242628]IaSipTcpSocketC::handleSocketData remoteIpAddr is 217.0.26.99:5060:TCP and pbxIpAddr is 192.168.3.1:5060:TCP
SIP 20:38:34.291: TRANSPORT : IaSipTcpSocketC::startInactivityTimer(): Started inactivity timer with 720 sec
SIP 20:38:34.291: TRANSPORT : IaSipTransportC::handleData:217.0.26.99:5060:TCP
SIP 20:38:34.291: TRANSCEIVER : IaSipTransceiverC::handleData() pbxIpAddr is 192.168.3.1:5060:TCP
SIP 20:38:34.292: TRANSCEIVER : LAN > UA: "200 OK" status [6320 OPTIONS] received from [217.0.26.99:5060:TCP]
SIP 20:38:34.292: TRANSCEIVER : SIP/2.0 200 OK
SIP 20:38:34.292: TRANSCEIVER : Via: SIP/2.0/TCP 192.168.3.1;rport=59935;received=195.14*.***.**;branch=z9hG4bK_AI2021May14383426556
SIP 20:38:34.292: TRANSCEIVER : To: <sip:sip-trunk.telekom.de>;tag=ccdc14f6
SIP 20:38:34.292: TRANSCEIVER : From: <sip:sip-trunk.telekom.de>;tag=AI51E9E7F3A35A9C54
SIP 20:38:34.292: TRANSCEIVER : Call-ID: AI540D2DEC31A6D6D0
SIP 20:38:34.292: TRANSCEIVER : Supported: 100rel,gin,path,timer
SIP 20:38:34.292: TRANSCEIVER : CSeq: 6320 OPTIONS
SIP 20:38:34.292: TRANSCEIVER : Accept: application/sdp
SIP 20:38:34.292: TRANSCEIVER : Accept-Encoding: identity
SIP 20:38:34.292: TRANSCEIVER : Allow: ACK, BYE, CANCEL, INFO, INVITE, NOTIFY, OPTIONS, PRACK, PUBLISH, REFER, REGISTER, SUBSCRIBE, UPDATE
SIP 20:38:34.292: TRANSCEIVER : Content-Length: 0

 

[Rangierdraht]

Die Anlage muß ein Register schicken, darauf bekommt sie 2x forbidden und einmal 200ok.
Auf die Options Pakete die sie ständig schickt bekommt sie immer ein forbidden. Das ist das Keepalive, das wird nur gemacht um die Firewall offen zu halten.
Der Registrierungstimer darf bei Telekom so weit ich weiß nicht niedriger als 480 sein.
Du mußt nach dem Register suchen und dir dann die Call ID kopieren, dann kannst du nach der Call ID suchen und findest dann alles was dazu gehört.
Leider sind auch interne SIP Nachrichten dabei von den Telefonen.

 

[insidERR]

Die mit der Suche nach "Register" im Log liefert die Ergebnisse wie oben beschrieben.
Habe jetzt Registierungstimer auf 500 gestellt. Die Anlage war sofort offline und auch noch nach 15 Minuten nicht wieder online.
Dann den Timer auf 60 gestell und nach etwas mehr 2 Minuten war die Anlage wieder online. Der Wert wurde automatisch von 60 auf 240 umgestellt.

 

[Rangierdraht]

Ich hatte dir leider den falschen Weg gezeigt, da sieht man die Register Meldungen nicht.
Hier noch mal der richtige Weg:
3 System Monitor
enter
3 I-Bus - Tier
dann mit den Zahlen 9 (display SIP Reg Msgs), e (extended infoelement decoding) und f (show full SIP message) auf on schalten.
dann o drücken um den Trace zu starten.

Die Anfrage muß so aussehen:

16:16:18.598: SIP: >> 217.10.79.9:5060     :UDP                         MT: REGISTER sip:sipgate.de
         REGISTER sip:sipgate.de SIP/2.0
         Via: SIP/2.0/UDP 192.168.88.44:5060;branch=z9hG4bK_AI2021May1616185971997007168;rport
         To: <sip:[email protected]>
         From: <sip:[email protected]>;tag=AID44E341316C67262
         Call-ID: [email protected]
         CSeq: 727474 REGISTER
         Allow: ACK,BYE,CANCEL,INVITE,NOTIFY,OPTIONS,PUBLISH,UPDATE,REFER
         Allow-Events: presence,dialog,message-summary,refer
         Max-Forwards: 70
         User-Agent: Aastra 400
         Expires: 3000
         Contact: <sip:[email protected]:5060;line=AI919D55B194ABB177>;expires=3000  das ist der Reregistrierungstimer bei mir 3000

         Content-Length: 0

Die Antwort muß so aussehen:

16:16:18.669: SIP: << 217.10.79.9:5060     :UDP                         MT: 200 OK
         SIP/2.0 200 OK
         Via: SIP/2.0/UDP 192.168.88.44:5060;received=91.61.20.3;branch=z9hG4bK_AI2021May1616186341997007169;rport=5060
         To: <sip:[email protected]>;tag=c63713a666d5644779294882ed89253a.f299
         From: <sip:[email protected]>;tag=AI6BED74EE6310E8D4
         Call-ID: [email protected]
         CSeq: 727475 REGISTER
         Contact: <sip:[email protected]:5060;line=AI919D55B194ABB177>;expires=600;received="sip:91.61.20.3:5060" wird von Sipgate auf 600 geändert.
         Content-Length: 0

Bei der Telekom werden immer 3 Server abgefragt, 2 antworten dann mit SIP/2.0 401 Unauthorized

 

[koyaanisqatsi]

Bei der Telekom werden immer 3 Server abgefragt, 2 antworten dann mit SIP/2.0 401 Unauthorized

Wenn es wirklich 3 Server sind, dann müssen alle Drei so auf ein Register antworten.
...denn 401 ist die Aufforderung des Servers an den Klienten zur "Gesichtskontrolle".
Danach sollte der Klient beim nächsten Versuch einen Authorization: Header mit der richtigen Antwort senden.
Nach der 401 vom Server also nochmal...

[May 16 17:36:51] REGISTER sip:192.168.188.9 SIP/2.0
[May 16 17:36:51] Via: SIP/2.0/UDP 192.168.188.1:5060;rport;branch=<hash>
[May 16 17:36:51] From: <sip:[email protected]>;tag=<hash>
[May 16 17:36:51] To: <sip:[email protected]>
[May 16 17:36:51] Call-ID: <hash>@192.168.188.1
[May 16 17:36:51] CSeq: 72 REGISTER
[May 16 17:36:51] Contact: <sip:[email protected];uniq=<hash>>
[May 16 17:36:51] Authorization: Digest username="1005", realm="asterisk", nonce="<hash>", uri="sip:192.168.188.9", response="<hash>", algorithm=MD5            
[May 16 17:36:51] Max-Forwards: 70
[May 16 17:36:51] Expires: 1800
[May 16 17:36:51] User-Agent: AVM FRITZ!Box 7590 (UI) 154.07.27 (May 4 2021)
[May 16 17:36:51] Supported: 100rel,replaces
[May 16 17:36:51] Allow-Events: telephone-event,refer,reg
[May 16 17:36:51] Allow: INVITE,ACK,OPTIONS,CANCEL,BYE,UPDATE,PRACK,INFO,SUBSCRIBE,NOTIFY,REFER,MESSAGE,PUBLISH                                                                             
[May 16 17:36:51] Accept: application/sdp, multipart/mixed
[May 16 17:36:51] Accept-Encoding: identity
[May 16 17:36:51] Content-Length: 0
[May 16 17:36:51]
[May 16 17:36:51] <------------->
[May 16 17:36:51] --- (17 headers 0 lines) ---
[May 16 17:36:51] Sending to 192.168.188.1:5060 (no NAT)
[May 16 17:36:51]
[May 16 17:36:51] <--- Transmitting (no NAT) to 192.168.188.1:5060 --->
[May 16 17:36:51] SIP/2.0 200 OK
[May 16 17:36:51] Via: SIP/2.0/UDP 192.168.188.1:5060;branch=<hash>;received=192.168.188.1;rport=5060                                                                      
[May 16 17:36:51] From: <sip:[email protected]>;tag=<hash>
[May 16 17:36:51] To: <sip:[email protected]>;tag=<hash>
[May 16 17:36:51] Call-ID: <hash>@192.168.188.1
[May 16 17:36:51] CSeq: 72 REGISTER
[May 16 17:36:51] Server: PiBX
[May 16 17:36:51] Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH, MESSAGE                                                                                
[May 16 17:36:51] Supported: replaces, timer
[May 16 17:36:51] Expires: 1800
[May 16 17:36:51] Contact: <sip:[email protected];uniq=<hash>>;expires=1800                                                                                         
[May 16 17:36:51] Date: Sun, 16 May 2021 15:36:50 GMT
[May 16 17:36:51] Content-Length: 0

Achte auf die: CSeq: Nummer [AKTION]
...die gleiche Nummer gibt es immer mindestens zweimal: 1x Klientseitig (Anfrage) und 1x Serverseitig (Antwort)

 

[insidERR]

Hallo @Rangierdraht , @koyaanisqatsi
danke für die Meldungen.
Ich habe es gestern getestet und folgendes ist dabei rum gekommen.
Intervall auf 485 gestellt (dabei wird die Verbindung automatisch gekappt) und >20 Minuten gewartet. -> Nix passiert.
Dann auf 60 geändert und nach ca.2 Minuten war die Anlage wieder online.
Das sind die Auszüge aus dem Log.

Das ist die Anfrage

19:27:41.273: SIP: >> 217.0.26.101:5060 :TCP MT: REGISTER sip:sip-trunk.telekom.de
REGISTER sip:sip-trunk.telekom.de SIP/2.0
Via: SIP/2.0/TCP 192.168.3.1:5060;branch=z9hG4bK_AI2021May172741271+49XXXXXXX144;rport
To: <sip:[email protected]>
From: <sip:[email protected]>;tag=AI8B935B0D02DB0246
Call-ID: [email protected]
CSeq: 20582 REGISTER
Route: <sip:reg.sip-trunk.telekom.de:5060;lr>
Allow: ACK,BYE,CANCEL,INVITE,NOTIFY,OPTIONS,PUBLISH,UPDATE,REFER
Allow-Events: presence,dialog,message-summary,refer
Max-Forwards: 70
User-Agent: Aastra 400
Expires: 0
Contact: <sip:[email protected]:5060;transport=tcp;line=AI2E8B33227F7BC1FA>;expires=0
Content-Length: 0

Darauf die Antwort:

19:27:41.317: SIP: << 217.0.26.101:5060 :TCP MT: 401 Unauthorized
SIP/2.0 401 Unauthorized
Via: SIP/2.0/TCP 192.168.3.1:5060;rport=59942;received=195.12X.XXX.X;branch=z9hG4bK_AI2021May172741271+49XXXXXXX144
To: <sip:[email protected]>;tag=3df226f3
From: <sip:[email protected]>;tag=AI8B935B0D02DB0246
Call-ID: [email protected]
CSeq: 20582 REGISTER
WWW-Authenticate: Digest algorithm=MD5, nonce="588716f1d520b491588716f133487ff18616205c067e649fe26702a449df7699", realm="sip-trunk.telekom.de"
Reason: TSSI;cause=4010001
Content-Length: 0

Weiter unten im Log kommt noch

19:52:17.922: SIP: >> 217.0.26.101:5060 :TCP MT: REGISTER sip:sip-trunk.telekom.de
REGISTER sip:sip-trunk.telekom.de SIP/2.0
Via: SIP/2.0/TCP 192.168.3.1:5060;branch=z9hG4bK_AI2021May175217921+49XXXXXXX149;rport
To: <sip:[email protected]>
From: <sip:[email protected]>;tag=AIC4E353FAD4B9FA61
Call-ID: [email protected]
CSeq: 20748 REGISTER
Route: <sip:reg.sip-trunk.telekom.de:5060;lr>
Allow: ACK,BYE,CANCEL,INVITE,NOTIFY,OPTIONS,PUBLISH,UPDATE,REFER
Allow-Events: presence,dialog,message-summary,refer
Max-Forwards: 70
User-Agent: Aastra 400
Expires: 60
Contact: <sip:[email protected]:5060;transport=tcp;line=AI2E8B33227F7BC1FA>;expires=60
Content-Length: 0

19:52:17.943: SIP: << 217.0.26.101:5060 :TCP MT: 423 Interval Too Brief
SIP/2.0 423 Interval Too Brief
Via: SIP/2.0/TCP 192.168.3.1:5060;rport=59942;received=195.12X.XXX.X;branch=z9hG4bK_AI2021May175217921+49XXXXXXX149
To: <sip:[email protected]>;tag=dfb9e72b
From: <sip:[email protected]>;tag=AIC4E353FAD4B9FA61
Call-ID: [email protected]
CSeq: 20748 REGISTER
Min-Expires: 240
Reason: TSSI;cause=4230001
Content-Length: 0

Danach noch paar Registeranfragen, darauf UNAUTHORISED
Zum Schluss bevor die Registrierung erfolgte und ich darauf den Log gestoppt hatte.

19:52:18.043: SIP: >> 217.0.26.101:5060 :TCP MT: REGISTER sip:sip-trunk.telekom.de
REGISTER sip:sip-trunk.telekom.de SIP/2.0
Via: SIP/2.0/TCP 192.168.3.1:5060;branch=z9hG4bK_AI2021May17521842+49XXXXXXX152;rport
To: <sip:[email protected]>
From: <sip:[email protected]>;tag=AIC5D7CFA7CD8EBC2D
Call-ID: [email protected]
CSeq: 20751 REGISTER
Authorization: Digest username="551131331748",realm="sip-trunk.telekom.de",nonce="d2a35138800ef358d2a3513807533838a37839c34b1de0aafeced8ef749ebb9e",uri="sip:sip-trunk.telekom.de",response="0f1d5b8bf840d957796b0a8fb3050f0d",algorithm=MD5
Route: <sip:reg.sip-trunk.telekom.de:5060;lr>
Allow: ACK,BYE,CANCEL,INVITE,NOTIFY,OPTIONS,PUBLISH,UPDATE,REFER
Allow-Events: presence,dialog,message-summary,refer
Max-Forwards: 70
User-Agent: Aastra 400
Expires: 240
Contact: <sip:[email protected]:5060;transport=tcp;line=AI2E8B33227F7BC1FA>;expires=240
Content-Length: 0

19:52:18.082: SIP: << 217.0.26.101:5060 :TCP MT: 200 OK
SIP/2.0 200 OK
Via: SIP/2.0/TCP 192.168.3.1:5060;rport=59942;received=195.12X.XXX.X;branch=z9hG4bK_AI2021May17521842+49XXXXXXX152
To: <sip:[email protected]>;tag=28b6ef53
From: <sip:[email protected]>;tag=AIC5D7CFA7CD8EBC2D
Call-ID: [email protected]
Contact: <sip:[email protected]:5060;transport=tcp;line=AI2E8B33227F7BC1FA>;expires=240
CSeq: 20751 REGISTER
P-Associated-URI: <sip:[email protected];user=phone>, <sip:[email protected];user=phone>, <sip:[email protected];user=phone>
Reason: TSSI;cause=0
Content-Length: 0

Was mich etwas wundert, ist z.B. dass sich die Anfrage ständig ändert.

Via: SIP/2.0/TCP 192.168.3.1:5060;rport=59942;received=195.12X.XXX.X;branch=z9hG4bK_AI2021May17521842+49XXXXXXX152

Wir haben einen Nummernblock 100-299 bei der Telekom reserviert. Die komplette Nummer der Zentrale lautet z.B. +49 221 123 0 (ist oben durch +49XXXXXXX maskiert)
Die Nummern danach sind die Durchwahlen der Einzelplätze. Die übermittelte Nummer "+49XXXXXXX152" wäre demnach falsch => +49 221 123 0 152 . Hier wäre die eine 0 zu viel in der Nummer

Was mich generell wundert, dass es mit der Registrierung ja grundsätzlich klappt. Aber nur bei einem bestimmten Regintervall, welches dann auf einen auf einen weniger passenden Wert gesetzt wird.

 

[koyaanisqatsi]

Moinsen


Ein Expires: 0 ist ein "Unregister".
...weil es ein explizites "Unregister" nicht gibt ( SIP Logik )


Es wurde ein Expires: von 60 angefordert, das ist dem Server zu wenig und bestimmt, dass das minimal festgelegte Expires: der Serverkonfiguration genommen werden muss.
Der Server hat hier immer das letzte Wort.


Tja, nuh sehen ja From: und To: Header plausibel aus, aber was, zum Donnerwetter, hat die lokale IP im Contact: Header zu suchen?

@sonyKatze - Geht sowas mit der Proxyangabe?

 

[chrsto]

hat die lokale IP im Contact: Header zu suchen?

Das ist korrekt so.

@insidERR hast du eigentlich mal ein Ticket bei Mitel aufgemacht?

 

[insidERR]

@chrsto ne, ich bin ja nur der dumme Endbenutzer. Kann ja sein, dass es nur ein Haken in einem Unter/unter/unter/untermenü ist der gesetzt werden will. Habe auch keinen direkten Kontakt zu Mitel. Bevor ich unseren Dienstleister für teures Geld mobilisiere, frage ich kluge Leute im Forum um Rat. Hier wurde mir schon paar Mal schnell geholfen, als der Dienstleister gesagt hat "das geht nicht"

 

[chrsto]

Ich glaube aber nicht, dass du ohne weiter kommst. Wenn ich dich richtig verstehe, macht die Anlage ja gar nichts mehr, sobald eine Netzwerkunterbrechung da war, korrekt?
Es gibt keinen Haken "Wenn Netzwerk/Internet weg war, verbinde neu: ja/nein". Dafür ist ja das Registrierungsintervall gedacht, bzw. wenn der Switch aus war und Netzwerk wieder da ist, das normale Verhalten.

Aus deine Beiträgen lese ich, dass du sogar insg. 2 Probleme hast:

1. Die Mitel realisiert nicht, dass die Netzwerkverbindung weg ist/war, wenn der Switch an dem sie hängt neustartet, dein Beitrag #7
2. Die Mitel realisiert nicht, dass die Internetverbindung weg ist/war, wenn ein Switch davor neustartet, dein Beitrag #16

Oder sie realisiert es und stellt sich stur

Du könntest noch testen, das Netzwerkkabel an der Mitel zu ziehen (statt eines Switch Reboots) und schauen was dann passiert.

Es gibt auch noch eine interessante Anmerkung von Mitel zum Test mit den Telekom Anschlüssen: "Ein Trennen der Verbindung bei Netzwerkunterbrechungen konnte nicht getestet werden."

 

[insidERR]

Installiert wurde die Anlage Mitte 2020. Angeschlossen war die Mitel bis vor 2 Monaten an einem "AudioCodes" VoIP-ISDN Wandler. Dieser hing an einer eigenen 16MBit Internet/VoIP Leitung. Ohne Firewall oder andre Switche. Diese 16MBit Leitung haben wir jetzt platt gemacht. Vor Monaten aber schon die Mitel von den ISDN Anschlüssel getrennt. Sie verbindet sich seit dem über eine Deutschland LAN Glasfaserleitung mit der Telekom.
Mitel -> SICSO Switch -> UNIFY Switch -> SOPHOS Firewall -> LAN-Glasfaser Wandler -> TelekomNetz
Aufgefallen ist das Problem, als der UNIFY Switch nachts um 4 einen Neustart gemacht hat. Seit dem war externe Telefonie nicht möglich. Ich habe es erst um 8 Uhr morgens gemerkt. Habe die Mitel neu gestartet, dann ging alles wieder.
Dann habe ich diesen Thread eröffnet, weil ich keine Ahnung von der Registrierung/Einwahl habe.

Die Mitel geht offline wenn eine der Komponenten (einer der Switche) neu gestartet wird, ich in der Firewall die Mitel für paar Minuten aussperre(und wieder frei gebe) oder in der Mitel das Registrierungsintevall auf z.B. 240 setze. Dann kann das eingestellte Intervall mehrmals durchlaufen, die Mitel regisitriert sich einfach nicht.
Sobald ich das Intervall dann auf 60 setze, ist die Mitel nach ca.2 Minuten registriert. Das Intervall wird dabei (auf Befehl von der Telekom) auf 240 gesetzt.
Beim nächsten temporären Verbindungsverlust bleibt die Mitel dann wieder getrennt.

Das mit dem Kabel ziehen könnte ich mal ausprobieren. Kann aber einige Tage dauern, da viele Kollegen deutlich später gehen als ich.

 

[Rangierdraht]

Mir gehen da auch so langsam die Ideen aus. Man müsste das Log im Fehlerfall beobachten. Spätestens nach dem Reregistrierungstimer sollte sie es wieder versuchen.
Aber wenn du schon einen Audiocodes hast, dann kauf doch die SIP Lizenzen dafür nach, dann hast du die zusätzliche Absicherung. Was ich so gelernt habe in letzter Zeit ist das auch wirklich anzuraten.
Ich hatte mit der Registrierung auch bei einer Anlage Probleme, hab dann einen Lancom Router als SBC dazwischen geschaltet, seit dem ist Ruhe.
Mit dem Lancom ist das günstiger, weil da bei vielen Routern der Voicecallmanager schon mit drin ist. Die Kanäle sind auch nicht beschränkt. Dafür hat der aber bei weitem nicht so viele Einstellmöglichkeiten.