Hi Ravi, Best approach would be for the UAC to strip off header or replace with same header value as in INVITE during early dialog transactions.
In case, if there is no control to modify UPDATE then other way is to handle as glare condition as explained in UPDATE RFC 3311 for handling offer/answer negotiation with colliding UPDATE-UPDATE or UPDATE-INVITE. IMO, this case can be treated under glare condition scheme. Regards, Manjunath -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Ravi Kumar Sent: Wednesday, October 20, 2010 2:52 PM To: [email protected] Subject: [Sip-implementors] Regarding Rfc 4028 _____ From: Ravi Kumar [mailto:[email protected]] Sent: Friday, October 15, 2010 7:27 PM To: ''[email protected]' Subject: Regarding Rfc 4028 Hi All, I have call flow Like below. UE UE | | --------Inv----------> (Session Expire: 1800) | | <----------183----- | | ------update------->(Session Expire: 1600) | | <-------200-update (Session Expire: 1600;refresher=uas) | | <-------200-Inv--- (Session Expire: 1800;refresher=uas) | | Doubt: 1. When UAC is negotiating session timer value with INVITE request, and session timer negotiation is not completed then UAC should not start negotiation with UPDATE request. Because this behavior not defined by RFC-4028. How does other implementation handles this at UAS side. And UAC should send UPDATE request with Session Expire header when INVITE negotiation is not completed. 2. Can UPDATE request start Session timer negotiation, because it is used for session timer refresher? 3. What does RFC-4028 last response mean? **************************************************************************** **************************** This e-mail and attachments contain confidential information from HUAWEI, which is intended only for the person or entity whose address is listed above. Any use of the information contained herein in any way (including, but not limited to, total or partial disclosure, reproduction, or dissemination) by persons other than the intended recipient's) is prohibited. If you receive this e-mail in error, please notify the sender by phone or email immediately and delete it _______________________________________________ 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
