Subject: [SIP] ACK handling at Stateful Proxies

From: "Jo Hornsby" <[email-masked]>
Date: Tue, 25 Jul 2000 15:47:37 +0100

Hi,

I'd just like to clarify the following.  Section 12.3.5 says the
following:
"When an ACK request is received, it is either processed locally
 or proxied. To make this determination, the To, From, CSeq and
 Call-ID fields are compared against those in previous requests.
 If there is no match, the ACK request is proxied as if it were
 an INVITE request. If there is a match, and if the server had
 ever sent a 200 response upstream, the ACK is proxied. If the
 server had never sent any responses upstream, the ACK is also
 proxied. If the server had sent a 3xx, 4xx, 5xx or 6xx response,
 but no 2xx response, the ACK is processed locally if the tag in
 the To field of the ACK matches the tag sent by the proxy in
 the response."

Is it necessarily either/or?  According to the above paragraph, in
the case that a 200 arrives late, and the INVITE was not successful
(i.e., the proxy has already sent back a non-200), it will not
process the ACK locally (and thus will retransmit the response).

Might it be better as:
"...If there is a match, and if the server had never sent any
 responses upstream, or had sent 2xx responses upstream, the ACK
 is proxied.  Additionally, if the server had sent a 3xx, 4xx,
 5xx or 6xx response, the ACK is processed locally if the tag
 in the To field of the ACK matches the tag sent by the proxy in
 the response."

Going back to section 4.2.2:
"A proxy server receiving an ACK request after having sent a 3xx,
 4xx, 5xx, or 6xx response must make a determination about whether
 the ACK is for it, or for some user agent or proxy server further
 downstream.  This determination is made by examining the tag in
 the To field. If the tag in the ACK To header field matches the
 tag in the To header field of the response, and the From, CSeq
 and Call-ID header fields in the response match those in the ACK,
 the ACK is meant for the proxy server. Otherwise, the ACK SHOULD
 be proxied downstream as any other request."

This suffers from the same problem (if it is a problem), although
in this case, the proxy will also fail to do the right thing if
a 200 response to a re-INVITE arrives "late".

This doesn't cover all the cases (12.3.5 does), but instead of:
"Otherwise, the ACK SHOULD be proxied downstream as any other
 request."
perhaps:
"If the proxy had also forwarded at least one 2xx response, or
 if the tag or ACK is not meant for the proxy server, the ACK
 SHOULD be proxied downstream as any other request."

Finally, the indented paragraph in section 4.2.2:
"It is possible for a user agent client or proxy server to
 receive multiple 3xx, 4xx, 5xx, and 6xx responses to a request
 along a single branch. This can happen under various error
 conditions, typically when a forking proxy transitions from
 stateful to stateless before receiving all responses. The
 various responses will all be identical, except for the tag in
 the To field, which is different for each one. It can therefore
 be used as a means to disambiguate them. This method MUST be
 supported by SIP proxy, redirect and user agent servers as
 well as clients."

I'm slightly confused as to why this is here (I'm taking it
as some sort of explanation for the previous paragraph -- am I
being silly?), since it seems to be talking about client
behaviour rather than server behaviour.  I would say that
this is an important note of potential behaviour in itself, and
deserves to be far more prominent. &:)  Perhaps as a note
somewhere that a client needs to be prepared to receive more
than one final response, and should attempt to ACK them all,
using the tag in the To header to disambiguate?

Cheers,

 - Jo.
-- 
  Jo Hornsby; IT Professional         --       mailto:[email-masked]
 Ubiquity Software Corporation        --         http://www.ubiquity.net/

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

---

From: Henning Schulzrinne <[email-masked]>
Date: Tue, 25 Jul 2000 18:39:34 -0400

> process the ACK locally (and thus will retransmit the response).

Not sure I get the scenario, but here's my interpretation:

- proxy times out branch (and sends CANCEL)
- proxy sends some 4/5/6xx upstream
- 200 arrives from the timed-out branch since it met the CANCEL in
mid-flight
- proxy forwards 200 upstream
- UA ACKs both 4/5/6 and 200, as appropriate

> using the tag in the To header to disambiguate?

The user agent section already has:

Multiple responses may arrive at the UAC for a single {\INVITE} request,
due to a forking proxy.  Each response is distinguished by the
``\header{tag}'' parameter in the \header{To} header field, and each
represents a distinct call leg.  The caller {\MAY} choose to acknowledge
or terminate the call with each responding UAS.

etc.

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

---

From: Jonathan Rosenberg <[email-masked]>
Date: Wed, 26 Jul 2000 01:31:10 -0400

> - UA ACKs both 4/5/6 and 200, as appropriate

Right, so Jo's point here I think is that the text discusses ACK
matching under
the assumption that only a single response was forwarded upstream, but
here there are 
multiple ones.

