Based upon rfc3311 sections 5.1 and 5.2, returning a 504 response would appear to be a decent response for indicating that the sdp modification should be done with a re-INVITE instead of an UPDATE.
However based upon experience, I don't recommend indicating support for UPDATE when only support UPDATE without sdp. The following are two of the reasons. 1) Some vendors interpret rfc3311 to indicate that the sdp must be included. 2) Some vendors release the call upon receiving a 504 response instead of (delaying if needed and) subsequently sending a re-INVITE instead. > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf > Of Barry Ostroff > Sent: Thursday, December 14, 2006 1:18 PM > To: [email protected] > Subject: [Sip-implementors] Can a UA only support UPDATE for > session timerrefreshes? > > If a UA wants to support UPDATEs for session timer refreshes only (RFC > 4028) and it always includes > an Allow header, should it advertise support for UPDATE or > not? If it does, this implies full support of RFC 3311. But > if the UA does advertise UPDATE support, it would need to > reject any UPDATE that includes a body. What would that > response look like (405, 488, ???)? What if such an UPDATE > included a refresh along with a body. What would the > rejection say about the success or failure of the timer > refresh? Would this behavior have any affect on potential > re-INVITE behavior (i.e. the remote UA says "Hey, no support > for any body type - so, I can't even reINVITE)? Might the > remote UA just terminate the dialog in this case? Or, should > the local UA not include UPDATE in an Allow header, but > process a session timer refresh in an UPDATE if it gets one > (and reject ones with a body with a 405)? > If the local UA does not advertise UPDATE support, then will > the remote UA even bother to send UPDATEs for timer refreshes? > > Barry Ostroff > Magpie Telecom Insiders _______________________________________________ Sip-implementors mailing list [email protected] https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
