Jeff, Thanks. You confirmed what I already suspected. I tried using manual activation but still hit problems. It seemed that once the SDP on the initial INVITE had been changed, then it would not change back on subsequent destinations. I guess that is why you had to operate it on each branch in the way you describe.
I am trying a completely different approach now. The actual problem was that one gateway was already running RTP Proxy (acting like an SBC). When two RTP Proxies were chained, only one would activate and, if it was the wrong one, the network routing would not support direct access to the remote end point. I fixed it by making the Proxies engage with the f option. This makes all the Proxies in the chain active even if they detect the others are there. This solution works provided you have full access to the config on all the gateways and servers in the chain, which on this occasion I did. John From: Jeff Pyle [mailto:[email protected]] Sent: 29 August 2013 20:13 To: John Q; OpenSIPS users mailling list Subject: Re: [OpenSIPS-Users] Cancelling engage_rtp_proxy Hi John, I had asked the same question a while back. The answer I received was your second option. It seemed the only way to disengage_rtp_proxy() once engaged was to end the dialog. Since I needed to selectively engage and disengage based on the current iteration of a serial fork, my only solution was to manually manage with use_media_proxy(). This was in 1.6. I found it effective on initial INVITEs to use_media_proxy() on the branch_route so I didn't have to turn it off if I went to a new branch...it effectively died with the branch. The commands may have changed in more current versions but the approach should remain compatible. - Jeff On Thu, Aug 29, 2013 at 10:16 AM, John Quick <[email protected]> wrote: I am trying to configure OpenSIPS (v1.9.1) to act as a Proxy between remote customer systems and a number of gateways, some (but not all) of which require proxying of the media with RTPProxy. It will try one gateway first, but if that gives a timeout error then I change the destination to another gateway inside the failure handling block and try again. My question is this: Can I use unforce_rtp_proxy() to cancel the effect of an earlier engage_rtp_proxy() used on the initial call attempt? Or will I have to enable RTP Proxy using rtpproxy_offer() and rtpproxy_answer() in order to be able to deselect it on the second destination attempt. John Quick Smartvox Limited Web: www.smartvox.co.uk _______________________________________________ Users mailing list [email protected] http://lists.opensips.org/cgi-bin/mailman/listinfo/users _______________________________________________ Users mailing list [email protected] http://lists.opensips.org/cgi-bin/mailman/listinfo/users
