Subject: RE: [Sip] REFER and dialogs terminated by BYE

From: "Sriram Parameswar" <[email-masked]>
Date: Thu, 1 Aug 2002 09:38:39 -0500

Good question - my initial reaction would be that the receipt of the BYE
would terminate the Implicit Subscription just as a 481 may be used to
terminate subscriptions. Further - no NOTIFYs will be sent on the terminated
subscription.

Regards,

Sriram

-----Original Message-----
From: Pekka Pessi [mailto:[email-masked]]
Sent: Thursday, August 01, 2002 8:39 AM
To: [email-masked]
Subject: [Sip] REFER and dialogs terminated by BYE

	Hello,

	Let's say a REFER is used to transfer an existing call. REFER is
	sent using the existing dialog. Now, what should happen to the
	dialog and the subscription(s) when either end uses BYE to
	terminate the original call before the subscription(s) created
	by REFER have terminated?
	
	BR,

					Pekka

_______________________________________________
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: Robert Sparks <[email-masked]>
Date: 01 Aug 2002 10:31:43 -0500

No.

The subscription relationship and invite relationship are independent.
This is the same as multiple SUBSCRIBEs to different events in the
same INVITE dialog. The subscription lifetimes are independent from
each other and from the lifetime of the INVITE association.

As Adam pointed out - the subscription ends with a NOTIFY with
a Subscription-State of terminated.

RjS

On Thu, 2002-08-01 at 09:38, Sriram Parameswar wrote:
> terminate subscriptions. Further - no NOTIFYs will be sent on the
> terminated subscription.
> 
> Regards, 
> 
> Sriram 
> 
> From: Pekka Pessi [ mailto:[email-masked]
> <mailto:[email-masked]> ] 
> <https://www1.ietf.org/mailman/listinfo/sip>

---

From: Robert Sparks <[email-masked]>
Date: 01 Aug 2002 10:35:49 -0500

To save people from asking where this is described, the following
appears on page 19 of rfc3265:

   Multiple subscriptions can be associated with a single dialog.
   Subscriptions may also exist in dialogs associated with INVITE-
   created application state and other application state created by
   mechanisms defined in other specifications.  These sets of
   application state do not interact beyond the behavior described for a
   dialog (e.g., route set handling).

   A subscription is destroyed when a notifier sends a NOTIFY request
   with a "Subscription-State" of "terminated".

      A subscriber may send a SUBSCRIBE request with an "Expires" header
      of 0 in order to trigger the sending of such a NOTIFY request;
      however, for the purposes of subscription and dialog lifetime, the
      subscription is not considered terminated until the NOTIFY with a
      "Subscription-State" of "terminated" is sent.

   If a subscription's destruction leaves no other application state
   associated with the dialog, the dialog terminates.  The destruction
   of other application state (such as that created by an INVITE) will
   not terminate the dialog if a subscription is still associated with
   that dialog.

      Note that the above behavior means that a dialog created with an
      INVITE does not necessarily terminate upon receipt of a BYE.
      Similarly, in the case that several subscriptions are associated
      with a single dialog, the dialog does not terminate until all the
      subscriptions in it are destroyed.

RjS

---

From: "Arunachalam Venkatraman" <[email-masked]>
Date: Thu, 1 Aug 2002 21:21:00 -0500

RFC3261 is silent on the matter of To tag when a request is to be
resubmitted.
In section 8.1.3.5 Processing 4xx Responses, it is said -
In all of the above cases, the request is retried by creating a new
   request with the appropriate modifications.  This new request
   constitutes a new transaction and SHOULD have the same value of the
   Call-ID, To, and From of the previous request, but the CSeq should
   contain a new sequence number that is one higher than the previous.
<<<<<<<<<<<<<

Now, a proxy returning a 407, is acting as a UAS and will add a To tag to
that response creating a dialog (of sorts, since receipt of 407 terminates
that dialog).

When the request is resubmitted with credentials, the To tag should be
omitted in addition to the above requirements on Call-Id, From and CSeq
thereby initiating a new dialog.

Maybe this is the only logical conclusion from the definition of a dialog
and from other portions of the protocol specification. I believe there is
some value to expressing this explicitly.

Now, in general, the UAC has no way of knowing if the final 4xx response
came from a target UAS or from an intermediary proxy. So, the general rule
must be to always drop the To tag from the previous response when
resubmitting a request.

The sip call flow examples document (draft-ietf-sip-call-flows-05.txt) does
demonstrate this in 3.1.2 Successful SIP to SIP through two proxies.