[rtmpdump] What to look for to solve a "handshake failed"?

rtmpdump at pepak.net rtmpdump at pepak.net
Sun Dec 18 08:01:47 CET 2011


I have been comparing the handshakes of RTMPDUMP and native player
side-by-side and noticed several things:

1. Some of RTMPDUMP's HTTP headers are ending with \n and not \r\n as
per HTTP specification. See HTTP_Post(), headers "User-Agent" and

2. For some reason, RTMPDUMP seems to be a bit impatient. The native
player's sequence is:

- POST /open/1
- receive an answer "638525327" - I assume that's a "RTMP connection handle"
- POST /send/638525327/0
- receive an answer ...

On the other hand, RTMPDUMP's sequence is:

- POST /open/1
- POST /send//0
- receive an answer to "open"
- after two seconds of no answer to "send", POST /close/1

I will need to look into rtmp.c to see why it doesn't wait for the
answer and instead immediately sends a new request, but I think this
might very well account for my handshake failures - the server expects
a connection handle in "send" and since it doesn't get any, it ignores
the request.


> Hi!

> I am trying to download a stream from a provider which recently
> switched to a new Flash player (the older version worked just fine
> with RTMPDUMP). Using WireShark I managed to find all? required
> parameters, and debugging the player I managed to find the secure
> token. But I am still getting a "handshake failed". Could it mean an
> unsupported (I am using the latest GIT version of RTMPDUMP)
> authentication scheme or is there some other expected reason? And if
> it *is* an unsupported authentication scheme, does it make sense for
> me to try to decipher it from the player's code? (The player is
> apparently a version of JWPlayer, but either stripped to the bones or
> very old, because the SWF is very short and it seems to contain very
> few scripts, so I think I stand a good chance of finding the scheme,
> if it can be done from client-side; the only problem is that I have no
> idea how to add it to RTMPDUMP even if I find it.)

> If anyone wants to give it a try, the command-line I am using is:

> rtmpdump
>   -z
>   -v
>   -r "rtmpt://ctv-flv1.content.mediastream.cz/CTv-video"
>   -y "mp4:vypravej/history/139.mp4"
>   -f "WIN 10,3,183,11"
>   -s "http://img8.ceskatelevize.cz/libraries/JWPlayer/player.swf"
>   -W "http://img8.ceskatelevize.cz/libraries/JWPlayer/player.swf"
>   -t "rtmpt://ctv-flv1.content.mediastream.cz/CTv-video"
>   -p
> "http://www.ceskatelevize.cz/porady/10266819072-vypravej/ve-stopach-doby/1975/v-moste-byl-kvuli-dolovani-presunut-dekansky-kostel-nanebevzeti-panny-marie/"
>   -T "5%qp-xvbt+_oi"
>   -o "x.mp4"

> And I get the following result:

> RTMPDump v2.4
> (c) 2010 Andrej Stepanchuk, Howard Chu, The Flvstreamer Team; license: GPL
> DEBUG: Parsing...
> DEBUG: Parsed protocol: 1
> DEBUG: Parsed host    : ctv-flv1.content.mediastream.cz
> DEBUG: Parsed app     : CTv-video
> DEBUG: Protocol : RTMPT
> DEBUG: Hostname : ctv-flv1.content.mediastream.cz
> DEBUG: Port     : 80
> DEBUG: Playpath : mp4:vypravej/history/139.mp4
> DEBUG: tcUrl    : rtmpt://ctv-flv1.content.mediastream.cz/CTv-video
> DEBUG: swfUrl   :
> http://img8.ceskatelevize.cz/libraries/JWPlayer/player.swf
> DEBUG: pageUrl  :
> http://www.ceskatelevize.cz/porady/10266819072-vypravej/ve-stopach-doby/1975/v-moste-byl-kvuli-dolovani-presunut-dekansky-kostel-nanebevzeti-panny-marie/
> DEBUG: app      : CTv-video
> DEBUG: flashVer : WIN 10,3,183,11
> DEBUG: live     : no
> DEBUG: timeout  : 30 sec
> DEBUG: 00 b9 3c 04 ba dd 2f 40 05 74 be 1b cb 7f c5 cd
> DEBUG: 1b ed 8c f9 1c ae 54 be f4 bd 07 a3 48 29 6c f4
> DEBUG: SWFSize  : 105686
> DEBUG: Setting buffer time to: 36000000ms
> Connecting ...
> DEBUG: RTMP_Connect1, ... connected, handshaking
> DEBUG: HandShake: Client type: 03
> DEBUG: HandShake: Client digest offset: 53
> DEBUG: HandShake: Initial client digest: 
> DEBUG: 5f 45 64 8c f0 16 f8 a6 23 99 f0 e9 d8 6e 8d 61
> DEBUG: 10 d7 bf 45 0a 70 60 f1 f3 20 b4 46 de e2 44 e1
> ERROR: RTMP_Connect1, handshake failed.
> DEBUG: Closing connection.

> I am not certain whether this means the handshake failed after the
> application of the secure token or before it.

> The packet capture of the webbrowser playing the beginning of the
> movie is here:
> http://tmp.pepak.net/ct.zip
> (the interesting packets, at least interesting to my eyes, are 1062
> and 1078)

> Thanks for any tips as to where to look.

> Pepak

> _______________________________________________
> rtmpdump mailing list
> rtmpdump at mplayerhq.hu
> https://lists.mplayerhq.hu/mailman/listinfo/rtmpdump

More information about the rtmpdump mailing list