[wireshark] bug of toch gelijk?

[Ierlandfan]

Opstelling:

Managed POE switch
Alle VOIP telefoons aangesloten op POE Switch
Poort 26 Voip uplink (rt+tx gemirrored naar 25)
Poort 25 monitor port.
Laptop.

Stelling:
Als ik een trace doe van twee voip telefoons die met elkaar bellen (zelfde LAN netwerk) verwacht ik RTP van
192.168.0.1 naar 192.168.0.2 te zien (direct onderling RTP verkeer)
Echter zie ik de pbx (192.168.0.3) er steeds tussenin staan. (Wireshark meting)
Echter zie ik in de bandbeedte monitor op de switch (poort 26) dat het RTP op het Lan blijft.

Ergo: twee metingen die in conflict zijn met elkaar.

Als proef op de som twee voip toestellen via een kleine (10 poorts) managed D-Link switch verbonden (buiten POE switch om) direct op de uplink. RTP verkeer blijft wel op LAN (Wireshark meting+bandbreedte monitor). Beide hetzelfde. Zelfde meting, zelfde opstelling, andere switch.

Ik denk, ik gooi de POE switch eruit voor de test. Ik installeer een D-link managed 24 poorts, (Non POE) voor de test op dezelfde manier als de kleine 10-poorts D-link switch.

Wireshark zegt weer dat er een pbx tussen zit, bandbreedte monitor zegt van niet.

Voor de zekerheid weer de twee voip toestellen via dezelfde kleine (10 poorts) managed D-link switch verbonden direct op de uplink. RTP verkeer blijft wel op LAN (Wireshark meting)+bandbreedte monitor. Beide hetzelfde.

POE switch is 24 poort 3com (default settings)
Non-POE switch is 24 poort D-Link (default settings)
Andere managed switch is 10 poorts D-link (default settings)

Wireshark is fout maar waarom?
En zo ja, is het een instelling op de switch of gewoon een switch die niet met Voip kan omgaan?

Ik probeer dit logisch te verklaren maar het lukt niet.

[Verwijderd]

de pbx (192.168.0.3) is toch ook LAN dan?

Ik snap je niet helemaal? Als ik het zo lees, gaat het verkeer van te telefoons via de centrale, en praten de telefoon's geen RTP direct onderling. Dat is toch prima mogelijk?

En aangezien je de poort van de VoIP uplink in monitoring zet, zou je indien de telefoons onderling RTP doen helemaal geen RTP verkeer zien...

[Verwijderd]

^^ Wat ITsMatthijs zegt.

Er klopt inderdaad ook iets niet aan je uitleg. De pbx waarvan je spreekt is inderdaad toch ook dezelfde LAN? Of bedoel je dat deze op een andere switch zit (achter de uplink)?
Misschien kan een kleine schets helpen ter verduidelijking.

Ik ben verder geen VoIP specialist, maar heb wel wat ervaring met troubleshooting hierop. Er zijn normaal gezien 2 manieren waarop je VoIP infrastructuur kan geconfigureerd zijn:
1) alle verkeer tussen de telefoons gaat via de callmanager (pbx): dus zowel RTP (signalling) als de voice stream zelf (= twee verschillende communicaties!)
2) het RTP verkeer gaat naar de callmanager, maar de voice stream gaat rechtstreeks tussen de telefoons.

Ik denk dat je dus eerst even moet uitzoeken hoe de VoIP infrastructuur juist werd geconfigureerd, voor je hier logische verklaringen voor kan gaan bedenken.

[tlpeter]

Het kan zijn dat de pbx nodig is.
Vaak zal het gesprek wel tussen de twee toestellen gaan maar is er altijd nog signalering naar de pbx.

[Equator]

tlpeter schreef op vrijdag 23 april 2010 @ 14:00:
Het kan zijn dat de pbx nodig is.
Vaak zal het gesprek wel tussen de twee toestellen gaan maar is er altijd nog signalering naar de pbx.

Lijkt mij ook.. Het toestel geeft immers aan de PBX aan dat hij nog in gesprek is..

[tlpeter]

Ik werk met een bepaald type pbx en met die pbx moet die er gewoon zijn.
Trek je de stekker er uit dan is het over en sluiten met bellen.
Er zijn merken waarbij het gesprek door gaat maar niet veel.

[ Voor 18% gewijzigd door tlpeter op 23-04-2010 14:54 ]

[Ierlandfan]

Laat ik verduidelijken en aanpassen.
PBX is niet lokaal. Ander subnet. Zeg 10.1.1.10. Maakt het makkelijker voor de uitleg.

Signalling mag ik verwachten dus 10.1.1.10 mag ertussen zitten voor SIP pakketjes.
RTP verkeer MOET onderling gaan aangezien dit zo is ingesteld.
En dit wordt ook door de 10 poorts D-link bevestigd. Zowel door Wireshark alsmede de Bandbreedte monitor.

