I see your point, but even in the scenario you describe, there is a re-INVITE that would convey to the UA updated capabilities. It is OK for this stuff to change during the dialog, but the UAs have to rely on those changes being communicated in signaling. Otherwise, there is no point at looking at things like the Allow header.
cheers, (-:bob -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Paul Kyzivat Sent: Wednesday, March 21, 2012 12:06 PM To: [email protected] Subject: Re: [Sip-implementors] 405 response for UPDATE Ahh, you found an old email of mine. :-) There are many of these things in sip where support for *something* is declared somewhere. For the most part there is no guarantee how long this support is promised to remain, or in what scopes they hold. We could *try* to tighten these up, but doing so would break some things. The use case I usually use to identify such issues is 3pcc - where there is a B2BUA call controller between a caller and a callee. The controller may usually try to act like a proxy - relaying requests to the other end. But this means it has to reflect the capabilities and limitations of one end to the other, because otherwise it may be asked to do something that it can't forward and can't emulate. The controller can then do a transfer, replacing one of the endpoints with a new one. The other end doesn't see this as a transfer, just a reinvite. But once this is done, the new endpoint might not have the same capabilities and restrictions as the old one. So the controller may have to report the change. To the unchanged endpoint this will appear as a mid-dialog change of its peer's capabilities. It could show up as a 405. Thanks, Paul On 3/21/12 10:06 AM, harbhanu sahai 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 > _______________________________________________ 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
