OpenCom X320 - VoIP am Telekom SIP-Trunk

maba001

Neuer User
Mitglied seit
20 Aug 2019
Beiträge
10
Punkte für Reaktionen
0
Punkte
1
Hallo zusammen,

ich habe dieses Forum rauf und runter nach einer Anleitung durchsucht, die beschreibt, wie die OpenCom X320 via DSL am Telekom SIP-Trunk zu konfigurieren ist. Es gibt dafür mehrere Hinweise, bei mir tut es aber trotz inzwischen längeren Versuchen nicht. Weder eingehende noch ausgehende Anrufe funktionieren im reinen IP-Betrieb. Beide Richtungen funktionieren, wenn die OpenCOM X320 über die S0 Schnittstelle betrieben wird.

Symptom:
  • Telefonie --> SIP-Leitungen --> SIP-Leitung ausgeschaltet ==> Betrieb via S0 = ein- / ausgehend funktioniert
  • Telefonie --> SIP-Leitungen --> SIP-Leitung eingeschaltet ==> Betrieb via IP direkt zum SIP-Trunk = ein- / ausgehend FEHLER
    Eingehend: dreifacher Ton di-da-di, kurze Pause, Besetzt Piepser
SW-Info der OpenCOM:
Code:
* Filename: /dahlem/trace/trace2.txt
* DateTime: Tue Aug 20 21:13:02 2019
* --------- Hardware Info
* SerialNr: SN100-09462007162F3
* Board   : OpenCom X320(OCX320), dahlem OCX
* --------- Software Info
* Revision: R 1.618 mitel-ocx
* Release : 12.1 SP4
* Comment :
* BuildNr : 0x0C42
Log des Verbindungsaufbaus (sieht OK aus):
Code:
21:01:58.11 aw_worker.0: Set VT-Trace to level 3
21:01:58.11 aw_worker.0: Set SIP-Trace Level 2
21:01:58.12 ZGS_SIP: <21:01:58.123>--------------------------------------------------------------
21:01:58.12 ZGS_SIP: MESS-Level 3 gesetzt!
21:01:59.33 CI: ---CI--20082019-21:01:59.335-------------------------------------------------------------
21:01:59.33 CI: Prim:I7D2R(0xA110) 0x010030(ZGS_D3) ZGS(02:Line-ISDN)->CI-GL Idx:0 Trid:2/0xFFFF
21:01:59.33 CI: opt. Elemente: 0
21:01:59.33 CI: TEI:      0x00
21:02:04.37 CI: ---CI--20082019-21:02:04.374-------------------------------------------------------------
21:02:04.37 CI: Prim:I7D2E(0xA111) 0x010030(ZGS_D3) ZGS(02:Line-ISDN)->CI-GL Idx:0 Trid:2/0xFFFF
21:02:04.37 CI: opt. Elemente: 0
21:02:04.37 CI: TEI:      0x00
21:02:14.37 CI: ---CI--20082019-21:02:14.375-------------------------------------------------------------
21:02:14.37 CI: Prim:I7D2R(0xA110) 0x010030(ZGS_D3) ZGS(02:Line-ISDN)->CI-GL Idx:0 Trid:2/0xFFFF
21:02:14.37 CI: opt. Elemente: 0
21:02:14.37 CI: TEI:      0x00
21:02:19.41 CI: ---CI--20082019-21:02:19.415-------------------------------------------------------------
21:02:19.41 CI: Prim:I7D2E(0xA111) 0x010030(ZGS_D3) ZGS(02:Line-ISDN)->CI-GL Idx:0 Trid:2/0xFFFF
21:02:19.41 CI: opt. Elemente: 0
21:02:19.41 CI: TEI:      0x00
21:02:26.05 ZGS_SIP: --21:02:26.053--------------------------------------------------------
21:02:26.05 ZGS_SIP: (LoPo 19, Task 22) Zust SIPM_TE_Registered, SIP_LINE_CHECK_TIMER(0xD812)
21:02:26.06 ZGS_SIP: <21:02:26.059>-TX(488 Bytes)--SIP--TCP-IP:217.0.26.197----Dest:5060--Src:10690--
21:02:26.06 ZGS_SIP: OPTIONS sip:sip-trunk.telekom.de SIP/2.0
21:02:26.06 ZGS_SIP: Via: SIP/2.0/TCP 192.168.1.254:10690;branch=z9hG4bK255_OPTIONS;rport
21:02:26.06 ZGS_SIP: From: <sip:[email protected]>;tag=9fxced225sl
21:02:26.06 ZGS_SIP: To: <sip:[email protected]>
21:02:26.06 ZGS_SIP: Call-ID: [email protected]
21:02:26.06 ZGS_SIP: CSeq: 255 OPTIONS
21:02:26.06 ZGS_SIP: Contact: <sip:[email protected]:10690;transport=tcp>;reg-id=1;+sip.instance="<urn:uuid:7B4
21:02:26.06 ZGS_SIP: E031F-F2AD-4D3B-A823-D0B309A8573F>"
21:02:26.06 ZGS_SIP: Max-Forwards: 70
21:02:26.06 ZGS_SIP: User-Agent: OpenCom X320 (R 1.618 mitel-ocx)
21:02:26.06 ZGS_SIP: Content-Length: 0
21:02:26.11 ZGS_SIP: <21:02:26.119>-RX(498 Bytes)--SIP--TCP-IP:217.0.26.197----Dest:10690-Src:5060---
21:02:26.12 ZGS_SIP: SIP/2.0 200 OK
21:02:26.12 ZGS_SIP: Via: SIP/2.0/TCP 192.168.1.254:10690;rport=10690;received=93.240.102.100;branch=z9hG4bK255_OPTIONS
21:02:26.12 ZGS_SIP: To: <sip:[email protected]>;tag=747c60fe
21:02:26.12 ZGS_SIP: From: <sip:[email protected]>;tag=9fxced225sl
21:02:26.12 ZGS_SIP: Call-ID: [email protected]
21:02:26.12 ZGS_SIP: Supported: 100rel,gin,path,timer
21:02:26.12 ZGS_SIP: CSeq: 255 OPTIONS
21:02:26.12 ZGS_SIP: Accept: application/sdp
21:02:26.12 ZGS_SIP: Accept-Encoding: identity
21:02:26.12 ZGS_SIP: Allow: ACK, BYE, CANCEL, INFO, INVITE, NOTIFY, OPTIONS, PRACK, PUBLISH, REFER, REGISTER, SUBSCRIBE,
21:02:26.12 ZGS_SIP: UPDATE
21:02:26.12 ZGS_SIP: Content-Length: 0
Log eines Calls (FEHLER):
Code:
21:46:03.11 ZGS_SIP: <21:46:03.116>-RX(1108 Bytes)-SIP--TCP-IP:217.0.26.197----Dest:10690-Src:5060---
21:46:03.11 ZGS_SIP: INVITE sip:[email protected]:10690;transport=tcp SIP/2.0
21:46:03.12 ZGS_SIP: Via: SIP/2.0/TCP 217.0.26.197:5060;branch=z9hG4bK4ce49021a1b9efd9e0b06cc5f1cdcf90.5c65a798
21:46:03.12 ZGS_SIP: Record-Route: <sip:reg.sip-trunk.telekom.de;transport=tcp;lr>
21:46:03.12 ZGS_SIP: Max-Forwards: 61
21:46:03.12 ZGS_SIP: To: <sip:[email protected];user=phone>
21:46:03.12 ZGS_SIP: From: <sip:[email protected];user=phone>;tag=98603a04
21:46:03.12 ZGS_SIP: Call-ID: [email protected]
21:46:03.12 ZGS_SIP: Contact: <sip:1O/iw[email protected]th1>
21:46:03.12 ZGS_SIP: Supported: from-change,histinfo,resource-priority
21:46:03.12 ZGS_SIP: CSeq: 6905024 INVITE
21:46:03.12 ZGS_SIP: Allow: ACK, BYE, CANCEL, INFO, INVITE, NOTIFY, OPTIONS, PRACK, REGISTER, UPDATE
21:46:03.12 ZGS_SIP: P-Asserted-Identity: <sip:[email protected];user=phone>
21:46:03.12 ZGS_SIP: P-Called-Party-ID: <sip:[email protected];user=phone>
21:46:03.12 ZGS_SIP: Content-Type: application/sdp
21:46:03.12 ZGS_SIP: Content-Disposition: session
21:46:03.12 ZGS_SIP: Content-Length: 231
21:46:03.12 ZGS_SIP: v=0
21:46:03.12 ZGS_SIP: o=- 7849248 7849248 IN IP4 217.0.26.197
21:46:03.13 ZGS_SIP: s=on transit
21:46:03.13 ZGS_SIP: c=IN IP4 217.0.133.185
21:46:03.13 ZGS_SIP: t=0 0
21:46:03.13 ZGS_SIP: m=audio 21404 RTP/AVP 9 8 0 102 101
21:46:03.13 ZGS_SIP: a=rtpmap:102 G726-32/8000
21:46:03.13 ZGS_SIP: a=rtpmap:101 telephone-event/8000
21:46:03.13 ZGS_SIP: a=fmtp:101 0-15
21:46:03.13 ZGS_SIP: a=sendrecv
21:46:03.13 ZGS_SIP: a=ptime:20
21:46:03.13 ZGS_SIP: ----- Find_Linkid(socket 5012)...
21:46:03.14 ZGS_SIP: check account link 482 found proxy 217.0.26.197:5060
21:46:03.14 ZGS_SIP: check account link 482 ([email protected])...
21:46:03.14 ZGS_SIP: invalid state von link 482: 999
21:46:03.14 ZGS_SIP: check account link 514 found proxy 217.0.26.197:5060
21:46:03.14 ZGS_SIP: check account link 514 ([email protected])...
21:46:03.14 ZGS_SIP:  A5. cmp requri_comp_value '+49xxxxyyyyyy' with requri_username '+49xxxxyyyyyy' (leftside)
21:46:03.14 ZGS_SIP: csip_find_linkid() get '514' -----
21:46:03.14 ZGS_SIP: found 2 counter 2
21:46:03.14 ZGS_SIP: sipte_setup_ind() State:0 Callid:714 Trid:19/0xFFF3
21:46:03.15 ZGS_SIP: SIPU_filter_attributes(dont_filter=FALSE), Profil:
21:46:03.15 ZGS_SIP: 0:             PCMA/8000
21:46:03.15 ZGS_SIP: 1:             G729/8000
21:46:03.15 ZGS_SIP: 2:             PCMU/8000
21:46:03.15 ZGS_SIP: 3:                     ?
21:46:03.15 ZGS_SIP: 4:                     ?
21:46:03.15 ZGS_SIP: 5:                     ?
21:46:03.15 ZGS_SIP: 6:                     ?
21:46:03.15 ZGS_SIP: 7:                     ?
21:46:03.15 ZGS_SIP: 8:                     ?
21:46:03.15 ZGS_SIP: 9:                     ?
21:46:03.16 ZGS_SIP: vor Filterung:
21:46:03.16 ZGS_SIP:  0:    RM_CODECTYPE_G711A, PT:  8, RTP:(217.0.133.185:21404, sendrecv)
21:46:03.16 ZGS_SIP:  1:    RM_CODECTYPE_G711U, PT:  0, RTP:(217.0.133.185:21404, sendrecv)
21:46:03.16 ZGS_SIP: nach Filterung:
21:46:03.16 ZGS_SIP:  0:    RM_CODECTYPE_G711A, PT:  8, RTP:(217.0.133.185:21404, sendrecv)
21:46:03.16 ZGS_SIP:  1:    RM_CODECTYPE_G711U, PT:  0, RTP:(217.0.133.185:21404, sendrecv)
21:46:03.17 ZGS_SIP: get_rmid() failed State:0 Callid:714 Trid:19/0xFFF3
21:46:03.17 ZGS_SIP: <21:46:03.178>-TX(435 Bytes)--SIP--TCP-IP:217.0.26.197----Dest:5060--Src:10690--
21:46:03.17 ZGS_SIP: SIP/2.0 480 Temporarily not available
21:46:03.17 ZGS_SIP: Via: SIP/2.0/TCP 217.0.26.197:5060;branch=z9hG4bK4ce49021a1b9efd9e0b06cc5f1cdcf90.5c65a798
21:46:03.18 ZGS_SIP: From: <sip:[email protected];user=phone>;tag=98603a04
21:46:03.18 ZGS_SIP: To: <sip:[email protected];user=phone>;tag=9fxced271sl
21:46:03.18 ZGS_SIP: Call-ID: [email protected]
21:46:03.18 ZGS_SIP: CSeq: 6905024 INVITE
21:46:03.18 ZGS_SIP: User-Agent: OpenCom X320 (R 1.618 mitel-ocx)
21:46:03.18 ZGS_SIP: Warning: 399 adapt "get_rmid failed"
21:46:03.18 ZGS_SIP: Content-Length: 0
mitel_config1.png
 
