Eingehender Context - Zum allgemeinen Verständnis

Friederich · 24 Mrz 2014

Hallo,

Vielleicht kann mir ja jemand auf die Sprünge helfen und mir mal erklären, wie Asterisk den Context für eingehende Anrufe bestimmt.
Mein Setup ist ein Asterisk in einem LAN mit ein paar lokalen Clients. Der Asterisk hat 3 "äußere" Nummern bei einem SIP-Provider registriert.

also sip.conf in etwa so:

Code:

[general]
...

register => 031234567:3322332233:[email protected]@tel.t-online.de/031234567
register => 031234568:3322332234:[email protected]@tel.t-online.de/031234568
register => 031234569:3322332235:[email protected]@tel.t-online.de/031234569

[t-online]
context=ankommend
type=friend
secret=123456
host=tel.t-online.de
realm=tel.t-online.de
fromdomain=tel.t-online.de
[email protected]
directmedia=no
;outboundproxy=tel.t-online.de

defaultexpiry=300
maxexpiry=300

nat=yes         ; Eigener Server steht hinter NAT-Firewall (ankommende Rufe)
qualify=yes     ; Connectivität prüfen
canreinvite=no  ; no=Clients können sich nur über Asterisk-Server verbinden

insecure=port,invite

;session-timers=refuse

In der Anleitung von betateilchen (Dank, Dank und nochmals Dank dafür!) findet sich je ein Context für ausgehende Gespräche und einer für eingehende Gespräche.

Der Kontext für eingehende Gespräche ist in der Anleitung

Code:

[sipgate_de_in] 
...
type=peer
fromdomain=sipgate.de
host=sipgate.de
disallow=all
allow=ulaw
context=ankommend

und er steht ganz am "Ende" der Datei.
Das Setup hat bei mir glaube ich auch so nicht funktioniert (Asterisk 1.8).

Also ich frage mich nun: Wie bestimmt der Asterisk den Kontext für eingehende Gespräche genau?
Über "host=" oder "fromdomain=" des letzten (von oben nach unten) matchenden Kontextes? Warum sind ein- und ausgehender Kontext vom Typ "peer" (darf ja normalerweise nur raustelefonieren)

wildzero · 24 Mrz 2014

Man benötigt keine zwei Kotexte für ein/ausgehende peers. In deinem Fall sollte bereits alles von tel.t-online.de kommend im Dialplan unter "ankommend" landen? Was genau funktioniert nicht?

Wie bestimmt der Asterisk den Kontext für eingehende Gespräche genau?

Mittels "host=" wenn dieser != dynamic ist.

Friederich · 24 Mrz 2014

[EDIT]Also bei mir kommen die Gespräche in "ankommend" an. Das funktioniert soweit.[/EDIT]

Also es gibt hier jetzt folgendes Problem mit Asterisk:

Nach einer Weile (ich nehme an nach einem IP-Wechsel am DSL-Router) kommen die Gespräche plötzlich in den [default]-Context! (Oder eben den, den ich unter [general] eingestellt habe)

Seltsamerweise ändert sich die CHANNEL-Variable bei ankommenden Gesprächen:
Ist Asterisk neu gestartet lautet ${CHANNEL}:

Code:

SIP/telekom_channel_0-00000...

und der Anruf gelangt in den Kontext "ankommend" für den host "tel.t-online.de"!

Nach der besagten Weile ändert sich ${CHANNEL} für Anrufe auf der Verbindung auf

Code:

SIP/tel.t-online.de-000000...

und der Kontext ist dann auch nicht mehr "ankommend", d.h. offenbar wird der eingehende Ruf nicht über [t-online] in sip.conf abgewickelt.

Kann man das verstehen?

rentier-s · 25 Mrz 2014

Verwendet T-Online Load Balancer? Das würde dieses Verhalten erklären. Oder Du hast nach einer bestimmten Zeit ein Problem mit der DNS Auflösung, so dass der host Eintrag nicht mehr aufgelöst und somit nicht der IP Adresse des INVITE zugeordnet werden kann.

