Subject: UAC use of tags received in responses

From: Robert Sparks <[email-masked]>
Date: Thu, 10 Feb 2000 09:41:09 -0600

Currently, a proxy is required to add a tag to a response it generates
locally if the request did not contain one. A UAC is required to use
tags it sees in final responses (creating legs for each unique tag
received) in subsequent requests to that leg.

Taken together, these requirements destroy call progress in the case
of a 407 (and several other responses a proxy might generate that 
shouldn't necessarily clobber call progress, such as 500, 503, 504,
305, 400, 411, 413, maybe even 408).

Consider the following:

  UA A           Proxy        UA B
   |  INVITE       |            |
   |  To: B        |            |
   |  From: A      |            |
   |  CallID: 1    |            |
   |  CSeq: 1 INVITE            |
   |-------------->|            |
   |               |            |
   |  407          |            |
   |  To: B;tag=1  |            |
   |  From: A      |            |
   |  CallID: 1    |            |
   |  CSeq: 1 INVITE            |
   |<--------------|            |
   |               |            |
   |  ACK          |            |
   |  To: B;tag=1  |            |
   |  From: A      |            |
   |  CallID: 1    |            |
   |  CSeq: 1 ACK  |            |
   |-------------->|            |
   |               |            |
   |  INVITE       |            |
   |  To: B;tag=1  |            |
   |  From:A       |            |
   |  (appropriate credentials) |
   |  CallID: 1    |            |
   |  CSeq: 2 INVITE            |
   |-------------->|            |
   |               |            |
   |               | INVITE     |
   |               | To: B;tag=1|
   |               | From: A    |
   |               | CallID: 1  |
   |               | CSeq: 2 INVITE
   |               |----------->|

B MUST respond now with a 481 Call Leg/Transaction Does Not Exist -
There is no legal way for the session to be successfully established.

One of the two requirements above must be modified to allow for this
scenario. Changing the requirement on the proxy, having it not add tags
for some or all locally generated responses, leads to problems determining
the appropriate destination for the subsequent ACK (pointed out by Jonathan
Rosenberg). The better solution then (suggested by both Jonathan and Alan
Johnston) is to modify the behavior of the UAC such that:

   A UAC only copies a tag into subsequent requests if it arrives in a
   200 OK to an INVITE.

So, in the above sequence, the CSeq: 2 INVITE would have no tag.

Unless discussion here uncovers a problem with this approach, I propose
adding the above sentence to section 11.3 and changing the sentence in
Section 6.41 To:
from 
   All subsequent transactions between two entities MUST include
   the "tag" parameter, as described in Section 11.
to
   Section 11 details when the "tag" parameter MUST appear in subsequent 
   requests.

NOTE that even though a UAC doesn't use a tag it sees in non-200 responses
in subsequent requests, an implementation may need to keep them as part
of transaction state. An example is being able to associate 183s with
200s on a forked INVITE.

RjS

---

From: Jonathan Rosenberg <[email-masked]>
Date: Thu, 10 Feb 2000 17:11:28 -0500

>    A UAC only copies a tag into subsequent requests if it arrives in a

I would further clarify this:

     A UAC copies the tag from the response into the ACK, but it MUST
NOT
     copy the tag into any subsequent requests unless the response was
     a 200 class response to an INVITE.

Since ACK is a "subsequent" request after all.

-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

---

From: Robert Sparks <[email-masked]>
Date: Wed, 16 Feb 2000 13:18:07 -0600

Since there have been no other comments, the suggestion now
is to add the following to '11.3 Caller Receives Response to 
Initial Request':

   A UAC MUST copy the tag from a final response into the ACK of that
   response. The UAC MUST include that tag into all other subsequent
   requests if, and only if, the response was in the 200 class. The
   UAC MUST NOT include that tag in any subsequent requests beyond
   the ACK if the response was not in the 200 class.

and changing the sentence in Section 6.41 To:
from 
   All subsequent transactions between two entities MUST include
   the "tag" parameter, as described in Section 11.
to
   Section 11 details when the "tag" parameter MUST appear in subsequent 
   requests.

RjS

> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of Jonathan
> Rosenberg
> Sent: Thursday, February 10, 2000 4:11 PM
> To: [email-masked]
> Cc: 'SIP List' (E-mail); Henning Schulzrinne (E-mail)
> Subject: Re: UAC use of tags received in responses
> 
> 
> 
> 
> Robert Sparks wrote:
> >

---

From: Igor Slepchin <[email-masked]>
Date: Wed, 16 Feb 2000 15:05:45 -0500

Robert Sparks wrote:
> <...>
> The UAC MUST include that tag into all other subsequent
>    requests if, and only if, the response was in the 200 class. 

CANCEL is an exception from that rule. People also argued for allowing
BYE requests with no tag (though I am not very happy with the idea).

---
Igor Slepchin

---

From: Jonathan Rosenberg <[email-masked]>
Date: Thu, 17 Feb 2000 01:48:08 -0500

Igor Slepchin wrote:
> CANCEL is an exception from that rule. 

