We continue to have problems keeping a stream up with Wowza (and other viewers) orginating from an Axis IP camera transmitted over cellular link using RTP/RTSP. It is sporatic at best. No problems if it is http tunneled or sent mjpeg to another viewer or software.
When viewing the stream through Wowza on a client flash player and observing the stream in WS, immediately when the video freezes, Wowza sends a RTSP TEARDOWN command to the camera, or possibly vice-versa.
Reviewing the sequence of packets just prior to the command being issued, there is no indication of a problem and the video looks great. We see no packet losses reported at the time the video freezes either as per the Wowza log.
TCP jt400 > rtsp [ACK] Seq=3178 Ack=1279962 Win=65535 Len=0
RTP PT=DynamicRTP-Type-96, SSRC=0x747A0685, Seq=3143, Time=2137502535, Mark
RTP PT=DynamicRTP-Type-96, SSRC=0x747A0685, Seq=3144, Time=2137514547, Mark
TCP jt400 > rtsp [ACK] Seq=3178 Ack=1280292 Win=65205 Len=0
RTP PT=DynamicRTP-Type-96, SSRC=0x747A0685, Seq=3145, Time=2137523556, Mark
RTP PT=DynamicRTP-Type-96, SSRC=0x747A0685, Seq=3146, Time=2137532565, Mark
TCP jt400 > rtsp [ACK] Seq=3178 Ack=1280557 Win=64940 Len=0
RTSP TEARDOWN rtsp://18.104.22.168:554/axis-media/media.amp?videocodec=h264 RTSP/1.0
From Wowza’s side, could you please explain the exact criteria that Wowza “sees” for it to issue the RTSP TEARDOWN command, which obviously terminates the session?
Is it a timing sequence, a flag from the camera, etc? Maybe that could help us diagnose further and solve the problem.