persistence with rtsp

hello,

 

 

thank you for your reply. but we are trying to force all components to use pure rtsp - we don't want to handle rtsp-tunneling via the loadbalancer.

 

 

so we configured the real player not to use http-tunneling and traced on the client node and on the helix-server node with ethereal.

 

 

when we start a streaming download of a *.wmv-file, then we can access the stream and we see rtsp tunneled via http sent to the rtsp-port.

 

 

but when we start a streaming download of a *.rm-file, then the real player tries to use pure rtsp. in this case the rtsp-options request is received on the helix-server-node, but we can NOT see the following rtsp-describe request sent by the client on the helix-server node, although the client receives an answer to this request (and the stream can not be downloaded).

 

so we think that the answer must be produced by the loadbalancer itself (see the attached ethereal-traces).

 

 

is this observed behaviour part of the loadbalancer configuration (if that's the case: how can we disable this?)

 

 

can the real player be forced to always use pure rtsp (not tunneled in any way)? and is there a difference in the protocol choosen by the real player dependent on the streamed media type (rm, wmv, ...)?

 

 

thanks,

 

albert

 

 

=======================================================================

 

this is an ethereal trace taken on the client-side, where

 

we tried to download a media stream (*.rm) via pure rtsp, but failed

 

because the rtsp-describe never reached the helix-server (and we

 

think the loadbalancer answered instead of the helix-server).

 

=======================================================================

 

 

OPTIONS rtsp://158.226.219.222:554 RTSP/1.0

 

CSeq: 1

 

User-Agent: RealMedia Player (HelixDNAClient)/10.0.0.0 (win32)

 

ClientChallenge: 1f86e2c643592f625a33fda9efa4fec3

 

ClientID: WinNT_5.1_6.0.12.1056_RealPlayer_R30DED_de-at_686

 

CompanyID: /0xfnpVYGBwuXMQwGzpM+g==

 

GUID: 00000000-0000-0000-0000-000000000000

 

PlayerStarttime: [04/02/2005:14:38:11 01:00]

 

Pragma: initiate-session

 

RegionData: 1140

 

 

RTSP/1.0 200 OK

 

CSeq: 1

 

Date: Fri, 04 Feb 2005 13:45:51 GMT

 

Session: 23478-1

 

Server: Helix Server Version 9.0.5.1159 (sunos-5.8-sparc-server) (RealServer compatible)

 

Public: OPTIONS, DESCRIBE, ANNOUNCE, PLAY, SETUP, GET_PARAMETER, SET_PARAMETER, TEARDOWN

 

RealChallenge1: 743343e19df49991f747138ef6b10f4e

 

StatsMask: 3

 

 

DESCRIBE rtsp://158.226.219.222:554/real9video.rm?CHSETID=41&xyz=martin RTSP/1.0

 

CSeq: 2

 

User-Agent: RealMedia Player (HelixDNAClient)/10.0.0.0 (win32)

 

Accept: application/sdp

 

Session: 23478-1

 

Bandwidth: 1544000

 

ClientID: WinNT_5.1_6.0.12.1056_RealPlayer_R30DED_de-at_686

 

Cookie: cbid=rfqgjhcidjfkhldmeoloqphqerjrktlufkrgkieliggkilplmsnrqugqlorndtdudfjjdhci

 

GUID: 00000000-0000-0000-0000-000000000000

 

Language: de-at

 

RegionData: 1140

 

Require: com.real.retain-entity-for-setup

 

SupportsMaximumASMBandwidth: 1

 

 

=======================================================================

 

this is an ethereal trace taken on the client-side, where

 

we tried to download a media stream (*.wmv) via pure rtsp, but we

 

saw a rtsp request tunneled via http and sent to the rtsp port:

 

(and we could access the data stream)

 

=======================================================================

 

 

GET /wmvideo.wmv?CHSETID=36&xyz=mp HTTP/1.1

 

Accept: */*

 

User-Agent: NSPlayer/9.0.0.2980

 

Host: 158.226.219.222

 

Cookie: cbid=rfqgjhcidjfkhldmeoloqphqerjrktlufkrgkieliggkilplmsnrqugqlorndtdudfjjdhci

 

X-Accept-Authentication: Negotiate, NTLM, Digest, Basic

 

Pragma: version11-enabled=1

 

Pragma: no-cache,rate=1.000,stream-time=0,stream-offset=0:0,packet-num=4294967295,max-duration=0

 

Pragma: packet-pair-experiment=1

 

Pragma: pipeline-experiment=1

 

Supported: com.microsoft.wm.srvppair, com.microsoft.wm.sswitch, com.microsoft.wm.predstrm

 

Pragma: xClientGUID={3300AD50-2C39-46c0-AE0A-CC44945DC0BE}

 

Accept-Language: de-DE, *;q=0.1

 

 

HTTP/1.0 200 OK

 

Content-Type: application/octet-stream

 

Server: Cougar 4.1.0.3917

 

Cache-Control: no-cache

 

Pragma: no-cache

 

Pragma: client-id="5483"

 

Pragma: features="seekable,stridable"

 

 

$H.....<----- snip ---->