Daar zie ik dus:
(10 poorts D-link managed)

Protocol RTP Source 192.168.0.1 to protocol RTP destination 192.168.0.2
Protocol RTP Source 192.168.0.2 to protocol RTP destination 192.168.0.1
Bandbreedte op de Uplink:> 0 RTP verkeer.

Het vreemde is dus dat dit met de andere managed switches niet is te zien.

Daar zie ik dus:
(3Com, D-Link 24 poorts managed)

Protocol RTP Source 192.168.0.1 to protocol RTP destination 10.1.1.10
Protocol RTP Source 10.1.1.10 to protocol RTP destination 192.168.0.2
Protocol RTP Source 192.168.0.2 to protocol RTP destination 10.1.1.10
Protocol RTP Source 10.1.1.10 to protocol RTP destination 192.168.0.1
Bandbreedte op de Uplink:> 0 RTP verkeer.

Zelfde meting op dezelfde manier als eerste meting. Enige verschil is andere switch.

Nu zit ik eens te denken...de D-link 10 poorts heeft geen uplink poort en de andere twee wel.
(poort 25 en 26) Maar dan nog mag een switch niet deze trace laten zien lijkt mij.
Iemand een idee?

[lordgandalf]

is het niet zo dat die 3com iets tegen houd en dat ie dan via het pad wat werkt gaat lopen namelijk de voip server ??
dat zou wat verklaren. dat ie ziet van he ik kan niet meteen naar de andere telefoon dus dan doe ik het maar via de server want die kunnen we beide benaderen

[Ierlandfan]

Dat strookt weer niet met de bandbreedte monitor (0 KB RTP) op de uplink poort. (de poort naar de pbx)
Ik zou je anders gelijk geven.

[ChaserBoZ_]

Verwijderd schreef op vrijdag 23 april 2010 @ 13:55:
^^ Wat ITsMatthijs zegt.

Er klopt inderdaad ook iets niet aan je uitleg. De pbx waarvan je spreekt is inderdaad toch ook dezelfde LAN? Of bedoel je dat deze op een andere switch zit (achter de uplink)?
Misschien kan een kleine schets helpen ter verduidelijking.

Ik ben verder geen VoIP specialist, maar heb wel wat ervaring met troubleshooting hierop. Er zijn normaal gezien 2 manieren waarop je VoIP infrastructuur kan geconfigureerd zijn:
1) alle verkeer tussen de telefoons gaat via de callmanager (pbx): dus zowel RTP (signalling) als de voice stream zelf (= twee verschillende communicaties!)
2) het RTP verkeer gaat naar de callmanager, maar de voice stream gaat rechtstreeks tussen de telefoons.

Ik denk dat je dus eerst even moet uitzoeken hoe de VoIP infrastructuur juist werd geconfigureerd, voor je hier logische verklaringen voor kan gaan bedenken.

RTP is juist NIET de signalling, maar de 'payload', het spraakverkeer.

Signalling kan o.a. via SIP.

[Azhrarn]

ChaserBoZ_ heeft gelijk hoor. RTP is inderdaad de payload. Je signaling hangt af van wat je gebruikt.
Dat kan SCCP, SIP of H323 zijn. In jouw geval dus SIP.
Normaal gezien zou je uplink poort naar de PBX geen RTP mogen bevatten tenzij je specialere zaken doet als Music On Hold, of Codec Translations of ...
Ik vraag mij eigenlijk ook af wat jij een voip uplink noemt? Gaat die daarna naar een L3 switch waar hierop je pbx zit.

Normaal zou je gewoon RTP (de voicestream dus) tussen de phones onderling moeten hebben. De signaling, adres opzoeken in database, en dat soort zaken passeert normaal via een SIP-server(je pbx dus).

[Ierlandfan]

Ok, we hebben nu duidelijk dat RTP (Payload, audio) onderling zou moeten lopen.
we hebben nu duidelijk dat SIP via de pbx zou kunnen lopen.

Wat ik dus niet mag zien in de Wireshark trace van de switch is RTP verkeer naar buiten toe.
Dat doe ik dus wel op 2 switches terwijl het niet zo is (bandbreedtemonitor)
1 switch geeft het wel goed aan.

Wie heeft er een idee.

[ Voor 22% gewijzigd door Ierlandfan op 26-04-2010 13:43 ]

[Van Heupscheute]

Benader het eens van de andere kant, Wat zou er moeten gebeuren volgens de signaling?

Kijk naar de invite, en zoek het sdp gedeelte op.
Daarin staat de source-ip & port waarop de bellende UA zijn media op verwacht.

Kijk dan naar de SDP info van de 200OK message.
Daar staat dezelfde info van de andere kant.
Als dit het IP is van de proxy, zal de media daarheen gestuurd worden.
Als dit het IP is van de andere UA zal de RTP daarheen gestuurd worden.

En... ook niet onbelangrijk..
Haal niet laag2 en laag3 door elkaar.