Posts by Merlin

    Hallo,


    tatsächlich haben wir den Fehler auch. Er tritt aber sehr selten auf. Wir nutzen einen Telekom SIP Trunk und für Mobilfunk Starface Connect. Stand 13.06.2023 beobeachten wir auch Probleme mit 7.3 Anlagen, aber immer im Zusammenspiel mit Telekomanschlüssen. Ist natürlich nur eine Vermutung, aber mir scheint das die Telekom wieder irgendetwas bastelt.


    VG

    Merlin

    Hallo Joshua,


    wenn ich das richtig sehe, ist das ein Telekom SIP-Trunk. Ich hatte gestern das Problem auch. Bei uns in der Firma selbst und auch beim Kunden. Andere Telekomprodukte hatten das nicht. - sofern ich das beurteilen kann. Sieht mir nach einem externen Problem aus.


    VG

    Merlin

    Hallo Zusammen,


    ich habe folgendes Problem. Ich habe beim Kunden eine Cloud eingerichtet. Soweit so gut. Dann habe ich den Leitungen zwei Nummern des SIP Providers registriert, diese sind auch grün.

    Ausgehende Rufe sind kein Problem. Bei eingehenden Rufen passieren komische Sachen. Und zwar wird als DialedNumber im Log einmal der SIP-Benutzername angezeigt. Das hat zur Folge, dass eingehnde Rufe nicht signalisiert werden, da die Anlage die Nummer nicht kennt. Anschließend probiert die Anlage diese Nummer extern anzurufen, was scheitert. Zu sehen ist das unten im Log.

    Wenn ich dann wieder diese Nummer anrufe funktioniert es! Als DialedNumber steht jetzt die richtige Rufnummer drin und die Anlage kann die Nummer der passenden Gruppe zuordnen und klingel lassen. Dieser Zustand ändert sich minütlich ohne ersichtlichen Grund. Mal funktioniert es, mal nicht. Hierzu die Logs:


    Eingehnder Ruf der nicht funktioniert:

    [2023-03-15T11:41:32,828] [ 0396 ] ********* Call created **********

    [2023-03-15T11:41:32,828] [ 0396 ] Starting call routing : SIP/1219185-0000018c dial number 1219791 CallerId [number=0049XXXX56811171]

    [2023-03-15T11:41:32,839] [ 0396 ] Routing call "CallerId [dialedNumber=1219791, number=0049XXXX56811171]" to number 1219791 over service OutgoingService

    [2023-03-15T11:41:32,839] [ 0396 ] CallLeg: 2fc20675-3a77-44b2-9c41-527f3e499861

    [2023-03-15T11:41:32,839] [ 0396 ] No line found routing: LINE rejecting call

    [2023-03-15T11:41:32,840] [ 0396 ] Got dialstatus DialReturnCodes(hc=CALL_REJECTED, ds=UNKNOWN, cr=UNKNOWN)

    [2023-03-15T11:41:32,841] [ 0396 ] Hangup Cause: CALL_REJECTED | SIP/1219185-0000018c

    [2023-03-15T11:41:32,841] [ 0396 ] ********* Call finished *********

    [2023-03-15T11:41:40,045] [ ---- ] Incoming call from line 13085037(1008)

    [2023-03-15T11:41:40,045] [ ---- ] Found extension on line 13085037(1008) 00XXXXX13085037


    Eingehnder Ruf der funktioniert

    [2023-03-15T11:41:40,045] [ 0397 ] ********* Call created **********

    [2023-03-15T11:41:40,045] [ 0397 ] Starting call routing : SIP/1219185-0000018d dial number 0049XXX13085037 CallerId [number=0049XXXX6811171]

    [2023-03-15T11:41:40,051] [ 0397 ] Routing call "CallerId [dialedNumber=13085037, number=0049XXXX6811171]" to number 00XXXX13085037 over service RingAllGroupService

    [2023-03-15T11:41:40,051] [ 0397 ] CallLeg: c9bc8756-a98f-4739-8782-164124089ca6

    [2023-03-15T11:41:40,151] [ 0397 ] Dial | SIP/1219185-0000018d -> SIP/1030.N510IP-0000018e

    [2023-03-15T11:41:40,151] [ 0397 ] Dial | SIP/1219185-0000018d -> SIP/1023.ylnkt58w-0000018f

    [2023-03-15T11:41:40,151] [ 0397 ] Dial | SIP/1219185-0000018d -> SIP/1011.ylnkt58w-00000190

    [2023-03-15T11:41:40,151] [ 0397 ] Dial | SIP/1219185-0000018d -> SIP/1031.N510IP-00000191

    [2023-03-15T11:41:40,218] [ 0397 ] Channelstate is RINGING | SIP/1023.ylnkt58w-0000018f

    [2023-03-15T11:41:40,226] [ 0397 ] Channelstate is RINGING | SIP/1011.ylnkt58w-00000190

    [2023-03-15T11:41:40,695] [ 0397 ] Channelstate is RINGING | SIP/1030.N510IP-0000018e

    [2023-03-15T11:41:40,726] [ 0397 ] Channelstate is RINGING | SIP/1031.N510IP-00000191

    [2023-03-15T11:41:40,996] [ 0397 ] Hangup Request Event | SIP/1219185-0000018d

    [2023-03-15T11:41:40,997] [ 0397 ] DialEnd with dialstatus CANCEL | SIP/1219185-0000018d -> SIP/1030.N510IP-0000018e

    [2023-03-15T11:41:40,997] [ 0397 ] DialEnd with dialstatus CANCEL | SIP/1219185-0000018d -> SIP/1023.ylnkt58w-0000018f

    [2023-03-15T11:41:40,997] [ 0397 ] DialEnd with dialstatus CANCEL | SIP/1219185-0000018d -> SIP/1011.ylnkt58w-00000190

    [2023-03-15T11:41:40,997] [ 0397 ] DialEnd with dialstatus CANCEL | SIP/1219185-0000018d -> SIP/1031.N510IP-00000191

    [2023-03-15T11:41:40,997] [ 0397 ] Hangup Cause: NORMAL_CLEARING | SIP/1030.N510IP-0000018e

    [2023-03-15T11:41:40,998] [ 0397 ] Hangup Cause: NORMAL_CLEARING | SIP/1023.ylnkt58w-0000018f

    [2023-03-15T11:41:40,998] [ 0397 ] Hangup Cause: NORMAL_CLEARING | SIP/1011.ylnkt58w-00000190

    [2023-03-15T11:41:40,998] [ 0397 ] Hangup Cause: NORMAL_CLEARING | SIP/1031.N510IP-00000191

    [2023-03-15T11:41:40,998] [ 0397 ] Hangup Cause: NOTDEFINED | SIP/1219185-0000018d

    [2023-03-15T11:41:41,011] [ 0397 ] ********* Call finished *********

    [2023-03-15T11:41:41,012] [ 0397 ] Got dialstatus DialReturnCodes(hc=CALL_REJECTED, ds=CANCEL, cr=UNKNOWN)


    Laut Dokumentation des Providers siganlisiert dieser bei eingehnden Rufen: "SIP-Registered-Contact (in der Regel der SIP-Benutzername) z.B. 123456"
    Beim Provider handelt sich um DBN.

    Hat jemand eine Idee wie ich das Leitungsprofil anpassen kann, das es sauber funktioniert? Bzw. kennt jemand das Problem?


    VG
    Merlin

    Hallo Zusammen,


    weiß jemand, ob es ein Modul für folgenende Anwendung gibt. Ein Kunde muss aus rechtlichen Gründe Gespräche aufzeichnen. In Zukunft sollen diese automatisch dem Kunden in einer Dritten Software zugeordnet werden. Dafür muss der Dateiname des Mitschnittes ein bestimmtes Format haben, bspw. Telefonummer_Datum_Uhrzeit. Und diese Mitschnitte müssen aus der Anlage exportiert werden. Kennt jemand ein Modul, welches diese Anfoderung umsetzten kann?


    VG
    Merlin

    Hi,


    das Problem hatte ich auch bei einem Kunden. Hat ca. 5 Tage gedauert bis es behohben war. Und den genauen Grund bzw. die Lösung kenne ich leider auch nicht.

    Wir haben bei Starface ein Ticket eröffnet. Die wollten ein Dump mit Fehlerbeschreibung etc. Antwort kam recht zügig - 1-2 Tage später. Wir sollten sicherstellen das SIPTRUNK.DE von der Starface aus erreichbar ist. ich hatte das per SSH gepingt. War möglich! Am Wochenende danach war es weg.

    Unsere Meinung war die Fehlerquelle die URI zur Anmelung am SIP Provider -> siehe mein Thread Telekom Voice/ Data - Keine Registrierung der Leitungen - Error 400


    Ich wünsche dir viel Erfolg.

    War ein ziemlicher sch***


    VG

    Merlin

    Hallo zusammen,

    wir haben seit einigen Tagen das Problem, dass sich ein Teil der von Voice/ Data Nummern nicht registrieren. Andere wiederrum funktionieren. Alles der gleiche Anschluss! Nach verändern und anpassen jeglicher erdenklichen Einstellung ist beim Auslesen des Netzwerktraffics aufgefallen, dass sich die Nummern mit folgendem URI registrieren wollen:

    sip:sip:tel.t-online.de


    Die Nummern die an funktionieren melden sich mit folgendem URI:

    sip:tel.t-online.de


    Sprich nur einmal das Protokoll voransetzten. Wir verwenden aber überall das gleiche Provider-Profil.


    Hat jemand eine Idee wie man diesen Fehler behebt?


    VG

    Merlin


    Im Anschluss nochmal der gesamte Auszug.

    Leitung die sich registriert:


    REGISTER sip:tel.t-online.de SIP/2.0


    Via: SIP/2.0/UDP 10.1.122.130:5060;branch=z9hG4bK6c350015


    Max-Forwards: 70


    From: <sip:089922XXXXX@tel.t-online.de>;tag=as25abb21c


    To: <sip:089922XXXXXX@tel.t-online.de>


    Call-ID: 416451703950e6e70bd39abb3d7bbc70@tel.t-online.de


    CSeq: 103 REGISTER


    Supported: replaces, timer


    User-Agent: STARFACE PBX


    Authorization: Digest username="schecxxxxxx.xxxx@t-online.de", realm="tel.t-online.de", algorithm=MD5, uri="sip:tel.t-online.de", nonce="4e42414e4241b37909dccd6ee8c08ac4da723758ef7e", response="e947c88ef0abbc6170387f5b55405407", qop=auth, cnonce="2fcb654d", nc=00000001


    Expires: 600


    Contact: <sip:92283492@10.1.122.130:5060>


    Content-Length: 0


    Leitungen die sich nicht registrieren:


    REGISTER sip:tel.t-online.de SIP/2.0


    Via: SIP/2.0/UDP 10.1.122.130:5060;branch=z9hG4bK5cdfa6c4


    Max-Forwards: 70


    From: <sip:0897XXXXXXX@tel.t-online.de>;tag=as03540940


    To: <sip:0897XXXXXXX@tel.t-online.de>


    Call-ID: 463abc0a41c3c8892eab44a54f85d9cc@tel.t-online.de


    CSeq: 103 REGISTER


    Supported: replaces, timer


    User-Agent: STARFACE PBX


    Authorization: Digest username="bauXXXXXXXX@t-online.de", realm="tel.t-online.de", algorithm=MD5, uri="sip:sip:tel.t-online.de", nonce="f30b87769259c1679db909f92aab55fb", response="fa5421c1543c65fbdc98137d2505dbaa", qop=auth, cnonce="06bf9ce1", nc=00000001


    Expires: 600


    Contact: <sip:74548151@10.1.122.130:5060>


    Content-Length: 0



    Hallo Zusammen,


    ich habe folgendes Problem. Appliance Compact v3 auf Version 6.6. Ich habe Connect aktiviert, leider registrieren sich die Leitungen nach 2 Tagen immernoch nicht. Mit Connect gesprochen -> Connect ist aktiviert das passt alles. Alle benötigten Ports sind offen. Neugestartet etc. alles gemacht was dazu gehört.

    Hat noch jemand eine Idee, oder hatte das Problem schon einmal?


    MfG

    Merlin

    Nein leider nicht.
    Was ein bisschen komisch ist, das dieser Fehler zeitlich gut mit dem Update auf ST7 zusammenpasst.
    Muss ich eventuell in Telefone --> ID-Anzeige etwas umstellen? Wenn ja, vielleicht weiß jemand was und wo? Diese Einstellungen sind angeblich nicht Update sicher.
    Grüße,
    Merlin

    Hallo Jens,


    das Problem hatte ich auch schon. Allerdings war das ein Client der über die externe IP auf die Anlage zugreift.
    Ich habe bei Server --> Netzwerk auf Hinter NAT --> Ja umgestellt dann ging es.
    Bei dem Kunden macht die FritzBox DSL auf eine Firewall als Exposed Host.
    Vielleicht hilft dir das weiter.


    Grüße,
    Merlin

    Hi all,


    ich habe folgendes Problem:
    beim Kunden wurde die Hardware Appliance auf ST7 geupdatet.
    Seitdem funktioniert dieses Szenario nicht mehr:
    Der Kunde hat eine Zusammenarbeit mit einer anderen Firma. Bei dieser Firma ist eine Weiterleitung auf seine Nummer eingerichtet.
    Wenn die Weiterleitung bei der "externen" Firma aktiv war, wurde die Nummer in der ST6.7 angezeigt, welche die Nummer der "externen" Firma angerufen hat. So konnte der Kunde direkt diese Nummer zurückrufen.
    Seit dem Update wird in der Anrufliste die Nummer der "externen" Firma angezeigt und nicht die des ursprünglichen Anrufers. Der Kunde kann den ursprünglichen Anrufer nicht zurückrufen.
    Ist das ein Fehler der Starface7, weiß das jemand?
    Wenn nicht, wie wird das auf der Anlage richtig konfiguriert?


    danke schonmal :)


    Grüße,
    Merlin

    Hallo Zusammen,


    bei uns ist das Probelm erst heute morgen aufgetreten. Gibt es eine Lösung dafür, sobald der lizenzserver wieder da ist? Neustart der Anlage o.Ä.?


    Gruß
    Merlin

    Hallo zusammen,


    Fabian, leider hat das auch nicht geholfen... Ich will einen Kofiguarationsfehler nicht ausschließen, aber ich bin das Szenario mehrfach durchgegangen - es sollte nach meinem Verständnis so funktionieren.
    Was könnte ich noch machen?


    Martin, es ist Version 6.7.3.11


    Ich bin für jede Hilfe offen :)


    Lg,
    Merlin

    Hallo Fabian,


    erstmal vielen Dank für deine schnelle Rückmeldung.


    das ist das Log von der ZGU, die auf den AB von Standort2 umleiten soll.


    [2021-09-09 16:56:06,831] INFO [main] 00498...
    [2021-09-09 16:56:06,832] DEBUG [isCalledNumberMatched] 00498... matches positive list
    [2021-09-09 16:56:06,832] INFO [isCallerNumberMatched] 00498... matches positive list
    [2021-09-09 16:56:06,832] DEBUG [Execute] Executing Asterisk Application Command: Progress
    [2021-09-09 16:56:06,887] DEBUG [Execute] Execution took 55 ms
    [2021-09-09 16:56:06,887] DEBUG [Execute] Executing Asterisk Application Command: Playback(silence/1)
    [2021-09-09 16:56:08,490] DEBUG [Execute] Execution took 1602 ms
    [2021-09-09 16:57:14,934] INFO [main] 00498...
    [2021-09-09 16:57:14,935] DEBUG [isCalledNumberMatched] 00498... matches positive list
    [2021-09-09 16:57:14,936] INFO [isCallerNumberMatched] 00498... matches positive list
    [2021-09-09 16:57:14,936] DEBUG [Execute] Executing Asterisk Application Command: Progress
    [2021-09-09 16:57:14,987] DEBUG [Execute] Execution took 51 ms
    [2021-09-09 16:57:14,987] DEBUG [Execute] Executing Asterisk Application Command: Playback(silence/1)
    [2021-09-09 16:57:16,590] DEBUG [Execute] Execution took 1603 ms


    Das ist das Log von der ZGU die, die Nummer für die obere ZGU auf der Ausnahmenliste hat.


    [2021-09-09 17:02:53,273] INFO [main] 00498...
    [2021-09-09 17:02:53,277] DEBUG [isCalledNumberMatched] 00498... matches negative list
    [2021-09-09 17:02:53,277] INFO [main] Target number not matched. Exit.
    [2021-09-09 17:02:54,949] INFO [main] 93
    [2021-09-09 17:02:54,953] DEBUG [isCalledNumberMatched] 93 matches positive list
    [2021-09-09 17:02:54,954] INFO [isCallerNumberMatched] 00498... matches positive list
    [2021-09-09 17:02:54,954] DEBUG [Execute] Executing Asterisk Application Command: Progress
    [2021-09-09 17:02:54,956] DEBUG [Execute] Execution took 2 ms
    [2021-09-09 17:02:54,956] DEBUG [Execute] Executing Asterisk Application Command: Playback(silence/1)
    [2021-09-09 17:02:55,976] DEBUG [Execute] Execution took 1020 ms


    Ich hoffe das hilft weiter :)


    lg
    Merlin

    Liebe Starface-Kollegen,


    in der Anlage eines Kunden tritt folgendes Problem auf.
    Der Kunde hat zwei Standort die beide über eine Anlage bedient werden. Außerhalb den Geschäftszeiten möchte der Kunde - wenn
    Standort1 angerufen (die Telefonnummer von Standort1) wird, dass der entsprechende Anrufbeantworter annimmt. Das gleiche Spiel
    für Standort2 mit eben einem extrigen AB und einer anderen Nummer.
    Dieses Szeanrio ist auf der Anlage wie folgt gelöst. Es gibt eine ZGU die alle eingehenden Nummer auf eine Gruppe umleitet,
    welche dann mit einer IMMER-Umleitung auf den AB des Standort1 umleitet. In dieser ZGU sind Ausnahmen gesetzt und zwar
    die Nummern von Standort2. Dann gibt es eine zweite ZGU, die die Nummern die als Ausnhamen in der ersten ZGU gesetzt sind
    jetzt als eingehende Nummer hat. Sprich die Ausnahmen aus der ersten ZGU werden mithilfe einer zweiten ZGU auf eine andere Gruppe umgeleitet,
    die dann mit einer IMMER-Umleitung auf den AB des Standort2 umleitet.
    Das Problem ist, dass das nicht funktioniert. Wenn ich die Nummer von Standort2 anrufe, werde ich auf den AB von Standort1 weitergeleitet,
    obwohl eben diese Nummer als Ausnahmen gesetzt sind.
    Außerdem sind in der ersten ZGU die Faxnummern als Ausnahme gesetzt. Das funktioniert auch - wenn ich die Faxnummer anrufe, dann nimmt dieses auch ab und ich werde nicht auf den AB weitergeleitet.
    Das scheint aber bei den Nummern die auf den Standort2 verweisen und die in der zweiten ZGU gesetzt sind nicht zu funktionieren.


    Ich freue mich auf eine Rückmeldung.


    Lg
    Merlin