> -----Original Message----- > From: Dean Willis [mailto:[EMAIL PROTECTED] > > On Oct 15, 2007, at 1:26 PM, Brian Stucker wrote: > > How does 3265 make this any better? > > > 3265 makes it better in two ways: > > 1) It provides distinct dialogs for each channel of the mux. Thus, > two events of the same class, but related to different subscriptions, > can be distinguished. > > 2) It provides semantic distinction, such that two events that > transport the same kind of content but that have different effects on > the application can be distinguished. > > The provide NOTIFY-over-an-INVITE dialog loses advantage 1, but > retains 2. The argument is that this makes it good enough for some > applications. However, there are obviously applications where it > might NOT be good enough, and a separate dialog ala 3265 would be > required.
Actually, I'd argue the converse as well: there are applications where "advantage 1" is a disadvantage, or at least potentially confusing. DTMF is a primary example of this. If two app servers kpml subscribe to my Invite dialog, I will send them both the dtmf event, assuming the regex works out. Which one should act on it? They both will. Neither knows about the other. (although I should note I don't think supporting two kpml subscriptions is even required by rfc4730, which makes it even less deterministic, and gives up "advantage 1" anyway) -hadriel _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use [EMAIL PROTECTED] for questions on current sip Use [EMAIL PROTECTED] for new developments on the application of sip
