Subject: Dialog Tunnelling == bad (Was: [SIP] Event ID)

From: "Fairlie-Cuninghame, Robert" <[email-masked]>
Date: Tue, 19 Feb 2002 14:56:44 -0800

Hi all, 

My food for thought for the day:

This is not so much an objection to the Event header Id parameter but I
wanted to raise my concern that this idea of tunnelling subscriptions (or
other sub-dialog, e.g. REFERs) through INVITE initiated dialogs (or other
any dialog) - I believe it is running in the wrong direction. 

I completely agree with Jonathan that we need to separate session state from
sip dialog state. I believe you are trying to accomplish this with your
concept of extending a "session dialog" concept by encompassing all
tunnelled sub-dialogs. I believe this is analogous to trying to implement
call-control by doing "funky" stuff in B2BUA's using a single dialog - e.g.
DTMF in INFO - it works _very_ well for some application models but falls
down quickly when you try to use MUTLIPLE DIALOGS! This is why it is so hard
to kick DTMF in INFO - it works so well for the B2BUA model but falls apart
when you start using REFER/Replaces/etc/etc.

The separation of session state from dialog state should revolve around
SESSIONs being defined in terms of CONVERSATION-SPACEs. Now conversation
spaces revolve around the call-control primitives and MULTIPLE dialogs. 

Encouraging REFER's and SUBSCRIBE's to be tunnelled through INVITE initiated
dialogs makes it very difficult to work with conversation spaces. The reason
for this is that you have now muddied the association between the original
INVITE dialog and existence of the residual dialog where the dialog would
not otherwise be in the conversation-space. This approach simply complicates
conversation spaces and the use of call-control primitives such as
REFER/Replaces/Join, etc - an area which is already complicated enough.

So let me give a couple of rough examples. For starters the conversation
space model must be rewritten to differentiated between what is a "real
conversation space dialog" participant and what is a "residual dialog that
has been terminated but is still hanging around because it is acting as a
conduit for a SUBSCRIBE or REFER" dialog. This is a TERRIBLE complication to
the conversation space concept - perhaps terminally. 

For instance, unless you redefine the conversation space very carefully, a
INVITE-initiated dialog that is currently only being used by a subscription
to a conversation-space will stop a conversation space (as currently
written) from ending. The conversation-space must be redefined not in terms
of dialogs but in terms of sub-dialogs which incidentally usually won't even
exist when the INVITE dialog is first received. Obviously this is not an
unsolvable problem but it shows the tip of the iceberg in terms of wide
ranging complications introduced. 

Likewise, the handling of all call-control primitives such as
Replace/Join/etc etc is complicated by the fact that an INVITE-initiated
dialog may exist but its no longer being used for an INVITE sip session. 

So what are we trying to accomplish? We are trying to guarantee that if a
path for an INVITE dialog is established, then subsequent dialogs from some
entity along that call path can also establish a new dialog fairly reliably.
So the requirement is that the network and UA treats the new dialog
identically for routing purposes but is recognized as *NOT* the same dialog
(so that it won't be torn down at the same time). This is a problem with
backward compatibility but I feel it is better than going down the other
road of sub-dialogs!!

Shouldn't we be working not making sure that we put together guidelines so
that Route headers are portable/usable by "companion dialogs" from entities
on the same call path. IMO, this is the direction we should be heading and
not to the B2BUA infested waters of sub-dialogs.

I would say even that (perhaps counter-intuitively) backwards compatibly is
MORE of a problem with this new sub-dialog concept than with trying to do
things correctly with Route headers. At least you know if a set of
pre-loaded Route header fail when everything has its own dialog (and
probably has a good chance of working even with today's proxies); however,
when trying to have multiple sub-dialogs use the same call transaction id
you have NO idea whether a proxy will drop all sub-dialogs when the first
BYE comes along! I think that is something worth thinking about!

<Donning flame retardant suit now. :)>

Cheers,

Robert.

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

_______________________________________________
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