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
