[Top][All Lists]

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

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

From: Simon Morlat
Subject: Re: [Linphone-developers] [PATCH] DCCP Support
Date: Wed, 03 Jul 2013 11:53:20 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130510 Thunderbird/17.0.6

Hi Samuel,

Thank you for your very interesting response.
Our company (Belledonne Communications) would be interested to merge your contribution to the main tree of Linphone.
Indeed despite DCCP isn't very widely used I believe it is very innovative and illustrates very well its capabilities with a VoIP application like Linphone.
If merged, it will give better chance for your contribution to continue to build and work accross future versions of Linphone.

The merging process implies too things:
- we would dedicate work hours to carefully merge, commit after commit and possibly make some changes in order to preserve API compatibilities
- we would need from you to accept our contributor agreement, whose goal is essentially to provide us the necessary rights on your contribution in order for Belledonne Communications to continue to make commercial licensing of Linphone including your contribution.

Please review our contributor agreement:
If agreed, please sign it and email me back a scanned version.

Best regards,


Le 20/06/2013 20:46, Samuel Jero a écrit :

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

Linphone-developers mailing list

reply via email to

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