[pjsip] Weired Scenario- Symbian HTTP tunneling

vivek shrivastava vivek.mics at gmail.com
Wed Aug 26 01:57:02 EDT 2009


---------------------------------------

Hi Klaus and Benny,

I was just going through pjsip blog and I came across your post over
there. I'm also interested doing this stuff.
Following is your post from the blog. I have no idea how to reply on
the blog that's why e-mailing you.

-------------------------------------------------------------------------------------------------------------------------------

Interesting.

For SIP-tunneling in combination with an HTTP proxy it might also be
possible if pjsip can be extended with a TLS_HTTPPROXY transport, which
connects to the HTTP proxy and perform a CONNECT before TLS handshake.

If the SIP proxy is listening on port 443 too, it should work (as many
http proxies allow CONNECT only to https port)

regards
klaus

Benny Prijono schrieb:
> I also happen to play on this area yesterday. Someone else wanted HTTP

> tunnel because of two things: some provider blocks pretty much
> everything except HTTP, and second because one some mobile plan people
> can have unlimited http data traffic.
>

> We don't have HTTP tunnel of course, and I wasn't aware of this post
> yesterday, so I suggested an alternative solution, with adding TCP port
> 80 to my OpenSER configs, and install TURN server on TCP port 80 too (on

> different IP address obviously). Then on pjsip side, just enable TURN
> and connect with TCP (--use-turn --turn-tcp options).
>
>  From the feedback that I got so far (I've only started experimenting

> yesterday), this seems to be able to penetrate the firewall fine, so it
> seems that the firewall doesn't actually inspect the content of the
> connection (which is understandable, since this must be quite an

> expensive operation). Though some tweaking may be required, as we may
> get ICE negotiation failure with this configuration due to additional
> round-trips to setup TURN permissions, especially on slow links. And of

> course you'll need robust software in the server side since by listening
> on port 80 you will get many HTTP requests from web spiders. :)
>
> But the advantage of this is we're using standard based approach, and no

> development is needed on pjsip side. So might worth considering. Fyi
> http://www.sf.net/projects/turnserver works fine with pjsip so far.
>

> As for the original question, sorry I have no idea. Since it's the pjsip
> side that you're debugging, log file from pjsip will be useful.
>
> cheers
>  Benny

-------------------------------------------------------------------------------------------------------------------------------

My understanding is for the whole above discussion, we are suppose to
use OpenSER, TURN server and SIP UA (pjsip client).
Few questions on this

1. Can I use Asterix Box(SIP server) instead of OpenSER?
And this server is suppose to configure for port 80. Is that correct?

2. Need to install TURN server at different IP, and same should be
configure for port 80. Is it correct?
I assume that there must be some configuration I need to perform, and
which will have my Asterix servers details. Is this correct?

3. I'm using PJSIP Symbian UA. Here I need to specify TURN server IP.
Is this understanding is correct?
-are there any more changes required at PJSIP UA front? If yes,
suggestions will be appreciated.

I would be excepecting reply on this rom Benny.
Benny , please put your expert thoughts on this.

Thanks.
vivek

