> -----Original Message----- > From: [EMAIL PROTECTED] [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? 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. _______________________________________________ Sip-implementors mailing list [EMAIL PROTECTED] http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
