[OpenSIPS-Users] Message compression in OpenSIPS 1.12

Bogdan-Andrei Iancu bogdan at opensips.org
Wed Sep 3 11:49:01 CEST 2014


On 03.09.2014 11:59, Saúl Ibarra Corretgé wrote:
> Hi Razvan,
>
> On 02 Sep 2014, at 18:25, Răzvan Crainea <razvan at opensips.org> wrote:
>
>> 2)Compressing the SIP message (using gzip). The idea is to take the SDP body and several headers that are not used in the routing logic, compress them, apply a base64 transformation and add to the message's body. A use case for this is a platform that has several edge servers (SBCs) and a few core instances - when entering the platform the message compression should be applied and then sent to the core servers. Inside the core networks, the messages should be carried in the compressed format to reduce the bandwidth. When leaving the network, the message has to be decompressed and forwarded to the next gateway without any compression, since the other equipments might not understand them.
>> There will be several functions exported in the script:
>>
>>     a) compress_msg("1","Header1|Header2"); compresses the body of the message and listed headers
>>     b) decompress_msg(); decompress both headers and body
>>
>> What do you think about this approach? Is this something you find useful? Since we don't have a final decision for this topic, we are looking for more input from you guys.Anybody is welcome to throw any kind of useful feedback on this matter, so don't be shy!
>>
>
> IIRC this is not standard, and Apple uses it somewhere on their FaceTime implementation. Kamailio has it and someone was working on a patch for PJSIP, but other than that I’m not sure how useful it is, servers could use TCP between them.
It is not indeed, but the main idea is to first help you with better 
handling traffic inside your network (which may be up to 3 or 4 OpenSIPS 
boxes when you have a distributed platform) ; handling means bandwidth 
and processing as parsing SIP messages - like headers (maybe 20) or body 
you do not care about and you just want to carry through without a need 
to parse and look.

And maybe in the future it will be some progress into 
standardization....for now I see the real need for it (at least for me:) ).

Regards,
Bogdan



More information about the Users mailing list