Zuletzt bearbeitet:

chrsto

Mitglied
Mitglied seit
8 Sep 2010
Beiträge
323
Punkte für Reaktionen
12
Punkte
18
Beim Präfix für Rufnummer kommend fehlt 'ne 0 und wenn du ein Fax nutzt, sollte der Haken noch raus, hat aber beides nichts mit deinem Problem zu tun.

Hast du auch die Anrufverteilung Kommend DDI / Gehend DDI bearbeitet und Einträge erstellt?
Hast du den Sip Trunk auch im Leitweg eingetragen?
 

maba001

Neuer User
Mitglied seit
20 Aug 2019
Beiträge
10
Punkte für Reaktionen
0
Punkte
1
Hallo chrsto,

erstens: vielen Dank für die 2 Konfigurationshinweise.

Mein Ziel ist zunächst mal, "Kommend" hinzubekommen. Deshalb ist im Moment nur "Kommend DDI" konfiguriert. Dort sind drei Einträge drin.
Im Leitweg habe ich den Eintrag auch gemacht, aber noch nicht in "Gehend DDI".

2019-08-21 09_05_57-OpenCom X320.png

Jeweils die gleiche Nummer
- Eintrag 1: 0049 .... * (internationales Format)
- Eintrag 2: 07... * (nationales Format)
- Eintrag 3: 4 ... * (nur Ortsnetz)

