Hello Vikram , As vimal mentioned earlier , the 2xx response is sent end to end , i.e by the receipient UAS. Whereas , Intermediate proxies cannot generate/re-transmit a 2xx as it is not the final recipient. . A proxy is supposed to only forward the 2xx response. Thus there is a difference in behavior between the way an UA and a proxy handles the 2xx. Thus the functionality of sending a 2xx and ACKING it has been moved out of the transaction layer to the UAS/UAC core.
On the other hand , a non 2xx response essentially has same behavior for both proxies and user agent and can be handled in a common place in the transaction layer , hence u see the completed state in the transaction layer where ACK is sent for non-2xx responses. Hope this helps. Regards , Sayan P.S. Can you please post only to sip implementors for questions on existing SIP next time ? For one thing a cross post messes up the filtering rules in my mail client :) -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of VikramB Sent: Thursday, January 12, 2006 6:17 PM To: vimal srivastava; [email protected] Cc: [email protected] Subject: [Sip] Re: [Sip-implementors] sip transcation query Thanks for the response , But i am bit confused now ! AFIK any final resopnse should terminate the session, then how came after non-2xx response the ACK still can be part of the same transcation !! vikram ----- Original Message ----- From: "vimal srivastava" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]>; <[email protected]> Cc: <[email protected]> Sent: Tuesday, January 10, 2006 2:25 PM Subject: RE: [Sip-implementors] sip transcation query > Hi > Actually if we look at the intent of ACK in case of 2xx response things > become similar. > the ACK for 2xx resonse may carry SDP and it will un-necessarily congest > the network if it is sent thru all the proxies which are handling the > messaging statefully. Ack is usually exchanged directly > purpose of ACK is also to tell the end UAS that the originator has > received 200 message (which has SDP) so that conversation can begin. so > this signfies the need of ACK. > > in case of non-2xx final response, intent of ACK just to ackknowledge the > previous node that i have received the non-2xx response. and if ACK is not > received retransmit the non-2xx final response. if ACK is not sent then > there is no way to tell the pevious node that final response is received. > > This is not needed in case of 2xx response becos, if 2xx is lost in > between, UAC will not send ACK to the UAS and UAS will re-transmit 2xx > response again. > ACK for 2xx is exchanged directly (normally) between UAC and UAS so it > does not congest the network. > now if for non-2xx we leave the responsiblity of delivery to UAC (the way > it makes sure for 2xx), then even if non-2xx is lost at some intermediate > node, UAS will send non-2xx again and will traverse thru all the nodes > which is not neded. so by using hop-by-hop reliablity mechanism, some > network traffic is saved. > > UAS must know if 2xx is received at UAC or not because its > acknolwedegement of SDP exchanged , else processing at UAS stops > (convesation would not beging) > for non-2xx response UAS does not care. it does not stop any processing > for UAS > > so in essence: > for non-2xx final response (for invite) reliability is ensured hop-by-hope > and > for 2xx final response (for invite) reliablity is ensured end to end. > > > > cheers > v. > > > > From: "VikramB" <[EMAIL PROTECTED]> > To: <[email protected]> > CC: [email protected] > Subject: [Sip-implementors] sip transcation query > Date: Tue, 10 Jan 2006 09:20:06 +0530 > > Hello All, > In rfc 3261 section 6 Definition > > SIP Transaction : > .... > ..... > If the request is INVITE and the final > response is a non-2xx, the transaction also > includes an ACK to the response. The ACK for a 2xx response to > an INVITE request is a separate transaction. > > My query is why ACK is considered as a part of same transaction when in > case of non-2xx response.? > > > > regards > > VIkram > _______________________________________________ > Sip-implementors mailing list > [email protected] > https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors > > > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use [email protected] for questions on current sip Use [email protected] for new developments on the application of sip 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 proprietary, confidential or privileged information. If you are not the intended recipient, you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately and destroy all copies of this message and any attachments. WARNING: Computer viruses can be transmitted via email. The recipient should check this email and any attachments for the presence of viruses. The company accepts no liability for any damage caused by any virus transmitted by this email. www.wipro.com _______________________________________________ Sip-implementors mailing list [email protected] https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
