Einseitig fehlender Sprachkanal bei internem ARF-Übergang

[Rougu]

Hallo,

Beobachtet mit LCOS 10.00.0255 an 1783VA.

Ich habe VLANs für Intranet (Daten) und VoIP definiert. Der Router ist in beiden "zuhause": 10.10.32.1/25 (Daten-Intranet), 10.10.32.129/27 (VoIP).

Der Voice Call Manager des Routers bindet sich immer automatisch an die IP des Daten-Intranets (10.10.32.1, niedrigste IP?), kommuniziert aber auch über die anderen logischen IP-Interfaces.

Telefone, die den LC-Router als Registrar verwenden und ihn über die IP-Adresse des VoIP-VLANs (10.10.32.129) ansprechen, haben ein Problem:

Bei Anrufen wird der kommende Audio-Kanal (Early Media und Hören des entfernten Gesprächspartners) nicht durchgeschaltet.

Sobald ich den LC-Router (Registrar) mit Telefon über das Daten-Intranet-VLAN oder VPN an seiner IP anspreche, die er intern als Interface für VCM gewählt hat, funktioniert es.

IMHO halte ich das für einen Bug.

Gruß,
rougu

BTW: Wie kann ich festlegen, an welches Interface sich der Voice-Call-Manager intern bindet?

[Jirka]

Hallo Rougu,

Wie kann ich festlegen, an welches Interface sich der Voice-Call-Manager intern bindet?

das kann man gar nicht festlegen.

Der Voice Call Manager des Routers bindet sich immer automatisch an die IP des Daten-Intranets

Was meinst Du damit genau? Oder woraus schließt Du das?

Bei Anrufen wird der kommende Audio-Kanal nicht durchgeschaltet.

Sind Deine IP-Netze durch ein Schnittstellen-Tag getrennt? Wie sieht das genau aus?

Viele Grüße,
Jirka

[Rougu]

Hallo Jirka,

Die Netze für Daten und VoIP teilen sich das Routing Tag 1

Code: Alles auswählen

> cd /Setup/TCP-IP/Network-list
> ls

Network-name      IP-Address       IP-Netmask       VLAN-ID  Interface           Src-check      Type      Rtg-tag  Comment                                                         
==================-----------------------------------------------------------------------------------------------------------------------------------------------------------------
INTRANET          10.10.32.1       255.255.255.128  101      LAN-1               loose          Intranet  1        he02 intranet                                                   
NETMGT            10.10.32.193     255.255.255.224  102      LAN-1               loose          Intranet  1        he02 mgt                                                        
VOIP              10.10.32.129     255.255.255.224  104      LAN-1               loose          Intranet  1        he02 voip                                                       
DMZ               172.23.113.254   255.255.255.0    103      LAN-1               strict         DMZ       3        demilitarized zone                                              

Bei einem Telefonat eines SIP-Users @10.10.32.130 über eine SIP-Leitung nach extern (Telekom) werden Audio-Streams definiert, wobei der Endpoint des Routers die Adresse aus dem INTRANET verwendet, obwohl der SIP-Client im VOIP-Netz sitzt.

Code: Alles auswählen

[MEDIA] 2017/07/15 16:47:02,196 [RT-ENDPOINT] : Constructing cRtIncomingStream 0470e010: LocalRtpSocket=10.10.32.1:8014
[MEDIA] 2017/07/15 16:47:02,196 [RT-ENDPOINT] : Construct cRtOutgoingStream 077ffc50: dtmf=0x02, remote=10.10.32.130:5060

Diese Streams sind wie beschrieben nicht beide funktionsfähig. Der Stream für Early-Media und das Hören des externen Teilnehmers ist stumm.

Gruß,

rougu

[Dr.Einstein]

Hi,

tjaja, der Call Manager ist überhaupt nicht ARF Kompatibel. Man kann z.B. nicht einmal sagen, dass sich SIP User nur aus Netz 1 anmelden dürfen.

