Hi, I am quoting below text posted by Brett Tate couple of days back;
If I understand your question, you are wanting to know if it is okay for a UAC to release all subsequent 2xx related dialogs and keep the first INVITE 2xx's dialog. The answer is yes. And excluding race conditions, multiple 2xx responses should be rare since the forking proxy must send cancel on the other branches after forwarding a final response; see RFC 3261 section 16.7 number 10. RFC 3261 section 13.2.2.4: "If, after acknowledging any 2xx response to an INVITE, the UAC does not want to continue with that dialog, then the UAC MUST terminate the dialog by sending a BYE request as described in Section 15." Best Regards, Vivek Batra -----Original Message----- From: sip-implementors-boun...@lists.cs.columbia.edu [mailto:sip-implementors-boun...@lists.cs.columbia.edu] On Behalf Of VARUN BHATIA Sent: Friday, April 11, 2014 10:04 AM To: sip-implementors Subject: [Sip-implementors] Multiple 200 OK responses processing Hi, My software is acting as a B2bua when I receive multiple 2XX responses, I am not able to handle it as per my understanding I worked for 2 approaches but both of them are rejected by Stack: 1. Relaying first 200 OK to UAC and for other generating local ACK but the problem which I faced in this was after first ACK generation stack was not accepting second ACK, it seems that it has cleared that particular transaction. 2. Relaying all 200 OK to UAC in this also face the same problem first ACK received is correct but all other ACK are not been handled by the stack. Is there any stack configuration corresponding to forking handling ? How this part should be handled at transaction level not sure ? RFC says: Multiple 2xx responses may arrive at the UAC for a single INVITE request due to a forking proxy. Each response is distinguished by the tag parameter in the To header field, and each represents a distinct dialog, with a distinct dialog identifier. The UAC core MUST generate an ACK request for each 2xx received from the transaction layer. Any inputs are really appreciable. Thanks, Varun Bhatia _______________________________________________ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors _______________________________________________ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
