[SR-Users] Looking for RTP Proxy in TCP

Fri Jun 8 15:23:05 CEST 2012

On Fri, Jun 8, 2012 at 6:41 PM, Daniel-Constantin Mierla
<miconda at gmail.com> wrote:
>
> On 6/8/12 1:26 PM, Aft nix wrote:
>>
>> On Fri, Jun 8, 2012 at 2:18 PM, Andrew Pogrebennyk
>> <apogrebennyk at sipwise.com> wrote:
>>>
>>> The papers talk about transport protocol for signaling, not media/RTP.
>>> I didn't hear of anyone who does RTP over TCP neither. I doubt even that
>>> the performance is a primary reason behind that, for media over TCP the
>>> client link must be virtually packet-loss free (due to TCP
>>> retransmissions), while over UDP sometimes up to 5% packet loss can be
>>> tolerated. TCP was not designed as transport for real-time media :-)
>>>
>>> On 06/08/2012 12:35 AM, Yang Hong wrote:
>>>>
>>>> Hello.
>>>>
>>>> SIP over TCP would reduce server performance significantly when compared
>>>> with SIP Over UDP.
>>>>
>>>> Please read the following two papers. Combining RTP proxy with SIP over
>>>> TCP would degrade SIP server performance even worse.
>>>>
>>>> ---------------------------------------------------------------------------------------------------------------------------------------------------------------
>>>> http://www.cs.columbia.edu/~hgs/papers/Shen1008_TLS.pdf
>>>>
>>>> The Impact of TLS on SIP Server Performance
>>>>
>>>> "Securing SIP is accomplished by using TLS instead of UDP as the
>>>> transport protocol. We show that using TLS can reduce performance by up
>>>> to a factor of 17 compared to the typical case of SIP-over-UDP."
>>>>
>>>> "Network operators considering deploying SIP over TLS will need to
>>>> consider the extra resources required to provide the same service
>>>> quality as would be the case with UDP."
>>>>
>>>> ---------------------------------------------------------------------------------------------------------------------------------------------------------------
>>>>
>>>> http://www.cs.columbia.edu/~hgs/nossdav/2007/files/file-27-session5-paper1-nahum.pdf
>>>>
>>>> Evaluating SIP Proxy Server Performance
>>>>
>>>> "The next most signi cant performance feature is which transport
>>>> protocol is used, TCP or UDP. Using TCP can reduce performance anywhere
>>>> from 43 percent (the stateful proxying scenario with authentication) to
>>>> 65 percent (state-less proxying without authentication).
>>>>
>>>> ---------------------------------------------------------------------------------------------------------------------------------------------------------------
>>>>
>>>> Best regards,
>>>>
>>>> Yang
>>>>>
>>>>> Date: Thu, 7 Jun 2012 13:36:39 +0200
>>>>> From: miconda at gmail.com
>>>>> To: sr-users at lists.sip-router.org
>>>>> Subject: Re: [SR-Users] Looking for RTP Proxy in TCP
>>>>>
>>>>> Hello,
>>>>>
>>>>> On 6/4/12 7:14 PM, Austin Einter wrote:
>>>>>>
>>>>>> Hi All
>>>>>> Now I am using Kamailio 3.1.5 and RTP proxy 1.1.
>>>>>> Looks both are compatible and working fine.
>>>>>>
>>>>>> The RTP Proxy basically sends/receives RTP packets over UDP.
>>>>>> Is there any RTP Proxy available that does send/receive of RTP packets
>>>>>> over TCP and also should be compatible with Kamailio 3.1.5.
>>>>>>
>>>>>> If you have any information in this regard, kindly share.
>>>>>
>>>>> RTP itself is specified over UDP, also I am not aware of any SIP phone
>>>>> doing RTP over TCP.
>>>>>
>>>>> MSRP is a mechanism specified for sending message streams over TCP, we
>>>>> have a module for that, but I guess is not exactly what you are
>>>>
>>>> looking for:
>>>>>
>>>>> http://kamailio.org/docs/modules/devel/modules/msrp.html
>>>>>
>>>>> Maybe based on it you can implement one that fits your needs.
>>>>>
>>>>> Cheers,
>>>>> Daniel
>>>>>
>>> _______________________________________________
>>> SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
>>> sr-users at lists.sip-router.org
>>> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
>>
>>
>> These things are wild attempt to escape some telcos blocking UDP
>> packets suspecting VOIP for pushing their own IP telephony product.
>> Sometimes even encrypted media is blocked because their DPI use some
>> heuristic methods for detecting media packet. Like payload size in
>> different codecs can give a clue about the packet. Although This bites
>> in the a** of whole "net neutrality" campaign, They don't bother.
>>
>> These practices force VOIP providers for "obsfucation" techniques for
>> escaping the DPI. Interesting thing is i know of some situation when
>> they blocked VPN because people were using it to make VOIP calls. Now
>> you can use VPN for other purposes!
>>
>> Some telco even went to lengths to block UDP "streams" by calculating
>> some "threshold" bandwidth consumption.
>>
>> The DPI vendors are making a business case, but it all comes at price
>> of making Provider inventing non standard schemes to do ordinary
>> stuffs.
>>
>> Media over TCP is the worst idea in the history of worst ideas. But
>> sometimes you have no choice.
>>
>> I guess big web companies should push these telcos who are afraid of
>> losing their traditional TDM market share and going at lengths to stop
>> media over IP.
>
> look at htproxy:
>
> http://www.mbdsys.com/foss/htproxy/file/f16c43f3c3c3/README
>
> it is kind of http proxy that can be used to tunnel udp packets. You need to
> have a client application supporting it, on the sip server side you don't
> need anything.
>
>

Hi Daniel,

Does this tunnel over "HTTP"? I mean the actual payload goes as
payload of a http packet which goes over TCP?

If i'm not wrong, for sending 30 bytes of actual voice data, you have
send like 1K data?

Does this really work?

I think i'm gonna set this up in my lab to see if it works.

Thanks for the interesting link.

cheers.

> Cheers,
> Daniel
>
> --
> Daniel-Constantin Mierla - http://www.asipto.com
> http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
> Kamailio Advanced Training, Seattle, USA, Sep 23-26, 2012 -
> http://asipto.com/u/katu
> Kamailio Practical Workshop, Netherlands, Sep 10-12, 2012 -
> http://asipto.com/u/kpw
>
>
>

-- 
-aft