Subject: RE: [Sipping] updated conference and dialog event packages

From: "Sriram Parameswar" <[email-masked]>
Date: Tue, 2 Jul 2002 19:54:57 -0500

Paul,

Interesting analysis - just a few questions, in-line (below).

Thanks,

Sriram

-----Original Message-----
From: Paul Kyzivat [mailto:[email-masked]]
Sent: Tuesday, July 02, 2002 7:35 PM
To: Parameswar, Sriram [NGC:B615:EXCH]
Cc: Jonathan Rosenberg; [email-masked]
Subject: Re: [Sipping] updated conference and dialog event packages

Sriram,

The catch in that quote is "*such as* a 2xx response to an INVITE". You are
correct that bis-09 only gives one way to establish a dialog. But the point
of introducing the
concept was to permit extensions to introduce dialogs in other ways. The
event specification provides another way of introducing a dialog, using
SUBSCRIBE. It also goes on
to explain the life cycle of a dialog in greater detail. So the following
are all interesting life cycles for a dialog:

1) dialog created by 200 response to INVITE. 
   Goes away with subsequent BYE.

2) dialog created by 200 response to SUBSCRIBE. 
   Goes away when the subscription expires.

3) dialog created by 200 response to INVITE. 
   SUBSCRIBE sent within dialog.
   Subsequent BYE ends call leg, but not dialog.
   Dialog goes away when subscription expires.
[SKP] Wouldn't the SUBSCRIBE initiate its own dialog, independent of the
dialog that was created in response to the INVITE? Thus the BYE ends the
INVITE initiated dialog and the subscription expiry ends the SUBSCRIBE
initiated dialog.

4) dialog created by 200 response to INVITE. 
   SUBSCRIBE sent within dialog.
   Subscription expires but dialog doesn't end.
   Subsequent BYE ends call leg, and dialog.
[SKP] same as above - aren't those two dialogs independent?

5) dialog created by 200 response to SUBSCRIBE. 
   Second SUBSCRIBE sent within same dialog.
   Dialog goes away only when both subscriptions expire.
[SKP] Here the second SUBSCRIBE sent *may* belongs to the same dialog
(example: refreshing subscription) or creating a new dialog (example: new
subscription for a different event package).

	Paul

> Sriram Parameswar wrote:
> 
> Paul,
> 
> Not sure about the difference you are making between Dialog and Call-leg -
according to Bis-09 they are the same - please see my quote below:
> 
> "Dialog: A dialog is a peer-to-peer SIP relationship between two UAs that
persists for some time. A dialog 627
> is established by SIP messages, such as a 2xx response to an INVITE
request. A dialog is identified by 628
> a call identifier, local tag, and a remote tag. A dialog was formerly
known as a call leg in RFC 2543. 629"

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 03 Jul 2002 08:39:59 -0400

Sriram - response below.

	Paul

> Interesting analysis - just a few questions, in-line (below).
...
> [SKP] Wouldn't the SUBSCRIBE initiate its own dialog, independent of the dialog that was created in response to the INVITE? Thus the BYE ends the INVITE initiated dialog
> and the subscription expiry ends the SUBSCRIBE initiated dialog.
> 
> [SKP] Here the second SUBSCRIBE sent *may* belongs to the same dialog (example: refreshing subscription) or creating a new dialog (example: new subscription for a
> different event package).

Take a look at section 4.3.4 of draft-ietf-sip-events-05:

"If an initial SUBSCRIBE is sent on a pre-existing dialog, a matching 200-class response or successful NOTIFY request merely creates a new subscription associated with that
dialog...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)."

It is exactly this kind of confusion that leads me to suggest that "dialog" is the wrong name for the event package it names.

	Paul

_______________________________________________
Sipping mailing list  https://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