> -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@;cisco.com] > > [EMAIL PROTECTED] continued: > > > > About the new SUBSCRIBE within a SUBSCRIBE dialog scenario, > are you suggesting that it is possible subscribe to different > events using the same dialog? > > Yes. This is explicitly mentioned in RFC 3265. > > > If so, then should this really be allowed and why? > > I can't answer that. I think life would have been a lot > simpler if dialogs were never shared. I presume somebody > decided they were expensive enough that it would be valuable > to share them.
This issue is raised so often that I might just need to add it as an explanitory appendix to the next version of the spec. This behaviour stems naturally from being able to share dialog between INVITE and SUBSCRIBE. The fundamental problem is that without sharing the dialog, there is no way to make sure that you land on the same UAS. Intervening proxies can have various routing logic (e.g. round-robin, time-of-day, etc) that would end up sending you to a different server than you are currently communicating with. That is sometimes unacceptable. Take, for example, the case in which I want to subscribe to some state of the terminal to which I'm currently in an INVITE dialog. Into this mix, add the possibility that I might want to subscribe to more than one aspect of your terminal -- different event packages, perhaps, or maybe even the same event package with different parameters (e.g. filters). That forces us to have the ability to have *two* subscriptions within a dialog. And that's where we are today. If you can come up with a better scheme, I'm all ears. This issue is more protocol development than implementatation, so followups to the SIP WG mailing list, please. /a _______________________________________________ Sip-implementors mailing list [EMAIL PROTECTED] http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