Und der Call Manager nimmt die IP des Netzes, dass Alphabetisch ganz oben steht (l /Setup/TCP-IP/Network-list). Was der Callmanager ebenfalls nicht mag sind IP Netze mit /32 als Maske.

Gruß Dr.Einstein

[Jirka]

Hallo Rougu,

ok. Liegt das jetzt an der 10-er Firmware oder an Deinen - ich sage mal ungewöhnlichen - IP-Adresskreisen? Weil mit der 9.24 habe ich an mehreren Stellen VoIP-Telefone laufen, die nicht im ersten ARF-Netz liegen...
Hattest Du die 9.24 vorher im Einsatz? Oder gleich mit der 10 gestartet und da waren dann schon die Probleme?
Kannst Du mal Dein VoIP-Netz testhalber auf die 10.10.33.1/24 ändern? Tritt das Problem dann auch auf?

Hallo Dr. Einstein,

Und der Call Manager nimmt die IP des Netzes, dass Alphabetisch ganz oben steht [...].

hast Du Dir das mal genau angeschaut? Wäre es nicht korrekter, hier von einer numerischen statt alphabetischen Sortierung zu reden?

Viele Grüße,
Jirka

[Dr.Einstein]

Hi Jirka,

hast Du Dir das mal genau angeschaut? Wäre es nicht korrekter, hier von einer numerischen statt alphabetischen Sortierung zu reden?

alphanummerisch Intranet, danach alphanummerisch DMZ.

[Jirka]

Hi Dr. Einstein,

hmm. Also ich bin da anderer Meinung. Mir ist so wie erst nach Schnittstellen-Tag und anschließend nach IP-Adresse...

Viele Grüße,
Jirka

[Dr.Einstein]

Hi Jirka,

mein Fehler, du hast natürlich komplett recht, erst Tag, dann IP.

Gruß Dr.Einstein

[Koppelfeld]

unter Verwendung von ARF + Routing Tags man extremst aufpassen muss, damit der Call Manager überhaupt noch funzt, von Sicherheit zwischen den Netzen ganz zu schweigen.

Oh shit, Frau Schmidt.
Genau das habe ich gestern in meinem juvenilen Leuchtsinn als Feature angepriesen:
- Zwei Internet-Provider, nur einer davon Telekom
- Alter Telekom-Privatkundenanschluß (per "SIP-Leitungs"-Routing-Tag aufs Telekom-Interface gelenkt
- Zweiter Provider (Asibell)
- VPN mit ARF zum Franzmann 'rüber nach Lyon

"Kein Problem", höre ich mich noch sagen.

[Jirka]

Hi Koppelfeld,

ist auch kein Problem. Bekommt man alles hin. Bei der VPN-Verbindung muss man aufpassen, dass der SIP-Client mit einer Route mit Routing-Tag 0 zu erreichen ist. Ist er das nicht, legt man halt eine Route an (mit möglichst 32-er Netzmaske - aus Sicherheitsgründen).

Viele Grüße,
Jirka

[Koppelfeld]

Hmmm.
Feature-Request:
Der VCM _selbst_ müßte ein Routing-Tag erhalten können, nicht nur die "SIP-Leitungen".

[cpuprofi]

Hallo,

Hmmm.
Feature-Request:
Der VCM _selbst_ müßte ein Routing-Tag erhalten können, nicht nur die "SIP-Leitungen".

dafür wäre ich auch.

Grüße
Cpuprofi

[Rougu]

Hallo,

interessant, welches Echo mein Post hervorruft. Scheint ja nicht ganz unbedeutend zu sein.

@Jirka:
die "ungewöhnlichen IP-Netze" sind völlig RFC-konform. Der Standort hat die Summen-Route 10.10.32.0/24 (sehr schön auch für die VPN-SAs!). Innerhalb des Standorts wird addressraum-sparsam aufteilt in Häppchen. (in speziellen Fällen, nicht hier: sogar bis hinunter auf /30 für Transfernetze zu externen xDSL-Modems.) Das ist m. E. keine Fehlerquelle.


Das Problem ist nicht neu bei 10.00, nun aber verschlimmert. Ich kenne das Problem seit mindestens 8.84 (am 1823):

a) Der VCM "bindet sich" gemäß minimalem Routing-Tag und minimaler IPv4-Adresse an das Intranet, oben also 10.10.32.1/25 (rt 1).
b) VoIP-Clients sitzen im VOIP-Netz, sagen wir 10.10.32.128/27 (auch rt 1).
c) Solange "_sip._udp.voip-domain" auf den Registrar 10.10.32.1 zeigte oder direkt der Registrar 10.10.32.1 eingetragen wurde, funktionierte die wunderbare Voip-Welt bis LCOS 9.24.

