|
From: | Samuel Jero |
Subject: | Re: [Linphone-developers] [PATCH] DCCP Support |
Date: | Thu, 20 Jun 2013 14:46:05 -0400 |
User-agent: | Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130510 Thunderbird/17.0.6 |
Simon,
DCCP is, indeed, a connection-oriented protocol, requiring a connect() call sender side and listen()/accept() receiver side. As far as NAT traversal goes, the vast majority of consumer grade NAT devices have no support for DCCP. Some of them will drop the packets entirely, others will pass them through but not update the pseudo-header-based checksum, resulting in checksum failure at the receiver. On the upside, Linux's netfilter NAT system has had DCCP support since 2005. This situation is representative of DCCP's status in general: No one is using it because there is little support and no one is supporting it because no one is using it. My hope is that getting DCCP support into a few good applications, like Linphone, would help to break this cycle. My MS thesis research into the quality of video streaming using DCCP has shown that DCCP has distinct promise in this area. It is significantly more responsive to network conditions that RTCP, usually achieves much more even video quality than UDP/RTCP, and is distinctly fairer to other network traffic. For new applications, it provides the additional benefit that application designers don't have to design and implement congestion control algorithms; DCCP will take care of that automatically. Limited NAT support is not the only issue that DCCP faces at the moment. Currently, the only maintained implementation of DCCP is in Linux. OS X, iOS, and Windows currently have no support. This is why I wrapped all the DCCP socket calls in #defines and disable it by default, requiring a --enable-dccp option to oRTP's configure script to enable it (I suppose you could also try OS detection). One last comment about NAT support. The imminent transition to IPv6 by a large number of ISPs (at least here in the US) will require that the vast majority of consumer endpoint NAT boxes be replaced. For those boxes based on Linux (dd-wrt and friends), it is quite possible that they could pull in DCCP support automatically at that time. Further, IPv6 itself should do away with a lot of the issues surrounding NAT. Since my last email, I have added a new branch to the github repositories mentioned previously. This branch, "multi", contains a number of smaller commits that are cumulatively identical to the single large commit in the "for-linphone" branch. This may be helpful to understand my changes and the reasoning behind them (or to modify them, if needed). Samuel Jero Masters Student Computer Science Internetworking Research Group Ohio University address@hiddenOn 06/20/2013 12:56 PM, Simon Morlat wrote:
|
signature.asc
Description: OpenPGP digital signature
[Prev in Thread] | Current Thread | [Next in Thread] |