RTP-Ports für einzelne Verbindung ermitteln/bestimmen

[Mulle75]

Hallo,

ich stehe hier vor einem Problem, zu dem ich durch google und Suchfunktion hier im Forum noch keine Lösung gefunden habe.
Und zwar möchte ich die verwendeten RTP Ports für eine einzelne Verbindung ermitteln, oder aber diese explizit festlegen. Man kann zwar in der rtp.conf eine Port-Range festlegen, aus welcher sich Asterisk welche rausnimmt, aber dies ist wohl zufällig, wenn ich das richtig verstanden habe.
Gibt es eine Funktion oder eine Variable mit der ich das feststellen kann? Über sachdienliche Hinweise die zur Lösung des Problems führen wäre ich sehr froh

Mit freundlichen Grüßen
Manuel

 

[Ottone]

Was genau ist der Hintergrund dieser Frage, was möchtest Du erreichen?

Die Antwort lautet ersteinmal "Nein".

Du könntest aber z.B. einen SIP proxy mit media proxy dem Asterisk vorschalten, oder Dir die offenen Ports Deines Rechners anschauen (mit netstat und Konsorten), oder per "sip set debug" im CLI die Verhandlung der RTP ports mitlesen.

 

[Mulle75]

Hallo, und danke schonmal für die schnelle Antwort.

Was ich möchte ist folgendes:
Der Asterisk hängt an einer Satellitenverbindung - da gibt es 2 Arten von Dienstklassen, eine best-effort (standard) Verbindung, und eine mit zugesicherter Dienstgüte (streaming). Letztere ist teurer und soll nur im Falle einer zustande kommenden Verbindung aufgebaut werden. (Bzw, wenns nur eine wäre wäre das weniger problematisch, es sollen bis zu 8 sein). Man kann zusätzlich zu solch einer Standardverbindung bis zu 8 Streamingverbindungen aktivieren, dabei wird dann über ein Traffic Flow Template bestimmt, welcher Traffic über welche Verbindung läuft. Mein Gedanke war dann halt, dass ich das anhand der RTP-Ports bestimme, da sich daran ja die Verbindungen unterscheiden lassen. Also z.B. Verbindung 1 läuft über 10000 und 10001, Verb. 2 über 10010 und 10011 etc. So dass ich dann ein TFT festlege, welches eben jede RTP-Verbindung über eine eigene Streaming-Verbindung laufen lasse.

Das ganze soll natürlich automatisch geschehen, weswegen die Sache mit SIP-Debug mitlesen flachfällt.
Wieviel Aufwand wäre es denn (grob geschätzt), wenn ich da ein SIP-Proxy und Media-Proxy zusätzlich installiere? :|

Gruß
Manuel

 

[Ottone]

Wie wäre denn eine Unterscheidung mittels QoS (TOS, DiffServ) usw.?

 

[Mulle75]

Uff, da bin ich gerade etwas überrumpelt. Also bei den TFT's kann ich auf jeden Fall auch einen TOS-Wert angeben.
Entschuldige die wahrscheinlich blöde Frage...setze ich dann in der sip.conf für den entsprechenden User einfach "tos=0xXX" (XX = 2 Hex Ziffern)? Oder sehe ich das falsch? Wenn das so ginge wäre das natürlich ausgezeichnet.

Danke nochmals und Grüße aus der Sauna die sich Büro schimpft

Manuel

 

[Ottone]

Schau mal im Wiki nach.

 

[Mulle75]

Hallo,

also ich habe mal im Wiki geschaut, aber ich bin mir nicht ganz sicher ob ich das richtig verstanden habe.
Kann ich die tos-bits also nur für _alle_ SIP-Verbindungen einstellen? Weil wenn ich tos=0x10 bei [general] in die sip.conf eintrage, dann steht beim Starten von Asterisk nach Parsing sip.conf => "Using SIP TOS: lowdelay", wenn ich jedoch versuche bei den einzelnen Benutzern einen TOS-Wert einzutragen, dann steht da "Using SIP TOS: none". Was ja ansich wohl korrekt ist, jedoch finde ich keinen Hinweis darauf, ob das dann evtl doch für die einzelnen User gesetzt wird...ich bin gerade leicht am verzweifeln hier

 

[Ottone]

Ich denke das ist nur generell einstellbar, nicht pro user/peer. Auf OS Ebene lassen sich die Dinge allerdings noch weiter verbiegen, siehe auch "traffic shaper", "wondershaper" usw.

 

[Mulle75]

Ok, dann werd ich mal zu diesen Stichworten weiterrecherchieren. Vielen Dank für Deine Zeit und Mühe.

Gruß
Manuel

 

[Ottone]

Es gibt noch einen dritten Weg: Viele SIP Endgeräte wie z.B. SNOM Telefone erlauben auch selbst das setzen von TOS Werten, dann müsstest Du nur dafür sorgen dass Asterisk dies nicht wieder überschreibt (sofern der audio traffic überhaupt über Asterisk geführt wird, Stichwort "media path").

 

