On 27/03/10 16.13, Kristian Kielhofner wrote:

There are many things wrong with this but let's start with the most obvious: it won't take much time for these mobile operators to distinguish your port 53 RTP traffic from real DNS traffic. Even with the same port number they look nothing alike and it would be trivial for any provider worth their salt to separate and classify the traffic accordingly. Nevermind the fact that you'd be attracting A LOT of attention for yourself.

Your RTP traffic (at a rate of around 50pps) would hammer the network and potentially DoS other user's legitimate DNS traffic. Don't get greedy.

Well, that's a point of the whole vision. Mobile VoIP it's difficult and require a lot of hacks and optimization and still it's difficult. You can't control the QoS policy of mobile operator but if you know that they optimize some port or protocol try to use it. You need to bypass eventually present block by obfuscating RTP and SIP protocol. You need to use TCP port for SIP that does not have low NAT timeout of idle session. You need to use VAD, high ptime, reduce protocol overhead and employ important jitter buffer optimization on SIP UA in order to manage the difficulties in the burst based mobile networks. And the war never end, i do security mobile crypto product and in my context those tools are important when there are important international political events. During that periods even the full udp could be blocked by mobile operators, DPI technologies can be enhanced to provide more informations to intelligence services and in such context the only transport you will have is HTTP (not even HTTPS) requiring to make VoIP over HTTP (dirty, slow, drammatically inefficient transport... brrr!). So the possibility to multiplex across a single UDP port it's just one part of the big picture where the mobile is a pain in the XXX in any network scenario you want to look at it.

P.S. - If you were interested in doing this from a research perspective I'd recommend developing your own RTP proxy (perhaps using RTPProxy or MediaProxy as a base) to accomplish your "multiplexing" goals although I think you're up for a challenge - just look at the performance implications for any IAX2 implementation and you'll see what I am talking about.

mmmm probably if requiring a third party apps approach an RTP over DNS, by encapsulating packets within a DNS tunnel, would be even more effective. Also i am seeing that the TCP socket of FS and the congestion control of TCP under mobile network have to be finely tuned and modified in order to handle the mobile network IP-related issues (high packet loss, high latency, high burst of traffic) where the retransmission of TCP and the exponential backoff algorithms could be killers. Probably a TCP proxy with PEP approach is required to really use TCP on mobile environment for always on connection and realtime signaling. FS could also introduce such kind of support to be suited for mobile clients. Fabio

Le 27/03/2010 à 16:26, Jean-Yves F. Barbier a écrit :

A comm needs 2 RTP streams, most of (good) softphones forbid an odd port number in order to keep things clear: they give you an even port, and the next one is the RTP "return path" of the same comm.

Actually, a comm is 2 RTP streams but they use the same port on both ends (endpoint A port X <------> endpoint B port Y>. The next port (often the odd one) is "used" by RTCP, so let's say it's unused as RTCP is not really widely used, but another RTP stream should never use this port, as it could lead to some strange things....