Re: [Sip] Comments on draft-ietf-sip-compression-01.txt

[Gonzalo Camarillo <[e-mail]>]

Hisham,

inline:

[e-mail] wrote:
> 
> - Section 4: it says:
> 
> "If a client sends a compressed request, it SHOULD add the parameter
>    comp=sigcomp to the topmost entry of the Via header field."
> 
> Why isn't that so also for proxies?


Where did you read that proxies are not clients?


 
> Section 5: Second and third paragraph. What is the purpose of this? If I understand correctly, it is to allow the UAC sending compressed requests within this dialog. But this doesn't work.
> 
> Consider this scenario
> 
> UA1 --- P1 --- P2 --- P3 --- UA2
> 
> P1 wants to compress
> P2 doesn't want to compress
> P3 wants to compress
> 

When you provide an example like this, you should indicate on which
interface each SIP entity wants to compress. In fact, the purpose of the
paragraph you are referring to, is to avoid asymmetrical compression.
That is, if SIP messages from P1 to P2 are compressed, messages from P2
to P1 will be compressed as well.

In an example like this, you also have to define if, regardless of waht
they want, they support SigComp or not. I assume that they all support
it.

> They all record-route
> 
> Initial INVITE from UA1 is not compressed. So INVITE arrive at UA2 looking like this:
> 
> INVITE: sip:[e-mail] SIP/2.0
> via: p3
> via: p2
> via: p1
> via:ua1
> Record-route: <p1;comp=sigcomp> , <p2> , <p3;comp=sigcomp>
> contact: ua1
> ...

A proxy adding sigcomp to the Record-route will add it to the Via header
as well. Therefore the Vias in your example are likely to be different.
But anyway, let's focus on the R-R header.

If the proxies have record-routed like this, it is because they want the
following scenario:

UA1 --- P1 -c- P2 --- P3 -c- UA2

--- means no compression
-c- means SigComp

 
> Response from UA2 to P2 looks like:
> 

It should be UA2 to *P3* (not P2). And the Via headers are wrong again.

> SIP/2.0 200 Ok
> via: p2
> via: p1
> via:ua1
> Record-route: <p1;comp=sigcomp> , <p2> , <p3;comp=sigcomp>
> ...

You do not mention the Contact header in the response, which would be
ua2;comp=sigcomp

Therefore, you already have bidirectional compression between P3 and
UA2, which was what you wanted.

> 
> According to the above mentioned paragraphs, P3 removes its comp=sigcomp and forwards response to P2:
> 
> SIP/2.0 200 Ok
> via: p1
> via:ua1
> Record-route: <p1;comp=sigcomp> , <p2> , <p3>
> ...

Here you have bidirectional NO compression between P2 and P3, which is
what you wanted.

> 
> Again P2 applies the same logic, but this time adds comp=sigcomp, therefore making the response sent to P1 look like
> 
> SIP/2.0 200 Ok
> via:ua1
> Record-route: <p1;comp=sigcomp> , <p2;comp=sigcomp> , <p3>

Here you have bidirectional compression between P1 and P2, which was
what you wanted.

 
> and finally P1 will remove comp=sigcomp. Record-Route header looks like
> 
> Record-route: <p1> , <p2;comp=sigcomp> , <p3>

Here you have bidirectinal NO compression between UA1 and P1, which was
what you wanted.

> 
> That is not the desired behaviour.

This *IS* the intended behaviour if the proxies Record-Routed in the
request in the way you described it.

> The requirement should be that each proxy that record-routes examines the contact-header sent in the request and add/remove comp=sigcomp in the record-route header of the response. In this way, if the UAC wishes for requests within dialogs to be compressed, it indicates so in the contact-header.
> 

This mechanism allows compression between proxies as well. That's why
you have to inspect the RR headers as well.

Regards,

Gonzalo
_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [e-mail] for questions on current sip
Use [e-mail] for new developments on the application of sip