Hi Bob, Reply inline.
> -----Original Message----- > From: Bob Penfield [mailto:[email protected]] > Sent: Wednesday, March 21, 2012 9:26 AM > To: Brett Tate; Kashif Husain; [email protected] > Subject: RE: [Sip-implementors] 405 response for UPDATE > > I guess that depends on your interpretation of integral to the usage. >From a RFC 5057 perspective, my understanding is that it would be the methods >required for the usage. However as always, the UA can decide to terminate the dialog anytime it wants. For instance if a UA knows that INFO is important for the specific session, the UA can terminate a dialog usage because the other side doesn't support INFO even though RFC 5057 indicates that the INFO 405 should only terminate the transaction. > If the UA is using UPDATE which includes SDP to modify the session > parameters, it is important for that session. Yep. > What is the UA supposed to do? It was told that it could > use UPDATE, so it did. Is it supposed to try UPDATE and > then if that fails use INVITE? It can do whatever it wants. It received a 405 indicating UPDATE no longer supported. Thus if it wants to allow the call to continue and attempt the modification/refresh again, it should send re-INVITE. > Why would UPDATE be OK at the beginning of the > session and then not be OK later? As far as I know it is mostly just a B2BUA side effect. > If there were no other transactions that included > an Allow header, how is the UA supposed to know that > it is not OK now? If that is the case, then the > Allow header is useless. It isn't useless; however a 405 is possible. > It just does not make sense. > > > cheers, > (-:bob > > > > > -----Original Message----- > From: Brett Tate [mailto:[email protected]] > Sent: Wednesday, March 21, 2012 8:52 AM > To: Bob Penfield; Kashif Husain; [email protected] > Subject: RE: [Sip-implementors] 405 response for UPDATE > > 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
