Subject: [Sip] Re: RFC4235 Dialog Event package query

From: "Dale R. Worley" <[email-masked]>
Date: Mon, 29 May 2006 21:07:48 -0400

On Fri, 2006-03-03 at 14:44 +0000, Michael Procter wrote:
> [...] 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!)

I was hoping that there would be more discussion of this question.

> 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.

I've recently been working on the implementation of the dialog event
package in our "parked call server", and what I am discovering is this:
It's clear in practice how dialogs are grouped based on "what user they
are destined for"; the conceptual design of a UA seems to always
generate this grouping.  Which makes it easy to determine, from the
request-URI of the SUBSCRIBE, which group of dialogs to report in the
dialog event package.

What is *not* clear is what URI should be used to describe this group.
It's possible for the group to "naturally" have an AOR, a GRUU, and more
than one IP-based contact address (e.g., if the UA makes connections
through a NAT as well as directly).  (Well, presumably if it has a GRUU,
it doesn't use IP contact addresses.)  And of course, the request-URI
for the SUBSCRIBE in question.

Currently, our implementation uses the "local network" contact address,
because that is always defined.

There is also the messy case that in some situations, one has a multi-
line phone instrument.  Note that while each line of the instrument has
one or more well-defined URIs, the instrument *as a whole* does not.
And sometimes one wants information about all calls active on the
instrument, not just on the line.  (Consider "camp-on", when a held call
is to ring the phone when it is no longer active.)

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