[Live-devel] live-devel Digest, Vol 47, Issue 15

[Brian Gitonga Marete]

On Wed, 2007-09-26 at 08:59 -0700, romater wrote:
> Hello:
>            EveryOne, Thanks for your help!
>            Now my problem is that: my client player and the stream
> server 
> are behind different NAT ,after client player connect the stream serve
> by 
> rtsp protocal,the stream serve begin send the video rtp packets,but
> the rtp 
> packets can not arrive to the client player. The cause maybe is that:
> the 
> rtp packets can not find the the client player client rtp port because
> the 
> Nat. I think if mapping all the udp port it is too trouble,The
> software vlc 
> can solve this problem,but I do not known how it do? 

Hello,

Anyone should correct me if I am wrong, but I think the problem is that
the multimedia data suddenly starts arriving at the NATing/Masquerading
router "out of the band" the connection was initially negotiated on.
They are UDP packets destined for internal ports from which no previous
packets have been sent (since the negotiation was via TCP.) Thus, the
router does not know where to send them internally. For something like
NTP or DNS, even though they operate via UDP, the router is able to keep
some sort of "session" since the "connection" is initiated from inside.
So it knows where to send the reply packets (internally.) This is not
true for UDP packets that start arriving due to some RTSP session.

There are probably some high-end routers that can "track" the RTSP
negotiation and send the UDP packets to the proper place when they start
arriving. I know that there is some unofficial "conntrack" module for
the Linux kernel that does the same thing. Search for it on Google if
that can be a solution for you.

BGM.