Subject: Re: UAC use of tags received in responses

From: Jonathan Rosenberg <[email-masked]>
Date: Fri, 03 Mar 2000 00:30:36 -0500

Anders Kristensen wrote:
> 
> Jonathan Rosenberg wrote:
> >
> > Anders Kristensen wrote:
> > >
> > > I'm not sure it's a problem, but this can give rise to curious
> > > situations when the the non-2xx final response was generated by a UAS.
> > > In this case the UAS has inserted a To tag and hence believes the call
> > > consists of a single leg, whose UAS identifier (the To of the original
> > > request) has a tag.
> > >
> > > The UAC ACKs the response (ACK includes To tag) and resubmits the
> > > request *without* To tag. This basically constitutes initiating a new
> > > transaction in a new leg.
> > >
> > > Now I'm not sure if it's well-specified whether the UAS will associate
> > > that new request with the existing leg (which has a To tag). I think
> > > this would (or should) be the correct behaviour, as it really is the
> > > same leg, but I would imagine that different implementations might
> > > differ on this point. The consequence is that the second response (say a
> > > 2xx) may be returned with the *original* To tag.
> >
> > Hmm. I don't think this would happen. If the UAS receives a request and
> > sends a non-200 response with a tag, the call leg is over. It doesn't
> > know whether it will ever receieve another request, so I imagine it will
> > flush the state, and thats it.
> 
> This would be true if it wasn't because the UAS has to keep transaction
> state hanging around for retransmissions - for a period of approximately
> 30 seconds. This is easily enough time for someone to manually type in a
> password and resubmit the request.
> 
> > When the new request arrives, it creates
> > a new call leg. The tag in the response will probably be different than
> > the previous, or it might be the same.
> >
> > On the UAC, this basically means it really can't associate a tag with
> > the call leg until the 200 OK. Before that, any tags it sees in
> > provisionals or non-200s might not be the final tag.
> 
> That might work, although it's a bit awkward. It's basically saying that
> the UAC shouldn't represent the initial leg as a real leg.

No, it can represent the initial leg as a real leg, and have a tag
associated with it that it learned from a provisional. However, if the
initial INVITE is rejected, the tag is basically "invalidated". You'll
launch a new INVITE (assuming the rejection was something like a 401)
without a tag.

> 
> >
> > > Maybe it should be clarified whether the UAS should respond to the
> > > second request with the old or a new To tag, and whether the UAC is
> > > supposed to think of the two requests as belonging to different legs?
> >
> > I don't think we can impose requirements on maintenance of state at a UA
> > after rejecting a new INVITE.
> 
> So you're saying that both behaviours are acceptable: if the UAS knows
> of the old leg it may or may not respond with the old tag, and it's up
> to the UAC to recognize that the response to the resubmitted request
> belongs to the new leg.  This seems like a reasonable solution to me,
> although it basically modifies the rule that a leg is identified by
> Call-ID, From, and To headers.

No, I don't think its changing this rule. You can almost think of the
new request as being on a new leg (in fact, one could conceivably even
use a new Call-ID for that resubmitted request - things will still work
just fine).

> 
> It is maybe worth noting that the UAC can address this problem
> differently by forcing the reissued request to belong to a different leg
> (by using a different From tag) or a different call (by using a
> different Call-ID). This denies the UAS (and proxies) the opportunity to
> recognize that the second request is related to the first, and so should
> be discouraged.

A good point.

-Jonathan R.

-- 
Jonathan D. Rosenberg                       200 Executive Drive
Chief Scientist                             Suite 120 
dynamicsoft                                 West Orange, NJ 07052
[email-masked]                     FAX:   (732) 741-4778
http://www.cs.columbia.edu/~jdrosen         PHONE: (732) 741-7244
http://www.dynamicsoft.com