24 Feb
2014
24 Feb
'14
6:21 p.m.
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(a)sipwise.com> wrote:
On 02/22/14 07:07, Mihai Marin wrote:
--
Carlos
http://caruizdiaz.com
http://ngvoice.com
+595981146623
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(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users