It is a design feature of KPML, in fact, an advance in the state of the art, for multiple, independent, unrelated applications to subscribe for user stimulus from the same device.
Making multiple subscription handling at the device optional and not mandatory was, IMHO, an unfortunate loss at the hands of work group consensus. However, stating that it is non-deterministic is incorrect. The subsequent subscribers know reliably the device rejected their subscription request. On 10/16/07 6:59 PM, "Hadriel Kaplan" <[EMAIL PROTECTED]> wrote: > > >> -----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 Notice: This email message, together with any attachments, may contain information of BEA Systems, Inc., its subsidiaries and affiliated entities, that may be confidential, proprietary, copyrighted and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it. _______________________________________________ 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
