Subject: [Sip] Re: SIP and SigComp draft comment.

From: Gonzalo Camarillo <[email-masked]>
Date: Mon, 08 Jul 2002 13:31:13 +0300

Adam,

What you are describing is what I meant the draft to say. In addition, I
also agree with you that some clarification is needed, so I will add
some text about it.

Below you have the last paragraph of section 3. This paragraph deals
with a proxy/UAC sending the first INVITE:
"Regardless of whether the request is sent compressed or not, if a
   client would like to receive subsequent requests within the same
   dialog compressed, this client SHOULD add the parameter comp=sigcomp
   to the URI in the Contact header field if it is a user agent client.
   If the client is a proxy, it SHOULD add the parameter comp=sigcomp to
   its URI in the Record-Route header field."

the paragraph above is supposed to address what you reffer to as "a
proxy tailoring its Record-Route entry for B". I believe that if we do
the following addition the paragraph would be clearer.

OLD:
... requests within the same dialog compressed.

NEW:
... requests within the same dialog in the UAS->UAC direction
compressed.

I will also add that if a proxy/UAC sends a request compressed (e.g., a
proxy to a wireless terminals that had REGISTERED a comp=sigcomp SIP
URI), it SHOULD add comp=sigcomp to its RR entry.

The paragraph below is the second paragraph of section 4:
"  A proxy performing Record-Route inspects the Record-Route header
   field in the response and the Contact header field in the request
   that triggered this response (see example in Section 7). It looks for
   the URI of the next upstream (closer to the user agent client) hop in
   the route set. If this URI contains the parameter comp=sigcomp, the
   proxy SHOULD add comp=sigcomp to its entry in the Record-Route header
   field."

The paragraph above is supposed to address the rewriting of the
Record-Route entry in order to make it suitable for A's consumption. Let
me know if you think something should be clarified.

With the clarifications above, the example you gave will work just fine.

Some people have expressed concerns about the meaning of comp=sigcomp.
In the current draft it means *willingness* (clarification will be
added), whereas folks have proposed that it should mean only *support*.

If the parameter meant support, in scenarios like the one Adam showed:

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

P2 would know that P1 and P3 supported sigcomp, but it would have no
data available to make the decision about whether or not to send
compress messages towards both proxies. However, if the parameter means
willingness, it will be clear for P2 that it does not need to compress
any message. 

And talking into consideration that wireless terminals (3G or not) will
typically REGISTER a comp=sigcomp SIP URI, the last proxy (i.e., P3)
will typically know that it has to RR with comp=sigcomp in the first
INVITE when it consults the registrar.

Thanks for the feedback,

Gonzalo

Adam Roach wrote:
> 
> 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