Hello,
I'm trying the simplest case first. I don't understand why you are saying that most of the people don't use mediaproxy-ng for WebRTC to WebRTC calls. If my firewall is a restrictive one I need to use turn server and mediaproxy-ng can do turn too? Probably I'm not seeing the big picture.

Regarding the problem with Incompatible SDP I have attached the SDP before mp-ng and after:

BEFORE mediaproxy-ng magic:
14(21473) DEBUG: websocket [ws_frame.c:650]: ws_frame_receive(): Rx SIP message:
INVITE sip:bob@93.187.138.214 SIP/2.0
Via: SIP/2.0/WS an6ikqlgivd7.invalid;branch=z9hG4bK5845620
Max-Forwards: 69
To: <sip:bob@93.187.138.214>
From: "Alice Test" <sip:alice@93.187.138.214>;tag=dt8iuu64l9
Call-ID: bmaapitncfv1jnijrbcf
CSeq: 7318 INVITE
Contact: <sip:sbt6u2o1@an6ikqlgivd7.invalid;transport=ws;ob>
Allow: ACK,CANCEL,BYE,OPTIONS,INVITE
Content-Type: application/sdp
Supported: path, outbound, gruu
User-Agent: JsSIP 0.3.0
Content-Length: 2967

v=0
o=- 1167703101330838157 2 IN IP4 127.0.0.1
s=-
t=0 0
a=group:BUNDLE audio video
a=msid-semantic: WMS 3G8DreUBMks5DpcqNiiE5jXIC4GzIwfd7CUv
m=audio 9496 RTP/SAVPF 111 103 0 8 106 105 13 126
c=IN IP4 213.233.85.51
a=rtcp:9496 IN IP4 213.233.85.51
a=candidate:3511930567 1 udp 2113937151 10.93.108.223 53310 typ host generation 0
a=candidate:3511930567 2 udp 2113937151 10.93.108.223 53310 typ host generation 0
a=candidate:2681221687 1 tcp 1509957375 10.93.108.223 0 typ host generation 0
a=candidate:2681221687 2 tcp 1509957375 10.93.108.223 0 typ host generation 0
a=candidate:1343998067 1 udp 1845501695 213.233.85.51 9496 typ srflx raddr 10.93.108.223 rport 53310 generation 0
a=candidate:1343998067 2 udp 1845501695 213.233.85.51 9496 typ srflx raddr 10.93.108.223 rport 53310 generation 0
a=ice-ufrag:gNml+vA5NqfaRg0w
a=ice-pwd:dQJW2XWJ+g6gTIujfT819g2d
a=ice-options:google-ice
a=mid:audio
a=extmap:1 urn:ietf:params:rtp-hdrext:ssrc-audio-level
a=sendrecv
a=rtcp-mux
a=crypto:1 AES_CM_128_HMAC_SHA1_80 inline:uWFSQ5+41i2e12WFnGJKCfe+kuudHy0NurAaT8or
a=rtpmap:111 opus/48000/2
a=fmtp:111 minptime=10
a=rtpmap:103 ISAC/16000
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:106 CN/32000
a=rtpmap:105 CN/16000
a=rtpmap:13 CN/8000
a=rtpmap:126 telephone-event/8000
a=maxptime:60
a=ssrc:231261060 cname:aZBL5jB9VQtchKUh
a=ssrc:231261060 msid:3G8DreUBMks5DpcqNiiE5jXIC4GzIwfd7CUv e8c9eb9c-916e-4c30-884f-fd602b2d8c90
a=ssrc:231261060 mslabel:3G8DreUBMks5DpcqNiiE5jXIC4GzIwfd7CUv
a=ssrc:231261060 label:e8c9eb9c-916e-4c30-884f-fd602b2d8c90
m=video 9496 RTP/SAVPF 100 116 117
c=IN IP4 213.233.85.51
a=rtcp:9496 IN IP4 213.233.85.51
a=candidate:3511930567 1 udp 2113937151 10.93.108.223 53310 typ host generation 0
a=candidate:3511930567 2 udp 2113937151 10.93.108.223 53310 typ host generation 0
a=candidate:2681221687 1 tcp 1509957375 10.93.108.223 0 typ host generation 0
a=candidate:2681221687 2 tcp 1509957375 10.93.108.223 0 typ host generation 0
a=candidate:1343998067 1 udp 1845501695 213.233.85.51 9496 typ srflx raddr 10.93.108.223 rport 53310 generation 0
a=candidate:1343998067 2 udp 1845501695 213.233.85.51 9496 typ srflx raddr 10.93.108.223 rport 53310 generation 0
a=ice-ufrag:gNml+vA5NqfaRg0w
a=ice-pwd:dQJW2XWJ+g6gTIujfT819g2d
a=ice-options:google-ice
a=mid:video
a=extmap:2 urn:ietf:params:rtp-hdrext:toffset
a=extmap:3 http://www.webrtc.org/experiments/rtp-hdrext/abs-send-time
a=sendrecv
a=rtcp-mux
a=crypto:1 AES_CM_128_HMAC_SHA1_80 inline:uWFSQ5+41i2e12WFnGJKCfe+kuudHy0NurAaT8or
a=rtpmap:100 VP8/90000
a=rtcp-fb:100 ccm fir
a=rtcp-fb:100 nack
a=rtcp-fb:100 goog-remb
a=rtpmap:116 red/90000
a=rtpmap:117 ulpfec/90000
a=ssrc:3207772497 cname:aZBL5jB9VQtchKUh
a=ssrc:3207772497 msid:3G8DreUBMks5DpcqNiiE5jXIC4GzIwfd7CUv ec757148-040c-479f-adbe-f6bac271fbd6
a=ssrc:3207772497 mslabel:3G8DreUBMks5DpcqNiiE5jXIC4GzIwfd7CUv
a=ssrc:3207772497 label:ec757148-040c-479f-adbe-f6bac271fbd6