Friederich · 25 Mrz 2014

Dass die DNS-Auflösung nicht korrekt ist, halte ich für unwahrscheinlich. Aber gut, man weiss ja nie ...
Also ich werde das nochmal beobachten und evtl. morgen nochmal die "Ergebnisse" bringen.
Danke schonmal für den Tip.

Friederich · 26 Mrz 2014

Ich bringe hier nochmal meine (fast) vollständige sip.conf:

Code:

[general]
externhost=myhost123.no-ip.org
externrefresh=600

localnet=192.168.6.0/255.255.255.0
bindport=5065
bindaddr=0.0.0.0

language=de

maxexpiry=3600
minexpiry=60
defaultexpiry=600

registertimeout=30
registerattempts=0

nat=no
canreinvite=no

dtmfmode=rfc2833

stunaddr=stun.t-online.de
stunrefresh=30


register => 031234567:3322332233:[email protected]@tel.t-online.de/031234567
register => 031234568:3322332234:[email protected]@tel.t-online.de/031234568
register => 031234569:3322332235:[email protected]@tel.t-online.de/031234569
context=ankommend_default

[telekom_channel_macro](!)
context=ankommend_tk
type=friend
secret=123456
host=tel.t-online.de
realm=tel.t-online.de
fromdomain=tel.t-online.de
[email protected]
directmedia=no
;outboundproxy=tel.t-online.de

defaultexpiry=300
maxexpiry=300

nat=yes         ; Eigener Server steht hinter NAT-Firewall (ankommende Rufe)
qualify=yes     ; Connectivität prüfen
canreinvite=no  ; no=Clients können sich nur über Asterisk-Server verbinden

insecure=port,invite

;session-timers=refuse

[telekom_channel_0](telekom_channel_macro)
fromuser=031234567

[telekom_channel_1](telekom_channel_macro)
fromuser=031234568

[telekom_channel_2](telekom_channel_macro)
fromuser=031234568

[localphones]
...

So. Also heute morgen war es mal wieder soweit.
Eingehende Rufe wurden wieder im [general]-Kontext "empfangen" und nicht im zum Host gehörenden [telekom_channel_0]

Wie gehabt:
- Nach einem /etc/init.d/asterisk restart kommen die Gespräche korrekt über [ankommend_tk] mit CHANNEL "SIP/telekom_channel_0-000..".

- Nach einer Weile dann kommen Gespräche über [ankommend_default] mit CHANNEL "SIP/tel.t-online.de-000.." oder auch mal "SIP/anonymous.invalid-000.."
Auch habe ich hier eine Meldung (allerdings _nach_ einem beendetem Gespräch) gehabt:
"chan_sip.c:3656 retrans_pkt: Retransmission timeout reached on transmission [email protected] for seqno 15699 (Critical Response) -- See https://wiki.asterisk.org/wiki/display/AST/SIP+Retransmissions Packet timed out after 31999ms with no response"

Was ich getestet habe:
- Der Asterisk steht hinter einer Fritzbox, deren IP ich soeben mal testweise geändert habe. Das hat aber keine Änderung bewirkt (eingehende Gespr. kommen danach trotzdem noch korrekt über [telekom_channel_0])
- Die Namensauflösung (im system) hat die ganze Zeit über korrekt funktioniert.

Wie ist das erklärbar?
Die Retransmission-Warnung kommt ja typischerweise wenn man "nat=no" gesetzt hat, was bei mir im [general]-Kontext der Fall ist
- Liegt es evtl. am Macro? (Ich hatte schon Probleme mit dem verfluchten macro-kram in der extensions.conf)
- Liegt es vielleicht daran, dass die Asterisk-interne Auflösung über IP funktioniert und diese DNS-Abfrage nur einmal am Anfang geschieht und dank Load-Balancing der Telekom irgendwann eine neue IP der Telekom die Gespräche schickt, die im Asterisk nicht bekannt ist? Wenn ja, wie kann man das im Asterisk handhaben?

