IETF Logo Mail Archive

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

hisham.khartabil@nokia.com Mon, 23 September 2002 14:40 UTC

Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA10956 for <sip-archive@odin.ietf.org>; Mon, 23 Sep 2002 10:40:49 -0400 (EDT)
Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g8NEgCG15308 for sip-archive@odin.ietf.org; Mon, 23 Sep 2002 10:42:12 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g8NEeHv15257; Mon, 23 Sep 2002 10:40:17 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g8NEcwv15169 for <sip@optimus.ietf.org>; Mon, 23 Sep 2002 10:38:58 -0400
Received: from mgw-x1.nokia.com (mgw-x1.nokia.com [131.228.20.21]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA10745 for <sip@ietf.org>; Mon, 23 Sep 2002 10:37:04 -0400 (EDT)
From: hisham.khartabil@nokia.com
Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37]) by mgw-x1.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g8NEcmT19793 for <sip@ietf.org>; Mon, 23 Sep 2002 17:38:48 +0300 (EET DST)
Received: from esebh004.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id <T5d843de86bac158f25147@esvir05nok.ntc.nokia.com> for <sip@ietf.org>; Mon, 23 Sep 2002 17:36:48 +0300
Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Mon, 23 Sep 2002 17:36:48 +0300
X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Date: Mon, 23 Sep 2002 17:36:47 +0300
Message-ID: <2038BCC78B1AD641891A0D1AE133DBB7C20665@esebe019.ntc.nokia.com>
Thread-Topic: Comments on draft-ietf-sip-compression-01.txt
Thread-Index: AcJjDqVOE6xYHbcvRe6Lbt4c59WJ+Q==
To: sip@ietf.org
X-OriginalArrivalTime: 23 Sep 2002 14:36:48.0047 (UTC) FILETIME=[A5B32BF0:01C2630E]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id g8NEcwv15172
Subject: [Sip] Comments on draft-ietf-sip-compression-01.txt
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>, <mailto:sip-request@ietf.org?subject=unsubscribe>
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>, <mailto:sip-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 8bit

- 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:ua2@example.com 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 sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip

v2.23.0 | Report a Bug | By Email