If UPDATE was integral to the INVITE usage, it would have been defined within RFC 3261.
> -----Original Message----- > From: Bob Penfield [mailto:[email protected]] > Sent: Wednesday, March 21, 2012 8:50 AM > To: Brett Tate; Kashif Husain; [email protected] > Subject: RE: [Sip-implementors] 405 response for UPDATE > > Then does that mean the RFC 5057 is incorrect when it says: > > (3) 405 Method Not Allowed: > > 501 Not Implemented: > > Either of these responses would be aberrant in our example > scenario since support for the NOTIFY method is required by the > usage. In this case, the UA knows the condition is unrecoverable > and should stop sending NOTIFYs on the usage. Any refresh > subscriptions should be rejected. In general, these errors will > affect at most the usage. If the request was not integral to the > usage (it used an unknown method, or was an INFO inside an INVITE > usage, for example), only the transaction will be affected. > > Typically UPDATE is integral to the INVITE usage. > > > cheers, > (-:bob > > > > > -----Original Message----- > From: [email protected] [mailto:sip- > [email protected]] On Behalf Of Brett Tate > Sent: Wednesday, March 21, 2012 8:46 AM > To: Kashif Husain; [email protected] > Subject: Re: [Sip-implementors] 405 response for UPDATE > > > Is this a valid behavior? > > Is it allowed to send 405 in this scenario? > > Yes; the behavior is valid. Just because UPDATE was allowed, it > doesn't mean that it must continue to be allowed. > > However, the behavior that you are describing is more prevent with > B2BUAs reconnecting dialogs that do and don't support UPDATE. > > > _______________________________________________ > Sip-implementors mailing list > [email protected] > https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors _______________________________________________ Sip-implementors mailing list [email protected] https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
