Subject: [SIP] Adding tags across reboots.

From: "Fairlie-Cuninghame, Robert" <[email-masked]>
Date: Thu, 20 Jul 2000 04:58:25 -0700

I have two queries, the first is about the handling of received INVITE's
when you have no call state (affecting robustness after crash); the second
more serious query is about handling BYE, CANCEL, INFO requests when you
have no call state.

In Section 1.5 (point 1)  there is a whole paragraph devoted to behaviour of
clients that wish to be robust across a crash. 

Consider the following scenario: UA1 sends INVITE (with no To or From tags)
to UA2. UA2 adds a To tag in the 200Ok response and this is used in all
subsequent transactions by both UA's as per RFC.

Now UA1 crashes and reboot. UA2 sends a re-INVITE to UA1 (perhaps due to
Session Timer). This re-INVITE will have a From tag but no To tag and UA1
will treat the re-INIVTE as new call, correct? Thus, it will then add
_another_ To tag (in what was originally the From field). 

Should UA2 match this 200Ok response to the existing call ? No, you can't
change the From tag mid-call. So in this situation you can't recover from a
crash, right ? So how do you handle this ? [Distinguishing an INVITE from a
re-INVITE without call state]. I have one suggestion at the end of this
email.

Now, what about handling _non-INVITE_ requests after a crash. In Section
6.44 (To), it says that a UAS must place a tag on all final responses to all
transactions within a call leg. And Section 11 is unclear on what to do.

Let's consider the same scenario described above except when UA1 receives a
BYE from UA2 after a crash (which is probably much more likely). This
scenario extends to whenever you receive a BYE, INFO, CANCEL or similar
post-INVITE request - whenever you would want respond with a 481 Not
exist(ie no call state).

UA1 should return a 481 request when it receives the BYE/INFO/CANCEL but
once again if it was to place a To tag in the 481 response then UA2 would
not be able to match the response to the request. 

I think the spec should be clarified in Section11 as to the behaviour when
BYE/INFO/CANCEL/etc responses are received but no call state exists.
Is the correct behaviour NOT to add a To tag when issuing a 481? Can anyone
think of some way in which this will affect forking proxies - I beleive it
should be okay as these requests do not relete to call establisment.

One solution that would fix all these problems is to make a From tag
mandatory in INVITE's (even if it is just tag=0) so that a new tag will not
be added, however this is a fairly heavy burden.

Any other ideas?

Robert.

_______________________________________________
SIP mailing list
[email-masked]
http://lists.bell-labs.com/mailman/listinfo/sip

---

From: Henning Schulzrinne <[email-masked]>
Date: Thu, 20 Jul 2000 12:09:41 -0400

One possibility is to make the From/To tags constant across reboots and
only dependent on the system identity, not its incarnation index. For
example, this could be a hash of the user id and a processor ID and MAC
address.

-- 
Henning Schulzrinne   http://www.cs.columbia.edu/~hgs