Jump to content

Deutsche Telekom - DeutschlandLAN SIP-Trunk


gifti

Recommended Posts

Hallo Vodia-Support, hallo Forum,

Ende 2018 sollen in Deutschland auch ISDN Anlagenanschlüsse von Telekom-Geschäftkunden abgeschaltet werden. Ich vermute, die Telekom wird u.a. eine Migration auf das Produkt DeutschlandLAN SIP-Trunk vorgeschlagen. Ich habe unserer Firma mal einen Test-Anschluss (SIP-Trunk Pooling) organisiert und versucht, meine Voida 5.1.1 damit bekannt zu machen. Leider bisher ohne Erfolg -_-.

Auch mit der aktuellen Version Vodia 58.2 habe ich auf meinem Vodia Testsystem den Trunk nicht zum Laufen gebracht. Die Standardeinstellungen für eine "SIP-Registrierung" beim Provider "Deutsche Telekom" sind auch nur auf den IP-basierenden (Basis-)Anschluss ausgerichtet.

Gibt es jetzt schon Möglichkeiten den SIP-Trunk der Telekom mit einer Vodia-PBX zu nutzen?
Wenn ja, wie und wo muss ich die Anmeldedaten der Telekom (Bsp: Registrar => sip-trunk.telekom.de) eintragen?
Wenn nein, ist eine Anschlussmöglichkeit des Telekom SIP-Trunks in Arbeit? Wie sieht hier die zeitliche Planung aus?

Viele Grüße
Gifti

Link to comment
Share on other sites

Wir haben den Trunk mit einem T-Entertain Anschluss ausprobiert und nach einigem hin-und-her zum Laufen bekommen. Eines der Hauptprobleme für uns ist dass wir das nicht von ausserhalb ausprobieren kann, sondern nur mit einem T-*-Anschluss (Deutsche Telekom bietet das nicht in Boston an). Am besten wäre es wenn wir mal über HTTP einen Zugang zu einer 58.2 und einem T-SIP-trunk bekommen könnten...

Link to comment
Share on other sites

Beim Aufbau des Testsystems habe ich auch gleich die Lösung für den SIP-Trunk der Telekom gefunden :D.
Es lag an den fehlenden Zertifikaten und zwei Feldern in der Trunkeinstellung.

Ich beschreibe mal die vollständige Konfiguration:

Einrichtung DSL

  • Produkt DeutschandLAN SIP-Trunk Pooling bei der Telekom bestellt
  • dazu gabs einen DSL-Anschluss mit 16 kbit Upload und 2.400 Kbit Download (erweiterter Frequenzbereich durch Annex J)
  • daher braucht man auch einen Annex J fähigen DSL-Router (Modem)
  • ich habe mich für ein D-Link DSL-321B Rev. Z (Revision D funktiniert nicht!!!) entschieden
  • leider kann das DSL-321B im Router-Betrieb keine VLAN ID 7 über PPPoe senden
  • daher musste ich das Modem im Bridge Mode an meinen alten Bintec R1200 Router hängen, der über PPPoe eine VLAN ID mitgeben kann
  • auf eine Firewall habe ich erst mal verzichtet, da die Geräte ja alle nur im Testnetz hängen
  • ich habe mich für den Registered Mode entschieden, bei dem die IP-Adresse der Telekom dynamisch bleibt
  • dafür gabs noch einen DynDNS Eintrag im Web + NAT Regel auf dem Router, um den Zugriff über https aus dem Internet zu gewährleisten

Einrichtung PBX Testystem:

  • ich habe mir einen neuen Vodia PBX free Lizenzschlüssel generiert
  • einem Raspberry PI 2 mit Raspbian frisch aufgesetzt
  • die aktuelle PBX Version 58.2 nach Anleitung installiert und Lizenz aktiviert
  • Nebenstelle eingerichtet und ein Snom370 angeschlossen / provisioniert

Einrichtung Deutschland-LAN SIP-Trunk:

  • in der Standard Domain unter Leitungen einen neuen VoIP Provider vom Typ other ausgewählt
    • Typ: SIP Registrierung
    • Name: <egal>
    • Outbound Proxy Adresse: reg.sip-trunk.telekom.de
    • Benutzername (für die Registrierung): Telefonie-Benutzername (12 stellige Nummer)
    • Passwort: Telefonie-Passowort
  • dann müsst ihr den Eintrag noch editieren und Domäne und Konto hinzufügen
    • Domäne: sip-trunk.telekom.de
    • Konto: Registrierungsrufnummer (im kanonischen Format +49123456789000)
  • damit die Gespräche irgendwo ankommen, Ziel Konto nicht vergessen (in meinem Fall das Snom 370)
  • den Trunk im Dialplan eintragen