-JOnathan R.
-- 
Jonathan D. Rosenberg                       72 Eagle Rock Ave.
Chief Scientist                             First Floor
dynamicsoft                                 East Hanover, NJ 07936
[email-masked]                     FAX:   (973) 952-5050
http://www.cs.columbia.edu/~jdrosen         PHONE: (732) 741-7244
http://www.dynamicsoft.com

---

From: "Jo Hornsby" <[email-masked]>
Date: Wed, 26 Jul 2000 08:58:39 +0100

> - UA ACKs both 4/5/6 and 200, as appropriate

Exactly right.  However, my interpretation of 12.3.5 is that the
proxy would not process the ACK locally in this case, since it
had forwarded a 2xx (admittedly, it's a bit of race -- the ACK
for the 4/5/6xx would have to arrive after the proxy had forwarded
the 2xx).  And tags in To headers cannot necessarily be used to
distinguish between ACKs, since this might be as the result of
a re-INVITE.

> or terminate the call with each responding UAS.

Cool.  But doesn't this apply to clients in general?  And thus,
shouldn't it be stated that a client should attempt to ACK all
responses along a single branch with different tag parameters
in the To header?

Cheers,

 - Jo.

---

From: Henning Schulzrinne <[email-masked]>
Date: Wed, 26 Jul 2000 14:53:26 -0400

> the assumption that only a single response was forwarded upstream, but

I simplified section 12.3.5 to read

When an {\ACK} request is received, it is proxied unless the request's
\header{To} (including the tag), \header{From}, \header{CSeq} and
\header{Call-ID} header fields match those of a (non-200) response sent
by the proxy.  In that case, the request is processed locally and stops
retransmissions of responses.

I believe that handles the multiple-ACK case and is simpler. It does
require that a server keep track of which non-2xx response it has
forwarded, since it needs to match the To tag.

Let me know if I missed any tag subtleties...
-- 
Henning Schulzrinne   http://www.cs.columbia.edu/~hgs

---

From: "Jo Hornsby" <[email-masked]>
Date: Thu, 27 Jul 2000 14:08:56 +0100

> Let me know if I missed any tag subtleties...

My original (badly explained) point was that in the case of a
re-INVITE, you wouldn't be able to distinguish between an ACK
for the non-2xx response that the proxy returned (or forwarded),
and an ACK for a "late" 200 (that the proxy also had to forward).

This is because the re-INVITE would already have a tag in the
To header, so a proxy would be unable to play with it.

I was going to suggest that in this case, the proxy both forward
the ACK and process it locally, but I've just realised that
that might halt 2xx retransmissions when the UAC hadn't even
seen the 2xx.

Given this, I think that the new 12.3.5 above is the best that
we can do.

Ah well. &:)

Cheers,

 - Jo.

---

From: Henning Schulzrinne <[email-masked]>
Date: Thu, 27 Jul 2000 09:15:48 -0400

> To header, so a proxy would be unable to play with it.

Pardon me for deing dense, but the proxy never adds a tag. It forwards
the responses from one of the branches. Unless a single To;tag
combination produces both a 200 and a 3/4/5/6xx (which it should never
do), it should be unambiguous which response the ACK belongs to. The
proxy would track whether it had issued a non-200 for this To;tag and
decide accordingly.

---

From: "Jo Hornsby" <[email-masked]>
Date: Thu, 27 Jul 2000 15:27:40 +0100

> Pardon me for deing dense, but the proxy never adds a tag.

Sorry -- "play" was a bad word to use.

> It forwards
> the responses from one of the branches.

Yes.  But there are also cases where the response is generated
locally: 404, 408 being typical examples.

> Unless a single To;tag

It is unlikely, but I don't think that is so impossible.

Consider that two UAs are in an (audio) call.  The caller decides
that they would like to add video.  The callee's UA interactively
asks the callee if it's okay to add the video stream.  The callee
is temporarily distracted, and does not initially see the prompt.
An intermediate proxy times out, returns a 408 and sends a CANCEL
downstream.  Meanwhile the callee has accepted the video and the
callee's UA returns 200 before it sees the CANCEL.  The timed-out
(and any other) proxies have to forward the 200, so the caller's
UA sees both a 408 and a 200 (note that it is not necessarily
obvious which order these will arrive in).

At any point along the route, it will not be apparent to a proxy
whether the ACK is for the 408 or for the 200.

With the new wording, the 200 will probably not be ACKed; I think
that this is the preferable behaviour since the 408 is more likely
to be seen at the callee's UA before the 200, and I would guess
that the 200 will just be seen as a retransmission of the 408.
Therefore both UAs will conclude the same thing: that the re-INVITE
failed.

I'm happy now. &:)
Have I missed anything?

 - Jo.

---

From: Jonathan Rosenberg <[email-masked]>
Date: Thu, 27 Jul 2000 10:57:33 -0400

> obvious which order these will arrive in).

I'll note that this won't happen in the proxy uses the new CANCEL rules
(the 487 stuff). In that case, it won't send a response after CANCEL, it
will wait to receive the 487 and then forward that. 

