Hello Indresh , I am thinking about two scenarios here ...
1 >The late media scenario as I mentioned earlier , in this case you have to copy the entire SDP answer and keep it in your transaction layer with the ACK message for future re-transmission. This may mean , a>Duplication of the memory allocated for storing the SDP as you may be storing that in your offer/answer state machine any way , and now you are keeping another copy within the ACK message in the SIP transaction. b>If you want to avoid duplication then you land up making your sip transaction layer tightly coupled with your offer/answer state machine which , I think should not be done ... as they are really independent of each other 2>Forking , If you get multiple 2xx responses , you will have to ACK all of them and then send BYE for the dialogs which you do not want. Now , if any of those 2xx are re-transmitted , you will have to re-transmit the ACK and then BYE it again. To do both of these from the transaction layer will be difficult as the BYE will be a separate new transaction with it's own 200 OK ... What do you think about these scenarios ? Regards , Sayan -----Original Message----- From: Singh, Indresh [mailto:[EMAIL PROTECTED] Sent: Friday, March 18, 2005 8:12 PM To: Sayan Chowdhury (WT01 - TELECOM SOLUTIONS); [email protected] Subject: RE: [Sip-implementors] Saving ACK in the UAC core !! Thanks for the reply Sayan, 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... ACK construction is definitely done by the UAC core as you indicated. My cocern is specifically regarding the retransmission which is kind of like this - UAC sends INVITE creates a transaction - Gets a 200 OK frees the transaction and passed the message to UAC core - UAC core constructs the ACK and sends it directly to transport as per recommendation of section 13.2.2.4 - Now if the UAC core constructs and has the responsibility of retransmission, that is where I think we have a design limitation of keeping a number of ACKs possible .... Now if we follow the same logic as we follow for 3XX, I do not have to worry about keeping copies of ACK in UAC core, when ever TXN time will timeout it will retrieve the txn ptr which has copy of last sent message. - UAC sends INVITE creates a transaction - Gets a 200 OK and passed the message to UAC core - UAC core constructs the ACK and sends it to transaction layer on the same transaction. ( I know that ACK will have it's own branch, but I am sure it is possible to locate INVITE txn and push this ACK on the same transaction ) . Now if we use this txn time for handling duplicate 2XX and free the TXN after 32 seconds. I do not have to store the ACKs in the UAC core ... But then fundamentally I am deviating from the recommendations ( for my memory savings reasons. UAC core/dialog is in SHM, TXN is on heap and have to keep multiple ACKs in dialog as indicated above ), so I want to understand if I do decide to deviate then what are it's impact from handling some call scenarios / application. I want to basically make sure that later on we do not have to go back to what the protocol says, bcoz we could not forsee the call-scenario I am looking for. Was I able to explain, what I meant to ?? if not please let me know. Thanks. Indresh -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Friday, March 18, 2005 6:08 AM To: Singh, Indresh; [email protected] Cc: Shetty, Sathish Subject: RE: [Sip-implementors] Saving ACK in the UAC core !! 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. 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
