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

[Mihai Marin]

Hello,
Thank you for your detailed explication but I miss some information or I'm
unable to understand it properly. What I'm trying to do is to use
mediaproxy-ng as a turn server between 2 WebRTC endpoints (when at least
one is behind restrictive firewall). Trying to replicate what you explained
on my needs I tried:
$avp(rtpproxy_offer_flags) = "froc+SP";
$avp(rtpproxy_answer_flags) = "froc-SP";

But, unfortunately, I have the same error. Sorry if the solution is obvious
but I can't find it.

Thank you.

Best regards,
Mihai M


On Tue, Feb 4, 2014 at 10:45 PM, Muhammad Shahzad <shaheryarkh at gmail.com>wrote:

> There are several problems that need to be addressed in your kamailio.cfg
> but let me try to focus only on mediaprxoy-ng related ones.
>
> First instead of engaging mediaproxy in failure route, engage it main
> route or branch route. Why wait for failure when we know call will fail
> anyway if you try to call webrtc to sip or vice versa.
>
> Secondly you need to keep track of connection type of both caller and
> callee and set appropriate mediaproxy-ng flags according to call direction,
> e.g. call from webrtc to sip, or sip to webrtc or webrtc to webrtc or sip
> to sip, each type of call needs different set of flags for both
> rtpproxy_offer and rtpproxy_answer.
>
> How you do this, is pretty simple, to detect if caller is webrtc endpoint
> you can use,
>
>
> if ($avp(mline) =~ "SAVPF") {
> # caller is a webrtc endpoint
> };
>
> To check if callee is a webrtc endpoint, you can use,
>
> if ($(ru{uri.param,transport}) =~ "ws") {
> # callee is a webrtc endpoint
> };
>
> For testing purpose, i recommend you only use mediaproxy-ng for bridging
> webrtc to sip or vice versa calls, i.e. if both endpoints are using same
> transport (e.g. sip to sip or webrtc to webrtc calls) then don't use
> mediaproxy-ng at all and allow endpoints to establish media directly (that
> would work out the box at least for webrtc to webrtc calls).
>
> Finally use correct flags for each type of call (i recommend doing it in
> branch route), for example,
>
> For WebRTC to SIP call use flags (case-sensitive),
>
> $avp(rtpproxy_offer_flags)  = "froc-sp";
> $avp(rtpproxy_answer_flags) = "froc+SP";
> rtpproxy_offer($avp(rtpproxy_offer_flags));
>
> For SIP to WebRTC call use flags (case-sensitive),
>
> $avp(rtpproxy_offer_flags)  = "froc+SP";
> $avp(rtpproxy_answer_flags) = "froc-sp";
> rtpproxy_offer($avp(rtpproxy_offer_flags));
>
>
> Then in reply route,
>
> rtpproxy_answer($avp(rtpproxy_answer_flags));
>
>
> Remember, currently mediaproxy-ng does NOT support SRTP/DTLS, which is
> required by firefox, so as result your webrtc endpoint MUST be running on
> Chrome.
>
> Hope this helps.
>
> Thank you.
>
>
>
>
> On Tue, Feb 4, 2014 at 3:28 PM, Mihai Marin <marinmihai at gmail.com> wrote:
>
>> Hello,
>> Thank you for your support.
>>
>> Yes, I have the same error without video enabled. I have attached the
>> logs from jssip (with and without video support) and logs from kamailio
>> when trying a call with video support enabled. The kamailio.cfg used is the
>> same from my previous mail.
>>
>> I also tried with sipml5 and I have the same behavior.
>>
>> I'm stuck on this error and I think I'm looking in the wrong direction.
>>
>> Thank you.
>>
>> Best regards,
>> Mihai M
>>
>>
>> On Tue, Feb 4, 2014 at 2:49 PM, Andrew Pogrebennyk <
>> apogrebennyk at sipwise.com> wrote:
>>
>>> Hi,
>>> could you please post also your Chrome js developer log?
>>> Does the problem exist if you start the jssip clients without video
>>> support?
>>>
>>> Andrew
>>>
>>> On 02/03/2014 12:00 PM, Mihai Marin wrote:
>>> > Hello,
>>> >
>>> > Another weekend struggling to make a call from jssip to another jssip
>>> > behind firewall and I still receive 488 - Not Acceptable Here. I tried
>>> > all the ideas that I had/received without any success - including catch
>>> > 488 and re-invite.
>>> > [...]
>>> > What do I miss from my configuration?
>>> >
>>> > Thank you.
>>> >
>>> > Best regards,
>>> > Mihai M
>>>
>>>
>>> _______________________________________________
>>> 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
>>>
>>
>>
>> _______________________________________________
>> 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
>>
>>
>
> _______________________________________________
> 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sip-router.org/pipermail/sr-users/attachments/20140205/51ec19f2/attachment.html>