Hello Indresh , Theoretically we can have both infinite offer-answers and an infinite memory model as well :) Practically I guess we may need to limit it according to the system on which we are implementing our UAC... Also do you need to preserve the copy of the entire ACK message? you can remember the transaction object for the timer duration and generate the ACK each time you get a retransmitted 200 .
As for the scenario is concerned, how about the late media call? i.e. offer carried in 200 OK and answer in ACK ? I think you will be hard pressed to do this in the transaction layer... Regards, Sayan -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Singh, Indresh Sent: Thursday, March 17, 2005 7:58 PM To: '[EMAIL PROTECTED]' Cc: Shetty, Sathish Subject: [Sip-implementors] Saving ACK in the UAC core !! Hi, I have this concern regarding the UAC core ACK retransmission logic. As per the RFC-3261 after getting a 200 OK from the UAS, UAC should free the transaction, pass the event to the UAC core and the UAC core will send an ACK ( thus ensuring reliability of the final response). Now UAC has to save this ACK for 64 * t1 secs. The problem is that let us say if the UAC core is the dialog/session layer in an implementation. Then copy of the first ACK is saved in the dialog/session layer and a Timer is run for 64 * t1 sec. Now immediately if there is a media re-negotiation ( re-INVITE-200OK-ACK), then UAC has to run another timer for 64 * t1 sec and save another copy of the ACK message ( for handling 200 OK retrans by the UAS ) Now there is no limit on how many times a user can re-negotiate media ( theoretically), so how many copies of the ACK message and how many timers one is going to run in the dialog/session layer. Dialog/Session Layer is a persistent call block and many times memory for it is allocated from Shared memory where you can not have dynamically expandable memory. Even if you save it in a link-list pointer and keep the link-list on heap, one has to worry about syncing stuff ( for failover support etc ). So I am basically again coming back and asking the question why do we have to handle the INVITE-2XX-ACK differently and handle it in UAC core and not in the transaction level. Please let me know if the query is not coherent. Regards, Indresh K Singh _______________________________________________ Sip-implementors mailing list [email protected] http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors Confidentiality Notice The information contained in this electronic message and any attachments to this message are intended for the exclusive use of the addressee(s) and may contain confidential or privileged information. If you are not the intended recipient, please notify the sender at Wipro or [EMAIL PROTECTED] immediately and destroy all copies of this message and any attachments. _______________________________________________ Sip-implementors mailing list [email protected] http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
