Verständnisfrage zur sip.conf

Dobse

Neuer User
Mitglied seit
26 Jul 2005
Beiträge
17
Punkte für Reaktionen
0
Punkte
0
Hallo zusammen!

Ich habe Probleme, die Logik der sip.conf zu verstehen. Soweit ich es verstanden habe wird im [general]-Teil Asterisk als SIP-Client konfiguriert (ggf. bei mehreren SIP-Providern). Nun die Frage: Warum brauche ich dann zusätzlich noch für jeden SIP-Provider einen eigenen [ ... ]-Abschnitt in dem ich dann Passwort/Host etc. wiederhole?

Irgendwie sind das doch zwei Paar Stiefel. In den [ ... ]-Abschnitten werden sowohl die SIP-Telefone definiert, d. h. Asterisk verhält sich für diese wie ein Server und diese müssen sich mit dem Passwort anmelden, das man in secret= ... festlegt. Bei einem SIP-Provider ist es doch gerade andersrum: Bei dem muß Asterisk selbst sich mit einem Passwort anmelden. Rein formal besteht aber zwischen SIP-Telefonen und SIP-Providern in der sip.conf kein Unterschied. Woher weiß nun Asterisk, daß das eine ein SIP-Provider und das andere ein SIP-Telefon ist?
 
[general] ist quasi die default-section. Alles was dort definiert ist ist für die peers und clients voreingestellt. Ebenfalls in diesem Bereich sind Grundeinstellungen für den asterisk-server: port, nat, expirey,externip etc. und das register für eingehende Anrufe pro Anbieter. Natürlich müssen für abgehende Gespräche dann extra peer-Definitonen erfolgen, ebenfalls für alle lokalen sip-clients.

Die Unterscheidung ob asterisk client oder server ist wird z.B. über den host-Parameter geregelt. Ist hier eine gültige Adresse eingetragen meldet sich asterisk dort an. Steht dort 'dynamic' wartet asterisk darauf, dass sich ein client anmeldet.
 
Ich verstehe Deine Antwort folgendermaßen: alles was in den register => ... Zeilen steht bezieht sich auf eingehende Anrufe. Die extra peer-Definitionen beziehen sich nur auf ausgehende Anrufe.

Das ist komisch, denn ein eingehender Anruf von (in meinem Falle) web.de-Freephone landet in dem Kontext, den ich im [web.de_Freephone]-Abschnitt definiert habe. Dieser Abschnitt kann sich folglich nicht nur auf ausgehende Anrufe beziehen?
 
Dobse schrieb:
Ich verstehe Deine Antwort folgendermaßen: alles was in den register => ... Zeilen steht bezieht sich auf eingehende Anrufe. Die extra peer-Definitionen beziehen sich nur auf ausgehende Anrufe.

richtig.

[general] Die register-Anweisung ist für eingehende Anrufe und der context= ist die default-extension für alle weiteren peer-/client-Definitionen.
Das ist komisch, denn ein eingehender Anruf von (in meinem Falle) web.de-Freephone landet in dem Kontext, den ich im [web.de_Freephone]-Abschnitt definiert habe. Dieser Abschnitt kann sich folglich nicht nur auf ausgehende Anrufe beziehen?

Bei den Provider-Definitionen setze ich keinen context und damit zieht der default-context unter [general] für eingehende Anrufe. Ausgehende Rufe werden ja von einem client SIP/Capi/ZAP abgesetzt und wenn du in der capi.conf/zapata.conf mal nachschaust steht dort auch ein context= für die abgehenden calls!
Bei einem sip-client wiederum setze ich den context= ebenfalls für abgehende Rufe (sip.conf).
 
Danke für die schnelle Antwort. Meine Frage war ja, warum der EINgehende Anruf von web.de im Kontext landet, der bei [web.de] definiert war und nicht im default-Kontext
(denn
eingehend -- register - Zeilen,
ausgehend --- [ ... ]-Abschnitte)

Noch was: Was hat ein Kontext bei ausgehenden Anrufen überhaupt für einen Sinn? Ausgehende Anrufe werden doch sozusagen von mir über die extensions.conf gesteuert und da bin ich doch automatisch in dem Kontext, wo eben der DIAL-Befehl steht?

Entschuldigung, aber ich scheine auf dem Schlauch zu stehen.
 
Dobse schrieb:
Danke für die schnelle Antwort. Meine Frage war ja, warum der EINgehende Anruf von web.de im Kontext landet, der bei [web.de] definiert war und nicht im default-Kontext
(denn
eingehend -- register - Zeilen,
ausgehend --- [ ... ]-Abschnitte)

