3 Apr
2013
3 Apr
'13
12:39 a.m.
On Tue, Apr 2, 2013 at 9:13 PM, Richard Fuchs <rfuchs(a)sipwise.com> wrote:
On 04/02/13 10:54, aft wrote:
So the bottom line is i have to include the code in both places.
Another thing is i'm assuming you know much about the development of this media
relay. So i'm asking, is there any plan for including "repacketization"
feature?
Its very crucial for our operation, so if there is no plan for it,
then i wish to do it
myself. Although i know nothing of its codebase, but if active developers help,
i think i can do it.
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
_______________________________________________
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
--
-aft