Noch ein Detail: ich hatte zuerst die Codecs im Verdacht und habe deshalb zum "Standard", den Codec G711u hinzugefügt (das u soll das Mü darstellen). Das kann ich aber auch wieder rausnehmen.

DM41: 2 Beiträge zusammengeführt. Bei Ergänzungen bitte editieren.
 
Zuletzt bearbeitet von einem Moderator:

chrsto

Mitglied
Mitglied seit
8 Sep 2010
Beiträge
323
Punkte für Reaktionen
12
Punkte
18
Wenn du in den Providereinstellungen DID: username take from auf "Input control" gestellt hast und den Wert P-Called-Party-ID eingetragen hast, reicht das int. Format (0049......)

Den Codec kannst du wieder rausnehmen. Telekom macht nur 711a.
 

maba001

Neuer User
Mitglied seit
20 Aug 2019
Beiträge
10
Punkte für Reaktionen
0
Punkte
1
Die Provider-Einstellungen habe ich an dieser Stelle nicht vom Standard, den Mitel ausliefert, abgeändert. Sollte dort noch etwas eingestellt werden?

2019-08-21 09_58_44-OpenCom X320.png
 

chrsto

Mitglied
Mitglied seit
8 Sep 2010
Beiträge
323
Punkte für Reaktionen
12
Punkte
18
Der Rest ist ok.
 

