direkt eingehende Anrufe von einem Client auf unterscheiden

[Thomas007]

Hallo,
wie unterscheide ich SIP-Anrufe eines Clients die direkt bei meinem Asterisk Server eingehen.
Ich habe in der sip.conf. nur Registrierungen und einen dazu gehörigen Kontext. Trotzdem wird jeder Anruf angenommen und im Teilplan unter diesen Kontext bearbeitet.

Wo lese ich wirksam den "Absender" aus?
Whitelist für bekannte Anrufer, deny für alle anderen..
Die nächste Frage wäre, da der Absendereintrag ja beliebig editiert werden kann, wie sich es über reverse lookup auf bestimmte Domain-Namen beschränken kann.

Gruss Thomas

 

[kombjuder]

Re: direkt eingehende Anrufe von einem Client auf unterschei

Ich habe in der sip.conf. nur Registrierungen und einen dazu gehörigen Kontext. Trotzdem wird jeder Anruf angenommen und im Teilplan unter diesen Kontext bearbeitet.

Dann stimmt irgendwas mit deiner sip.conf nicht.

Meine Kristallkugel meint, du hast zwischen [general] und dem nächsten [XXX] Eintrag etwas stehen wie context = default.

Zu Whitelists befrage mal google. Das habe ich schon mal gelesen.

 

[Thomas007]

Die sip.conf besteht nur aus [global], den Parametern, context=eingehend und dann ein paar Registrierungen, kein [default] oder ein anderer Eintrag.

Trotzdem kommt jeder der sich mit einem Client direkt auf [email protected] verbindet einen Anschluß und wenn irgendwas im context eingehend vorkommt wird es auch abgearbeitet???

Es würde ja schon Sinn machen für Anrufer, die mit einem Client von irgendwo kommen durch einen anderen Context abzuarbeiten, als die die über einen SIP-Proxy, wo ich mich angemeldet habe, vermittelt werden.

Mir fällt nur ein, daß ich an Hand der Registrierung ..../Kennung im Dialplan selektiere. Aber ist das der richtige Weg?

Whitelist wäre sicher über iptables möglich, aber ich dachte ich kann das irgendwie in Asterisk unterbringen.

 

[rollo]

Was kombjuder Dir zwischen den Zeilen sagen wollte ist, dass wir mehr input benötigen, um konkret helfen zu können. Dazu zählt als erstes eine aussagekräftige Signatur. Weiterhin in diesem Fall Deine sip.conf und extensions.conf. Bitte zum posten die Code Tags benutzen!

Auch wenn wir ahnen, was falsch läuft, ist es einfacher am konkreten Beispiel die Änderungen zu erläutern.

jo

 

[kombjuder]

Die sip.conf besteht nur aus [global], den Parametern, context=eingehend und dann ein paar Registrierungen, kein [default] oder ein anderer Eintrag.

Mit dem context= in [global] setzt du den Einsprung in deine extensions.conf für alles, was nicht über einen anderen context reinkommt, also quasi den defaultcontext.

Es würde ja schon Sinn machen für Anrufer, die mit einem Client von irgendwo kommen durch einen anderen Context abzuarbeiten, als die die über einen SIP-Proxy, wo ich mich angemeldet habe, vermittelt werden.

Kein Problem, erstell einen und trage ihn unter global ein.

Mir fällt nur ein, daß ich an Hand der Registrierung ..../Kennung im Dialplan selektiere. Aber ist das der richtige Weg?

Da gibt es viele Wege. Ich habe einen [eingehend] dort landet alles was registriert von aussen kommt und wird dann entsprechend weiterverarbeitet.
Dann gibt es einen [ENUM] da landet alles drin, was über meine ENUM-Einträge reinkommt
...
Jede andere funktionierende Lösung ist auch der richtige Weg. Ich kenne deine Bedürfnisse und Wünsche nicht, desshalb kann ich dir nur meine Lösung sagen. Ob deine ähnlich aufbaust...
Es gibt im Netz unendlich viele Vorschläge, schau dir mal ein paar an, vielleicht findest du eine die dir gefällt.

Whitelist wäre sicher über iptables möglich, aber ich dachte ich kann das irgendwie in Asterisk unterbringen.

Das funktioniert nur, wenn dein Gegenüber eine feste IP-Adresse hat. Lass dich von extern direkt anrufen und schau, was für auswertbare Daten beim Anruf übertragen werden. Damit kannst du dann eine funktionierende Lösung basteln.
Ein anderer Weg für eine reine Whitelist:
Du legst in deiner Sip.conf einen Eintrag [whitelist] an, der kein Passwort hat. An deinen Personen der Whitelist verteilst du eine "Rufnummer" [email protected].
Unter dieser können sie dich dann ohne Autentifizierung direkt anrufen. So was verwende ich für meine Enum-Einträge. Kommt da Mist drüber rein, wird die Rufnummer geändert und Ruhe ist.

 

[Thomas007]

In der sip.conf steht ein Beispiel, diesem würde ich gerne folgen
[global]
context= default
register => 2345assword@beliebigerName_sip_proxy
[beliebigerName_sip_proxy]
type = peer
context = provider01
host = mysiprovider.com

Das funktioniert aber bei mir nicht, ich bekomme keine Registrierung zustande.

Was für ein Eintrag fehlt da noch?
Ich habe bereits rumgeraten und ausprobiert, allerdings ohne Erfolg. Auch habe ich keine Doko gefunden, die das näher beschreibt.

 

[kombjuder]

Auch habe ich keine Doko gefunden, die das näher beschreibt.

Probiere es mal damit: http://www.asterisk.li/sip-zwei.htm

 

[Thomas007]

danke für den Tip.
Du gibst register => 4799001[email protected]/4799001 an und definierst dann für einen Context, nämlich [4799001]
Wird der überhaupt für incomming verwendet? Eigentlich wird der doch genommen um mit der extension in der extensions.conf einzuspringen statt s eben 4799001.
Das ist ja das was ich genau nicht möchte, ich möchte z.B. unterschiedliche Codecs und Contexte für unterschiedliche register verwenden und auf s einspringen und nicht über eine beim register definierte extension. Also lieber nach dem Beispiel aus der sip.conf.

; Register 2345 at sip provider 'sip_proxy'. Calls from this provider connect to local
; extension 1234 in extensions.conf default context, unless you define
; unless you configure a [sip_proxy] section below, and configure a context.
; Tip 1: Avoid assigning hostname to a sip.conf section like [provider.com]
; Tip 2: Use separate type=peer and type=user sections for SIP providers
; (instead of type=friend) if you have calls in both directions

Bloß genau das klappt bei mir nicht und dazu habe ich auch keine weiteren Beispiele gefunden.
Dein Beispiel funktioniert aus, wobei ich mir nicht sicher bin, daß für incomming register der Context im sip.conf verwendet wird.

 

[kombjuder]

; Tip 2: Use separate type=peer and type=user sections for SIP providers
; (instead of type=friend) if you have calls in both directions

Dann mache es so wie oben beschrieben. 2 getrennte Einträge (Contexte), einen für incomming und einen für raus. Wobei die Registerzeile bei sipgate so aussehen muss, sonst geht es nicht.