AFTER mediaproxy-ng magic:
14(21473) DEBUG: rtpproxy-ng [rtpproxy.c:1333]: rtpp_function_call(): proxy reply: d3:sdp3046:
v=0
o=- 1167703101330838157 2 IN IP4 93.187.138.214
s=-
t=0 0
a=group:BUNDLE audio video
a=msid-semantic: WMS 3G8DreUBMks5DpcqNiiE5jXIC4GzIwfd7CUv
m=audio 30408 RTP/SAVPF 111 103 0 8 106 105 13 126
c=IN IP4 93.187.138.214
a=candidate:3511930567 1 udp 2113937151 10.93.108.223 53310 typ host generation 0
a=candidate:3511930567 2 udp 2113937151 10.93.108.223 53310 typ host generation 0
a=candidate:2681221687 1 tcp 1509957375 10.93.108.223 0 typ host generation 0
a=candidate:2681221687 2 tcp 1509957375 10.93.108.223 0 typ host generation 0
a=candidate:1343998067 1 udp 1845501695 213.233.85.51 9496 typ srflx raddr 10.93.108.223 rport 53310 generation 0
a=candidate:1343998067 2 udp 1845501695 213.233.85.51 9496 typ srflx raddr 10.93.108.223 rport 53310 generation 0
a=ice-ufrag:gNml+vA5NqfaRg0w
a=ice-pwd:dQJW2XWJ+g6gTIujfT819g2d
a=ice-options:google-ice
a=mid:audio
a=sendrecv
a=crypto:1 AES_CM_128_HMAC_SHA1_80 inline:uWFSQ5+41i2e12WFnGJKCfe+kuudHy0NurAaT8or
a=rtpmap:111 opus/48000/2
a=fmtp:111 minptime=10
a=rtpmap:103 ISAC/16000
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:106 CN/32000
a=rtpmap:105 CN/16000
a=rtpmap:13 CN/8000
a=rtpmap:126 telephone-event/8000
a=maxptime:60
a=ssrc:231261060 cname:aZBL5jB9VQtchKUh
a=ssrc:231261060 msid:3G8DreUBMks5DpcqNiiE5jXIC4GzIwfd7CUv e8c9eb9c-916e-4c30-884f-fd602b2d8c90
a=ssrc:231261060 mslabel:3G8DreUBMks5DpcqNiiE5jXIC4GzIwfd7CUv
a=ssrc:231261060 label:e8c9eb9c-916e-4c30-884f-fd602b2d8c90
a=rtcp:30409
a=candidate:8JGnwCAu0icAoJnr 1 UDP 2130706432 93.187.138.214 30408 typ host
a=candidate:8JGnwCAu0icAoJnr 2 UDP 2130706431 93.187.138.214 30409 typ host
m=video 30408 RTP/SAVPF 100 116 117
c=IN IP4 93.187.138.214
a=candidate:3511930567 1 udp 2113937151 10.93.108.223 53310 typ host generation 0
a=candidate:3511930567 2 udp 2113937151 10.93.108.223 53310 typ host generation 0
a=candidate:2681221687 1 tcp 1509957375 10.93.108.223 0 typ host generation 0
a=candidate:2681221687 2 tcp 1509957375 10.93.108.223 0 typ host generation 0
a=candidate:1343998067 1 udp 1845501695 213.233.85.51 9496 typ srflx raddr 10.93.108.223 rport 53310 generation 0
a=candidate:1343998067 2 udp 1845501695 213.233.85.51 9496 typ srflx raddr 10.93.108.223 rport 53310 generation 0
a=ice-ufrag:gNml+vA5NqfaRg0w
a=ice-pwd:dQJW2XWJ+g6gTIujfT819g2d
a=ice-options:google-ice
a=mid:video
a=sendrecv
a=crypto:1 AES_CM_128_HMAC_SHA1_80 inline:uWFSQ5+41i2e12WFnGJKCfe+kuudHy0NurAaT8or
a=rtpmap:100 VP8/90000
a=rtcp-fb:100 ccm fir
a=rtcp-fb:100 nack
a=rtcp-fb:100 goog-remb
a=rtpmap:116 red/90000
a=rtpmap:117 ulpfec/90000
a=ssrc:3207772497 cname:aZBL5jB9VQtchKUh
a=ssrc:3207772497 msid:3G8DreUBMks5DpcqNiiE5jXIC4GzIwfd7CUv ec757148-040c-479f-adbe-f6bac271fbd6
a=ssrc:3207772497 mslabel:3G8DreUBMks5DpcqNiiE5jXIC4GzIwfd7CUv
a=ssrc:3207772497 label:ec757148-040c-479f-adbe-f6bac271fbd6
a=rtcp:30409
a=candidate:8JGnwCAu0icAoJnr 1 UDP 2130706432 93.187.138.214 30408 typ host
a=candidate:8JGnwCAu0icAoJnr 2 UDP 2130706431 93.187.138.214 30409 typ host



