Cameron,<br>
<br>
The problem is that the c= field in the SDP payload is always pointing
to <a href="http://127.0.0.1">127.0.0.1</a> (aka, your loopback interface). This is not going to work
since neither Sipura or X-lite client can connect to your loopback
interface.<br>
<br>
More specifically, the INVITE message that is sent from the Sipura to
the SER proxy is then rewritten and then relayed to the X-lite SIP UA.
This relayed INVITE has the incorrect c= field in the SDP.<br>
<br>
Likewise, the 200OK that X-lite replies with is then rewritten by SER
and relayed to the Sipura UA. This 200OK also has a c= of <a href="http://127.0.0.1">127.0.0.1</a><br>
<br>
I suspect that your call to use_media_proxy() is correct, but media proxy is running on the wrong interface.<br><br>If
you look at the <a href="http://onsip.org">onsip.org</a> documentation you will find a mediaproxy
init.d start script in the appendix. In this start script you will see
the following line:<br>
<br>
PROXY_OPTIONS=&quot;--ip=<a href="http://71.16.1.15">71.16.1.15</a> --listen=<a href="http://127.0.0.1">127.0.0.1</a>&quot;<br>
<br>
The --ip option must be an IP that is available to all SIP clients
(NATed an non-NATed). Therefore you should specify a public ip address.
This then is the ip that will be used in the c= field in the SDP
payload. The --listen parameter can be <a href="http://127.0.0.1">127.0.0.1</a> if you are running
mediaproxy on your SIP router. If not, then you will need to change
this as well.<br>
<br>
NOTE: If you're mediaproxy is behind an ALG enabled router, such as a
Cisco 3600, then the router will rewrite the RFC1918 IPs with the
public ones, so in this case you would use the --ip option as an
RFC1918 address.<br>
<br>
Regards,<br>
Paul<br>