[SR-Users] kamailio with mediaproxy-ng, 488 Not Acceptable Here
Mihai Marin
marinmihai at gmail.com
Wed Feb 5 17:23:47 CET 2014
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 at 93.187.138.214 SIP/2.0
Via: SIP/2.0/WS an6ikqlgivd7.invalid;branch=z9hG4bK5845620
Max-Forwards: 69
To: <sip:bob at 93.187.138.214>
From: "Alice Test" <sip:alice at 93.187.138.214>;tag=dt8iuu64l9
Call-ID: bmaapitncfv1jnijrbcf
CSeq: 7318 INVITE
Contact: <sip:sbt6u2o1 at 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 at 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 at gmail.com
> > <mailto: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
> > <mailto: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 <mailto: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
> > <mailto: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 <mailto:
> 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 <mailto: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/ba9ab55e/attachment-0001.html>
More information about the sr-users
mailing list