maba001

Neuer User
Mitglied seit
20 Aug 2019
Beiträge
10
Punkte für Reaktionen
0
Punkte
1
VoIP Profil "Standard" hat jetzt wieder nur die zwei ursprünglichen Protokolle.

Login bei Telekom SIP-Trunk ist in Ordnung.

Code:
12:47:28.53 ZGS_SIP: vor Filterung:
12:47:28.53 ZGS_SIP:  0:     RM_CODECTYPE_G729, PT: 18, RTP:(217.0.132.38:17262, sendrecv)
12:47:28.53 ZGS_SIP:  1:    RM_CODECTYPE_G711A, PT:  8, RTP:(217.0.132.38:17262, sendrecv)
12:47:28.53 ZGS_SIP: nach Filterung:
12:47:28.53 ZGS_SIP:  0:     RM_CODECTYPE_G729, PT: 18, RTP:(217.0.132.38:17262, sendrecv)
12:47:28.53 ZGS_SIP:  1:    RM_CODECTYPE_G711A, PT:  8, RTP:(217.0.132.38:17262, sendrecv)
12:47:28.54 ZGS_SIP: get_rmid() failed State:0 Callid:1066 Trid:19/0xFFFE
12:47:28.55 ZGS_SIP: <12:47:28.551>-TX(437 Bytes)--SIP--TCP-IP:217.0.26.197----Dest:5060--Src:10690--
12:47:28.55 ZGS_SIP: SIP/2.0 480 Temporarily not available
12:47:28.55 ZGS_SIP: Via: SIP/2.0/TCP 217.0.26.197:5060;branch=z9hG4bKc809f5e032defa06ce09acd2af7ed070.7ba3f580
12:47:28.55 ZGS_SIP: From: <sip:[email protected];user=phone>;tag=841496a8
12:47:28.55 ZGS_SIP: To: <sip:[email protected];user=phone>;tag=9fxced329sl
12:47:28.55 ZGS_SIP: Call-ID: [email protected]
12:47:28.55 ZGS_SIP: CSeq: 31204620 INVITE
12:47:28.55 ZGS_SIP: User-Agent: OpenCom X320 (R 1.618 mitel-ocx)
12:47:28.55 ZGS_SIP: Warning: 399 adapt "get_rmid failed"
12:47:28.55 ZGS_SIP: Content-Length: 0
12:47:28.60 ZGS_SIP: <12:47:28.603>-RX(394 Bytes)--SIP--TCP-IP:217.0.26.197----Dest:10690-Src:5060---
12:47:28.60 ZGS_SIP: ACK sip:[email protected]:10690;transport=tcp SIP/2.0
12:47:28.60 ZGS_SIP: Via: SIP/2.0/TCP 217.0.26.197:5060;branch=z9hG4bKc809f5e032defa06ce09acd2af7ed070.7ba3f580
12:47:28.60 ZGS_SIP: Max-Forwards: 62
12:47:28.60 ZGS_SIP: To: <sip:[email protected];user=phone>;tag=9fxced329sl
12:47:28.60 ZGS_SIP: From: <sip:[email protected];user=phone>;tag=841496a8
12:47:28.60 ZGS_SIP: Call-ID: [email protected]
12:47:28.60 ZGS_SIP: CSeq: 31204620 ACK
12:47:28.60 ZGS_SIP: Content-Length: 0
12:47:58.28 ZGS_SIP: --12:47:58.283--------------------------------------------------------
12:47:58.28 ZGS_SIP: (LoPo 19, Task 29) Zust SIPM_TE_Registered, SIP_LINE_CHECK_TIMER(0xD812)
12:47:58.29 ZGS_SIP: <12:47:58.290>-TX(488 Bytes)--SIP--TCP-IP:217.0.26.197----Dest:5060--Src:10690--
12:47:58.29 ZGS_SIP: OPTIONS sip:sip-trunk.telekom.de SIP/2.0
12:47:58.29 ZGS_SIP: Via: SIP/2.0/TCP 192.168.1.254:10690;branch=z9hG4bK355_OPTIONS;rport
12:47:58.29 ZGS_SIP: From: <sip:[email protected]>;tag=9fxced330sl
12:47:58.29 ZGS_SIP: To: <sip:[email protected]>
12:47:58.29 ZGS_SIP: Call-ID: [email protected]
12:47:58.29 ZGS_SIP: CSeq: 355 OPTIONS
12:47:58.29 ZGS_SIP: Contact: <sip:[email protected]:10690;transport=tcp>;reg-id=1;+sip.instance="<urn:uuid:7B4
12:47:58.29 ZGS_SIP: E031F-F2AD-4D3B-A823-D0B309A8573F>"
12:47:58.29 ZGS_SIP: Max-Forwards: 70
12:47:58.29 ZGS_SIP: User-Agent: OpenCom X320 (R 1.618 mitel-ocx)
12:47:58.29 ZGS_SIP: Content-Length: 0
12:47:58.35 ZGS_SIP: <12:47:58.355>-RX(498 Bytes)--SIP--TCP-IP:217.0.26.197----Dest:10690-Src:5060---
12:47:58.35 ZGS_SIP: SIP/2.0 200 OK
12:47:58.35 ZGS_SIP: Via: SIP/2.0/TCP 192.168.1.254:10690;rport=10690;received=93.240.102.100;branch=z9hG4bK355_OPTIONS
12:47:58.35 ZGS_SIP: To: <sip:[email protected]>;tag=e89a056b
12:47:58.36 ZGS_SIP: From: <sip:[email protected]>;tag=9fxced330sl
12:47:58.36 ZGS_SIP: Call-ID: [email protected]
12:47:58.36 ZGS_SIP: Supported: 100rel,gin,path,timer
12:47:58.36 ZGS_SIP: CSeq: 355 OPTIONS
12:47:58.36 ZGS_SIP: Accept: application/sdp
12:47:58.36 ZGS_SIP: Accept-Encoding: identity
12:47:58.36 ZGS_SIP: Allow: ACK, BYE, CANCEL, INFO, INVITE, NOTIFY, OPTIONS, PRACK, PUBLISH, REFER, REGISTER, SUBSCRIBE,
12:47:58.36 ZGS_SIP: UPDATE
12:47:58.36 ZGS_SIP: Content-Length: 0
12:48:44.82 aw_worker.2: Set SIP-Trace Level 0
Wer kann mir beim eigentlichen Fehler weiterhelfen? Ich habe 2 Stellen im Verdacht, einen Hinweis zu liefern aber in diesem Fall ist Google nicht mein Freund.

