Re: [Ekiga-list] Ekiga on Ubuntu using DSL
- From: Eugen Dedu <Eugen Dedu pu-pm univ-fcomte fr>
- To: Ekiga mailing list <ekiga-list gnome org>
- Subject: Re: [Ekiga-list] Ekiga on Ubuntu using DSL
- Date: Sat, 27 Mar 2010 20:34:57 +0100
Chris Vine wrote:
> On Sat, 27 Mar 2010 08:31:58 +0100
> yannick <sevmek free fr> wrote:
>> You can test ekiga 3.2.6 for karmic with the patch here:
>> https://launchpad.net/~sevmek/+archive/ppa
>>
>> I do no used "ekiga-released" as I consider it as official and I do
>> not want to confuse users of it with some testing.
>
> I am not using karmic. Can you please post the patch here and I will
> recompile libopal.
Attached.
Thanks,
--
Eugen
#! /bin/sh /usr/share/dpatch/dpatch-run
## libname.dpatch by Eugen Dedu
##
## All lines beginning with `## DP:' are a description of the patch.
## DP: nat patch
@DPATCH@
diff -u opal-svn/samples/simple/Makefile opal/samples/simple/Makefile
--- opal-svn/src/rtp/rtp.cxx 2010/03/14 23:18:55 24128
+++ opal/src/rtp/rtp.cxx 2010/03/16 06:22:52 24129
@@ -1640,15 +1640,24 @@
PIPSocket::Address bindingAddress = localAddress;
if (natMethod != NULL && natMethod->IsAvailable(localAddress)) {
switch (natMethod->GetRTPSupport()) {
+ case PNatMethod::RTPIfSendMedia :
+ /* This NAT variant will work if we send something out through the
+ NAT port to "open" it so packets can then flow inward. We set
+ this flag to make that happen as soon as we get the remotes IP
+ address and port to send to.
+ */
+ localHasNAT = true;
+ // Then do case for full cone support and create STUN sockets
+
case PNatMethod::RTPSupported :
if (natMethod->CreateSocketPair(dataSocket, controlSocket, localAddress)) {
- PTRACE(4, "RTP\tSession " << sessionID << ", " << natMethod->GetName() << " created RTP/RTCP socket pair.");
+ PTRACE(4, "RTP\tSession " << sessionID << ", " << natMethod->GetName() << " created STUN RTP/RTCP socket pair.");
dataSocket->GetLocalAddress(localAddress, localDataPort);
controlSocket->GetLocalAddress(localAddress, localControlPort);
}
else {
PTRACE(2, "RTP\tSession " << sessionID << ", " << natMethod->GetName()
- << " could not create RTP/RTCP socket pair; trying to create RTP socket anyway.");
+ << " could not create STUN RTP/RTCP socket pair; trying to create individual sockets.");
if (natMethod->CreateSocket(dataSocket, localAddress) && natMethod->CreateSocket(controlSocket, localAddress)) {
dataSocket->GetLocalAddress(localAddress, localDataPort);
controlSocket->GetLocalAddress(localAddress, localControlPort);
@@ -1659,22 +1668,18 @@
dataSocket = NULL;
controlSocket = NULL;
PTRACE(2, "RTP\tSession " << sessionID << ", " << natMethod->GetName()
- << " could not create RTP sockets individually either, using normal sockets.");
+ << " could not create STUN RTP/RTCP sockets individually either, using normal sockets.");
}
}
break;
- case PNatMethod::RTPIfSendMedia :
- /* We canot use NAT traversal method (e.g. STUN) to create sockets
- as the NAT router will then not let us talk to the real RTP
- destination. All we can so is bind to the local interface, which
- telling the remote our address is the external address of the
- NATrouter, and hope the remote is tolerant enough of things like
- non adjacent RTP/RTCP ports etc. */
- localHasNAT = natMethod->GetInterfaceAddress(bindingAddress);
- break;
-
default :
+ /* We canot use NAT traversal method (e.g. STUN) to create sockets
+ in the remaining modes as the NAT router will then not let us
+ talk to the real RTP destination. All we can so is bind to the
+ local interface the NAT is on and hope the NAT router is doing
+ something sneaky like symmetric port forwarding. */
+ natMethod->GetInterfaceAddress(bindingAddress);
break;
}
}
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]