I'm not sure about implementation specifics with the technologies you're using, but perhaps you can implement a similar approach to what I've done before in an ASP.NET app:
In the "POST Recipient View" API request to DocuSign, specify returnUrl property to specify where DocuSign should redirect to upon completion -- in my example, I'll call this page DSComplete.aspx. So, when the DocuSign session concludes, the iFrame content will render DSComplete.aspx.
In DSComplete.aspx, I then use JavaScript to immediately redirect the "content page" (i.e., the parent page of the iframe) to another destination -- in my example, let's call that destination DSResults.aspx. This is what gets us out of the iFrame, and back into just another regular/non-iFrame page. I also pass along (as part of the redirect URL) the full querystring that came from DocuSign to the returnUrl page:
ClientScript.RegisterStartupScript(GetType(), "Load", "window.parent.location.href = 'DSResults.aspx?" + Request.QueryString.ToString() + "'; ");
Finally, in DSResults.aspx, I evaluate querystring parameters (especially the event parameter that DocuSign used to specify the outcome of the embedded session), and take appropriate action (i.e., display appropriate messaging to the user according to the outcome of the signing session, etc.).
So, regardless of what language you're using, the key is really that the returnUrl page needs to immediately redirect the content page (i.e., parent page of the iFrame) to another regular/non-iFrame page (by setting "window.parent.location.href" using JavaScript as described in #2 above), and then that other page actually does the evaluation of the event querystring parameter, etc. (#3 above).