>From these threads, we can infer that Allow header may carry different content at different times of the dialog. But the base rule to be followed could be as follows.
UA1 ---------------------------------> UA2 INVITE sip:[email protected] SIP/2.0 Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, UPDATE, SUBSCRIBE, NOTIFY SIP/2.0 200 OK (for INVITE request) Allow: INVITE, ACK, CANCEL, OPTIONS, BYE <-------------UPDATE **acceptable** -----200-UPD-----> For some reason UA1 don't want to support UPDATE from now on within this dialog. OPTIONS ----> Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, <-------------UPDATE **NOT acceptable** -----405-UPD-----> On Wed, Mar 21, 2012 at 7:36 PM, harbhanu sahai <[email protected]>wrote: > Also, as per 3261 the Allow header present in provisional is valid untill > the dialog is in early state. > > Header fields present in a provisional > response are applicable as long as the dialog is in the early state > (for example, an Allow header field in a provisional response > contains the methods that can be used in the dialog while this is in > the early state). > > On the other hand for Allow present in 2xx, lists methods supported for the > "duration of call" > > A 2xx response to an INVITE SHOULD contain the Allow header field and > the Supported header field, and MAY contain the Accept header field. > Including these header fields allows the UAC to determine the > features and extensions supported by the UAS for the duration of the > call, without probing. > > Found an old archive which underscores the point that the Allow header > content can be updated within a dialog. > > https://lists.cs.columbia.edu/pipermail/sip-implementors/2008-August/020143.html > > > But now what's confusing is this -- > "The scope of these things is very unclear. About all you can > ***reliably **assume > is that they are true at the time they are conveyed***. " > > Regards, > Harbhanu > > On Wed, Mar 21, 2012 at 6:55 PM, Bob Penfield <[email protected] > >wrote: > > > I guess that depends on your interpretation of integral to the usage. If > > the UA is using UPDATE which includes SDP to modify the session > parameters, > > it is important for that session. 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? Why would UPDATE be OK at the beginning of > > the session and then not be OK later? 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 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 > > > _______________________________________________ > Sip-implementors mailing list > [email protected] > https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors > -- Thanks, Nataraju A.B. _______________________________________________ Sip-implementors mailing list [email protected] https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
