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
