inline
>-----Original Message----- >From: [email protected] [mailto:[email protected]] On Behalf Of Eric >Burger >Sent: Friday, March 06, 2009 4:56 PM <snip> > >On Feb 16, 2009, at 7:18 PM, Brett Tate wrote: > <snip> >> Section 4.3: When sending a 489, it indicates "MUST terminate the >> INVITE dialog". The "MUST terminate" seems severe even if all the >> negotiation race conditions are adequately addressed. The mentioned >> "protocol failure" reason seems contrary to the "strictly send and >> lenient receive" mantra. > >Maybe living in New Hampshire has made me more conservative. A lot of >folks will today say that while "Be conservative in what you send and >liberal in what you receive" may have been the greatest mistake we >ever made in protocol design. Let us look at this from a practical >perspective. If you are a bad implementor and send a 489 you didn't >mean to, who knows what else you will get wrong. Conversely, if you >are a bad implementor and forget to tear down a 489-ed INFO, bad >things probably will not happen. > >I will defer to the WG on this one. Any other opinions? RFC 5057 indicates that a 489 should destroy the dialog usage. However, it also says: (12) 489 Bad Event: In our example scenario, [5] declares that the subscription usage in which the NOTIFY is sent is terminated. This response is only valid in the context of SUBSCRIBE and NOTIFY. UAC behavior for receiving this response to other methods is not specified, but treating it as an unknown 4xx is a reasonable practice. I'm inclined to say that since the INFO is not suppose to change dialog state, a 489 response to an INFO should not destroy the INVITE dialog usage. With SUBSCRIBE/NOTIFY its a failure of the dialog establishing/target-refresh request which is essential to the dialog usage. But INFO is not essential to the INVITE dialog usage, so applying the last sentence above makes sense to me. cheers, (-:bob _______________________________________________ Sip mailing list https://www.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