In theory, yes. However, the copy-the-tag-into-subsequent-requests rule
applies only after a 200 OK to INVITE has come. At that point, sending a
CANCEL is guaranteed to do nothing. So, there is no point in sending
one. If you did, you are right it should not contain a tag.

> People also argued for allowing

The same thing is true here with BYE. The issue is that people will be
sending BYE before the 200 OK (and thus the tag) has been established. 

Igor has a good point, though, that we should clarify that obviously
tags cannot be inserted into requests sent before the 200 OK to INVITE
comes.

-Jonathan R.

---

From: Jonathan Rosenberg <[email-masked]>
Date: Thu, 17 Feb 2000 12:20:33 -0500

Igor Slepchin wrote:
> One could theoretically CANCEL any request. A more practical example is
> a re-INVITE. Besides, UAC might want to send a CANCEL even after it got
> a 200 OK to cancel the search on forked branches that might still be
> outstanding.

Fair enough. However, I think that in the case of cancelling a
re-INVITE,
you do actually want the tag in the To field. I believe the CANCEL needs
to
match the request its cancelling, in terms of the To, From, Call-ID and
CSeq,
including tags. In the case of multiple call legs, if a re-INVITE were
sent on
each call leg, and then cancelled on each call leg, you might not be
able to distinguish 
the CANCELs except for the tag in the To field.

So, if this is OK, the proposed addition is:

"The exception to this is CANCEL. The CANCEL always contains exactly the
same value of the To field as the request it is cancelling."

-Jonathan R.

---

From: "Daniel G. Petrie" <[email-masked]>
Date: Thu, 17 Feb 2000 19:03:17 -0500

Sorry I could not resist these two questions.

What would one expect to happen when sending
a CANCEL to a ReINVITE:
  Cancel the transaction, leave the call up at the previously negotiated
capabilities.
 or
  Cancel the transaction, drop the call.

Why would someone want to do this?
Cheers,
Dan

---

From: Igor Slepchin <[email-masked]>
Date: Thu, 17 Feb 2000 20:43:40 -0500

>   Cancel the transaction, drop the call.

The former.
 
> Why would someone want to do this?

Media renegotiation might involve some user interaction and the caller
may want to give up on the re-INVITE if it does not complete within
certain time. For example, a re-INVITE may be sent when one of the call
participants wants to start video exchange. If the other side is capable
of supporting it, the user there might be prompted to see if he/she
agrees to activate video.

---
Igor Slepchin

---

From: Jonathan Rosenberg <[email-masked]>
Date: Fri, 18 Feb 2000 09:45:16 -0500

> agrees to activate video.

I'd also like to add to this that whilst CANCEL is most useful for
INVITE, it is a generic mechanism that can be applied to any request
(excepting CANCEL itself and ACK). In general, if you get a CANCEL for a
request for which you haven't sent a response, you should send a 487
response to the original request, 200 OK to the CANCEL, and then behave
as if the original request were never received.

-Jonathan R.

---

From: Robert Sparks <[email-masked]>
Date: Fri, 18 Feb 2000 09:29:01 -0600

This is like the case when the reINVITE ultimately
receives a non-200 final response (not including 401, 407
or responses that induce Retry-Afters leading in the end
to a reINVITE receiving a 200). 

I think that case has been discussed here (I know it has
been discussed at the bake-offs). Returning (if possible)
to the previous call state is the right approach. UA
implementations must be careful, however, with how they get
back to that state. A failed HOLD, for example, better not 
leave the user thinking the call is on hold while media is
still being sent to the other end. 

RjS

ps. More at the edge, if you have a reINVITE/200/ACK sequence
where the 200 contains "bad" SDP, yet another reINVITE will 
have to be issued to restore the call to the previous state (which
should have a high probability of success since the UAs agreed
to get that call into that state once before).

> [mailto:[email-masked]]On Behalf Of Igor
> Slepchin
> Sent: Thursday, February 17, 2000 7:44 PM
> To: Daniel G. Petrie
> Cc: Jonathan Rosenberg; [email-masked]

---

From: Anders Kristensen <[email-masked]>
Date: Thu, 24 Feb 2000 18:13:09 +0000

>      a 200 class response to an INVITE.

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.

So now we have a UAC which basically knows of two legs: the original
*with* a To tag and a new one without.  It then receives a response
whose To, From pair would seem to indicate that it belongs to the
original leg, but which really belongs to the second - the one that
knows of the transaction...

This all seems a bit fishy, no?

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?

Anders

-- 
Anders Kristensen <[email-masked]>,
http://www-uk.hpl.hp.com/people/ak/
Hewlett-Packard Labs, Bristol, UK

---

From: Jonathan Rosenberg <[email-masked]>
Date: Fri, 25 Feb 2000 14:37:04 -0500

> 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. 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. 

> 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. 

-Jonathan R.

---

From: Anders Kristensen <[email-masked]>
Date: Mon, 28 Feb 2000 12:14:15 +0000

Jonathan Rosenberg wrote:
> 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

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.

> 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.

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.

Anders