rejected because extension not found in context 'default'

  • Hallo Forum,


    wir nutzen eine Starface VMware Appliance (aktuellste Version), die an drei 10er SIPtrunks von Easybell angemeldet ist, von denen nur der erste Trunk tatsächlich verwendet wird. Wir nutzen zwei Telefone (-3 und -4), ein Fax (-1) und eine Gruppe (-0) die auf beiden Telefonen klingelt. Folgendes Problem:


    Zuerst funktioniert alles wunderbar. Man kann anrufen, man kann angerufen werden und überall werden die korrekten Rufnummern angezeigt. Nach einigen Stunden bzw. Tagen an denen niemand im Büro ist, kann man plötzlich von außen nicht mehr anrufen, sondern bekommt die Provider-Ansage "Die gewählte Rufnummer ist nicht vergeben". Die SIPtrunks sind aber nach wie vor bei Easybell registriert und im PBX Logfile tauchen folgende EInträge auf:


    [Mar 3 18:39:49] VERBOSE[30586] asterisk.c: -- Remote UNIX connection disconnected
    [Mar 3 18:40:47] VERBOSE[2645] asterisk.c: -- Remote UNIX connection
    [Mar 3 18:40:47] VERBOSE[31434] asterisk.c: -- Remote UNIX connection disconnected
    [Mar 3 18:40:49] VERBOSE[2645] asterisk.c: -- Remote UNIX connection
    [Mar 3 18:40:49] VERBOSE[31440] asterisk.c: -- Remote UNIX connection disconnected
    [Mar 3 18:41:49] VERBOSE[2645] asterisk.c: -- Remote UNIX connection
    [Mar 3 18:41:49] VERBOSE[31480] asterisk.c: -- Remote UNIX connection disconnected
    [Mar 3 18:42:15] VERBOSE[2911][C-0000000f] netsock2.c: == Using SIP RTP TOS bits 184
    [Mar 3 18:42:15] VERBOSE[2911][C-0000000f] netsock2.c: == Using SIP RTP CoS mark 5
    [Mar 3 18:42:15] NOTICE[2911][C-0000000f] chan_sip.c: Call from '' (195.185.37.60:5064) to extension '4989*******0' rejected because extension not found in context 'default'.
    [Mar 3 18:42:15] VERBOSE[2911][C-00000010] netsock2.c: == Using SIP RTP TOS bits 184
    [Mar 3 18:42:15] VERBOSE[2911][C-00000010] netsock2.c: == Using SIP RTP CoS mark 5
    [Mar 3 18:42:15] NOTICE[2911][C-00000010] chan_sip.c: Call from '' (195.185.37.60:5064) to extension '********0' rejected because extension not found in context 'default'.
    [Mar 3 18:42:15] VERBOSE[2911][C-00000011] netsock2.c: == Using SIP RTP TOS bits 184
    [Mar 3 18:42:15] VERBOSE[2911][C-00000011] netsock2.c: == Using SIP RTP CoS mark 5
    [Mar 3 18:42:15] NOTICE[2911][C-00000011] chan_sip.c: Call from '' (195.185.37.60:5064) to extension '4989******0' rejected because extension not found in context 'default'.
    [Mar 3 18:42:15] VERBOSE[2911][C-00000012] netsock2.c: == Using SIP RTP TOS bits 184
    [Mar 3 18:42:15] VERBOSE[2911][C-00000012] netsock2.c: == Using SIP RTP CoS mark 5
    [Mar 3 18:42:15] NOTICE[2911][C-00000012] chan_sip.c: Call from '' (195.185.37.60:5064) to extension '******0' rejected because extension not found in context 'default'.


    Was könnte dieses Problem auslösen? Ein eingehendes Fax (passiert ziemlich selten)? Der Anrufbeantworter (ist über das Modul "Zeitgesteuerte Umleitung" realisiert. Wird manuell ein- und ausgeschaltet)?


    Wenn ich durch irgendeine Änderung in der Leitungskonfiguration die Startface dazu bringe sich neu bei Easybell zu registrieren, dann funktioniert (erst mal) wieder alles.


    Über einen Tipp wäre ich dankbar!


    Florian Pürner
    KOPFteam GmbH

  • Es gibt da schon einen Thread, der das Problem grob beschreibt, wir hatten das beim Provider Globalways ähnlich.
    Wir konnten das durch eine angepasste Leitungskonfiguration lösen.


    Hier das Beispiel:


    [Globalways_AG_-_FRA-incoming]
    exten => _.,1,Set(channelname=Globalways_AG_-_FRA-incoming)
    exten => _.,2,Set(lineconfigid=1075)
    exten => _.,3,Goto(Globalways_AG_-_FRA-incoming-manuell,${EXTEN},1)

    [Globalways_AG_-_FRA-incoming-manuell]
    exten => _X.,1,Set(var_to=${SIP_HEADER(To)})
    exten => _X.,2,Set(firstcut=${CUT(var_to,:,2)})
    exten => _X.,3,Set(secoundcut=${CUT(firstcut,@,1)})
    exten => _X.,4,Goto(incoming,${secoundcut},1)
    exten => _X.,5,Hangup

    exten => _+X.,1,Set(var_to=${SIP_HEADER(To)})
    exten => _+X.,2,Set(firstcut=${CUT(var_to,:,2)})
    exten => _+X.,3,Set(secoundcut=${CUT(firstcut,@,1)})
    exten => _+X.,4,Goto(incoming,${secoundcut},1)
    exten => _+X.,5,Hangup


    [Globalways_AG_-_S-incoming]
    exten => _.,1,Set(channelname=Globalways_AG_-_S-incoming)
    exten => _.,2,Set(lineconfigid=1007)
    exten => _.,3,Goto(Globalways_AG_-_S-incoming-manuell,${EXTEN},1)

    [Globalways_AG_-_S-incoming-manuell]
    exten => _X.,1,Set(var_to=${SIP_HEADER(To)})
    exten => _X.,2,Set(firstcut=${CUT(var_to,:,2)})
    exten => _X.,3,Set(secoundcut=${CUT(firstcut,@,1)})
    exten => _X.,4,Goto(incoming,${secoundcut},1)
    exten => _X.,5,Hangup

    exten => _+X.,1,Set(var_to=${SIP_HEADER(To)})
    exten => _+X.,2,Set(firstcut=${CUT(var_to,:,2)})
    exten => _+X.,3,Set(secoundcut=${CUT(firstcut,@,1)})
    exten => _+X.,4,Goto(incoming,${secoundcut},1)
    exten => _+X.,5,Hangup

  • Vielen Dank für die ausführliche Antwort! Ich werde mir das morgen in Ruhe ansehen.


    Was ich noch nicht verstanden habe: Was ist das Grundproblem? Die prinzipielle Kommunikation zwischen Starface und Easybell oder die drei SIPtrunks?


    Zweiteres liese sich einfach lösen: Da wir eh' nur 4 Nummern aus dem ersten Trunk verwenden, könnte ich die beiden anderen Trunks einfach aus der Starface-Konfiguration löschen. Wir haben die nur weil wir bei der DTAG einen 30er Trunk hatten und Easybell daraus drei 10er Trunks gemacht hat.

  • Das Problem ist, dass das Routing der Gespräch Richtung intern nicht klappt, da die Nummern nicht erkannt werden.

  • Hat hier schon jemand eine Lösung gefunden? Wir hatten das früher mal, dann war für einige Monate Ruhe und nun passiert es wieder täglich.
    Während Easybell nicht funktioniert, funktionieren Toplink und Sipgate aber weiter.


    Gruß
    Sascha

  • Moin,


    das eingehende Rufnummernformat beginnnt hier mit "4989" laut obigem Post.


    Im entsprechenden Providerprofil (Admin => Leitungen => Leitungen => "Bleistift" neben "Provider: [Providername]") muss das endsprechende Nummernformat unten auf der Seite stimmen.


    Selbiges nebenbei auch bei ISDN einstellbar im Kartenreiter "Erweitert" => "Nummernformat".


    Grüße, Jürgen

  • Moin,


    das eingehende Rufnummernformat beginnnt hier mit "4989" laut obigem Post.


    Im entsprechenden Providerprofil (Admin => Leitungen => Leitungen => "Bleistift" neben "Provider: [Providername]") muss das endsprechende Nummernformat unten auf der Seite stimmen.


    Selbiges nebenbei auch bei ISDN einstellbar im Kartenreiter "Erweitert" => "Nummernformat".


    Grüße, Jürgen

  • Ich habe es jetzt ebenfalls wieder, dass gelegentlich Gespräche nicht reinkommen. Versucht man es später nochmals, dann funktioniert es wieder.


    chan_sip.c: Call from '' (212.227.124.129:5060) to extension '4951XXXX99913' rejected because extension not found in context 'default'.


    Ich habe mehrere Rufnummern bei 1&1 und es trifft die Nummern nach Lust und Laune.


    Im Leitungsprofil habe ich unter Wählformat und Rufnummernanzeige "RFC3261" (Vorgabe von 1&1) gewählt und unter Anzeige eingehend "11 (222) XXX".


    Gibt es hier eine simple Lösung oder ist der SIP-Header von 1&1 einfach gelegentlich unsauber?


    Mit freundlichem Gruß
    Andreas

  • Hallo Schubbie,


    das ist ja schon ewig her! Ich habe damals nach langem Suchen herausgefunden dass die Registrierung Starface<->EasyBell via UDP alle 10 Minuten refreshed wird. Unsere Firewall (SonicWall) hatte aber ein UDP Timeout von 30 Sekunden. Ich habe das UDP Timeout in der Firewall an zwei Stellen (Sicher ist sicher: Einmal den generellen Defaultwert und einmal in der Firewall Rule LAN->WAN) auf 600 Sekunden geändert. Seitdem ist das Problem nie wieder aufgetreten.


    Schönen Abend,
    Florian

  • Hallo Florian,
    danke für die Rückmeldung. In meinem Ubiquiti USG3P habe ich in der Firewall die Möglichkeit unter "State timeouts" "UDP others" (jetzt 30 Sekunden) und "UDP Stream" (jetzt 180 Sekunden) eine Zeit einzustellen. Das sollte das von dir angesprochene sein?
    Ich ändere beide Werte auf 600 Sekunden. Vielleicht habe ich ja Glück, dass es damit nicht mehr auftritt. Das Blöde ist ja, dass es monatelang gar nicht mehr aufgetreten ist und jetzt unvermittelt wieder auftritt.


    Habe ich durch das Ändern der Einstellungen in der Firewall irgendwelche Nachteile?


    Ebenfalls noch einen schönen Abend.
    Mit freundlichem Gruß
    Andreas

  • Anscheinend scheint es nicht geholfen zu haben. Die eine Nummer war nach einem Neustart des Gateways und der Starface immer noch nicht erreichbar.
    Ich änderte dann im Leitungsprofil das eingehende Nummernformat auf " no screening" startete die Starface neu und konnte die Nummern erreichen. Danach habe ich es zurück geändert und die Nummern funktionieren immer noch. Kann es sein, dass in der Config etwas bei einem Update durcheinander gekommen ist?


    Was mich noch irritiert sind folgende Zeilen, die ich in der Benutzeroberfläche anscheinend nicht beeinflussen kann:


    Dec 29 01:15:40] VERBOSE[2984] pbx.c: -- Including context 'hint' in context 'international'
    [Dec 29 01:15:40] VERBOSE[2984] pbx.c: -- Registered extension context 'calling'; registrar: pbx_config
    [Dec 29 01:15:40] WARNING[2984] pbx_config.c: The use of '_.' for an extension is strongly discouraged and can have unexpected behavior. Please use '_X.' instead at line 67 of /etc/asterisk/dialplan/extensions.conf
    [Dec 29 01:15:40] VERBOSE[2984] pbx.c: -- Added extension '_.' priority 1 to calling
    [Dec 29 01:15:40] WARNING[2984] pbx_config.c: The use of '_.' for an extension is strongly discouraged and can have unexpected behavior. Please use '_X.' instead at line 68 of /etc/asterisk/dialplan/extensions.conf
    [Dec 29 01:15:40] VERBOSE[2984] pbx.c: -- Added extension '_.' priority 2 to calling
    [Dec 29 01:15:40] WARNING[2984] pbx_config.c: The use of '_.' for an extension is strongly discouraged and can have unexpected behavior. Please use '_X.' instead at line 69 of /etc/asterisk/dialplan/extensions.conf
    [Dec 29 01:15:40] VERBOSE[2984] pbx.c: -- Added extension '_.' priority 3 to calling
    [Dec 29 01:15:40] WARNING[2984] pbx_config.c: The use of '_.' for an extension is strongly discouraged and can have unexpected behavior. Please use '_X.' instead at line 70 of /etc/asterisk/dialplan/extensions.conf
    [Dec 29 01:15:40] VERBOSE[2984] pbx.c: -- Added extension '_.' priority 4 to calling
    [Dec 29 01:15:40] WARNING[2984] pbx_config.c: The use of '_.' for an extension is strongly discouraged and can have unexpected behavior. Please use '_X.' instead at line 71 of /etc/asterisk/dialplan/extensions.conf
    [Dec 29 01:15:40] VERBOSE[2984] pbx.c: -- Added extension '_.' priority 5 to calling
    [Dec 29 01:15:40] VERBOSE[2984] pbx.c: -- Added extension 'failed' priority 1 to calling
    [Dec 29 01:15:40] VERBOSE[2984] pbx.c: -- Added extension 'failed' priority 2 to calling


    Sollte ich das UDP-Timeout in der Firewall trotzdem auf 600 lassen?


    Mit freundlichem Gruß
    Andreas

  • Moin,
    nachdem es nun Monate lang ging (warum auch immer), bin ich auf die Idee gekommen, dass es nicht sein kann, dass ich nichts basteln muss und habe eine OPNsense installiert. Nun habe ich hier das Problem,

    Zitat

    [Jul 28 01:42:16] NOTICE[2338][C-00000006] chan_sip.c: Call from '' (212.227.124.129:5060) to extension '4951xxx99913' rejected because extension not found in context 'default'.


    kann es jedoch etwas eingrenzen.


    1&1 nutzt für den Sip-Server 2 unterschiedliche IPs (212.227.124.129 & 212.227.124.130). Kommt zuvor ein Anruf über die 129 rein, dann wird ein folgnder über die 130 abgewiesen und andersrum. Sprich die Starface akzeptiert anscheinend nur eine IP. Wenn die 129 funktioniert, dass funktioniert diese immer, wie auch die 130. Leider wechselt 1&1 die IP zwischen den beiden vermutlich nach Auslastung, so dass mal die eine und mal die andere IP reinkommt.


    Habt ihr eine Idee, wie man der Starface nun sagt, dass die doch bitte die Rufe von beiden IPs an die Endgeräte leiten und nicht abweisen soll?


    Mit freundlichem Gruß
    Andreas

  • Ich habe im Leitungsprofil die SIP-Adresse anstelle von SIP.1und1.de eingegeben und die Starface lässt dann tatsächlich nur die Rufe von dieser Adresse zu den Endgeräten durch. Wird die andere IP verwendet kommt besagte Meldung im Log.


    Hat jemand eine Idee, wie man das lösen kann?


    Mit freundlichem Gruß
    Andreas

  • D.h. wenn ich mit einem Access-SBC auf Provider-Seite loadbalancing mache, dann muss der Invite immer vom gleichen SBC kommen, damit das durchgeht?


    Wir haben hier auf dem Cirpack-Krempel zwar Floating-IPs, die im Failover mitgenommen wird, allerdings kann man auch anstelle von active-standby auch active-active (also eigentlich active-standby / active-standby mit 4 Servern) bauen. Letzteres würde dann mit Starface nicht gehen, da 2 aktive IPs genutzt werden. Momentan haben wir active-active (allerdings ohne Redundanz) nur bei den RTP-Forwardern, d.h. der Invite kommt immer von der gleichen IP, der RTP-Strom von zwei RTP-Forwarder mit jeweils 2 IPs (redundante Netzwerkkarten pro Forwarder).

  • Du könntest es ja mal ausprobieren, um meine Beobachtung zu bestätigen oder auch nicht.


    Seltsam finde ich, dass es mit dem Ubiquiti Gateway ging, daher möchte ich einen Fehler in der Konfiguration der OPNsense nicht ausschließen. Allerdings kann ich im Log der Starface sehen, dass die IP einen Ruf an die Starface signalisiert, der nicht beim Endgerät ankommt, da durch die Starface abgewiesen.

  • Moin,
    SIPROXD habe ich wieder deaktiviert, da ich es damit nicht lösen könnte. Vielleicht bin ich auch für die Einrichtung zu blöd, das weiß ich leider nicht. Der ist ja eher für die Deutsche Telekom, ich hatte die IPs entsprechend auf 1&1 geändert.


    Auf Ubiquiti musste ich SIP-ALG deaktivieren, damit es läuft.


    Ich habe nochmals probiert gehabt. Ich dachte mir, dass wenn ich in der Starface nur eine IP im Leitungsprofil angebe und nur diese in der OPNsense freigebe, dann sucht 1&1 sich vielleicht den Weg über den anderen Server. Aber nein, es wird trotzdem noch von dem zweiten Server aus probiert.


    Was mir aufgefallen ist ist, dass die IP, mit der die Telefonie dann funktioniert, in der Firewall Live-Ansicht nicht auftaucht. Wird versucht ein Ruf auf der anderen IP zu signalisieren, dann taucht diese in der Live-Ansicht auf und wird an die Starface weitergeleitet und bei der Starface erscheint dann die besagte Nachricht. Da scheint ja dann doch eine Art STUN auf der IP, die funktioniert, zu laufen, wenn die IP in der Firewall nicht auftaucht?
    Leider kenne ich mich mit dem ganzen Kram nicht aus...


    SipGate läuft problemlos anscheinend per STUN, jedoch kann man diesen bei der Starface ja gar nicht angeben?

  • Hat noch jemand eine Idee? Ich habe auf V7 geupdated und seit dem ist das Problem fast immer da. Es ist einige Monate gar nicht aufgefallen und mit dem Update geht das Problem wieder los ...

  • Hallo,
    würde mich Schubbie anschließen.
    Erhalte nach Update auf V7 (letzter Patchstand)


    chan_sip.c: Call from '' (227.4.21.65:5060) to extension 'RufnummerVonMir' rejected because extension not found in context 'default'


    Es betrifft von der Telekom der Deutschland LAN/IP Anschluss immer wieder eine andere der 2 Rufnummern

  • Eventuell habe ich es eben gefunden. Ich habe mit nochmals die Tipps zur Leitungskonfiguration durchgelesen:
    https://knowledge.starface.de/…viderprofil+konfigurieren


    Erst hatte ich "permit" in Verdacht und dort beide IPs eingetragen, jedoch keine Änderung.


    Dann habe ich "resolve Host" gefunden. Mit Haken wird die IP der angegebenen SIP-Domain aufgelöst und die IP in die Konfiguration geschrieben, welche ja nur eine IP sein kann. Nimmt man den Haken raus, dann wird der FQDN in die Konfiguration geschrieben und es scheint zu funktionieren.
    Ich teste weiter, bisher sieht es aber gut aus.

Jetzt mitmachen!

Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!