RE: [Sip] Replies to ACK

[Jiri Kuthan <jiri@iptel.org>]

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 sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip