On Mon, Jun 28, 2010 at 10:44 PM, Harbhanu <[email protected]> wrote: >>> Yes. But you should promptly ACK the received 2xx. > Even sending a prompt ACK doesn't guarantee that the there will be no > further 2xx retransmission. This is correct. The UAS will retransmit till it gets ACK for 2xx. In your case, you never sent ACK. > > >>>This seems to be a problem with the UAC behavior. It should not send >>>UPDATE unless it has sent ACK and INVITE offer/answer has been >>>completed. > Here, what if we consider that the offer is in INVITE and thus answer would > be there in 2xx. Even if the offer is in INVITE and the answer comes in 2xx, the UPDATE is likely to be rejected by 491 response as for the UAS, it never got for the ACK for 2xx and was never sure that the answer reached the UAC. In normal case when you send ACK and then UPDATE immediately, this race condition that resulted in 491 response for UPDATE may still happen when UPDATE crosses ACK. The UPDATE needs to recover from 491 response.
> > Actually this queries initiates two issues - > > 1. INVITE and UPDATE handling - > IMO here we need to consider the extensions defined in draft- > 'http://tools.ietf.org/html/draft-ietf-sipcore-reinvite-04#section-3.5' > Did you also mean the same ?? > > 2. Handling retransmissions of 2xx(INVITE) - > Should we restart session timer here or not? > Although, I am not quite sure whether can we consider the retrans issue in > isolation, but if that is so we can restart the timer, since retrans 2xx > also indicates that the peer is 'still alive'. > Retransmissions are not supposed to be processed again. They are meant for reliable delivery over un-reliable transport. In your case, retransmissions happened not because of packet loss, it happened because UAC did not sent ACK. Even if you are resetting session-timer for every received 2xx, what is the guarantee that the UAS is doing the same when it is sending 2xx everytime? > Thanks for your reply! > > Regards, > Harbhanu > > **************************************************************************** > *********** > 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! > > -----Original Message----- > From: Vikram Chhibber [mailto:[email protected]] > Sent: Monday, June 28, 2010 11:17 PM > To: Harbhanu > Cc: [email protected] > Subject: Re: [Sip-implementors] Retrans 2xx handilng - RFC-4028 > > On Mon, Jun 28, 2010 at 3:06 AM, Harbhanu <[email protected]> wrote: >> Please consider the below mentioned scenario. Here, should session timer > be >> restarted/'re-handled' when retransmitted 2xx is received? >> >> >> >> UAC UAS >> >> | | >> >> |INVITE | >> >> |--------------------->| >> >> | 2xx | >> >> |<---------------------| >> >> | | >> >> |UPDATE | >> >> |--------------------->| >> >> | 2xx-UPDATE| >> >> |<---------------------| >> >> | | >> >> | 2xx(re-trans)| >> >> |<---------------------| >> >> | | >> >> >> >> >> >> IMO even though not explicitly mentioned in RFC-4028, we should ignore >> retransmissions of 2xx of refresh requests. > Yes. But you should promptly ACK the received 2xx. >> >> Since, this might have issue in consistent/alike handling of 2xx for ALL >> session refresh requests, since there is a fundamental difference between >> INVITE and UPDATE at transaction layer itself. Otherwise too, here UPDATE >> could change many other parameters such as SE value & refresher, which >> needn't be reverted after receiving 2xx of INVITE. > This seems to be a problem with the UAC behavior. It should not send > UPDATE unless it has sent ACK and INVITE offer/answer has been > completed. >> >> >> >> Please share your opinion. Thanks! >> >> >> >> Regards, >> >> Harbhanu >> >> >> >> > **************************************************************************** >> *********** >> 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
