I think if you want to do away with the hassle of Offer-Answer for updating a specific SIP header value, using UPDATE is the better option. A RE-INVITE will inevitably lead to a re-negotiation irrespective of whether any media information has changed or not.
I understand that from an implementation point of view, it's a very inefficient mechanism to redo the negotiation with a RE-INVITE even if nothing has changed for the ongoing session. That is precisely the reason UPDATE method is in place. Regards, Gaurav -----Original Message----- ********************** Legal Disclaimer **************************** "This email may contain confidential and privileged material for the sole use of the intended recipient. Any unauthorized review, use or distribution by others is strictly prohibited. If you have received the message in error, please advise the sender by reply email and delete the message. Thank you." ********************************************************************** From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Paul Kyzivat Sent: Tuesday, November 22, 2005 3:13 AM To: Ansari, Mohammed Cc: [email protected] Subject: Re: [Sip-implementors] Re-Invite to refresh a poc session Ansari, Mohammed wrote: > I am a bit unclear on the use of re-Invite to "modify" a specific sip > header value. (example is the case of OMA POC where session-expires > header is used to inform the server about the request session expires > interval). UPDATE can be used but it is discouraged to be used after > session establishment in favor of re-Invite per UPDATE specification. > > Using re-Invite for session refresh brings out the issue of the sdp that > was previously negotiated: > > A) If no sdp is provided in the re-INVITE (since the purpose of this > type of re-INVITE is not negotiating sdp parameters but modify sip > header only), RFC3261 indicates that an offer will come in the response > to the re-INVITE. This is not desired. Hence this option is not taken. > > B) Is it ok to re-offer identical sdp offer as the first INVITE? Is > there a GUARANTEED way to ensure that the receiving end will NOT process > is this identical sdp and send a different answer? The specifications > are not clear on the no-op case. > > Can someone comment on the use of re-INVITE to modify a sip header and > not have to deal with sdp offer/answer re-negptiation? If you use reinvite then you MUST be prepared to deal with offer/answer re-negotiation - there will be an offer/answer. The offer MAY include the same SDP currently in use by the offerer, but it is not required to be the same. IF the offer is the same, then the answer MAY be the same, but need not be. But I don't understand why this is such a big deal. A reinvite that changes things can come at any time, whether you want it or not, so you must be prepared to deal with it. At the same time, such a reinvite may not change anything, so you probably want to have an easy path through your code if important things don't change. So, when you want to do something that uses a reinvite, just send it off, changing the things you want to change and proposing to keep other things unchanged. Then just deal with whatever happens. Paul _______________________________________________ Sip-implementors mailing list [email protected] http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors _______________________________________________ Sip-implementors mailing list [email protected] http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
