[Gelöst] FreePBX DID Telekom DeutschlandLAN SIP-Trunk

Bon_Go

Neuer User
Mitglied seit
22 Apr 2009
Beiträge
7
Punkte für Reaktionen
0
Punkte
1
Hallo Community,

gesucht habe ich schon, nichts passenden oder gar funktionierendes gefunden.

'Kurz' zur Konstellation: ich habe zwangsweise ein aktuelles Asterisk for Raspi mit FreePBX installiert um einen Telekom SIP Trunk benutzen zu können. Hintergrund ist dass der Anschluss ein ISDN Anlagenanschluss war, nun ein Telekom VOIP SIP Trunk Anschluss ist und die bisher am ISDN Anlagenanschluss genutzte Fritz!Box 7390 keinen Telekom SIP Trunk bedienen kann (Registrierungsprobleme wg. DNS Auflösung Anmeldeserver, TCP Protokoll usw. - whatever, kann halt keine Fritte). Im Prinzip wird die PBX auf dem Raspi nur als SBC für die Fritte genutzt da die bisherigen Endgeräte (mehr. DECT, analoges FAX usw.) weiterhin an der Fritte hängen und das soll auch so bleiben, einfache Sachen. Ausgehende und eingehende Anrufe von der Fritte über den Raspi und andersrum alles kein Ding, das geht erstmal. Telefonie 'tut'. Randnotiz zur Info: zentraler Router ist ein Lancom 1631 wg. VPN, der kann kein ISDN, Telefonie durch den durch geht halt.

Aber nun zum Problem: ich bekomme alle eingehenden Anrufe von dem SIP Trunk von aussen auf dem Raspi nur ohne DID / mit der DID 0 rein. Ich habe das log unter /var/log/asterisk/full immer in Beobachtung und da seh ich nix mit anderer DID oder Verarbeitungsregel die darauf hinweist. Ich hab bei Inbound Routes schon einiges probiert - hat alles nicht funktioniert. Wenn ich mit der Durchwahl 0 anrufe komme ich bei der damit per Inbound Route verbundenen Extension raus. Das gleiche passiert aber auch wenn ich z.B. die Durchwahl 1 anrufe: auch da komme ich bei der Extension die für die DID 0 definiert wurde raus und nicht bei der Extension die ich für die DID 1 definiert habe. Es geht mir letztlich um 3 Nummern für verschiedene Endgeräte (2 Telefonnummern + 1 Faxnummer). Aktuell ist es so dass alle eingehenden Anrufe bei der ersten Extension ankommen, die mit der DID 0. Ich hatte auch schon mal versucht für jede dieser Nummern einen eigenen SIP Trunk mit anderer Registrierung (die letzten Zahlen) anzulegen. Die 3 SIP Trunks sind alle registriert aber das klappt auch irgendwie nicht. Die Anrufe kommen scheinbar bei dem SIP Trunk rein der sich als letztes registriert hat und das ist immer mal ein anderer. Damit klappt das also auch nicht: alle eingehenden Anrufe landen dann wg. der Inbound Route bei der zu diesem einen (zuletzt registriertem?) Trunk passenden Extension.


Die SIP Settings des (einen einzigen / ersten) Trunks sind outgoing:
Code:
srvlookup=yes
type=peer
secret=<Passwort>
qualify=yes
nat=force_rport
insecure=invite
host=sip-trunk.telekom.de
fromuser=+49<Ortsvorwahl><Stammnummer>0
fromdomain=sip-trunk.telekom.de
realm=sip-trunk.telekom.de
dtmfmode=rfc4733
transport=tcp
progressinband=yes
disallow=all
allow=alaw
register=yes
tcpenable=yes
tlsenable=yes
defaultuser=<Telekom-Benutzername>@sip-trunk.telekom.de
session-timers=refuse

incoming:
Code:
user context: +49<vorwahl><Stammnummer>0
tcp://+49<Ortsvorwahl><Stammnummer>0:<Passwort>:<Telekom-Benutzername>@sip-trunk.telekom.de/+49<Ortsvorwahl><Stammnummer>0~240

