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

From: Paul Kyzivat <[email-masked]>
Date: Tue, 02 Jul 2002 15:23:47 -0400

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: "Sriram Parameswar" <[email-masked]>
Date: Tue, 2 Jul 2002 19:59:22 -0500

Jonathan,

There are two use cases that you detail, in the use of the dialog package:

   "There are two distinct use cases for dialog state. The first is when
   a subscriber is interested in the state of a specific dialog (and
   they are authorized to find out about just the state of that dialog).
   In that case, when the dialog terminates, so too does the
   subscription. In these cases, the value of the subscription duration
   is largely irrelevant, and SHOULD be longer than the typical duration
   of a dialog, about two hours would cover most dialogs.

   In another case, a subscriber is interested in the state of all call
   legs for a specific user. In these cases, a shorter interval makes
   more sense. The default is one hour for these subscriptions."

I suggest we define an Event Package Parameter for the case where a user
wants to subscriber to a specific dialog. I would suggest sending the dialog
identifier (Call-ID, To-tag, From-tag) as the parameters to the "dialog"
event.

Thoughts?

Sriram

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