Hello Sirs, I have a problem configuring kamailio with mediaproxy-ng and I'm asking for help.
I managed to build everything, kamailio find support for mediaproxy-ng using rtpproxy-ng. When I'm trying to make a call from Web using my phone's internet provider to my computer's web I get 488 Not Acceptable Here. Swithing the caller I get no video.
I have used the kamailio-advanced.cfg generated and added websocket support. The call in my network is working perfect.
Can you help me with this?
mediaproxy-ng log: mediaproxy-ng[14896]: Returning to SIP proxy: d7:createdi1390864117e7:streamslld3:tag10:trhh9viigs6:status34:known but unconfirmed peer address5:statsd3:rtpd8:countersd7:packetsi0e5:bytesi0e6:errorsi0ee12:peer addressd6:family4:IPv47:address13:213.233.85.554:porti48279ee23:advertised peer addressd6:family4:IPv47:address13:213.233.85.554:porti48279ee10:local porti30008ee4:rtcpd8:countersd7:packetsi0e5:bytesi0e6:errorsi0ee12:peer addressd6:family4:IPv47:address13:213.233.85.554:porti48280ee23:advertised peer addressd6:family4:IPv47:address13:213.233.85.554:porti48280ee10:local porti30009eeeed3:tag0:6:status20:unknown peer address5:statsd3:rtpd8:countersd7:packetsi0e5:bytesi0e6:errorsi0ee12:peer addressd6:family4:IPv67:address2:::4:porti0ee23:advertised peer addressd6:family4:IPv67:address2:::4:porti0ee10:local porti30010ee4:rtcpd8:countersd7:packetsi0e5:bytesi0e6:errorsi0ee12:peer addressd6:family4:IPv67:address2:::4:porti0ee23:advertised peer addressd6:family4:IPv67:address2:::4:porti0ee10:local porti30011eeeeee6:totalsd5:inputd3:rtpd7:packetsi0e5:bytesi0e6:errorsi0ee4:rtcpd7:packetsi0e5:bytesi0e6:errorsi0eee6:outputd3:rtpd7:packetsi0e5:bytesi0e6:errorsi0ee4:rtcpd7:packetsi0e5:bytesi0e6:errorsi0eeee6:result2:oke
kamailio:
11(14926) ERROR: *** cfgtrace: c=[/usr/local/etc/kamailio/kamailio-advanced.cfg] l=860 a=24 n=rtpproxy_manage 11(14926) DEBUG: rtpproxy-ng [rtpproxy.c:1333]: rtpp_function_call(): proxy reply: d7:createdi1390864117e7:streamslld3:tag10:trhh9viigs6:status34:known but unconfirmed peer address5:statsd3:rtpd8:countersd7:packetsi0e5:bytesi0e6:errorsi0ee12:peer addressd6:family4:IPv47:address13:213.233.85.554:porti48279ee23:advertised peer addressd6:family4:IPv47:address13:213.233.85.554:porti48279ee10:local porti30008ee4:rtcpd8:countersd7:packetsi0e5:bytesi0e6:errorsi0ee12:peer addressd6:family4:IPv47:address13:213.233.85.554:porti48280ee23:advertised peer addressd6:family4:IPv47:address13:213.233.85.554:porti48280ee10:local porti30009eeeed3:tag0:6:status20:unknown peer address5:statsd3:rtpd8:countersd7:packetsi0e5:bytesi0e6:errorsi0ee12:peer addressd6:family4:IPv67:address2:::4:porti0ee23:advertised peer addressd6:family4:IPv67:address2:::4:porti0ee10:local porti30010ee4:rtcpd8:countersd7:packetsi0e5:bytesi0e6:errorsi0ee12:peer addressd6:family4:IPv67:address2:::4:porti0ee23:advertised peer addressd6:family4:IPv67:address2:::4:porti0ee10:local porti30011eeeeee6:totalsd5:inputd3:rtpd7:packetsi0e5:bytesi0e6:errorsi0ee4:rtcpd7:packetsi0e5:bytesi0e6:errorsi0eee6:outputd3:rtpd7:packetsi0e5:bytesi0e6:errorsi0ee4:rtcpd7:packetsi0e5:bytesi0e6:errorsi0eeee6:result2:oke 11(14926) ERROR: *** cfgtrace: c=[/usr/local/etc/kamailio/kamailio-advanced.cfg] l=867 a=16 n=if 11(14926) ERROR: *** cfgtrace: c=[/usr/local/etc/kamailio/kamailio-advanced.cfg] l=862 a=24 n=is_request 11(14926) ERROR: *** cfgtrace: c=[/usr/local/etc/kamailio/kamailio-advanced.cfg] l=866 a=16 n=if 11(14926) ERROR: *** cfgtrace: c=[/usr/local/etc/kamailio/kamailio-advanced.cfg] l=863 a=24 n=has_totag 11(14926) DEBUG: siputils [checks.c:103]: has_totag(): no totag 11(14926) ERROR: *** cfgtrace: c=[/usr/local/etc/kamailio/kamailio-advanced.cfg] l=864 a=25 n=add_rr_param 11(14926) ERROR: *** cfgtrace: c=[/usr/local/etc/kamailio/kamailio-advanced.cfg] l=873 a=16 n=if 11(14926) ERROR: *** cfgtrace: c=[/usr/local/etc/kamailio/kamailio-advanced.cfg] l=867 a=24 n=is_reply 11(14926) ERROR: *** cfgtrace: c=[/usr/local/etc/kamailio/kamailio-advanced.cfg] l=873 a=2 n=return 11(14926) ERROR: *** cfgtrace: c=[/usr/local/etc/kamailio/kamailio-advanced.cfg] l=1009 a=16 n=if 11(14926) ERROR: *** cfgtrace: c=[/usr/local/etc/kamailio/kamailio-advanced.cfg] l=989 a=24 n=t_is_canceled 11(14926) DEBUG: tm [t_lookup.c:1071]: t_check_msg(): DEBUG: t_check_msg: msg id=2 global id=2 T start=0x7f62174df4e0 11(14926) DEBUG: tm [t_lookup.c:1143]: t_check_msg(): DEBUG: t_check_msg: T already found! 11(14926) DEBUG: tm [t_reply.c:1827]: relay_reply(): DEBUG: relay_reply: branch=0, save=0, relay=0 icode=0 11(14926) DEBUG: <core> [msg_translator.c:2007]: generate_res_buf_from_sip_res(): old size: 397, new size: 305 11(14926) DEBUG: <core> [msg_translator.c:2025]: generate_res_buf_from_sip_res(): copied size: orig:125, new: 33, rest: 272 msg= SIP/2.0 488 Not Acceptable Here Via: SIP/2.0/WS ebhg3v0qb6fm.invalid;rport=1034;received=213.233.85.55;branch=z9hG4bK8048296 To: sip:bob@93.187.138.214;tag=r6dc2287g9 From: "Alice Test" sip:alice@93.187.138.214;tag=trhh9viigs Call-ID: fvgga4ikm8vrvuji0g0n CSeq: 6228 INVITE Content-Length: 0
11(14926) DEBUG: websocket [ws_frame.c:713]: ws_frame_transmit(): Tx message: SIP/2.0 488 Not Acceptable Here Via: SIP/2.0/WS ebhg3v0qb6fm.invalid;rport=1034;received=213.233.85.55;branch=z9hG4bK8048296 To: sip:bob@93.187.138.214;tag=r6dc2287g9 From: "Alice Test" sip:alice@93.187.138.214;tag=trhh9viigs Call-ID: fvgga4ikm8vrvuji0g0n CSeq: 6228 INVITE Content-Length: 0
Thank you.
Best regards, Mihai M
Hi!
The problem is different SDP formats between normal SIP clients/gateways, and WebRTC clients.
You have to instruct mediaproxy-ng to rewrite the SDP and do the conversion (encryption, ...).
So either the rtpproxy_ng calls lack the commands for the "gatewaying", or the webrtc clients uses eg. an encryption which is not supported by mediaproxy-ng.
Please also post the kamailio.cfg snippets when calling rtpproxy_ng and give details about your environment (browser, SIP client ...)
regards Klaus
On 27.01.2014 22:38, Mihai Marin wrote:
Hello Sirs, I have a problem configuring kamailio with mediaproxy-ng and I'm asking for help.
I managed to build everything, kamailio find support for mediaproxy-ng using rtpproxy-ng. When I'm trying to make a call from Web using my phone's internet provider to my computer's web I get 488 Not Acceptable Here. Swithing the caller I get no video.
I have used the kamailio-advanced.cfg generated and added websocket support. The call in my network is working perfect.
Can you help me with this?
mediaproxy-ng log: mediaproxy-ng[14896]: Returning to SIP proxy: d7:createdi1390864117e7:streamslld3:tag10:trhh9viigs6:status34:known but unconfirmed peer address5:statsd3:rtpd8:countersd7:packetsi0e5:bytesi0e6:errorsi0ee12:peer addressd6:family4:IPv47:address13:213.233.85.554:porti48279ee23:advertised peer addressd6:family4:IPv47:address13:213.233.85.554:porti48279ee10:local porti30008ee4:rtcpd8:countersd7:packetsi0e5:bytesi0e6:errorsi0ee12:peer addressd6:family4:IPv47:address13:213.233.85.554:porti48280ee23:advertised peer addressd6:family4:IPv47:address13:213.233.85.554:porti48280ee10:local porti30009eeeed3:tag0:6:status20:unknown peer address5:statsd3:rtpd8:countersd7:packetsi0e5:bytesi0e6:errorsi0ee12:peer addressd6:family4:IPv67:address2:::4:porti0ee23:advertised peer addressd6:family4:IPv67:address2:::4:porti0ee10:local porti30010ee4:rtcpd8:countersd7:packetsi0e5:bytesi0e6:errorsi0ee12:peer addressd6:family4:IPv67:address2:::4:porti0ee23:advertised peer addressd6:family4:IPv67:address2:::4:porti0ee10:local porti30011eeeeee6:totalsd5:inputd3:rtpd7:packetsi0e5:bytesi0e6:errorsi0ee4:rtcpd7:packetsi0e5:bytesi0e6:errorsi0eee6:outputd3:rtpd7:packetsi0e5:bytesi0e6:errorsi0ee4:rtcpd7:packetsi0e5:bytesi0e6:errorsi0eeee6:result2:oke
kamailio:
11(14926) ERROR: *** cfgtrace: c=[/usr/local/etc/kamailio/kamailio-advanced.cfg] l=860 a=24 n=rtpproxy_manage 11(14926) DEBUG: rtpproxy-ng [rtpproxy.c:1333]: rtpp_function_call(): proxy reply: d7:createdi1390864117e7:streamslld3:tag10:trhh9viigs6:status34:known but unconfirmed peer address5:statsd3:rtpd8:countersd7:packetsi0e5:bytesi0e6:errorsi0ee12:peer addressd6:family4:IPv47:address13:213.233.85.554:porti48279ee23:advertised peer addressd6:family4:IPv47:address13:213.233.85.554:porti48279ee10:local porti30008ee4:rtcpd8:countersd7:packetsi0e5:bytesi0e6:errorsi0ee12:peer addressd6:family4:IPv47:address13:213.233.85.554:porti48280ee23:advertised peer addressd6:family4:IPv47:address13:213.233.85.554:porti48280ee10:local porti30009eeeed3:tag0:6:status20:unknown peer address5:statsd3:rtpd8:countersd7:packetsi0e5:bytesi0e6:errorsi0ee12:peer addressd6:family4:IPv67:address2:::4:porti0ee23:advertised peer addressd6:family4:IPv67:address2:::4:porti0ee10:local porti30010ee4:rtcpd8:countersd7:packetsi0e5:bytesi0e6:errorsi0ee12:peer addressd6:family4:IPv67:address2:::4:porti0ee23:advertised peer addressd6:family4:IPv67:address2:::4:porti0ee10:local porti30011eeeeee6:totalsd5:inputd3:rtpd7:packetsi0e5:bytesi0e6:errorsi0ee4:rtcpd7:packetsi0e5:bytesi0e6:errorsi0eee6:outputd3:rtpd7:packetsi0e5:bytesi0e6:errorsi0ee4:rtcpd7:packetsi0e5:bytesi0e6:errorsi0eeee6:result2:oke 11(14926) ERROR: *** cfgtrace: c=[/usr/local/etc/kamailio/kamailio-advanced.cfg] l=867 a=16 n=if 11(14926) ERROR: *** cfgtrace: c=[/usr/local/etc/kamailio/kamailio-advanced.cfg] l=862 a=24 n=is_request 11(14926) ERROR: *** cfgtrace: c=[/usr/local/etc/kamailio/kamailio-advanced.cfg] l=866 a=16 n=if 11(14926) ERROR: *** cfgtrace: c=[/usr/local/etc/kamailio/kamailio-advanced.cfg] l=863 a=24 n=has_totag 11(14926) DEBUG: siputils [checks.c:103]: has_totag(): no totag 11(14926) ERROR: *** cfgtrace: c=[/usr/local/etc/kamailio/kamailio-advanced.cfg] l=864 a=25 n=add_rr_param 11(14926) ERROR: *** cfgtrace: c=[/usr/local/etc/kamailio/kamailio-advanced.cfg] l=873 a=16 n=if 11(14926) ERROR: *** cfgtrace: c=[/usr/local/etc/kamailio/kamailio-advanced.cfg] l=867 a=24 n=is_reply 11(14926) ERROR: *** cfgtrace: c=[/usr/local/etc/kamailio/kamailio-advanced.cfg] l=873 a=2 n=return 11(14926) ERROR: *** cfgtrace: c=[/usr/local/etc/kamailio/kamailio-advanced.cfg] l=1009 a=16 n=if 11(14926) ERROR: *** cfgtrace: c=[/usr/local/etc/kamailio/kamailio-advanced.cfg] l=989 a=24 n=t_is_canceled 11(14926) DEBUG: tm [t_lookup.c:1071]: t_check_msg(): DEBUG: t_check_msg: msg id=2 global id=2 T start=0x7f62174df4e0 11(14926) DEBUG: tm [t_lookup.c:1143]: t_check_msg(): DEBUG: t_check_msg: T already found! 11(14926) DEBUG: tm [t_reply.c:1827]: relay_reply(): DEBUG: relay_reply: branch=0, save=0, relay=0 icode=0 11(14926) DEBUG: <core> [msg_translator.c:2007]: generate_res_buf_from_sip_res(): old size: 397, new size: 305 11(14926) DEBUG: <core> [msg_translator.c:2025]: generate_res_buf_from_sip_res(): copied size: orig:125, new: 33, rest: 272 msg= SIP/2.0 488 Not Acceptable Here Via: SIP/2.0/WS ebhg3v0qb6fm.invalid;rport=1034;received=213.233.85.55;branch=z9hG4bK8048296 To: <sip:bob@93.187.138.214 mailto:sip%3Abob@93.187.138.214>;tag=r6dc2287g9 From: "Alice Test" <sip:alice@93.187.138.214 mailto:sip%3Aalice@93.187.138.214>;tag=trhh9viigs Call-ID: fvgga4ikm8vrvuji0g0n CSeq: 6228 INVITE Content-Length: 0
11(14926) DEBUG: websocket [ws_frame.c:713]: ws_frame_transmit(): Tx message: SIP/2.0 488 Not Acceptable Here Via: SIP/2.0/WS ebhg3v0qb6fm.invalid;rport=1034;received=213.233.85.55;branch=z9hG4bK8048296 To: <sip:bob@93.187.138.214 mailto:sip%3Abob@93.187.138.214>;tag=r6dc2287g9 From: "Alice Test" <sip:alice@93.187.138.214 mailto:sip%3Aalice@93.187.138.214>;tag=trhh9viigs Call-ID: fvgga4ikm8vrvuji0g0n CSeq: 6228 INVITE Content-Length: 0
Thank you.
Best regards, Mihai M
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
Hello, Thank you for your answer.
My server is a centos with public ip. I'm using chrome with jssip framework for sip client - tried sipml5 also. I have attached to this e-mail my kamailio configuration.
Regarding the kamailio + mediaproxy-ng I took the latest versions from git - also tried with kamailio 4.1.1. The mediaproxy-ng I'm running using the command: /tmp/mediaproxy-ng/daemon/mediaproxy-ng --ip=PUBLIC_IP --listen-ng= 127.0.0.1:2222
I also tried the following configuration and I have the same error: route { ......................
################################################################################################################## # Use RTP-Proxy ############################################################################################################### #if (!rtpproxy_offer("arf")) { # sl_send_reply("503", "No RTP-Relay available"); # exit; #} if (is_method("INVITE")) { if (sdp_content()) { if (rtpproxy_offer()) rtpproxy_manage("cowf","PUBLIC_IP"); t_on_reply("1"); } } else { if (sdp_content()) { if (rtpproxy_offer()) rtpproxy_manage("cowf","PUBLIC_IP"); } } if (is_method("ACK") && sdp_content()) { rtpproxy_answer(); rtpproxy_manage("cowf","PUBLIC_IP"); }
#t_on_reply("1");
# Relay this statefully t_relay(); ............................................................... ******************************************************************* onreply_route[1] { if ((($Rp == MY_WS_PORT || $Rp == MY_WSS_PORT) && !(proto == WS || proto == WSS)) || $Rp == MY_MSRP_PORT) { xlog("L_WARN", "SIP response received on $Rp\n"); drop; exit; } if (nat_uac_test(64)) { # Do NAT traversal stuff for replies to a WebSocket connection # - even if it is not behind a NAT! # This won't be needed in the future if Kamailio and the # WebSocket client support Outbound and Path. add_contact_alias(); } # A Transaction from a NATed Client to a NATed Client? Use the RTP-Proxy! if (status=~"(180)|(183)|(2[0-9][0-9])") { fix_nated_contact(); if (sdp_content()) { rtpproxy_answer(); } } }
If my problem could be caused by a kamalio miss-configuration could you please send me an example of configuration that should work with websockets, rtpproxy-ng->mediaproxy-ng in order to remove one possible cause?
Thank you.
Best regards, Mihai M
On Wed, Jan 29, 2014 at 1:31 PM, Klaus Darilion < klaus.mailinglists@pernau.at> wrote:
Hi!
The problem is different SDP formats between normal SIP clients/gateways, and WebRTC clients.
You have to instruct mediaproxy-ng to rewrite the SDP and do the conversion (encryption, ...).
So either the rtpproxy_ng calls lack the commands for the "gatewaying", or the webrtc clients uses eg. an encryption which is not supported by mediaproxy-ng.
Please also post the kamailio.cfg snippets when calling rtpproxy_ng and give details about your environment (browser, SIP client ...)
regards Klaus
On 27.01.2014 22:38, Mihai Marin wrote:
Hello Sirs, I have a problem configuring kamailio with mediaproxy-ng and I'm asking for help.
I managed to build everything, kamailio find support for mediaproxy-ng using rtpproxy-ng. When I'm trying to make a call from Web using my phone's internet provider to my computer's web I get 488 Not Acceptable Here. Swithing the caller I get no video.
I have used the kamailio-advanced.cfg generated and added websocket support. The call in my network is working perfect.
Can you help me with this?
mediaproxy-ng log: mediaproxy-ng[14896]: Returning to SIP proxy: d7:createdi1390864117e7:streamslld3:tag10:trhh9viigs6:status34:known but unconfirmed peer address5:statsd3:rtpd8:countersd7:packetsi0e5:bytesi0e6:errorsi0ee12:peer addressd6:family4:IPv47:address13:213.233.85.554: porti48279ee23:advertised peer addressd6:family4:IPv47:address13:213.233.85.554:porti48279ee10:local porti30008ee4:rtcpd8:countersd7:packetsi0e5:bytesi0e6:errorsi0ee12:peer addressd6:family4:IPv47:address13:213.233.85.554: porti48280ee23:advertised peer addressd6:family4:IPv47:address13:213.233.85.554:porti48280ee10:local porti30009eeeed3:tag0:6:status20:unknown peer address5:statsd3:rtpd8:countersd7:packetsi0e5:bytesi0e6:errorsi0ee12:peer addressd6:family4:IPv67:address2:::4:porti0ee23:advertised peer addressd6:family4:IPv67:address2:::4:porti0ee10:local porti30010ee4:rtcpd8:countersd7:packetsi0e5:bytesi0e6:errorsi0ee12:peer addressd6:family4:IPv67:address2:::4:porti0ee23:advertised peer addressd6:family4:IPv67:address2:::4:porti0ee10:local porti30011eeeeee6:totalsd5:inputd3:rtpd7:packetsi0e5: bytesi0e6:errorsi0ee4:rtcpd7:packetsi0e5:bytesi0e6: errorsi0eee6:outputd3:rtpd7:packetsi0e5:bytesi0e6:errorsi0ee4:rtcpd7: packetsi0e5:bytesi0e6:errorsi0eeee6:result2:oke
kamailio:
11(14926) ERROR: *** cfgtrace: c=[/usr/local/etc/kamailio/kamailio-advanced.cfg] l=860 a=24 n=rtpproxy_manage 11(14926) DEBUG: rtpproxy-ng [rtpproxy.c:1333]: rtpp_function_call(): proxy reply: d7:createdi1390864117e7:streamslld3:tag10:trhh9viigs6:status34:known but unconfirmed peer address5:statsd3:rtpd8:countersd7:packetsi0e5:bytesi0e6:errorsi0ee12:peer addressd6:family4:IPv47:address13:213.233.85.554: porti48279ee23:advertised peer addressd6:family4:IPv47:address13:213.233.85.554:porti48279ee10:local porti30008ee4:rtcpd8:countersd7:packetsi0e5:bytesi0e6:errorsi0ee12:peer addressd6:family4:IPv47:address13:213.233.85.554: porti48280ee23:advertised peer addressd6:family4:IPv47:address13:213.233.85.554:porti48280ee10:local porti30009eeeed3:tag0:6:status20:unknown peer address5:statsd3:rtpd8:countersd7:packetsi0e5:bytesi0e6:errorsi0ee12:peer addressd6:family4:IPv67:address2:::4:porti0ee23:advertised peer addressd6:family4:IPv67:address2:::4:porti0ee10:local porti30010ee4:rtcpd8:countersd7:packetsi0e5:bytesi0e6:errorsi0ee12:peer addressd6:family4:IPv67:address2:::4:porti0ee23:advertised peer addressd6:family4:IPv67:address2:::4:porti0ee10:local porti30011eeeeee6:totalsd5:inputd3:rtpd7:packetsi0e5: bytesi0e6:errorsi0ee4:rtcpd7:packetsi0e5:bytesi0e6: errorsi0eee6:outputd3:rtpd7:packetsi0e5:bytesi0e6:errorsi0ee4:rtcpd7: packetsi0e5:bytesi0e6:errorsi0eeee6:result2:oke 11(14926) ERROR: *** cfgtrace: c=[/usr/local/etc/kamailio/kamailio-advanced.cfg] l=867 a=16 n=if 11(14926) ERROR: *** cfgtrace: c=[/usr/local/etc/kamailio/kamailio-advanced.cfg] l=862 a=24 n=is_request 11(14926) ERROR: *** cfgtrace: c=[/usr/local/etc/kamailio/kamailio-advanced.cfg] l=866 a=16 n=if 11(14926) ERROR: *** cfgtrace: c=[/usr/local/etc/kamailio/kamailio-advanced.cfg] l=863 a=24 n=has_totag 11(14926) DEBUG: siputils [checks.c:103]: has_totag(): no totag 11(14926) ERROR: *** cfgtrace: c=[/usr/local/etc/kamailio/kamailio-advanced.cfg] l=864 a=25 n=add_rr_param 11(14926) ERROR: *** cfgtrace: c=[/usr/local/etc/kamailio/kamailio-advanced.cfg] l=873 a=16 n=if 11(14926) ERROR: *** cfgtrace: c=[/usr/local/etc/kamailio/kamailio-advanced.cfg] l=867 a=24 n=is_reply 11(14926) ERROR: *** cfgtrace: c=[/usr/local/etc/kamailio/kamailio-advanced.cfg] l=873 a=2 n=return 11(14926) ERROR: *** cfgtrace: c=[/usr/local/etc/kamailio/kamailio-advanced.cfg] l=1009 a=16 n=if 11(14926) ERROR: *** cfgtrace: c=[/usr/local/etc/kamailio/kamailio-advanced.cfg] l=989 a=24 n=t_is_canceled 11(14926) DEBUG: tm [t_lookup.c:1071]: t_check_msg(): DEBUG: t_check_msg: msg id=2 global id=2 T start=0x7f62174df4e0 11(14926) DEBUG: tm [t_lookup.c:1143]: t_check_msg(): DEBUG: t_check_msg: T already found! 11(14926) DEBUG: tm [t_reply.c:1827]: relay_reply(): DEBUG: relay_reply: branch=0, save=0, relay=0 icode=0 11(14926) DEBUG: <core> [msg_translator.c:2007]: generate_res_buf_from_sip_res(): old size: 397, new size: 305 11(14926) DEBUG: <core> [msg_translator.c:2025]: generate_res_buf_from_sip_res(): copied size: orig:125, new: 33, rest: 272 msg= SIP/2.0 488 Not Acceptable Here Via: SIP/2.0/WS ebhg3v0qb6fm.invalid;rport=1034;received=213.233.85.55;branch= z9hG4bK8048296 To: <sip:bob@93.187.138.214 mailto:sip%3Abob@93.187.138.214>;tag=r6dc2287g9
From: "Alice Test" <sip:alice@93.187.138.214 mailto:sip%3Aalice@93.187.138.214>;tag=trhh9viigs
Call-ID: fvgga4ikm8vrvuji0g0n CSeq: 6228 INVITE Content-Length: 0
11(14926) DEBUG: websocket [ws_frame.c:713]: ws_frame_transmit(): Tx message: SIP/2.0 488 Not Acceptable Here Via: SIP/2.0/WS ebhg3v0qb6fm.invalid;rport=1034;received=213.233.85.55;branch= z9hG4bK8048296 To: <sip:bob@93.187.138.214 mailto:sip%3Abob@93.187.138.214>;tag=r6dc2287g9
From: "Alice Test" <sip:alice@93.187.138.214 mailto:sip%3Aalice@93.187.138.214>;tag=trhh9viigs
Call-ID: fvgga4ikm8vrvuji0g0n CSeq: 6228 INVITE Content-Length: 0
Thank you.
Best regards, Mihai M
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
Peter had a talk at Astricon 2013 presenting how it works. I think the magic lies on the parameters. See this slide (there are some more interesting slides) https://www.youtube.com/watch?list=PLighc-2vlRgQHZMBp-8CCFi5otCnw7Lwj&v=...
regards Klaus
On 29.01.2014 12:53, Mihai Marin wrote:
Hello, Thank you for your answer.
My server is a centos with public ip. I'm using chrome with jssip framework for sip client - tried sipml5 also. I have attached to this e-mail my kamailio configuration.
Regarding the kamailio + mediaproxy-ng I took the latest versions from git - also tried with kamailio 4.1.1. The mediaproxy-ng I'm running using the command: /tmp/mediaproxy-ng/daemon/mediaproxy-ng --ip=PUBLIC_IP --listen-ng=127.0.0.1:2222 http://127.0.0.1:2222
I also tried the following configuration and I have the same error: route { ......................
################################################################################################################## # Use RTP-Proxy ############################################################################################################### #if (!rtpproxy_offer("arf")) { #sl_send_reply("503", "No RTP-Relay available"); #exit; #} if (is_method("INVITE")) { if (sdp_content()) { if (rtpproxy_offer()) rtpproxy_manage("cowf","PUBLIC_IP"); t_on_reply("1"); } } else { if (sdp_content()) { if (rtpproxy_offer()) rtpproxy_manage("cowf","PUBLIC_IP"); } } if (is_method("ACK") && sdp_content()) { rtpproxy_answer(); rtpproxy_manage("cowf","PUBLIC_IP"); }
#t_on_reply("1");
# Relay this statefully t_relay(); ...............................................................
onreply_route[1] { if ((($Rp == MY_WS_PORT || $Rp == MY_WSS_PORT) && !(proto == WS || proto == WSS)) || $Rp == MY_MSRP_PORT) { xlog("L_WARN", "SIP response received on $Rp\n"); drop; exit; } if (nat_uac_test(64)) { # Do NAT traversal stuff for replies to a WebSocket connection # - even if it is not behind a NAT! # This won't be needed in the future if Kamailio and the # WebSocket client support Outbound and Path. add_contact_alias(); } # A Transaction from a NATed Client to a NATed Client? Use the RTP-Proxy! if (status=~"(180)|(183)|(2[0-9][0-9])") { fix_nated_contact(); if (sdp_content()) { rtpproxy_answer(); } } }
If my problem could be caused by a kamalio miss-configuration could you please send me an example of configuration that should work with websockets, rtpproxy-ng->mediaproxy-ng in order to remove one possible cause?
Thank you.
Best regards, Mihai M
On Wed, Jan 29, 2014 at 1:31 PM, Klaus Darilion <klaus.mailinglists@pernau.at mailto:klaus.mailinglists@pernau.at> wrote:
Hi! The problem is different SDP formats between normal SIP clients/gateways, and WebRTC clients. You have to instruct mediaproxy-ng to rewrite the SDP and do the conversion (encryption, ...). So either the rtpproxy_ng calls lack the commands for the "gatewaying", or the webrtc clients uses eg. an encryption which is not supported by mediaproxy-ng. Please also post the kamailio.cfg snippets when calling rtpproxy_ng and give details about your environment (browser, SIP client ...) regards Klaus On 27.01.2014 22:38, Mihai Marin wrote: Hello Sirs, I have a problem configuring kamailio with mediaproxy-ng and I'm asking for help. I managed to build everything, kamailio find support for mediaproxy-ng using rtpproxy-ng. When I'm trying to make a call from Web using my phone's internet provider to my computer's web I get 488 Not Acceptable Here. Swithing the caller I get no video. I have used the kamailio-advanced.cfg generated and added websocket support. The call in my network is working perfect. Can you help me with this? mediaproxy-ng log: mediaproxy-ng[14896]: Returning to SIP proxy: d7:createdi1390864117e7:__streamslld3:tag10:trhh9viigs6:__status34:known but unconfirmed peer address5:statsd3:rtpd8:__countersd7:packetsi0e5:__bytesi0e6:errorsi0ee12:peer addressd6:family4:IPv47:__address13:213.233.85.554:__porti48279ee23:advertised peer addressd6:family4:IPv47:__address13:213.233.85.554:__porti48279ee10:local porti30008ee4:rtcpd8:__countersd7:packetsi0e5:__bytesi0e6:errorsi0ee12:peer addressd6:family4:IPv47:__address13:213.233.85.554:__porti48280ee23:advertised peer addressd6:family4:IPv47:__address13:213.233.85.554:__porti48280ee10:local porti30009eeeed3:tag0:6:__status20:unknown peer address5:statsd3:rtpd8:__countersd7:packetsi0e5:__bytesi0e6:errorsi0ee12:peer addressd6:family4:IPv67:__address2:::4:porti0ee23:__advertised peer addressd6:family4:IPv67:__address2:::4:porti0ee10:local porti30010ee4:rtcpd8:__countersd7:packetsi0e5:__bytesi0e6:errorsi0ee12:peer addressd6:family4:IPv67:__address2:::4:porti0ee23:__advertised peer addressd6:family4:IPv67:__address2:::4:porti0ee10:local porti30011eeeeee6:totalsd5:__inputd3:rtpd7:packetsi0e5:__bytesi0e6:errorsi0ee4:rtcpd7:__packetsi0e5:bytesi0e6:__errorsi0eee6:outputd3:rtpd7:__packetsi0e5:bytesi0e6:__errorsi0ee4:rtcpd7:__packetsi0e5:bytesi0e6:__errorsi0eeee6:result2:oke kamailio: 11(14926) ERROR: *** cfgtrace: c=[/usr/local/etc/kamailio/__kamailio-advanced.cfg] l=860 a=24 n=rtpproxy_manage 11(14926) DEBUG: rtpproxy-ng [rtpproxy.c:1333]: rtpp_function_call(): proxy reply: d7:createdi1390864117e7:__streamslld3:tag10:trhh9viigs6:__status34:known but unconfirmed peer address5:statsd3:rtpd8:__countersd7:packetsi0e5:__bytesi0e6:errorsi0ee12:peer addressd6:family4:IPv47:__address13:213.233.85.554:__porti48279ee23:advertised peer addressd6:family4:IPv47:__address13:213.233.85.554:__porti48279ee10:local porti30008ee4:rtcpd8:__countersd7:packetsi0e5:__bytesi0e6:errorsi0ee12:peer addressd6:family4:IPv47:__address13:213.233.85.554:__porti48280ee23:advertised peer addressd6:family4:IPv47:__address13:213.233.85.554:__porti48280ee10:local porti30009eeeed3:tag0:6:__status20:unknown peer address5:statsd3:rtpd8:__countersd7:packetsi0e5:__bytesi0e6:errorsi0ee12:peer addressd6:family4:IPv67:__address2:::4:porti0ee23:__advertised peer addressd6:family4:IPv67:__address2:::4:porti0ee10:local porti30010ee4:rtcpd8:__countersd7:packetsi0e5:__bytesi0e6:errorsi0ee12:peer addressd6:family4:IPv67:__address2:::4:porti0ee23:__advertised peer addressd6:family4:IPv67:__address2:::4:porti0ee10:local porti30011eeeeee6:totalsd5:__inputd3:rtpd7:packetsi0e5:__bytesi0e6:errorsi0ee4:rtcpd7:__packetsi0e5:bytesi0e6:__errorsi0eee6:outputd3:rtpd7:__packetsi0e5:bytesi0e6:__errorsi0ee4:rtcpd7:__packetsi0e5:bytesi0e6:__errorsi0eeee6:result2:oke 11(14926) ERROR: *** cfgtrace: c=[/usr/local/etc/kamailio/__kamailio-advanced.cfg] l=867 a=16 n=if 11(14926) ERROR: *** cfgtrace: c=[/usr/local/etc/kamailio/__kamailio-advanced.cfg] l=862 a=24 n=is_request 11(14926) ERROR: *** cfgtrace: c=[/usr/local/etc/kamailio/__kamailio-advanced.cfg] l=866 a=16 n=if 11(14926) ERROR: *** cfgtrace: c=[/usr/local/etc/kamailio/__kamailio-advanced.cfg] l=863 a=24 n=has_totag 11(14926) DEBUG: siputils [checks.c:103]: has_totag(): no totag 11(14926) ERROR: *** cfgtrace: c=[/usr/local/etc/kamailio/__kamailio-advanced.cfg] l=864 a=25 n=add_rr_param 11(14926) ERROR: *** cfgtrace: c=[/usr/local/etc/kamailio/__kamailio-advanced.cfg] l=873 a=16 n=if 11(14926) ERROR: *** cfgtrace: c=[/usr/local/etc/kamailio/__kamailio-advanced.cfg] l=867 a=24 n=is_reply 11(14926) ERROR: *** cfgtrace: c=[/usr/local/etc/kamailio/__kamailio-advanced.cfg] l=873 a=2 n=return 11(14926) ERROR: *** cfgtrace: c=[/usr/local/etc/kamailio/__kamailio-advanced.cfg] l=1009 a=16 n=if 11(14926) ERROR: *** cfgtrace: c=[/usr/local/etc/kamailio/__kamailio-advanced.cfg] l=989 a=24 n=t_is_canceled 11(14926) DEBUG: tm [t_lookup.c:1071]: t_check_msg(): DEBUG: t_check_msg: msg id=2 global id=2 T start=0x7f62174df4e0 11(14926) DEBUG: tm [t_lookup.c:1143]: t_check_msg(): DEBUG: t_check_msg: T already found! 11(14926) DEBUG: tm [t_reply.c:1827]: relay_reply(): DEBUG: relay_reply: branch=0, save=0, relay=0 icode=0 11(14926) DEBUG: <core> [msg_translator.c:2007]: generate_res_buf_from_sip_res(__): old size: 397, new size: 305 11(14926) DEBUG: <core> [msg_translator.c:2025]: generate_res_buf_from_sip_res(__): copied size: orig:125, new: 33, rest: 272 msg= SIP/2.0 488 Not Acceptable Here Via: SIP/2.0/WS ebhg3v0qb6fm.invalid;rport=__1034;received=213.233.85.55 <tel:213.233.85.55>;branch=__z9hG4bK8048296 To: <sip:bob@93.187.138.214 <mailto:sip%3Abob@93.187.138.214> <mailto:sip%3Abob@93.187.138.__214 <mailto:sip%253Abob@93.187.138.214>>>;tag=r6dc2287g9 From: "Alice Test" <sip:alice@93.187.138.214 <mailto:sip%3Aalice@93.187.138.214> <mailto:sip%3Aalice@93.187.__138.214 <mailto:sip%253Aalice@93.187.138.214>>>;tag=trhh9viigs Call-ID: fvgga4ikm8vrvuji0g0n CSeq: 6228 INVITE Content-Length: 0 11(14926) DEBUG: websocket [ws_frame.c:713]: ws_frame_transmit(): Tx message: SIP/2.0 488 Not Acceptable Here Via: SIP/2.0/WS ebhg3v0qb6fm.invalid;rport=__1034;received=213.233.85.55 <tel:213.233.85.55>;branch=__z9hG4bK8048296 To: <sip:bob@93.187.138.214 <mailto:sip%3Abob@93.187.138.214> <mailto:sip%3Abob@93.187.138.__214 <mailto:sip%253Abob@93.187.138.214>>>;tag=r6dc2287g9 From: "Alice Test" <sip:alice@93.187.138.214 <mailto:sip%3Aalice@93.187.138.214> <mailto:sip%3Aalice@93.187.__138.214 <mailto:sip%253Aalice@93.187.138.214>>>;tag=trhh9viigs Call-ID: fvgga4ikm8vrvuji0g0n CSeq: 6228 INVITE Content-Length: 0 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 <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 <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
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.
request_route {
# per request initial checks route(REQINIT);
# websockets route(WSDETECT); # NAT detection route(NATDETECT);
......... }
route[WITHINDLG] { if (has_totag()) { # sequential request withing a dialog should # take the path determined by record-routing if (loose_route()) { route(DLGURI); if (is_method("BYE")) { setflag(FLT_ACC); # do accounting ... setflag(FLT_ACCFAILED); # ... even if the transaction fails } else if ( is_method("ACK") ) { route(NATMANAGE); .................
}
branch_route[MANAGE_BRANCH] { xdbg("new branch [$T_branch_idx] to $ru\n"); route(NATMANAGE); }
# Caller NAT detection route route[NATDETECT] { #!ifdef WITH_NAT force_rport(); if (nat_uac_test("19")) { if (is_method("REGISTER")) { fix_nated_register(); } else { add_contact_alias(); } setflag(FLT_NATS); } #!endif return; }
# RTPProxy control route[NATMANAGE] { #!ifdef WITH_NAT if (is_request()) { if(has_totag()) { if(check_route_param("nat=yes")) { setbflag(FLB_NATB); } } } if (!(isflagset(FLT_NATS) || isbflagset(FLB_NATB))) return;
#tried this rtpproxy_manage("+","93.187.138.214"); #tried this too #if (is_request()) { # if (is_direction("downstream")) # rtpproxy_manage("1FOII"); # else # rtpproxy_manage("1FOIIR"); #} else { # if (is_direction("downstream")) # rtpproxy_manage("2FOIIR"); # else # rtpproxy_manage("2FOII"); #}
if (is_request()) { if (!has_totag()) { add_rr_param(";nat=yes"); } } if (is_reply()) { if(isbflagset(FLB_NATB)) { add_contact_alias(); } } #!endif return; }
failure_route[MANAGE_FAILURE] { t_on_failure("UA_FAILURE"); ... }
failure_route[UA_FAILURE] { if (t_check_status("488") && sdp_content()) { if (sdp_get_line_startswith("$avp(mline)", "m=")) { if ($avp(mline) =~ "SAVPF") { $avp(rtpproxy_offer_flags) = "frocsp"; $avp(rtpproxy_answer_flags) = "froc+SP"; } else { $avp(rtpproxy_offer_flags) = "froc+SP"; $avp(rtpproxy_answer_flags) = "frocsp"; } # In a production system you probably need to catch # "RTP/SAVP" and "RTP/AVPF" and handle them correctly # too } append_branch(); rtpproxy_offer($avp(rtpproxy_offer_flags)); t_on_reply("RTPPROXY_REPLY"); route(RELAY); } }
What do I miss from my configuration?
Thank you.
Best regards, Mihai M
On Wed, Jan 29, 2014 at 2:57 PM, Klaus Darilion < klaus.mailinglists@pernau.at> wrote:
Peter had a talk at Astricon 2013 presenting how it works. I think the magic lies on the parameters. See this slide (there are some more interesting slides) https://www.youtube.com/watch?list=PLighc-2vlRgQHZMBp- 8CCFi5otCnw7Lwj&v=rXsVSaRuv20&feature=player_detailpage#t=659
regards Klaus
On 29.01.2014 12:53, Mihai Marin wrote:
Hello, Thank you for your answer.
My server is a centos with public ip. I'm using chrome with jssip framework for sip client - tried sipml5 also. I have attached to this e-mail my kamailio configuration.
Regarding the kamailio + mediaproxy-ng I took the latest versions from git - also tried with kamailio 4.1.1. The mediaproxy-ng I'm running using the command: /tmp/mediaproxy-ng/daemon/mediaproxy-ng --ip=PUBLIC_IP --listen-ng=127.0.0.1:2222 http://127.0.0.1:2222
I also tried the following configuration and I have the same error: route { ......................
############################################################ ###################################################### # Use RTP-Proxy ############################################################ ################################################### #if (!rtpproxy_offer("arf")) { #sl_send_reply("503", "No RTP-Relay available");
#exit; #} if (is_method("INVITE")) { if (sdp_content()) { if (rtpproxy_offer()) rtpproxy_manage("cowf","PUBLIC_IP"); t_on_reply("1"); } } else { if (sdp_content()) { if (rtpproxy_offer()) rtpproxy_manage("cowf","PUBLIC_IP"); } } if (is_method("ACK") && sdp_content()) { rtpproxy_answer(); rtpproxy_manage("cowf","PUBLIC_IP"); }
#t_on_reply("1");
# Relay this statefully t_relay(); ...............................................................
onreply_route[1] { if ((($Rp == MY_WS_PORT || $Rp == MY_WSS_PORT) && !(proto == WS || proto == WSS)) || $Rp == MY_MSRP_PORT) { xlog("L_WARN", "SIP response received on $Rp\n"); drop; exit; } if (nat_uac_test(64)) { # Do NAT traversal stuff for replies to a WebSocket connection # - even if it is not behind a NAT! # This won't be needed in the future if Kamailio and the # WebSocket client support Outbound and Path. add_contact_alias(); } # A Transaction from a NATed Client to a NATed Client? Use the RTP-Proxy! if (status=~"(180)|(183)|(2[0-9][0-9])") { fix_nated_contact(); if (sdp_content()) { rtpproxy_answer(); } } }
If my problem could be caused by a kamalio miss-configuration could you please send me an example of configuration that should work with websockets, rtpproxy-ng->mediaproxy-ng in order to remove one possible cause?
Thank you.
Best regards, Mihai M
On Wed, Jan 29, 2014 at 1:31 PM, Klaus Darilion <klaus.mailinglists@pernau.at mailto:klaus.mailinglists@pernau.at> wrote:
Hi! The problem is different SDP formats between normal SIP clients/gateways, and WebRTC clients. You have to instruct mediaproxy-ng to rewrite the SDP and do the conversion (encryption, ...). So either the rtpproxy_ng calls lack the commands for the "gatewaying", or the webrtc clients uses eg. an encryption which is not supported by mediaproxy-ng. Please also post the kamailio.cfg snippets when calling rtpproxy_ng and give details about your environment (browser, SIP client ...) regards Klaus On 27.01.2014 22:38, Mihai Marin wrote: Hello Sirs, I have a problem configuring kamailio with mediaproxy-ng and I'm asking for help. I managed to build everything, kamailio find support for mediaproxy-ng using rtpproxy-ng. When I'm trying to make a call from Web usingmy phone's internet provider to my computer's web I get 488 Not Acceptable Here. Swithing the caller I get no video.
I have used the kamailio-advanced.cfg generated and addedwebsocket support. The call in my network is working perfect.
Can you help me with this? mediaproxy-ng log: mediaproxy-ng[14896]: Returning to SIP proxy: d7:createdi1390864117e7:__streamslld3:tag10:trhh9viigs6:__status34:known but unconfirmed peer address5:statsd3:rtpd8:__countersd7:packetsi0e5:__ bytesi0e6:errorsi0ee12:peer addressd6:family4:IPv47:__address13:213.233.85.554:__ porti48279ee23:advertised peer addressd6:family4:IPv47:__address13:213.233.85.554:__ porti48279ee10:local porti30008ee4:rtcpd8:__countersd7:packetsi0e5:__ bytesi0e6:errorsi0ee12:peer addressd6:family4:IPv47:__address13:213.233.85.554:__ porti48280ee23:advertised peer addressd6:family4:IPv47:__address13:213.233.85.554:__ porti48280ee10:local porti30009eeeed3:tag0:6:__status20:unknown peer address5:statsd3:rtpd8:__countersd7:packetsi0e5:__ bytesi0e6:errorsi0ee12:peer addressd6:family4:IPv67:__address2:::4:porti0ee23:__advertised peer addressd6:family4:IPv67:__address2:::4:porti0ee10:local porti30010ee4:rtcpd8:__countersd7:packetsi0e5:__ bytesi0e6:errorsi0ee12:peer addressd6:family4:IPv67:__address2:::4:porti0ee23:__advertised peer addressd6:family4:IPv67:__address2:::4:porti0ee10:local porti30011eeeeee6:totalsd5:__inputd3:rtpd7:packetsi0e5:__ bytesi0e6:errorsi0ee4:rtcpd7:__packetsi0e5:bytesi0e6:__ errorsi0eee6:outputd3:rtpd7:__packetsi0e5:bytesi0e6:__ errorsi0ee4:rtcpd7:__packetsi0e5:bytesi0e6:__errorsi0eeee6:result2:oke
kamailio: 11(14926) ERROR: *** cfgtrace: c=[/usr/local/etc/kamailio/__kamailio-advanced.cfg] l=860 a=24 n=rtpproxy_manage 11(14926) DEBUG: rtpproxy-ng [rtpproxy.c:1333]: rtpp_function_call(): proxy reply: d7:createdi1390864117e7:__streamslld3:tag10:trhh9viigs6:__status34:known but unconfirmed peer address5:statsd3:rtpd8:__countersd7:packetsi0e5:__ bytesi0e6:errorsi0ee12:peer addressd6:family4:IPv47:__address13:213.233.85.554:__ porti48279ee23:advertised peer addressd6:family4:IPv47:__address13:213.233.85.554:__ porti48279ee10:local porti30008ee4:rtcpd8:__countersd7:packetsi0e5:__ bytesi0e6:errorsi0ee12:peer addressd6:family4:IPv47:__address13:213.233.85.554:__ porti48280ee23:advertised peer addressd6:family4:IPv47:__address13:213.233.85.554:__ porti48280ee10:local porti30009eeeed3:tag0:6:__status20:unknown peer address5:statsd3:rtpd8:__countersd7:packetsi0e5:__ bytesi0e6:errorsi0ee12:peer addressd6:family4:IPv67:__address2:::4:porti0ee23:__advertised peer addressd6:family4:IPv67:__address2:::4:porti0ee10:local porti30010ee4:rtcpd8:__countersd7:packetsi0e5:__ bytesi0e6:errorsi0ee12:peer addressd6:family4:IPv67:__address2:::4:porti0ee23:__advertised peer addressd6:family4:IPv67:__address2:::4:porti0ee10:local porti30011eeeeee6:totalsd5:__inputd3:rtpd7:packetsi0e5:__ bytesi0e6:errorsi0ee4:rtcpd7:__packetsi0e5:bytesi0e6:__ errorsi0eee6:outputd3:rtpd7:__packetsi0e5:bytesi0e6:__ errorsi0ee4:rtcpd7:__packetsi0e5:bytesi0e6:__errorsi0eeee6:result2:oke 11(14926) ERROR: *** cfgtrace: c=[/usr/local/etc/kamailio/__kamailio-advanced.cfg] l=867 a=16 n=if 11(14926) ERROR: *** cfgtrace: c=[/usr/local/etc/kamailio/__kamailio-advanced.cfg] l=862 a=24
n=is_request 11(14926) ERROR: *** cfgtrace: c=[/usr/local/etc/kamailio/__kamailio-advanced.cfg] l=866 a=16n=if 11(14926) ERROR: *** cfgtrace: c=[/usr/local/etc/kamailio/__kamailio-advanced.cfg] l=863 a=24
n=has_totag 11(14926) DEBUG: siputils [checks.c:103]: has_totag(): no totag 11(14926) ERROR: *** cfgtrace: c=[/usr/local/etc/kamailio/__kamailio-advanced.cfg] l=864 a=25 n=add_rr_param 11(14926) ERROR: *** cfgtrace: c=[/usr/local/etc/kamailio/__kamailio-advanced.cfg] l=873 a=16n=if 11(14926) ERROR: *** cfgtrace: c=[/usr/local/etc/kamailio/__kamailio-advanced.cfg] l=867 a=24
n=is_reply 11(14926) ERROR: *** cfgtrace: c=[/usr/local/etc/kamailio/__kamailio-advanced.cfg] l=873 a=2 n=return 11(14926) ERROR: *** cfgtrace: c=[/usr/local/etc/kamailio/__kamailio-advanced.cfg] l=1009 a=16n=if 11(14926) ERROR: *** cfgtrace: c=[/usr/local/etc/kamailio/__kamailio-advanced.cfg] l=989 a=24
n=t_is_canceled 11(14926) DEBUG: tm [t_lookup.c:1071]: t_check_msg(): DEBUG: t_check_msg: msg id=2 global id=2 T start=0x7f62174df4e0 11(14926) DEBUG: tm [t_lookup.c:1143]: t_check_msg(): DEBUG: t_check_msg: T already found! 11(14926) DEBUG: tm [t_reply.c:1827]: relay_reply(): DEBUG: relay_reply: branch=0, save=0, relay=0 icode=0 11(14926) DEBUG: <core> [msg_translator.c:2007]: generate_res_buf_from_sip_res(__): old size: 397, new size: 305 11(14926) DEBUG: <core> [msg_translator.c:2025]: generate_res_buf_from_sip_res(__): copied size: orig:125, new: 33, rest: 272 msg= SIP/2.0 488 Not Acceptable Here Via: SIP/2.0/WS ebhg3v0qb6fm.invalid;rport=__1034;received=213.233.85.55 <tel:213.233.85.55>;branch=__z9hG4bK8048296 To: <sip:bob@93.187.138.214 <mailto:sip%3Abob@93.187.138.214> <mailto:sip%3Abob@93.187.138.__214 <mailto:sip%253Abob@93.187.138.214>>>;tag=r6dc2287g9 From: "Alice Test" <sip:alice@93.187.138.214 <mailto:sip%3Aalice@93.187.138.214> <mailto:sip%3Aalice@93.187.__138.214 <mailto:sip%253Aalice@93.187.138.214>>>;tag=trhh9viigs Call-ID: fvgga4ikm8vrvuji0g0n CSeq: 6228 INVITE Content-Length: 0 11(14926) DEBUG: websocket [ws_frame.c:713]: ws_frame_transmit():Tx message: SIP/2.0 488 Not Acceptable Here Via: SIP/2.0/WS ebhg3v0qb6fm.invalid;rport=__1034;received=213.233.85.55 tel:213.233.85.55;branch=__z9hG4bK8048296
To: <sip:bob@93.187.138.214 <mailto:sip%3Abob@93.187.138.214> <mailto:sip%3Abob@93.187.138.__214 <mailto:sip%253Abob@93.187.138.214>>>;tag=r6dc2287g9 From: "Alice Test" <sip:alice@93.187.138.214 <mailto:sip%3Aalice@93.187.138.214> <mailto:sip%3Aalice@93.187.__138.214 <mailto:sip%253Aalice@93.187.138.214>>>;tag=trhh9viigs Call-ID: fvgga4ikm8vrvuji0g0n CSeq: 6228 INVITE Content-Length: 0 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< http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users%3E
_________________________________________________ SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailinglist sr-users@lists.sip-router.org mailto:sr-users@lists.sip-router.org http://lists.sip-router.org/__cgi-bin/mailman/listinfo/sr-__users
<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
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
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
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 http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
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 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> 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 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
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.comwrote:
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 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> 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 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
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
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 relatedones.
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 mailinglist
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
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 <rfuchs@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 <shaheryarkh@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 <marinmihai@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 > <apogrebennyk@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@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@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@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@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
Hello,
Hope you don't mind if I borrow this topic to place a question or request. In past days I successfully setup Kamailio in my local network and made successful WebRTC to WebRTC and SIP to SIP calls. The problem is with WebRTC to SIP call. I also added mediaproxy-ng by following instructions found on https://github.com/sipwise/mediaproxy-ng . But I have problems with configuration. I tried to follow instructions given by Peter at Astricon 2013, but because I’m a bit unexperienced with Kamailio configuration I couldn’t make successful WebRTC to SIP call.
Is there any working example of kamailio.cfg file for Kamailio with mediaproxy-ng available? That would really help me to understand the whole concept. I’m using Kamailio 4.1.1 and mediaproxy-ng 3.8.0-30-generic.
Thank you.
Regards, Blaz
-- View this message in context: http://sip-router.1086192.n5.nabble.com/kamailio-with-mediaproxy-ng-488-Not-... Sent from the Users mailing list archive at Nabble.com.
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.
Thank you.
On Thu, Feb 6, 2014 at 2:43 PM, Richard Fuchs rfuchs@sipwise.com 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 <rfuchs@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 WebRTCendpoint
with a non-WebRTC one, which is usually what people are trying to do. In your case, the flags "froc" in either direction should besufficient
to get the job done. If it still doesn't work, can you please postthe
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 someinformation or
> I'm unable to understand it properly. What I'm trying to do is touse
> 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> > <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, engageit
> main route or branch route. Why wait for failure when we knowcall
> will fail anyway if you try to call webrtc to sip or viceversa.
> > Secondly you need to keep track of connection type of bothcaller
> 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 setof
> flags for both rtpproxy_offer and rtpproxy_answer. > > How you do this, is pretty simple, to detect if caller iswebrtc
> 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 bothendpoints
> 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 forwebrtc to
> webrtc calls). > > Finally use correct flags for each type of call (i recommenddoing
> 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 MUSTbe
> 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> > <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 videosupport)
> and logs from kamailio when trying a call with videosupport
> 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 thewrong
> 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> <mailto:apogrebennyk@sipwise.com <mailto:apogrebennyk@sipwise.com>>> wrote: > > Hi, > could you please post also your Chrome js developerlog?
> 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 jssipto
> another jssip > > behind firewall and I still receive 488 - NotAcceptable
> Here. I tried > > all the ideas that I had/received without anysuccess -
> 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> > <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@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@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@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 mailinglist
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
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 rfuchs@sipwise.com 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 <rfuchs@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 WebRTCendpoint
with a non-WebRTC one, which is usually what people are trying to do. In your case, the flags "froc" in either direction should besufficient
to get the job done. If it still doesn't work, can you please postthe
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 someinformation or
> I'm unable to understand it properly. What I'm trying to do is touse
> 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> > <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, engageit
> main route or branch route. Why wait for failure when we knowcall
> will fail anyway if you try to call webrtc to sip or viceversa.
> > Secondly you need to keep track of connection type of bothcaller
> 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 setof
> flags for both rtpproxy_offer and rtpproxy_answer. > > How you do this, is pretty simple, to detect if caller iswebrtc
> 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 bothendpoints
> 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 forwebrtc to
> webrtc calls). > > Finally use correct flags for each type of call (i recommenddoing
> 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 MUSTbe
> 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> > <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 videosupport)
> and logs from kamailio when trying a call with videosupport
> 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 thewrong
> 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> <mailto:apogrebennyk@sipwise.com <mailto:apogrebennyk@sipwise.com>>> wrote: > > Hi, > could you please post also your Chrome js developerlog?
> 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 jssipto
> another jssip > > behind firewall and I still receive 488 - NotAcceptable
> Here. I tried > > all the ideas that I had/received without anysuccess -
> 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> > <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@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@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@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 mailinglist
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
Hello, Would you mind posting your kamailio configuration file please? Thanks, Ashu
-- View this message in context: http://sip-router.1086192.n5.nabble.com/kamailio-with-mediaproxy-ng-488-Not-... Sent from the Users mailing list archive at Nabble.com.
Hello Sirs, Sir Richard, Does anyone has an idea for my previous mail/problem? I think the problem is in mediaproxy-ng but I can't be sure for that. Has anyone tried the same scenario before (WebRTC to WebRTC, append mediaproxy-ng as turn candidate and let client decide)?
Thank you.
Best regards, Mihai M
---------- Forwarded message ---------- From: Mihai Marin marinmihai@gmail.com Date: Wed, Feb 12, 2014 at 11:41 AM Subject: Re: [SR-Users] kamailio with mediaproxy-ng, 488 Not Acceptable Here To: "Kamailio (SER) - Users Mailing List" sr-users@lists.sip-router.org
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 rfuchs@sipwise.com 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 <rfuchs@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 WebRTCendpoint
with a non-WebRTC one, which is usually what people are trying to do. In your case, the flags "froc" in either direction should besufficient
to get the job done. If it still doesn't work, can you please postthe
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 someinformation or
> I'm unable to understand it properly. What I'm trying to do is touse
> 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> > <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, engageit
> main route or branch route. Why wait for failure when we knowcall
> will fail anyway if you try to call webrtc to sip or viceversa.
> > Secondly you need to keep track of connection type of bothcaller
> 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 setof
> flags for both rtpproxy_offer and rtpproxy_answer. > > How you do this, is pretty simple, to detect if caller iswebrtc
> 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 bothendpoints
> 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 forwebrtc to
> webrtc calls). > > Finally use correct flags for each type of call (i recommenddoing
> 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 MUSTbe
> 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> > <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 videosupport)
> and logs from kamailio when trying a call with videosupport
> 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 thewrong
> 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> <mailto:apogrebennyk@sipwise.com <mailto:apogrebennyk@sipwise.com>>> wrote: > > Hi, > could you please post also your Chrome js developerlog?
> 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 jssipto
> another jssip > > behind firewall and I still receive 488 - NotAcceptable
> Here. I tried > > all the ideas that I had/received without anysuccess -
> 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> > <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@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@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@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 mailinglist
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
On 02/12/14 04:41, Mihai Marin wrote:
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.
That's good to hear!
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).
...
- keep ice candidates and append itself - not working - rtpproxy_manage()
Looking at this, there's a very simple problem going on... The SDP body is getting too large for the receive buffer. :) It gets truncate, so can't be decoded, and the whole proxying thing fails.
This commit should fix that:
http://goo.gl/fBHfkh http://goo.gl/o1Pzt8
Please let me know if you're having any luck with that.
cheers
Hello Sirs, Thank you, one step forward but still buggy - half buggy :)
Now, it's working just one way. If bob calls alice, alice will receive video but bob won't. If I stop mediaproxy-ng process (without any other modification) and redo the call, everything is just fine.
The invite sdp that alice receives is here http://pastebin.com/BgZZbbEA The sdp from OK that bob receive is here http://pastebin.com/ADGt3D3E
I noticed something strange in those 2 SDPs (just audio candidates, video are the same): 1. offer 1.a. stun candidates a=candidate:1855365925 1 udp 1845501695 188.215.94.132 63015 typ srflx raddr 192.168.0.5 rport 63015 generation 0 a=candidate:1855365925 2 udp 1845501695 188.215.94.132 63015 typ srflx raddr 192.168.0.5 rport 63015 generation 0 1.b. turn candidates a=candidate:Om0baCmE7kgKNPvv 1 UDP 2130706432 93.187.138.214 30008 typ host a=candidate:Om0baCmE7kgKNPvv 2 UDP 2130706431 93.187.138.214 30009 typ host
2. answer 2.a. stun candidates a=candidate:1855365925 1 udp 1845501695 188.215.94.132 63028 typ srflx raddr 192.168.0.5 rport 63028 generation 0 a=candidate:1855365925 2 udp 1845501694 188.215.94.132 63031 typ srflx raddr 192.168.0.5 rport 63031 generation 0 2.b. turn candidates a=candidate:Om0baCmE7kgKNPvv 1 UDP 2130706432 93.187.138.214 30010 typ host
No bundle in sdp but: - offer has 1 single port for stun candidates and 2 for turn candidates - answer has 2 ports for stun candidates and 1 for turn candidates
The kamailio log can be accessed at http://pastebin.com/tVgE3BGt
Do you have any idea why this behavior?
Thank you.
Best regards, Mihai M
On Mon, Feb 17, 2014 at 8:35 PM, Richard Fuchs rfuchs@sipwise.com wrote:
On 02/12/14 04:41, Mihai Marin wrote:
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.
That's good to hear!
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).
...
- keep ice candidates and append itself - not working -
rtpproxy_manage()
Looking at this, there's a very simple problem going on... The SDP body is getting too large for the receive buffer. :) It gets truncate, so can't be decoded, and the whole proxying thing fails.
This commit should fix that:
http://goo.gl/fBHfkh http://goo.gl/o1Pzt8
Please let me know if you're having any luck with that.
cheers
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
On 02/18/14 11:12, Mihai Marin wrote:
Hello Sirs, Thank you, one step forward but still buggy - half buggy :)
Now, it's working just one way. If bob calls alice, alice will receive video but bob won't. If I stop mediaproxy-ng process (without any other modification) and redo the call, everything is just fine.
The invite sdp that alice receives is here http://pastebin.com/BgZZbbEA The sdp from OK that bob receive is here http://pastebin.com/ADGt3D3E
I noticed something strange in those 2 SDPs (just audio candidates, video are the same):
- offer
1.a. stun candidates a=candidate:1855365925 1 udp 1845501695 188.215.94.132 63015 typ srflx raddr 192.168.0.5 rport 63015 generation 0 a=candidate:1855365925 2 udp 1845501695 188.215.94.132 63015 typ srflx raddr 192.168.0.5 rport 63015 generation 0 1.b. turn candidates a=candidate:Om0baCmE7kgKNPvv 1 UDP 2130706432 93.187.138.214 30008 typ host a=candidate:Om0baCmE7kgKNPvv 2 UDP 2130706431 93.187.138.214 30009 typ host
- answer
2.a. stun candidates a=candidate:1855365925 1 udp 1845501695 188.215.94.132 63028 typ srflx raddr 192.168.0.5 rport 63028 generation 0 a=candidate:1855365925 2 udp 1845501694 188.215.94.132 63031 typ srflx raddr 192.168.0.5 rport 63031 generation 0 2.b. turn candidates a=candidate:Om0baCmE7kgKNPvv 1 UDP 2130706432 93.187.138.214 30010 typ host
No bundle in sdp but:
- offer has 1 single port for stun candidates and 2 for turn candidates
- answer has 2 ports for stun candidates and 1 for turn candidates
The kamailio log can be accessed at http://pastebin.com/tVgE3BGt
Do you have any idea why this behavior?
Yes, this is caused by MP-NG demultiplexing RTCP. I haven't thought of this before, as in our case we only use MP-NG with the '+' flag, which would eliminate this issue.
What happens is that MP-NG supports rtcp-mux in that it answers to an rtcp-mux offer and handles it correctly, but it never offers rtcp-mux to anyone, unless that endpoint is already talking rtcp-mux.
So from Alice's offer, MP-NG knows that Alice supports rtcp-mux and gladly accepts the offer in the answer sent to Alice. In this case, the same port is used for RTP and RTCP, which implies that only one ICE candidate is given for that port (only in the answer though -- in the offer, two must be given as a fallback).
However, MP-NG doesn't offer rtcp-mux to Bob, which means that Bob's answer includes separate ICE candidates for RTP and RTCP (due to separate ports). As those ICE candidates are left in place by MP-NG when translating the answer (which will include rtcp-mux), there's now a disagreement between the ICE candidates from Bob (two per candidate due to lack of rtcp-mux) and the ICE candidate inserted by MP-NG (only one due to rtcp-mux).
There's two possible solutions without resorting to the '+' flag... Either make MP-NG offer rtcp-mux to Bob initially (who may or may not accept it -- if he doesn't, nothing is fixed), or make it reject the rtcp-mux offer coming from Alice (which violates the WebRTC spec).
Another thing that MP-NG could do is to remove the RTCP ICE candidates in the answer going to Alice, hoping that Bob knows to demultiplex the RTCP packets coming in on the RTP port, despite rtcp-mux not having been negotiated.
I can't say I like any of these options :)
cheers
Hello Sirs, Sir Richard, I understand the problem but I don't understand the behavior. Let me tell you how I understood the problem and where I misunderstand the behavior.
BOB sens an offer to Alice with rtcp-mux. The flow is: UAC (bob) - Kamailio - MP-NG - Kamailio - UAS (alice). From the offer, MP-NG knows that bob request rtcp-mux but ignore it by removing "a=rtcp-mux" line from SDP and add 2 ICE Candidates with different ports . ALICE sends answer to BOB's offer without rtcp-mux. The flow is: UAC (alice) - Kamailio - MP-NG - Kamailio - UAS (bob). From the offer, MP-NG knows that bob accept rtcp-mux, ignore it first time, but still accept alice's answer with rtcp-mux (accepting the RTP and RTCP multiplexing) - offering rtcp-mux in response (answer).
First, I don't understand why is not working :). Offer received by alice does not contain rtcp-mux and has 2 ICE Candidates with different ports and the answer contains a=rtcp-mux and has 1 ICE Candidates for bundle. The most important part (for this problem) from RFC 5761 I think is the following 5.1.3 http://tools.ietf.org/html/rfc5761#section-5.1.3. Interactions with ICE
It is common to use the Interactive Connectivity Establishment (ICE) [19 http://tools.ietf.org/html/rfc5761#ref-19] methodology to establish RTP sessions in the presence of Network Address Translation (NAT) devices or other middleboxes. If RTP and RTCP are sent on separate ports, the RTP media stream comprises two components in ICE (one for RTP and one for RTCP), with connectivity checks being performed for each component. If RTP and RTCP are to be multiplexed on the same port some of these connectivity checks can be avoided, reducing the overhead of ICE.
If it is desired to use both ICE and multiplexed RTP and RTCP, the initial offer MUST contain an "a=rtcp-mux" attribute to indicate that RTP and RTCP multiplexing is desired and MUST contain "a=candidate:" lines for both RTP and RTCP along with an "a=rtcp:" line indicating a fallback port for RTCP in the case that the answerer does not support RTP and RTCP multiplexing. This MUST be done for each media where RTP and RTCP multiplexing is desired.
If the answerer wishes to multiplex RTP and RTCP on a single port, it MUST generate an answer containing an "a=rtcp-mux" attribute and a single "a=candidate:" line corresponding to the RTP port (i.e., there is no candidate for RTCP) for each media where it is desired to use
RTP and RTCP multiplexing. The answerer then performs connectivity
checks for that media as if the offer had contained only a single candidate for RTP. If the answerer does not want to multiplex RTP and RTCP on a single port, it MUST NOT include the "a=rtcp-mux" attribute in its answer and MUST perform connectivity checks for all offered candidates in the usual manner.
On receipt of the answer, the offerer looks for the presence of the "a=rtcp-mux" line for each media where multiplexing was offered. If this is present, then connectivity checks proceed as if only a single candidate (for RTP) were offered, and multiplexing is used once the session is established. If the "a=rtcp-mux" line is not present, the session proceeds with connectivity checks using both RTP and RTCP candidates, eventually leading to a session being established with RTP and RTCP on separate ports (as signalled by the "a=rtcp:" attribute).
My thought is that the cause why is not working in my example is that I'm in a LAN (no restrictive network with friendly NAT) where TURN is not needed and I have no a=rtcp-mux but 2 ICE STUN Candidates with the same port.
Another question is why MP-NG does not offer rtcp-mux event is it knows from the original SDP that rtcp-mux is prefered, at least for the "no +" case? Can't we put a rule like: ok, if we want "no + case" - decision moved to client side - and original SDP has a=rtcp-mux we generate candidates according to that. Why changing client preferences when switching to "no + - client decision"?
I hope I don't say stupid things and sorry if I do that.
Thank you.
Best regards, Mihai M
On Tue, Feb 18, 2014 at 6:43 PM, Richard Fuchs rfuchs@sipwise.com wrote:
On 02/18/14 11:12, Mihai Marin wrote:
Hello Sirs, Thank you, one step forward but still buggy - half buggy :)
Now, it's working just one way. If bob calls alice, alice will receive video but bob won't. If I stop mediaproxy-ng process (without any other modification) and redo the call, everything is just fine.
The invite sdp that alice receives is here http://pastebin.com/BgZZbbEA The sdp from OK that bob receive is here http://pastebin.com/ADGt3D3E
I noticed something strange in those 2 SDPs (just audio candidates, video are the same):
- offer
1.a. stun candidates a=candidate:1855365925 1 udp 1845501695 188.215.94.132 63015 typ srflx raddr 192.168.0.5 rport 63015 generation 0 a=candidate:1855365925 2 udp 1845501695 188.215.94.132 63015 typ srflx raddr 192.168.0.5 rport 63015 generation 0 1.b. turn candidates a=candidate:Om0baCmE7kgKNPvv 1 UDP 2130706432 93.187.138.214 30008 typ
host
a=candidate:Om0baCmE7kgKNPvv 2 UDP 2130706431 93.187.138.214 30009 typ
host
- answer
2.a. stun candidates a=candidate:1855365925 1 udp 1845501695 188.215.94.132 63028 typ srflx raddr 192.168.0.5 rport 63028 generation 0 a=candidate:1855365925 2 udp 1845501694 188.215.94.132 63031 typ srflx raddr 192.168.0.5 rport 63031 generation 0 2.b. turn candidates a=candidate:Om0baCmE7kgKNPvv 1 UDP 2130706432 93.187.138.214 30010 typ
host
No bundle in sdp but:
- offer has 1 single port for stun candidates and 2 for turn candidates
- answer has 2 ports for stun candidates and 1 for turn candidates
The kamailio log can be accessed at http://pastebin.com/tVgE3BGt
Do you have any idea why this behavior?
Yes, this is caused by MP-NG demultiplexing RTCP. I haven't thought of this before, as in our case we only use MP-NG with the '+' flag, which would eliminate this issue.
What happens is that MP-NG supports rtcp-mux in that it answers to an rtcp-mux offer and handles it correctly, but it never offers rtcp-mux to anyone, unless that endpoint is already talking rtcp-mux.
So from Alice's offer, MP-NG knows that Alice supports rtcp-mux and gladly accepts the offer in the answer sent to Alice. In this case, the same port is used for RTP and RTCP, which implies that only one ICE candidate is given for that port (only in the answer though -- in the offer, two must be given as a fallback).
However, MP-NG doesn't offer rtcp-mux to Bob, which means that Bob's answer includes separate ICE candidates for RTP and RTCP (due to separate ports). As those ICE candidates are left in place by MP-NG when translating the answer (which will include rtcp-mux), there's now a disagreement between the ICE candidates from Bob (two per candidate due to lack of rtcp-mux) and the ICE candidate inserted by MP-NG (only one due to rtcp-mux).
There's two possible solutions without resorting to the '+' flag... Either make MP-NG offer rtcp-mux to Bob initially (who may or may not accept it -- if he doesn't, nothing is fixed), or make it reject the rtcp-mux offer coming from Alice (which violates the WebRTC spec).
Another thing that MP-NG could do is to remove the RTCP ICE candidates in the answer going to Alice, hoping that Bob knows to demultiplex the RTCP packets coming in on the RTP port, despite rtcp-mux not having been negotiated.
I can't say I like any of these options :)
cheers
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
On 02/20/14 04:15, Mihai Marin wrote:
Hello Sirs, Sir Richard, I understand the problem but I don't understand the behavior. Let me tell you how I understood the problem and where I misunderstand the behavior.
BOB sens an offer to Alice with rtcp-mux. The flow is: UAC (bob) - Kamailio - MP-NG - Kamailio - UAS (alice). From the offer, MP-NG knows that bob request rtcp-mux but ignore it by removing "a=rtcp-mux" line from SDP and add 2 ICE Candidates with different ports . ALICE sends answer to BOB's offer without rtcp-mux. The flow is: UAC (alice) - Kamailio - MP-NG - Kamailio - UAS (bob). From the offer, MP-NG knows that bob accept rtcp-mux, ignore it first time, but still accept alice's answer with rtcp-mux (accepting the RTP and RTCP multiplexing) - offering rtcp-mux in response (answer).
First, I don't understand why is not working :). Offer received by alice does not contain rtcp-mux and has 2 ICE Candidates with different ports and the answer contains a=rtcp-mux and has 1 ICE Candidates for bundle.
Let me try to put it in a more concise way then.
Bob is calling Alice. Bob is offering to Alice, and Alice is answering to Bob.
Bob's point of view: Bob offers rtcp-mux. He also includes ICE candidates for RTCP as fallback, as required. Bob receives an answer accepting rtcp-mux. Thus, Bob will talk rtcp-mux and as such, the answer must not include separate ICE candidates for RTCP.
Alice's point of view: Alice receives offer without rtcp-mux. Since rtcp-mux wasn't offered, it can't be negotiated nor offered nor accepted. Alice therefore allocates a separate port for RTCP and includes separate ICE candidates for RTCP, as required.
Mediaproxy's point of view: Bob offers rtcp-mux and mediaproxy accepts it in its answer. Thus, Bob will talk rtcp-mux and therefore mediaproxy won't include a separate ICE candidate for RTCP, as required.
The problem is that Alice doesn't know that Bob talks rtcp-mux, only mediaproxy knows. Alice therefore includes separate ICE candidates for RTCP, while mediaproxy doesn't. Bob now sees separate ICE candidates for RTCP coming from Alice, although Bob is talking rtcp-mux and so those shouldn't be there.
Another question is why MP-NG does not offer rtcp-mux event is it knows from the original SDP that rtcp-mux is prefered, at least for the "no +" case? Can't we put a rule like: ok, if we want "no + case" - decision moved to client side - and original SDP has a=rtcp-mux we generate candidates according to that. Why changing client preferences when switching to "no + - client decision"?
The reason is that not all RTP clients support rtcp-mux and since mediaproxy has no real benefit from muxing RTCP, the chances of establishing media flow are higher if rtcp-mux is left out. To the offering client, it normally makes no difference (Bob sees his rtcp-mux offer accepted, as required by WebRTC, so all is good) and we are conservative with what we're sending to the answering client. You never know what a client which doesn't understand rtcp-mux will do...
If mediaproxy knew that the answering client is also WebRTC, then it would be safe to include rtcp-mux in the offer. But, it doesn't know that.
As mentioned earlier, the fact that this causes problems when ICE candidates are only inserted and not deleted is something that hasn't occurred to me before (mediaproxy's design is primarily based on it being used to unconditionally proxy the media, and not to merely serve as a fallback). I can envision something like an "rtcp-mux pass-through" mode, where mediaproxy's offering and answering of rtcp-mux depends on what the other client does. This is something that still needs to be implemented though.
I'm not sure what the default mode of operation ought to be: should the default be to always try to demux RTCP unless specified otherwise, or should the default be to go along with what the clients do unless demux is specifically requested? Any opinions on this?
cheers
Hello Sirs, Sir Richard, Thank you for your detailed explication. I'm still thinking on that but I would say to act as the caller and keep caller decision. If caller makes an offer with rtcp-mux , include separate ICE candidates for RTCP for media proxy too and forward as it is to alice. If callee accept it (or not) you will receive the OK with alice sdp, modify it (depending on her choices) and forward to bob. In this way, we cover all the cases. Eventually we can add another parameter to always ignore rtcp-mux offers.
What are the disadvantages on doing that? Is there any possibility that some SIP clients not to respond properly to an SDP with rtcp-mux and that's why you are removing it - or for '+' case where delay will be added?
Thank you for sharing it with me and again, sorry if I misunderstood something.
Have a nice weekend.
Best regards, Mihai M
On Thu, Feb 20, 2014 at 2:44 PM, Richard Fuchs rfuchs@sipwise.com wrote:
On 02/20/14 04:15, Mihai Marin wrote:
Hello Sirs, Sir Richard, I understand the problem but I don't understand the behavior. Let me tell you how I understood the problem and where I misunderstand the behavior.
BOB sens an offer to Alice with rtcp-mux. The flow is: UAC (bob) - Kamailio - MP-NG - Kamailio - UAS (alice). From the offer, MP-NG knows that bob request rtcp-mux but ignore it by removing "a=rtcp-mux" line from SDP and add 2 ICE Candidates with different ports . ALICE sends answer to BOB's offer without rtcp-mux. The flow is: UAC (alice) - Kamailio - MP-NG - Kamailio - UAS (bob). From the offer, MP-NG knows that bob accept rtcp-mux, ignore it first time, but still accept alice's answer with rtcp-mux (accepting the RTP and RTCP multiplexing) - offering rtcp-mux in response (answer).
First, I don't understand why is not working :). Offer received by alice does not contain rtcp-mux and has 2 ICE Candidates with different ports and the answer contains a=rtcp-mux and has 1 ICE Candidates for bundle.
Let me try to put it in a more concise way then.
Bob is calling Alice. Bob is offering to Alice, and Alice is answering to Bob.
Bob's point of view: Bob offers rtcp-mux. He also includes ICE candidates for RTCP as fallback, as required. Bob receives an answer accepting rtcp-mux. Thus, Bob will talk rtcp-mux and as such, the answer must not include separate ICE candidates for RTCP.
Alice's point of view: Alice receives offer without rtcp-mux. Since rtcp-mux wasn't offered, it can't be negotiated nor offered nor accepted. Alice therefore allocates a separate port for RTCP and includes separate ICE candidates for RTCP, as required.
Mediaproxy's point of view: Bob offers rtcp-mux and mediaproxy accepts it in its answer. Thus, Bob will talk rtcp-mux and therefore mediaproxy won't include a separate ICE candidate for RTCP, as required.
The problem is that Alice doesn't know that Bob talks rtcp-mux, only mediaproxy knows. Alice therefore includes separate ICE candidates for RTCP, while mediaproxy doesn't. Bob now sees separate ICE candidates for RTCP coming from Alice, although Bob is talking rtcp-mux and so those shouldn't be there.
Another question is why MP-NG does not offer rtcp-mux event is it knows from the original SDP that rtcp-mux is prefered, at least for the "no +" case? Can't we put a rule like: ok, if we want "no + case" - decision moved to client side - and original SDP has a=rtcp-mux we generate candidates according to that. Why changing client preferences when switching to "no + - client decision"?
The reason is that not all RTP clients support rtcp-mux and since mediaproxy has no real benefit from muxing RTCP, the chances of establishing media flow are higher if rtcp-mux is left out. To the offering client, it normally makes no difference (Bob sees his rtcp-mux offer accepted, as required by WebRTC, so all is good) and we are conservative with what we're sending to the answering client. You never know what a client which doesn't understand rtcp-mux will do...
If mediaproxy knew that the answering client is also WebRTC, then it would be safe to include rtcp-mux in the offer. But, it doesn't know that.
As mentioned earlier, the fact that this causes problems when ICE candidates are only inserted and not deleted is something that hasn't occurred to me before (mediaproxy's design is primarily based on it being used to unconditionally proxy the media, and not to merely serve as a fallback). I can envision something like an "rtcp-mux pass-through" mode, where mediaproxy's offering and answering of rtcp-mux depends on what the other client does. This is something that still needs to be implemented though.
I'm not sure what the default mode of operation ought to be: should the default be to always try to demux RTCP unless specified otherwise, or should the default be to go along with what the clients do unless demux is specifically requested? Any opinions on this?
cheers
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
On 02/22/14 07:07, Mihai Marin wrote:
Hello Sirs, Sir Richard, Thank you for your detailed explication. I'm still thinking on that but I would say to act as the caller and keep caller decision. If caller makes an offer with rtcp-mux , include separate ICE candidates for RTCP for media proxy too and forward as it is to alice. If callee accept it (or not) you will receive the OK with alice sdp, modify it (depending on her choices) and forward to bob. In this way, we cover all the cases. Eventually we can add another parameter to always ignore rtcp-mux offers.
What are the disadvantages on doing that? Is there any possibility that some SIP clients not to respond properly to an SDP with rtcp-mux and that's why you are removing it - or for '+' case where delay will be added?
Compatibility is exactly the reason. I don't have any exact numbers, but I'm sure that there's a large number of SIP/RTP clients out there (I'd say the vast majority) which don't support rtcp-mux at all. Some of them might start misbehaving if they receive an rtcp-mux offer (even though as per RFC, they shouldn't, but experience shows that RFC compliance is often just wishful thinking). Since from our point of view (always either '+' or '-') there's no disadvantage in always demuxing RTCP, this was what was implemented.
In any case, I'll see if I can get a solution implemented in the near future.
cheers
Just in case someone is interested, I created a sample script that could help new comers having the same problem.
I will write a blog entry explaining how this works, but in a nutshell:
- this script is configured to run behind NAT, port TCP 10080 and TCP/UDP 5090 are exposed to the Internet - you have to create valid users using, preferably, "kamctl add ..." - RTP ports should be open in range 30k-35k, inclusive - I used jssip as WEBRTC SIP UA: http://tryit.jssip.net/ - Always disable video before placing a call from jssip UA - I tested calls between: - jssip to csipsimple - csipsimple to jssip - csipsimple to csipsimple
Link to the scripts: https://github.com/caruizdiaz/kamailio-ws
Regards,
On Sat, Feb 22, 2014 at 9:31 AM, Richard Fuchs rfuchs@sipwise.com wrote:
On 02/22/14 07:07, Mihai Marin wrote:
Hello Sirs, Sir Richard, Thank you for your detailed explication. I'm still thinking on that but I would say to act as the caller and keep caller decision. If caller makes an offer with rtcp-mux , include separate ICE candidates for RTCP for media proxy too and forward as it is to alice. If callee accept it (or not) you will receive the OK with alice sdp, modify it (depending on her choices) and forward to bob. In this way, we cover all the cases. Eventually we can add another parameter to always ignore rtcp-mux offers.
What are the disadvantages on doing that? Is there any possibility that some SIP clients not to respond properly to an SDP with rtcp-mux and that's why you are removing it - or for '+' case where delay will be
added?
Compatibility is exactly the reason. I don't have any exact numbers, but I'm sure that there's a large number of SIP/RTP clients out there (I'd say the vast majority) which don't support rtcp-mux at all. Some of them might start misbehaving if they receive an rtcp-mux offer (even though as per RFC, they shouldn't, but experience shows that RFC compliance is often just wishful thinking). Since from our point of view (always either '+' or '-') there's no disadvantage in always demuxing RTCP, this was what was implemented.
In any case, I'll see if I can get a solution implemented in the near future.
cheers
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
On 02/22/14 07:07, Mihai Marin wrote:
Hello Sirs, Sir Richard, Thank you for your detailed explication. I'm still thinking on that but I would say to act as the caller and keep caller decision. If caller makes an offer with rtcp-mux , include separate ICE candidates for RTCP for media proxy too and forward as it is to alice. If callee accept it (or not) you will receive the OK with alice sdp, modify it (depending on her choices) and forward to bob. In this way, we cover all the cases. Eventually we can add another parameter to always ignore rtcp-mux offers.
Alright, can you please update your 3.0 branch from git and try with this. The rtcp-mux default now is to go along with the client's choice, which I believe should fix your use case.
On the other hand, it may break the usual WebRTC<>non-WebRTC bridging case, depending on how picky the WebRTC client is. To accommodate for this, there's a set of new flags within the control protocol to do things like accepting rtcp-mux when the other client doesn't accept it, removing an rtcp-mux offer from SDP, offering it when it wasn't offered, offering it but rejecting it on the other side, and all kinds of other scenarios (which may or may not collide with how ICE candidates are handled). I'll see if I can get those implemented into the rtpproxy-ng module soon for those who may need them.
cheers
Hello Sirs, Sir Richard, This is working perfect. I have tried the following test cases: 1. WS - WS in intranet; PASSED 2. WS - WS in different networks, both with restrictive firewalls: PASSED 3. WS - SIP Client (Boghe, Jitsi) in intranet: PASSED 4. WS - IMSDroid, both with restrictive firewalls: PASSED 5. WS - Linphone (intranet/internet): FAILED, video not receiving from WS to Linphone (Linphone does not receive video) 6. Linphone - Linphone in different networks, both with restrictive firewalls: PASSED
So, we have very good results. I'm loving it :)
I'll dig into the problem with Linphone to try to figure out what's the problem. I'll be back with news but until now looks very good.
Thank you.
Best regards, Mihai M
On Mon, Feb 24, 2014 at 9:39 PM, Richard Fuchs rfuchs@sipwise.com wrote:
On 02/22/14 07:07, Mihai Marin wrote:
Hello Sirs, Sir Richard, Thank you for your detailed explication. I'm still thinking on that but I would say to act as the caller and keep caller decision. If caller makes an offer with rtcp-mux , include separate ICE candidates for RTCP for media proxy too and forward as it is to alice. If callee accept it (or not) you will receive the OK with alice sdp, modify it (depending on her choices) and forward to bob. In this way, we cover all the cases. Eventually we can add another parameter to always ignore rtcp-mux offers.
Alright, can you please update your 3.0 branch from git and try with this. The rtcp-mux default now is to go along with the client's choice, which I believe should fix your use case.
On the other hand, it may break the usual WebRTC<>non-WebRTC bridging case, depending on how picky the WebRTC client is. To accommodate for this, there's a set of new flags within the control protocol to do things like accepting rtcp-mux when the other client doesn't accept it, removing an rtcp-mux offer from SDP, offering it when it wasn't offered, offering it but rejecting it on the other side, and all kinds of other scenarios (which may or may not collide with how ICE candidates are handled). I'll see if I can get those implemented into the rtpproxy-ng module soon for those who may need them.
cheers
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
-
Andrew Pogrebennyk -
ashutosh -
Carlos Ruiz Díaz -
Klaus Darilion -
Mihai Marin -
Muhammad Shahzad -
prevelikzalogaj -
Richard Fuchs