RE: SigComp Requirements (was Re: [rohc] RE: Default decompressio n algorithms)

["Lars-Erik Jonsson (EPL)" <[e-mail]>]

Miguel,

Here are some immediate comments on these requirements.

Cheers,
/L-E



6.5 Compression of SIP signaling 
    
   As the radio interface is a scarce resource, the transport of SIP 
   messages over the radio interface must be done efficiently. 
    
   Therefore, there must be a mechanism to efficiently transport SIP 
   signaling packets over the radio interface, by compressing the SIP 
   signaling messages between the UA and the SIP outbound proxy, and by 
   compressing the IP and transport layer protocol headers that carry 
   these SIP messages. 
   
-> LEJ: Yes, this is why we do SigComp, in addition to link-layer
   IP/UDP header compression.
    

6.5.1 Extensibility of the SIP compression 
    
   The chosen solution(s) must be extensible to facilitate the 
   incorporation of new and improved compression algorithms in a backward 
   compatible way, as they become available.

-> LEJ: The UDVM approach should fully meet this requirement. 
    
    
6.5.2 SIP compression and roaming 
    
   The chosen solution(s) for SIP compression must work in roaming 
   scenarios. 
    
-> LEJ: This was one of the reasons we decided to do compression end2end (not per link).
    

6.5.3 Minimal impact of SIP compression on the network 
    
   Application specific compression must minimize impacts on existing 
   3GPP network, e.g. the compression must be defined between the UA at 
   the SIP terminal and the outbound SIP Proxy in the visited network.

-> LEJ: Luckily, there were also technical arguments for placing SigComp at
   the application layer (UA<->Proxy). 
    
    
6.5.4 Optionality of SIP compression 
    
   It must be possible to leave the usage of compression for SIP 
   signaling optional. 

-> LEJ: No problem, we do not expect everyone to suddenly use compressed SIP.
    
    
6.5.5 Default algorithm for SIP compression 
    
   If SIP signaling compression is used, a default algorithm must be 
   supported by the UA and the network elements involved for compression. 
    
-> LEJ: Why?? We are currently having a discussion about this on the list, 
   and we will see what the outcome will be. ROHC is not at all discussing
   algorithms, and will therefore not define any default algorithm. What is
   still under consideration is whether we should provide mechanisms to
   announce decompressor-supported algorithms. However, the usefulness of
   this is still not clearly proven, and if we want to support this we must
   consider the security aspects of it and the added complexity of the 
   solution. 

    
6.5.6 Compression Negotiation 
    
   There must be a mechanism to negotiate between the UA and the first 
   SIP outbound proxy the compression algorithm to be used. The type of 
   negotiation mechanism that should be implemented is that the UAC 
   includes a list of compression algorithms and the first SIP outbound 
   proxy responds with the selected one. Subsequent SIP messages are 
   compressed based on the agreed algorithm.

-> LEJ: This is not a requirement, its is a proposed solution/mechanism.
   Further, only the Proxy->UA traffic direction is addressed above.



> 
> A group of individuals collected the 3GPP requirements 
> related to SIP and
> write them down in an Internet Draft,
> 
> http://search.ietf.org/internet-drafts/draft-garcia-sipping-3g
> pp-reqs-02.txt
> 
> Version -03 is on its way and will be submitted before the 
> deadline to MN.
> 
> I will encourage to read the actual section 6.5 in that 
> document. There are
> several requirements affecting compression.
> 
> I will also recommend to read requirements 6.1.1 and 6.1.2. 
> Although these
> are general requirements, they are applicable to all the rest of the 
> requirements and possible solutions.
> 
> /Miguel

_______________________________________________
Rohc mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/rohc