[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

[Freedombox-discuss] towards a business plan

Hi Marc,

On Tue, Mar 8, 2011 at 3:20 AM, Marc Petit-Huguenin
<marc at petit-huguenin.org> wrote:
> Hash: SHA1
> On 03/07/2011 04:21 AM, Paul Gardner-Stephen wrote:
>> Hello,
>> On Mon, Mar 7, 2011 at 9:55 AM, Marc Petit-Huguenin
>> <marc at petit-huguenin.org> wrote:
>> .. snip ...
>>>> Yes, SIP is very good in many ways, but at ServalProject.org at least,
>>>> we are looking to create a simple alternative protocol (open of
>>>> course) which will tolerate latency and excessive packet loss much
>>>> better than SIP does,
>>> I guess you mean RTP, not SIP here.
>> Excuse my sloppy lumping of RTP and SIP together; my concern is with
>> them jointly and severally.
>> Neither is good in bad packet loss, which is reasonable, as they were
>> not designed with it in mind.
> For SIP, packet loss is not that critical - it's just signaling and that would
> just delay call establishment and stuff like that. ?That does not really make
> for a bad user experience.

In our experience the packet loss in signalling results in terrible
user experience.
Sometimes calls will take 30sec - 90sec to establish, or not establish
at all, even though once established, the call goes fine.
One component of this problem is that packet loss on wifi increases
with packet size, and SIP uses hairy great packets that love to get
lost in transit.

> RTP on the other hand works very well with packet loss and latency - when RTCP
> is also correctly implemented, which is rarely the case in my experience. ?In my
> opinion, RTP is one of the IETF protocol that stick the most to the original
> premise of the Internet, the end to end argument - argument which is also the
> foundation of the Freedom Box, if I am not confused.

Once the call is established, you are right, RTP works fairly well,
with just drop outs for missing audio.
This can still be improved by using a codec regime that uses Forward
Error Correction or similar to accomodate the loss of some reasonable
amount of packet loss, say, up to 25%, although 75% should be


> - --
> Marc Petit-Huguenin
> Personal email: marc at petit-huguenin.org
> Professional email: petithug at acm.org
> Blog: http://blog.marc.petit-huguenin.org
> Version: GnuPG v1.4.11 (GNU/Linux)
> iEYEARECAAYFAk11DNoACgkQ9RoMZyVa61eXKgCbBbs0n+Vjwm1QefLtyFya3ANm
> pTYAnRD7BdhNZaY3Sz/ieyEHiwuTWcbk
> =y8nu

Reply to: