Hi Benny Locally here in South Africa and many developing nations where bandwidth cost is 3 to 10 times the norm, the first question in VOIP proposals is bandwidth. I found the following drafts with similar ideas, http://tools.ietf.org/html/draft-ietf-avt-mux-rtp-00 expired : Feb 21, 1999 draft-tanigawa-rtp-multiplex-00.txt Expires: December 16, 1998 These did not make it as standards. RFC 4170 Tunneling Multiplexed Compressed RTP November 2005 This is the Best Current Practice, although I could not find any actual implementations on the net. I think in a world where the internet is getting faster and cheaper by the day, most people are not concerned about the waste in small VOIP packets. For those who are interested in reducing bandwidth, here is some of my calculations. Codec Mux Mini RTP Header Full RTP Pack # channels in # channels in # channels in Codec bit rate Mux config same pipe same pipe same pipe 8kbps 8 ch * 40ms 2.55 2.57 2.10 8kbps 12 ch * 40ms 2.65 2.66 2.14 6kbps 8 ch * 40ms 2.97 2.99 2.33 6kbps 12 ch * 40ms 3.11 3.13 2.38 4kbps 8 ch * 40ms 3.70 3.74 2.68 4kbps 12 ch * 40ms 3.95 3.97 2.76 Mini RTP, and Full RTP pack refer to above drafts requiring extensive protocol changes. Codec Mux can be implemented in specific applications(branch to branch communications) without changes to the SIP protocol stack. Using a multiple channel codec mux that calls underlying codecs, and a application that is aware of this codec ability, the application can set-up a SIP link for as many channels as it needs. DTMF events (and maybe other things) may require special attention. Anyone that would like to share in such a project is welcome to contact me. Will keep you posted. Regards Lafras ----- Original Message ----- From: "Lafras Henning" <lafras@xxxxxxxxxx> To: "pjsip embedded/DSP SIP discussion" <pjsip at lists.pjsip.org> Sent: Wednesday, October 03, 2007 10:56 PM Subject: Re: [pjsip] SIP trunking Hi Benny, >It will increase latency and make it more prone to packet loss of >course, but I guess that's the price you'll have to pay for having l>less bandwidth. Well that is exactly the point, We want communications with less latency, less bandwidth and less noticeable packet loss, If a user is trunking 8 channels of VOIP to a TISP, we can reduce the bandwidth AND/OR latency per channel by packing. >What would you save by combining SIP and RTP into a single transport? I do not suggest we combine SIP and RTP, I suggest we combine packets going to the same destination/proxy irrespective of protocol, if this happens to be SIP and RTP combined then all the better. In fact SIP and RTP may still be best served going to separate destination/proxies as they do now. If I can take my 8 channels and squeeze them into the same space as three.three channels, as per your calculation example, (and get the same or better latency) I'll will take it any day. Especially if my a TISP only needs a B2BUA to comply. Packet loss would improve in narrow pipes as less data is sent. To reduce latency we can use codecs with smaller sample buffers and pack more channels. Packet loss would be better as 8 separate users would notice 1/8 loss each, less than a single user with 1/1 loss would notice. For best QOS in larger trunks(100+), sending a few G711 samples per channel could bring SIP to PSTN quality in terms of latency. All this within the SIP protocol. >IAX saves bandwidth because it modifies the protocol, AFAIK. IAX cannot compress voice much more than or even as much as speex. The verbose SIP protocol would compress very nicely (probably close to IAX overhead %) with standard lossless data compression algorithms. Regards Lafras ----- Original Message ----- From: "Benny Prijono" <bennylp@xxxxxxxxx> To: "pjsip embedded/DSP SIP discussion" <pjsip at lists.pjsip.org> Sent: Wednesday, October 03, 2007 9:16 PM Subject: Re: [pjsip] SIP trunking Hi Lafras, please excuse the lack of deep analytical review to your proposal, by I think the idea is silly. What would you save by combining SIP and RTP into a single transport? IAX saves bandwidth because it modifies the protocol, AFAIK. There is one thing that you could do, within the standard, to reduce the overhead, that is to pack multiple codec frames into one RTP packet. Lets see how much we could gain by doing so: Assuming an 8Kbit/s (1KByte/s) codec is used (and overhead is 40 bytes per packet for IP+UDP+RTP headers): #frames Header-bandwidth Overhead Total b/w 1 40x50=2000 200% 24 Kb/s 2 40x25=1000 100% 16 Kb/s 4 40x12.5=500 50% 12 Kb/s 6 40x9.3=333 33.3% 10.6 Kb/s 8 40x6.25=250 25% 10 Kb/s I guess it doesn't look too bad anymore, say with 4 frames per RTP. It will increase latency and make it more prone to packet loss of course, but I guess that's the price you'll have to pay for having less bandwidth. Btw in pjmedia you set the number of frames per packet by specifying it in pjmedia_stream_info.param->setting.frm_per_pkt. But IIRC it currently only works for g711, which kinda defeat the purpose. :) cheers, -benny Lafras Henning wrote: > Hi Benny, > A general VOIP question, > > I see in the internet a lot of reference to SIP trunking, but this refers to > just using normal SIP to communicate a number of channels to a TISP. > > IAX/2 fills a niche mainly to optimise bandwidth by sharing IP overhead. > Needed when in high compression codecs, overhead is 50% of the traffic. > Surely we don't need a totally different protocol to do this? > It would be better to concatenate SIPand RTP packets (going to a single > destination/proxy) > into a single UDP/TCP/TLS payload with change to the transport layer of > the SIP stack (and publish a RFC on it). > > - The main objective is to share headers. > - Optionally some SIP content compression could be added. > - I don't think RTP content compression would have much benefit(can't > beat speex :). > - Implemented in the transports layer. > > Or do you think the gains would be inconsequential? > > Or do you think such is better left for external solutions such as VPN - > although I don't think that would allow for optimal bandwidth solution. > > Or is it a stupid idea? > > If not let's call this SIPTP - SIP Trunk Protocol - logical hey? > > Not to be confused with > trans-di-?-hydridobis(silyl)bis(trialkylphosphine)di-platinum complexes > (SiPtP)2 - > and we thought programmers were geeks! ;) > > Regards > Lafras > > > > > ------------------------------------------------------------------------ > > _______________________________________________ > 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 -- Benny Prijono http://www.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 _______________________________________________ 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
