<div dir="ltr">Just in case someone is interested, I created a sample script that could help new comers having the same problem.<div><br></div><div><div>I will write a blog entry explaining how this works, but in a nutshell:</div>
<div><br></div><div>- this script is configured to run behind NAT, port TCP 10080 and TCP/UDP 5090 are exposed to the Internet</div><div>- you have to create valid users using, preferably, "kamctl add ..."</div>
<div>- RTP ports should be open in range 30k-35k, inclusive</div><div>- I used jssip as WEBRTC SIP UA: <a href="http://tryit.jssip.net/">http://tryit.jssip.net/</a></div><div>- Always disable video before placing a call from jssip UA</div>
<div>- I tested calls between:</div><div>        - jssip to csipsimple</div><div>        - csipsimple to jssip</div><div>        - csipsimple to csipsimple</div></div><div><br></div><div><br></div><div>Link to the scripts: <a href="https://github.com/caruizdiaz/kamailio-ws">https://github.com/caruizdiaz/kamailio-ws</a></div>
<div><br></div><div>Regards,</div><div class="gmail_extra"><br><div class="gmail_quote">On Sat, Feb 22, 2014 at 9:31 AM, Richard Fuchs <span dir="ltr"><<a href="mailto:rfuchs@sipwise.com" target="_blank">rfuchs@sipwise.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="">On 02/22/14 07:07, Mihai Marin wrote:<br>
> Hello Sirs, Sir Richard,<br>
</div><div class="">> Thank you for your detailed explication.<br>
> I'm still thinking on that but I would say to act as the caller and keep<br>
> caller decision. If caller makes an offer with rtcp-mux ,<br>
> include separate ICE candidates for RTCP for media proxy too and forward<br>
> as it is to alice. If callee accept it (or not) you will receive the OK<br>
> with alice sdp, modify it (depending on her choices) and forward to bob.<br>
> In this way, we cover all the cases. Eventually we can add another<br>
> parameter to always ignore rtcp-mux offers.<br>
><br>
> What are the disadvantages on doing that? Is there any possibility that<br>
> some SIP clients not to respond properly to an SDP with rtcp-mux and<br>
> that's why you are removing it - or for '+' case where delay will be added?<br>
<br>
</div>Compatibility is exactly the reason. I don't have any exact numbers, but<br>
I'm sure that there's a large number of SIP/RTP clients out there (I'd<br>
say the vast majority) which don't support rtcp-mux at all. Some of them<br>
might start misbehaving if they receive an rtcp-mux offer (even though<br>
as per RFC, they shouldn't, but experience shows that RFC compliance is<br>
often just wishful thinking). Since from our point of view (always<br>
either '+' or '-') there's no disadvantage in always demuxing RTCP, this<br>
was what was implemented.<br>
<br>
In any case, I'll see if I can get a solution implemented in the near<br>
future.<br>
<br>
cheers<br>
<br>
<br>_______________________________________________<br>
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list<br>
<a href="mailto:sr-users@lists.sip-router.org">sr-users@lists.sip-router.org</a><br>
<a href="http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users" target="_blank">http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users</a><br>
<br></blockquote></div><br><br clear="all"><div><br></div>-- <br><div dir="ltr">Carlos<div><a href="http://caruizdiaz.com" target="_blank">http://caruizdiaz.com</a></div><div><a href="http://ngvoice.com">http://ngvoice.com</a></div>
<div>+595981146623</div></div>
</div></div>