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

[hisham.khartabil@nokia.com]

redirected to sip...

> -----Original Message-----
> From: ext Adam Roach [mailto:adam@dynamicsoft.com]
> Sent: Tuesday, November 05, 2002 9:40 PM
> To: Khartabil Hisham (NMP/Helsinki); Adam Roach;
> sip-implementors@cs.columbia.edu
> Cc: brett@broadsoft.com
> Subject: RE: [Sip-implementors] Questions about Dialogs
> 
> 
> > -----Original Message-----
> > From: hisham.khartabil@nokia.com [mailto:hisham.khartabil@nokia.com]
> > 
> > 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 sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip