From Martins.Pukitis@lantiq.com Tue Jul 3 11:44:41 2012 Received: with ECARTIS (v1.0.0; list asterisk_channel_lantiq); Tue, 03 Jul 2012 11:44:46 +0200 (CEST) Received: from Smtp2.Lantiq.com ([195.219.66.201]:13097 "EHLO smtp2.lantiq.com" rhost-flags-OK-OK-OK-OK) by eddie.linux-mips.org with ESMTP id S1903458Ab2GCJol (ORCPT ); Tue, 3 Jul 2012 11:44:41 +0200 X-IronPort-AV: E=McAfee;i="5400,1158,6760"; a="354958" Received: from unknown (HELO MUCSVECH044.lantiq.com) ([10.64.181.189]) by smtp2.lantiq.com with ESMTP; 03 Jul 2012 11:44:36 +0200 Received: from MUCSE039.lantiq.com ([169.254.3.50]) by MUCSVECH044.lantiq.com ([10.64.181.79]) with mapi id 14.02.0247.003; Tue, 3 Jul 2012 11:44:53 +0200 From: "Pukitis Martins (LQLA CPE ST VD)" To: "asterisk_channel_lantiq@linux-mips.org" Subject: streaming RTP through Asterisk not optimal Thread-Topic: streaming RTP through Asterisk not optimal Thread-Index: Ac1ZAH2xYpY2ANluQ4aCVfcV2P5PMw== Date: Tue, 3 Jul 2012 09:44:51 +0000 Message-ID: <0516062BB218664B8C4CF0F51E20E69F012202@MUCSE039.lantiq.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.64.132.27] Content-Type: multipart/alternative; boundary="_000_0516062BB218664B8C4CF0F51E20E69F012202MUCSE039lantiqcom_" MIME-Version: 1.0 Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s asterisk_channel_lantiq"> (uid 0) X-Orcpt: rfc822;asterisk_channel_lantiq@linux-mips.org Original-Recipient: rfc822;asterisk_channel_lantiq@linux-mips.org X-archive-position: 3 X-ecartis-version: Ecartis v1.0.0 Sender: asterisk_channel_lantiq-bounce@linux-mips.org Errors-to: asterisk_channel_lantiq-bounce@linux-mips.org X-original-sender: Martins.Pukitis@lantiq.com Precedence: bulk List-help: List-unsubscribe: List-software: Ecartis version 1.0.0 List-Id: asterisk_channel_lantiq X-List-ID: asterisk_channel_lantiq List-subscribe: List-owner: List-post: List-archive: X-list: asterisk_channel_lantiq --_000_0516062BB218664B8C4CF0F51E20E69F012202MUCSE039lantiqcom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear Lantiq channel driver for Asterisk user. Please, note that the current implementation of lantiq channel driver is no= t 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 p= ackets through userspace sockets. In both cases packets go through userspace and are passed to / received fro= m 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 d= irectly between the TAPI and the Linux network stack. But this requires a p= atch to the Linux network stack. SVIP device has its own ethernet interface and is capable of sending/receiv= ing RTP stream directly (redirection to the remote peer by NAT kernel modul= e in necessary to hide the internal IP/MAC address of SVIP device). Passing packets through userspace adds aditional delay and jitter. There ar= e 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 st= ream through it. Regards, Martins Pukitis. --_000_0516062BB218664B8C4CF0F51E20E69F012202MUCSE039lantiqcom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Dear Lantiq channel driver for Asterisk user.

 

Please, note that the current implementation of l= antiq 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) send= s/receives RTP packets through userspace sockets.

In both cases packets go through userspace and ar= e passed to / received from Asterisk.

For CPE the packet exchange over the file descrip= tors through user space is deprecated because it causes voice quality issue= s. 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 remot= e peer by NAT kernel module in necessary to hide the internal IP/MAC addres= s 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 ne= gotiation and not to send RTP stream through it.

 

Regards,

Martins Pukitis.

 