Wo ist mein Fehler? Wo sollte ich nach der eingehenden DID suchen / wie kommt die PBX an die ran?

//edit by stoney: [CODE] TAGs [/CODE] gesetzt
 
Zuletzt bearbeitet von einem Moderator:
Zunächst muss ich sagen, dass ich den SIP Trunk der Telekom nicht kenne.
Würde aber vielleicht folgendermaßen ran gehen:

1. alle Inboundrules löschen.
2. eine Inboundrule ohne DID Angabe anlegen und die auf eine Nebenstelle schicken.

Jetzt müssten doch eigentlich alle Anrufe auf dieser Nebenstelle landen, und im CDR sollte man sehen können wie das DID Format ist.
 
  • Like
Reaktionen: Bon_Go
Für alle welche die Lösung suchen und falls der Link mal schlecht erreichbar ist:

Einen neuen chan_sip SIP Trunk anlegen

Reiter General:
Trunk Name vergeben, Outbound CallerID im Format <01234222220> eintragen (keine Länderkennung, Ortsvorwahl mit führender Null, Stammnummer und erste Durchwahlnummer des SIP Trunks), Maximum Channels begrenzen auf die Anzahl Sprachkanäle die verfügbar sind

Reiter Dialed Number Manipulation Rules kann erstmal belassen werden

Reiter sip Settings Reiter Outgoing:

Trunk Name: einen Namen vergeben
Peer Details:
Code:
videosupport=no
usereqphone=yes
type=peer
transport=tcp
srvlookup=yes
session-timers=refuse
secret=YYYYYYYYY
qualify=yes
insecure=invite
host=reg.sip-trunk.telekom.de
fromdomain=sip-trunk.telekom.de
dtmfmode=rfc2833
disallow=all
directmedia=no
defaultuser=55XXXXXXXX
allow=g722,alaw

Reiter sip Settings Reiter Incoming:
User Context: einen Namen vergeben
User Details:
Code:
videosupport=no
usereqphone=yes
type=peer
transport=tcp
srvlookup=yes
session-timers=refuse
secret=YYYYYYYYY
qualify=yes
insecure=invite
host=reg.sip-trunk.telekom.de
fromdomain=sip-trunk.telekom.de
dtmfmode=rfc2833
disallow=all
directmedia=no
defaultuser=55XXXXXXX
allow=g722,alaw
context=from-pstn-toheader

Register String :
Code:
tcp://[email protected]:YYYYYYYYY:[email protected]:5060

zu ersetzen ist:
Code:
+491zzzzzzz     +49 + Ortsvorwahl ohne 0 + Stammnummer, z.B. +49123422222
YYYYYYYYY       das Passwort für die Registrierung
55XXXXXXXX      Telekom-Benutzername

