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

From: [email-masked]
Date: Mon, 23 Sep 2002 17:36:47 +0300

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

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

They all record-route

Initial INVITE from UA1 is not compressed. So INVITE arrive at UA2 looking like this:

INVITE: sip:[email-masked] SIP/2.0
via: p3
via: p2
via: p1
via:ua1
Record-route: <p1;comp=sigcomp> , <p2> , <p3;comp=sigcomp>
contact: ua1
...

Response from UA2 to P2 looks like:

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

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

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>

and finally P1 will remove comp=sigcomp. Record-Route header looks like

Record-route: <p1> , <p2;comp=sigcomp> , <p3>

That is not the desired behaviour. 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.

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

---

From: Gonzalo Camarillo <[email-masked]>
Date: Tue, 24 Sep 2002 08:55:14 +0300

Hisham,

inline:

> Why isn't that so also for proxies?

Where did you read that proxies are not clients?

> P2 doesn't want 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.

> Record-route: <p1;comp=sigcomp> , <p2> , <p3;comp=sigcomp>

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.

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

> Record-route: <p1;comp=sigcomp> , <p2> , <p3>

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

> Record-route: <p1;comp=sigcomp> , <p2;comp=sigcomp> , <p3>

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

> 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