--_000_0516062BB218664B8C4CF0F51E20E69F012202MUCSE039lantiqcom_-- From john@phrozen.org Tue Jul 3 13:29:47 2012 Received: with ECARTIS (v1.0.0; list asterisk_channel_lantiq); Tue, 03 Jul 2012 13:29:53 +0200 (CEST) Received: from nbd.name ([46.4.11.11]:38636 "EHLO nbd.name" rhost-flags-OK-OK-OK-OK) by eddie.linux-mips.org with ESMTP id S1903450Ab2GCL3r (ORCPT ); Tue, 3 Jul 2012 13:29:47 +0200 Message-ID: <4FF2D760.8040609@phrozen.org> Date: Tue, 03 Jul 2012 13:28:32 +0200 From: John Crispin User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.24) Gecko/20111114 Icedove/3.1.16 MIME-Version: 1.0 To: asterisk_channel_lantiq@linux-mips.org Subject: Re: streaming RTP through Asterisk not optimal References: <0516062BB218664B8C4CF0F51E20E69F012202@MUCSE039.lantiq.com> In-Reply-To: <0516062BB218664B8C4CF0F51E20E69F012202@MUCSE039.lantiq.com> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s asterisk_channel_lantiq"> (uid 0) X-Orcpt: rfc822;asterisk_channel_lantiq@linux-mips.org Original-Recipient: rfc822;asterisk_channel_lantiq@linux-mips.org X-archive-position: 4 X-ecartis-version: Ecartis v1.0.0 Sender: asterisk_channel_lantiq-bounce@linux-mips.org Errors-to: asterisk_channel_lantiq-bounce@linux-mips.org X-original-sender: john@phrozen.org Precedence: bulk List-help: List-unsubscribe: List-software: Ecartis version 1.0.0 List-Id: asterisk_channel_lantiq X-List-ID: asterisk_channel_lantiq List-subscribe: List-owner: List-post: List-archive: X-list: asterisk_channel_lantiq 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, John From john@phrozen.org Tue Jul 3 13:56:02 2012 Received: with ECARTIS (v1.0.0; list asterisk_channel_lantiq); Tue, 03 Jul 2012 13:56:08 +0200 (CEST) Received: from nbd.name ([46.4.11.11]:45458 "EHLO nbd.name" rhost-flags-OK-OK-OK-OK) by eddie.linux-mips.org with ESMTP id S1903458Ab2GCL4C (ORCPT ); Tue, 3 Jul 2012 13:56:02 +0200 Message-ID: <4FF2DD8A.8040609@phrozen.org> Date: Tue, 03 Jul 2012 13:54:50 +0200 From: John Crispin User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.24) Gecko/20111114 Icedove/3.1.16 MIME-Version: 1.0 To: asterisk_channel_lantiq@linux-mips.org Subject: Re: implementation for Lantiq SVIP device References: <0516062BB218664B8C4CF0F51E20E69F011CAE@MUCSE039.lantiq.com> In-Reply-To: <0516062BB218664B8C4CF0F51E20E69F011CAE@MUCSE039.lantiq.com> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s asterisk_channel_lantiq"> (uid 0) X-Orcpt: rfc822;asterisk_channel_lantiq@linux-mips.org Original-Recipient: rfc822;asterisk_channel_lantiq@linux-mips.org X-archive-position: 5 X-ecartis-version: Ecartis v1.0.0 Sender: asterisk_channel_lantiq-bounce@linux-mips.org Errors-to: asterisk_channel_lantiq-bounce@linux-mips.org X-original-sender: john@phrozen.org Precedence: bulk List-help: List-unsubscribe: List-software: Ecartis version 1.0.0 List-Id: asterisk_channel_lantiq X-List-ID: asterisk_channel_lantiq List-subscribe: List-owner: List-post: List-archive: X-list: asterisk_channel_lantiq On 28/06/12 14:23, Pukitis Martins (LQLA CPE ST VD) wrote: > Patch on top of > > * commit 553ea59a4cc2d4b963d25ca6c82c0d71311331ac > > | Author: Kaspar Schleiser > > | Date: Wed Jun 20 16:56:27 2012 +0200 > > | > > | implement transmission of dtmf in call > > | > > | Contributed by T-Labs, Deutsche Telekom Innovation Laboratories > Hi Martins, Thank you for the SVIP patch. There are a few formal errors. It seesm like the patch infact consists of 3 patches 1) fix some encoding errors in the license header 2) some whitespace fixes 3) the actualy new feature being added Would you mind to resend the patch split up into 3 ? Thanks, John