Between them, I have some strange logs in kamailio:
 14(21473) ERROR: *** cfgtrace: c=[/usr/local/etc/kamailio/kamailio-test-media.cfg] l=878 a=25 n=rtpproxy_manage
14(21473) DEBUG: <core> [parser/sdp/sdp_helpr_funcs.c:565]: extract_mediaip(): located IP address [127.0.0.1] in `o=' field
14(21473) DEBUG: <core> [parser/sdp/sdp_helpr_funcs.c:565]: extract_mediaip(): located IP address [213.233.85.51] in `c=' field
14(21473) DEBUG: <core> [parser/sdp/sdp.c:574]: parse_sdp_session(): ignoring unknown type in a= line: `a=ice-ufrag:gNml+vA5NqfaRg0w
a=ice-pwd:dQJW2XWJ+g6gTIujfT819g2d
a=ice-options:google-ice
a=mid:audio
...............................................................
14(21473) DEBUG: <core> [parser/sdp/sdp.c:574]: parse_sdp_session(): ignoring unknown type in a= line: `a=ssrc:3207772497 label:ec757148-040c-479f-adbe-f6bac271fbd6
'
14(21473) DEBUG: rtpproxy-ng [rtpproxy_funcs.c:148]: check_content_type(): type <application/sdp> found valid
14(21473) DEBUG: rtpproxy-ng [rtpproxy.c:1333]: rtpp_function_call(): proxy reply: d3:sdp3046:v=0
o=- 1167703101330838157 2 IN IP4 93.187.138.214
s=-
t=0 0
a=group:BUNDLE audio video
a=msid-semantic: WMS 3G8DreUBMks5DpcqNiiE5jXIC4GzIwfd7CUv


Thank you very much for your help and for spending time debugging this error.


Best regards,
Mihai M


On Wed, Feb 5, 2014 at 5:41 PM, Richard Fuchs <rfuchs@sipwise.com> wrote:
Hey,

If you're trying to connect two WebRTC endpoints with each, you don't
need any of mediaproxy-ng's magic to get it working. All the previous
replies were assuming that you were trying to connect a WebRTC endpoint
with a non-WebRTC one, which is usually what people are trying to do.

In your case, the flags "froc" in either direction should be sufficient
to get the job done. If it still doesn't work, can you please post the
rejected SDP body as it appears both on the sender's side and on the
receiver's side (i.e. both before and after it went through MP-NG).

cheers


On 02/05/14 05:17, Mihai Marin wrote:
> 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@gmail.com
> <mailto:shaheryarkh@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@gmail.com
>     <mailto:marinmihai@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@sipwise.com <mailto:apogrebennyk@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@lists.sip-router.org
>             <mailto:sr-users@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@lists.sip-router.org <mailto:sr-users@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@lists.sip-router.org <mailto:sr-users@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@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@lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users