Hi Varun,
What do you mean by the tag is changed in subsequent 2XX? It will be different for all 2XX due to the fact of having different dialogs with B2BUA. As you quote forking is being handled by B2BUA, B2BUA would have been created multiple dialogs at the time of forking and while receiving subsequent 2XX, it must be able to match 2XX using dialog identifier and generate ACK accordingly followed by BYE. Best Regards, Vivek Batra From: VARUN BHATIA [mailto:[email protected]] Sent: Friday, April 11, 2014 12:04 PM To: Vivek Batra Cc: sip-implementors Subject: Re: [Sip-implementors] Multiple 200 OK responses processing Hi Vivek, The issue is that when we receive subsequent 2XX response the tag is changed and we have to generate an ACK corresponding to it, now when we generate the ACK for subsequent 2XX the ACK is rejected by stack because there is no transaction matching corresponding to that. On Fri, Apr 11, 2014 at 10:45 AM, Vivek Batra <[email protected]> wrote: Hi, >From RFC 6228 Introduction; Upstream SIP entities might receive multiple 2xx final responses. When a SIP entity receives the first 2xx final response, and it does not intend to accept any subsequent 2xx final responses, it will automatically terminate any other outstanding early dialog associated with the request. If the SIP entity receives a subsequent 2xx final response, it will normally generate and send an ACK request, followed with a BYE request, using the dialog identifier retrieved from the 2xx final response. Best Regards, Vivek Batra From: VARUN BHATIA [mailto:[email protected]] Sent: Friday, April 11, 2014 10:37 AM To: Vivek Batra Cc: sip-implementors; Brett Tate Subject: Re: [Sip-implementors] Multiple 200 OK responses processing Thanks Vivek, but the requirement is that we should process all 200 OK and generate ACK ? On Fri, Apr 11, 2014 at 10:34 AM, Vivek Batra <[email protected]> wrote: 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: [email protected] [mailto:[email protected]] 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 [email protected] https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors -- Regards, Varun Bhatia -- Regards, Varun Bhatia _______________________________________________ Sip-implementors mailing list [email protected] https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
