Subject: AW: [Sipping] Immediate NOTIFIES change in sip-events-01

From: Brazier Lachlan <[email-masked]>
Date: Fri, 9 Nov 2001 11:43:52 +0100

Hi,

> 
> ACK can only be used for INVITE. 

Why's that?

I include the response from Sean Olson:

1) I hope no proxies out there try to block 
an ACK because they don't remember the ACK. 2) ACK is so closely 
tied to INVITE in the current spec. that it would be difficult 
to extend it to other methods in most implementations. 

Regarding 1)
I really assume that no proxy blocks an ACK, when it has no Call state for
it.

Regarding 2)
Why's that? This would mean that an ACK request is "untouchable" for other
drafts. Because of 1), I don't see how proxies have a problem with an ACK.
This leaves UA's; but if UA's are implemented for SUB/NOTIFY, they can add
waiting for an ACK request as well.

My reasons for waiting for an ACK are:

* We know we need a 3 way- handshake because of forking --> Why not use one
we know is working (INVITE/response/ACK). Note, I'm not saying to use it the
same way as with INVITE. The ACK would be meaningfull only for the
endpoints, even with error responses. But as the endpoints need to handle
the SUBSCRIBE request, they can wait for an ACK before sending the NOTIFY.
If they sent an error response, they will just drop the ACK.

* Repetition: 
A sends a SUBSCRIBE. Proxy P forks the subscribe. Several 2xx message come
back. As the request was a SUBSCRIBE, only one response will be passed
further on. Now A ACK's the response. As the To header in the ACK has a
Tag, the proxy can fork the ACK if it wishes (for RFC2543 reasons), and
everybody will know if it's response arrived at the subscriber or not, and
can send the NOTIFY in case of yes, and do nothing in case of no.

As far as I see, this is exactly what we wanted.

Please also note, that I believe that a Subscription-Expires header and a
Subscription-Status header are still usefull in a NOTIFY request.

Cu
Lachlan

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

---

From: Pekka Pessi <[email-masked]>
Date: 09 Nov 2001 16:10:42 +0200

>Why's that?

	It is a special transaction which requires that proxies forward
	all 2xx messages to client.  Now, they forward first final
	response and throw away everything else.

						Pekka