Stelle 1:

Code:
12:47:28.54 ZGS_SIP: get_rmid() failed State:0 Callid:1066 Trid:19/0xFFFE
12:47:28.55 ZGS_SIP: <12:47:28.551>-TX(437 Bytes)--SIP--TCP-IP:217.0.26.197----Dest:5060--Src:10690--
12:47:28.55 ZGS_SIP: SIP/2.0 480 Temporarily not available

Fehler 480 nach get_rmid() failed State:0
Stelle 2:

Code:
12:47:58.35 ZGS_SIP: SIP/2.0 200 OK
12:47:58.35 ZGS_SIP: Via: SIP/2.0/TCP 192.168.1.254:10690;rport=10690;received=93.240.102.100;branch=z9hG4bK355_OPTIONS
12:47:58.35 ZGS_SIP: To: <sip:[email protected]>;tag=e89a056b
12:47:58.36 ZGS_SIP: From: <sip:[email protected]>;tag=9fxced330sl
12:47:58.36 ZGS_SIP: Call-ID: [email protected]
12:47:58.36 ZGS_SIP: Supported: 100rel,gin,path,timer
Hier bekomme ich etwas später SIP 200 OK aber die Verbindung zeigt sowohl beim To: als auch beim From: auf die gleiche "lokale" Telefonnummer ohne die Endziffer und verwendet die lokale IP-Adresse. Hier hätte ich ein Routing zu den Systemtelefonen erwartet oder zumindest eine Erweiterung des To: auf die vollständige Nummer mit Extension "-0" oder "-66" (Sammelnummer, die an alle Apparate geht).
 

