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 <rfu...@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 <shaherya...@gmail.com > > <mailto:shaherya...@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 <marinmi...@gmail.com > > <mailto:marinmi...@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 > > <apogreben...@sipwise.com <mailto:apogreben...@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 > >
_______________________________________________ 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
