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