SIP Trunk speichern
Danach im Menü Settings / Asterisk SIP Settings
Reiter General SIP Settings:
Code:
T38 Pass-Trough     no   T-Kom hat kein T38 :(
Codecs: ulaw, alaw, g722, g726

Chan SIP Settings:
NAT und IP Configuration
Code:
Default Context     from-pstn-toheader
Bind Port           5060   (Chan PJSIP ausschalten oder anderen Port geben)
Enable SRV Lookup   Yes
Enable TCP          Yes


Nicht zu vergessen: eine Outbound Route für den Trunk erstellen / anpassen und ebenso Inbound Routes für die einzelnen DID oder was auch immer zu den jew. Extension, Queues, IVR, Ring Groups usw..

Maschine neu starten sinnvollerweise.
 
Super, Danke, ein praktischer Ansatz, verläuft aber auch leider im Sand bisher.

Ich habe alle Trunks gelöscht bis auf einen, die Stammnummer mit 0 hintendran überall bei der Registrierung angegeben, alle Inbound Rules gelöscht, eine Rule angelegt die auf eine Extension verweist und mal bei verschiedenen Nummern des SIP Trunks angerufen: im CDR steht unter DID immer die Nummer mit der sich der eine Trunk registriert hat, die Stammnummer mit der 0 hintendran.

Ich habe alle Trunks gelöscht bis auf einen, die Stammnummer _ohne_ 0 hintendran überall bei der Registrierung angegeben, alle Inbound Rules gelöscht, eine Rule angelegt die auf eine Extension verweist und mal bei verschiedenen Nummern des SIP Trunks angerufen: im CDR steht unter DID immer die Nummer mit der sich der eine Trunk registriert hat, die Stammnummer (ohne 0) halt.

Ich habe zwei SIP Trunks angelegt, bei dem einen geht die Registrierung mit Stammnummer mit 0 hintendran raus, bei dem zweiten Trunk mit einer 1 hintendran, sonst sind beide gleich, beide Trunks bei den Outbound Rules eingetragen, alle Inbound Rules gelöscht, eine Rule angelegt die alles annimmt und auf eine Extension verweist und mal bei verschiedenen Nummern des SIP Trunks angerufen: im CDR steht unter DID immer die gleiche DID, scheinbar die des einen SIP Trunks der sich zuletzt registriert hat. Mal war es die DID mit der Stammnummer + 0 hintendran, nach reboot die mit einer 1 hintendran - aber bei mehreren Anrufen an verschiedene Nummern dann halt immer die gleiche. Keine Lösung.

### Zusammenführung Doppelpost ###

Was ich noch gefunden habe: ich bin nicht der einzige mit dem Problem.

Unter https://telekomhilft.telekom.de/t5/...runk-mit-Asterisk-FreePBX/td-p/2724448/page/3 gibt es theoretisch einen Workaround.

Praktisch sieht es so aus dass ich in der Logdatei /var/log/asterisk/full bzw. im asterisk CLI (gestartet mit asterisk -rvvvv) ja nichtmal die Durchwahl sehe die ich anrufe. Beispiel: wenn ich die Nummer <Stammnummer>9 anrufe klingelt das Telefon, ich kann abheben und telefonieren - aber unter /var/log/asterisk/full oder im asterisk CLI steht immer nur die Nummer der SIP Trunk Registrierung drin, nicht die Nummer die ich anrufe.

### Zusammenführung Doppelpost ###


Ich habe nun das asterisk CLI mal mit asterisk -rvvvvvv -g -dddddd -c gestartet und angerufen, innerhalb 2 sek. wurden 11.460 Zeilen Text mit allen möglichen Debugmeldungen generiert. Ich habe nach allen Regeln der Kunst den Output durchsucht. Nirgends taucht die Durchwahl auf die ich angerufen habe. Immer ist es die Nummer mit der ich den SIP Trunk registriert habe (aktuell die Stammnummer ohne abschließende 0). Bei den geloggten Invites steht immer nur <Telekom-Benutzername>@sip-trunk.telekom.de .

### Zusammenführung Doppelpost ###


Ich taste mich langsam ran. Wenn ich auf dem asterisk CLI (start mit asterisk -r) den logger einschalte:
Code:
>core set verbose 5
>core set debug 5
>module reload logger
>sip set debug on
dann sehe ich mehr.

Ich habe von aussen die Durchwahl 9 angerufen. Es wurden knapp 22.471 Zeilen in 1,5 Sekunden generiert und da steht das vollständige SIP Protokoll drin, inklusive dem vollständigem INVITE und To: und dort dann der vollständigen Nummer die ich angerufen habe:

Code:
<--- SIP read from TCP:217.0.15.67:5060 --->
INVITE sip:+49<Ortsvorwahl><Stammnummer>@<int.IP_PBX>:5060;transport=tcp SIP/2.0
Via: SIP/2.0/TCP 217.0.15.67:5060;branch=xyz...
Record-Route: <sip:reg.sip-trunk.telekom.de;transport=tcp;lr>
Max-Forwards: 60
To: +49<Ortsvorwahl><Stammnummer>9 <sip:+49<Ortsvorwahl><Stammnummer>[email protected];user=phone>       <- TADAAAA
From: +49<Ortsvorwahl><Anrufernummer> <sip:+49<Ortsvorwahl><Anrufernummer>@sip-trunk.telekom.de;transport=udp;user=phone>;tag=6ddae2f0
Call-ID: xxx@xyz
Contact: <sip:<blabla>>
Supported: histinfo,timer
Session-Expires: 1900;refresher=uac
CSeq: 21871243 INVITE
Allow: ACK, BYE, CANCEL, INFO, INVITE, MESSAGE, OPTIONS, PRACK, REFER, REGISTER, UPDATE
Min-SE: 900
P-Asserted-Identity: <sip:+49<Ortsvorwahl><Anrufernummer>@sip-trunk.telekom.de;user=phone>
P-Called-Party-ID: <sip:+49<Ortsvorwahl><Stammnummer>[email protected];user=phone>    <- Hier auch
X-TAS-Edge-Policies: send-pheader-policy=772;redirection-handling=0;max-transp-rate=-1
Content-Type: application/sdp
Content-Disposition: session
Content-Length: 272


Wenn man dann noch ein klein wenig sucht dann findet man die Lösung hier:
https://community.freepbx.org/t/sip-trunk-deutsche-telekom/51002/5

Der entscheidende Punkt - neben einigen Änderungen bei der Registrierung des SIP Trunks wie dort beschrieben - ist die Anweisung context=from-pstn-toheader. Jetzt funktioniert alles.

//edit by stoney: [CODE] TAGs [/CODE] gesetzt und Doppelposts zusammengeführt
 
Zuletzt bearbeitet von einem Moderator:
Hi, ich stehe vor dem gleichen problem, bin deinem link gefolgt, allerdings etwas verwirrt, muss ich für jede rufnummer 2 trunks anlegen, eine für eingehend, eine für ausgehend ?

Ich beziehe mich auf trunkname IN und OUT aus der anleitung aus dem link...

Wie würden die inbound und outbound routes ausschauen?
Wäre für hilfe dankbar.
Lg
 
Zuletzt bearbeitet:
Nein, natürlich nicht. Ein Anbieter = ein SIP Trunk.

Du legst einen chan_sip Trunk wie oben beschrieben an. Beim Anlegen gibt es halt die Reiter outgoing und incoming, steht oben im Beitrag 4 in meinen Einstellungen haarklein alles drin. Das ist die Lösung zu meinem Problem #1.

Damit die angerufene Nummer (DID) in der Asterisk korrekt erkannt werden kann muss der Parameter context=from-pstn-toheader beim Anlegen des SIP Trunks bei incoming mit angegeben werden. Das steht oben in Beitrag 4 auch schon drin, hatte ich nachgetragen. Das ist die Lösung zu meinem Problem #2.

Outbound Route wäre z.B.: einfach nur ein X. bei match pattern [ / ]und dann halt den eingerichteten Trunk darunter auswählen so dass dieser für alle zu gewählten Nummern ausgehend benutzt wird.
Inbound Route wäre z.B.: wenn es auf dieser oder jener DID klingelt dann leite den Anruf an eine RingGroup oder Extension. Pro DID braucht es eine Inbound Route.

Schau mal https://dewiki.peoplefone.com/wiki/Konfiguration_FreePBX im unteren Teil, vielleicht hilft es dir das mit Bild zu sehen.
 
Hallo liebe Gemeinde,
auch ich habe in den letzten Tagen einen DTAG SIP-Trunk mit Asterisk 13 (trotz mehrmaliger Versicherung durch verschiedene DTAG-Mitarbeiter, dass es nicht funktioniere) in Betrieb genommen.
Im Prinzip haben die obigen Einstellungen bei mir sehr gut gepasst, jedoch gibt es zwei Punkte, die ich anders habe und der Allgemeinheit teilen möchte:

1. Habe ich einen Custom-Context angelegt, um die korrekte DID zu ermitteln. [from-pstn-toheader] ist nicht korrekt, da gem. der "technischen Unterlage" (vgl. https://geschaeftskunden.telekom.de.../blobBinary/SIP-Trunk-Technische-Unterlage.ps) die korrekte Nebenstelle im Header "P-Called-Party-ID" mitgeteilt wird und nicht im To-Header. Das ist bei mir insofern aufgeschlagen, als dass Ortsgespräche (insbesondere von KabelDeutschland) nicht im E.164-Format angekommen sind, sondern nur mit der Ortsrufnummer, ohne Länderkennung/ONKZ. Dazu habe ich in der Datei /etc/asterisk/extensions_custom.conf folgenden Teil eingefügt (Vorlage aus from-pstn-toheader):
Code:
[from-pstn-pcpid]
; TELEKOM SIP-Trunk
: https://geschaeftskunden.telekom.de/blobCache/umn/uti/457678_1548405575000/blobBinary/SIP-Trunk-Technische-Unterlage.ps
; https://www.telekom.de/hilfe/downloads/1tr118-11.pdf
;
; Vorgehensweise: 1. Aufteilung ob SIP oder PJSIP, Fallback: weiter zu from-pstn, im Zweifel: Fallthrough
;                 2. aus dem P-Called-Party-ID-Header alles vor dem "@"-Zeichen ausschneiden und als exten an from-pstn schicken.
;                 3. weiter wie "normal"
;
exten => _.,1,NoOp(Attempting to extract DID from SIP To header)
same => n,gotoif($["${CHANNEL(channeltype)}"="SIP"]?SIP)
same => n,gotoif($["${CHANNEL(channeltype)}"="PJSIP"]?PJSIP)
same => n,NoOp(Unable to determine SIP channel type)
same => n,goto(from-pstn,${exten},1))
same => n(SIP),Goto(from-pstn,${CUT(CUT(SIP_HEADER(P-Called-Party-ID),@,1),:,2)},1)
same => n(PJSIP),Goto(from-pstn,${CUT(CUT(PJSIP_HEADER(read,P-Called-Party-ID),@,1),:,2)},1)

2. Bei Rufumleitungen wird im Standardfall der Anruf weiterhin über die PBX geführt und benötigt damit Ressourcen. Bereits bei ISDN gab es die Funktionalität "Call Deflection" (CD), welche über den D-Kanal signalisiert, dass der Anruf umgeleitet wird und die (beiden, da hin und retour) B-Kanäle freiräumt. Der zweite Vorteil von CD liegt darin, dass die Rufnummer des ursprünglich Anrufenden (A) am Zieltteilnehmer (C) angezeigt wird und nicht die Rufnummer des ursprünglich Angerufenen (B).
Dazu hatte ich bereits in der Vergangenheit einen Codeschnipsel in der oben genannten extensions_custom.conf, welcher den Anruf via SIP 302 Transferiert und das SIP-VoIP-Gateway in den CD "übersetzt". Diesen habe ich nur leicht (DID, von YYYY auf +49XXXXYYYY) anpassen müssen. Man könnte sich noch überlegen, ob man den [from-pstn-custom] auf die exten => s matcht, aber da wir nur eine Stammrufnummer haben, tut es das an dieser Stelle und bringt möglicherweise ein bisschen Sicherheit mit.

Code:
[from-internal-custom]
; Anrufweiterleitung ("Call Deflection") intern/extern erkennen
;
; Vorgehensweise: 1. Auf alle ausgehenden Anrufe reagieren; wenn ausgehende Rufnummer mit + beginnt, dies durch "000" ersetzen (Notwendig für Rückrufe über die Nebenstellen)
;                 2. Auf alle ausgehenden Anrufe reagieren; Debuggingvariablen anzeigen
;                 3. ggf. diverse Variablen ausgeben (normal auskommentiert)
;                 4. Auswerten, ob der Anruf von extern oder intern kommt (anhand von ORIGCHANNEL) und entsprechend entweder als SIP 302 (Transfer) an den Provider schicken oder einen neuen Anruf starten
;
exten => _X.,1,ExecIf($[ "${CALLERID(num):0:1}" = "+" ]?Set(CALLERID(num)=000${CALLERID(num):1}))
same => n,Noop(ORIGCHANNEL=${ORIGCHANNEL}::RDNIS=${CALLERID(rdnis)}::ANI=${CALLERID(ani)}::DNID=${CALLERID(dnid)}::CHANNELTYPE=${CHANNEL(channeltype)})
;same => n,Noop(${OUT_1})
;same => n,Noop($["${EXTEN:0:1}"=="0"])
; Wenn der Quellkanal aus dem Trunk (1. Trunk = OUT_1; 2. Trunk = OUT_2; ...) kommt, dann kann man den Quellkanal umleiten und via SIP 302-Move temp. ein Call Deflection auslösen
same => n,ExecIf($["${ORIGCHANNEL:0:3}"=="SIP" & "${EXTEN:0:1}"=="0"]?ChannelRedirect(${ORIGCHANNEL},back2provider,${EXTEN:1},1)
; Wenn der Quellkanal nicht aus dem Trunk kommt, dann geht's ganz normal weiter mit wählen.
same => n,ExecIf($["${ORIGCHANNEL:0:3}"!="SIP" | "${EXTEN:0:1}"!="0"]?Goto(from-internal-additional,${EXTEN},1))

[back2provider]
; Call Deflection / SIP 302 an Provider schicken und Transferstatus als Variable anzeigen. Damit ist für die TK-Anlage der Anruf beendet.
;
exten => _X.,1,Transfer(${EXTEN})
same => n,NoOp(TRANSFERSTATUS=${TRANSFERSTATUS})
same => n,Hangup()

[from-pstn-custom]
; -- Fügt bei eingehenden Anrufen die Variable ORIGCHANNEL ein, um den ursprünglichen Kanal wieder zu erreichen und umzuleiten --;
; Auf alle eingehenden Anrufe reagieren; Debuggingvariablen anzeigen
exten => _+49XXXXYYYY.,1,Noop(RDNIS=${CALLERID(rdnis)}::ANI=${CALLERID(ani)}::DNID=${CALLERID(dnid)})
same => n,Set(__ORIGCHANNEL=${CHANNEL})
same => n,Goto(ext-did-0002,${EXTEN},1)

PS: An der Firewall (pfSense) habe ich folgende Settings - abweichend von der offizielen pfSense-Doku aktiv:
- System/Advanced/Firewall & NAT => Firewall Optimization Options = Conservative
- Outbound von der TK-Anlage ins Internet: TK (Port any) => IP any (Port 5060) (TCP)
- Outbound von der TK-Anlage ins Internet: TK (Port 30000:30100) => IP any (Port any) (UDP)
- Inbound: nix
- NAT: nix

Die ausgehenden RTP-Ports (30000-30100) habe ich in der FreePBX unter SIP-Settings definiert.

Viele Grüße

Bastolino

Edit: eingefügt, dass bei ausgehenden Rufnummern im E.164-Format diese mit führender "0" auch wieder ausgegeben werden, jedoch nicht mit "+" sondern mit "00".
 
Zuletzt bearbeitet:
Hallo,

vielen Dank für diese Beispiele! Da ich diesen Thread erst jetzt gesehen habe, mich die Anbindung eines Telekom-SIP-Trunks an Asterisk aber seit einer Woche auch umtreibt: Geht das mit der "302 Moved Temporarily"-Call Deflection nicht auch mit Bordmitteln? Andernorts bin ich nämlich auf das Flag "promiscredir" gestossen, das standardmässig ausgeschaltet ist, das man aber z. B. auf dem SIP-Channel des Telekom SIP-Trunks einschalten könnte.

Auf https://www.storck.net/tipps/asterisk-am-telekom-sip-trunk/ steht, dass man dann neben Einschalten von progressinband auch noch send_diversion abschalten müsse, damit die Telekom-Infrastruktur das akzeptiere.

Ich komme gerade nicht dazu, meine Experimente fortzusetzen.

Grüsse
Philipp
 
Hallo Philipp,

Ich habe es mit den Boardmitteln nicht ohne weiteres hinbekommen, allerdings ist das Setup, das ich an dieser Stelle nur migriert habe, auch schon einige Jahre laufend gewesen. Ich bin mir nicht mehr 100%ig sicher, aber ich glaube mein Hauptproblem war damals, dass nicht ein 302 sondern ein 301 zurückgesendet wurde. Meine Erinnerung mag mich täuschen. Wenn du es hinbekommst mit promiscredir, würde ich mich über eine kurze Info und die entsprechenden Schnipsel deiner Config sehr freuen!
Aktuell ist leider Hochsaison, sodass ich Änderungen erst wieder im November vornehmen möchte/darf.

Viele Grüße
Bastolino

PS: Trotzdem danke für den Link, den kannte ich noch nicht und dort wird mein Problem mit der "Amts-null" subjektiv schöner gelöst als bei mir.
 
Hallo Bastelino,

vielen Dank für Deine Antwort! Nachdem ich nun verstanden habe, was die Asterisk Apps ChannelRedirect und Transfer() und der sip.conf-Parameter promiscredir genau bewirken, und die Idee Deines Dialplan-Fragments durchdrungen habe, glaube ich nicht mehr an eine Lösung mit Bordmitteln. Ich hatte endlich Gelegenheit, das Fragment auszurollen, und kann bestätigen, dass es seinen Zweck voll erfüllt! Zwar kam vereinzelt eine Verbindung ohne Ton zustande, aber ich sehe die Ursache in den vielen Variablen im PSTN, nicht in der Asterisk-Konfiguration, denn meist funktioniert es super. Meine Teststrecke: Initiator: VoIP-Anschluss von Tal.de / OpenNumbers / Equada, Asterisk mit o. g. Dialplan-Fragment an Telekom Deutschland Lan SIP Trunk, Deflection auf Schweizer Mobilfunknummer bei Sunrise.

Beste Grüsse
Philipp
 
Liebes Forum,

nun konnte ich einige Zeit lang Erfahrung mit o. g. Konfiguration sammeln. Die Asterisk App Transfer() unterstützt (mindestens) zwei Arten von Weiterleitung: "302 Moved Temporarily"-Call Deflection und die SIP "REFER"-Methode. Offenbar wählt Transfer() erstere, falls der Channel bislang nicht beantwortet wurde, und letztere, wenn er explizit oder implizit, z. B. durch eine zwischenzeitlich abgespielte Ansage, beantwortet worden ist. Ersteres funktioniert am Telekom DeutschlandLAN SIP-Trunk tadellos, letzteres führt leider zu einer Ablehnung:
Code:
[FONT=courier new]REFER sip:<deleted>@th1 SIP/2.0
Via: SIP/2.0/TCP <deleted>:5060;branch=<deleted>
Route: <sip:reg.sip-trunk.telekom.de;transport=tcp;lr>
Max-Forwards: 70
From: <sip:<deleted>@verizon.de;user=phone>;tag=<deleted>
To: <sip:[email][email protected][/email]>;tag=<deleted>
Contact: <sip:<deleted>@<deleted>:5060;transport=TCP>
Call-ID: <deleted>@<deleted>
CSeq: 102 REFER
User-Agent: Asterisk PBX 11.25.3
Date: Mon, 31 Aug 2020 19:53:55 GMT
Refer-To: <sip:<deleted>@anonymous.invalid>
Referred-By: <sip:<deleted>@<deleted>:5060;transport=TCP>
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH, MESSAGE
Supported: replaces, timer
Content-Length: 0


---

<--- SIP read from TCP:<deleted>:5060 --->
SIP/2.0 405 Method Not Allowed
Via: SIP/2.0/TCP <deleted>:5060;branch=<deleted>
Record-Route: <sip:reg.sip-trunk.telekom.de;transport=tcp;lr>
To: <sip:[email][email protected][/email]>;tag=<deleted>
From: <sip:<deleted>@verizon.de;user=phone>;tag=<deleted>
Call-ID: <deleted>@<deleted>
Contact: <sip:<deleted>@th1>
CSeq: 102 REFER
Allow: ACK, BYE, CANCEL, INFO, INVITE, MESSAGE, OPTIONS, PRACK, PUBLISH, REGISTER, SUBSCRIBE, UPDATE
Reason: TSSI;cause=4050003
Content-Length: 0[/FONT]
[Edit Novize: Log in Code-Tags gepackt]

Was "Reason: TSSI;cause=4050003" genau heisst, erschliesst sich mir nicht, im Netz findet man speziell betr. Telekom Deutschland ähliche Codes gegenüber anderen PBXs. Zur Anonymisierung habe ich diverse IP-Adressen, Telefonnummern etc. in o. g. SIP-Mitschnitt durch <deleted> ersetzt. Insbes. gilt aber, dass in "Refer-To:" das korrekte Ziel steht.

Vorläufig behelfe ich mir mit einem auf die Asterisk Channel-Variable ${TRANSFERSTATUS} gestützten Workaround: Schlägt Transfer() fehl, wird per Asterisk App Dial() innerhalb von [back2provider] über einen zweiten Kanal zum Ziel heraustelefoniert. Das funktioniert, freilich sieht der schlussendlich Angerufene dann nicht mehr die Nummer des Anrufers, sondern die Hauptnummer des Rufnummernblocks (könnte man nach Freischaltung von CLIP no screening vermutlich ändern).

Falls jemand einen ursächlichen Fix kennt (kann auch im Update von Asterisk bestehen), wäre ich über eine kurze Mitteilung dankbar.

Lieber Gruss
Philipp
 
Zuletzt bearbeitet von einem Moderator:
Hi Philipp,
entschuldige die späte Rückmeldung - ich hab's erst jetzt durch Zufall gelesen.
Würdest du uns an deinem Workaround auch teilhaben lassen? Tatsächlich habe ich das Problem zwar aktuell noch nicht, aber wer weiß, wer sich darüber freut :)
Ansonsten vielen Dank!
LG Basti
 
Hallo Basti,

ich bin hier nicht wirklich aktiv und sehe Deine Bitte erst jetzt (bzw. habe eine etwaige Benachrichtigung darüber in meiner Mailbox übersehen). Das tut mir leid.

[Edit Novize: Überflüssiges Fullquote des Beitrag direkt darüber gelöscht - siehe Forumsregeln]
Sehr gerne hier mein Wählplan-Fragment:

Code:
[back2provider]
; Depending on whether the call has already been answered, either forward call using "REFER" or deflect call using "302 Moved Temporarily".
exten => _X!,1,Transfer(${EXTEN})
 same => n,GotoIf($[foo${TRANSFERSTATUS} = fooSUCCESS]?hangup)
 same => n,NoOp(Deflection or referral failed, falling back to outbound call via second line...)
 same => n,Gosub(dial-outbound,s,1(${EXTEN},-1))
 same => n(hangup),Hangup

"dial-outbound" ist meine Routine, die letztlich via Asterisk-Application "Dial" eine Verbindung über unseren SIP-Provider zum Ziel aufbaut. Hätten wir beim Provider (Deutsche Telekom) das Leistungsmerkmal "CLIP no screening" beauftragt, könnten wir vermutlich die CallerId auf die Quelle des Anrufs umbiegen, so dass für den Angerufenen gar nicht unterscheidbar wäre, ob REFER bzw. 302 funktioniert haben oder die Verbindung durch die PBX geschleift werden musste.

Lieber Gruss
Philipp
 
Zuletzt bearbeitet von einem Moderator:
Holen Sie sich 3CX - völlig kostenlos!
Verbinden Sie Ihr Team und Ihre Kunden Telefonie Livechat Videokonferenzen

Gehostet oder selbst-verwaltet. Für bis zu 10 Nutzer dauerhaft kostenlos. Keine Kreditkartendetails erforderlich. Ohne Risiko testen.

3CX
Für diese E-Mail-Adresse besteht bereits ein 3CX-Konto. Sie werden zum Kundenportal weitergeleitet, wo Sie sich anmelden oder Ihr Passwort zurücksetzen können, falls Sie dieses vergessen haben.