Subject: [Sip] Subscribe/Notify and Refer/Notify

From: "Kaul, Amit" <[email-masked]>
Date: Fri, 18 Oct 2002 01:27:05 -0700

Hi,

I have following doubts in the Subscribe/Notify and Refer/Notify drafts :

i) As per the Subsc/Notify draft, Subscriber should be able to receive
   NOTIFY before receiving 2xx. Also, it shall create a new
subscription/dialog
   when it receives NOTIFY.

   Consider a scenario like this :

 |                 			SUBS
 | **Subsc. Trans. 
 | tmr. starts        	--------------------------->
 |                  			NOTIFY(ss: active)
 |         		 	<--------------------------
 |                   	
 |   *Subsc./Dialog
 |     created               		2xx(Notify)
 |			--------------------------->
 |
 \/  **Subsc. Trans. Tmr
        Times out : NO
        final response for SUBS
        is recvd.

In this case, subscription and dialog are created before getting 2xx for the
intial SUBSCRIBE.
However, if Subscriber doesn't get any final response and the transaction
timer for SUBSCRIBE
transaction times out, what should be the action on the part of subscriber :
a) Remove the subscription
b) Keep the subscription and remove the SUBSCRIBE transaction gracefully.

ii) As per the Refer/Notify draft, the subscription expiry time, before the
Subscriber gets NOTIFY
   depends on "Refer-To" header.

  E.g., in the draft, this line is mentioned :
    Subscription-State: active;expires=(depends on Refer-To URI)
   a) What exactly is meant by this ? 

   b) If no NOTIFY is received before the REFER (Refer/2xx) transaction
times  out, does that mean that subscription/dialog
   is automatically removed ? OR is subscriber supposed to wait for the
NOTIFY till some "Configured" time ?

thanks
__amit
_______________________________________________
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: Sun, 20 Oct 2002 09:07:33 +0300

>    NOTIFY before receiving 2xx. Also, it shall create a new

i also complained about this a couple of weeks ago to the author of the
sub/not rfc 3265.  sub/not rfc is not following the dialog model of RFC
3261, which is very confusing.  at minimum, the sub/not rfc should have
had its own state diagrams in order to make the mess a bit clearer.  i
suggest that we announce the sub/not rfc obsolete and replace it with a
new, simpler one.

-- juha