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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.pjsip.org/pipermail/pjsip_lists.pjsip.org/attachments/20090703/2afd4427/attachment-0001.html>
