Mia, The UPDATE is sent for session refresh. It can be done using re-INVITE but RFC 4028 recommends using UPDATE.
"A re-INVITE generated to refresh the session is a normal re-INVITE, and an UPDATE generated to refresh a session is a normal UPDATE. If a UAC knows that its peer supports the UPDATE method, it is RECOMMENDED that UPDATE be used instead of a re-INVITE. A UA can make this determination if it has seen an Allow header field from its peer with the value 'UPDATE', or through a mid-dialog OPTIONS request. It is RECOMMENDED that the UPDATE request not contain an offer [4], but a re-INVITE SHOULD contain one, even if the details of the session have not changed." Thanks, -kashif On Wed, Mar 21, 2012 at 8:53 PM, Mia Cizmic <[email protected]> wrote: > 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
