Subject: RE: [Sip] RE: [Sip-implementors] Questions about Dialogs

From: [email-masked]
Date: Wed, 27 Nov 2002 11:41:55 +0200

I would like to continue discussing this issue...

In RFC3261, its says:

"For dialogs that have been established with an
   INVITE, the only target refresh request defined is re-INVITE (see
   Section 14). "

RFC3265 doesn't mention anything to extend the above statement about target refresh requests, nor does sip-refer.

Now, is it a general rule that any sip extension that creates a dialog, is allowed to refresh the target of an existing dialog? This is not mentioned anywhere.

eg: dialog created with INVITE can be target refreshed with REFER and SUBSCRIBE. A new extension FOO also creates dialog and therefore is a target refresh request for INVITE. BAR on the other hand is a sip extension that doesn't create a dialog and therefore is not a target refresh request for INVITE.

My sip stack has to be aware of all extensions is order to know which method creates dialogs and which one doesn't, and then decide if a target is to be refreshed or not.

I must admit, that if I extend Adam's scenario below in that the subscription is now terminated and the dialog still exists (because of the INVITE), then targeting is valuable. But in this scenario valuable enough?

I would like to hear from developers how they handled this situation, if any.

Regards,
Hisham

> -----Original Message-----
> From: ext [email-masked] 
> [mailto:[email-masked]]
> Sent: Wednesday, November 06, 2002 10:23 AM
> To: [email-masked]; [email-masked]
> Cc: [email-masked]
> Subject: [Sip] RE: [Sip-implementors] Questions about Dialogs
> 
> 
> redirected to sip...
> 
> > -----Original Message-----
> > From: ext Adam Roach [mailto:[email-masked]]
> > Sent: Tuesday, November 05, 2002 9:40 PM
> > To: Khartabil Hisham (NMP/Helsinki); Adam Roach;
> > [email-masked]
> > Cc: [email-masked]
> > Subject: RE: [Sip-implementors] Questions about Dialogs
> > 
> > 
> > > -----Original Message-----
> > > From: [email-masked] 
> [mailto:[email-masked]]
> > > 
> > > May I suggest that we only allow target refresh requests to 
> > > have the same method as the request that created the dialog. 
> > > i.e.: only a reINVITE can be target refresh requests for a 
> > > dialog created by INVITE, only reSUBSCRIBE can be target 
> > > refresh requests for a dialog created by SUBSCRIBE.
> > > 
> > > For a dialog created by INVITE, a SUBSCRIBE does not update 
> > > the target. For a dialog created by SUBSCRIBE, an INVITE does 
> > > not update the target.
> > > 
> > > This is the only way to do it to avoid complexity and 
> > > confusion. Otherwise you got to start asking about REFER and 
> > > other extensions that create dialogs.
> > > 
> > > I would prefer implementors to be able to build a generic 
> > > dialogs module in their stack that doesn't need to know about 
> > > methods. I mean what if I send a MESSAGE within a dialog? my 
> > > generic dialogs module no longer can be method agnostic 
> > > because it has to know that MESSAGE does not refresh a 
> > > target, but it has to know that SUBSCRIBE does... too complicated.
> > 
> > How does your generic dialogs module know not to create a dialog
> > when you send a MESSAGE that doesn't correspond to an existing
> > dialog?
> 
> Its up to the user of the module to know. Like a session 
> module on top of it. I don't want to update my dialogs module 
> for every extension. I'll just build modules on top of it. 
> Anyway, this is too much architecture stuff.
> 
> > 
> > You already need to keep track of a variety of attributes for
> > each method, such as which messages can start a dialog and which
> > can't; in other words, you can't have generic handling for
> > unknown methods. You must assign them attributes before your
> > dialog manager can do anything sensible. 
> > 
> > Tracking which method initiated a dialog is no more complicated
> > than tracking which methods can retarget.
> > 
> > That said, allowing only the initiating method to retarget can be
> > a rather severe restriction. I may have application logic that
> > knows that it needs to retarget at some point, and it does
> > so by sending an INVITE. However, with your proposal, that
> > would fail if the dialog had been created with a SUBSCRIBE*.
> > Instead, you'd need the application to keep track of which came
> > first and use it for retargeting. Now, that seems messy.
> > 
> > /a
> > 
> > * What? How would one plausibly get an INVITE on a dialog
> >   created by a SUBSCRIBE, you ask? I'm glad you did. Imagine
> >   that I've subscribed to the terminal state of the phone
> >   on your desk, because I want to get ahold of you as soon
> >   as you get off the phone. When I finally get a NOTIFY to
> >   let me know that your terminal has transitioned to a "free"
> >   state (i.e. on-hook), I want to send an INVITE. Of course,
> >   I want to make sure I only contact that one terminal that
> >   just became free. The only way I can reliably do this is
> >   by sending an INVITE in the same dialog. There you go.
> 
> This example doesn't clarify the need for an INVITE to 
> retarget a dialog initiated with a SUBSCRIBE. Its actually 
> saying that an INVITE needs to use the same target that was 
> established with the SUBSCRIBE.
> 
> Regards,
> Hisham
> 
> _______________________________________________
> 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
> 
_______________________________________________
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: Robert Sparks <[email-masked]>
Date: 27 Nov 2002 09:50:55 -0600

> Now, is it a general rule that any sip extension that creates a dialog, is allowed to refresh the target of an existing dialog? This is not mentioned anywhere.

I don't think we will find value in attempting to make a SUBSCRIBE
dialog and and INVITE dialog different things if they share the same
dialog identifiers. The state between them is inherently coupled (at
the least because of CSeq management), so attempting to decouple them
is doomed to sprawling complexity from the start. I believe it is better
to model shared dialog state as exactly that, and share all of it in the
same way. Thus, any method that can create a dialog can also refresh
a dialog, and "refresh" must always mean the same thing without regard
to method name. Otherwise, we are going to create _deep_ wells of
confusion, race and edge conditions. The easiest ones to see are those
involving CSeq management. 

I understand that this tight coupling is ugly. It would be very nice to
have a separate piece of code deal with subscribes and invites, but
if you want to share the dialog identifiers, you can't. You at least
have to have the dialog management part in common (because of the CSeq
issues).

The better path to pursue is to find a good answer to the "Globally
addressable URI problem" and provide a mechanism to associate two
dialogs. Then we can avoid these nasty issues by never attempting to
share dialog state this way.

> My sip stack has to be aware of all extensions is order to know which method creates dialogs and which one doesn't, and then decide if a target is to be refreshed or not.

If you do not know the extension, you will reject the request and don't
affect any existing dialogs. This is the same for methods you do know -
if you reject a re-invite, the dialog that re-invite appeared in is 
unaffected (well, almost unaffected. You have to update the remote
CSeq).