maba001

Neuer User
Mitglied seit
20 Aug 2019
Beiträge
10
Punkte für Reaktionen
0
Punkte
1
Da Incoming nach wie vor über die Fritzbox und S0 läuft, hier nochmal ein Versuch.

Ich habe jetzt gemäß Vorschlag von chrsto auf "input control" umgestellt. Aber was ist die P-Called-Party-ID ? Wo gehört sie hin ? Was ändere ich damit ?
 

Anhänge

chrsto

Mitglied
Mitglied seit
8 Sep 2010
Beiträge
323
Punkte für Reaktionen
12
Punkte
18
Das P-Called-Party-ID kommt in das von dir gelb markierte Feld rein. Bitte auf die Schreibweise achten.

Damit legst du fest, dass die Rufnummer die gerufen wurde aus der P-Called-Party-ID ausgelesen wird. Das ist das einzige Feld, in dem die Telekom die Rufnummer immer gleich formatiert, nämlich international, übergibt. Wenn also jemand deine Nebestelle 66 anruft und deine Kopfnummer 4711 in Köln wäre, würde da +49221471166 drin stehen. Wenn deine -0 gerufen wird: +4922147110, usw.

Danach kannst du eine Rufnummernverteilung im Format 00492214711...... anlegen.
 

maba001

