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

From: Brazier Lachlan <[email-masked]>
Date: Thu, 8 Nov 2001 05:25:48 +0100

Hello,

as SUBSCRIBE is compared to INVITE, can't we send an ACK request to the
response of the SUBSCRIBE? I'm not sure if a ACK would pass a proxy when no
INVITE did before????

But just for going into it:
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.
After receiveing an ACK, the presentity can send an immediate NOTIFY if it
wishes, saying it's status, which could pe pending, online, offline, etc.

Of course everything hangs on the handling of the ACK. I'm really not sure
if a "lonely" ACK for an RFC2543 proxy will be forwarded.

Is this a nonsense?

Lachlan

-----Originalnachricht-----
Von: Jonathan Rosenberg
An: 'James Undery'; 'Brian Stucker'; 'Fairlie-Cuninghame, Robert';
[email-masked]
Gesendet: 07.11.01 21:31
Betreff: RE: [Sipping] Immediate NOTIFIES change in sip-events-01

I think James is right here. I don't have a problem with keeping the
202,
but the mapping of SUB/NOT to the INVITE handshake is by now quite
clear:

INVITE            SUB/NOT
------            -------

INVITE  <----->    SUBSCRIBE
1xx     <----->     final response to SUBSCRIBE
final resp     <------>   NOTIFY
ACK           <------>  final response to NOTIFY

From this it is clear that we need, within NOTIFY, to convey the full
set of
information which would be possible to be conveyed in the final response
to
an INVITE. Treating the absence of a body of NOTIFY to imply pending is
one
way, but it covers only one case. I think a more generic mechanism,
through
some header, like Subscription-Status or something, that has a response
code
and reason phrase, is much better and more generic. 

Now, if we take this one step further, it should, in theory, be allowed
to
CANCEL a SUBSCRIBE after I get a final response to the SUBSCRIBE, and
the
result of that would be to cause all subscriptions that have not
generated a
NOTIFY yet (because the subscription wasn't authorized) to immediately
send
a NOTIFY with a Subscription-Status of 487. Once you allow this kind of
cancellation, then it no longer becomes neccesary to have an immediate
NOTIFY, for the same reason you don't need to send a 2xx to INVITE
immediately. I'm not proposing that, but I think it is important to
consider
how closely we do, or do not, wish to align the two mechanisms together.

-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

> -----Original Message-----
> From: James Undery [mailto:[email-masked]]
> Sent: Wednesday, November 07, 2001 8:35 AM
> To: 'Brian Stucker'; 'Fairlie-Cuninghame, Robert'; [email-masked]
> Subject: RE: [Sipping] Immediate NOTIFIES change in sip-events-01
> 
> 
> Hi
> 
> This still doesn't cover Robert's point, i.e. you will only 
> see one final
> response and potentially multiple NOTIFYs. Your FSMs are 
> already overly
> simplified because of ignoring this complexity.
> 
> My personally favoured solution would be to include optional 
> subscription
> status info in NOTIFYs as a header. e.g. Replace 
> Subscription-Expires with
> something like a Subscription-State header that contained 
> status (optional),
> expires and expiry-reason (optional) parameters.

_______________________________________________
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

_______________________________________________
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: "Bob Penfield" <[email-masked]>
Date: Thu, 8 Nov 2001 08:45:30 -0500

Hi,

ACK can only be used for INVITE. Any stateful element will look for a
corresponding INVITE transaction to match the ACK to. There would be no way
for SIP elements to know which new methods would use ACK, therefore all new
methods MUST be non-INVITEs and follow the rules for non-INVITE requests.

cheers,
(-:bob

Robert F. Penfield
Chief Software Architect
Acme Packet, Inc.
130 New Boston Street
Woburn, MA 01801
[email-masked]

----- Original Message -----
From: "Brazier Lachlan" <[email-masked]>
To: "'Jonathan Rosenberg '" <[email-masked]>; "''James Undery' '"
<[email-masked]>; "''Brian Stucker' '" <[email-masked]>;
"''Fairlie-Cuninghame, Robert' '" <[email-masked]>; <[email-masked]>
Sent: Wednesday, November 07, 2001 11:25 PM
Subject: AW: [Sipping] Immediate NOTIFIES change in sip-events-01