weil man natürlich einen default immer überschreiben kann. Es ist denkbar, dass du einen context explizit für jeden provider/peer anlegst und dort dann an- und abgehende Rufe behandelst. Das Minimum ist jedoch ein- und ausgehende Rufe in der extensions.conf auseinanderzuhalten um zu verhindern, dass asterisk als relay dient. Daher mein Vorschlag den contect unter [general] für eingehende Gespräche zu belassen und diesen context gezielt nur bei den lokalen clients für abgehende Gespräche zu überschreiben. Dasselbe gilt für die capi.conf etc. dort auch für abgehende calls definieren. Mir ist klar,dass das Konzept mit den contexten nicht ganz straightforward gedacht ist (man braucht manchmal ein paar Versuche bis man ein Gefühl dafür erhält). ;-)
Noch was: Was hat ein Kontext bei ausgehenden Anrufen überhaupt für einen Sinn? Ausgehende Anrufe werden doch sozusagen von mir über die extensions.conf gesteuert und da bin ich doch automatisch in dem Kontext, wo eben der DIAL-Befehl steht?

Entschuldigung, aber ich scheine auf dem Schlauch zu stehen.

Es sind die Einstiegspunkte in der extensions.conf. Du hast z.B. einen Bereich für eingehende Gespräche und einen für ausgehende usw. Diese sind autark (ohne goto ;-) ) und schränken den Missbrauch ein z.B. relaying.
 
Ich versuche es nocheinmal anhand eines Beispiels zu verdeutlichen. Du führst z.B. ein abgehendes Gespräch über die capi-Schnittstelle an deinem asterisk (via Tk-Anlage). In der capi.conf ist der context [isdn-out] definiert und dieser Abschnitt muss in der extensions.conf vorhanden sein und regelt die abgehenden calls (SIP/IAX2/capi/ZAP-calls). Bei eingehenden Anrufen über SIP bestimmt der context= unter dem peer z.B. [sipgate] wo dieser Ruf in der extensions.conf behandelt wird. Steht dor z.B. sipgate-in muss in der extensions.conf ein [sipgate-in] vorhanden sein um eingehende Rufe von dort zu behandeln. Steht in dem peer nichts, dann zieht der default unter [general] z.B. context=incoming.
Habe ich z.B. einen Client definiert (keinen peer/provider) wie Xlite dann zieht der context= dort für abgehende calls. Eingehende calls kommen ja wieder über einen Anbieter/peer per SIP/IAX2/Capi/ZAP rein und landen in dem dortigen context. Per dial(SIP/xlite...) erfolgt dann die Signalisierung am Endgerät.

PS: und um die Sache noch komplizierter zu machen gibt es natürlich noch das include in der extensions.conf. Ich denke wichtig ist immer, bei allem was tu tust, deinen dialplan sorgfältig auf Missbrauch und Funktion zu testen (via Konsole 'asterisk -dddvvvr'). Denn asterisk arbeitet auch den dialplan (extensions.conf) nicht immer von oben nach unten ab :mrgreen:
 
Vielen herzlichen Dank für Deine ausführliche Hilfe.

Ich glaube, ich habe das mit den Kontexten schon verstanden. Was mich nur etwas verwirrt hatte: wenn ich mich bei meinem SIP-Provider nur mittels register-Zeile registriere (wenn ich z. B. nur Anrufe empfangen will), dann landen eingehende Anrufe im default-Kontext. Wenn ich nun zusätzlich um rauszutelefonieren noch einen [SIP-Provider]-Abschnitt definiere (lediglich um zusätzlich RAUS zu telefonieren) dann ändert sich unter Umständen der Kontext unter dem Rufe EINgehen.
 
Dobse schrieb:
Vielen herzlichen Dank für Deine ausführliche Hilfe.

Ich glaube, ich habe das mit den Kontexten schon verstanden. Was mich nur etwas verwirrt hatte: wenn ich mich bei meinem SIP-Provider nur mittels register-Zeile registriere (wenn ich z. B. nur Anrufe empfangen will), dann landen eingehende Anrufe im default-Kontext. Wenn ich nun zusätzlich um rauszutelefonieren noch einen [SIP-Provider]-Abschnitt definiere (lediglich um zusätzlich RAUS zu telefonieren) dann ändert sich unter Umständen der Kontext unter dem Rufe EINgehen.

Unter [general] definierst du den default-context für die peers/clients. Wenn du einen peer/client explizit definiert hast wird der context genommen der in den peer/client-Definitionen steht und wenn dort keiner ist der unter [general] und wenn dort auch keiner steht ist er default.
 

Zurzeit aktive Besucher

Statistik des Forums

Themen
244,839
Beiträge
2,219,264
Mitglieder
371,543
Neuestes Mitglied
Brainbanger
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.