type=friend für Provider

[philwo]

Hallo,

ich beschäftige mich gerade mit Asterisk und stelle fest, dass man für die Konfiguration doch nicht so unbeschreibliche Qualen ertragen muss, wie ich immer dachte. ;-)

Ich habe hier aber zwei Aussagen gefunden, die irgendwie im Widerspruch stehen:

Einerseits haben wir Betateilchens Kurs, da steht, man trennt einen SIP-Provider in ankommende und abgehende Gespräche.

Dann haben wir www.das-asterisk-buch.de, wo der Provider aber über type=friend eingebunden wird, und wo sogar steht: "In der Praxis wird meistens nur Friend benutzt." (http://www.das-asterisk-buch.de/stable/peers-users-friends.html)

Ich habe mal im Forum gesucht und ein paar mal "Man nimmt für Provider nicht type=friend" gefunden - aber nie eine Begründung

Verwechsel ich hier vielleicht auch total was und die beiden Sachen "Trennung von in und out" und "type=friend nimmt man nicht für Provider" haben gar nichts miteinander zu tun?

Ich könnte mir nur vorstellen, dass man damit meinem Provider erlauben würde, über meinen Asterisk auch externe Telefonnummern anzurufen - was ich natürlich nicht will, auch wenn es wohl nie vorkommen würde (andererseits wäre das ein interessantes Geschäftsmodell *g*)

Wo also genau liegt die "Gefahr" darin, oder ist das einfach Geschmackssache? Ich würde mich über eine Erklärung, warum www.das-asterisk-buch.de es anders macht, sehr freuen.

Viele Grüße,
Philipp

 

[betateilchen]

es ist in erster Linie eine Sicherheitsfrage (bezogen auf die Authentifizierung) und eine Frage, wie Asterisk eingehende Anrufe behandelt.

Bei type=friend werden automatisch zwei Objekte innerhalb Asterisk generiert, eines vom Type=peer und eines vom Type=user

Dies führt in der Regel dazu, daß es massive Probleme bei der Zuordnung eingehender Anrufe gibt, weil Asterisk zuerst nach einem Objekt vom type=user sucht, um den ankommenden Anruf zu authorisieren bevor er nach einem Objekt vom type=peer sucht.

Ist der Providercontext nun mit type=friend angelegt, gibt es (s.o.) logischerweise ein Objekt vom Typ user, und der eingehende Anruf wird bezüglich des Authenticates gegen diesen Typ geprüft. Dies wird in den meisten Fällen scheitern. Es wird nach dem Scheitern aber nicht mehr nach einem Objekttyp peer gesucht, deshalb wird der Anruf auf dem Asterisk in vielen Fällen einfach nicht da ankommen, wo man ihn gerne hätte.

---

xDie in meinem Kurs aufgezeigte Trennung nach eingehenden und ausgehenden Kontexten hat einen anderen Hintergrund. Es geht dabei nur um die Darstellung einer zuverlässigen Möglichkeit, wenn man mehrere SIP Accounts beim gleichen Anbieter auf einem einzigen Asterisk nachvollziehbar verwalten möchte. Sowohl der eingehende als auch der ausgehende Kontext sind vom type=peer.

 

[FrankIT]

Es geht dabei nur um die Darstellung einer zuverlässigen Möglichkeit, wenn man mehrere SIP Accounts beim gleichen Anbieter auf einem einzigen Asterisk nachvollziehbar verwalten möchte. Sowohl der eingehende als auch der ausgehende Kontext sind vom type=peer.

Mit type=peer kann man aber in der sip.conf erst mal nicht unterscheiden, auf welchem dieser SIP-Konten ein Anruf hereinkommt.

 

[betateilchen]

doch - genau das kann man

Und in meinem Asterisk Kurs (und auch schon lange davor am Beispiel Sipgate) habe ich auch erklärt, wie und warum.

 

[FrankIT]

:wiejetzt:Wie soll das gehen?

In deinem Asterisk-Kurs liest sich das so:

[sipgate_de_in] 
; Diesen Context brauchen wir nur einmal - 
; egal wieviele Sipgate-Accounts wir registrieren
; wichtig ist, dass dies der LETZTE Context von
; oben nach unten in der sip.conf  betrachtet, ist
; der einen Verweis auf sipgate.de beinhaltet !
; Durch die Angabe von "context = ankommend"
; werden alle Anrufe in den gleichnamigen Context 
; [ankommend] in der extensions.conf geleitet.
;
type=peer
fromdomain=sipgate.de
host=sipgate.de
context=ankommend

Wenn mein Asterisk also mehrere Sipgate-Konten registriert, landen alle ankommenden Anrufe im Kontext "ankommend", egal über welches Konto der Anruf kommt. Unterscheiden kann ich die Konten dann erst im Dialplan, aber eben nicht hier in der sip.conf, solange ich nur mit type=peer arbeite.

 

[betateilchen]

ja ok - so gesehen hast Du recht. Wobei sich mir nicht wirklich der Sinn erschließt, die ankommenden Anrufe bereits in der sip.conf unterscheiden zu müssen.

 

[voipie]

ja ok - so gesehen hast Du recht. Wobei sich mir nicht wirklich der Sinn erschließt, die ankommenden Anrufe bereits in der sip.conf unterscheiden zu müssen.

Diese Unterscheidung kann Sinn machen, wenn man unterschiedliche Capabilities haben will.

Welcher type bei den ankommenden Anrufen würde denn eine Unterscheidung ermöglichen?

 

[betateilchen]

Diese Unterscheidung kann Sinn machen, wenn man unterschiedliche Capabilities haben will.

:wiejetzt:

Welcher Account was kann, lege ich immer in der extensions.conf fest. Das kann ich doch auch in einem zentralen [ankommend] Context auseinandersortieren.

 

[voipie]

-- bt: unnötiges Fullquote entfernt. bitte die Forumregeln beachten! --

In Foren kann man auch keine Frage stellen, ohne gleich alles zu erklären

Ich probier es mal anders: Ich nutze Callweaver, also sowohl Voice als auch Fax. Jetzt stellt sich hier in CH das Problem, dass viele VoIP Anbieter nur Reseller eines Backbones sind. Je nach ankommender Telefonnummer möchte ich aber unterschiedliche t38 capabilities signalisieren. Sprich: die Faxnummer kann t38, die Voice-Nummer nicht. Und das muss ich in der sip.conf setzen.

 

[betateilchen]

Bei mir sind auch die Nur-Voice-Accounts T.38 enabled - das spielt überhaupt keine Rolle, da kein menschlicher Nutzer T.38 direkt oder Faxtöne spricht.

 

[FrankIT]

Welcher type bei den ankommenden Anrufen würde denn eine Unterscheidung ermöglichen?

Da bleiben nicht mehr viele übrig. Mit type=user werden ankommende Anrufe über den Benutzernamen zugeordnet. (Wenn du type=friend nimmst, werden intern zwei Objekte erzeugt – eins als type=user, eins als type=peer.)
Damit lässt sich dann schon in der sip.conf zwischen mehreren Benutzerkonten unterscheiden.

PS: Möglicherweise kommt gleich ein Admin und löscht dein "sinnloses Fullquote". :blonk:

 

[betateilchen]

Das mit type=user setzt aber voraus, daß der Provider überhaupt einen Benutzernamen im ankommenden Anruf mitschickt

 

[voipie]

Dankeschön. Es klappt noch nicht, aber ich weiss jetzt wo ich anzusetzen habe. Bei type=user versucht er über die Caller-Id des eingehenden Anrufes zu authentifizieren. Bei type=friend, merke ich das implizite peer, da er den als letztes definierten Sip-Channel der gleichen IP nutzt. Werde jetzt mal etwas spezifischer nachlesen und experimentieren.

 

[stephanw]

Unterschiedliche Contexte für mehrere Konten

Hallo
ich finde es persönlich sinvoll, die verschiedenen Konten des gleichen Anbieters grad zu Beginn in unterschiedliche Kontexte der extensions.conf zu schicken.

Deshalb habe ich diesen Thread mit Interesse gelesen. Aber leider lässt er offen, ob es nun möglich ist, die unterschiedlichen Konten eines Anbieters in unterschiedliche Kontexte zu schicken...

Hat jemand eine Idee, wie man das machen kann?
Danke und Gruss
Stephan

 

[FrankIT]

Ankommende SIP-Anrufe lassen sich auf zwei Arten einem Kanal der sip.conf zuordnen:

1. mit einem [user], der zu dem Namen passt, der im From-Header steht oder

2. mit einem [peer], dessen from-Attribut mit der Urprungs-IP-Adresse übereinstimmt.

Hat man mehrere SIP-Konten bei demselben Provider, bleibt nur noch Option 1., d.h. man braucht type=user oder type=friend, wenn man die Konten schon in der sip.conf ankommend trennen will.

 

[betateilchen]

Hat man mehrere SIP-Konten bei demselben Provider, bleibt nur noch Option 1

...und auch dann ist nicht gewährleistet, daß es mit jedem Provider funktioniert, weil nicht jeder Provider sich korrekt am Asterisk authentifiziert.​

 

[stephanw]

betateilchen glaube ich es ....

Ok, ich sehs ja ein... scheint kein zuverlässiger Weg zu sein in der sip.conf das zu regeln.
Mal ne ganz blöde Frage:
Wäre es nicht am einfachsten, wenn man beim register anstatt nur die Extensions auch noch den Context angeben könnte? So wies z.B. beim Goto möglich ist (context,extension,priority).
Also z.B.

register=>tel:[email protected]/MyContext/MyExtenesion

Das Ganze scheint mir schon seit langem unlogisch. Ist es nicht so?
[user] => eingehende Anrufe (Braucht aber öffentliche IP des Asterisk)
register => eingehende Anrufe (* registriert sich beim Provider für eingehend, so auch hinter NAT erreichbar)
[peer] => Ausgehende Anrufe

Sehe ich das so richtig? Wenn ja, was in aller Welt hat den ein "context=...." in der Peer Definition verloren?
Ich danke euch scon jetzt, wenn ihr mir helft diesen schwarzen Fleck in meinem * Wissen zu erleuchten

P.S: Ach ja, mein Provider schickt im From: seine Domäne (also z.B. telserver.com). Bringt mich auch nicht viel weiter, da diese ja bei jedem Konto gleich ist.

 

[FrankIT]

Nochmal kurz nachgedacht: Mit einem "normalen" Provider wird es nicht funktionieren, denn da steht im From-Header ja die Rufnummer oder sonstige SIP-Kennung des Anrufers.

Am sinnvollsten ist es wohl, in der Registrierung eine eindeutige Extension anzugeben. Im Dialplan ist es dann relativ einfach, die ankommenden Anrufe anhand dieser Extension zu unterscheiden.

 

[betateilchen]

@FrankIT gut, daß Du da endlich auch draufkommst Übrigens wird auch das mit der eindeutigen Extension nicht immer funktionieren, da es viele Provider gibt, die das einfach ignorieren.

@stephanw
Du hast so viele Denkfehler in Deinem letzten Posting, daß ich gar nicht weiß, wo ich anfangen soll

Aber mal zwei wichtige Dinge:

1. auch eingehende Anrufe sollten in einem PEER Context abgehandelt werden, und DA brauchst Du dann natürlich auch einen context= Eintrag
2. was Du im register => hinter dem letzten / angibst, hat nichts mit "myextension" zu tun, sondern wird in den contact Header der REGISTER SIP message geschrieben, die an den Server geht. Da würde irgendeine zusätzlich Information absolut keinen Sinn für Deinen Asterisk machen, da das register ausschließlich für den "fremden" Server bestimmt ist. Außerdem ist auch ein register => gar nicht immer notwendig

Arbeite Dich doch mal komplett durch meinen Asterisk Kurs hier im Forum - da sind solche Grundlagen beschrieben und erklärt.

 

[stephanw]

Vieles klar...

Danke Betateilchen...
Der gröbste Denkfehler war wohl, dass ich nicht gecheckt habe, dass die Extension im register für den Provider gedacht ist.... So wird dann vieles klarer.

Und das mit den verschiedenen Peer Kontexten, wo der letzte in der sip.conf für eingehend berücksichtigt wird, ist zwar eine Lösung, aber schon etwas holprig.

Aber ich weiss nun, was ich tue, und da ist mir schon viel wohler dabei

Danke nochmals und schönen Tag
Stephan