OCS desktop sharing

[devuysts]

Wij hebben een OCS infrastructuur (OCS 2007 R2) die zeer goed dienst doet, afgezien van 1 kleine issue:
Van het moment dat 1 van de 2 partijen een desktop sharing doet, houdt die +- 5 seconden stand.
Dan verbreekt die zonder specifieke boodschap in de client.

Ik heb reeds geprobeerd dit te loggen met de S4 & SIPStack properties in de logging tool. Ikzie allerlei sends en recieves met de nodige ack, en op een bepaalde moment staat er in de log het volgende:

06/04/2010|11:50:23.936 450:1D98 INFO :: Sending Packet - Publiekipadres (From Local Address: 192.168.22.70:49324) 1057 bytes:
06/04/2010|11:50:23.936 450:1D98 INFO :: BYE sip:[e-mail];opaque=user:epid:vlNV-ppYCFe7s8dpjd0t3QAA;gruu SIP/2.0
Via: SIP/2.0/TLS 192.168.22.70:49324
Max-Forwards: 70
From: <sip:[e-mail]>;tag=4ff569d23a;epid=a5241b6309
To: <sip:[e-mail]>;epid=a0b77fca23;tag=bfabbc5ebb
Call-ID: 421d329e2f424bc39fc4421dd080d7d5
CSeq: 3 BYE
Route: <sip:access.domein.com:443;transport=tls;opaque=state:Ci.R9a600;lr;ms-route-sig=erSpokBaciuHiAKgaRl1TrbGrbEdDC-pSawVoDOwAA>
Route: <sip:frontserver.domein.com:5061;transport=tls;opaque=state:F:T:Eu;lr;received=192.168.21.114;ms-received-cid=96701>
User-Agent: UCCAPI/3.5.6907.196 OC/3.5.6907.196 (Microsoft Office Communicator 2007 R2)
Supported: ms-dialog-route-set-update
Ms-client-diagnostics: 52021; reason="Call terminated on media timeout"
Proxy-Authorization: NTLM qop="auth", realm="SIP Communications Service", opaque="7F6F9551", targetname="frontserver.domein.com", crand="5ed328c6", cnum="19", response="010000009048e5063fec94eb8cde0b6f"
Content-Length: 0


06/04/2010|11:50:23.936 450:1D98 INFO :: End of Sending Packet - Publiekipadres (From Local Address: 192.168.22.70:49324) 1057 bytes


De foutmelding - Ms-client-diagnostics: 52021; reason="Call terminated on media timeout" - zegt me niets zo veel en als ik de logging opzet in de client, krijg ik dezelfde logs.
Het eigenaardige is dat de desktopshare-verbinding wel degelijk wordt opgezet. Na 5 sec vebreekt die dus.
Het probleem stelt zich niet als beide partijen buiten het netwerk zitten.
Maar, zo heb ik de documentatie gelezen, dan communiceren ze onderling zonder de edge server te contacteren.
Alle andere zaken zoals audio, video, IM werken perfect.

Iemand een idee?

[Verwijderd]

Heb je dit alleen met de 196 client? had .83 daar ook last van of deed die het wel goed?

[devuysts]

beiden vertoonden de symptomen. Ik heb de test tevens eens omgedraaid (source/destination).
Ik denk niet dat ik een firewall probleem heb, want de verbinding wordt wel degelijk gelegd. na 5 sec is de fun over

[Verwijderd]

Je schrijft dat het probleem er niet is als beide partijen buiten het netwerk zitten. Komt dit dus alleen voor bij firewall traversal, of heb je het ook intern?

Heb je je interne adressen expres als 192.168 geschreven, of heb je echt unroutable adressen intern? Het lijkt me namelijk niet onmogelijk dat dat gerelateerd is aan het droppen van de verbinding - omdat de buitenkant probeert 192.168... te bereiken van buiten.

[devuysts]

beiden intern heb ik het nog niet geprobeerd. de interne adressen zijn echt in ocs meegeven en staan ook zo in de parameters in de mcc.
Ik doe de test met 2 interne clients

[Verwijderd]

Aan je log entry te zien stuurt je interne client naar de externe een BYE - omdat hij van de externe niets krijgt. Ik zou het zoeken in je firewall - poortjes open en correct geNAT. Volgende stap is op je externe client kijken of die probeert met 192.168.xx.xx te verbinden, of met het publieke IP van je FE server.

[devuysts]

hoe verklaar je dan dat de connectie toch wordt gelegd eerst?

[devuysts]

Intern werkt dit dus wel...very strange