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
