[Top] [All Lists]

Re: streaming RTP through Asterisk not optimal

Subject: Re: streaming RTP through Asterisk not optimal
From: John Crispin <>
Date: Tue, 03 Jul 2012 13:28:32 +0200
In-reply-to: <>
List-archive: <>
List-help: <>
List-id: asterisk_channel_lantiq <>
List-owner: <>
List-post: <mailto:config>
List-software: Ecartis version 1.0.0
List-subscribe: <>
List-unsubscribe: <>
Original-recipient: rfc822;
References: <>
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv: Gecko/20111114 Icedove/3.1.16
On 03/07/12 11:44, Pukitis Martins (LQLA CPE ST VD) wrote:
> Dear Lantiq channel driver for Asterisk user.
> Please, note that the current implementation of lantiq channel driver is
> not the most efficient.
> In current channel driver implementation:
> -              CPE devices send/receive RTP packets through channel
> driver read/write interface.
> -              SVIP device (VoIp CentralOffice device) sends/receives
> RTP packets through userspace sockets.
> In both cases packets go through userspace and are passed to / received
> from Asterisk.
> For CPE the packet exchange over the file descriptors through user space
> is deprecated because it causes voice quality issues. The preferred
> solution is to use the KPI2UDP driver which transports RTP packets in
> kernel space directly between the TAPI and the Linux network stack. But
> this requires a patch to the Linux network stack.
> SVIP device has its own ethernet interface and is capable of
> sending/receiving RTP stream directly (redirection to the remote peer by
> NAT kernel module in necessary to hide the internal IP/MAC address of
> SVIP device).
> Passing packets through userspace adds aditional delay and jitter. There
> are definite problems in QOS tests using userspace.
> For SVIP we did the easiest implementation first, because currently we
> don’t know how to use Asterisk only for call negotiation and not to send
> RTP stream through it.
> Regards,
> Martins Pukitis.

Hi Martins,

Inside openwrt we already have the kpi and ifx-redirect drivers. However
we never had a chance to make use of them :-)

i am not sure what would be involved to allow offloading of the trp
stream to the kernel.

Not having the data pass via the userland will certainly improve quality
simply because there are less context switches.

A few weeks ago i was actually looking into the way the driver
implements the in kernel redirection. Maybe if we make this work for
asterisk we should use a encapsulation method similar to how the l2tp
kernel driver works.

However we should first evaluate how to teach asterisk what traffic
offloading is.

Kind regards,

<Prev in Thread] Current Thread [Next in Thread>