The other case which can cause multiple responses is forking, but
reinvites
will, with the bis draft, never be forked. Thats because the UAS inserts
a Contact into the 200 OK. Reinvites thus always have a route directly
to the UAS.

So, in practice, this problem will go away once everyone has implemented
the bis
draft. In the interim, it can happen. In this case, I would recommend
forwarding
ACKs that match a 200 OK you've sent upstream.

-Jonathan R.

---

From: "Jo Hornsby" <[email-masked]>
Date: Fri, 28 Jul 2000 09:57:14 +0100

> will wait to receive the 487 and then forward that.

Hmmm... have I misunderstood 487?

Consider the following scenario:
  UA1 sends an INVITE to UA2, and that INVITE traverses proxies P1
  and P2.  At some point later, P1 times-out on the INVITE and sends
  a CANCEL to P2; P2 in turn sends a CANCEL to UA2, but UA2 sends
  a 200 at the same time.

    UA1            P1            P2            UA2
        -- INV -->
        <-- 100 --
                      -- INV -->
                      <-- 100 --
                                    -- INV -->
                                    <-- 100 --
[0]
                      -- CCL -->
        <-- 408 --
                                    <-- 200 --
[1]
                                    -- CCL -->
[2]
                      <-- 487 --
                      <-- 200 --
        <-- 200 --
              
[0] some time passes, and P1 times-out
[1] 200 (above) and (CANCEL) below "cross on the wire"
[2] note that UA2 does not return 487, because it has already
    returned a final response

Result: UA1 sees a 408 followed by a 200, but will probably
        only see the 200 as a retransmission of the 408.
        Subsequent ACKs will be ambiguous.

> reinvites will, with the bis draft, never be forked. Thats because
> the UAS inserts a Contact into the 200 OK. Reinvites thus always
> have a route directly to the UAS.

Agreed...

> So, in practice, this problem will go away once everyone has
> implemented the bis draft.

...but not so sure about this (unless scenario above is not
bis-Correct[tm]).

> In the interim, it can happen. In this case, I would recommend
> forwarding ACKs that match a 200 OK you've sent upstream.

Even though the UA might not have seen the 200, and is even
less likely to as a result of forwarding the ACK?  Also, should
this ACK halt the 487 (or whatever) retransmissions?

 - Jo.

---

From: Jonathan Rosenberg <[email-masked]>
Date: Fri, 28 Jul 2000 10:05:14 -0400

>   a CANCEL to P2; P2 in turn sends a CANCEL to UA2, but UA2 sends

Thats the problem. What I'm arguing is that upon sending cancel, P1
should NOT at that point return a 408, but rather wait for the
487. If everyone implemented bis, it would get this 487 right away
(modulo packet losses), or get a different final response if that
response and the CANCEL pass on the wire.

> this ACK halt the 487 (or whatever) retransmissions?

Hmm. Actually, there is a way to distinguish these two ACKs. If the UAS
is
acking the non-200, the ACK won't contain any Route headers. If the ACK
is for the 200, it will. So, if the proxy receives an ACK without route
headers, it knows the ACK is for it. Works so long as UAS inserts
Contact.

Sound right?

-Jonathan R.

---

From: "Jo Hornsby" <[email-masked]>
Date: Fri, 28 Jul 2000 15:33:15 +0100

> response and the CANCEL pass on the wire.

Ah right, I see.  I guess we'll have to kick of another timer,
in case the next downstream stateful-proxy/UA doesn't return a
487.  But that's no biggie.

> headers, it knows the ACK is for it. Works so long as UAS inserts

Very sweet.

> Sound right?

Yup -- works for me.

Cheers,

 - Jo.

---

From: "Vipul Sharma" <[email-masked]>
Date: Fri, 28 Jul 2000 10:48:49 -0400

Hi!,
	This is not exactly a SIP question/issue (my apologies).....But could
someone point me to where I can find the RFC's that are going to be
discussed in Pittsburgh. I am told that they are available in zipped (or
some other) format. Thanks in advance for your help.

Vip

---

From: Henry Sinnreich <[email-masked]>
Date: Fri, 28 Jul 2000 10:07:03 -0500

See the IETF web site and search at
http://search.ietf.org/search/brokers/internet-drafts/query.html

The SIP WG is at
http://search.ietf.org/html.charters/sip-charter.html

and there is an additional web page for all SIP related drafts
at
http://www.softarmor.com/sipwg/drafts/

Henry

>-----Original Message-----
>From: [email-masked]
>[mailto:[email-masked]]On Behalf Of Vipul Sharma
>Sent: Friday, July 28, 2000 9:49 AM
>To: [email-masked]
>Subject: [SIP] RE: RFC's ..Where are they (smile) ???
>
>
>Hi!,

---

From: Jonathan Rosenberg <[email-masked]>
Date: Fri, 28 Jul 2000 11:33:23 -0400

The list of drafts for this meeting is also at:

http://www.softarmor.com/sipwg/meets/IETF48/agenda.htm

-Jonathan R.