[SR-Users] kamailio with mediaproxy-ng, 488 Not Acceptable Here

[Carlos Ruiz Díaz]

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 at 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 at lists.sip-router.org
> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
>
>


-- 
Carlos
http://caruizdiaz.com
http://ngvoice.com
+595981146623
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sip-router.org/pipermail/sr-users/attachments/20140224/7d30f6cb/attachment.html>