Betrifft: 19.10.R
Server Management Interface -> Interfaces -> Edit:
Voip: Plain (UDP/RTP)
RTP Port From: 10000
RTP Port To: 28998
Mit diesen Einstellungen wollte ich einen Colt-SIP-Trunk an Pascom anbinden (RTP - Einstellungen laut Colt Dokumentation). Das SIP-Signaling kam zustande und der Anruf konnte aufgebaut werden.
Jedoch keine Ton-Übertragung in irgendeine Richtung.
Per tcpdump festgehalten:
IP CO.LT.REDA.CTED.9934 > PAS.COM.REDA.CTED.10634: UDP, length 172
das sieht soweit korrekt aus (Colt hat eig. eine Port-Untergrenze von 5000 - diese konnte ich jedoch wegen RTP Port-Range speichern nicht möglich nicht so niedrig setzen)
Dies wurde jedoch von Pascom mit einem:
IP PAS.COM.REDA.CTED > CO.LT.REDA.CTED: ICMP PAS.COM.REDA.CTED udp port 10634
unreachable, length 208
beantwortet. Laut RTP-Einstellungen sollte Port 10634 allerdings zur Verfügung stehen für RTP Kommunikation?
Und in Gegenrichtung:
IP PAS.COM.REDA.CTED.1024 > CO.LT.REDA.CTED.9934: UDP, length 172
Meiner Meinung nach sollte nicht von Port 1024 aus gesendet werden.
Ich habe das ganze bereits in Colt Trunk Umstellung angesprochen, bin mittlerweile jedoch zu der Überzeugung gelangt, dass dieses Verhalten ein Bug ist und deshalb jetzt ein eigenes Thema eröffnet.
ich bräuche bitte eine Rückmeldung bezüglich dieses Bugs. In Arbeit / wird gefixt / wird erst geprüft / wird nicht gefixt / kein Bug - irgendwas. Ich muss die Anbindung langfristig planen/sicherstellen.
Wir haben weder Partner noch Premium Subscription. Es geht im ersten Schritt nicht darum, dass das “schnell” gefixt wird (bei 3 Wochen Stillschweigen eh auch hinfällig), sondern wir eine Rückmeldung zu dem gemeldeten Bug bekommen (ob überhaupt was unternommen wird). Wir stehen damit gerade einfach an.
Oder ist eine Basic-Subscription nicht ausreichend für Rückmeldungen zu Bugmeldungen (und möglichen Fixes)?
Also ich sage mal so.
Die meisten die hier Support geben sind Pascom Partner die für den Support hier nix bekommen.
Basic Support bedeute das du nur hier im Forum Hilfe bekommst und keine garantierte Reaktionszeit hast.
Wenn du jetzt dazu noch Problem mit irgendeinem SIP-Trunk hast der nicht offiziell von Pascom Supportet wird (Colt ist eine Community Vorlage), dann würde ich dir schon Raten dir einen Partner zu suchen oder halt Support über Pascom zu haben.
Es ist wie bei allem wenn du selber am Auto runschraubst kannst nachher auch nicht zur Werkstatt gehen und dich beschweren.
Zu deinem Problem die Port Range die du da verstellst hat nix mit dem SIP-Trunk zu tuen die ist für den SessionBorder Controller da also Inbound für Telefone und Pascom Clients, meine ich.
Dementsprechens ist da auch kein Bug.
Wenn der Ton nicht geht ist das mit ziemlicher Sicherheit ein Firewall Problem.
Was du versuchen kannst ist mal im Amt von default/NAT auf ein Interface umzuschalten ob das was bringt.
Hallo @MarkusSachs
Danke fürs Antworten.
Deine Auto-rumschrauben Analogie ist zwar in sich korrekt, ich würde allerdings behaupten, dass ich eher den Knopf für die Warnblinkanlage betätige ohne, dass das Licht angeht. Aber Naja.
Unsere Pascom-Instanz hängt direkt am Internet. Kein NAT, keine Firewall. Wenn eine Firewall das Problem ist, dann die von Pascom selbst.
Da ich mit der Voip-Einstellung (RTP / SRTP / Disable) sehr wohl Einfluss auf die Kommunikation meines Colt-Trunks nehme, hätte ich angenommen, dass ich die entsprechende Port-Range damit ebenfalls festlegen kann.
Jedes Mal wenn ich das Amt aufs Interface umgestellt hab, ging gar nichts mehr. Den oben beschriebenen Fehler habe ich zwar gefunden, weil ich versucht habe einen Colt Trunk anzubinden, ich wäre aber immernoch der Meinung, dass das gefundene Verhalten (auch ohne Colt Hintergrund) ein Bug ist. Nehme auch gerne eine schlüssige Erklärung wenn dem nicht so ist.
Dein Hinweis ist willkommen und ich finds toll, dass du dich damit überhaupt auseinander setzt, aber leider schon erfolglos versucht.
Okee wie hängst du die PascomInstanz direkt ans Internet die hat eine Öffentlich IP?
Kannst du mal den Aufbau als Schaubild anhängen?
Was ich dir damit sagen wollten ist die Basis Lizenz ist gedacht für Partner oder Kunden die sich mit TK und IP, und Asterisk auskennen.
Wenn man aber in dem Bereich nicht viel KnowHow hat dann ist das eher schwierig und dann würde ich raten suche dir eine Partner der das mal vor Ort anschauen kann, und dich beraten kann.
Warum nimmst du keine Pascom aus der Cloud da hast du die Probleme schonmal nicht?
entschuldige das ich nicht vorher auf deinen Beitrag aufmerksam gewordne bin. Die RTP Range im Interface greift nur für Verbindungen die den Sessionbordercontroller (Kamailio) verwenden. Wenn du im Amt unter Schnittstelle “default/NAT” verwendest, dann greift hier der NAT Mechanismus des Betriebssystems. Die Portrange hier wird nicht durch die Einstellungen im Interfacemanagement beeinflusst. Ob Colt mit Outbound-Proxy (bei Schnittstelle im Amt die Schnittstelle anstelle von default/NAT auswählen) funktioniert kann ich dir aber leider nicht beantworten, das müsste man testen.
Hi @Steve,
wir haben nun einen eigenen Test-Server aufgesetzt samt eigenem Colt Test Trunk etc.
Situation genau gleich wie bei unserem Produktiv-System: kein NAT = eigene öffentliche IP, letzte Server Version = 19.13, Colt Trunk authentifiziert über IP = keine Registrierung.
Ich hab nun mit einem generischen SIP Trunk systematisch durchgetestet und bin auf folgendes gestoßen:
===== Interface=ifens3
Der allererste Call funktioniert (manchmal), solange kein OPTIONS Paket gesendet wird - das erhält keine Antwort da es nicht weitergesandt wird an 212.23.246.72 (=Colt Server IP) - es endet bei 10.0.3.1 (quelle: sngrep)
“pjsip show endpoints” pre-call:
Endpoint: mdc_trunk_conf-2 Unavailable 0 of inf
Aor: mdc_trunk_conf-2 0
Contact: mdc_trunk_conf-2/sip:212.23.246.72 eab50fda2a NonQual nan
Transport: tcp tcp 3 96 0.0.0.0:5060
Identify: mdc_trunk_conf-2-identify/mdc_trunk_conf-2
Match: 212.23.246.72/32
“pjsip show endpoints” post-call:
Endpoint: mdc_trunk_conf-2 Unavailable 0 of inf
Aor: mdc_trunk_conf-2 0
Contact: mdc_trunk_conf-2/sip:212.23.246.72 eab50fda2a Unavail nan
Transport: tcp tcp 3 96 0.0.0.0:5060
Identify: mdc_trunk_conf-2-identify/mdc_trunk_conf-2
Match: 212.23.246.72/32
Ein aor/qualify_frequency= beschleunigt nur das senden des OPTIONS Paketes und damit die unverfügbarkeit des Trunks
===== Interface=default/NAT
Hier kommt der Anruf selbst zustande, aber kein RTP-Stream = Kein Audio in irgendeine Richtung
“pjsip show endpoints”:
Endpoint: mdc_trunk_conf-2 Not in use 0 of inf
Aor: mdc_trunk_conf-2 0
Contact: mdc_trunk_conf-2/sip:212.23.246.72 eab50fda2a Avail 18.241
Transport: udp udp 3 96 0.0.0.0:5060
Identify: mdc_trunk_conf-2-identify/mdc_trunk_conf-2
Match: 212.23.246.72/32
Die Options Pakete werden offensichtlich korrekt weitergereicht und bekommen auch eine Antwort (quelle: sngrep). Nur der RTP-Stream kommt nicht zustande (wie in meinem ersten Post in diesem Thread beschrieben).
SIP-ALG = On/Off macht keinen Unterschied in beiden Szenarien. Gibt es noch irgendwelche Ideen dazu?
Beste Grüße
Ben
hast du dein Problem gelöst? Wir sehen hier - mit Pascom 19 hinter NAT an Colt SIP - wohl gleichen Effekt: bei eingehendem Anruf sendet die Pascom RTP-Pakete vom falschen UDP-Port 1024.
09:47:17.605211 IP 212.36.166.233.19928 > 10.6.0.5.10246: UDP, length 172
09:47:17.618746 IP 10.6.0.5.1024 > 212.36.166.233.19928: UDP, length 172
Selten (weniger als 10% der Versuche) geht’s richtig - dann schickt die Pascom als erstes ein RTP-Paket zu Colt, erst danach kommt ein eingehendes RTP-Paket von Colt:
09:27:03.986206 IP 212.36.166.235.5060 > 10.6.0.5.5060: SIP: INVITE sip:+49xxxxxxx@ext.ern.add.res:5060 SIP/2.0
09:27:03.987480 IP 10.6.0.5.5060 > 212.36.166.235.5060: SIP: SIP/2.0 100 Trying
09:27:03.998544 IP 10.6.0.5.5060 > 212.36.166.235.5060: SIP: SIP/2.0 180 Ringing
09:27:04.000634 IP 10.6.0.5.5060 > 212.36.166.235.5060: SIP: SIP/2.0 183 Session Progress
09:27:05.035011 IP 10.6.0.5.5060 > 212.36.166.235.5060: SIP: SIP/2.0 183 Session Progress
09:27:05.054673 IP 10.6.0.5.11208 > 212.36.166.230.6758: UDP, length 172
09:27:05.060225 IP 212.36.166.230.6758 > 10.6.0.5.11208: UDP, length 172
09:27:05.074703 IP 10.6.0.5.11208 > 212.36.166.230.6758: UDP, length 172
09:27:05.080237 IP 212.36.166.230.6758 > 10.6.0.5.11208: UDP, length 172
09:27:05.094701 IP 10.6.0.5.11208 > 212.36.166.230.6758: UDP, length 172
Ich habe den Verdacht, dass das (iptables-basierte?) NAT innerhalb der Pascom LXC-Container falsch reagiert - oder ist hier kamailio als SBC noch dazwischen?
tut mir Leid - wir konnten das nicht lösen und haben zu peoplefone gewechselt.
Laut meinen Infos sollte da ein Kamailio als SBC dazwischen sein. Iptables werden eingesetzt, so viel ich gesehen hab, dürften aber daran nicht Schuld sein.