Control the source port

[GoldenEgg]

Hello,
I saw several conversation regarding the fact that VLC do not allow to select its source port when streaming video with UDP. I have to ask the question again and to try to be more specific with what stand behind it and to see how can I overcome the situation I'm facing:

When I stream video with UDP to a specific public IP address and port pair in order to penetrate the NAT and bring the video into the target private IP behind this NAT I need to punch a hole in it before the VLC stream arrives to the NAT. In order to do this I have to send a dummy UDP packet FROM the target private IP TO the source of the streaming.

Now, there are different types of NAT (see http://www.crfreenet.org/~martin/referaty/stun/naty.pdf) and there is specifically one type - "Port Restricted Cone NAT", that accept only incoming UDP packet that designated to a specific internal destination port and arrived from a specific source port. In order to punch a hole in that kind of a NAT one have to know both source and destination ports of the incoming UDP stream (in our case VLC stream) and of course its source IP - in that point I have a problem with the fact that VLC source port is unknown before the streaming begin.

I hope I made myself clear and I hope I can get some help in resolving that issue.

Thanks,

Eyal

[frankcch]

I have the same problem. I need to know the rtp source port in order to overcome the NAT issue.
Without knowing the sorce port, the sending stream is not able to reach to the destination.

[Rémi Denis-Courmont]

The source port is provided by the server in the RTSP SETUP response if the client needs to punch holes.

[frankcch]

Hi,

I have two windows XP/PCs, both have 2.7 GHz CPU, one PC1 with ip 192.168.2.101, and another PC2 with 192.168.2.102. Both PC1 and PC2 set up to capture RTP streaming and send RTP streaming in both direction. But only one PC can capture the video streaming.
The other PC cannot capture streaming.

PC1 (192.168.2.101) <---------RTP-------> PC2 (192.168.2.102)
capture streaming <------- RTP ----- send streaming
send streaming --------- RTP -------> capture straming

Here are the set up
PC1 (192.168.2.101) set up
vlc --rtp-caching=300 rtp://@:1234
vlc dshow:// --sout #transcode{vcodec=h264,vb=800,fps=5,scale=1,acodec=none}:rtp{dst=192.168.2.102,port=1234,mux=ts}"

PC1 (192.168.2.102) set up
vlc --rtp-caching=300 rtp://@:1234
vlc dshow:// --sout #transcode{vcodec=h264,vb=800,fps=5,scale=1,acodec=none}:rtp{dst=192.168.2.101,port=1234,mux=ts}"

PROBLEM: sometimes only can capture one way video and it take 10-20 seconds to capture the video, the other side without out video.

For example,
Both PC1 and PC2 are set up to capture and send streaming.
PC1 takes 10 seconds to capture video sending from PC2, and PC2 cannot see the video sending from PC1.
If PC2 stop sending streaming, then PC2 is able to capture video which sending from PC1,
If PC2 start to sending the streaming again, then sometimes has only one PC can capture the video, somestimes both PCs can capture video.

Both PC1 and PC2 CPU rate around 60% only, and I can see the both PC1 and PC2 do send and receive packets from sniffer, without lost any packets. But one one PC can capture the video.

I tried different vb, fps, and caching, but problem is still there. I am wondering where the CAPTURE is not running (or not activated) while sending streaming. The video capture will be back if stop sending streaming.

By the way, I bring up the capture and send streaming on both PC1 and PC2 by using the windows CreateProcess()

[tamiro44]

You are using VLC as server?
Maybe you have to check the GOP size (I-frames) at the sender?