<div dir="ltr"><div>Great, i would test Bundle right away. Just wondering if this branch also supports DTLS--SRTP. I would love to test that feature when available.<br><br></div>Thank you.<br><div><br><br></div></div><div class="gmail_extra">

<br><br><div class="gmail_quote">On Thu, Feb 6, 2014 at 2:43 PM, Richard Fuchs <span dir="ltr"><<a href="mailto:rfuchs@sipwise.com" target="_blank">rfuchs@sipwise.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

Hey,<br>
<br>
What mediaproxy-ng can do (which other RTP proxies don't do) is<br>
translate RTP/AVP (from regular SIP endpoints) to and from RTP/SAVPF<br>
(encrypted RTP from WebRTC), which is what people usually use it for.<br>
<br>
Assuming that ICE does its job correctly, two WebRTC endpoints should be<br>
able to communicate directly with each other (without RTP proxy), even<br>
if a firewall is involved. But I understand that in some cases even ICE<br>
might fail.<br>
<br>
There's two things I see wrong with the resulting SDP body, both related<br>
to the last stable version of MP-NG not supporting BUNDLE. If you could<br>
try adding an SDP rewrite rule to your kamailio config to remove the<br>
a=group:... line. If that doesn't work, also try disabling video when<br>
making the call.<br>
<br>
Alternatively, you can try building MP-NG from this branch:<br>
<a href="https://github.com/sipwise/mediaproxy-ng/tree/rfuchs/3.0" target="_blank">https://github.com/sipwise/mediaproxy-ng/tree/rfuchs/3.0</a><br>
This is currently under heavy development, but it should support BUNDLE<br>
just enough to make this work.<br>
<br>
cheers<br>
<div class="im"><br>
<br>
On 02/05/14 11:23, Mihai Marin wrote:<br>
> Hello,<br>
> I'm trying the simplest case first. I don't understand why you are<br>
> saying that most of the people don't use mediaproxy-ng<br>
> for WebRTC to WebRTC calls. If my firewall is a restrictive one I need<br>
> to use turn server and mediaproxy-ng can do turn too? Probably I'm not<br>
> seeing the big picture.<br>
><br>
> Regarding the problem with Incompatible SDP I have attached the SDP<br>
> before mp-ng and after:<br>
><br>
> BEFORE mediaproxy-ng magic:<br>
> 14(21473) DEBUG: websocket [ws_frame.c:650]: ws_frame_receive(): Rx SIP<br>
> message:<br>
</div>> INVITE <a href="mailto:sip%3Abob@93.187.138.214">sip:bob@93.187.138.214</a> <mailto:<a href="mailto:sip%253Abob@93.187.138.214">sip%3Abob@93.187.138.214</a>> SIP/2.0<br>
<div class="im">> Via: SIP/2.0/WS an6ikqlgivd7.invalid;branch=z9hG4bK5845620<br>
> Max-Forwards: 69<br>
</div>> To: <<a href="mailto:sip%3Abob@93.187.138.214">sip:bob@93.187.138.214</a> <mailto:<a href="mailto:sip%253Abob@93.187.138.214">sip%3Abob@93.187.138.214</a>>><br>
<div class="im">> From: "Alice Test" <<a href="mailto:sip%3Aalice@93.187.138.214">sip:alice@93.187.138.214</a><br>
</div>> <mailto:<a href="mailto:sip%253Aalice@93.187.138.214">sip%3Aalice@93.187.138.214</a>>>;tag=dt8iuu64l9<br>
<div><div class="h5">> Call-ID: bmaapitncfv1jnijrbcf<br>
> CSeq: 7318 INVITE<br>
> Contact: <sip:sbt6u2o1@an6ikqlgivd7.invalid;transport=ws;ob><br>
> Allow: ACK,CANCEL,BYE,OPTIONS,INVITE<br>
> Content-Type: application/sdp<br>
> Supported: path, outbound, gruu<br>
> User-Agent: JsSIP 0.3.0<br>
> Content-Length: 2967<br>
><br>
> v=0<br>
> o=- 1167703101330838157 2 IN IP4 127.0.0.1<br>
> s=-<br>
> t=0 0<br>
> a=group:BUNDLE audio video<br>
> a=msid-semantic: WMS 3G8DreUBMks5DpcqNiiE5jXIC4GzIwfd7CUv<br>
> m=audio 9496 RTP/SAVPF 111 103 0 8 106 105 13 126<br>
> c=IN IP4 213.233.85.51<br>
> a=rtcp:9496 IN IP4 213.233.85.51<br>
> a=candidate:3511930567 1 udp 2113937151 10.93.108.223 53310 typ host<br>
> generation 0<br>
> a=candidate:3511930567 2 udp 2113937151 10.93.108.223 53310 typ host<br>
> generation 0<br>
> a=candidate:2681221687 1 tcp 1509957375 10.93.108.223 0 typ host<br>
> generation 0<br>
> a=candidate:2681221687 2 tcp 1509957375 10.93.108.223 0 typ host<br>
> generation 0<br>
> a=candidate:1343998067 1 udp 1845501695 213.233.85.51 9496 typ srflx<br>
> raddr 10.93.108.223 rport 53310 generation 0<br>
> a=candidate:1343998067 2 udp 1845501695 213.233.85.51 9496 typ srflx<br>
> raddr 10.93.108.223 rport 53310 generation 0<br>
> a=ice-ufrag:gNml+vA5NqfaRg0w<br>
> a=ice-pwd:dQJW2XWJ+g6gTIujfT819g2d<br>
> a=ice-options:google-ice<br>
> a=mid:audio<br>
> a=extmap:1 urn:ietf:params:rtp-hdrext:ssrc-audio-level<br>
> a=sendrecv<br>
> a=rtcp-mux<br>
> a=crypto:1 AES_CM_128_HMAC_SHA1_80<br>
> inline:uWFSQ5+41i2e12WFnGJKCfe+kuudHy0NurAaT8or<br>
> a=rtpmap:111 opus/48000/2<br>
> a=fmtp:111 minptime=10<br>
> a=rtpmap:103 ISAC/16000<br>
> a=rtpmap:0 PCMU/8000<br>
> a=rtpmap:8 PCMA/8000<br>
> a=rtpmap:106 CN/32000<br>
> a=rtpmap:105 CN/16000<br>
> a=rtpmap:13 CN/8000<br>
> a=rtpmap:126 telephone-event/8000<br>
> a=maxptime:60<br>
> a=ssrc:231261060 cname:aZBL5jB9VQtchKUh<br>
> a=ssrc:231261060 msid:3G8DreUBMks5DpcqNiiE5jXIC4GzIwfd7CUv<br>
> e8c9eb9c-916e-4c30-884f-fd602b2d8c90<br>
> a=ssrc:231261060 mslabel:3G8DreUBMks5DpcqNiiE5jXIC4GzIwfd7CUv<br>
> a=ssrc:231261060 label:e8c9eb9c-916e-4c30-884f-fd602b2d8c90<br>
> m=video 9496 RTP/SAVPF 100 116 117<br>
> c=IN IP4 213.233.85.51<br>
> a=rtcp:9496 IN IP4 213.233.85.51<br>
> a=candidate:3511930567 1 udp 2113937151 10.93.108.223 53310 typ host<br>
> generation 0<br>
> a=candidate:3511930567 2 udp 2113937151 10.93.108.223 53310 typ host<br>
> generation 0<br>
> a=candidate:2681221687 1 tcp 1509957375 10.93.108.223 0 typ host<br>
> generation 0<br>
> a=candidate:2681221687 2 tcp 1509957375 10.93.108.223 0 typ host<br>
> generation 0<br>
> a=candidate:1343998067 1 udp 1845501695 213.233.85.51 9496 typ srflx<br>
> raddr 10.93.108.223 rport 53310 generation 0<br>
> a=candidate:1343998067 2 udp 1845501695 213.233.85.51 9496 typ srflx<br>
> raddr 10.93.108.223 rport 53310 generation 0<br>
> a=ice-ufrag:gNml+vA5NqfaRg0w<br>
> a=ice-pwd:dQJW2XWJ+g6gTIujfT819g2d<br>
> a=ice-options:google-ice<br>
> a=mid:video<br>
> a=extmap:2 urn:ietf:params:rtp-hdrext:toffset<br>
> a=extmap:3 <a href="http://www.webrtc.org/experiments/rtp-hdrext/abs-send-time" target="_blank">http://www.webrtc.org/experiments/rtp-hdrext/abs-send-time</a><br>
> a=sendrecv<br>
> a=rtcp-mux<br>
> a=crypto:1 AES_CM_128_HMAC_SHA1_80<br>
> inline:uWFSQ5+41i2e12WFnGJKCfe+kuudHy0NurAaT8or<br>
> a=rtpmap:100 VP8/90000<br>
> a=rtcp-fb:100 ccm fir<br>
> a=rtcp-fb:100 nack<br>
> a=rtcp-fb:100 goog-remb<br>
> a=rtpmap:116 red/90000<br>
> a=rtpmap:117 ulpfec/90000<br>
> a=ssrc:3207772497 cname:aZBL5jB9VQtchKUh<br>
> a=ssrc:3207772497 msid:3G8DreUBMks5DpcqNiiE5jXIC4GzIwfd7CUv<br>
> ec757148-040c-479f-adbe-f6bac271fbd6<br>
> a=ssrc:3207772497 mslabel:3G8DreUBMks5DpcqNiiE5jXIC4GzIwfd7CUv<br>
> a=ssrc:3207772497 label:ec757148-040c-479f-adbe-f6bac271fbd6<br>
><br>
><br>
> AFTER mediaproxy-ng magic:<br>
> 14(21473) DEBUG: rtpproxy-ng [rtpproxy.c:1333]: rtpp_function_call():<br>
> proxy reply: d3:sdp3046:<br>
> v=0<br>
> o=- 1167703101330838157 2 IN IP4 93.187.138.214<br>
> s=-<br>
> t=0 0<br>
> a=group:BUNDLE audio video<br>
> a=msid-semantic: WMS 3G8DreUBMks5DpcqNiiE5jXIC4GzIwfd7CUv<br>
> m=audio 30408 RTP/SAVPF 111 103 0 8 106 105 13 126<br>
> c=IN IP4 93.187.138.214<br>
> a=candidate:3511930567 1 udp 2113937151 10.93.108.223 53310 typ host<br>
> generation 0<br>
> a=candidate:3511930567 2 udp 2113937151 10.93.108.223 53310 typ host<br>
> generation 0<br>
> a=candidate:2681221687 1 tcp 1509957375 10.93.108.223 0 typ host<br>
> generation 0<br>
> a=candidate:2681221687 2 tcp 1509957375 10.93.108.223 0 typ host<br>
> generation 0<br>
> a=candidate:1343998067 1 udp 1845501695 213.233.85.51 9496 typ srflx<br>
> raddr 10.93.108.223 rport 53310 generation 0<br>
> a=candidate:1343998067 2 udp 1845501695 213.233.85.51 9496 typ srflx<br>
> raddr 10.93.108.223 rport 53310 generation 0<br>
> a=ice-ufrag:gNml+vA5NqfaRg0w<br>
> a=ice-pwd:dQJW2XWJ+g6gTIujfT819g2d<br>
> a=ice-options:google-ice<br>
> a=mid:audio<br>
> a=sendrecv<br>
> a=crypto:1 AES_CM_128_HMAC_SHA1_80<br>
> inline:uWFSQ5+41i2e12WFnGJKCfe+kuudHy0NurAaT8or<br>
> a=rtpmap:111 opus/48000/2<br>
> a=fmtp:111 minptime=10<br>
> a=rtpmap:103 ISAC/16000<br>
> a=rtpmap:0 PCMU/8000<br>
> a=rtpmap:8 PCMA/8000<br>
> a=rtpmap:106 CN/32000<br>
> a=rtpmap:105 CN/16000<br>
> a=rtpmap:13 CN/8000<br>
> a=rtpmap:126 telephone-event/8000<br>
> a=maxptime:60<br>
> a=ssrc:231261060 cname:aZBL5jB9VQtchKUh<br>
> a=ssrc:231261060 msid:3G8DreUBMks5DpcqNiiE5jXIC4GzIwfd7CUv<br>
> e8c9eb9c-916e-4c30-884f-fd602b2d8c90<br>
> a=ssrc:231261060 mslabel:3G8DreUBMks5DpcqNiiE5jXIC4GzIwfd7CUv<br>
> a=ssrc:231261060 label:e8c9eb9c-916e-4c30-884f-fd602b2d8c90<br>
> a=rtcp:30409<br>
> a=candidate:8JGnwCAu0icAoJnr 1 UDP 2130706432 93.187.138.214 30408 typ host<br>
> a=candidate:8JGnwCAu0icAoJnr 2 UDP 2130706431 93.187.138.214 30409 typ host<br>
> m=video 30408 RTP/SAVPF 100 116 117<br>
> c=IN IP4 93.187.138.214<br>
> a=candidate:3511930567 1 udp 2113937151 10.93.108.223 53310 typ host<br>
> generation 0<br>
> a=candidate:3511930567 2 udp 2113937151 10.93.108.223 53310 typ host<br>
> generation 0<br>
> a=candidate:2681221687 1 tcp 1509957375 10.93.108.223 0 typ host<br>
> generation 0<br>
> a=candidate:2681221687 2 tcp 1509957375 10.93.108.223 0 typ host<br>
> generation 0<br>
> a=candidate:1343998067 1 udp 1845501695 213.233.85.51 9496 typ srflx<br>
> raddr 10.93.108.223 rport 53310 generation 0<br>
> a=candidate:1343998067 2 udp 1845501695 213.233.85.51 9496 typ srflx<br>
> raddr 10.93.108.223 rport 53310 generation 0<br>
> a=ice-ufrag:gNml+vA5NqfaRg0w<br>
> a=ice-pwd:dQJW2XWJ+g6gTIujfT819g2d<br>
> a=ice-options:google-ice<br>
> a=mid:video<br>
> a=sendrecv<br>
> a=crypto:1 AES_CM_128_HMAC_SHA1_80<br>
> inline:uWFSQ5+41i2e12WFnGJKCfe+kuudHy0NurAaT8or<br>
> a=rtpmap:100 VP8/90000<br>
> a=rtcp-fb:100 ccm fir<br>
> a=rtcp-fb:100 nack<br>
> a=rtcp-fb:100 goog-remb<br>
> a=rtpmap:116 red/90000<br>
> a=rtpmap:117 ulpfec/90000<br>
> a=ssrc:3207772497 cname:aZBL5jB9VQtchKUh<br>
> a=ssrc:3207772497 msid:3G8DreUBMks5DpcqNiiE5jXIC4GzIwfd7CUv<br>
> ec757148-040c-479f-adbe-f6bac271fbd6<br>
> a=ssrc:3207772497 mslabel:3G8DreUBMks5DpcqNiiE5jXIC4GzIwfd7CUv<br>
> a=ssrc:3207772497 label:ec757148-040c-479f-adbe-f6bac271fbd6<br>
> a=rtcp:30409<br>
> a=candidate:8JGnwCAu0icAoJnr 1 UDP 2130706432 93.187.138.214 30408 typ host<br>
> a=candidate:8JGnwCAu0icAoJnr 2 UDP 2130706431 93.187.138.214 30409 typ host<br>
><br>
><br>
><br>
> Between them, I have some strange logs in kamailio:<br>
>  14(21473) ERROR: *** cfgtrace:<br>
> c=[/usr/local/etc/kamailio/kamailio-test-media.cfg] l=878 a=25<br>
> n=rtpproxy_manage<br>
> 14(21473) DEBUG: <core> [parser/sdp/sdp_helpr_funcs.c:565]:<br>
> extract_mediaip(): located IP address [127.0.0.1] in `o=' field<br>
> 14(21473) DEBUG: <core> [parser/sdp/sdp_helpr_funcs.c:565]:<br>
> extract_mediaip(): located IP address [213.233.85.51] in `c=' field<br>
> 14(21473) DEBUG: <core> [parser/sdp/sdp.c:574]: parse_sdp_session():<br>
> ignoring unknown type in a= line: `a=ice-ufrag:gNml+vA5NqfaRg0w<br>
> a=ice-pwd:dQJW2XWJ+g6gTIujfT819g2d<br>
> a=ice-options:google-ice<br>
> a=mid:audio<br>
> ...............................................................<br>
> 14(21473) DEBUG: <core> [parser/sdp/sdp.c:574]: parse_sdp_session():<br>
> ignoring unknown type in a= line: `a=ssrc:3207772497<br>
> label:ec757148-040c-479f-adbe-f6bac271fbd6<br>
> '<br>
> 14(21473) DEBUG: rtpproxy-ng [rtpproxy_funcs.c:148]:<br>
> check_content_type(): type <application/sdp> found valid<br>
> 14(21473) DEBUG: rtpproxy-ng [rtpproxy.c:1333]: rtpp_function_call():<br>
> proxy reply: d3:sdp3046:v=0<br>
> o=- 1167703101330838157 2 IN IP4 93.187.138.214<br>
> s=-<br>
> t=0 0<br>
> a=group:BUNDLE audio video<br>
> a=msid-semantic: WMS 3G8DreUBMks5DpcqNiiE5jXIC4GzIwfd7CUv<br>
><br>
><br>
> Thank you very much for your help and for spending time debugging this<br>
> error.<br>
><br>
><br>
> Best regards,<br>
> Mihai M<br>
><br>
><br>
> On Wed, Feb 5, 2014 at 5:41 PM, Richard Fuchs <<a href="mailto:rfuchs@sipwise.com">rfuchs@sipwise.com</a><br>
</div></div><div><div class="h5">> <mailto:<a href="mailto:rfuchs@sipwise.com">rfuchs@sipwise.com</a>>> wrote:<br>
><br>
>     Hey,<br>
><br>
>     If you're trying to connect two WebRTC endpoints with each, you don't<br>
>     need any of mediaproxy-ng's magic to get it working. All the previous<br>
>     replies were assuming that you were trying to connect a WebRTC endpoint<br>
>     with a non-WebRTC one, which is usually what people are trying to do.<br>
><br>
>     In your case, the flags "froc" in either direction should be sufficient<br>
>     to get the job done. If it still doesn't work, can you please post the<br>
>     rejected SDP body as it appears both on the sender's side and on the<br>
>     receiver's side (i.e. both before and after it went through MP-NG).<br>
><br>
>     cheers<br>
><br>
><br>
>     On 02/05/14 05:17, Mihai Marin wrote:<br>
>     > Hello,<br>
>     > Thank you for your detailed explication but I miss some information or<br>
>     > I'm unable to understand it properly. What I'm trying to do is to use<br>
>     > mediaproxy-ng as a turn server between 2 WebRTC endpoints (when at<br>
>     least<br>
>     > one is behind restrictive firewall). Trying to replicate what you<br>
>     > explained on my needs I tried:<br>
>     > $avp(rtpproxy_offer_flags) = "froc+SP";<br>
>     > $avp(rtpproxy_answer_flags) = "froc-SP";<br>
>     ><br>
>     > But, unfortunately, I have the same error. Sorry if the solution is<br>
>     > obvious but I can't find it.<br>
>     ><br>
>     > Thank you.<br>
>     ><br>
>     > Best regards,<br>
>     > Mihai M<br>
>     ><br>
>     ><br>
>     > On Tue, Feb 4, 2014 at 10:45 PM, Muhammad Shahzad<br>
>     <<a href="mailto:shaheryarkh@gmail.com">shaheryarkh@gmail.com</a> <mailto:<a href="mailto:shaheryarkh@gmail.com">shaheryarkh@gmail.com</a>><br>
</div></div><div><div class="h5">>     > <mailto:<a href="mailto:shaheryarkh@gmail.com">shaheryarkh@gmail.com</a> <mailto:<a href="mailto:shaheryarkh@gmail.com">shaheryarkh@gmail.com</a>>>> wrote:<br>


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