Einrichtung Zertifikate:

  • der Trunk spricht nur über TLS und braucht zwei Zertifikate der Deutschen Telekom:
  • ich habe die beiden Zertifikate als .cer Files (Base64 codiert) gespeichert
  • so kann man sie über die Zwischenablage in den PBX übertragen
  • im PBX unter Einstellungen / Sicherheit / Zertifikate
  • Vertrauenswürdige Root CA (für Server Authentifizierung) auswählen und den Base64 Code jeweils hinein kopieren/speichern
  • jetzt sollten beiden Zertifikatsnamen in der unteren Liste auftauchen

Deutsche Telekom Root CA 2

-----BEGIN CERTIFICATE-----
MIIDnzCCAoegAwIBAgIBJjANBgkqhkiG9w0BAQUFADBxMQswCQYDVQQGEwJERTEc
MBoGA1UEChMTRGV1dHNjaGUgVGVsZWtvbSBBRzEfMB0GA1UECxMWVC1UZWxlU2Vj
IFRydXN0IENlbnRlcjEjMCEGA1UEAxMaRGV1dHNjaGUgVGVsZWtvbSBSb290IENB
IDIwHhcNOTkwNzA5MTIxMTAwWhcNMTkwNzA5MjM1OTAwWjBxMQswCQYDVQQGEwJE
RTEcMBoGA1UEChMTRGV1dHNjaGUgVGVsZWtvbSBBRzEfMB0GA1UECxMWVC1UZWxl
U2VjIFRydXN0IENlbnRlcjEjMCEGA1UEAxMaRGV1dHNjaGUgVGVsZWtvbSBSb290
IENBIDIwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCrC6M14IspFLEU
ha88EOQ5bzVdSq7d6mGNlUn0b2SjGmBmpKlAIoTZ1KXleJMOaAGtuU1cOs7TuKhC
QN/Po7qCWWqSG6wcmtoIKyUn+WkjR/Hg6yx6m/UTAtB+NHzCnjwAWav12gz1Mjwr
rFDa1sPeg5TKqAyZMg4ISFZbavva4VhYAUlfckE8FQYBjl2tqriTtM2e66foai1S
NNs671x1Udrb8zH57nGYMsRUFUQM+ZtV7a3fGAigo4aKSe5TBY8ZTNXeWHmb0moc
QqvF1afPaA+W5OFhmHZhyJF81j4A4pFQh+GdCuatl9Idxjp9y7zaAzTVjlsB9WoH
txa2bkp/AgMBAAGjQjBAMB0GA1UdDgQWBBQxw3kbuvVT1xfgiXotF2wKsyudMzAP
BgNVHRMECDAGAQH/AgEFMA4GA1UdDwEB/wQEAwIBBjANBgkqhkiG9w0BAQUFAAOC
AQEAlGRZrTlk5ynrE/5aw4sTV8gEJPB0d8Bg42f76Ymmg7+Wgnxu1MM9756Abrsp
tJh6sTtU6zkXR34ajgv8HzFZMQSyzhfzLMdiNlXiItiJVbSYSKpk+tYcNthEeFpa
IzpXl/V6ME+un2pMSyuOoAPjPuCp1NJ70rOo4nI8rZ7/gFnkm0W09juwzTkZmDLl
6iFhkOQxIY40sfcvNUqFENrnijchvllj4PKFiDFT1FQUhXB59C4Gdyd1Lx+4ivn+
xbrYNuSD7Odlt79jWvNGr4GUN9RBjNYj1h7P9WgbRGOiWrqnNVmh5XAFmw4jV5mU
Cm26OWMohpLzGITY+9HPBVZkVw==
-----END CERTIFICATE-----

 

Shared Business CA 4