Seit LCOS 10.00 ist aber Schluss mit lustig, weil von zwei Sprachkanälen (rx und tx) nicht mehr beide korrekt durchgeschaltet werden, sondern nur noch einer, wie im Ursprungs-Post beschrieben.

Als Workaround bleibt im Moment nur die Auflösung der dedizierten VoIP-VLANs und der Transfer der VoIP-Clients ins Intranet 10.10.32.0/25, wo auch der VCM zuhause ist.

Insofern +1 für den Featurewunsch "rt für vcm"!


PS:
Ich habe das Problem hier angesprochen, weil ich schon lange unzufrieden war und jetzt schnell noch unzufriedener werde mit der Diskrepanz zwischen dem beworbenen Alleinstellungsmerkmal ARF und der nicht vorhandenen Kompatibilität mit einem weiteren, inzwischen wieder aktiv beworbenen und entwickelten Funktionsmerkmal "Voice-Call-Manager".

[Jirka]

Hallo Rougu,

die "ungewöhnlichen IP-Netze" sind völlig RFC-konform.

das habe ich doch nie angezweifelt. Trotzdem musst Du doch zugeben, dass eine derartige Konstruktion nicht häufig anzutreffen ist. Nun kann es doch sein, dass so ein Programmierer bei LANCOM auch mal Fehler macht und gewisse Netzmasken nicht richtig interpretiert werden. Verstehst Du, was ich meine? Man muss versuchen runterzubrechen, wo der Fehler oder die Ursache liegt. Deswegen hatte ich Dich gebeten, mal eben das VoIP-Netz abzuändern. Ich meine das sind 15 Min. incl. Test, wenn ich das hier auf dem Schreibtisch nachbaue, brauche ich schon mal mind. 10 Min. mehr und außerdem habe ich dafür i. A. keine Zeit, hier warten mehrere Kunden, dass ich mich ihrer Probleme annehme...

Hatten wir uns nicht mal persönlich kennengelernt - oder verwechsel ich Dich jetzt? Irgendwie hatte ich da den Eindruck, Du tickst wie ich.

Der Standort hat die Summen-Route 10.10.32.0/24 (sehr schön auch für die VPN-SAs!).

Ohne Frage ist das durchdacht...

Innerhalb des Standorts wird addressraum-sparsam aufteilt in Häppchen.

Nun gut, an privaten IP-Adressbereichen mangelt es jetzt zwar noch nicht, aber ok.

Das ist m. E. keine Fehlerquelle.

Das wissen wir genau, wenn man den Fehler so auch mit "normalen" Netzen hat. Ich meine vermutlich hast Du Recht und natürlich hast Du jetzt auch nichts falsch gemacht, aber trotzdem hätte ich das gerne abgecheckt gehabt.

Ich kenne das Problem seit mindestens 8.84

Ohne Frage... Ich habe auch schon mehrfach Bugs aus genau diesem Bereich gemeldet, wo z. B. über VPN die Sprachdaten nur einseitig übertragen wurden. Die sind aber inzwischen gefixt.

Seit LCOS 10.00 ist aber Schluss mit lustig

Das ist doch jetzt mal eine Aussage.
Das bestätigt auch meine Beobachtung, dass ich derartige Konstellationen (allerdings nicht mit so "ungewöhnlichen" Netzen) mit der 9.24 erfolgreich laufen habe.

Viele Grüße,
Jirka