Ein Asterisk Problem, an dem ich nicht weiterkomme

betateilchen

Grandstream-Guru
Mitglied seit
30 Jun 2004
Beiträge
12,882
Punkte für Reaktionen
0
Punkte
0
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:[email protected]/4317066
register => 1012345:[email protected]/1012345
register => 4317514:[email protected]/4317514
register => 1838786:[email protected]/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 !
 
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.
 
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.
 
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 [email protected]

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

HTH,

jo
 
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:[email protected]
register => 1838786:[email protected]

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 ?
 
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:[email protected]/431xxxx
register => 604xxxx:[email protected]/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:[email protected]

oder

register => 431xxxx:[email protected]/2003

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

jo
 
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.
 
@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 :)
 
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
 
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.
 
Das ist aber noch verbesserungswürdig, oder???
 
rubinho schrieb:
Ich musste in der Sip.conf unter dem Sipgateuser diesen Wert eintragen
host=217.10.64.86

:lol: Cooool! Das funktioniert ja super. Bau ich gleich in meine HowTo ein. :D
Danke!
Udo
 

Zurzeit aktive Besucher

Statistik des Forums

Themen
244,695
Beiträge
2,216,697
Mitglieder
371,315
Neuestes Mitglied
jack-mack
Holen Sie sich 3CX - völlig kostenlos!
Verbinden Sie Ihr Team und Ihre Kunden Telefonie Livechat Videokonferenzen

Gehostet oder selbst-verwaltet. Für bis zu 10 Nutzer dauerhaft kostenlos. Keine Kreditkartendetails erforderlich. Ohne Risiko testen.

3CX
Für diese E-Mail-Adresse besteht bereits ein 3CX-Konto. Sie werden zum Kundenportal weitergeleitet, wo Sie sich anmelden oder Ihr Passwort zurücksetzen können, falls Sie dieses vergessen haben.