Asterisk mit 2 sipgate Accounts

[nroej]

Moin!

Ist es möglich mit asterisk sich 2 mal unter verschiedenen Benutzern an Sipgate anzumelden und diese 2 registrierungen in verschiedenen Kontexten zu benutzen?

Hintergrund:

Ich will meine alte ISDN Dect Anlage mit hfc an den Asterisk tüddeln (morgen müsste meine erebayte ISDN Karte kommen ) und zum schluss sollen dann mein Mitbewohner und ich über verschiedene abgehende MSNs per DECT Telefon jeweils auf der entsprechenden Sipgate Leitungen raustelefonieren (weil ich will ja nicht das $mitbewohner mein sipgate guthaben vertelefoniert ;-))

Grüße

Jörn

 

[Hupe]

Ja, geht.

 

[nroej]

*freu* & danke für die schnell antwort

sehr gut, also einfach 2 verschiedene kontexte in der sip.conf:

register => ich@sipgate
register => meinmitbewohner@sipgate

[sipgate1]
user=ich
....


[sipgate2]
user=meinmitbewohner
......

und die entsprechend auf die msns mappen?!

(jetzt muss ich nur noch meinen mitbewohner davon überzeugen mir sein sipgate passwort zu geben :twisted: )

 

[Hupe]

Für die sip.conf copiest du praktisch die entsprechenden Zeilen. Mußt eben nurnoch die entsprechenden Benutzerdaten ändern. Außerdem sollte hinter dem register-Befehl noch die Sipgatenummer stehen (mit einem "/" getrennt).
Die eingehenden sipgate-Anrufe müssen in eine xtension in der extensions.conf geleitet werden und da unterschieden werden (Ist laut Betateilchen ein bug. Hab es aber noch nicht selbst getestet, da ich das sowieso so gemacht habe).
also sip.conf

;Sipgate 1
register => 1234567:[email protected]/1234567
;Sipgate 2
register => 7654321:[email protected]/7654321

[1234568]  
type=friend   
username=1234567
secret=passwd1
host=sipgate.de 
fromuser=1234567
callerid="1234567"
fromdomain=sipgate.de
nat=no
context=sipgatin
canreinvide=no   
dtmfmode=info 
disallow=all
allow=ilbc  
allow=gsm
allow=g726
disallow=ulaw
disallow=alaw

[7654321]  
type=friend   
username=7654321
secret=passwd2
host=sipgate.de 
fromuser=7654321
callerid="7654321"
fromdomain=sipgate.de
nat=no
context=sipgatin
canreinvide=no   
dtmfmode=info 
disallow=all
allow=ilbc  
allow=gsm
allow=g726
disallow=ulaw
disallow=alaw

Und dann extensions.conf:

[sipgatin]
exten => 1234567,1,Dial(....)
exten => 1234567,2,Hangup
exten => 1234567,102,Hangup
exten => 7654321,1,Dial(....)
exten => 7654321,2,Hangup
exten => 7654321,102,Hangup
exten => h,1,Hangup

 

[betateilchen]

Die angesprochene Problematik hat mich mehrere Nächte und einige Kannen Kaffee gekostet.

Wer mehr als 1 Sipgate-Account im Asterisk registrieren will, und ein zuverlässige Trennung erzielen möchte, der sollte folgendermaßen vorgehen:

1. SIP.CONF

Alle ankommenden Anrufe werden in den Kontext [sipgate_de_in] geleitet, da dies der "letzte" Kontext in der Liste ist, der zu einem ankommenden Anruf von Sipgate "paßt".

register => 1234567:[email protected]
register => 7654321:[email protected]

[1234567]
type=peer
username=1234567
fromuser=1234567
secret=pw1
context=default
host=sipgate.de
fromdomain=sipgate.de
insecure=very
caninvite=no
canreinvite=no
nat=no
disallow=all
allow=ilbc

[7654321]
type=peer
username=7654321
fromuser=7654321
secret=pw2
context=default
host=sipgate.de
fromdomain=sipgate.de
insecure=very
caninvite=no
canreinvite=no
nat=no
disallow=all
allow=ilbc

