Hi Razvan,

On 02 Sep 2014, at 18:25, Răzvan Crainea <[email protected]> wrote:

> Hi all,
> 
> The first topic presented in the last public meeting[1] was related to 
> Message compression - the idea is to reduce the size of the SIP messages to 
> avoid UDP fragmentationor to save bandwidth and processing power.
> 
> This topic was split in two parts:
> 
> 1) SIP-wise changes over the messages (RFC3261 compliant -> supported by all 
> user agents)
>    a) function that converts all header names to the short form (i.e. From -> 
> f, Call-ID -> i, etc.). A single function will be exported in the script that 
> will be called for the requests that should use the short form.
>    b) function that joins together headers that support multiple bodies (i.e. 
> Record-Route, Via, Contact, etc.). There will be a function that indicates 
> whether the outgoing request should merge these headers in a single one. An 
> example of usage is when having two Via headers such as the following example:
> 
> Via: SIP/2.0/UDP bigbox3.site3.atlanta.com;branch=z9hG4bK77ef4c2312983.1
> Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKnashds8
> 
> These headers will be merged in a single header:
> 
>    Via: SIP/2.0/UDP bigbox3.site3.atlanta.com;branch=z9hG4bK77ef4c2312983.1, 
> SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKnashds8
> 
>    c)delete irrelevant headers: create a new function that is used to delete 
> certain headers that are not mandatory in the SIP protocol. By default, all 
> headers but the mandatory ones are deleted. However, the function should 
> receive a headers whitelist as a parameter: a list of headers that should not 
> be deleted because they might be useful for the platform or end-users.
> 
>    comp_delete_headers("X-Source-IP|User-Agent|Date");
> 
>    d) remove redefined SDP attributes: provide a function that removes 
> attributes that are redefined for some of the static codecs. For example, 
> consider the following SDP:
> 
>    m=audio 49230 RTP/AVP 0 98
>    a=rtpmap:0 PCMU/8000
>    a=rtpmap:98 L16/11025/2
> 
> The SDP above can be suppressed to the following form:
> 
>    m=audio 49230 RTP/AVP 0 98
>    a=rtpmap:98 L16/11025/2
> 
> 

I think this is a good idea. I actually have ran into this not so long ago :-) 
Of course the solution would be to switch to TCP, but well, not everyone can do 
that...


> 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.


Regards,

--
Saúl Ibarra Corretgé
AG Projects



Attachment: signature.asc
Description: Message signed with OpenPGP using GPGMail

_______________________________________________
Users mailing list
[email protected]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

Reply via email to