Subject: [Sip] Event ID (was RE: Events Last Call.)

From: Adam Roach <[email-masked]>
Date: Mon, 18 Feb 2002 14:35:40 -0500

Copying SIP mailing list...

> -----Original Message-----
> From: Fairlie-Cuninghame, Robert [mailto:[email-masked]]
>
> The Event id parameter seems to add a lot of complication to 
> the draft - why was it added ?

There's a rather ugly problem we're trying to solve, and it's
probably been the hardest thing to get to work correctly in the
whole sip-events draft.

The basic setup is this: I'm in an INVITE-initiated session with
you. That INVITE transaction set up a dialog with a route path
and other goodies that make sure that subsequent requests from
me to you end up on exactly the same UA on your end, and that
subsequent requests from you to me end up on exactly the same UA
on my end. Now, for whatever reason, you want to subscribe to
some resource state relating exactly to the terminal that your
INVITE landed on. How do you do this?

You can't use the contact, since the user-portion may very well
contain state information that isn't valid outside the dialog.
You can't just copy the route set for this reason and the additional
reason that proxies may have done the same sort of trick with the
user portion of URIs in the route set.

So, what's the solution? As Rohan suggested, you can re-use the
same dialog that was created by the INVITE. Problem solved.
You just send the SUBSCRIBE on the dialog -- which includes the
same route-set and same contact -- and you hit the same UA. But
this ends up meaning that you need to be extremely careful about
how you define dialog termination. Does the dialog terminate when
the BYE comes across, as bis has (until recently) said? That would
be bad -- what if one of the events yet to be reported is some
sort of end-of-call statistics?

So, after much discussion, arguing, and heartburn with a variety
of people (including a discussion during my presentation in SLC),
we determined that the only reasonable thing to do would be that
termination of the last "thing" in a dialog would terminate the
dialog. So, we added language to bis to say that BYE doesn't
*necessarily* terminate the dialog, and a lengthy discussion in
sip-events to talk about dialog lifetimes.

To summarize, we need to be able to send SUBSCRIBEs on existing
dialogs so that we can reach the same terminal that the dialog
"connects" us to. So far, so good.

But there's one more scary, ugly problem: what if we need to send
*two* subscriptions down this same dialog? In the sunshine case,
you can perform demultiplexing based on the event package name.
But let's imagine that there's an event package that defines a
body for the SUBSCRIBE message. This body gives a filter for
what types of events we want to know about. It is quite possible
that the easiest (or only) way to subscribe to the events I'm
interested in would be to install two subscriptions to the same
package with different filter criteria. But when I get a NOTIFY
back, how on earth am I going to be able to tell which subscriptoin
it corresponds to?

The answer we came up with was the "id" parameter. It uniquely
identifies a subscription within a dialog. It's easy to implement,
not really that confusing, and finally ties up the huge barrel of
worms we opened up seven paragraphs ago.

/a

_______________________________________________
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

---

From: Jonathan Rosenberg <[email-masked]>
Date: Mon, 18 Feb 2002 15:16:42 -0500

inline.

> user portion of URIs in the route set.

Indeed, the spec only requires that the scope of the URI in the
record-route be within the dialog. THat is actually not true for
contact, which need to be globally scoped, in order to enable transfer,
for example.

> back, how on earth am I going to be able to tell which subscriptoin

There is a bigger issue here, one we are beginning to scratch the
surface
of. We will only (and should only) touch it a little in bis, but it is
something that requires much more thought. A subject for draft standard,
I think.

The issue is that we are realizing that there is a great deal of value
in very cleanly separating the SIP state from the state of the things
established through it. One such case is the session. Our big pain with
early media was trying to couple sip state (whcih drives applications
and services) with the sesison state. One of the ideas in UNIFY that
vastly simplified the problem was to view them as separate things. Now,
the same is true for a subscription. Its state exists as a separate
thing from the sip state. The problem we are running into here is that
we want one sip dialog to effectively act as a "conduit" for several
"application layer" state processing, such as a subscription or a
session. SIP has never had a clean separation between these layers,
either in management of state, or separation of header functionality. I
think others have made this observation as well, including Dean.

So, for now, we just need to make sure we've got separate identifiers
for these things (we've always had it for sessions; the SDP has a
session ID), and make sure the lifetimes are well specified, even if
mangled a bit. -08 of bis does a much better job of this; I've rewritten
the terminate.tex section such that it really views BYE as termination
of the sesison, not the dialog (of course, termination of the session
implies termination of the dialog, unless an extension, like subscribe,
put others application state within the dialog). So, the functional
behavior is unchanged, but the presentation is more consistent with the
proper split, I think.

-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