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

From: "Fairlie-Cuninghame, Robert" <[email-masked]>
Date: Mon, 18 Feb 2002 15:24:34 -0800

Adam,

Thank you for the explanation on the design purpose for the Event header Id
parameter.

I wonder though if this seems to be running in the same direction that
transporting DTMF in INFO was heading - catering only to application servers
which are B2BUA's. Why should B2BUA's get special treatment? Surely this is
only encouraging them - if you want to make sure that a SUBSCRIBE works then
your applications server should be a B2BUA. What if a proxy on an INVITE
dialog wants to subscribe? 

Now I don't think this is necessarily contrary to the Id parameter but the
way you justify the complexity added by the Id parameter scares me.
Basically, if you are solving the problem for an UA endpoint delivering a
subscription through an existing INVITE dialog then IMO you must also
address how a proxy can also accomplish this in an equally guaranteed
manner. I will say it again, otherwise the only reliable way application
developers have of **reliably** creating a subscription that is associated
to an INVITE-initiated dialog is to build their server as a B2BUA. [Actually
I believe that in most cases you actually want to associate the subscription
to the user endpoint's conversation-space rather than to the INVITE-dialog
itself ... but that's a whole different email and is largely independent to
how the SUBSCRIBE is delivered. :)]

So, yes, it's a little messy but not too conceptually difficult and REALLY,
REALLY needs to be done to avoid huge headaches when people start trying to
use advanced call control primitives and multiple application interactions
with B2BUA's. [all part of Jonathan's big ball of pain]

That's my view at any rate - we really don't want to encourage B2BUA's
anymore than we have to. :)

Regards,

Robert.

> -----Original Message-----
> From: Adam Roach [mailto:[email-masked]]
> Sent: 18 February 2002 19:36
> To: 'Fairlie-Cuninghame, Robert'
> Cc: [email-masked]'
> Subject: Event ID (was RE: Events Last Call.)
> 
> 
> 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: Adam Roach <[email-masked]>
Date: Mon, 18 Feb 2002 18:31:04 -0500

> manner. 

I hat B2BUAs at least as much as you do, and fully understand your
objection. As soon as you propose something that works, I'll
incorporate it.

/a