[SR-Users] mediaproxy-ng Tutorial

[aft]

On Tue, Apr 2, 2013 at 9:13 PM, Richard Fuchs <rfuchs at sipwise.com> wrote:
> 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.
>

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.

> cheers
>
> _______________________________________________
> SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
> sr-users at lists.sip-router.org
> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users



--
-aft