Was ich jetzt mal teste (reine Verzweiflungstaten):
- nat provisorisch auch im [general]-Kontext angeschaltet (das benötigt man für int. Telefone, die auch raustelefonieren eigentlich nicht, oder?)
- in dnsmgr.conf enable=yes (ist das sinnvoll?), was löst der DNS-Manager denn genau auf? Auch die IPs der eingehenden Verbindungen?
- qualifyfreq=300 für den Telekom-Host (http://www.ip-phone-forum.de/showthread.php?t=258023), man weiss ja nie

Vielleicht hat jemand einen Tip, was da läuft? Ich bin ziemlich ratlos...

abw1oim · 26 Mrz 2014

Wie von rentier-s angemerkt, verwendet T-Online (respektive die Telekom) Loadbalancer. Da Asterisk bei eingehenden Anrufen die IP-Adresse in der sip.conf matcht, klappt hier der match nicht, wenn ein anderer als der/die konfigurierten hosts (hier: tel.t-online.de) im Paket enthalten ist. Da hilft auch kein dnsmgr von Asterisk, wenn eben die Telekom die Loadbalancer nach außen nicht maskiert (das ist das gleiche Problem wie bei 1und1).
Da hilft nur, die Telekom-Hosts - soweit bekannt - alle als eigene Incoming-peers mit dem gewünschten Kontext in die Konfig aufzunehmen, andernfalls landet man im Kontext des General-Abschnittes ankommend_default (oder wenn dort nicht konfiguriert eben in default), sofern allowguests=yes ist, andernfalls wird dann der Anruf sogar abgewiesen.
Kurze Rede, langer Sinn ... hier mal meine aktuelle Telekom-Zusatzkonfig aller mir bekannten Hosts in der Loadbalancer-Gruppe ohne Garantie auf Vollständigkeit (Stand: 16.04.2014):

Code:

[external-standard](!)
	type=peer
	usereqphone=no
	t38pt_udptl=no
	nat=force_rport,comedia
	directmedia=no
	disallow=all
	allow=ulaw
	allow=alaw
	dtmfmode=rfc2833
	context=ankommend_tk

[DTAG-IP_IN16_026](external-standard)
host=217.0.16.26
trustrpid=no


[DTAG-IP_IN16_035](external-standard)
host=217.0.16.35
trustrpid=no


[DTAG-IP_IN16_090](external-standard)
host=217.0.16.90
trustrpid=no


[DTAG-IP_IN16_102](external-standard)
host=217.0.16.102
trustrpid=no


[DTAG-IP_IN16_106](external-standard)
host=217.0.16.106
trustrpid=no


[DTAG-IP_IN16_154](external-standard)
host=217.0.16.154
trustrpid=no


[DTAG-IP_IN16_163](external-standard)
host=217.0.16.163
trustrpid=no


[DTAG-IP_IN16_166](external-standard)
host=217.0.16.166
trustrpid=no


[DTAG-IP_IN16_170](external-standard)
host=217.0.16.170
trustrpid=no


[DTAG-IP_IN16_230](external-standard)
host=217.0.16.230
trustrpid=no



[DTAG-IP_IN17_026](external-standard)
host=217.0.17.26
trustrpid=no


[DTAG-IP_IN17_035](external-standard)
host=217.0.17.35
trustrpid=no


[DTAG-IP_IN17_090](external-standard)
host=217.0.17.90
trustrpid=no


[DTAG-IP_IN17_102](external-standard)
host=217.0.17.102
trustrpid=no


[DTAG-IP_IN17_106](external-standard)
host=217.0.17.106
trustrpid=no


[DTAG-IP_IN17_154](external-standard)
host=217.0.17.154
trustrpid=no


[DTAG-IP_IN17_163](external-standard)
host=217.0.17.163
trustrpid=no


[DTAG-IP_IN17_166](external-standard)
host=217.0.17.166
trustrpid=no


[DTAG-IP_IN17_170](external-standard)
host=217.0.17.170
trustrpid=no


[DTAG-IP_IN17_230](external-standard)
host=217.0.17.230
trustrpid=no



[DTAG-IP_IN19_026](external-standard)
host=217.0.19.26
trustrpid=no


[DTAG-IP_IN19_035](external-standard)
host=217.0.19.35
trustrpid=no


[DTAG-IP_IN19_090](external-standard)
host=217.0.19.90
trustrpid=no


[DTAG-IP_IN19_102](external-standard)
host=217.0.19.102
trustrpid=no


[DTAG-IP_IN19_106](external-standard)
host=217.0.19.106
trustrpid=no


[DTAG-IP_IN19_154](external-standard)
host=217.0.19.154
trustrpid=no


[DTAG-IP_IN19_163](external-standard)
host=217.0.19.163
trustrpid=no


[DTAG-IP_IN19_166](external-standard)
host=217.0.19.166
trustrpid=no


[DTAG-IP_IN19_170](external-standard)
host=217.0.19.170
trustrpid=no


[DTAG-IP_IN19_230](external-standard)
host=217.0.19.230
trustrpid=no



[DTAG-IP_IN20_026](external-standard)
host=217.0.20.26
trustrpid=no


[DTAG-IP_IN20_035](external-standard)
host=217.0.20.35
trustrpid=no


[DTAG-IP_IN20_090](external-standard)
host=217.0.20.90
trustrpid=no


[DTAG-IP_IN20_102](external-standard)
host=217.0.20.102
trustrpid=no


[DTAG-IP_IN20_106](external-standard)
host=217.0.20.106
trustrpid=no


[DTAG-IP_IN20_154](external-standard)
host=217.0.20.154
trustrpid=no


[DTAG-IP_IN20_163](external-standard)
host=217.0.20.163
trustrpid=no


[DTAG-IP_IN20_166](external-standard)
host=217.0.20.166
trustrpid=no


[DTAG-IP_IN20_170](external-standard)
host=217.0.20.170
trustrpid=no


[DTAG-IP_IN20_230](external-standard)
host=217.0.20.230
trustrpid=no

Friederich · 26 Mrz 2014

Danke, sowas hab ich mittlerweile befürchtet. Das mit den einzelnen Kontexten/IP ist ja gut und schön, aber man muss dann wohl auf der Hut sein, sollte die Telekom auf die Idee kommen, da was zu ändern.
Schön wäre es halt gewesen, wenn an der Stelle ein reverse-Lookup gemacht worden wäre.

Ich schiebe also nun einfach alles eingehende via [general] einen default-Kontext der extensions.conf. Ich sortiere dort eh' schon nach dem SIP-TO-Header.

Gibt es dabei erfahrungsgemäß irgendetwas besonderes zu beachten (sicherheitstechnisch...)?

Dank und Grüße
Friederich

sparkie · 26 Mrz 2014

Friederich schrieb:
Ich schiebe also nun einfach alles eingehende via [general] einen default-Kontext der extensions.conf. Ich sortiere dort eh' schon nach dem SIP-TO-Header.

das mache ich bei mir genauso. Dann ist man von den IP-Adressen unabhaengig. Selbst Anrufe ueber diverse externen native-ISDN Busse landen bei mir im (einzigen) incoming-context. Dort hat man dann alle noetigen Infos um das Zeug wieder nach Bedarf zu separieren. Zu diesem Zweck in diesem Context einfach mal den maximalen debug im Asterisk anwerfen und man sieht was alles an Unterscheidungskriterien vorhanden ist.

- sparkie

xrated · 29 Mrz 2014

Wenn man derart viele Peers definiert, läuft man in die Gefahr das man vom ISP ausgesperrt wird wegen der Unzahl an Anfragen, insbesondere wenn dann noch Qualify verwendet wird. Bei z.B. 1&1 gibts mittlerweile über 50 Peers, das sollte man nicht unterschätzen.

Das sortieren im Default Context via Header ist sicherheitstechnisch auch nicht so das wahre, weil das leicht zu fälschen ist.

Genial wäre es wenn man in Asterisk beim Peer zusätzlich einen Adressrange definieren könnte für eingehende Anrufe wo auch das insecure gilt. Sonst wird der Peer ja nur verwendet wenn die Quelle vom Anruf dem host matched.

abw1oim · 29 Mrz 2014

wenn man in Asterisk beim Peer zusätzlich einen Adressrange definieren könnte

Da kannst Du ja mal über JIRA einen CR stellen

Ansonsten: Natürlich sind diese verschiedenen PEERS beim Loadbalancing nicht über qualify zu verifizieren, dann kann tatsächlich eine Sperrung erfolgen, da man die Gegenstelle "ärgert". Wenn ein qualify gebraucht wird, um etwa das NAT am Router offen zu halten, sollte das nur zu genau einer Gegenstelle des Loadbalancer-Verbandes gehen, das wäre in dem konkreten Beispiel etwa tatsächlich der FQDN tel.t-online.de, den man eben auch zur abgehenden Telefonie verwendet.

xrated · 29 Mrz 2014

abw1oim schrieb:
Wenn ein qualify gebraucht wird, um etwa das NAT am Router offen zu halten, sollte das nur zu genau einer Gegenstelle des Loadbalancer-Verbandes gehen, das wäre in dem konkreten Beispiel etwa tatsächlich der FQDN tel.t-online.de, den man eben auch zur abgehenden Telefonie verwendet.

Nur ob die anderen Server dann bescheid wissen wenn sich deine IP geändert hat, da würde ich mich auch nicht auf NAT-T verlassen. Lieber NAT vernünftig einstellen und externhost verwenden damit die Public IP im Sip Header erscheint statt der privaten IP. Den Qualify benütze ich primär zur Überwachung mit Nagios. Da habe ich einfach den Interval massiv erhöht.

Ich habs erstmal hier geschrieben:
http://blog.gmane.org/gmane.comp.telephony.pbx.asterisk.user

Habe letztens erst hier was erreicht:
https://issues.asterisk.org/jira/browse/ASTERISK-20841

abw1oim · 29 Mrz 2014

Korrekte NAT-Einstellungen sind natürlich was Feines, wenn man eben selbst allles einstellen kann.
Ich sag' nur WLAN-Netze auf deren (NAT)-Controller man keinen Zugriff hat. Da hab' ich schon Kundenszenarien gehabt mit NAT hinter NAT - dann wird Arbeiten mit SIP zum Albtraum

Friederich · 31 Mrz 2014

Dank erstmal an alle!

Aber nach Tagen mit diesem verfluchten Telekomanschluss bin ich nun irgendwie restlos verwirrt.
Also welche Einstellungen sollte man denn genau in der sip.conf haben, wenn man die Sache mit dem eingehenden Rufen per default-Context regelt?
Ist es richtig, dass [general] dann für eingehende Anfragen und [telekom_channel_0] (s.o. #6) nur noch für ausgehende Verbindungen gilt?

Welche Einstellungen sollten denn dann in welchem Context getroffen werden?
-> nat=??
-> canreinvite=??
-> externrefresh=??
...
( abw1oim: Danke für deine Konfig, aber ich kenne da ja den "general"-Teil nicht ...)

Wie sollte man die Portweiterleitungen auf dem NAT-Router davor setzen? Reicht 5060 (bzw. 5065 bei mir s. #6), oder noch die "oberen" UDP-Ports?
Sollte man den Stunserver nutzen, oder ist das an der Fritzbox eher kontraproduktiv?

Sollte (und kann) man die (lokalen) Clients so einstellen, dass auch Gesprächsdaten grundsätzlich über den Asterisk laufen (Outbound-Proxy?) - Geht das überhaupt?
Wenn es nicht geht, wie handhabt man dieses Problem am besten bzgl. NAT?

Noch eine allgemeine Frage:
Wenn sich Asterisk am Trunk registriert, dann übermittelt Asterisk seine IP (intern) oder seine externe Adresse?
Was passiert, wenn er nach einem Reconnect eine neue Adresse bekommt?

Ach, Fragen über Fragen!

rentier-s · 1 Apr 2014

Ist es richtig, dass [general] dann für eingehende Anfragen und [telekom_channel_0] (s.o. #6) nur noch für ausgehende Verbindungen gilt?

Jein. Wenn allowguest=yes ist, landen alle nicht authentifizierten Anrufe in dem im [general] gesetzten Context. Ein mittels passendem host und insecure zuordenbarer Anruf wird im Context des entsprechenden peer landen (den Effekt hast Du ja bereits beobachtet).

Welche Einstellungen sollten denn dann in welchem Context getroffen werden?

nat=yes im [general] und no bei den rein lokalen Clients
canreinvite gibt es nicht mehr, heißt directmedia und directrtpsetup, bei Audio-Problemen auf no setzen
externrefresh muss zusammen mit externhost verwendet werden, localnet nicht vergessen

http://www.voip-info.org/wiki/view/Asterisk+config+sip.conf#SIPConfigurationgeneral

Wie sollte man die Portweiterleitungen auf dem NAT-Router davor setzen?

Den SIP Port (sip.conf bindport) und die RTP Ports (rtp.conf).

Sollte man den Stunserver nutzen, oder ist das an der Fritzbox eher kontraproduktiv?

Wäre eine Alternative zu externhost.

Sollte (und kann) man die (lokalen) Clients so einstellen, dass auch Gesprächsdaten grundsätzlich über den Asterisk laufen

Was meinst Du mit Gesprächsdaten? Asterisk ist kein Proxy, sondern eine PBX, im Client darf also ausschließlich Asterisk als Host eingetragen sein.

Wenn sich Asterisk am Trunk registriert, dann übermittelt Asterisk seine IP (intern) oder seine externe Adresse?

Je nachdem, ob das Ziel im in localnet definierten Bereich liegt. (soweit mein Verständnis)

Was passiert, wenn er nach einem Reconnect eine neue Adresse bekommt?

Stichwort externrefresh

Friederich · 1 Apr 2014

nat=yes im [general] und no bei den rein lokalen Clients
canreinvite gibt es nicht mehr, heißt directmedia und directrtpsetup, bei Audio-Problemen auf no setzen
externrefresh muss zusammen mit externhost verwendet werden, localnet nicht vergessen
http://www.voip-info.org/wiki/view/Asterisk+config+sip.conf#SIPConfigurationgeneral

Danke.

Was meinst Du mit Gesprächsdaten? Asterisk ist kein Proxy, sondern eine PBX, im Client darf also ausschließlich Asterisk als Host eingetragen sein.

Damit meine ich die Mediadaten, also die Audiostreams.
Die laufen doch (im Normalfall) direkt von Telefon zu Telefon (oder zum telekom-trunk?) und Asterisk vermittelt diese Endpunktadressen nur, richtig?
Oder laufen diese Daten immer über den Asterisk? Die Anzahl der durch Asterisk allozierten RTP-Ports lässt darauf schließen ... oder werden die zehntausend UDP-Ports für Anrufbeantworter und angeschlossene Analog-/ISDN-Telefone benötigt?

Sollten die Mediastreams vom SIP-Telefon direkt zum Ziel laufen, wie handhabt man das am besten am NAT-Gateway?

Und: Welche Einstellungen muss man eigentlich an den SIP-Telefonen treffen? Asterisk nur als Registrar und fertig?

\[Stun..\]Wäre eine Alternative zu externhost.

Soweit ich stun verstanden habe, wird damit nur festgestellt, welche externe IP der benutzende hat und auf welchem Port das NAT-Gateway auf Rückantwort lauscht (die er dann an den internen Client weitergibt). Das würde doch im Grunde nur die UDP-Portweiterleitung ersetzen konnen (wenn alles gut geht, und vor jeder Connection eine neue Abfrage gemacht wird).
Oder wird das wirklich dann auch bei jedem (Re-)Registrieren verwendet?

(Ich hoffe ich nerve nicht)
Gruß
Friederich

xrated · 2 Apr 2014

Die Gesprächsdaten laufen im Normalfall immer über Asterisk der diese bridged. Wenn man directmedia=yes einstellt dann laufen die Gespräche von Endgerät zu Endgerät aber bei NAT funktioniert das nicht mehr.
In rtp.conf reichen meist auch wesentlich weniger Ports, je nachdem wie viele Gespräche man gleichzeitig führen will.

Stun ist einfach nur eine Alternative Möglichkeit wenn man kein NAT nutzen kann/will. Der Traffic läuft dann über einen externen Server z.B. stun.sipgate.de

rentier-s · 2 Apr 2014

Friederich schrieb:
Welche Einstellungen muss man eigentlich an den SIP-Telefonen treffen? Asterisk nur als Registrar und fertig?

Genau so, vorausgesetzt die Telefone sind im gleichen Netzwerk.

xrated schrieb:
Die Gesprächsdaten laufen im Normalfall immer über Asterisk der diese bridged.

Das kann man so pauschal nicht sagen. Es gibt verschiedene Aspekte, die Asterisk veranlassen, im Audiostrom zu bleiben. Die Flags für DTMF Funktionen bei Verwendung von inband DTMF sind ein Beispiel. Bridging funktioniert außerdem nur, wenn nicht transcodiert werden muss.

xrated schrieb:
In rtp.conf reichen meist auch wesentlich weniger Ports

Zwei pro (Sprach-)Kanal, wobei der erste gerade ist.

xrated schrieb:
Stun ist einfach nur eine Alternative Möglichkeit wenn man kein NAT nutzen kann/will. Der Traffic läuft dann über einen externen Server z.B. stun.sipgate.de

Nein. STUN ist eine Technik, um das Vorhandensein und den Typ eines NAT zu ermitteln. Mit dem Datenstrom an sich hat der STUN Server nichts zu tun, das wäre ein Proxy.

@Friedrich, das hast Du grundsätzlich richtig verstanden. Ein NAT hält den Port aber nur eine bestimmte Zeit offen, ohne Keepalive (zB. qualify) nutzt STUN allein deshalb nicht viel, wenn man ankommende Anrufe erwartet.
Die zuverlässigste Variante für Asterisk ist imho immer noch externip bzw. externhost + externrefresh und Portforwarding wie beschrieben.

xrated · 4 Apr 2014

Unter gmane.comp.telephony.pbx.asterisk.user hat sich übrigens niemand gemeldet auf meinen Vorschlag einen Range fürs Peer Matching zu definieren. Kann mir aber schlecht vorstellen das das so wenige Leute betrifft. Und selbst habe ich leider keinerlei Erfahrung mit C++ sonst würde ich selbst was machen.

@rentier-s
gibts für Bridged mehrere Bedeutungen? So ganz kann ich der Erklärung nicht folgen.
Bei rtcp gibts ja z.B. rtpaudioqos für den lokalen channel der das Gespräch initiiert und rtpaudioqosbridged für den anderen channel der von Dial aufgerufen wird.
Und ich dachte mir das Asterisk zwischen diesen 2 channels dann die Gesprächsdaten verbindet (bridged) wenn kein directmedia eingestellt ist. Damit sich die 2 channels gegenseitig überhaupt verständigen können.

rentier-s · 7 Apr 2014

xrated schrieb:
gibts für Bridged mehrere Bedeutungen?

Bisschen OT, aber das erlauben wir uns einfach mal. Wenn im Zusammenhang mit Asterisk von "bridging" gesprochen wird, verstehe ich darunter native bridging (bypass) bzw. packet-to-packet bridging (audio passthrough).

Eingehender Context - Zum allgemeinen Verständnis

Neuer User

Mitglied

Neuer User

rentier-s

Guest

Neuer User

Neuer User

Aktives Mitglied

Neuer User

Aktives Mitglied

Mitglied

Aktives Mitglied

Mitglied

Aktives Mitglied

Neuer User

rentier-s

Guest

Neuer User

Mitglied

rentier-s

Guest

Mitglied

rentier-s

Guest

Statistik des Forums