Subject: [Sip] Guidelines for Implementing the Dialog Event Package in User Agents

From: [email-masked]
Date: Wed, 28 Jun 2006 12:38:15 -0400

I've submitted draft-worley-sip-dialog-02, "Guidelines for
Implementing the Dialog Event Package in User Agents".  It doesn't
change too much from the -01 version, other than updating the data on
current implementations.  (They're still not very good.)

It can be gotten from
https://scm.sipfoundry.org/rep/ietf-drafts/worley/draft-worley-sip-dialog-02.{txt,html,xml}
as well as the I-D archives.

Discussion of earlier versions has shown that there are still some
undefined aspects of dialog event packages.  Michael Proctor gives a
good summary:

    I've been reading this document, and also Dale Worley's draft containing
    implementation guidelines (draft-worley-sip-dialog-00).  One thing that
    has come up in the discussions I have had with Dale is the question of
    what is meant by the mandatory "entity" attribute in the dialog-info
    element.

    >From RFC4235 Section 4.1:
       o  entity: This attribute contains a URI that identifies the user
	  whose dialog information is reported in the remainder of the
	  document.  This user is referred to as the "observed user".

    There doesn't appear to be any further discussion of what the entity
    value should be, but all the examples in the RFC are apparently AORs.
    (Except for the example in 4.2, which is missing the element altogether!)

    It is also unclear what use the element is.  I first thought it could
    be used to distinguish between responses to a forked SUBSCRIBE, but
    that doesn't make any sense if the entity is the AOR.  Maybe the
    Contact (or better, GRUU) would be a more useful URI to use in those
    circumstances.

    Having the entity as the AOR does give the interesting side effect of
    allowing a GRUU to be mapped back to an AOR, simply by subscribing
    to the dialog package for the GRUU you are interested in.  I remember
    this was a hot topic a couple of months ago - I don't recall what
    the result was.

    A problem with requiring the AOR to be present is that not all UAs
    know their AOR.  There are various devices that are still statically
    registered and so don't necessarily know their AOR.  There are
    probably other reasons why a UA might not know its AOR aswell.
    Under these circumstances, I suppose the request-URI might be the
    best thing to put in the field.

    So, it seems likely that the intention was that an AOR be used, but
    there appear to be good and not-so-good reasons to use a contact
    URI/GRUU instead.  I would like to understand what the entity
    element is for (any use-cases?) and why it is mandatory.  Any
    clarifications to the usage could be added to Dale's draft.

In regard to "Who uses the 'entity' attribute?', I've seen client
applications that use the entity value for storing dialog state
information (because it has to process partial updates).

It would also be desirable for "pseudo-presence" applications if there
was a way that one could subscribe to all the dialog event state in a
particular UA "instrument", rather than just for a particular "line".

Dale

_______________________________________________
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