Subject: RE: [Sip] Replies to ACK

From: Jiri Kuthan <[email-masked]>
Date: Wed, 18 Dec 2002 13:16:45 +0100

Just to be safe -- I'm not advocating ACK/replies, I'm trying to
understand a potential gap betweeen running code I sighted, 
specification and its interpretations. I simply wish to know
whether it is a bug or feature, which is not apparent to me
from the spec.

At 12:09 PM 12/18/2002, Drage, Keith (Keith) wrote:
>Remember we do not tend to write standards stating what is precluded.
>
>There is an implicit assumption that what is not allowed is precluded. 
>Certainly any equipment claiming conformance to RFC 3261 should list this as an exception, like any other extensions, as it is not explicitly required by RFC 3261.

What implementers of the device in question might have seen in RFC3261
is "...each transaction consists of a reuqest...and at least one response..." 
(Section 4) and "...ACK...considered its own transaction" (Section 17).

>I would also still question the use. There seems to be little point in responding when as far as I read RFC 3261, any intermediate proxy would kill the incoming response message at the client process, and not pass it up to the transaction layer for further processing. 

I read the spec slightly differently. Reply matching succeeds if both branch 
and CSeq method matches (you would not be able to distinguish replies to CANCEL 
and INVITEs otherwise). If a device sends a reply to an ACK, the reply will be 
forwarded upstream statelessly. Besides that, such a reply does not have to visit 
a proxy at all, as it follows ACK path, which may be direct.

-Jiri 

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [email-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip

---

From: [email-masked]
Date: Wed, 18 Dec 2002 15:29:21 +0200

> whether it is a bug or feature, which is not apparent to me

i looked every place where rfc3261 mentions ack and didn't mention
anywhere if a proxy is allowed to respond to an ack it doesn't like.  my
interpretation of rfc3261 is that an ack to 2xx response is routed
exactly like any other request, which means, for example, that if a
proxy gets such an ack that contains a request uri it doesn't for some
reason like, it is allowed to respond with, for example, 403 forbidden.

since this clearly is unclear, i would suggest that whoever keeps an bug
list on rfc3261, adds this issue there to be clarified one way or
another in the next revision.

-- juha

---

From: Robert Sparks <[email-masked]>
Date: 18 Dec 2002 16:05:29 -0600

I've added this to the list of bugs being tracked as bug #684.

It has always been the intent that no element ever generate
a response to an ACK. 

Here is some evidence of that intent:

From the first paragraph of page 124  (this alone addresses
what stateful proxies are going to do with responses to ACKs):

  The client transaction is also responsible for receiving responses
  and delivering them to the TU, filtering out any response
  retransmissions or disallowed responses (such as a response to ACK).

From page 130:

  Although any request MAY contain a body, a body in an ACK is special
  since the request cannot be rejected if the body is not understood.

From page 51 
 o  A stateless UAS MUST ignore ACK requests.

There are probably more, but I think those make the point

RjS

---

From: Jonathan Rosenberg <[email-masked]>
Date: Thu, 19 Dec 2002 10:07:37 -0500

> It has always been the intent that no element ever generate

Robert is absolutely correct.

I believe there were explicit statements to this regard in bis 
revisions, but this is something that got lost. I suspect it got lost 
because it was always obvious in the minds of the editors and thus 
somehow never got stated...

Jiri has claimed that they are "harmless". However, in practice, we 
found that they confused implementations. Indeed, according to the 
transaction matching rules, an ACK for non-2xx has the same branch ID as 
the INVITE. As such, the response to ACK also has this same branch ID. 
This will cause the INVITE state machine to consider that response as a 
response to the original INVITE (CSeq method is not needed in the 
matching process!). This will trigger an ACK retransmit, which triggers 
an ACK response, which triggers an ACK retransmit, etc. The result is a 
message storm.

Thus, sending an ACK response is a BAD THING.

Robert has already logged a bug against it.

-Jonathan R.

-- 
Jonathan D. Rosenberg, Ph.D.                72 Eagle Rock Ave.
Chief Scientist                             First Floor
dynamicsoft                                 East Hanover, NJ 07936
[email-masked]                     FAX:   (973) 952-5050
http://www.jdrosen.net                      PHONE: (973) 952-5000
http://www.dynamicsoft.com

---

From: Jiri Kuthan <[email-masked]>
Date: Fri, 20 Dec 2002 11:10:11 +0100

At 04:07 PM 12/19/2002, Jonathan Rosenberg wrote:
>Jiri has claimed that they are "harmless". 

I'm not sure I ever did. Never mind.

[...]

>This will cause the INVITE state machine to consider that response as 
>a response to the original INVITE (CSeq method is not needed in the matching process!). 

Is that some implicit assumption too? I read the following in spec,
section 17.1.3: "A response matches ... If the method parameter in the 
CSeq header field matches the method of the request that created the 
transaction." It does not mention any special case, in which method 
matching is not used. Which is IMHO correct.

>This will trigger an ACK retransmit, which triggers an ACK response, which triggers an ACK retransmit, etc. The result is a message storm.
>

Thanks -- I think explicitely declaring replies to ACKs as illegal
would add clarity. 

-Jiri

---

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 24 Dec 2002 11:23:54 -0500

inline.

Jiri Kuthan wrote:

 >
 >> This will cause the INVITE state machine to consider that response
 >> as a response to the original INVITE (CSeq method is not needed in
 >> the matching process!).
 >
 >
 > section 17.1.3: "A response matches ... If the method parameter in
 > the CSeq header field matches the method of the request that created
 > the transaction." It does not mention any special case, in which
 > method matching is not used. Which is IMHO correct.

Not an implicit assumption, just me forgetting that the method check was 
there too. So, I guess there would not be any confusion in the client 
state machine. But, there are enough other potential problems that I 
still think its not a good idea.

-Jonathan R.