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

12 Feb 2014

Hello,
I managed to try it out and I have good news and bad news :)

The good news is that always TURN is working perfect. So, if I remove all
the ice-candidates (rtpproxy_manage("+")) everything is perfect. If I just
append turn candidate (rtpproxy_manage()) I have strange errors in kamailio
log and the media won't flow (black image on both parties).

I have attached the logs for both cases:
1. remove previous ice candidates - working - rtpproxy_manage("+")
http://snk.to/f-c7tjwm5k

2. keep ice candidates and append itself - not working - rtpproxy_manage()
http://snk.to/f-c71n29ic

My case and probably a nice feature is to have the possibility to append
the turn server candidate in SDP and let the client to decide what to use -
for WebRTC to WebRTC. Or, make this decision on server side (as it is now)
when you need conversion (RTP/AVP to and from RTP/SAVPF) - WebRTC to SIP,
etc. I'm sorry if I'm telling something wrong.

What I noticed is this line:
14(8465) ERROR: rtpproxy-ng [rtpproxy.c:1339]: rtpp_function_call(): failed
to decode bencoded reply from proxy: d3:sdp4301:v=0

I'm testing with the branch that you told me - pull yesterday.

Thank you.

Best regards,
Mihai M

On Thu, Feb 6, 2014 at 3:43 PM, Richard Fuchs &lt;rfuchs(a)sipwise.com&gt; wrote:

...
  Hey,

 What mediaproxy-ng can do (which other RTP proxies don't do) is
 translate RTP/AVP (from regular SIP endpoints) to and from RTP/SAVPF
 (encrypted RTP from WebRTC), which is what people usually use it for.

 Assuming that ICE does its job correctly, two WebRTC endpoints should be
 able to communicate directly with each other (without RTP proxy), even
 if a firewall is involved. But I understand that in some cases even ICE
 might fail.

 There's two things I see wrong with the resulting SDP body, both related
 to the last stable version of MP-NG not supporting BUNDLE. If you could
 try adding an SDP rewrite rule to your kamailio config to remove the
 a=group:... line. If that doesn't work, also try disabling video when
 making the call.

 Alternatively, you can try building MP-NG from this branch:
 https://github.com/sipwise/mediaproxy-ng/tree/rfuchs/3.0
 This is currently under heavy development, but it should support BUNDLE
 just enough to make this work.

 cheers

 On 02/05/14 11:23, Mihai Marin wrote:
  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 <mailto:sip%3Abob@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 <mailto:sip%3Abob@93.187.138.214>>
 From: "Alice Test" <sip:alice@93.187.138.214
 <mailto:sip%3Aalice@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 &lt;rfuchs(a)sipwise.com
 <mailto: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      &lt;shaheryarkh(a)gmail.com
<mailto:shaheryarkh@gmail.com>
     > <mailto: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      &lt;marinmihai(a)gmail.com
<mailto:marinmihai@gmail.com>
      <mailto: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
         &lt;apogrebennyk(a)sipwise.com      <mailto:apogrebennyk@sipwise.com>
<mailto: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(a)lists.sip-router.org     
<mailto:sr-users@lists.sip-router.org>

<mailto: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(a)lists.sip-router.org
     <mailto:sr-users@lists.sip-router.org>
     <mailto: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(a)lists.sip-router.org     
<mailto:sr-users@lists.sip-router.org>
     <mailto: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(a)lists.sip-router.org <mailto: 
sr-users(a)lists.sip-router.org&gt;

http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users

     _______________________________________________
     SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing  list
      sr-users(a)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(a)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(a)lists.sip-router.org
 http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

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