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