You could probably create something like this using oSip and oRtp, or one of the many tunnelling products out there (realtunnel says it supports sip tunnelling, but I've never tried it, and http-tunnel says they're working on UDP for things like SIP), but there are a couple of problems with that. 1) Even the cheap firewalls these days are becoming SPI firewalls. In this situation, packets over the http port that aren't ACTUALLY http packets are liable to be disallowed as a matter of course. 2) When doing rtp transmissions over http, there's no way to regulate the call quality in relation to the other http traffic. You'll almost certainly end up in situations where call quality is suffering because of other traffic on the http realm. For now, check out some of the tunnelling solutions and see how they work. An alternative might be to tunnel SIP over http and RTP over the less-used HTTPS toward an outbound proxy of some sort. RTP through firewalls will ALWAYS be the biggest problem because it tends to deal in port ranges instead of single ports (the hazards of multiple streams). I'm hoping, though, as time goes on, people start to expect SIP in much the way they expect IM functionality to work and just open up firewalls to allow it on a more regular basis (assuming the increase in number of SIP-aware firewalls). If you have any luck with the tunnelling, though, I'd love to hear about it. With Skype's protocol doing autotunnelling and basic NAT traversal, it often makes it a more appealing protocol than SIP to consumers.  SIP can now handle NAT traversal in one form or fashion, but its inability to bounce through alternate ports to traverse firewalls is... limiting. N. On Fri, 9 Dec 2005 16:23:09 -0800, Imran Akbar wrote