 |
Startseite Telefonbörse Telefondatenbank (Betatest) |
Telefon Forum |  |
 |
mehr als 8900 Themen und 56200 Antworten |
 |
||||||||
| Zurück zur Übersicht! | Datenschutz | FAQ | Hilfe | Impressum | |||||
| Kategorie: > Fernamtstechnik, Vermittlungstechnik |
| Dauer des Verbindungsaufbaus im ISDN | |
| Münzersammler mathias77  gmx.net(Mailadresse bestätigt) 27.08.2019 |
Hallo, seinerzeit wurde ja mit dem überragend schnellem Verbindungsaufbau im ISDN geworben. Kann mir jemand sagen, wie schnell das ging? Heute finde ich dazu irgendwie nichts oder ich bin zu blöd zum suchen. :( |
| |
 |
|
| Anzahl der unterhalb stehenden Antworten: 13 |
| Thomas (Mailadresse bestätigt) 07.09.2019 |
Das Verhalten des österreichischen NGN, welches sich nutzerseitig nahezu "null" von einem echten ISDN-Anschluss unterscheidet, kann ich bestätigen. So beide Anschlüsse von A1 sind; erfolgt der Rufaufbau nach Wahl der letzten Ziffer augenblicklich. Was mir kürzlich jedoch aufgefallen ist: bei einer Tele2-Preselection (1002) ergeben sich seit ca. Mai 2019 folgende Verschlechterungen: Rufaufbau dauert nach Wahl der letzten Ziffer der Telefonnummer ca. 5 Sekunden, vorher ging dies bei gerufenen Festnetzanschlüssen augenblicklich – nur bei gerufenen Mobilfunkanschlüssen dauerte es ähnlich lang ISDN-Steuermerkmale (z.B. Rufumleitung bei gerufenem Anschluss usw.) werden nicht mehr durchgereicht und am Telefon angezeigt. Benutzt man einen anderen Verbindungsnetzbetreiber (bspw. COLT 1025) hat man diese Probleme nicht; hier geht es wie gewohnt augenblicklich durch. Ebenfalls dauert die Anwahl von entbündelten Tele2-Anschlüssen – unabhängig ob durch A1 (1001) oder Call-by-Call/CPS – ca. 5 Sekunden, bis der Anruf durchgestellt wird und das Freizeichen kommt. Vom entbündelten Tele2-ISDN-Anschluss weg zu einem A1 geht der Rufaufbau (komischerweise) immer noch augenblicklich - konnte ich bei einem Bekannten testen. Weiß hier eventuell jemand mehr über Grund und Ursache? |
|
| |
|
|
| Wählamt Kleinbaumgarten (Mailadresse bestätigt) 07.09.2019 |
Dieser Text bezieht sich auf den Beitrag von Impuls vom 06.09.2019!  Zunächst: In Österreich gab es - ähnlich wie in Deutschland - zwei Lieferanten für die Digitalvermittlungen: OES-D, System DMS100: Lieferant Nortel (Vertreten durch das Konsortium KAPSCH/SCHRACK) OES-E, System EWS-D: Lieferant SIEMENS (Vertreten durch Siemens Österreich, anfänglich war auch ALCATEL mitbeteiligt). Beide Systeme waren im Prinzip TDM-Vermittlungen mit ZZK7-Signalisierung untereinander und "nach draußen", also an der Netzkante zu anderen Netzen. Der Trace von gestern war zugegebenermaßen zu Verkehrslast-Schwachzeiten erstellt, ist aber dennoch aussagekräftig für Verbindungsaufbauzeiten im NGN, das ein ISDN emuliert. Die verlängerten Zeiten bei einzelnen Destinationen erklären sich damit, daß sich vermutlich (mindestens) eine echte VoIP-Strecke unterwegs eingefügt hat. Bei dem normalen SIP (bzw. SIP-I, also SIP mit ISUP-Signalisierung) können manche Systeme das ursprünglich mitgesendete "Wahlende-Kennzeichen" nicht erkennen und warten eben weitere etwa fünf Sekunden ein "Interdigit-Time-Out" ab, um sicherzugehen, die gesamte Wahlinformation eingesammelt zu haben. In Extremfällen, speziell bei Auslandsverbindungen, wo mehrere (nicht "wirklich") professionelle Betreiber sich entlang der Verbindungsstrecke hintereinander aufreihen, können sich diese Wartezeiten summieren. Übrigens: Das österreichische NGN der hiesigen Telekom arbeitet netzintern mit SIP-I, an der Netzkante können alle bislang üblichen Schnittstellen (SIP, SIP-I, ZZK7, S2M) zu anderen Netzbetreibern angeboten werden. Zum Teilnehmer hin werden POTS, ISDN-BRA und ISDN-PRI geschaltet. Bei ISDN ist, mit Ausnahme der D-Kanalnutzung und der "Permanent Virtuellen Leitung" weiternin das gesamte ISDN-Dienstespektrum - zumindest netzintern - verfügbar. Alternative Netzanbieter nutzen, neben VoIP-Technik bis heute noch teilweise TDM-Technik (EWS-D, DMS 100E, Ericsson AXE oder ANS). |
|
| |
|
|
| Impuls (Mailadresse bestätigt) 06.09.2019 |
Dieser Text bezieht sich auf den Beitrag von Münzersammler vom 06.09.2019! Der Verbindungsaufbau hat normal immer die gleiche Zeit gedauert. Über das Nummer 7 Netz ging das sehr schnell. Bei den Systemen EWSD und S12 hat die DBP normalerweise immer die neueste SW zuerst getestet und wenn für gut befunden ein gespielt. Österreich oder Schweiz hatten immer ältere Versionen im Netz. |
|
| |
|
|
| Münzersammler mathias77 gmx.net(Mailadresse bestätigt) 06.09.2019 |
Dieser Text bezieht sich auf den Beitrag von Münzersammler vom 06.09.2019! Mir kamen da noch ein paar Fragen: vielen Dank für deine Antwort. Die Daten zeigen zwar, wie lange ein einzelner Rufaufbau (unter Laborbedingungen?) dauern kann, aber dennoch nicht: - Gibt es im ISDN eine maximale Rufaufbauzeit? - Wie lautet die konkret? Nur weil ein Rufaufbau 300 ms gedauert hat, könnte ein anderer ja trotzdem 5 s dauern. Interessant finde ist auch, daß in Österreich ein ISDN-ähnliches Signalisierungsverfahren genutzt werden soll im NGN, aber was er damit genau meint, verstehe ich leider nicht. |
|
| |
|
|
| Münzersammler mathias77 gmx.net(Mailadresse bestätigt) 06.09.2019 |
Dieser Text bezieht sich auf den Beitrag von Wählamt Kleinbaumgarten vom 06.09.2019! Hallo Norman, vielen herzlichen Dank dafür! Die Antwort war erstklassig :) |
|
| |
|
|
| Wählamt Kleinbaumgarten (Mailadresse bestätigt) 06.09.2019 |
Dieser Text bezieht sich auf den Beitrag von Impuls vom 02.09.2019! Guten Morgen, in Österreich ist die Migration vom "nativen" ISDN auf eine österreichspezifische Version des NGN bereits weitgehend abgeschlossen, es wird aber ein ISDN-ähnliches Verhalten seitens des Netzes an das Tageslicht gelegt, der Verbindungsaufbau erfolgt daher im Millisekundenbereich. Anbei ein Signalisierungs-Trace: +43 2522 88211-79515 (ISDN) ruft +43 2522 88043 (POTS) Start[06.09.2019 2:51:43] -------------------------------------------------------------------------------- #000003 SETUP [0002]-->| 02:51:51,833 00 01 98 8E | 08 01 02 05 | Bearer Caps 04 03 90 90 A3 | Channel Id 18 01 8A | Progress Ind 1E 02 81 83 | Calling PN 6C 07 01 80 37 39 35 31 | 35 | Called PN 70 0F 81 31 30 30 31 30 | 32 35 32 32 38 38 30 34 | 33 | SendingCompl A1 | [51:51.83] i[99]: nstanl: CONNECT IND [26ca] ctrl[3] fac[ff] ch[2] dad[10010252288043] oad[79515] oad2[] sin[102] [51:51.83] i[99]: nstanl: search_redirect(oad) <1079515> to <> [51:51.83] i[99]: nstanl: search_redirect(102) <1079515> to <> [51:51.83] i[99]: nstanl: send0 connect_resp to 7 [51:51.84] i[99]: nstanl: digits1 0x802a986a <> dad 0x801ceca5 <10010252288043> [51:51.84] i[99]: nstanl: dadsub 0x0 <(null)> 0 14 [51:51.84] i[99]: nstanl: digits2 0x802a986a <10010252288043> 0x0 <(null)> 0 0 14 [51:51.84] i[99]: nstanl: digits3 0x802a986a <10010252288043> 0x0 <(null)> 0 0 14 [51:51.84] i[99]: nstanl: digits4 0x802a986a <10010252288043> 14 [51:51.84] i[99]: nstanl: digits5 lmu 79 <10010> <810010> [51:51.84] i[99]: nstanl: digits6 <10010252288043> <810010> 5 6 [51:51.84] i[99]: nstanl: digits7 <10010252288043> <810010> 5 6 [51:51.86] i[99]: nstanl: route_plan CI: 0 <810010252288043> <10010252288043> [51:51.86] i[99]: nstanl: ci0 <810010252288043> <79515> lp 0x802a9860 79 c3 1 102 [51:51.86] i[99]: nstanl: handle_new 0 0x802a9860 <810010252288043> <79515> 1 102 0 79 [51:51.86] i[99]: nstanl: next_new_link1 0 0 [51:51.86] i[99]: nstanl: new_link 0x802a81e0 ctrl 0 dad <> oad <> [51:51.86] i[99]: nstanl: next_new_link2 0 [51:51.86] i[99]: nstanl: next_new_link4 255 [51:51.86] i[99]: nstanl: mk_new_conn search_redir lp 0x802a81e0 <810010252288043> 0x102 0x0 [51:51.88] i[99]: nstanl: ci1 <810010252288043> <79515> lp 0x802a9860 79 c3 1 conn 0x802a81e0 <> <10010252288043> 0 0 2 |<--[0002] CALL PROCEEDING #000003 | 02:51:51,880 02 01 8E 9A | 08 01 82 02 | Channel Id 18 01 8A | Progress Ind 1E 02 82 88 |<--[003C] SETUP #000000 | 02:51:51,880 00 01 4C 68 | 08 01 3C 05 | SendingCompl A1 | Bearer Caps 04 03 90 90 A3 | Channel Id 18 01 82 | Progress Ind 1E 02 80 83 | Calling PN 6C 06 81 37 39 35 31 35 | Called PN 70 0F 81 31 30 30 31 30 | 32 35 32 32 38 38 30 34 | 33 #000000 CALL PROCEEDING [003C]-->| 02:51:52,052 02 01 68 4E | 08 01 BC 02 | Channel Id 18 01 8A | [51:52.05] i[99]: nstanl: CONNECT ACK [10981979] chi[2] [51:52.05] i[99]: nstanl: ALERT IND 4904 [10981979] [51:52.05] i[99]: nstanl: ALERT IND lp 0x802a81e0 ctrl 0 cc 64 conn 0x802a9860 #000000 ALERTING [003C]-->| 02:51:52,162 02 01 6A 4E | 08 01 BC 01 | Progress Ind 1E 02 82 82 | Progress Ind 1E 02 82 88 | [51:52.16] i[99]: nstanl: ALERT IND 3804 [10981979] [51:52.16] i[99]: nstanl: ALERT IND lp 0x802a81e0 ctrl 0 cc 64 conn 0x802a9860 [51:52.16] i[99]: nstanl: search_redirect(102) <810010252288043> to 0x0 -1 |<--[0002] ALERTING #000003 | 02:51:52,162 02 01 90 9A | 08 01 82 01 | Progress Ind 1E 02 82 88 #000003 DISCONNECT [0002]-->| 02:51:54,240 00 01 9A 92 | 08 01 02 45 | 08 02 81 90 | [Normal call clearing] | Progress Ind 1E 02 81 83 | [51:54.24] i[99]: nstanl: DISCONNECT IND [109726ca] [51:54.24] i[99]: nstanl: DISCONNECT IND lp 0x802a9860 ctrl 3 cc 64 conn 0x802a81e0 [51:54.24] i[99]: nstanl: enqueue_dialback db 0 cc 40 ctrl 0 <810010252288043> <79515> : n/a [51:54.24] i[99]: nstanl: DISC_IND lp 0x802a9860 3 1 <810010252288043> 40 conn 0x802a81e0 0 3 <> 40 [51:54.24] i[99]: nstanl: DISC_IND lp 3 1 <810010252288043> 0 conn 0 3 <> 0 |<--[003C] DISCONNECT #000000 | 02:51:54,240 00 01 4E 6C | 08 01 3C 45 | 08 02 80 90 | [Normal call clearing] #000000 RELEASE [003C]-->| 02:51:54,552 02 01 6C 50 | 08 01 BC 4D | |<--[003C] RELEASE COMPLETE #000000 | 02:51:54,552 00 01 50 6E | 08 01 3C 5A [51:54.55] i[99]: nstanl: DISCONNECT CONF [10981979] [51:54.55] i[99]: nstanl: DISC_CONF lp 0x802a81e0 <> <10010252288043> ctrl 0 cc 64 st 30 cau 255 conn 0x802a9860 [51:54.55] i[99]: nstanl: DISC_CONF maxcalls 0 conn 3 1 <810010252288043> 0 [51:54.56] i[99]: nstanl: reset_link 0x802a9860 st 1 (1) dir 1 ctrl 3 dad <810010252288043> oad <79515> cau 0x0 lmu 79 [51:54.56] i[99]: nstanl: dchan_ccbs_local_user_free ctrl 3 dad <1079515> [51:54.56] i[99]: nstanl: reset_link 0x802a81e0 st 30 (3) dir 2 ctrl 0 dad <> oad <10010252288043> cau 0xff lmu 0 [51:54.56] i[99]: nstanl: DISC_CONF art 4008304 c_art 304 |<--[0002] RELEASE #000003 | 02:51:54,568 02 01 92 9C | 08 01 82 4D [51:54.56] i[99]: nstanl: DISCONNECT CONF [109726ca] [51:54.56] i[08]: HndlDosIpc unknown ident 0, mtype 7e01 [51:54.56] i[08]: notify_dialog_subscribers_of_remote_user_free for dad <1079515> #000003 RELEASE COMPLETE [0002]-->| 02:51:54,583 00 01 9C 94 | 08 01 02 5A | -------------------------------------------------------------------------------- -------------------------------------------------------------------------------- End[06.09.2019 2:53:36] Man sieht also, daß von der SETUP-Information (vorwärts gerichtet) um 02:51:51,833 Uhr bis zum einlangenden Alerting um: 02:51:52,162 Uhr 0,329 Sekunden, also gerundet eine Drittelsekunde vergehen. Das Melden wurde hier nicht durchgeführt, zumindest hierzulande erfolgt das Melden ohne Unterdrückung von Sprachsignalen. Das getrennte Führen der Signalisierungskanäle in der DIV- bzw. TDM-Technik (also Time Division Multiplex), von den Nutzkanälen ist in der Systematik des ISUP-SS7, also der Signalisierung mittels eines(!) zentralisierten Signalisierungskanales und der Assoziierung der zugehörigen Nutzkanäle begründet. |
|
| |
|
|
| Impuls (Mailadresse bestätigt) 02.09.2019 |
Dieser Text bezieht sich auf den Beitrag von Münzersammler vom 02.09.2019! Ich kenne das aus dem Netz der Telekom eigentlich nicht, dass da die ersten Silben verschluckt wurden. Bei den DIV-Systemen EWSD und S12 geht der Verbindungsaufbau ja einen anderen Weg als die Verbindung selbst. Ich kann mir vorstellen, dass die eigentliche Verbindung erst dann durchgeschaltet wird, wenn der gerufene Tlnr den Hörer abnimmt. Wenn der gerufene Tlnr sich nicht meldet, spart man sich schon Leitungskapazitäten. |
|
| |
|
|
| Münzersammler mathias77 gmx.net(Mailadresse bestätigt) 02.09.2019 |
Gibts den niemanden, der da was genaueres weiß oder eine Quelle zum Nachlesen kennt? |
|
| |
|
|
| Steffen Froeschle kinobauer.ch kinobauer kinobauer.ch(Mailadresse bestätigt) 27.08.2019 |
Dieser Text bezieht sich auf den Beitrag von countryman vom 27.08.2019! Ja, das mit der ersten Silbe ist mir bei Arcor-ISDN-Anschlüssen mit DSL (gesplittert) immer mal wieder aufgefallen. Ich weiss nicht, was an diesm Anschluss für eine Telefonanlage installiert war, aber dieses Verhalten war immer gleich. |
|
| |
|
|
| Detlef Genthe post telegenthe.de(Mailadresse bestätigt) 27.08.2019 |
Dieser Text bezieht sich auf den Beitrag von Münzersammler vom 27.08.2019! Ich habe eine Sekunde als Maximalzeit in Erinnerung, aber auch keine ordentliche Quelle. Real ging es meist schneller. |
|
| |
|
|
| Münzersammler mathias77 gmx.net(Mailadresse bestätigt) 27.08.2019 |
Dieser Text bezieht sich auf den Beitrag von countryman vom 27.08.2019! Interneteinwahl gibt es noch, ja. Allerdings nicht mehr lange. Die Leute die das Nutzen, haben bald Probleme. :( Mich interessiert eine Literaturangabe oder genaue Zeiten zum Verbindungsaufbau. |
|
| |
|
|
| countryman ackersmann gmx.net(Mailadresse bestätigt) 27.08.2019 |
Dieser Text bezieht sich auf den Beitrag von Steffen Froeschle kinobauer.ch vom 27.08.2019! Ja, das war auch meine Erfahrung. ISDN (als Amtsanschluss mit DSL) endete hier erst 2018. Interneteinwahl ist freilich länger her ;-) Bei bestimmten Anschlüssen war allerdings auffällig, dass beim Verbindungsaufbau die ersten Silben der angerufenen Gegenstelle verschluckt wurden. Möglicherweise lag das aber auch an der dortigen Anlage. Apropos Interneteinwahl über Analog oder ISDN, gibt es das eigentlich noch irgendwo? |
|
| |
|
|
| Steffen Froeschle kinobauer.ch kinobauer kinobauer.ch(Mailadresse bestätigt) 27.08.2019 |
Hallo, habe zwar keine genaue Literaturangabe, aber aus meiner Erfahrung als Nutzer von ISDN von 1996-2015 war der Verbindungsaufbau immer extrem schnell, war die letzte Ziffer gewählt ertönte eigentlich sofort der Freiton. Eine Interneteinwahl dauerte nur wenige Sekunden (deutlich unter 10 sek). |
|
| |
|
|
| Werbung (2/-2) | |
