Subject: [sipcore] Keep issue

From: "Christer Holmberg" <[email-masked]>
Date: Wed, 12 Aug 2009 13:46:32 +0200

Hi,

In Stockholm there was concensus to use the Contact/Path/Record-Route
headers for negotiating keep-alive, instead of the Via header.

There is a problem, however:

Assume a UA sends an INVITE, and inserts "keep" in the Contact header.
The UA will not get back that Contact header in any response (the
response will contain the Contact of the remote user), so it will not
see if the next hop has added "=yes" to the parameter, indicating it
wants the UA to send keep-alives towards it.

The problem does not exist for Path and Record-Route, which will be used
by proxies to indicate willingness to support keep-alive, since those
headers always "come back" in the response.

Now, going back to Via is probably not a good idea, because then we
again end up with the problem which was the reason not to use Via.

One alternative is to not add "=yes" to the keep parameter inserted by
the previous hop, but that the entity which wants to receive keep-alive
indicates so in the header inserted by itself.

Example:

UAC                          P1                           UAS

---- INVITE ----------------->
     Contact: UA; keep-s
//indication that the UAC supports sending of keep-alives

                                  ---- INVITE ----------------->
                                  Contact: UAC; keep-s
                                  R-R: P1; keep-r, keep-s
//indication that P1 supports receiving of keep-alives from the UAC, and
that it supports sending of keep-alives

                                  <--- 200 -----------------------
                                  Contact: UAS
                                  R-R: P1; keep-r, keep-s
//the UAS does not want to receive keep-alives from P1, so it does not
insert an indication in its own Contact

<--- 200 -----------------------
      Contact: UAS
      R-R: P1; keep-r, keep-s				//even if the
UAC doesn't get back its own Contact, it can see from the R-R that P1
wants to receive keep-alives

The advantage of this alternative is that an entity will not modify a
parameter (by inserting the "=yes" value) inserted by someone else.

Regards,

Christer