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
- 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
Please review our contributor agreement:
If agreed, please sign it and email me back a scanned version.
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
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).
Internetworking Research Group
On 06/20/2013 12:56 PM, Simon Morlat wrote:
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--https://tools.ietf.org/html/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://github.com/samueljero/linphone-oRTP.git branch: for-linphone
linphone: git://github.com/samueljero/linphone.git branch: for-linphone
These branches base off of the master branch from
git://git.linphone.org/linphone.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