+1
Michael Procter wrote: > Scott Lawrence wrote: >> On Thu, 2009-04-02 at 10:03 +0100, Stephen Paterson wrote: >>> Hi all, >>> Thanks for your replies. Lots of answers saying I'll only get a single >>> 200. Sorry, bit of a slip on my part there! Ignore the '200/' and you'll >>> get my meaning. >>> Anyway, just to finish off, I'll be adding a flag so that the user can >>> say whether they want to accept multiple dialogs or not. The application >>> should not have to manage individual dialogs unless it really has to and >>> it's far simpler for me to reject all NOTIFYs subsequent to the initial >>> one than it would be for the application. >> That's a bad idea. The application should always expect that any >> SUBSCRIBE might fork and be prepared for multiple subscriptions >> (dialogs) as a result. >> > > On the face of it, that seems reasonable. But RFC3265 explicitly > requires event packages define whether or not multiple dialogs should be > supported. If they are not, it gives a procedure to achieve this > (reject the NOTIFY with 481). This seems like a reasonable feature for > Stephen's API to provide. > > Just out of curiosity, I checked the 12 event packages (with RFCs) > currently registered, and only 4 permit multiple subscriptions! > Consistent handling of the remaining 8 sounds like a good idea under > these circumstances. > > Michael > _______________________________________________ > Sip-implementors mailing list > Sip-implementors@lists.cs.columbia.edu > https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors > _______________________________________________ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
