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 > > > On Mon, Jun 29, 2009 at 2:18 PM, Klaus Darilion > <klaus.mailinglists at pernau.at <mailto: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 <mailto: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 <mailto: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