[Mulle75]

Also der RTP Traffic soll schon über Asterisk laufen. Eines der Telefone das ich hier habe erlaubt auf jeden Fall das manuelle setzen des TOS-Wertes, bei den anderen muss ich mal noch schauen.
Zumal sich jetzt noch an anderer Stelle ein Problem aufgetan hat, an der ich schon fest davon ausging dass es funktioniert...seufz, wieso muss am Ende immer alles knüppeldick kommen

 

[Ottone]

Ich nenne soetwas einen "Rückwärtstag" ;-(

 

[Mulle75]

Hehe, ja das ist aber noch beschönigend ausgedrückt. Und dummerweise häufen sich diese Tage, je näher es an den Abgabetermin geht

 

[laureen]

kleine anmerkung meinerseits: wir haben eine voip sat-verbindung in den senegal über ses-astra, das einzige was uns merkbare verbesserungen der latenz und verringerung der packet-losses auf 0 (!!!) brachte, war ein vpn tunnel. wir haben dazu openvpn verwendet, und das läuft besser als das ganze qos/tos/etc. weil der carrier nicht in die pakete reinschauen kann und deswegen auch rtp pakete nicht runterpriorisiert werden.

hoffe, das hilft!

grüße,
laureen

 

[Mulle75]

Hallo,

danke für den Hinweis, aber ich fürchte, dass mir das erstmal nicht weiterhilft. Oder kann ich denn damit irgendwie 2 verschiedene Telefonate unterscheiden? (Evtl. anhand des SPI?) Sorry, ich habe keinerlei Erfahrung mit VPN

 

[laureen]

langsam, reden wir mal über das loch in der wand, von dem es dir egal ist, wie es zustande kommt, und nicht über die bohrmaschine, also mal einen schritt zurück. du willst den traffic unterscheiden, der über 2 unterschiedliche logische links ("standard" und "stream") gesendet werden soll, richtig? gehen wir mal davon aus, du würdest alles über den "standard" schicken, was sind da deine befürchtungen bzw. welche probleme würden sich dadurch aus deiner sicht ergeben?

[EDIT] und kannst du bitte mal genau deine situation beschreiben oder sagen, ob ich das richtig verstanden habe:
asterisk -> firewall -> router -> sat -> router -> firewall -> telefone
[/EDIT]

grüße,
laureen

 

[Mulle75]

Hallo,

also die Situation ist die folgende:

WLAN-Telefon(e) -> WLAN-AP -> Asterisk -> Sat-Terminal <Sat-Link> Internet -> SIP-Server an public IP -> Telefon(e)

Bei der Sat-Verbindung kann man zusätzlich zu einer Standardverbindung auch noch _mehrere_ Streamingverbindungen aufbauen. Wenn ich lediglich eine einzelne Verbindung laufen hätte wäre es unproblematisch einfach ein TFT (Traffic Flow Template) anzulegen, in dem ich die Ports, die ich in der rtp.conf stehen hab über diese Streamingverbindung schicke. Allerdings sollen, wenn n Telefonate laufen auch n Streamingverbindungen stehen, so dass jedes Gespräch eine eigene hat. Und an dieser Stelle stehe ich vor dem Problem, wie ich die verschiedenen Gespräche unterscheiden kann. (Um Deine Metapher aufzugreifen: Ich stehe vor einer Wand mit n Löchern, habe n Kabel die durch jeweils ein Loch passen - nur brauch ich jemanden der die Kabel sortiert und ins richtige Loch quetscht )

Alles über die Standardverbindung schicken geht aus dem Grund nicht, dass das ein best-effort Dienst ist, ich aber eine feste QoS brauche - dies lässt sich eben über diese Streamingverbindungen machen.

 

[Ottone]

Was für Möglichkeiten zur Diskriminierung bieten Dir denn die TFTs überhaupt an? Bislang haben wir port(s) und TOS.

 

[Mulle75]

Ein TFT besteht aus einem oder mehreren Paketfiltern mit folgenden Parametern:
- Source Address
- Subnet Mask
- Protocol Nr. (TCP/UDP)
- Destination Port Range
- Source Port Range
- IPSec Security Parameter Index
- Type of Service

Source address und Subnet Mask fällt flach, weil ja alles über den selben Asterisk läuft. Protocol ist auch jeweils UDP - auch kein geeignetes Attribut. Bleiben Port Range, IPSec SPI und TOS.

 

[Ottone]

Wenn Deine Telefon STUN beherrschen, dann köntest Du in Asterisk "canreinvite=yes" setzen, müsstest aber darauf achten dass nicht auch noch andere Dial() Parameter einen RE-INVITE verhindern. Der RTP traffic würde dann an Asterisk vorbeifliessen und Du könntest nach Source Address filtern.

Nebenbei: VoIP über WLAN ist für Belange der Sprachqualität nicht ideal.