On Fri, Jul 3, 2009 at 2:16 PM, Benny Prijono<bennylp at teluu.com> wrote:
> I also happen to play on this area yesterday. Someone else wanted HTTP
> tunnel because of two things: some provider blocks pretty much everything
> except HTTP, and second because one some mobile plan people can have
> unlimited http data traffic.
>
> We don't have HTTP tunnel of course, and I wasn't aware of this post
> yesterday, so I suggested an alternative solution, with adding TCP port 80
> to my OpenSER configs, and install TURN server on TCP port 80 too (on
> different IP address obviously). Then on pjsip side, just enable TURN and
> connect with TCP (--use-turn --turn-tcp options).
>
> From the feedback that I got so far (I've only started experimenting
> yesterday), this seems to be able to penetrate the firewall fine, so it
> seems that the firewall doesn't actually inspect the content of the
> connection (which is understandable, since this must be quite an expensive
> operation). Though some tweaking may be required, as we may get ICE
> negotiation failure with this configuration due to additional round-trips to
> setup TURN permissions, especially on slow links. And of course you'll need
> robust software in the server side since by listening on port 80 you will
> get many HTTP requests from web spiders. :)
>
> But the advantage of this is we're using standard based approach, and no
> development is needed on pjsip side. So might worth considering. Fyi
> http://www.sf.net/projects/turnserver works fine with pjsip so far.
>
> As for the original question, sorry I have no idea. Since it's the pjsip
> side that you're debugging, log file from pjsip will be useful.
>
> cheers
>  Benny
>
>
> On Mon, Jun 29, 2009 at 2:18 PM, Klaus Darilion
> <klaus.mailinglists at pernau.at> wrote:
>>
>> Just fyi: there is also HTTP tunneling support in QuteCom. I don't know if
>> it does some kind of RTP compression.
>>
>> regards
>> klaus
>>
>> Fabio Pietrosanti (naif) schrieb:
>>>
>>> VOIP Guru wrote:
>>>>
>>>> Well I was playing with it for the last few months.
>>>> First I thought I could just use a opensource HTTP tunnel/server and
>>>> send the data through it. But later I realized, true HTTP tunneling
>>>> could not be usefull in this case. The main reason is most of the HTTP
>>>> tunnel does not keep persistent TCP connection rather it closes the
>>>> connection as soon as it completes the request. But in real life
>>>> scenario you dont want that as it will shoot up the PDD for the
>>>> overhead of reconnection. Second HTTP always adds the header with it
>>>> and can not be attached as is with the RTP as it will eat up all your
>>>> bandwidth and payload. So I came up with idea of using good HTTP
>>>> wrapping for SIP messages and having some tricky headers with RTP.
>>>
>>> For tricky headers for RTP what do you mean?
>>> In a project to make an RTP compatible packet over a 9.6kb GSM CSD
>>> channel last year we made a strong analisys to strip-out any field of the
>>> header that we was able not-to-retransmit at each packet, and we put all
>>> them in a HELO packet to be exchanged by the peer at the beginning.
>>>
>>> This greatly reduced the RTP header overhead from 12byte to 4byte + a two
>>> way initial HELO packet exchange.
>>> Are you using a similar approach?
>>>
>>> Still i am concerned about possible performence problem of TCP, even if
>>> the paper i provided in the past email state that by using NO_DELAY it
>>> should have less than 20-25% more latency than when used with UDP.
>>> Even if the paper also state that the latency of plain TCP it's more than
>>> 150-200% of UDP transport.
>>>
>>>>  I
>>>> also used two persistent connection one for SIP and another for RTP.
>>>>
>>>
>>> Nice, how do you manage congestions and retransmissions?
>>> I mean, did you had to enable/disable SACK features of TCP or something
>>> like this?
>>>
>>> I read there that using https instead of http would be maybe better:
>>> http://lists.iptel.org/pipermail/serusers/2005-December/026406.html
>>>
>>>> The most critical part is, you still need to parse the SIP and SDP for
>>>> routing all your message and RTP. So actually I ended up writing
>>>> partial SIP proxy with the mixup on HTTP protocol.
>>>>
>>>
>>> I think you also wrote a gateway to make translate the RTP-over-HTTP to
>>> plain RTP, right?
>>>
>>> Are you planning to release such software and/or the specifications of
>>> the protocol in an opensource environment?
>>>
>>> I would be very interesting in a cooperation about such kind of
>>> technology that, other than providing firewall-traversal, could also create
>>> some narrowbandwidth RTP header transport if properly implemented, thus
>>> strongly reducing the bandwidth.
>>>
>>> Waiting for yours
>>>
>>> Fabio
>>>
>>>
>>> _______________________________________________
>>> Visit our blog: http://blog.pjsip.org
>>>
>>> pjsip mailing list
>>> pjsip at lists.pjsip.org
>>> http://lists.pjsip.org/mailman/listinfo/pjsip_lists.pjsip.org
>>
>> _______________________________________________
>> Visit our blog: http://blog.pjsip.org
>>
>> pjsip mailing list
>> pjsip at lists.pjsip.org
>> http://lists.pjsip.org/mailman/listinfo/pjsip_lists.pjsip.org
>
>
> _______________________________________________
> Visit our blog: http://blog.pjsip.org
>
> pjsip mailing list
> pjsip at lists.pjsip.org
> http://lists.pjsip.org/mailman/listinfo/pjsip_lists.pjsip.org
>
>




More information about the pjsip mailing list