-----BEGIN CERTIFICATE-----
MIIGiTCCBXGgAwIBAgIIMBWLWM1WMfUwDQYJKoZIhvcNAQELBQAwcTELMAkGA1UE
BhMCREUxHDAaBgNVBAoTE0RldXRzY2hlIFRlbGVrb20gQUcxHzAdBgNVBAsTFlQt
VGVsZVNlYyBUcnVzdCBDZW50ZXIxIzAhBgNVBAMTGkRldXRzY2hlIFRlbGVrb20g
Um9vdCBDQSAyMB4XDTE0MDIxMTEzMjkwMloXDTE5MDcwOTIzNTkwMFowgdYxCzAJ
BgNVBAYTAkRFMSUwIwYDVQQKExxULVN5c3RlbXMgSW50ZXJuYXRpb25hbCBHbWJI
MR8wHQYDVQQLExZULVN5c3RlbXMgVHJ1c3QgQ2VudGVyMRwwGgYDVQQIExNOb3Jk
cmhlaW4gV2VzdGZhbGVuMQ4wDAYDVQQREwU1NzI1MDEQMA4GA1UEBxMHTmV0cGhl
bjEgMB4GA1UECRMXVW50ZXJlIEluZHVzdHJpZXN0ci4gMjAxHTAbBgNVBAMTFFNo
YXJlZCBCdXNpbmVzcyBDQSA0MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKC
AQEA0AmOfEgQdNgcqOwdEjRsMm7N+bmQ9tMqjqmA77w1pIebzqPDAUWBuseG1G1O
T76V6Ndfi1cFChPnmi0OINjSiuFvJ2LqdUxTjac4ASGt+NABEN5m2wvjaO2JbBou
tCnSG8sqDJ7wtN2xXxEa7lrzEEXYHxCDVqVC8wViidIIY33CjL/GFy4HkurmXiuC
9kRvxslPWygK4hGkKJWK3YKOh4OQFHZoMfjNKf5QgyzKhffXUlGG8pzR5Pk4RP2f
qwkLdxkWDdAanntaNzQLkFOOPl96VCqiwxiajcbpewva2fqntj9eBaeTITTZBmpI
/pCy1HwTjMYyFQFlnYrhR1nKhQIDAQABo4ICvTCCArkwDgYDVR0PAQH/BAQDAgEG
MB0GA1UdDgQWBBSr/2/REm9XytLY2MG+9hM0InSBMzAfBgNVHSMEGDAWgBQxw3kb
uvVT1xfgiXotF2wKsyudMzASBgNVHRMBAf8ECDAGAQH/AgEAMFIGA1UdIARLMEkw
PQYJKwYBBAG9Rw0ZMDAwLgYIKwYBBQUHAgEWImh0dHA6Ly9zYmNhLnRlbGVzZWMu
ZGUvY3BzL2Nwcy5wZGYwCAYGZ4EMAQICMIHjBgNVHR8EgdswgdgwNKAyoDCGLmh0
dHA6Ly9jcmwuc2JjYS50ZWxlc2VjLmRlL3JsL0RUX1JPT1RfQ0FfMi5jcmwwgZ+g
gZyggZmGgZZsZGFwOi8vbGRhcC5zYmNhLnRlbGVzZWMuZGUvQ049RGV1dHNjaGUl
MjBUZWxla29tJTIwUm9vdCUyMENBJTIwMixPVT1ULVRlbGVTZWMlMjBUcnVzdCUy
MENlbnRlcixPPURldXRzY2hlJTIwVGVsZWtvbSUyMEFHLEM9REU/QXV0aG9yaXR5
UmV2b2NhdGlvbkxpc3QwggEXBggrBgEFBQcBAQSCAQkwggEFMCoGCCsGAQUFBzAB
hh5odHRwOi8vb2NzcDAyLnRlbGVzZWMuZGUvb2NzcHIwOwYIKwYBBQUHMAKGL2h0
dHA6Ly9jcmwuc2JjYS50ZWxlc2VjLmRlL2NydC9EVF9ST09UX0NBXzIuY2VyMIGZ
BggrBgEFBQcwAoaBjGxkYXA6Ly9sZGFwLnNiY2EudGVsZXNlYy5kZS9DTj1EZXV0
c2NoZSUyMFRlbGVrb20lMjBSb290JTIwQ0ElMjAyLE9VPVQtVGVsZVNlYyUyMFRy
dXN0JTIwQ2VudGVyLE89RGV1dHNjaGUlMjBUZWxla29tJTIwQUcsQz1ERT9jQUNl
cnRpZmljYXRlMA0GCSqGSIb3DQEBCwUAA4IBAQCRf8qqiptZLVpOOmoRSgSZcNDh
hLWpN0pZXkUGYeyj64EAiSHLaLV32ZL+k84XPNjX8ezzHqhQDbKuXVMly1RGhtEz
8R/f5x1eYJKiWGbc3flt4VJeGKfPzRYoPPJJcTKabh8EKktx0DKDmldwoReRej6P
UHRlOQIdocYd0kLxl+InVmKOpMxfl/Y4Re2rthsjnrFBB6dCEha3cgaCcTz3qNUz
UahVS8jq8t/0tXoTBz4s0I/4JrBNHt/IFyBnwKM3YeNzlfokT4ptJ8OV28yNvspJ
nfKouiXc6eG1ojopwckO/uEu0JVEnyMOzGoIPU2/PhFvG6aAPsB4tvv/AHzR
-----END CERTIFICATE-----

