Please see inline... -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Harbhanu Sent: Tuesday, June 29, 2010 1:44 PM To: 'Vikram Chhibber' Cc: [email protected] Subject: Re: [Sip-implementors] Retrans 2xx handilng - RFC-4028
>> 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 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. 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'. [MSW] Yes, if you just take the retrans 2xx in isolation you are right. But if you consider the complete end to end scenario, retrans of 2xx is just due to delay in relaying that 2xx, because in-principle UPDATE would have started its transaction after completing the INV transaction [including ACK]. 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 _______________________________________________ Sip-implementors mailing list [email protected] https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
