.titleBar { margin-bottom: 5px!important; }

Ein Asterisk Problem, an dem ich nicht weiterkomme

Dieses Thema im Forum "Asterisk Allgemein" wurde erstellt von betateilchen, 19 Aug. 2004.

  1. betateilchen

    betateilchen Grandstream-Guru

    Registriert seit:
    30 Juni 2004
    Beiträge:
    12,882
    Zustimmungen:
    0
    Punkte für Erfolge:
    0
    Ort:
    am Letzenberg
    Eine Problembeschreibung mit der Bitte an alle Asterisk-Gurus, mir bei der Lösung zu helfen.

    Ausgangssituation:

    ich habe 4 Sipgate Acounts über Asterisk (CVS Head vom 17.08.2004) bei Sipgate registriert - soweit alles ok.

    Jetzt kommt das Problem:

    ALLE Anrufe, die über Sipgate reinkommen, werden in den LETZTEN Context meiner SIP.CONF geschickt, der zu Sipgate paßt.

    Das heißt: Anrufe auf der 4317066 werden mit dem Kontext 1838786 versehen und als solche weiterbehandelt.

    Sobald ich die Reihenfolge der Kontexte ändere, ändert sich auch die "falsche" Markierung. Dadurch, daß alle 4 Kontexte letztendlich in "default" geschickt werden, wird dort anhand der ankommenden Extension (die zum Glück korrekt ankommt) auch komplett richtig weiterbehandelt.

    Trotzdem hätte ich gerne eine Lösung, die dafür sorgt, daß ankommende Anrufe auch "richtig" erkannt werden.

    Code:
    [general]
    port = 5060
    bindaddr = xxx.xxx.xxx.xxx ; feste IP meines Asterisk
    context = default
    srvlookup = yes
    dtmfmode=rfc2833
    disallow=all
    allow=gsm
    allow=ulaw
    allow=ilbc
    
    register => 4317066:passwort@sipgate.de/4317066
    register => 1012345:passwort@sipgate.de/1012345
    register => 4317514:passwort@sipgate.de/4317514
    register => 1838786:passwort@sipgate.de/1838786
    
    [4317066]
    type=friend
    username=4317066
    fromuser=4317066
    secret=passwort
    context=default
    host=sipgate.de
    fromdomain=sipgate.de
    caninvite=no
    canreinvite=no
    insecure=very
    nat=no
    allow=all
    
    [1012345]
    type=friend
    username=1012345
    fromuser=1012345
    secret=passwort
    context=default
    host=sipgate.de
    fromdomain=sipgate.de
    insecure=very
    caninvite=no
    canreinvite=no
    nat=no
    allow=all
    
    [4317514]
    type=friend
    username=4317514
    fromuser=4317514
    secret=passwort
    context=default
    host=sipgate.de
    fromdomain=sipgate.de
    insecure=very
    caninvite=no
    canreinvite=no
    nat=no
    allow=all
    
    [1838786]
    type=friend
    username=1838786
    fromuser=1838786
    secret=passwort
    context=default
    host=sipgate.de
    fromdomain=sipgate.de
    insecure=very
    caninvite=no
    canreinvite=no
    nat=no
    allow=all
    
    ; ab hier kommen die angeschlussenen Endgeräte - hier irrelevant
    
    Richtig gravierend wird das Problem DANN, wenn ein Anbieter seine Anrufe in den Kontext "s" schickt - dann ist keinerlei Zuordnung mehr möglich, für wen der Anruf nun eigentlich bestimmt war.

    (Ja, es gibt Anbieter, die mit Kontext "s" ankommen - leider !)

    Danke für jede Unterstützung !
     
  2. otaku42

    otaku42 Admin-Team

    Registriert seit:
    26 März 2004
    Beiträge:
    1,670
    Zustimmungen:
    0
    Punkte für Erfolge:
    0
    Ohne in den Source geschaut zu haben: das hoert sich danach an, dass Asterisk eingehende Anrufe nur anhand des Providers matcht, nicht aber zusaetzlich anhand des angerufenen Teilnehmers.
    Sehr seltsam, das.
     
  3. betateilchen

    betateilchen Grandstream-Guru

    Registriert seit:
    30 Juni 2004
    Beiträge:
    12,882
    Zustimmungen:
    0
    Punkte für Erfolge:
    0
    Ort:
    am Letzenberg
    naja - in diese Richtung war ich ja gedanklich auch schon unterwegs.
    Aber erstens kenn ich mich mit Quelltexten nicht mehr SO gut aus wie früher, und zum anderen hätte mich mal interessiert ob schonmal jemand über dieses Problem gestolpert ist und viellleicht einen Lösungsansatz hat.

    Es ist übrigens kein SIP-spezifisches Problem, bei mehreren IAX-Registrierungen läßt sich dieses Verhalten 100% reproduzieren.
     
  4. rollo

    rollo IPPF-Promi

    Registriert seit:
    5 Juli 2004
    Beiträge:
    8,281
    Zustimmungen:
    1
    Punkte für Erfolge:
    38
    Ort:
    JO30SK
    Prinzipiell klappt das schon.
    Bei mir mit mehreren Nummern bei FWD (IAX und SIP) und bei Sipgate.

    Beim context würde ich von default abraten.

    Bei mir heißt der z.B. fromsipgate mit dem entsprechenden Eintrag in der extensions.conf

    type ist bei mir peer und fromdomain ist sipgate.net, wurde mir von denen mal so empfohlen und die SIP URI ist ja auch sip-nr@sipgate.net

    Ich könnte mir auch vorstellen, dass Asterisk bei Deinen Peers durcheinanderkommt, da sie wie die Rufnummern heissen.

    HTH,

    jo
     
  5. betateilchen

    betateilchen Grandstream-Guru

    Registriert seit:
    30 Juni 2004
    Beiträge:
    12,882
    Zustimmungen:
    0
    Punkte für Erfolge:
    0
    Ort:
    am Letzenberg
    Nächster Versuch

    @rollo danke für die Hinweise - aber sie haben mir alle nicht weitergeholfen.
    Kannst Du mal Deine Konfig für mehrere Sipgate-Acct in der SIP.CONF geben ?


    So - ich habe nun mal umgebaut.

    Auf einem 2. Asterisk habe ich folgende SIP.CONF

    Code:
    [general]
    port = 5060                     ; Sipport
    bindaddr = 217.20.126.92        ; Addresse für den SIP Kanal
    srvlookup = yes                 ; Enable DNS SRV lookups on outbound calls
    allow=all                       ; sperrt alle codecs
    
    register => 4317514:ppppp@sipgate.de
    register => 1838786:ppppp@sipgate.de
    
    
    und die EXTENSIONS.CONF sieht so aus

    Code:
    
    [general]
    static=yes
    writeprotect=no
    
    [globals]
    
    [default]
    exten => _.,1,Wait,20
    
    
    Nun passiert folgendes:

    Fall 1) ich rufe über einen Freenet-Account die Sipgate-Nummer 4317514 an:

    -- Executing Wait("SIP/freenet.de-080f9f00", "20") in new stack

    Fall 2) ich rufe über mein E-Plus-Handy die Sipgate-Nummer 4317514 an:

    -- Executing Wait("SIP/217.116.127.245-080f9f00", "20") in new stack

    Fall 3) ich rufe über einen PURtel-Account die Sipgate-Nummer 4317514 an:

    -- Executing Wait("SIP/217.116.127.245-080f9f00", "20") in new stack

    Fall 4) ich rufe die ZWEITE registrierte Sipgate Nummer 1838786 an:

    -- Executing Wait("SIP/217.116.127.245-080f9f00", "20") in new stack (GENAU das gleiche :shock: )

    Diese 217.xxx.xxx.xxx ist eine Sipgate-IP - aber warum kommt der Freenet-Anruf mit "freenet.de" rein ? Ich weiß doch nicht vorher, WOHER ein Anruf kommt. Also wie soll ich bitteschön kontextmäßig die ankommenden Anrufe auseinandersortieren ?


    Und was bitte ist diese "080f9f00" die in ALLEN Fällen mit ankommt ?
     
  6. rollo

    rollo IPPF-Promi

    Registriert seit:
    5 Juli 2004
    Beiträge:
    8,281
    Zustimmungen:
    1
    Punkte für Erfolge:
    38
    Ort:
    JO30SK
    Ok, habe mal die relevanten Teile rauskopiert:

    sip.conf
    Code:
    [general]
    
    port = 5050 ; Port to bind to (SIP is 5060)
    externip=mein.dynds.name
    localnet=192.168.1.0/255.255.255.0
    bindaddr = 192.168.1.33; Address to bind to (all addresses on machine)
    nat=yes
    srvlookup=yes
    context=from-sip
    
    disallow=all
    allow=ulaw
    allow=alaw
    allow=gsm
    
    register => 431xxxx1:xxxx@sipgate.de/431xxxx
    register => 604xxxx:xxxx@sipgate.de/604xxxx
    
    
    [sipgate1]
    type=peer
    secret=xxxx
    username=431xxxx
    host=sipgate.de
    dtmfmode=inband
    context=fromsipgate
    nat=no
    canreinvite=yes
    fromuser=431xxxx
    fromdomain=sipgate.de
    
    [sipgate2]
    entsprechend
    
    
    extensions.conf
    Code:
    [fromsipgate]
    exten => 431xxxx,1,Dial(sip/2003&CAPI/41:26,20,r)
    exten => 431xxxx,2,SetLanguage(de)
    exten => 431xxxx,3,Voicemail,u2003
    exten => 431xxxx,102,Voicemail,b2003
    
    exten => 604xxxx,1,Dial(sip/2003,20,r)
    exten => 604xxxx,2,SetLanguage(de)
    exten => 604xxxx,3,Voicemail,u2003
    exten => 604xxxx,102,Voicemail,b2003
    
    Wenn die erste Nummer angrufen wird, klingelt das SIP Telefon und die Gruppe 26 der TK Anlage, bei der zweiten nur das SIP Telefon.

    Die Konfiguration entspricht im wesentlichen den üblichen Beispielen. Mit

    register => 431xxxx:xxxx@sipgate.de

    oder

    register => 431xxxx:xxxx@sipgate.de/2003

    funktioniert es nur bedingt. Auch wird der Onlinestatus dann nicht richtig bei sipgate angezeigt.

    jo
     
  7. betateilchen

    betateilchen Grandstream-Guru

    Registriert seit:
    30 Juni 2004
    Beiträge:
    12,882
    Zustimmungen:
    0
    Punkte für Erfolge:
    0
    Ort:
    am Letzenberg
    Funktioniert nicht :motz:
    Die EXTENSIONS.CONF soritert die Anrufe schon richtig - aber die werden bei mir in der SIP.CONF schon nicht richtig zugeordnet.

    Habe das gleiche eben mal mit 2 BLUEsip-Accounts getestet. Da tritt genau der gleiche Fehler auf.

    -- Executing Wait("SIP/bluesip.net-0811bce8", "20") in new stack

    Aber hier steht wenigstens IMMER "bluesip.net" im Incoming, unabhängig, von wo aus ich die Münchner BLUEsip Nummer wähle.

    Übrigens ist es scheinbar hierbei völlig egal, ob in der SIP.CONF Kontexte vorhanden sind, oder nicht.

    @rollo Danke für Deine CONFs !
    Habe die eben mal exakt so in meinen Asterisk eingetragen - da wird genau das gleiche Fehlverhalten produziert.

    Nochmal: Es geht nicht darum, daß die Anrufe an die falsche Extension (in der extensions.conf) geschickt werden, sondern darum, daß die Anrufe IMMER über den LETZTEN Kontext in der SIP.CONF in die EXTENSIONS.CONF geleitet werden (in diesem Fall über Deinen Kontext [sipgate2] - obwohl auf der "ersten" Nummer [sipgate1] angerufen wird.
     
  8. otaku42

    otaku42 Admin-Team

    Registriert seit:
    26 März 2004
    Beiträge:
    1,670
    Zustimmungen:
    0
    Punkte für Erfolge:
    0
    @Betateilchen:

    Ich habe zwar keine konkrete Idee mehr fuer Dein Problem, aber bin gerade ueber etwas anderes gestolpert:
    allow=all ; sperrt alle codecs
    Das ist in Deiner sip.conf zu finden. Wenn es wirklich Deine Intention ist, alle Codecs zu sperren, musst Du da disallow hinschreiben :)
     
  9. rubinho

    rubinho Mitglied

    Registriert seit:
    3 Aug. 2004
    Beiträge:
    206
    Zustimmungen:
    0
    Punkte für Erfolge:
    16
    Beruf:
    Netz Admin
    Ort:
    Saarland
    Also ich hatte ein ähnliches Problem mit der Zuweisung externer anrufe von Sipgate.

    Bei mir war das Problem das ein ankommnder Sipgateanruf mit der Ip-Adresse ankam und nicht mit dem Namen (@sipgate.de)
    Ich musste in der Sip.conf unter dem Sipgateuser diesen Wert eintragen
    host=217.10.64.86

    Damit war das Problem bei mir gelöst.

    Gruß
    Rubinho
     
  10. betateilchen

    betateilchen Grandstream-Guru

    Registriert seit:
    30 Juni 2004
    Beiträge:
    12,882
    Zustimmungen:
    0
    Punkte für Erfolge:
    0
    Ort:
    am Letzenberg
    ALSO ...

    nach vielen Stunden Arbeit, unzähligen Telefonaten mit einigen Leuten, die sich richtig gut auskennen, x-Tests auf und mit verschiedenen Asterisk-Servern, der Lektüre der Asterisk-Doku und der Asterisk-Sourcen steht nun folgendes fest:

    1.) es ist möglich, alle ankommenden Anrufe EINES Provides in EINEN speziellen Kontext zu leiten, z.B. [provider_incoming]

    2.) es ist NICHT möglich, die ankommenden Anrufe von EINEM Provider nach verschiedenen Accounts bei diesem Provider zu sortieren und von der SIP.CONF in einzelne Account-bezogene Kontexte zu sortieren.

    Eine Sortierung ist nur innerhalb des in 1.) erreichten Kontextes anhand der angewählten Extension möglich.

    Die vorgenannten Erkenntnisse gelten nur für SIP-Verbindungen.

    Mit IAX-Verbindungen stellt sich das Problem noch sehr viel komplizierter dar - genauer: es ist nahezu unmöglich, so eine Sortierung vorzunehmen, vor allem, wenn der Provider ZWANGSLÄUFIG in die Extension "s" schickt, denn dann ist selbst in dem erreichten [provider_incoming] KEINE weitere Sortierung mehr möglich.

    Danke an alle, die mich beim Herausfinden dieser Punkte unterstützt und ihre Zeit investiert haben.
     
  11. allesOK

    allesOK Mitglied

    Registriert seit:
    24 Mai 2004
    Beiträge:
    732
    Zustimmungen:
    0
    Punkte für Erfolge:
    0
    Das ist aber noch verbesserungswürdig, oder???
     
  12. udosw

    udosw Aktives Mitglied

    Registriert seit:
    20 März 2004
    Beiträge:
    1,114
    Zustimmungen:
    0
    Punkte für Erfolge:
    0
    Ort:
    Hannover
    :lol: Cooool! Das funktioniert ja super. Bau ich gleich in meine HowTo ein. :D
    Danke!
    Udo