Danach sollte sich der Trunk verbinden und ein Testanruf möglich sein B)!

Großes Lob an Vodia! Die Log-Styles mit Rahmen und Proportionalschrift sind wirklich übersichtlich!
Der Trunk hat im Log die Installation eines Zertifikats gefordert und den Base64 Code gleich mit angezeigt.
Allerdings hat es mit diesem angezeigten Zertifikat nicht funktioniert? Ich musste die beiden o.g. Zertifikate verwenden ...

Viele Grüße
Gifti

@Vodia PBX Das Testsystem läuft noch. Wenn ihr Interesse an einem Zugang habt, schreibt mich kurz an.

 

 

Link to comment
Share on other sites

Die beiden SIP-Trunk-Produkte "DeuschlandLAN SIP-Trunk" und "Deutschland LAN SIP-Trunk Pooling" sind in der SIP-Konfiguration sicher gleich.
Allerdings wäre es schön für die beiden Anschlussarten "Static Mode" und "Registered Mode" jeweils ein Template zu haben.

Im "Static Mode" ändert sich der Proxy in stat.sip-trunk.telekom.de. Laut Telekom Doku (Seite 10) können dann die Felder Benutzername und Passwort leer bleiben. Die Telekom gibt an, man könne im Telefoniecenter den Trunk vom "Registered Mode" in den "Static Mode" umschalten. Ich konnte zwar im Kundencenter eine feste IP-Adresse aktivieren. Der Button "In Static Mode wechseln" im Telefoniecenter erscheint bei mir aber leider nicht? Das sogenannte Endgeäte-Szeneario bleibt immer im "Registered Mode"?

Naja, ich werde damit mal die Telekom konfrontieren.
Grüße / Gifti

sip-trunk.PNG

Link to comment
Share on other sites

  • 2 weeks later...
  • 1 month later...

Der DTAG-SIP-Trunk Läuft leider doch noch nicht ganz rund. Mit eingehenden Gesprächen gibt es keine Probleme. Sind stabil und Gesprächsqualität stimmt. Bei ausgehenden Gesprächen treten folgende Fehler auf:

Ins Mobilfunknetz Bsp: 0151xxxxxxx

Kein Freizeichen, kein Klingeln. Anruf bricht immer nach ca. 15 Sekunden mit SIP 500 ab. Anrufe ins Mobilfunknetz werden Netzseitig vollkommen blockiert. Ich habe aber keine Rufnummernsperren im Telefoniecenter etc. konfiguriert. PCAP Logs liegen vor und kann ich gerne nachliefern. So sehen die Flow-Sequenzen aus:

pbx_to_0151xxxxxxx_SIP500_interal_error.

Ins Festnetz

Alles normal. Freizeichen, Klingeln ... dann nach 30 Sekunden Netz-seitger Abbruch des RTP-Datentromes. Der RTP Datentrom PBX-seitig läuft weiter. Nach weiteren 120 Sekunden RTP Timeout PBX-seitig. Hier noch ein Flow. PCAP liegt vor.pbx_to_0361xxxxxx_30sec_disconnect.png

Ich hatte RTCP unter verdacht. Ich habe auch schon mal alle RTCP Einstellungen auf false und den PBX neu gestartet. Ohne Erfolg -_-.

