PVC2300 vs RTCP

Unanswered Question
Oct 12th, 2009
User Badges:

Hello,

I'm using the PVC2300 camera in a 'soft' real-time application which requires a minimum of timing information. The relation of NPT and RTP time stamps in the video data and RTSP packets SHOULD be specified by a RTCP-SR packet (according to RFC3550). But while viewing video from the PVC2300 with a RTSP client, the camera isn't emitting any RTCP-SR packet. I checked this with Wireshark. Are there any options in the camera setup that I missed? Are there any plans by Cisco to fix this issue in a future firmware release?

  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 0 (0 ratings)
Loading.
Eric Moyers Wed, 10/14/2009 - 06:55
User Badges:
  • Silver, 250 points or more

Hello

Could you provide a little info on what the soft app is that you are using. I would like to take this into our lab and set it up to see what I might can do to assist you.


Eric

bmstellmXXX Fri, 10/16/2009 - 08:18
User Badges:

Hello Eric,


the realtime problem in my application is that I would like to store the synchronized A/V streams of more than one camera into a single MP4 container. The clocks of the cameras are syncronized by NTP to the clock of the recording PC. The RTP packets only contain RTP time stamps. The relationship of the NTP to the RTP timestamps has to be specified by the cameras in there RTCP sender reports (see RFC3550).


The problem is that the PVC2300 isn't emitting any RTCP packet in my case.


The test setup is quite easy:


  1. Take the PVC2300.
  2. Connect it to a PC.
  3. Start WireShark or any other network monitor on the port to which the camera is connected.
  4. Start watching video with VLC: vlc.exe rtsp://admin:[email protected]/img/media.sav
  5. Watch the output in the network monitor: You will see, that the only RTCP packets are receiver reports issued by the PC. But no sender report from the camera at all.


Cameras of other brands are emitting the sender reports as specified in RFC3550.


Thank you very much for your help.


Best regards


Martin Stellmacher

Eric Moyers Fri, 10/16/2009 - 08:42
User Badges:
  • Silver, 250 points or more

Ok I am going to try and run this in our lab here at the Small Business Support Center. One thing you can look at if you have not already..........


Each RTP session is identified by a network address and a pair of ports: one for RTP data and one for RTCP data. The RTP data port should be even, and the RTCP port should be one above the RTP port. For example, if media data is being sent on UDP port 5004, the control channel will be sent to the same address on UDP port 5005. I know that the latest revision of the RTP specification relaxes the requirement that the RTCP port is odd-numbered, and allows nonadjacent RTP and RTCP ports. For compatibility with older implementations, it is still wise to use adjacent ports where possible, with the RTCP data being sent on the higher, odd-numbered, port.


So that said, just double check that the odd number UDP port above the UDP port that RTP is using is not blocked or being hindered in any way maybe check for any blocked ports possibly. WIllupdate after I get a lab going..

Eric Moyers Fri, 10/16/2009 - 09:04
User Badges:
  • Silver, 250 points or more

Just had a thought, what is the firmware version of the cameras. There was a fix for RTCP handling on RTP over UDP in version 1.0.1

bmstellmXXX Mon, 10/19/2009 - 01:20
User Badges:

Hello Eric,


  • of course I checked the firmware version and upgraded to V1.0.1 as soon as I realized that there was a problem. But unfortunately that doesn't changed anything.
  • while video is streamed by the Linksys camera to VLC I can observe the following port assignments:
    • RTSP (TCP): PC->CAM 2774->554, CAM->PC 554->2774
    • RTP (UDP): CAM->PC 5002->2776 (no data in the opposite direction)
    • RTCP (UDP): PC-CAM 2777->5003 (no data in the opposite direction)


Best regards


Martin Stellmacher

Actions

This Discussion

Related Content