Comments inline... Thanks & Regards, Nataraju A.B. -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Kasturi Narayanan Sent: Friday, January 13, 2006 8:40 PM To: 'Nataraju A B'; 'Asheesh Joshi'; 'Andy Pandaram' Cc: [EMAIL PROTECTED]; [email protected]; 'Christer Holmberg (JO/LMF)' Subject: Re: [Sip-implementors] Multiple non- 2xx responses
You said, "Due malfunctioning by the proxy the UAC may receive the multiple non-2xx responses as part of the same call. If this new failure response received before the transaction was terminated then it can generate the same ACK which sent for the earlier failure response, but this response will NOT be given to the application...." But remember that the to tags will be different for multiple 2xx or non 2xx responses. So if an ack is sent it shld have the same to: tag that was received. [ABN] yes the ACK has to carry the same tag which was carried the non-2xx response, not which was there in the earlier sent ACK.... What if a malfunctioning proxy sends a non 2xx response followed by a 2xx response? [ABN] in this case there is no matching client transaction, so we can drop it... So one approach could be, to drop all subsequent responses, if the first response is a non 2xx response. [ABN] if we decide to drop the subsequent non-2xx response, then the proxy keep retransmit till the Timer-J fires and then considers the response timeout. But if the client transaction is in completed, we can handle this flooding situation by replying that failure response with an ACK message without violating any part of the RFC.... Kasturi -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Nataraju A B Sent: Friday, January 13, 2006 7:19 AM To: 'Asheesh Joshi'; 'Andy Pandaram' Cc: [email protected]; [EMAIL PROTECTED]; 'Christer Holmberg (JO/LMF)' Subject: Re: [Sip-implementors] Multiple non- 2xx responses Comments inline... Thanks & Regards, Nataraju A.B. -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Asheesh Joshi Sent: Friday, January 13, 2006 5:54 PM To: Andy Pandaram Cc: [EMAIL PROTECTED]; [email protected]; Christer Holmberg (JO/LMF) Subject: Re: [Sip-implementors] Multiple non- 2xx responses I dont know if this case is possible. I think the stateful proxy will not forward all the non-2xx responses back to the originating UAC. You will only get one non-2xx response. Forking of INVITE at proxy will create new Transaction states which proxy should maintain and handle. Only when a final 2xx is received, ie. the proxy knows the dialog ID from the To:tag, then it will inform the originating UAC of the dialog. Multiple 2xx will then also be forwarded to the originating UAC. [ABN] perfectly right... In normal scenario UAC can expect either one or more 2xx responses or atmost one non-2xx failure response. Due malfunctioning by the proxy the UAC may receive the multiple non-2xx responses as part of the same call. If this new failure response received before the transaction was terminated then it can generate the same ACK which sent for the earlier failure response, but this response will NOT be given to the application.... If there is no matching client transaction (in UAC) then that response would be dropped. [/ABN] -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Christer Holmberg (JO/LMF) Sent: Friday, January 13, 2006 5:30 PM To: [EMAIL PROTECTED]; Andy Pandaram Cc: [email protected]; [EMAIL PROTECTED] Subject: Re: [Sip-implementors] Multiple non- 2xx responses I thought the question was about non-2xx response... -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED] Sent: 13. tammikuuta 2006 13:27 To: Andy Pandaram Cc: [EMAIL PROTECTED]; [email protected] Subject: Re: [Sip-implementors] Multiple non- 2xx responses Hi Andy, As per RFC 3261, Multiple 2xx responses may arrive at the UAC for a single INVITE request due to a forking proxy. Each response can be distinguished by the tag parameter in the To header field. Thus, each represents a distinct dialog, with a distinct dialog identifier. And the UAC MUST generate an ACK request for each 2xx received from the transaction layer. Shivani Flextronics, Bangalore "The thing always happens that you really believe in; and the belief in a thing makes it happen." Is it possible for a UAC to receive multiple non-2xx responses for an INVITE (because a call was forked and the forking proxy sent through both of them to a UAC)? What should be the UAC behavior in such a scenario? - Andy Send instant messages to your online friends http://in.messenger.yahoo.com _______________________________________________ Sip-implementors mailing list [email protected] https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors *********************** FSS-Restricted *********************** "DISCLAIMER: This message is proprietary to Hughes Software Systems Limited (HSS) and is intended solely for the use of the individual to whom it is addressed. It may contain privileged or confidential information and should not be circulated or used for any purpose other than for what it is intended. If you have received this message in error, please notify the originator immediately. If you are not the intended recipient, you are notified that you are strictly prohibited from using, copying, altering, or disclosing the contents of this message. HSS accepts no responsibility for loss or damage arising from the use of the information transmitted by this email including damage from virus." _______________________________________________ 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 _______________________________________________ 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
