Zeige Ergebnis 1 bis 11 von 11

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

  1. #1
    STARFACE User

    Registriert seit
    12.08.2016
    Ort
    München
    Beiträge
    11

    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
    32

    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
    11

    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
    32

    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
    30

    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
    30

    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
    303

    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
    11

    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
    303

    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
    303

    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

Ä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.
  •