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

From: "Sriram Parameswar" <[email-masked]>
Date: Tue, 2 Jul 2002 16:26:23 -0500

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"

Also - there should be just one call state machine associated with a dialog
(not sure though).

Thanks,

Sriram

__________________________________________
Sriram Parameswar              Phone: 972-685-8540
Interactive Multimedia Server (IMS) Fax: 972-684-3986
Nortel Networks, Richardson USA  Email: [email-masked]

-----Original Message-----
From: Paul Kyzivat [mailto:[email-masked]]
Sent: Tuesday, July 02, 2002 2:24 PM
To: Jonathan Rosenberg
Cc: [email-masked]
Subject: Re: [Sipping] updated conference and dialog event packages

I have one initial comment about draft-ietf-sipping-dialog-package-00. In a
way it is just a nit, but one that I think could prove confusing:

I think the name of this package (dialog) is confusing. The term "dialog" in
sip is not synonomous with "call-leg", yet this particular package, using
the same name,
applies only to call legs.

A sip dialog has a different state model than is portrayed in this package.
A dialog can come into existence as a result of an INVITE, or as a result of
a SUBSCRIBE, and
there may be additional ways in the future. The same dialog may be
associated with multiple state machines, for several invitations and up to
one call leg. The dialog
itself doesn't go away until all of the associated state machines have
terminated.

I think it would be way less confusing to change the name of this event
package back to "call-leg", or maybe "call-info".

	Paul

Jonathan Rosenberg wrote:
> 
> Folks,
> 
> I've split draft-rosenberg-sip-call-package into two drafts, and
> submitted them as new work items for sipping. Until they appear in the
> archives, you can pick them up at:
> 
> http://www.jdrosen.net/papers/draft-ietf-sipping-conference-package-00.txt
> http://www.jdrosen.net/papers/draft-ietf-sipping-dialog-package-00.txt
> 
> The changes since the previous revision are:
> 
> Dialog Package
> --------------
> 
> * chose a single default subscription duration (1 hr)
> 
> * defined a dialog state machine, replacing the kludgey response-code
> based reporting of events.
> 
> * specified detailed recommendation on generating NOTIFYs when the
> subscriber is not authorized to see details on how many calls you have
> and what states they are in.
> 
> * clarified that this is for INVITE initiated dialogs
> 
> * switched to XML schema for the dialog document
> 
> * detailed protocol mechanisms for partial updates
> 
> * local URI and remote URI made into elements, not attributes of the
> dialog element
> 
> * removed Route element
> 
> * proper IANA registrations of namespace and MIME type
> 
> Conference Package
> ------------------
> 
> * added an event parameter for supporting "recursion"; when a
> participant in a conference is also a conference, if the recursion flag
> is set, the conference server will generate a SUBSCRIBE to it to
> determine its membership.
> 
> * well specified algorithm for partial notifications
> 
> * switched to XML schema; proper namespace usages easily allowed for
> importing the dialog element from the dialog package
> 
> * IANA registrations for namespace and MIME type
> 
> Comments and questions welcome.
> 
> Thanks,
> Jonathan R.
> --
> Jonathan D. Rosenberg, Ph.D.            72 Eagle Rock Avenue
> Chief Scientist                         First Floor
> dynamicsoft                             East Hanover, NJ 07936
> [email-masked]                 FAX: (973) 952-5050
> http://www.jdrosen.net                  PH:  (973) 952-5000
> http://www.dynamicsoft.com
> 
> _______________________________________________
> 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

_______________________________________________
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

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 02 Jul 2002 20:34:50 -0400

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.

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.

5) dialog created by 200 response to SUBSCRIBE. 
   Second SUBSCRIBE sent within same dialog.
   Dialog goes away only when both subscriptions expire.

	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"