<rtcp_loss_rle>false</rtcp_loss_rle>
<rtcp_dup_rle>false</rtcp_dup_rle>
<rtcp_rcpt_times>false</rtcp_rcpt_times>
<rtcp_rcvr_rtt>false</rtcp_rcvr_rtt> <!-- default true --> 
<rtcp_stat_summary>false</rtcp_stat_summary>
<rtcp_voip_metrics>false</rtcp_voip_metrics> <!-- default true -->

Hier noch meine Trunkeinstellungen:

#Trunk 1
aadr: 
analog: false
bcp: 
behind_nat: false
cid_update: 
cobusy: 500 Line Unavailable
codec_lock: false
codecs: 
codest: 
cur: 
dial_extension: 40
dialplan: 
dir: 
dis: false
domain: 1
dtmf: false
dtmf_mode: 
earlymedia: false
expires: 3600
failover: never
fraction: 128
from_source: rpi
from_user: 
glob: plus
global: false
hcv: 
hd: 
hf: {from}
hpai: {from}
hppi: 
hpr: 
hrpi: 
hru: {request-uri}
ht: <{request-uri}>
icid: 
ignore_18x_sdp: false
interoffice: false
minimum: 10
minor: 162 s
name: Deutschand LAN
outbound_proxy: sip:reg.sip-trunk.telekom.de
pcap: true
prack: true
prefix: 73073
redirect: false
reg_account: +49361xxxxxxx
reg_display: Giftnotruf
reg_keep: 
reg_pass: xxxxxx
reg_registrar: sip-trunk.telekom.de
reg_user: 5511xxxxxxxx
remote_party: 
request_timeout: 
require: 
rfcrtp: false
ring180: false
rtcpxr: false
rtp_begin: 
rtp_end: 
send_email: 
sip_port: 
status: 200 OK
tel: false
trusted: false
type: register
use_epid: false
use_history: false
use_uuid: false
user_defined_hdr: 
uuid: 0a4a2738-6f40-4908-97c4-f8cb5ac84c36
wrtc_dest_name: 
wrtc_dest_number: 

Grüße / Gifti

Link to comment
Share on other sites

  • 2 weeks later...

Hallo,

ich habe am 14.11.2017 bei der Telekom eine Störung geöffnet. Am 15.11.2017 wurden zwei Testanrufe netzseitig von der Telekom analysiert.

  1. Anruf aus dem SIP-Trunk ins Festnetz nach ca. 36 Sekunden RTP Timeout netzseitig (15.11.2017 UTC 07:44:43)
  2. Anruf aus dem SIP-Trunk ins Mobilfunknetz mit SIP 500 Error (15.11.2017 UTC 07:47:09)

Antwort des/der Deutsche Telekom Servicetechnikers/in:

Quote

Externe Stoerungsursache;Kunde;Entstoerung durch Dritte;Fehler liegt am Engeräte Vodia-PBX des Kunden.,Diese verhält sich wirklich nicht SIP freudig.,Erster Call. Auf die 200 OK SDP des B-Tln sollte eine ACK Meldung folgen. Passiert jedoch nicht. -> RTP wird zwar aufgebaut aber ohne eine Antwort vom A-Tln wir der Call nach einiger Zeit Ausgetimt.,Zweiter Call. Auf die 183 Session Progress SDP Meldung mit Require 100rel sollte eine PRACK Meldung folgen. 3-Way-handshake. -> Passiert ebenfalls nicht... -> Call kann so nicht zustande kommen.,Kunde soll einmal seine Konfig/Firewalls und co prüfen. GGf sich mit dem Systemhersteller in Verbindung setzen.,Die Anlage verhält sich hier völlig Fehlerhaft. Hab ich so auch noch nicht gesehen.;

 

https://www.telekom.de/hilfe/downloads/1tr118_v10_.pdf

Ich habe von beiden Anrufen auch die PCAP Files aufgezeichnet. Die Flows sind exakt gleich wie in den Tests vorher.

Auf die 200 OK SDP des B-Tln (217.*) sollte eine ACK Meldung folgen. Passiert jedoch nicht. -> RTP wird zwar aufgebaut aber ohne eine Antwort vom A-Tln (192.*) wir der Call nach einiger Zeit ausgetimed.

pbx_to_0361xxxxxx_30sec_disconnect.png

Auf die 183 Session Progress SDP Meldung mit Require 100rel sollte eine PRACK Meldung folgen. 3-Way-handshake. -> Passiert ebenfalls nicht... -> Call kann so nicht zustande kommen

