[OpenSIPS-Users] ICE and Mediaproxy break when using append_branch and serial_branches/next_

[duane.larson at gmail.com]

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.

I am calling engage_media_proxy every time since "if (method==INVITE  
&& !has_totag())" always is true.

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.

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.

So there does seem to be an issue with serial forking. I think it only  
fails if the *first* endpoint doesn't answer and the second endpoint is a  
Private IP address client.

On Jul 13, 2011 2:28am, Saul Ibarra Corretge <saul at ag-projects.com> wrote:
> Hi,





> On Jul 12, 2011, at 9:29 PM, duane.larson at gmail.com wrote:





> > 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'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


> >


> > 90133XXX18 calls 90127X2XX9


> >


> >  
> modparam("mediaproxy", "mediaproxy_socket", "/var/run/mediaproxy/dispatcher.sock")


> > modparam("mediaproxy", "ice_candidate", "low-priority")


> >


> > 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


> >


> > if (method==INVITE && !has_totag()) {


> > # We can also use a specific media relay if we need to


> > engage_media_proxy();


> > }


> >


> > Then the call is made. I notice when doing a siptrace on the call that  
> sometimes my "c=IN IP4" 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 "173.XXX.XXX.111".  
> It'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't seem to make a difference on this problem.


> >


> > 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.





> Its been a while since I haven'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't answer?








> Regards,





> --


> Saúl Ibarra Corretgé


> AG Projects




















> _______________________________________________


> Users mailing list


> Users at lists.opensips.org


> http://lists.opensips.org/cgi-bin/mailman/listinfo/users



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/users/attachments/20110713/20013e6f/attachment.htm>