I set the Q value of the 90127X2XX9 device so that it gets called first and the outbound number gets called second.  When I do this I am able to get two-way audio when ringing the 90127X2XX9 client and also when the client picks up.  So it appears to work as normal when I do that.

<br />

<br />I am calling engage_media_proxy every time since &quot;if (method==INVITE && !has_totag())&quot; always is true.

<br />

<br />In this scenario the 90127X2XX9 gets called first and ICE makes it so that both my clients talk directly to each other since they are on the same subnet.  Then when the outbound number is called all media goes through my MediaRelay.

<br />

<br />And to be sure I disabled ICE on one of the clients and called again.  This time Mediaproxy was used when both of the clients talked to each other.  And I called a second time and let the first call to the client fail and when the outbound number was called I had two-way audio I am guessing because it is to a Public SIP gateway.

<br />

<br />So there does seem to be an issue with serial forking.  I think it only fails if the *first* endpoint doesn&#39;t answer and the second endpoint is a Private IP address client. 

<br />

<br />On Jul 13, 2011 2:28am, Saul Ibarra Corretge &lt;saul@ag-projects.com&gt; wrote:

<br />&gt; Hi,

<br />&gt; 

<br />&gt; 

<br />&gt; 

<br />&gt; 

<br />&gt; 

<br />&gt; On Jul 12, 2011, at 9:29 PM, duane.larson@gmail.com wrote:

<br />&gt; 

<br />&gt; 

<br />&gt; 

<br />&gt; 

<br />&gt; 

<br />&gt; &gt; I am using append_branch and serial_branches/next_branches to implement a FindMe/FollowMe feature. I just noticed that when I do this I am getting no audio clients that don&#39;t have a public IP. If I bypass the FindMe/FollowMe stuff audio works just fine. I am not sure what exactly is going on when it breaks. The scenario I have right now is

<br />&gt; 

<br />&gt; 

<br />&gt; &gt;

<br />&gt; 

<br />&gt; 

<br />&gt; &gt; 90133XXX18 calls 90127X2XX9

<br />&gt; 

<br />&gt; 

<br />&gt; &gt;

<br />&gt; 

<br />&gt; 

<br />&gt; &gt; modparam(&quot;mediaproxy&quot;, &quot;mediaproxy_socket&quot;, &quot;/var/run/mediaproxy/dispatcher.sock&quot;)

<br />&gt; 

<br />&gt; 

<br />&gt; &gt; modparam(&quot;mediaproxy&quot;, &quot;ice_candidate&quot;, &quot;low-priority&quot;)

<br />&gt; 

<br />&gt; 

<br />&gt; &gt;

<br />&gt; 

<br />&gt; 

<br />&gt; &gt; OpenSIPS knows that when 90127X2XX9 is called to first set $ru to 90127X2XX9 and then append_branch. Then OpenSIPS sets $ru to an outbound number that has to be reached via SIP trunk provider. Q-Values are set for both numbers so that the outbound number is called first and then 90127X2XX9 is called. Then I call serialize_branches(1) and then next_branches. I turn on Mediaproxy by doing the following

<br />&gt; 

<br />&gt; 

<br />&gt; &gt;

<br />&gt; 

<br />&gt; 

<br />&gt; &gt; if (method==INVITE && !has_totag()) {

<br />&gt; 

<br />&gt; 

<br />&gt; &gt; # We can also use a specific media relay if we need to

<br />&gt; 

<br />&gt; 

<br />&gt; &gt; engage_media_proxy();

<br />&gt; 

<br />&gt; 

<br />&gt; &gt; }

<br />&gt; 

<br />&gt; 

<br />&gt; &gt;

<br />&gt; 

<br />&gt; 

<br />&gt; &gt; Then the call is made. I notice when doing a siptrace on the call that sometimes my &quot;c=IN IP4&quot; in the SDP never has the IP of the Mediaproxy when it calls the outbound number and then the 90127X2XX9 number. Then other times it does include the mediaproxy IP which is &quot;173.XXX.XXX.111&quot;. It&#39;s just random when I test a call. Engage_media_proxy is called when the call to the outbound number is made and also when the call to the 90127X2XX9 number is made. If I disable ICE on the Blink client it doesn&#39;t seem to make a difference on this problem.

<br />&gt; 

<br />&gt; 

<br />&gt; &gt;

<br />&gt; 

<br />&gt; 

<br />&gt; &gt; I am using a branch version of OpenSIPS that was posted yesterday and I just upgraded Mediaproxy Dispatcher and Relay to the latest version without any luck.

<br />&gt; 

<br />&gt; 

<br />&gt; 

<br />&gt; 

<br />&gt; 

<br />&gt; Its been a while since I haven&#39;t used serial forking, but since you are using engage_media_proxy you may need to check how serial forking and the dialog module work together. Are you calling engage_media_proxy for every new branch that is appended? That is, is this always failing if the *first* endpoint doesn&#39;t answer?

<br />&gt; 

<br />&gt; 

<br />&gt; 

<br />&gt; 

<br />&gt; 

<br />&gt; 

<br />&gt; 

<br />&gt; 

<br />&gt; Regards,

<br />&gt; 

<br />&gt; 

<br />&gt; 

<br />&gt; 

<br />&gt; 

<br />&gt; --

<br />&gt; 

<br />&gt; 

<br />&gt; Saúl Ibarra Corretgé

<br />&gt; 

<br />&gt; 

<br />&gt; AG Projects

<br />&gt; 

<br />&gt; 

<br />&gt; 

<br />&gt; 

<br />&gt; 

<br />&gt; 

<br />&gt; 

<br />&gt; 

<br />&gt; 

<br />&gt; 

<br />&gt; 

<br />&gt; 

<br />&gt; 

<br />&gt; 

<br />&gt; 

<br />&gt; 

<br />&gt; 

<br />&gt; 

<br />&gt; 

<br />&gt; 

<br />&gt; _______________________________________________

<br />&gt; 

<br />&gt; 

<br />&gt; Users mailing list

<br />&gt; 

<br />&gt; 

<br />&gt; Users@lists.opensips.org

<br />&gt; 

<br />&gt; 

<br />&gt; http://lists.opensips.org/cgi-bin/mailman/listinfo/users

<br />&gt; 

<br />&gt; 

<br />&gt;