Neuer User
Mitglied seit
20 Aug 2019
Beiträge
10
Punkte für Reaktionen
0
Punkte
1
Hallo chrsto, schon mal vielen Dank. Das heißt "P-Called-Party-ID" ist ein fester String, der exakt so in dieses Feld geschrieben wird?

Never mind: ich habe das Feld im Log gefunden.
 
Zuletzt bearbeitet:

mschoenb

Mitglied
Mitglied seit
29 Okt 2014
Beiträge
309
Punkte für Reaktionen
15
Punkte
18
Besteht dein Problem noch?

Da du schon viel geändert hast, empfehle ich dir eine Werkseinstellung und danach ein Provider Template Update.
Eine MGW Karte hast du, und hat auch eine IP Adresse?

Lege alles neu an, und fand einfach mal mit 2 Nebenstellen und Zentrale an. Wenn es funktioniert, kannst du dir überlegen darauf aufzusetzen, ausser du hast eine grosse Anlage.
Wenn es nicht funktioniert, dann zeig uns die Einstellungen und ich vergleiche es mit meinen Templates. Bei mir funktionieren SIP Trunks mit der Mitel100 und X320 (aber jeweils eine DigiBox dahinter).

Wie ist die F!B eingestellt? Doppelregistrierung ist möglich (3 mal), aber kann zu Schwierigkeiten führen. Davon abgesehen ist eine F!B kein passender Router für eine SIP Trunk Anlage (fehlender SBC), aber ich habe es daran auch schon erfolgreich zum Laufen gebracht, auch wenn es immer mal wieder Neustarts ab und zu benötigte.

im Anrufverteilplan muss man immer noch 0049xxx und 0xxx eintragen, da über Telefonica (O2 Mobile und M-Net) beide Formate übergeben werden.
Fehlendes Freizeichen ist in an der Tagesordnung, was aber am Callserver bei Interconnectanrufen zu M-Net und vereinzelt Vodafone immer wieder passiert.

Ansonsten läuft alles soweit stabil.
 

maba001

Neuer User
Mitglied seit
20 Aug 2019
Beiträge
10
Punkte für Reaktionen
0
Punkte
1
Hallo, vielen Dank für die Nachfrage. Ja, das Problem besteht noch.

Die Anlage hat KEINE MediaGateWay-Karte. Laut Auskunft der Firma, die die Anlage verkauft hat (vor ca. 9 Jahren) sollte die X320 den Provider-Verkehr auch ohne abwickeln können. Ob das wahr ist, kann ich schlecht beurteilen. Das Internet widerspricht sich in diesem Punkt. Es gibt Infos, dass 32 VoIP Verbindungen auch ohne MGW funktionieren. Manche Quellen sagen auch es sind nur 8. Manche Quellen sagen, die MGW ist zwingend.

Intern werden keine IP-Telefone verwendet. Da sind nur Systemtelefone im Einsatz.
Der alte Anschluss (vor VoIP Umstellung) ging über zwei ISDN-Amtsanschlüsse und die entsprechenden S0/1 Anschlüsse (4 Gespräche parallel).

