In that case the change can be communicated in the signaling be having UPDATE absent from the Allow header in the 200-OK and/or ACK. My point is that if the most recent signaling message (INVITE and/or 18x) included UPDATE in the allow header, then the other end ought to be able to send UPDATE without it being rejected with 405.
cheers, (-:bob -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Mia Cizmic Sent: Wednesday, March 21, 2012 11:23 AM To: Kashif Husain; [email protected] Subject: Re: [Sip-implementors] 405 response for UPDATE Hi, I suppose your far-end entity supports UPDATE for early dialogs, but not after the dialog is confirmed, as RFC 3311 says: "Although UPDATE can be used on confirmed dialogs, it is RECOMMENDED that a re-INVITE be used instead." Regards, Mia -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Kashif Husain Sent: Wednesday, March 21, 2012 1:33 PM To: [email protected] Subject: [Sip-implementors] 405 response for UPDATE Hello SIP implementors, I have a far-end entity which sends UPDATE in Allow header but when I send UPDATE for session refresh I get 405 Method Not Allowed. Is this a valid behavior? Is it allowed to send 405 in this scenario? If yes then I would like know the reason behind it. Thank you very much in advance. Regards, -kashif _______________________________________________ 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
