Subject: [Sip] SIP and SigComp draft comment.

From: Adam Roach <[email-masked]>
Date: Tue, 25 Jun 2002 18:25:44 -0400

There has been a bit of discussion about how to handle
Contact, Route, and Record-Route with the "comp=sigcomp"
parameter.

There's a closely related issue that hasn't yet been touched
on, though: when the called party issues a request, the
"comp=sigcomp" headers end up being essentially in the wrong
place.

I'll demonstrate by way of an example.

+---+   +----+   +----+   +----+   +---+
| A |...| P1 |---| P2 |---| P3 |...| B |
+---+   +----+   +----+   +----+   +---+

A and B are wireless terminals with very low bandwidth
links (and, consequently, use SigComp). P1, P2, and P3 are
all proxies on the network.

A sends an INVITE to B. Assuming that each proxy
inserts its record-routes so that A gets the proper
route-set, you get the following at B:

Record-Route: <sip:abcdef@p3>
Record-Route: <sip:uvwxyz@p2>
Record-Route: <sip:123456@p1;comp=sigcomp>
Contact: <sip:usera@A;comp=sigcomp>

This is, of course, stored in B as the route set:
  <sip:abcdef@p3>,<sip:uvwxyz@p2>,<sip:123456@p1;comp=sigcomp>,
  <sip:usera@A;comp=sigcomp>

The response to the request delivers the same set of Record-Routes
to A, but with a contact of "sip:userb@B;comp=sigcomp":
  <sip:123456@p1;comp=sigcomp>,<sip:uvwxyz@p2>,<sip:abcdef@p3>,
  <sip:userb@B;comp=sigcomp>

So, A's route is absolutely correct; it will compress the message
sent to P1, and P3 will compress the message sent to B. Unfortunately,
B's route is really screwy. If it obeys the "comp" parameters, B
*won't* compress any requests in this dialog, so you'll be sending
uncompressed messages over the radio link. And, in a bitter irony,
P2 will waste cycles compressing the messages sent to P1 -- which
turns out to be completely unnecessary. In fact, it exacerbates the
fact that the B -> P3 request was sent uncompressed.

If we have the proxies tailor the route set for B, the same problem
happens, in the opposite direction.

The solution lies in step 8, detailed in section 16.7 of
2543bis-09.

In this case, the proxies would tailor the inserted "Record-Routes"
in the request for B's consumption:

Record-Route: <sip:abcdef@p3;comp=sigcomp>
Record-Route: <sip:uvwxyz@p2>
Record-Route: <sip:123456@p1>
Contact: <sip:usera@A;comp=sigcomp>

Then, as the INVITE response passes back through P3 and P1, they
would each modify the Record-Route headers so that they are
appropriate for A's consumption:

Record-Route: <sip:abcdef@p3>
Record-Route: <sip:uvwxyz@p2>
Record-Route: <sip:123456@p1;comp=sigcomp>
Contact: <sip:userb@B;comp=sigcomp>

Even though it's described in SIP, this usage should probably be
explicitly mentioned in in the SIP SigComp draft; otherwise, we
run the risk of having nodes do strange things.

/a

_______________________________________________
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: "Vijay K. Gurbani" <[email-masked]>
Date: Thu, 27 Jun 2002 11:49:00 -0500

Inline.

> I'll demonstrate by way of an example.

Adam:

Correct me if I am mistaken, but won't it be best (since in your
scenario, P3 supports sigcomp) for P3 to simply indicate it's sigcomp
support in the R-R going downstream, leaving P1's R-R alone.  Thus, the
R-R list from P3 will contain:

The Route list is now congruent on both ends; B knows that it can
compress the request across the first hop (P3) as does A (first hop for
it is P1).

This way, no re-writing of R-R's is necessary in the response.  If
P3 is a stateless proxy for instance, it may not be able to correlate
the response to the request for R-R re-writing.

> run the risk of having nodes do strange things.

I believe step 8 of Section 16.7 of -09bis assumes that a proxy is
modifying *it's* own R-R in a response that it inserted in the earlier
request, not someone else's (although, no harm is done if the 'foreign'
R-R is duplicated faithfully in the response).

Regards,

- vijay
-- 
Vijay K. Gurbani  vkg@{lucent.com,research.bell-labs.com,acm.org}
Wireless Networks Group/Internet Software and Services
Lucent Technologies/Bell Labs Innovations, 2000 Lucent Lane, Rm 6G-440
Naperville, Illinois 60566     Voice: +1 630 224 0216