On 04/02/13 10:54, aft wrote:
I was actually asking How it works? I mean when there is kernel based forwarding is enabled, what does the daemon do compared to when the kernel based forwarding is not enabled?
If i want do some modifications on rtp packets and intend to use kernel based forwarding then where should i put my code? in daemon part or the xtable module given there?
I was confused about the architecture of the package. When there is no kernel based forwarding, Then the daemon should work like a simple udp relay. But when there is kernel based forwarding, if the packets never comes up to the userland, then what does daemon do in that scenario?
Packet forwarding always happens in the userspace daemon during the initial stages of a newly established media stream. This is to make sure that the daemon can learn the correct media endpoints from the actual RTP packets (they may be different than what was advertised in the SDP, e.g. in NAT cases). Once the daemon is sufficiently satisfied with the endpoints that it has learned (after a few seconds of media flowing both ways), it will try to enable kernel forwarding for those streams. This involves the daemon sending a command to the kernel module which includes all the required parameters for packet forwarding, such as local UDP port, source address/port and destination address/port. From this point on, the kernel module will take over UDP packets arriving at this local port, will not pass them up to userspace any more and instead will send them right out again, towards their specified destination. The daemon will never get to see those packets (with the exception of STUN packets, a requirement for ICE) even though the userspace UDP socket remains open. The daemon becomes a controlling entity, telling the kernel what to do with those packets. It will periodically query the kernel module for statistics on all established streams (packet counts etc) to update its own internal stream statistics, which is important for timeout handling. When the media stream is torn down, or in case of re-invites or any other changes to the stream configuration, the daemon sends another command to the kernel module to stop forwarding packets arriving at these local UDP ports, at which point the packets will be passed up to userspace again.
Therefore, if you wish to manipulate RTP packets, the code would definitely have to be present in the daemon. If manipulation is required for a particular stream, then the daemon can either choose not to enable kernel forwarding for those streams, or the kernel module would have to support the same manipulation of the RTP packets. In the latter case, the control protocol between the daemon and the kernel module would have to be extended to include details about which manipulations are to be performed on the packets.
cheers