[Top][All Lists]

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

Re: [Linphone-developers] [PATCH] DCCP Support

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


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
On 06/20/2013 12:56 PM, Simon Morlat wrote:
Hi Samuel,

I apologize for my belated answer.
Congratulations for all the work you did in Linphone. I reviewed all your commits. This is very impressive and this looks pretty well written.
I did not know the existence of DCCP, and thus I also thank you for pointing this to us.

I have very quickly read the DCCP rfc and I would like to know if you had any opinion regarding the way it works with NATs.
Indeed  I understand that is connection oriented (like TCP), which means there are client and server sockets.
Do NATs support DCCP ?

Thank you very much,


Le 11/06/2013 23:53, Samuel Jero a écrit :
As part of my masters work, I have added support for streaming media
over the Datagram Congestion Control Protocol (DCCP) to linphone. DCCP
is a relatively new protocol (2006) developed by the IETF to provide
congestion control without reliability for applications like VoIP and
video streaming (RFC4340-- I would
like to contribute this work back to the main Linphone code-base, if
possible, so that others can utilize it.

My patches consist of three main parts:
1)Adding support for DCCP to oRTP. This involves substantial changes to
rtpsession_inet.c, particularly since DCCP is a connection-oriented
protocol, unlike UDP.
2)Updating the bitrate control mechanisms in mediastreamer2 and the
feedback it receives from oRTP. DCCP provides feedback to the
application as to how fast it is allowed to send and when it needs to
slow down. This feedback is distinctly more rapid that RTCP reports, so
I utilize it in preference to RTCP for bitrate control.
3)Updating APIs throughput oRTP, mediastreamer2, and liblinphone to
allow selection of transport protocol.

As the patches to add DCCP support are fairly significant, I have
created a repository on github containing the changes:
oRTP: git://   branch: for-linphone
git://   branch:
linphone: git://   branch: for-linphone
These branches base off of the master branch from
git:// as of 2013-06-10.

Direct links to my commits are below:

Any comments on these patches would be appreciated. I can try to split
out a large number of smaller patches if that would help, but a lot of
the changes are interrelated.


Linphone-developers mailing list

Attachment: signature.asc
Description: OpenPGP digital signature

reply via email to

[Prev in Thread] Current Thread [Next in Thread]