Debugging dropped RTMPS connection

Hi,

We have developed a Flex recorder application which sends a "live-record" RTMPS stream to Wowza. The setup works for all our clients but one. That client connects via web proxy (they claim that they don't proxy RTMPS stream, but we have no visibility in their setup). The problem is that, when IE is used, the RTMPS connection is dropped some 20-30 sec into the recording without any user action. At that moment, "recordstop" and "unpublish" events are registered in Wowza logs, exactly the same way as if the client application were closing the connection because of user action. The problem exists in IE but not in Chrome, where connection is not being dropped.

Am I right that "recordstop" and "unpublish" events indicate that the client closed the connection? Would it be recorded differently in the logs if a proxy were dropping it?

I would appreciate any advice on how to approach debugging of this. I guess one way would be to try to look into the exchange at RTMP level. For that, we would likely need to set up a transparent proxy between Wowza and Internet. Is there an easier way, e.g., can we log decrypted RTMPS exchange via some Wowza module? Any other suggestions?

1 Reply

The unpublish event should indicate that the connection was closed from the encoder. You can
enable additional debug logging for the SSL protocol, or enable it server-wide for more verbose logging. You can enable verbose logging by changing the rootCategory in your conf/log4j.properties file from INFO to DEBUG. Do note that this will output a lot of logging, and you should enable this only for a short test period, and only to capture a single test stream.