[pjsip] SIP trunking

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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





[Index of Archives]     [Asterisk Users]     [Asterisk App Development]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Security]     [Bugtraq]     [Linux]     [Linux OMAP]     [Linux MIPS]     [Linux API]
  Powered by Linux