Subject: [Sip] precisely when is a dialog terminated

From: Troy Cauble <[email-masked]>
Date: Tue, 12 Oct 2004 14:09:20 -0400

Sorry to bother this list, but I couldn't find a clear statement
in the RFC or a consensus on the sip-implementors list.

For the UA that sends a BYE, is the dialog terminated when the
BYE is sent or when the 200 response is received?  Can you point
to a quote in the RFC?

Related questions:

Should crossed BYEs generate 481s or 200s?  (I think the answer is
obvious based on the answer to the first question.)

If the dialog is not terminated until the BYE's response is received,
how are re-INVITES handled during the period from when the BYE is sent
until the response is received?  Specifically the RFC refers to the
session/media being stopped when the BYE is sent.  Could a re-INVITE
restart the session/media?

Thanks
-troy

_______________________________________________
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: Troy Cauble <[email-masked]>
Date: Wed, 13 Oct 2004 14:53:35 -0400

Tom's google tip returned a lot more results but
I didn't find any that addressed my questions.

I've read the RFC and the archives.

 > BYE is sent or when the 200 response is received?  Can you point

The following quote from 15.1.1 says that the Session is terminated
when the BYE transaction is started, but doesn't clearly say when the
dialog is terminated.  The last sentence may imply that it's terminated
when a final response is received, but that's inferring a lot, IMO.

>    The UAC MUST
>    consider the session terminated (and therefore stop sending or
>    listening for media) as soon as the BYE request is passed to the
>    client transaction.  If the response for the BYE is a 481
>    (Call/Transaction Does Not Exist) or a 408 (Request Timeout) or no
>    response at all is received for the BYE (that is, a timeout is
>    returned by the client transaction), the UAC MUST consider the
>    session and the dialog terminated.

"Terminating a dialog" by "sending a BYE" is referred to more than
once, but I take that as specifying the mechanism, not the precise
timing.

Thanks,
-troy

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Wed, 13 Oct 2004 16:45:04 -0500

> when a final response is received, but that's inferring a lot, IMO.

Troy:

Given that the SIP community believes that dialog sharing
may be undesirable, you can probably rest assured that the
dialog is terminated when a final response is received.

- vijay
-- 
Vijay K. Gurbani  vkg@{lucent.com,research.bell-labs.com,acm.org}
Wireless Networks Group/Internet Software and Services
Lucent Technologies/Bell Labs Innovations, 2000 Lucent Lane, Rm 6G-440
Naperville, Illinois 60566     Voice: +1 630 224 0216

---

From: Robert Sparks <[email-masked]>
Date: Thu, 14 Oct 2004 09:19:34 -0500

What is the practical impact of the answer to this question on your 
application?

For BYE, the dialog is going to terminate (for a given endpoint) when a 
200 is
sent or received. Why? You could get a recoverable error (a 407 or a 
503 for
example) response from an intervening proxy, and you need the dialog 
state
to generate your next request.

You can use similar reasoning to determine when you can lose state for 
other
dialog terminating events.

RjS

---

From: Troy Cauble <[email-masked]>
Date: Fri, 15 Oct 2004 10:52:39 -0400

Thank you!  The possibility of a 407 clarifies things nicely.
-troy

Robert Sparks wrote:

> sent or received. Why? You could get a recoverable error (a 407 or a 503 
> for
> example) response from an intervening proxy, and you need the dialog state

---

From: Alex Audu <[email-masked]>
Date: Fri, 15 Oct 2004 15:42:00 -0500

Isn't it also necessary to to ensure that there are no outstanding 
subscriptions
that  have application states associated with the dialog?

See the following from rfc 3265, section 3.3.4. Dialog creation and 
termination :

   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.

Cheers,
Alex.

Troy Cauble wrote:

>> For BYE, the dialog is going to terminate (for a given endpoint) when 
>> a 200 is
>> You can use similar reasoning to determine when you can lose state 
>> for other

---

From: Robert Sparks <[email-masked]>
Date: Sat, 16 Oct 2004 16:59:34 -0500

So, the original question was about a dialog with one usage.

In general, a dialog goes away when its last usage goes away.

Each type of usage gets terminated in different ways, but the
same logic can be used for determining when that is.

See the -nit- drafts for a more detailed discussion.

RjS

On Oct 15, 2004, at 3:42 PM, Alex Audu wrote:

>>> For BYE, the dialog is going to terminate (for a given endpoint) 
>>> when a 200 is