Jetzt funktioniert es gerade über den S0/1 der Fritzbox daher aber nur 2 Gepräche parallel.
Die VoIP-Registrierung funktioniert wie in den vorigen Posts beschrieben durchaus korrekt.

Im Voraus vielen Dank
 

chrsto

Mitglied
Mitglied seit
8 Sep 2010
Beiträge
323
Punkte für Reaktionen
12
Punkte
18
Die MGW ist ist zwingend.

32 Verbindungen (=Kanäle) beziehen sich auf 32 Mitel/Aastra/Detewe VoIP Verbindungen (damit ist NICHT VoIP/SIP gemeint).

8 Verbindungen (=Kanäle) beziehen sich auf ein System MIT MGW Karte. Damit kann dann auch SIP gemacht werden und IP/Nicht-IP Geräte können untereinander kommunizieren.

Statt eines MGW kannst du aber auch eine bintec be.ip plus davor schalten und die X320 weiter als ISDN Anlage betreiben.
 
Zuletzt bearbeitet:

maba001

Neuer User
Mitglied seit
20 Aug 2019
Beiträge
10
Punkte für Reaktionen
0
Punkte
1
Lässt sich diese Karte noch beschaffen und nachrüsten?
 

chrsto

Mitglied
Mitglied seit
8 Sep 2010
Beiträge
323
Punkte für Reaktionen
12
Punkte
18
Ja, gebraucht/neu bei einigen Händlern/ebay zu astronomischen Preisen. Siehe auch mein Zusatz in der Antwort davor.
 

mschoenb

Mitglied
Mitglied seit
29 Okt 2014
Beiträge
309
Punkte für Reaktionen
15
Punkte
18
Korrekt, die MGW Karte ist notwendig für SIP Trunkseitig.

Die MGW Karte ist bestimmt noch lieferbar. Suche dir einen Aastra/Mitel Händler,... ggf liest auch einer mit.
Und so teuer wie teilweise in der Bucht angeboten ist sie bei weitem nicht.

Dazu benötigst du noch die aktuelle FW12.1 (1.618) dafür kann diese 4 SIP Kanäle.

Aber du kannst dir eben auch eine Digitalisierungsbox der Telekom holen und alles auf ISDN laufen lassen
 

maba001

Neuer User
Mitglied seit
20 Aug 2019
Beiträge
10
Punkte für Reaktionen
0
Punkte
1
Also doch eher die Digitalisierungsbox? Die von der Telekom oder die Bintec? Welche funktioniert robuster? Bzgl. der Benutzerführung bin ich schmerztolerant aber die IP --> ISDN Funktion sollte robust und zuverlässig sein.

Allen schon mal vielen Dank !!!

Bei Ebay wird eine MGW für 329 € originalverpackt angeboten. Ist das Ok oder überteuert? Firmware habe ich bereits.
 

chrsto

Mitglied
Mitglied seit
8 Sep 2010
Beiträge
323
Punkte für Reaktionen
12
Punkte
18
Ob Digibox oder bintec ist egal. Mit einer Digibox wirst du bei einer Störungsmeldung trotz Routerfreiheit möglicherweise weniger Diskussionen haben.

329€ ist, dafür dass das Teil nicht mehr vertrieben wird, günstig. Ein realistischer Preis vor einem Jahr waren ca. 210€+- inkl. USt.
 

Rangierdraht

Mitglied
Mitglied seit
28 Mrz 2006
Beiträge
259
Punkte für Reaktionen
14
Punkte
18
Ich hätte noch einen neue Zyxel Gateway 400 hier, den würde ich für 250€ verkaufen. Mit den Dingern hatte ich bisher die besten Erfahrungen gemacht. Vor allem wenn Dect an der Anlage ist.
 

3CX PBX - GRATIS
Linux / Win / Cloud

Statistik des Forums

Themen
234,454
Beiträge
2,046,811
Mitglieder
354,239
Neuestes Mitglied
luksch96