[sipgate_de_in]
type=peer
fromdomain=sipgate.de
host=sipgate.de
context=fromsipgatede
disallow=all
allow=ilbc

Alle ankommenden Sipgate-Anrufe werden aus dem Kontext "sipgate_de_in" in den Kontext "fromsipgatede" in der extensions.conf geleitet.

2. EXTENSIONS.CONF

[fromsipgatede]
;hier werden alle ankommenden Sipgate-Anrufe nach den Rufnummern "sortiert"
exten => 1234567,1,(alles was mit diesem Anruf passieren soll)
exten => 1234567,2,(alles was mit diesem Anruf passieren soll)
;usw.

exten => 7654321,1,(alles was mit diesem Anruf passieren soll)
exten => 7654321,2,(alles was mit diesem Anruf passieren soll)
;usw.

Abgehende Anrufe erfolgen dann aus den benutzerbezogenen Kontexten einfach wie gewohnt mit

[user_1_kontext]
exten => _.,1,SetCallerID(1234567)
exten => _.,2,SetCIDName(user_1_name) ; wenn gewünscht
exten => _.,3,Dial(SIP/${EXTEN}@1234567,60,r)
exten => _.,4,Hangup

[user_2_kontext]
exten => _.,1,SetCallerID(7654321)
exten => _.,2,SetCIDName(user_2_name) ; wenn gewünscht
exten => _.,3,Dial(SIP/${EXTEN}@7654321,60,r)
exten => _.,4,Hangup

Das Ganze ist übrigens kein "Bug" - sondern bei genauer Betrachtung eine ziemlich geniale Möglichkeit, mit möglichst geringen Aufwand eine größtmögliche Flexibilität zu erreichen.

Die genannte Vorgehensweise ist auch nicht Sipgate-spezifisch, sondern ist in gleichem Schema mit allen SIP-Providern anwendbar.

 

[Hupe]

Naja, das mit dem Bug kann man halten wie man will. Wenn es eigentlich gehen sollte, es aber trotzdem nicht funzt, dann nenn ich sowas einen Bug.
Wüsste auch nicht, was deine Variante der sip.conf für einen Vorteil haben sollte. Ist im Prinzip ja das selbe. Nur eben ein Eintrag mehr in der sip.conf.

 

[betateilchen]

@hupe

was das bringt, habe ich schon geschrieben:

Wenn Du nur die beiden Kontext-Einträge mit den Sipgate-IDs drin hast, landet JEDER ankommende Anruf immer im 2. Kontext - ohne daß Du das beeinflussen könntest.

Mit dem 3. Eintrag weißt Du genau, daß der ankommende Ruf dortdrin landet - naja, kann ja jeder machen, wie er will. Mir ist einfach auch die angegebene Variante von der Logik her leichter nachvollziehbar, vor allem, wenn Du nicht nur 2 sondern vielleicht 20 Sipgate-Accounts auf einem Asterisk laufen hast.

 

[Hupe]

Wenn man den Bug kennt, dann trägt man ja sowieso überall den gleichen Context ein (wovon ich mal ausgehelwenn man 200 Accounts verwaltet).
Wenn man das wie Du macht, und der Bug wird einmal behoben, dann muß man bei 200 Accounts den Context überprüfen, bzw. den "default"-Context anpassen. Da kann man es doch gleich richtig machen.
Aber im Prinzip ist das ja erst einmal egal, der Bug ja (noch) existent ist.

 

[betateilchen]

Man muß eben NICHT 200 Kontexte ändern

Weil - es ist KEIN Bug, sondern ein beabsichtigtes Feature. Das habe ich zumindest auf Anfrage in den Asterisk-Mailinglisten als Antwort erhalten und die Begründung war für mich letztendlich schlüssig.

 

[Hupe]

Dummes Feature. Wenn jemand etwas in einen anderen Kontext umleiten möchte, dann soll er es doch so auch machen können. Hört sich für mich eher wie: "Wir bekommen es nicht in den Griff, also wird aus dem Bug ein Feature" an. Und wenn man alles in einen Kontext knallen möchte, dann kann man das ja auch so machen.