Seite 1 von 2 12 LetzteLetzte
Zeige Ergebnis 1 bis 15 von 17

Thema: rejected because extension not found in context 'default'

  1. #1
    STARFACE User

    Registriert seit
    12.08.2016
    Ort
    München
    Beiträge
    17

    Standard 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

  2. #2
    STARFACE User
    Benutzerbild von LUL
    Registriert seit
    04.07.2013
    Beiträge
    34

    Standard

    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

  3. #3
    STARFACE User

    Registriert seit
    12.08.2016
    Ort
    München
    Beiträge
    17

    Standard

    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.

  4. #4
    STARFACE User
    Benutzerbild von LUL
    Registriert seit
    04.07.2013
    Beiträge
    34

    Standard

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

  5. #5
    STARFACE User

    Registriert seit
    16.06.2014
    Beiträge
    15

    Standard

    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

  6. #6
    STARFACE Crew

    Registriert seit
    30.11.2015
    Beiträge
    31

    Standard

    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

  7. #7
    STARFACE Crew

    Registriert seit
    30.11.2015
    Beiträge
    31

    Standard

    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

  8. #8
    STARFACE Expert

    Registriert seit
    19.08.2014
    Beiträge
    338

    Standard

    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

  9. #9
    STARFACE User

    Registriert seit
    12.08.2016
    Ort
    München
    Beiträge
    17

    Standard

    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

  10. #10
    STARFACE Expert

    Registriert seit
    19.08.2014
    Beiträge
    338

    Standard

    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

  11. #11
    STARFACE Expert

    Registriert seit
    19.08.2014
    Beiträge
    338

    Standard

    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

  12. #12
    STARFACE Expert

    Registriert seit
    19.08.2014
    Beiträge
    338

    Standard

    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,
    [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

  13. #13
    STARFACE Expert

    Registriert seit
    19.08.2014
    Beiträge
    338

    Standard

    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

  14. #14
    STARFACE Expert

    Registriert seit
    04.05.2018
    Beiträge
    412

    Standard

    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).

  15. #15
    STARFACE Expert

    Registriert seit
    19.08.2014
    Beiträge
    338

    Standard

    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.

Ähnliche Themen

  1. Callcentric Provider - Problem default context
    Von alung im Forum Leitungen SIP, NGN, ALL-IP
    Antworten: 5
    Letzter Beitrag: 28.01.2016, 16:43
  2. Extension @ISDN-incoming does not exist
    Von RDM im Forum STARFACE Einrichtung & Administration
    Antworten: 4
    Letzter Beitrag: 19.12.2014, 16:51
  3. Fax-Extension-Number
    Von booc im Forum STARFACE Installation
    Antworten: 1
    Letzter Beitrag: 23.02.2010, 15:51
  4. registration error: 404 - Not found
    Von zmagyar im Forum STARFACE setup & administration
    Antworten: 1
    Letzter Beitrag: 11.08.2009, 11:07
  5. Mehrere default Wartemusikstücke
    Von slu im Forum STARFACE Einrichtung & Administration
    Antworten: 3
    Letzter Beitrag: 26.06.2009, 14:38

Lesezeichen

Forumregeln

  • Es ist Ihnen nicht erlaubt, neue Themen zu verfassen.
  • Es ist Ihnen nicht erlaubt, auf Beiträge zu antworten.
  • Es ist Ihnen nicht erlaubt, Anhänge hochzuladen.
  • Es ist Ihnen nicht erlaubt, Ihre Beiträge zu bearbeiten.
  •