Wenn es die Firewall gewesen wäre, hätten wir wohl hier schon das erste Thema gehabt.
Kein Wunder, dass es kein INVITE gab - wenn der Anruf ganz wo anders hin geht…
Der Scrennshot zeigt Trunk-Weiterleitung bei 81-84. Ist das so gewollt - was steckt dahinter?
Nicht dass die 81-84 auch ganz wo anders hin gehen!?
In der eingehenden Rufregel wird ja bei Quelle und Ziel immer noch der * stehen!?
Nachtrag —
Was passiert denn überhaupt, wenn Du die Nummern anrufst? Was hörst Du… Was zeigt die CLI? —
Was hast Du denn für Up- / Downloadraten über VPN? Wenn die im Keller sind, kann es mit der Sprachquali schon mal schwierig werden. ggf hilft eine Priorisierung (QOS).
Mit dem Mobil-Client kann ich Dir nicht viel weiter helfen, da ich ihn noch nie genutzt habe. Das liegt an meinem Android 4.4 uralt-Knochen. Darauf läuft der Client nicht - erst ab 5.0
Wenn ich die Nummer 81-84 anrufe kommt wieder das Fräulein von SIpcall “Bitte rufen sie später an”.Also auch keine Infos in der CLI. “Trunk-Weiterleitung” kann ich nicht ändern. Habe den Sipcall-Support kontakitert.
Bei den Rufregeln habe ich unter Ziel beides probiert, mit * und mit der Nummer. bei der *80 funktioniert beides.
Am Montag bin ich wieder im Büro und kann dann mal die Gesprächsqualität ab den Snoms prüfen. QOS und VPN folgt dann später.
Wenn ich die Nummer 81-84 anrufe kommt wieder das Fräulein von SIpcall “Bitte rufen sie später an”.Also auch keine Infos in der CLI. “Trunk-Weiterleitung” kann ich nicht ändern. Habe den Sipcall-Support kontakitert.
Der Sipcall Support konnte die Weiterleitungen wieder einrichten und nun funktioniert das mit dem Trunk, die Nebenstellen klingeln korrekt, je nach gewählter Amtnummer.
Nun kriege ich es aber nicht hin, dass die Nebenstellen beim Telefonieren ihre Entsprechende Amtsnummer als CallerID anzeigen. Es erscheint im Display des Angerufenen immer die Hauptnummer. Gibt es hier noch Ideen? In der Pascom Dokumentation steht, es müsse ausprobiert werden.
Amt/Account/Rufnummern-Übermittlung mal auf PPI umstellen.
Wenn Du die Doku gelesen hast, die wichtigsten Asterisk-Variablen kenngelernt und die regular expression verinnerlicht hast,
wird Deine ausgehende Rufregel(n) hoffentlich passen…
Hallo @Tyrion und @nada Danke für eure Antworten. Habe gestern noch in der Moby Dick Schule auf Youtube geschaut und gesehen, dass es einen Extra Teil darüber in der Doku gibt, resp. Mass ich mir noch(mals) genau ansehen.
CNS, ClipNoScreening sollte eigentlich nicht aktiviert sein - jedenfalls nciht willentlich.
Wie könnte ich testen ob an der 19 liegt oder am Provider ?
es scheint als das die Pascom die richtige Nummer überträgt …
von 4144123456781
nach 079123456789
angezeigt wird jedoch die Trunkhauptnummer 4144123456780
`Clip is: auto
-- Executing [s@mdc_outgoing_predial:11] Verbose("PJSIP/mdc_trunk_conf-1-00000016",
"1,Default numer is: ") in new stack
Default numer is:
-- Executing [s@mdc_outgoing_predial:12] ExecIf("PJSIP/mdc_trunk_conf-1-00000016", "0?
Set(PJSIP_HEADER(add,P-Preferred-Identity)=<sip:4144123456781@business2.voipgateway.org>)") in new stack
-- Executing [s@mdc_outgoing_predial:13] ExecIf("PJSIP/mdc_trunk_conf-1-00000016", "0?
Set(PJSIP_HEADER(add,P-Asserted-Identity)=
<sip:4144123456781@business2.voipgateway.org>)")
in new stack
-- Executing [s@mdc_outgoing_predial:14] ExecIf("PJSIP/mdc_trunk_conf-1-00000016", "1?
Set(PJSIP_HEADER(add,P-Preferred-Identity)=
<sip:4144123456781@business2.voipgateway.org>)") in new stack
-- Executing [s@mdc_outgoing_predial:15] ExecIf("PJSIP/mdc_trunk_conf-1-00000016", "1?Set(PJSIP_HEADER(add,P-Asserted-Identity)=<sip:4144123456781@business2.voipgateway.org>)") in new stack
-- Executing [s@mdc_outgoing_predial:16] Return("PJSIP/mdc_trunk_conf-1-00000016", "") in new stack
== Spawn extension (mdc_incoming-1, 079123456789, 1) exited non-zero on 'PJSIP/mdc_trunk_conf-1-00000016'
-- PJSIP/mdc_trunk_conf-1-00000016 Internal Gosub(mdc_outgoing_predial,s,1) complete GOSUB_RETVAL=
-- Called PJSIP/079123456789@mdc_trunk_conf-1`
meine Optionen in der C18 (hier funktioniert es problemlos)
Hier steht auch “not in use” bei einer 19.04, vielleicht wird im UI einfach nur das falsche Feld dargestellt. Die Funktion sollte dadurch nicht beeinträchtigt werden.
![peer2|462x222]
