Subject: RE: [SIP] Adding tags across reboots.

From: "Fairlie-Cuninghame, Robert" <[email-masked]>
Date: Thu, 20 Jul 2000 09:16:45 -0700

But in the scenario I described you would still be adding a tag to a URL
that didn't have one before (because the From URL never originally had a
tag) - thereby changing the call leg identifiers. 

Robert.

> -----Original Message-----
> From: Henning Schulzrinne [mailto:[email-masked]]
> Sent: Friday, July 21, 2000 12:10 AM
> To: Fairlie-Cuninghame, Robert
> Cc: [email-masked]'
> Subject: Re: [SIP] Adding tags across reboots.
> 
> 
> 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.
> 
> 
> "Fairlie-Cuninghame, Robert" wrote:
> > 
> > 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
> 
> -- 
> Henning Schulzrinne   http://www.cs.columbia.edu/~hgs
> 
> 
> _______________________________________________
> SIP mailing list
> [email-masked]
> http://lists.bell-labs.com/mailman/listinfo/sip
> 

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

---

From: "Brett Tate" <[email-masked]>
Date: Thu, 20 Jul 2000 21:29:02 -0400

The best thing to do is add a tag in the From header 
of the original INVITE.  And yes I wish that it was 
mandatory or that RFC2543 mention the 
potential for problems if the tag isn't added.

Another way is to set the Contact header of the 
original INVITE to be of a value which would 
distinguish an incoming re-INVITE from incoming 
INVITE.