Mitel Office 400 Umzug zu CompanyFlex ausgehend

[JD168]

Guten Morgen,

wir haben ein Mitel Office 400 im Einsatz. Nun wurden wir zu CompanyFlex umgezogen.
SIP registriert sich und von extern kommen auch Gespräche an. Jedoch kann nicht heraustelefoniert werden.

Welch Einstellung habe ich übersehen, bzw. muss in Verbindung mit CompanyFlex in der Mitel getroffen werden?

Freundliche Grüße
Jens

 

[chrsto]

Das sieht erst mal gut aus, der Fehler muss woanders liegen. Wie sieht das Bündel aus? Wurde ein Mitschnitt erstelle und analysiert?

 

[JD168]

Das freut mich zu lesen. Bündel sieht wie folgt aus. Ein Mitschnitt wurde noch nicht erstellt.

In einem anderen Beitrag habe ich den Hinweis auf "P-Preferred-Identity" gefunden, bei dem eine führende "+" vor der Rufnummer angegeben werden muss. Trifft das auch bei Mitel zu. Falls ja, wo kann ich dies finden?

 

[chrsto]

Du wirst um den Mitschnitt nicht herumkommen, da ich keinen Fehler sehe.

Einfluss auf die PPI nimmst du bei der Anruferkennung des jew. Benutzers, z.B. für Clip-No-Screening. Wichtiger ist aber die PAI, damit die Abrechnung der Telekom richtig funktioniert und nicht alles der -0 zugeordnet wird.

 

[JD168]

Ok, ich habe nun einmal zwei Rufnummer anrufen lassen und die Logdatei dazu gekürzt angehängt.

 

[chrsto]

Ähm ... du erwartest jetzt aber nicht ernsthaft, dass ich für dich 2,5MB Textdateien durchgehen, oder?
Wenn du die Daten so anlieferst, darfst du die gerne selbst analysieren. Ich gucke mir hier maximal einen Mitschnitt (PCAP) in Wireshark an, damit ich filtern kann.

 

[JD168]

Es wird ein falscher contact header übertragen. Hier muss statt der Rufnummer die Registrierungsnummer übertragen werden.
Nun frage ich mich, wo ich dies in der Mitel einstellen kann. Hat jemand einen Tip dazu?

 

[chrsto]

Das machst du oben im 3. Bild unter Contact Feld Typ und dort steht vollkommen korrekt die SIP-ID drin.

 

[JD168]

ok, prima, danke für den Hinweis.
Nun frage ich mich natürlich, wo die Mitel sich die falsche Nummer noch beziehen kann.

 

[chrsto]

Woher kommt denn die Info, dass das nicht stimmt?

 

[JD168]

Woher kommt denn die Info, dass das nicht stimmt?

Telekom Trace und in dem Mitel Log sehe...
SIP 12:58:59.240: UA_SIP_MSG : LAN > UA: "403 Forbidden (R403_REQUEST_NOT_ALLOWED)" status [10281 OPTIONS] received from [217.0.129.180:5060:TCP]

 

[chrsto]

Naja, Forbidden kann erstmal alles heißen. Ich kann nach wie vor keinen Fehler erkennen.

Ist vor der Anlage vielleicht ein Router mit aktivem SIP ALG, der irgendwas verändert?

 

[JD168]

Es ist eine Firewall, allerdings ohne VoIP Profil bzw. aktiven SIP ALG davor.

 

[chrsto]

Dann musst du warten, bis hier noch jemand mit einer Idee vorbei kommt, oder deinen Mitel Partner zu dir bestellen.

Ich habe nochmal alles mit der Anleitung von Mitel abgeglichen und sehe keinen Unterschied. Wenn kein SIP ALG existiert und auch kein weiterer SIP Provider aktiv ist und damit die gehende Rufverteilung fehlerhaft, weiß ich nicht, woran es liegen könnte.

 

[Unglaeubiger]

Von dem SIP-Reg.-Zeugs fehlt mir zwar ganz schön viel Plan,
nur diese IP-Adresse > 217.0.129.180:5060:TCP ist sicher die vom Telekom-DNS-Server, aber nicht die vom Anschluss, nur wie kommt die da rein?
Bei mir aus einem SIP-Trace stand die aktuelle IP-Adresse vom Anschluss drin, aber nicht die vom DNS-Server, da macht wohl irgendwas vor der Anlage etwas verkehrt und der Telekom-SIP-Server kann damit nichts anfangen.
Bei kommenden Gesprächen wäre das vllt. mal zu vergleichen, oder die aktuelle IP-Adresse abzufragen?
Was hängt da eigentlich als GW oder Modem-Router davor?
An welcher Stelle wurde eigentlich der Trace erzeugt, sicher nicht am WAN-/LAN-Port der Anlage, wohl eher weiter davor am Router direkt das was ins öffentliche IP-Netz geht?
Dann vllt. mal das Trace von der Anlage vor dem Router mit-loggen.

 

[chrsto]

Das ist eine IP Adresse eines SIP Servers. Erkennt man auch am Port 5060 dahinter. Und der meckert mit einem 403 Error. Ein DNS Server schickt keine Fehlernummer 403.

Und der Trace ist vom Monitor-Port der Anlage.

 

[Unglaeubiger]

Soll ich jetzt noch dazu einen korrekten Auszug eines funktionalen SIP-Traces dazupacken, damit man das versteht?
Dann versuch doch mal mit der IP-Adresse die lokale Auflösung regional hinzubekommen? Brauchst du aber nicht weil ich das schon vergeblich versucht hatte.
Und diese IP-Adresse 217.X.X.x
ist wie zufällig die vom Telekom-DNS-Server
DNS: 217.237.149.205, 217.237.151.51 < von mir aktuell, aber der DNS Server steht wohl lt. IP-Tabelle in München

Mit dem Eintrag ist ja wohl auch klar dass das nicht von einem SIP-Server auf Telekomseite kommt, und ganz oben 1. Zeile der gleiche Eintrag mit gleicher IP-Adresse (mmtrace_kurz1.txt

Transceive ist ja wohl Senden, und Empfangen tut der Telekom-SIP-Server und meckert dann rum oder nimmt den Ruf gar nicht erst als solchen an oder reicht den Ruf nicht weiter

SIP 15:47:00.006: TRANSCEIVER : transmitSipMessage (217.0.129.182:5060:TCP)

Wenn der Registrar oder interne SIP-Server in der Anlage solchen Quark ausgibt kann es dann auch nicht gehen.
Was die Anlage da falsch macht oder falsch eingestellt ist, wäre dann mal zu suchen warum und wo?
Ursache und Wirkung, die Wikung haben wir aber die Ursache nur ich?

 

[chrsto]

damit man das versteht?

Ich verstehe weder deinen ersten, noch deinen zweiten Beitrag.

 

[Unglaeubiger]

Hast du eigentlich schon mal einen SIP-Trace "zu Fuß" analysiert?
In der TXT-Datei ist doch alles in Klartext lesbar, und die Prinzipien wie eine Kommunikation im SIP abläuft ist doch wohl auch klar?
Mit falscher Absender-Kennung kann der Telekom-SIP-Server nichts anfangen, und dann kommt der Fehler 403, ob der dazu passt ist doch unwichtig, ist ja wie bei MS-OS-Fehlermeldungen würde ich mal behaupten.

Dann soll doch der TO mal bitte einen Trace eines ankommenden Rufes machen, der ja wohl funktioniert.
Dann sehen wir doch wie der Ruf zustande kommt, die IP des Anrufers und die IP der Anlage des eigenen Anschlusses.

 

[chrsto]

#6