pbx_to_0151xxxxxxx_SIP500_interal_error.

Was ist die Ursache? Kann ich an meiner Trunk-Konfiguration noch etwas ändern?

Grüße / Gifti

Link to comment
Share on other sites

PRACK kann nur gesendet werden wenn auch ein RSeq geschickt wird. Das ist in dem einen Trace drin; in dem anderen nicht. Das Hauptproblem dürfte aber sein warum die PBX keine Nachricht and die Telekom sendet (senden kann). 

Wir haben ein Setting "Don't accept SIP routing changes in dialog" mit dem wir das Problem erst mal lösen können. Dann dürfte die PBX die Nachrichten versenden können.

Link to comment
Share on other sites

So wir haben uns das mal im Detail angesehen. Die Telekom sendet zurück:

Record-Route: <sip:reg.sip-trunk.telekom.de;transport=tls;lr>

Im RFC3263 steht wie diese URL aufgelöst werden soll. Das transport=tls hat unsere PBX ein bisschen verwirrt; wenn in der URI ein Port angegeben ist, muss NAPTR und SRV übersprungen werden. Die PBX hat das auch bei Transport gemacht. Das ist offenbar inkorrekt, die nächste Version wird das wirklich nur bei Port machen und dann sollte auch der Telekom-Trunk rund laufen.

Link to comment
Share on other sites

  • 1 month later...

Hallo,

ich habe gerade mal 59.4 getestet. Damit sind die oben beschriebenen Probleme mit dem "Deutsche Telekom SIP-Trunk" wieder da :wacko:
Bin wieder zurück auf 59.1 und mein SIP-Trunk funktioniert ohne Probleme ...

Habt ihr den Fix mit der Record-Route / Port wieder verworfen?

Grüße Gifti

Link to comment
Share on other sites

  • 2 years later...

Das Einrichtungstemplate in der 65.0.5 setzt leider immer noch einige Werte falsch.

  1. DT benutzt Rufnummern im +49... format. Alle settings die sich darauf beziehen sollten entsprechend eingestellt sein (mindestens Rewrite global numbers im SIP Trunk)
  2. Encrypt media sollte auf Default stehen. Der Assistent stellt das auf "off". Wenn SIP per TLS benutzt wird (Default), *muss* auch RTP+DTLS benutzt werden. Ein mix von secure/insecure wird nicht unterstützt (steht so auch in der technischen Doku von DT,  [1], Abschnitt 11.31)
  3. PRACK sollte an sein, geht aber auch ohne (lt. [1])

Ein paar Nacharbeiten sind je nach Anschluss noch wichtig

  1. Destination for incoming calls sollte umgestellt werden wenn man mehr als eine Rufnummer / Extension hat
  2. Die Codec preference sollte angepasst werden, G.722, G.711(A/U) überprüfen

[1]: https://geschaeftskunden.telekom.de/internet-dsl/tarife/festnetz-internet-dsl/deutschlandlan-sip-trunk/sip-trunk-technische-unterlage

Link to comment
Share on other sites

Beim Thema SRTP schien es etwas hin- und herzugehen. Zwischendurch ging es nur wenn man SRTP explizit ausgeschaltet hatte. Jetzt scheint es so zu sein, dass SRTP/SDES doch wieder geht (vermutlich gab es zu viele Geräte die es so machen so dass DTLS in der Praxis zu viele Probleme bereitet hat). Wir haben die Vorlage wieder entsprechend angepaßt. 

Thema Codec ist auch schwierig. Das liegt weniger an der Telekom, sondern daran dass die das SDP weiter reichen an die andere Stelle, die dann teilweise mit nicht G.711 ins Schlingern kommen. Daher ist G.711 sozusagen der kleinste gemeinsamer Nenner mit dem es am wenigsten Ärger gibt. Wenn G.722 nicht nativ auf den Endgeräten unterstützt wird klingt es schlechter als G.711. 

Bezüglich Zuordnung eingehender Anrufe sollte IMHO praktisch immer ein Präfix verwendet werden. Dann braucht man keine Telefonnummern anlegen, sondern nur dafür sorgen dass die Nummer hinter dem Präfix einer Nebenstelle (kann auch eine Gruppe sein) entspricht. 

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...